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
-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
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
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
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
> >
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.
>
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
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
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
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
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
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
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
> >
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
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
> > >
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
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
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
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
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 <
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
21 matches
Mail list logo