> 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 fo
> 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
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 tokens
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.
With
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 applicat
This is actually very useful for LN too, see relevant discussion here
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011827.html
2016-02-12 11:05 GMT+01:00 Tier Nolan via bitcoin-dev
:
> On Fri, Feb 12, 2016 at 5:02 AM, wrote:
>>
>> Seems it could be done without any new op
Prior discussion:
http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000309.html
Goal:
Greatly improve security for payment networks like the 'Lightning
Network' (LN) [1]
---
Introduction:
To improve privacy while using a payment network, it is possible to
use onion-routing t
