05:20:50adam3us:adam3us has left #bitcoin-wizards
05:26:14justanotheruser:Is it possible to make a linked set of transactions safe from malleability attacks?
05:31:18justanotheruser:Not in a theoretical future btc?
05:31:45Luke-Jr:oh, sure then
05:32:07justanotheruser:Maybe having the previous tx linked based on its index in the utxo
05:32:08Luke-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:23adam3us: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:24Luke-Jr:eh, you could do that I guess, but it'd be ugly
05:32:30Luke-Jr:and you coudln't chain then
05:32:40Luke-Jr:adam3us: that isn't useful in many cases
05:32:58justanotheruser:What is the better method?
05:33:00Luke-Jr:justanotheruser: I'd just replace (txid,index) inputs with H(sPK)
05:33:21justanotheruser:adam3us: are you talking about bitcoin now?
05:33:30justanotheruser:Luke-Jr: sPK?
05:35:03adam3us:justanotheruser: yes. its a significantly limiting work around as Luke-Jr says however
05:35:29Luke-Jr:justanotheruser: scriptPubKey
05:36:08shesek:Luke-Jr, how would that work exactly? you could have multiple outputs with the same scriptPubKey
05:36:09Luke-Jr:actually, forget scriptPubKey, just make it hashScript :P
05:36:21Luke-Jr:shesek: no, you couldn't. you're already not supposed to ☺
05:36:58shesek:there are cases where its useful
05:37:08shesek:like, say, two parties making payments to the same multisig address
05:37:10justanotheruser:adam3us: does this solve anything if the original tx's hash is changed?
05:37:14shesek:for a sports bet or something
05:37:21Luke-Jr:shesek: you're not supposed to do that either ;)
05:37:57shesek:well... each one of them could generate two public keys and create two separate multisigs for that
05:38:04shesek:but it does add some complexity
05:38:06justanotheruser:Luke-Jr: seems workable
05:38:34Luke-Jr:justanotheruser: it's intentionally safe with signer-initiated malleations too (coinjoin for example)
05:38:55shesek:Luke-Jr, and what would happen if people reuse the scriptpubkey/scripthash anyway? the network would just reject it?
05:39:02justanotheruser:shesek: hopefully people would use a program that handles all the low level details for them
05:39:17justanotheruser:Luke-Jr: anything controversial about it?
05:39:34shesek:justanotheruser, just because a programmer has to deal with that complexity doesn't mean its not complex ^_^
05:40:21justanotheruser:shesek: I wouldn't consider handling 4 keys much more complex that two keys for a programmer
05:41:29shesek: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:45shesek:though in those cases I'd probably prefer to go with public key per transaction anyway
05:42:03Luke-Jr:justanotheruser: it's either a hardfork, or nearly doubles transaction sizes; it is incompatible with address reuse abuses; etc
05:42:19shesek:is something up with testnet? my client it stuck on "0 hours behind" for quite some time now
05:42:39shesek: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:48justanotheruser:Luke-Jr: this could be done without a hard fork?
05:43:00Luke-Jr:justanotheruser: a softfork
05:43:01shesek:ah, never mind... there we go
05:43:39Luke-Jr:justanotheruser: it'd be an ugly hack tho
05:43:44Luke-Jr:worse than BIP 16
05:43:59justanotheruser:Luke-Jr: how? Wouldn't new tx that don't reference the previous txid be invalid for old clients?
05:44:22Luke-Jr:justanotheruser: yes, but you'd make it so miners could freely change the txid-based input ids
05:44:35Luke-Jr:eg, skip them entirely in the signature
05:45:39justanotheruser:I see
05:46:18justanotheruser:These hacks you wizards come up with are pretty impressive
05:46:47justanotheruser:There's a few things I have thought were impossible without a hard fork
05:47:32Luke-Jr:if we were to do that one, I'd probably prefer a hardfork.
05:48:35justanotheruser:Yeah. Hopefully a few really useful hard forks can be already implemented for when a hard fork is needed for security reasons
05:52:35maaku: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:48maaku:justanotheruser: we should be able to eliminate malleability through whack-a-mole fixes
05:52:51Luke-Jr:maaku: no, it wouldn't.
05:53:04maaku:assuming ECDSA itself is not malleable
05:53:09Luke-Jr:maaku: you'd replace OP_CHECKSIGVERIFY with OP_NOP3 and make it do what you need
05:53:30maaku:Luke-Jr: ok, and yes that's a butt ugly hack
05:54:08justanotheruser:maaku: i wont believe a transaction can't be malleable until there is a mathematical proof
05:54:22maaku:justanotheruser: you won't get it
05:54:40justanotheruser:maaku: why not?
05:55:56maaku: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:43maaku: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:48justanotheruser:maaku: orders of magnitude more complex than ecdsa?
05:57:19maaku: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:42maaku:justanotheruser: yes more complex. it's not even comparable
05:58:25maaku: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:50maaku:anything less than that and you are making assumptions that may not actually hold
05:59:03justanotheruser:Too bad. Hopefully a hard fork will include Luke-Jrs idea
06:00:05maaku:but if you lessen the requirements to "All known sources of malleability are fixed", then that's doable
06:01:41justanotheruser:maaku: I'd rather not have everyone risking their smart contracts
06:10:08maaku:justanotheruser: it's no more than the current risk that there might exist an anyone-can-spend-all-coins bug
06:10:25maaku:which bitcoin has already suffered once, and a near-miss another recently
06:11:24justanotheruser:maaku: what was the recent miss
06:12:44maaku: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:47maaku: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:49shinybro_:shinybro_ is now known as cancerbro
06:41:00cancerbro:cancerbro is now known as resurrectionbro
06:57:58resurrectionbro:resurrectionbro is now known as shinybro_
10:10:29sl01: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:47sl01: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:31fanquake:fanquake has left #bitcoin-wizards
11:53:12Quanttek_:Quanttek_ is now known as Quanttek
11:54:53wallet421:wallet421 is now known as wallet42
12:39:42andytoshi: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:41Apocalyptic:I lol'd
15:03:52andytoshi:i have been reading about "chameleon signatures" http://citeseerx.ist.psu.edu/viewdoc/summary?doi= perhaps a useful primitive for bitcoin contracts?
15:07:37hearn: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:48hearn:in other external protocols that are related to forming contracts? maybe. not sure.
15:35:22gmaxwell:andytoshi: https://bitcointalk.org/index.php?topic=318279.0
15:37:57andytoshi:gmaxwell: oh, thx, i see you're six months ahead of me :)
15:39:33hearn:oh yes. i remember that now
15:43:13hearn:though i sort of struggle to come up with a situation where being forced to reveal a contract might happen
18:40:10zooko`:zooko` is now known as zooko
22:15:36phantomcircuit:i am CEO of the blockchain
22:15:42phantomcircuit:all do as i say!
22:16:41petertodd:phantomcircuit: your message makes less sense with join/quit notifications silence
22:16:56phantomcircuit:* [phantomcircuit] (~phantomci@blockchain.ceo): phantomcircuit