Re: [bitcoin-dev] [BIP] Normalized transaction IDs

2015-11-05 Thread Luke Dashjr via bitcoin-dev
On Thursday, November 05, 2015 3:27:37 PM Jorge Timón wrote: > On Tue, Nov 3, 2015 at 11:01 PM, Luke Dashjr via bitcoin-dev > > wrote: > > On Tuesday, November 03, 2015 9:44:02 PM Christian Decker wrote: > >> So this is indeed a form of desired malleability

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

2015-11-05 Thread s7r via bitcoin-dev
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Right. Wallets are covering malleability in acceptable ways. Normal user to user payments aren't (or at least shouldn't be) affected by malleability. Problems appear in second level and third level malleability, when Alice sends txB to Bob which

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

2015-11-05 Thread Adam Back via bitcoin-dev
About the conflicting spends by the private key holder (self signature malleability) that is in principle kind of fixable. You make a new pub key type which is r,Q (where r is the DSA signature component but chosen at key gen time, Q=xG is the pub key, r is point compressed R = (r,f(r)) = kG ), r

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

2015-11-05 Thread Jorge Timón via bitcoin-dev
On Tue, Nov 3, 2015 at 11:01 PM, Luke Dashjr via bitcoin-dev wrote: > On Tuesday, November 03, 2015 9:44:02 PM Christian Decker wrote: >> So this is indeed a form of desired malleability we will likely not be able >> to fix. I'd argue that this goes more

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

2015-11-03 Thread Christian Decker via bitcoin-dev
On Tue, Nov 3, 2015 at 9:49 PM Luke Dashjr wrote: > On Tuesday, November 03, 2015 8:37:44 PM Christian Decker wrote: > > I am still very much intrigued by Luke's idea of having empty scriptsigs > > and ship the signatures in external scripts, however the proposal uses > the > >

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

2015-11-03 Thread Luke Dashjr via bitcoin-dev
On Tuesday, November 03, 2015 9:44:02 PM Christian Decker wrote: > Ok, so assuming we can get a connected component of upgraded nodes that > relay both the transaction and the associated external scripts then we > could just piggyback the external scripts on top of the normal messages. >

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

2015-11-03 Thread Peter Todd via bitcoin-dev
On Tue, Nov 03, 2015 at 09:44:02PM +, Christian Decker via bitcoin-dev wrote: > Ok, so assuming we can get a connected component of upgraded nodes that > relay both the transaction and the associated external scripts then we > could just piggyback the external scripts on top of the normal

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

2015-10-22 Thread Gregory Maxwell via bitcoin-dev
On Thu, Oct 22, 2015 at 8:26 AM, Christian Decker via bitcoin-dev wrote: > Normalized transaction IDs do help in the case that the single signer wants > to immediately follow up its transaction with another transaction spending > the first one's change

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

2015-10-22 Thread Christian Decker via bitcoin-dev
Indeed the reason I got started with all of this is the use of normalized transaction IDs within smart contracts with multiple signers. Sorry if I was perceived as overselling it :-) So to summarize the discussions that have been on-going here as well as in the PR so far, most people seem to

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

2015-10-21 Thread Danny Thorpe via bitcoin-dev
A signer modifying the order of inputs or changing outputs when "re-signing" a transaction (which already has dependent child transactions spending its outputs) seems like quite a different hazard than a malicious third party modifying a transaction in the mempool by twiddling opcodes in the

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

2015-10-21 Thread Christian Decker via bitcoin-dev
On Wed, Oct 21, 2015 at 8:19 AM Luke Dashjr wrote: > On Monday, October 19, 2015 2:01:04 PM Christian Decker via bitcoin-dev > wrote: > > The proposal is implemented (see below), by computing the normalized > > transaction ID when adding them to the UTXO and storing them along

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

2015-10-21 Thread Gregory Maxwell via bitcoin-dev
On Wed, Oct 21, 2015 at 6:18 AM, Luke Dashjr via bitcoin-dev wrote: > On Monday, October 19, 2015 2:01:04 PM Christian Decker via bitcoin-dev wrote: >> The proposal is implemented (see below), by computing the normalized >> transaction ID when adding them to

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

2015-10-21 Thread Luke Dashjr via bitcoin-dev
On Wednesday, October 21, 2015 7:39:45 AM Christian Decker wrote: > On Wed, Oct 21, 2015 at 8:19 AM Luke Dashjr wrote: > > This doesn't completely close malleability (which should be documented in > > the BIP), so I'm not sure it's worth the cost, especially if closing > >

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

2015-10-21 Thread Gregory Maxwell via bitcoin-dev
On Wed, Oct 21, 2015 at 7:48 AM, Gregory Maxwell wrote: > I'm still sad that uniform segregated witeness is so hard to deploy, > adding another id to every utxo set won't be a nice cost. :( But I > have been trying for a long time to come up with anything better and > not

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

2015-10-21 Thread Christian Decker via bitcoin-dev
On Wed, Oct 21, 2015 at 9:52 AM Luke Dashjr wrote: > On Wednesday, October 21, 2015 7:39:45 AM Christian Decker wrote: > > On Wed, Oct 21, 2015 at 8:19 AM Luke Dashjr wrote: > > > This doesn't completely close malleability (which should be documented > in > > >

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

2015-10-21 Thread Christian Decker via bitcoin-dev
Hm, that is true as long as the signer is the only signer of the transaction, otherwise he'd be invalidating the signatures of the other signers. That can however be fixed by having a canonical ordering of Inputs and Outputs, which has been discussed before in order to decrease information that

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

2015-10-20 Thread Christian Decker via bitcoin-dev
On Tue, Oct 20, 2015 at 12:23 AM s7r via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > So what exactly is used to create the normalized txid (sha256 hash of > what data)? I've read in the linked BIP draft that it will strip the > 'malleable parts' but didn't understand what

[bitcoin-dev] [BIP] Normalized transaction IDs

2015-10-19 Thread Christian Decker via bitcoin-dev
After spending some more time on the normalized transaction ID proposal and reworking it to be a soft-fork (thanks sipa for helping me figuring out how), I'd like to propose the BIP again. As with the previous version, which was using a hard-fork, the normalized transaction ID is computed only

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

2015-10-19 Thread Tier Nolan via bitcoin-dev
On Mon, Oct 19, 2015 at 3:01 PM, Christian Decker via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > As with the previous version, which was using a hard-fork, the normalized > transaction ID is computed only considering the non-malleable parts of a > transaction, i.e., stripping

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

2015-10-19 Thread Christian Decker via bitcoin-dev
Yes, this has been pointed out in the PR as well. Transactions inputs must also be normalized by replacing malleable hashes with the normalized hashes. I will fix the spec and the implementation to reflect this :-) Regards, Christian On Mon, Oct 19, 2015 at 5:24 PM Tier Nolan via bitcoin-dev <

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

2015-10-19 Thread s7r via bitcoin-dev
So what exactly is used to create the normalized txid (sha256 hash of what data)? I've read in the linked BIP draft that it will strip the 'malleable parts' but didn't understand what exactly will be used to calculate the normalized transactions ids and how will the change apply retro-active for