| 00:02:59 | c0rw1n: | c0rw1n is now known as c0rw|drnk |
| 07:57:34 | nsh__: | nsh__ is now known as nsh |
| 10:46:44 | c0rw|drnk: | c0rw|drnk is now known as c0rw1n |
| 11:44:45 | qwertyoruiop: | qwertyoruiop is now known as Guest25051 |
| 13:05:02 | hearn_: | hearn_ is now known as hearn |
| 14:04:13 | jaekwon: | maidsafe, as far as i know, might partially solve the byzantine generals problem. but it doesn't seem like it solves what i call the venetian bankers problem, with game theoretically optimal actors. |
| 14:05:15 | jaekwon: | e.g. i think maidsafe would break down as soon as somebody comes up with a fork of the software that looked to cheat the system by collaborating. |
| 14:08:25 | nsh: | does maidsafe have a white paper or anything? |
| 14:09:18 | jaekwon: | there's one paper on the improved DHT |
| 14:09:27 | jaekwon: | and a wiki on github for the rest. |
| 14:09:49 | nsh: | so their product is... hope? |
| 14:10:15 | maaku: | nsh: hope and millions of dollars! |
| 14:10:36 | jaekwon: | i just don't think we (the cryptocurrency community as a whole) really understand what problem it is that we're solving. |
| 14:10:53 | jaekwon: | everybody talks about the byzantine generals problem |
| 14:11:12 | jaekwon: | and maidsafe might solve that as well as a bunch of other shitty coins. |
| 14:11:32 | jaekwon: | but they probably actually rely on hope, yeah. |
| 14:12:21 | jaekwon: | hope that everybody runs the "official" software or protocol and not deviate from it. |
| 14:13:57 | jaekwon: | bitcoin mostly solves the problem even in the face of everybody trying to cheat or collaborate, because the given protocol is an equilibrium. |
| 14:14:08 | jaekwon: | anyways, maidsafe. crazy. |
| 14:20:06 | helo: | to me it just sounds like utopic dreaming |
| 14:24:16 | jcorgan: | but it's Bitcoin 2.0 |
| 14:24:20 | jcorgan: | and webscale |
| 14:28:51 | hearn_: | hearn_ is now known as hearn |
| 14:30:31 | stqism: | stqism is now known as stur1es |
| 14:30:44 | stur1es: | stur1es is now known as stqism |
| 17:13:22 | andytoshi: | jaekwon: until maidsafe publishes anything at all which would validate their claims, nobody here will believe that they can do anything |
| 17:13:42 | andytoshi: | and the fact that they haven't published anything after all this time is good indication that they're just hot air |
| 17:21:22 | Luke-Jr: | andytoshi: in Texas, they were making impossible claims and couldn't answer my questioning of those claims |
| 17:21:40 | Luke-Jr: | as if they didn't understand why the claims were impossible |
| 17:22:12 | Apocalyptic: | is that surprising to you Luke ? |
| 17:22:17 | Luke-Jr: | no |
| 17:22:22 | Apocalyptic: | good then |
| 17:22:29 | Luke-Jr: | makes me feel I wasted 30 mins listening to em tho :P |
| 17:42:43 | gmaxwell: | That was generally the vibe I'd recieved from their published claims. They were claiming things which I believe to be likely impossible, of course, it's not at all unlikely that I'm incorrect but they also seemed to have no sense that these things were difficult to achieve much less hard to believe. "We did something you thought impossible" is pretty likely, "We did something you thought impossible and didn't even think it was a ... |
| 17:42:49 | gmaxwell: | ... challenge" is less so... and they did this several times. |
| 17:55:25 | bitcoinh_: | Luke-Jr - who is THEY? |
| 17:55:44 | Guest25051: | Guest25051 is now known as qwertyoruiop |
| 17:55:59 | bitcoinh_: | maidsafe at the texas bitcoin conference? |
| 17:59:56 | bitcoinh_: | /msg Luke-Jr |
| 18:00:03 | Luke-Jr: | … |
| 18:03:24 | Apocalyptic: | ^ you're doing it wrong |
| 21:27:42 | postpre: | postpre is now known as prepost |
| 21:46:54 | thufir: | question for anyone familiar with the probabilistic payment concept and only? implementation that is in python: other than the psychological issues people mention, is it known to be a technically safe/working solution? such that I should spend my effort to fix psychological issue? |
| 21:49:14 | arubi: | thufir, please explain what you mean by this. I'm very curious |
| 21:50:41 | thufir: | the probabilistic payment itself? or my ideas how to enable it? |
| 21:51:24 | arubi: | I don't really understand what you mean by probabilistic payment |
| 21:51:50 | arubi: | can you give an example? |
| 21:52:18 | thufir: | oh, and correction to my original statement: nodejs implementation, not python |
| 21:52:38 | arubi: | that's secondary to my question |
| 21:52:39 | thufir: | yes, i did not come up with it, but like the idea, it is defined here: https://en.bitcoin.it/wiki/Nanopayments |
| 21:54:18 | thufir: | I suppose a nice summary is you are sending payments via a transaction that is a lottery ticket. key enabling feature is that only the recipient can know if it is a winning one or not. |
| 21:54:39 | thufir: | only winning transaction (ticket) his blockchain |
| 21:55:17 | thufir: | so the psychological issue is: i pay you a micropayment, but you get nothing because it was a loosing ticket. however, the chance was provably fair, so i did 'pay' you. |
| 21:55:45 | arubi: | that's genious! |
| 21:55:57 | arubi: | genius * |
| 21:56:13 | arubi: | I've never heard of nanopayments |
| 21:56:31 | thufir: | I thought so too! (again, not my idea, just my favorite one :) |
| 21:56:59 | arubi: | I can see why! |
| 21:57:26 | arubi: | so what's the psychological issue? |
| 21:57:52 | thufir: | i tried to word it above. ill try again... |
| 21:58:07 | nsh: | * nsh blinks |
| 21:59:30 | arubi: | * arubi blinks regularly |
| 22:00:09 | thufir: | say I wanted to pay you 0.00009 BTC, with ticket probability of 1/1024, so each a chance to win 0.1 BTC, you would need to get paid 1024 times on average before you actually receive the BTC.. |
| 22:00:57 | arubi: | so 0.00009 + 1024 = 0.1 BTC? (or a bit less) |
| 22:01:10 | thufir: | however, you must accept each ticket as a valid payment of 0.00009 regardless, and also the payer has to expect their payment to debit them 0 or a 1 in 1024 chance of 0.1 btc |
| 22:02:46 | thufir: | so my original question is, is there anyone who has played with or spent thought on the issue who thinks the current implementation is flawed in that it could be exploited |
| 22:03:13 | arubi: | how? it seems pretty air tight to me |
| 22:04:04 | arubi: | as I understand it, the tx in question has more than 1 input. one is an input placed in and signed by the creator an of the tx, the client who is benefiting a service. |
| 22:04:58 | arubi: | she signs a tx with an input of 0.00009 btc that she controls, and adds to that tx an input that the service provider controls |
| 22:05:11 | arubi: | hmm wait, lemme read the wiki again |
| 22:07:01 | arubi: | now I'm not so sure: "Alice will create a multi-input transaction that spends her own coin AND Bob's secret transaction" |
| 22:07:15 | arubi: | what can be Bob's secret tx? |
| 22:08:09 | thufir: | it looks tight, but wondering if any changes to p2p protocol, etc, for instance disabled script opcodes, would have broke it, etc. |
| 22:09:11 | thufir: | bob's secret tx is one that is sent to alice first, off-chain |
| 22:10:48 | thufir: | sorry, he does not send it, just a range that the hash in his secret tx is in, alice is trying to guess it when generating her tx (the lottery ticket), bob has the secret tx so he will know if hers is valid or not, but not her |
| 22:12:13 | arubi: | yea but what are the inputs and outpus of his tx? how does it looks like? |
| 22:12:35 | arubi: | I mean, what does alice iterate over when trying to guess his tx? |
| 22:14:25 | thufir: | so yes, the inputs of his is why he actually has to have some coin to receive coin, as his ticket which is kept secret sends her btc, but her ticket includes sending it back to him. her ticket includes her payment of the full 0.1 btc and also a guess at his tx as input. he only told her a range his input is in |
| 22:15:50 | arubi: | I dunno, that doesn't sound right.. are you sure? |
| 22:17:01 | thufir: | somewhat. i suppose i will just port the nodejs to java :) sorry :) and in doing so learn the details. i've been unable to contact hi-entrophy, the implementor of the nodejs version, |
| 22:18:20 | arubi: | can you link me to the nodejs code? |
| 22:18:39 | thufir: | https://github.com/paulkernfeld/bitcoin-nanopayment |
| 22:19:39 | arubi: | thanks |
| 22:19:50 | thufir: | no problem! |
| 22:44:55 | andytoshi: | thufir: probablistic payments may be broken by tx malleability |
| 22:45:48 | thufir: | andytoshi: oh no! well that is what I was looking for. by what you say you mean broken by the change that was introduced to fix the tx malleability problem? |
| 22:46:07 | thufir: | andytoshi: either way, thanks for that very much! |
| 22:46:28 | andytoshi: | thufir: no, i mean it is broken by the malleability problem |
| 22:47:05 | andytoshi: | which there is no fix for, all that was fixed was the clients' handling of malleability (which was not ugly but not seriously broken) |
| 22:47:11 | andytoshi: | was ugly* |
| 22:47:25 | thufir: | aaah, i see. the fix was more midigation? |
| 22:47:54 | andytoshi: | yeah, sipa has a BIP which is toward a proper fix |
| 22:48:25 | thufir: | I will look up on that then, I am not familiar with what other than high level. |
| 22:48:43 | andytoshi: | but for example we don't even know if we know all the ways the ECDSA part of bitcoin signatures can be modified, so it may be incomplete |
| 22:50:01 | thufir: | ah right, now i am remembering, its actually the math allowing it, hmm. so you think it would allow bob to cheat by indeed modifying his secret tx to match alices guess? |
| 22:50:27 | andytoshi: | no, that can't happen, that would imply that SHA256d is broken |
| 22:50:36 | andytoshi: | which would in turn completely destroy the blockchain :) |
| 22:51:20 | andytoshi: | but it might cause him to lose the coins after broadcasting his tx, even if he broadcasts it alongside alice's tx |
| 22:51:54 | thufir: | ah, thx, was just about to ask what vector of attack it provided then. |
| 22:53:42 | thufir: | is that BIP accepted? or would it not be likely to be fixed before a better thing than probailitic payments like higherarchical chains? |
| 22:54:56 | andytoshi: | i'm not sure what it's status is, but for now all it does is make weirdly-formed transactions nonstandard. a next step would be to make them actually invalid, but that is a forking change and not to be done lightly |
| 22:55:09 | andytoshi: | there are more than enough usecases to justify a fork for malleability fixing... |
| 22:55:20 | andytoshi: | ...but what we lack is a solution which we -know- to be an actual solution |
| 22:55:26 | thufir: | agreed. much of the potential revolutionary power of bitcoin is the power of the script, so limiting it would be unfortunate |
| 22:55:35 | thufir: | ah, i see |
| 22:56:35 | andytoshi: | well, with malleability you don't lose expressivity, by definition we would only kill scripts which have other functionally-identical forms |
| 22:56:42 | thufir: | thank you very much then! looks like I am to first grok tx malleability before attempting to proceed further then. |
| 22:57:04 | thufir: | that is good news |
| 22:57:05 | andytoshi: | maybe read the first and last page of https://download.wpsoftware.net/bitcoin/malleability-faq.pdf |
| 22:57:21 | thufir: | thanks! |
| 22:57:31 | andytoshi: | the rest is just current-events gibberish which isn't current anymore (and all the gox stuff is actually untrue, i think) |
| 22:58:28 | thufir: | using gox and untrue in the same sentance is very redundant :) |
| 23:01:03 | thufir: | wow, this explains it much better than my previous read (https://en.bitcoin.it/wiki/Transaction_Malleability) did, thanks again |
| 23:07:44 | andytoshi: | oh, cool, happy to hear it :) |