| 05:20:50 | adam3us: | adam3us has left #bitcoin-wizards |
| 05:26:14 | justanotheruser: | Is it possible to make a linked set of transactions safe from malleability attacks? |
| 05:29:35 | Luke-Jr: | no |
| 05:31:18 | justanotheruser: | Not in a theoretical future btc? |
| 05:31:45 | Luke-Jr: | oh, sure then |
| 05:32:07 | justanotheruser: | Maybe having the previous tx linked based on its index in the utxo |
| 05:32:08 | Luke-Jr: | well, I'm not sure if it's confirmed possible, but one can imagine how to try to do it at least |
| 05:32:23 | adam3us: | justanotheruser: well if you wait until the first tx is confirmed in the block chain eg 6 blocks before revealing the dependent transaction |
| 05:32:24 | Luke-Jr: | eh, you could do that I guess, but it'd be ugly |
| 05:32:30 | Luke-Jr: | and you coudln't chain then |
| 05:32:40 | Luke-Jr: | adam3us: that isn't useful in many cases |
| 05:32:58 | justanotheruser: | What is the better method? |
| 05:33:00 | Luke-Jr: | justanotheruser: I'd just replace (txid,index) inputs with H(sPK) |
| 05:33:21 | justanotheruser: | adam3us: are you talking about bitcoin now? |
| 05:33:30 | justanotheruser: | Luke-Jr: sPK? |
| 05:35:03 | adam3us: | justanotheruser: yes. its a significantly limiting work around as Luke-Jr says however |
| 05:35:29 | Luke-Jr: | justanotheruser: scriptPubKey |
| 05:36:08 | shesek: | Luke-Jr, how would that work exactly? you could have multiple outputs with the same scriptPubKey |
| 05:36:09 | Luke-Jr: | actually, forget scriptPubKey, just make it hashScript :P |
| 05:36:21 | Luke-Jr: | shesek: no, you couldn't. you're already not supposed to ☺ |
| 05:36:58 | shesek: | there are cases where its useful |
| 05:37:08 | shesek: | like, say, two parties making payments to the same multisig address |
| 05:37:10 | justanotheruser: | adam3us: does this solve anything if the original tx's hash is changed? |
| 05:37:14 | shesek: | for a sports bet or something |
| 05:37:21 | Luke-Jr: | shesek: you're not supposed to do that either ;) |
| 05:37:57 | shesek: | well... each one of them could generate two public keys and create two separate multisigs for that |
| 05:38:04 | shesek: | but it does add some complexity |
| 05:38:06 | justanotheruser: | Luke-Jr: seems workable |
| 05:38:34 | Luke-Jr: | justanotheruser: it's intentionally safe with signer-initiated malleations too (coinjoin for example) |
| 05:38:55 | shesek: | Luke-Jr, and what would happen if people reuse the scriptpubkey/scripthash anyway? the network would just reject it? |
| 05:39:02 | justanotheruser: | shesek: hopefully people would use a program that handles all the low level details for them |
| 05:39:17 | justanotheruser: | Luke-Jr: anything controversial about it? |
| 05:39:34 | shesek: | justanotheruser, just because a programmer has to deal with that complexity doesn't mean its not complex ^_^ |
| 05:40:21 | justanotheruser: | shesek: I wouldn't consider handling 4 keys much more complex that two keys for a programmer |
| 05:41:29 | shesek: | justanotheruser, the general notion of never reusing public keys at all does add some complexities... it could be a long-lasting contract where both parties exchange payments on a regular basis |
| 05:41:45 | shesek: | though in those cases I'd probably prefer to go with public key per transaction anyway |
| 05:42:03 | Luke-Jr: | justanotheruser: it's either a hardfork, or nearly doubles transaction sizes; it is incompatible with address reuse abuses; etc |
| 05:42:19 | shesek: | is something up with testnet? my client it stuck on "0 hours behind" for quite some time now |
| 05:42:39 | shesek: | and none of the transaction I'm sending from my client, or sending from a faucet, are showing up on any on the block explorers |
| 05:42:48 | justanotheruser: | Luke-Jr: this could be done without a hard fork? |
| 05:43:00 | Luke-Jr: | justanotheruser: a softfork |
| 05:43:01 | shesek: | ah, never mind... there we go |
| 05:43:39 | Luke-Jr: | justanotheruser: it'd be an ugly hack tho |
| 05:43:44 | Luke-Jr: | worse than BIP 16 |
| 05:43:59 | justanotheruser: | Luke-Jr: how? Wouldn't new tx that don't reference the previous txid be invalid for old clients? |
| 05:44:22 | Luke-Jr: | justanotheruser: yes, but you'd make it so miners could freely change the txid-based input ids |
| 05:44:35 | Luke-Jr: | eg, skip them entirely in the signature |
| 05:45:39 | justanotheruser: | I see |
| 05:46:18 | justanotheruser: | These hacks you wizards come up with are pretty impressive |
| 05:46:47 | justanotheruser: | There's a few things I have thought were impossible without a hard fork |
| 05:47:32 | Luke-Jr: | if we were to do that one, I'd probably prefer a hardfork. |
| 05:48:35 | justanotheruser: | Yeah. Hopefully a few really useful hard forks can be already implemented for when a hard fork is needed for security reasons |
| 05:48:40 | justanotheruser: | If/when |
| 05:52:35 | maaku: | Luke-Jr: the signature would be over the txid though, right? i'm not sure how to do that as a soft-fork |
| 05:52:48 | maaku: | justanotheruser: we should be able to eliminate malleability through whack-a-mole fixes |
| 05:52:51 | Luke-Jr: | maaku: no, it wouldn't. |
| 05:53:04 | maaku: | assuming ECDSA itself is not malleable |
| 05:53:05 | justanotheruser: | Maaku |
| 05:53:09 | Luke-Jr: | maaku: you'd replace OP_CHECKSIGVERIFY with OP_NOP3 and make it do what you need |
| 05:53:30 | maaku: | Luke-Jr: ok, and yes that's a butt ugly hack |
| 05:54:08 | justanotheruser: | maaku: i wont believe a transaction can't be malleable until there is a mathematical proof |
| 05:54:22 | maaku: | justanotheruser: you won't get it |
| 05:54:40 | justanotheruser: | maaku: why not? |
| 05:55:56 | maaku: | because there are too many factors involved, and the system is orders of magnitude too complex to formally verify, and probably undecidable if we did |
| 05:56:43 | maaku: | best you can do (short of scrapping the current system with a manditory script replacement, for example) is fix known sources of malleability |
| 05:56:48 | justanotheruser: | maaku: orders of magnitude more complex than ecdsa? |
| 05:57:19 | maaku: | but you can't *proove* there are no other sources -- someone might find a bug in bitcoin or openssl that lets you change some field in some inconsequential way |
| 05:57:42 | maaku: | justanotheruser: yes more complex. it's not even comparable |
| 05:58:25 | maaku: | ecdsa is just a simple equation. proving there is no malleability means formalizing the entire consensus code, including script execution, *and* the platform on which it runs (x86 or compiler bugs) |
| 05:58:50 | maaku: | anything less than that and you are making assumptions that may not actually hold |
| 05:59:03 | justanotheruser: | Too bad. Hopefully a hard fork will include Luke-Jrs idea |
| 06:00:05 | maaku: | but if you lessen the requirements to "All known sources of malleability are fixed", then that's doable |
| 06:01:41 | justanotheruser: | maaku: I'd rather not have everyone risking their smart contracts |
| 06:10:08 | maaku: | justanotheruser: it's no more than the current risk that there might exist an anyone-can-spend-all-coins bug |
| 06:10:25 | maaku: | which bitcoin has already suffered once, and a near-miss another recently |
| 06:11:24 | justanotheruser: | maaku: what was the recent miss |
| 06:12:44 | maaku: | well it wasn't recent code so much as recent realization - signaturehash returns 1 if an index is out of bounds. if it had returned zero instead you could use that to steal coins |
| 06:14:47 | maaku: | that code's been in bitcoin since the beginning, so maybe satoshi knew what he was doing. but given the number of other more obvious bugs which did exist, i'd give even odds that it was a very lucky accidental near-miss |
| 06:27:49 | shinybro_: | shinybro_ is now known as cancerbro |
| 06:41:00 | cancerbro: | cancerbro is now known as resurrectionbro |
| 06:57:58 | resurrectionbro: | resurrectionbro is now known as shinybro_ |
| 10:10:29 | sl01: | was curious if any of you realized that maidsafe is claiming to have a brand new solution to double spending problem, seems bogus to me but I wonder if any of you looked at it |
| 10:11:47 | sl01: | there's some discussion of it here from their leader: http://www.reddit.com/r/maidsafe/comments/23z7fh/how_does_safecoin_solve_the_doublespend_issue/ |
| 11:44:31 | fanquake: | fanquake has left #bitcoin-wizards |
| 11:53:12 | Quanttek_: | Quanttek_ is now known as Quanttek |
| 11:54:53 | wallet421: | wallet421 is now known as wallet42 |
| 12:39:42 | andytoshi: | ah yes, the "trust is fine, bribing people probably won't work because they'll just take the bribe but not act on it" proof of security |
| 12:40:41 | Apocalyptic: | I lol'd |
| 15:03:52 | andytoshi: | i have been reading about "chameleon signatures" http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.50.3262 perhaps a useful primitive for bitcoin contracts? |
| 15:07:37 | hearn: | well, it depends how you define contracts i guess. if you mean the transactions themselves, everyone has to be able to check all signatures, so …. doubtful |
| 15:07:48 | hearn: | in other external protocols that are related to forming contracts? maybe. not sure. |
| 15:35:22 | gmaxwell: | andytoshi: https://bitcointalk.org/index.php?topic=318279.0 |
| 15:37:57 | andytoshi: | gmaxwell: oh, thx, i see you're six months ahead of me :) |
| 15:39:33 | hearn: | oh yes. i remember that now |
| 15:43:13 | hearn: | though i sort of struggle to come up with a situation where being forced to reveal a contract might happen |
| 18:40:10 | zooko`: | zooko` is now known as zooko |
| 22:15:36 | phantomcircuit: | i am CEO of the blockchain |
| 22:15:42 | phantomcircuit: | all do as i say! |
| 22:16:41 | petertodd: | phantomcircuit: your message makes less sense with join/quit notifications silence |
| 22:16:47 | phantomcircuit: | lol |
| 22:16:48 | phantomcircuit: | right |
| 22:16:56 | phantomcircuit: | * [phantomcircuit] (~phantomci@blockchain.ceo): phantomcircuit |