Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-20 Thread Gregory Maxwell
On Thu, Feb 20, 2014 at 10:07 PM, Mike Hearn wrote: > No, I was thinking of the height in coinbase change. At any rate, p2sh was > supported by the consensus code in bitcoinj for a long time already, since > it was first written. > > Support for sending to such addresses in the wallet appeared onc

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-20 Thread Mike Hearn
No, I was thinking of the height in coinbase change. At any rate, p2sh was supported by the consensus code in bitcoinj for a long time already, since it was first written. Support for sending to such addresses in the wallet appeared once an app that wanted that support also appeared, which seems O

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-20 Thread Gregory Maxwell
On Thu, Feb 20, 2014 at 7:11 AM, Pieter Wuille wrote: > I hereby request a BIP number. 62 assigned. -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pit

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-20 Thread Pieter Wuille
I hereby request a BIP number. On Thu, Feb 20, 2014 at 3:58 PM, Gavin Andresen wrote: > Great, I'm hearing rough consensus to proceed with Pieter's plan. > > RE: far from confident on malleability routes: I'm reasonably confident > that we can squash malleability for IsStandard, SIGHASH_ALL tra

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-20 Thread Gavin Andresen
Great, I'm hearing rough consensus to proceed with Pieter's plan. RE: far from confident on malleability routes: I'm reasonably confident that we can squash malleability for IsStandard, SIGHASH_ALL transactions. A proper proof of DSA signature un-malleability (or an lower bound for how much work

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-20 Thread Gregory Maxwell
On Thu, Feb 20, 2014 at 6:29 AM, Gavin Andresen wrote: > I think we should get Pieter's proposal done and implemented quickly. I > agree with Mike, it doesn't have to take a long time for the core network to > fully support this. > > Getting wallets to start generating transaction.version=3 might

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-20 Thread Gavin Andresen
I think we should get Pieter's proposal done and implemented quickly. I agree with Mike, it doesn't have to take a long time for the core network to fully support this. Getting wallets to start generating transaction.version=3 might take years, but that is OK. -- -- Gavin Andresen --

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-20 Thread Gregory Maxwell
On Thu, Feb 20, 2014 at 6:08 AM, Mike Hearn wrote: > We've done forking changes before much faster than a year and that was with > less experience. If we want, we can get this done within months. You mean P2SH... which your implementation has only picked up support for in the last month or so? -

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-20 Thread Mike Hearn
We've done forking changes before much faster than a year and that was with less experience. If we want, we can get this done within months. On 20 Feb 2014 16:30, "Michael Gronager" wrote: > As I see the BIP it is basically stressing that ver 1 transactions are > malleable. > > It then addresses

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-20 Thread Michael Gronager
As I see the BIP it is basically stressing that ver 1 transactions are malleable. It then addresses the need for unmalleable transactions for e.g. spending unconfirmed outputs in a deterministic way (i.e. no 3rd party can sabotage) - this transaction type is defined as ver 3. A lot of clients

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-19 Thread Natanael
You could pregenerate entire "trees" of alternative outcomes where you pick one branch / chain to broadcast based on the real world events as they happen. But I see another problem regarding use of oracles, if you have a P2SH address with 2-of-3 signatures or similar in the chain, amd some transac

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-19 Thread Allen Piscitello
This is somewhat problematic in my use case since some parts need to be in the chain earlier than others and have the same ID as expected. https://bitcointalk.org/index.php?topic=260898.10 I haven't gone back to see if there are any ways around it, but the main problem here is I need the Contract

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-19 Thread Natanael
Regarding chains of transactions intended to be published at once together, wouldn't it be easier to add a "only-mine-with-child flag"? That way the parent transactions aren't actually valid unless spent together with the transaction that depends on it, and only the original will have a child refe

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-19 Thread Pieter Wuille
On Wed, Feb 19, 2014 at 9:28 PM, Michael Gronager wrote: > I think that we could guarantee fewer incidents by making version 1 > transactions unmalleable and then optionally introduce a version 3 that > supported the malleability feature. That way most existing problematic > implementations wou

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-19 Thread Gregory Maxwell
dOn Wed, Feb 19, 2014 at 12:49 PM, Peter Todd wrote: > While we might be able to get away with a retroactive change in meaning right > now in the future that won't be so easy. There are lots if proposed > applications for nLockTime-using protocols that depend on transactions (or > parts of tran

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-19 Thread Peter Todd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 While we might be able to get away with a retroactive change in meaning right now in the future that won't be so easy. There are lots if proposed applications for nLockTime-using protocols that depend on transactions (or parts of transactions) bei

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-19 Thread Gregory Maxwell
On Wed, Feb 19, 2014 at 12:28 PM, Michael Gronager wrote: > Twisting your words a bit I read: > > * you want to support relay of transactions that can be changed on the fly, > but you consider it wrong to modify them. > * #3 is already not forwarded, but you still find it relevant to support it.

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-19 Thread Michael Gronager
Twisting your words a bit I read: * you want to support relay of transactions that can be changed on the fly, but you consider it wrong to modify them. * #3 is already not forwarded, but you still find it relevant to support it. Rational use cases of #3 will be pretty hard to find given the fact

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-19 Thread Jeremy Spilman
Longer term it would be more ideal have a canonical identifier for the transaction before it even gets to the chain to support these use cases, even if wallets are able to properly identify the status of it's transactions.   -Allen One possible work-around to get back trusted transaction chaining

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-19 Thread Pieter Wuille
On Wed, Feb 19, 2014 at 3:11 PM, Michael Gronager wrote: > Why introduce a new transaction version for this purpose ? Wouldn't it be > more elegant to simply let: > > 1. the next bitcoin version "prettify" all relayed transactions as > deterministic transactions fulfilling the scheme 1-6 effecti

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-19 Thread Michael Gronager
Why introduce a new transaction version for this purpose ? Wouldn't it be more elegant to simply let: 1. the next bitcoin version "prettify" all relayed transactions as deterministic transactions fulfilling the scheme 1-6 effectively blocking any malleability attack? If miners would upgrade the

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-12 Thread Gregory Maxwell
On Wed, Feb 12, 2014 at 4:39 PM, Alex Morcos wrote: > I apologize if this has been discussed many times before. It has been, but there are probably many people like you who have not bothered researching who may also be curious. > As a long term solution to malleable transactions, wouldn't it be

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-12 Thread Alex Morcos
I apologize if this has been discussed many times before. As a long term solution to malleable transactions, wouldn't it be possible to modify the signatures to be of the entire transaction. Why do you have to zero out the inputs? I can see that this would be a hard fork, and maybe it would be s

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-12 Thread Luke-Jr
On Wednesday, February 12, 2014 8:27:52 PM Mark Friedenbach wrote: > On 02/12/2014 08:44 AM, Alan Reiner wrote: > > Changing the protocol to use these static IDs is a pretty fundamental > > change that would never happen in Bitcoin. But they can still be > > useful at the application level to mit

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-12 Thread Mark Friedenbach
On 02/12/2014 08:44 AM, Alan Reiner wrote: > Changing the protocol to use these static IDs is a pretty fundamental > change that would never happen in Bitcoin. But they can still be > useful at the application level to mitigate these issues. Not to mention that it would be potentially very insec

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-12 Thread Alan Reiner
We're talking about two slightly different things. If their system had tracked by inputs and outputs (or some kind of static ID) , their system wouldn't have been issuing refunds/replacements/cancellations in the first place. I agree with you that the reissuing code should also guarantee that bot

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-12 Thread Gregory Maxwell
On Wed, Feb 12, 2014 at 7:12 AM, Rune Kjær Svendsen wrote: > Instead of trying to remove the possibility of transaction > malleability, would it make sense to define a new, "canonical > transaction hash/ID" (cTxID), which would be a hash of the part of the > transaction data which we know is not m

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-12 Thread Pieter Wuille
On Wed, Feb 12, 2014 at 5:56 PM, Pavol Rusnak wrote: > On 02/10/2014 12:33 AM, Pieter Wuille wrote: >> The proposed document is here: https://gist.github.com/sipa/8907691 > > If we are bumping nVersion, how about dropping DER encoding completely > and using just 64 bytes directly for signature? T

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-12 Thread Pieter Wuille
It's also not necessary for wallet software - it's really just for human consumption. A wallet can easily detect inputs being respent in another transaction. You don't need a static hash for that (which wouldn't need with all hash types, non-malleability double spends, ...). On Wed, Feb 12, 2014

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-12 Thread Pavol Rusnak
On 02/10/2014 12:33 AM, Pieter Wuille wrote: > The proposed document is here: https://gist.github.com/sipa/8907691 If we are bumping nVersion, how about dropping DER encoding completely and using just 64 bytes directly for signature? Also using 2 different variable integer encodings (in addition

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-12 Thread Jeff Garzik
On Wed, Feb 12, 2014 at 10:12 AM, Rune Kjær Svendsen wrote: > Instead of trying to remove the possibility of transaction > malleability, would it make sense to define a new, "canonical > transaction hash/ID" (cTxID), Yes, that is one proposal: https://github.com/sipa/bitcoin/commits/normtxid Bu

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-12 Thread Alan Reiner
Agreed. I'm not suggesting that malleability shouldn't be fixed or isn't a problem. I would love to be able to leverage chained TX for Bitcoin contracts. But that in its current state it doesn't have to be complicated to deal with it. Changing the protocol to use these static IDs is a pretty f

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-12 Thread Allen Piscitello
While that solution does work for many use cases, it does make it much harder to do anything needing chained transactions. Granted, this is the short term solution for current implementations, but having a transaction identifier that does not change does open up other use cases. For example, Alic

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-12 Thread Alan Reiner
I think the solution is simply to encourage Bitcoin software developers to design their software to use this static ID, instead of the full transaction hash.If MtGox had talked those IDs instead of the TX ID, their software would've correctly identified the mutated transactions and there would

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-12 Thread Rune Kjær Svendsen
Instead of trying to remove the possibility of transaction malleability, would it make sense to define a new, "canonical transaction hash/ID" (cTxID), which would be a hash of the part of the transaction data which we know is not malleable, and have clients use this cTxID internally, thus making th

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-09 Thread Luke-Jr
On Sunday, February 09, 2014 11:33:02 PM Pieter Wuille wrote: > The proposed document is here: https://gist.github.com/sipa/8907691 Rule 3 & 4 are already enforced. AFAIK nVersion==3 transactions are not currently considered non-standard? Luke ---

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-09 Thread Peter Todd
On Mon, Feb 10, 2014 at 12:33:02AM +0100, Pieter Wuille wrote: > Hello all, > > it was something I planned to do since a long time, but with the > recent related issues popping up, I finally got around to writing a > BIP about how we can get rid of transaction malleability over time. > > The prop

[Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-09 Thread Pieter Wuille
Hello all, it was something I planned to do since a long time, but with the recent related issues popping up, I finally got around to writing a BIP about how we can get rid of transaction malleability over time. The proposed document is here: https://gist.github.com/sipa/8907691 I expect most ru