Thanks Stephen, I hadn't thought about BIP 34 and we need to address this
in both proposals. If we can avoid it I'd like not to have one transaction
hashed one way and other transactions in another way.
Since BIP 34 explicitly uses the scriptSig to make the coinbase transaction
unique, simply
On Tue, May 19, 2015 at 9:28 AM, Christian Decker
decker.christ...@gmail.com wrote:
Thanks Stephen, I hadn't thought about BIP 34 and we need to address this
in both proposals. If we can avoid it I'd like not to have one
transaction hashed one way and other transactions in another way.
The
On Tue, May 19, 2015 at 11:16 AM Tier Nolan tier.no...@gmail.com wrote:
On Tue, May 19, 2015 at 9:28 AM, Christian Decker
decker.christ...@gmail.com wrote:
Thanks Stephen, I hadn't thought about BIP 34 and we need to address this
in both proposals. If we can avoid it I'd like not to have
An option would be that the height is included in the scriptSig for all
transactions, but for non-coinbase transctions, the height used is zero.
No need to add an extra field to the transaction just to include the
height. We can just add a rule that the height specified in the scriptSig
in
Hello,
How will this exactly be safe against:
a) the malleability of the parent tx (2nd level malleability)
b) replays
If you strip just the scriptSig of the input(s), the txid(s) can still
be mutated (with higher probability before it gets confirmed).
If you strip both the scriptSig of the
On Fri, May 15, 2015 at 10:54 AM, s7r s...@sky-ip.org wrote:
Hello,
How will this exactly be safe against:
a) the malleability of the parent tx (2nd level malleability)
The signature signs everything except the signature itself. The normalized
txid doesn't include that signature, so
We should make sure to consider how BIP34 affects normalized transaction ids,
since the height of the block is included in the scriptSig ensuring that the
txid will be different. We wouldn't want to enable replay attacks in the form
of spending coinbase outputs in the same way they were spent
On Friday, May 15, 2015 9:54:55 AM s7r wrote:
If you strip both the scriptSig of the parent and the txid, nothing can
any longer be mutated but this is not safe against replays. This could
work if we were using only one scriptPubKey per tx. But this is not
enforced, ...
Assuming you mean one
Ok, I think I got the OP_CHECKAWESOMESIG proposal, transactions keep
referencing using hashes of complete transactions (including signatures),
while the OP_CHECKAWESOMESIG looks up the previous transaction (which we
already need to do anyway in order to insert the prevOut pubkeyScript),
normalizes
I think this is a good way to handle things, but as you say, it is a hard
fork.
CHECKLOCKTIMEVERIFY covers many of the use cases, but it would be nice to
fix malleability once and for all.
This has the effect of doubling the size of the UTXO database. At minimum,
there needs to be a legacy txid
I think this needs more details before it gets a BIP number; for example,
which opcodes does this affect, and how, exactly, does it affect them? Is
the merkle root in the block header computed using normalized transaction
ids or normalized ids?
I think there might actually be two or three or four
Hi All,
I'd like to propose a BIP to normalize transaction IDs in order to address
transaction malleability and facilitate higher level protocols.
The normalized transaction ID is an alias used in parallel to the current
(legacy) transaction IDs to address outputs in transactions. It is
On Wed, May 13, 2015 at 8:40 PM Pieter Wuille pieter.wui...@gmail.com
wrote:
On Wed, May 13, 2015 at 11:04 AM, Christian Decker
decker.christ...@gmail.com wrote:
If the inputs to my transaction have been long confirmed I can be
reasonably safe in assuming that the transaction hash does not
On Wed, May 13, 2015 at 1:27 PM, Tier Nolan tier.no...@gmail.com wrote:
After more thought, I think I came up with a clearer description of the
recursive version.
The simple definition is that the hash for the new signature opcode should
simply assume that the normalized txid system was used
After more thought, I think I came up with a clearer description of the
recursive version.
The simple definition is that the hash for the new signature opcode should
simply assume that the normalized txid system was used since the
beginning. All txids in the entire blockchain should be replaced
On Wed, May 13, 2015 at 11:04 AM, Christian Decker
decker.christ...@gmail.com wrote:
If the inputs to my transaction have been long confirmed I can be
reasonably safe in assuming that the transaction hash does not change
anymore. It's true that I have to be careful not to build on top of
On Wed, May 13, 2015 at 12:14 PM, Christian Decker
decker.christ...@gmail.com wrote:
On Wed, May 13, 2015 at 8:40 PM Pieter Wuille pieter.wui...@gmail.com
wrote:
On Wed, May 13, 2015 at 11:04 AM, Christian Decker
decker.christ...@gmail.com wrote:
If the inputs to my transaction have
On Wed, May 13, 2015 at 9:31 PM, Pieter Wuille pieter.wui...@gmail.com
wrote:
This was what I was suggesting all along, sorry if I wasn't clear.
That's great. So, basically the multi-level refund problem is solved by
this?
On Wed, May 13, 2015 at 4:24 PM, Christian Decker
decker.christ...@gmail.com wrote
It does and I should have mentioned it in the draft, according to my
calculations a mapping legacy ID - normalized ID is about 256 MB in size,
or at least it was at height 330'000, things might have changed a
Glad you like it, I was afraid that I missed something obvious :-)
The points the two of you raised are valid and I will address them as soon
as possible. I certainly will implement this proposal so that it becomes
more concrete, but my C++ is a bit rusty and it'll take some time, so I
wanted to
On Wed, May 13, 2015 at 1:32 PM, Tier Nolan tier.no...@gmail.com wrote:
On Wed, May 13, 2015 at 9:31 PM, Pieter Wuille pieter.wui...@gmail.com
wrote:
This was what I was suggesting all along, sorry if I wasn't clear.
That's great. So, basically the multi-level refund problem is solved by
Normalized transaction ids are only effectively non-malleable when all
inputs they refer to are also non-malleable (or you can have malleability
in 2nd level dependencies), so I do not believe it makes sense to allow
mixed usage of the txids at all. They do not provide the actual benefit of
I think this hardfork is dead-on-arrival given the ideas for OP_CHECKSIG
softforking. Instead of referring to previous transactions by a normalised
hash, it makes better sense to simply change the outpoints in the signed data
and allow nodes to hotfix dependent transactions when/if they are
If the inputs to my transaction have been long confirmed I can be
reasonably safe in assuming that the transaction hash does not change
anymore. It's true that I have to be careful not to build on top of
transactions that use legacy references to transactions that are
unconfirmed or have few
On Wed, May 13, 2015 at 6:14 PM, Pieter Wuille pieter.wui...@gmail.com
wrote:
Normalized transaction ids are only effectively non-malleable when all
inputs they refer to are also non-malleable (or you can have malleability
in 2nd level dependencies), so I do not believe it makes sense to allow
25 matches
Mail list logo
