Re: [bitcoin-dev] Generalised Replay Protection for Future Hard Forks

> 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

Re: [bitcoin-dev] Generalised Replay Protection for Future Hard Forks

> 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

Re: [bitcoin-dev] Generalised Replay Protection for Future Hard Forks

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

Re: [bitcoin-dev] Generalised Replay Protection for Future Hard Forks

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.

[bitcoin-dev] Generalised Replay Protection for Future Hard Forks

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

Re: [bitcoin-dev] BIP CPRKV: Check private key verify

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,

[bitcoin-dev] [BIP] OP_CHECKPRIVPUBPAIR

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