>
> 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 scriptS
On Tue, May 19, 2015 at 11:16 AM Tier Nolan 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 one
>> transac
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.
>
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 remo
On Sat, May 16, 2015 at 4:58 AM, Stephen
wrote:
> 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 spend
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 fr
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 o
On Fri, May 15, 2015 at 10:54 AM, s7r 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 mutations of the
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 pare
Sorry about that, sometimes I hate keyboard shortcuts :-)
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 anyw
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
On Wed, May 13, 2015 at 1:32 PM, Tier Nolan wrote:
>
> On Wed, May 13, 2015 at 9:31 PM, Pieter Wuille
> 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?
>
Yes. So to be clear,
On Wed, May 13, 2015 at 9:31 PM, Pieter Wuille
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?
--
One dashbo
On Wed, May 13, 2015 at 1:27 PM, Tier Nolan 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 since the
> beg
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 w
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
> 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
On Wed, May 13, 2015 at 8:40 PM Pieter Wuille
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 change
>> anymo
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 6:14 PM, Pieter Wuille
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
> mixed usage of the
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 confir
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
guarant
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 mall
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 change
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 g
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
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
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
calculate
27 matches
Mail list logo
