>
> Sorry, I was careless with the use of `>=` there. You are correct, forks
> form a tree. For this proposal, every leaf must be assigned a unique
> `nForkId`. The relationship between `nForkId` is irrelevant (e.g. which
> number is bigger), as long as they are unique. Transactions are only valid
Totally agree something like this required..
I've been burned.
But I like the 'old' idea of putting the hash of a block that MUST be on
the chain that this txn can eventually be added to. If the hash is not a
valid block on the chain, the txn can't be added.
It means you can choose exactly
> But I like the 'old' idea of putting the hash of a block that MUST be on the
> chain that this txn can eventually be added to. If the hash is not a valid
> block on the chain, the txn can't be added.
>
> It means you can choose exactly which forks you want to allow your txn on,
> pre-fork
>
> This is actually incorrect. There are two transactions involved in LN. The
> funding transaction, which opens a payment channel, and a commitment
> transaction, which closes the channel when broadcasted to the network (the
> cooperative closing transaction can be considered a commitment
> OK, so nForkId 0 is exactly the "valid on all chains" specifier I was asking
> about, cool. And your LN example (and nLockTime txs in general) illustrate
> why it's preferable to implement a generic replay protection scheme like
> yours in advance, rather than before each fork: all ad hoc
OK, so nForkId 0 is exactly the "valid on all chains" specifier I was
asking about, cool. And your LN example (and nLockTime txs in general)
illustrate why it's preferable to implement a generic replay protection
scheme like yours *in advance*, rather than before each fork: all ad hoc RP
schemes
I guess I wasn't clear on the wildcard, `nForkId=0`
This proposal puts Bitcoin at `nForkId=1`, with the purpose of having
`nForkId=0` valid on *all* future forks. This means you can create a
`nLockTime` transaction, delete the private key and still be assured to not
lose potential future
Hey Jacob!
> Take the specific and common case of non-upgraded wallet software. Suppose a
> HF happens, and becomes the network used by 90% of users. Will old wallets
> still default to the old nForkId (10% legacy chain)? If so, I'd expect a lot
> of accidental mis-sends on that chain.
Thanks Mats, this proposal makes sense to me (especially the idea of
fork-specific addresses). It prevents replay across forks, and makes it
easy for client software, and thus potentially users, to specify which fork
a tx is for. But, like other (rougher) past proposals I've seen, it does
little
Presented is a generalised way of providing replay protection for future hard
forks. On top of replay protection, this schema also allows for fork-distinct
addresses and potentially a way to opt-out of replay protection of any fork,
where deemed necessary (can be beneficial for some L2
10 matches
Mail list logo
