<unnamed>

Public Key

npub1hz386xq4qszumlx5fsxa3kuxpaf8qvfrqqjg8zdl2l892hrcg55q6q5x8w

Profile Code

nprofile1qqst3gnarq2sgpwdln2ycrwcmwrq75nsxy3sqfyr3xl40nj4t3uy22qprdmhxue69uhhyetvv9ujuur0vd4k2arwdaehgu3wvdhk62mxfsj

Publishing to

relay.pocketnostr.com

Last Notes

2023-06-09 12:45:56 UTC

- reply

📅 Original date posted:2016-03-08
📝 Original message:
I'm not saying they close the channel. Alice could want to receive more
money and accept other payments, but not a particular one. But by doing
so, she would automatically disclose R for any old payment.
Am 08/03/2016 um 15:51 schrieb Nicolas Dorier:
> I'm not sure what you mean Alice don't have to disclose R if she does
> not want to.
--
Mats Jerratsch
Backend Engineer, Blockchain
e: mats at blockchain.com
PGP: https://pgp.mit.edu/pks/lookup?op=get&search=0x7F3EC6CA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160308/14ff2555/attachment-0001.sig>

2023-06-09 12:45:55 UTC

- reply

📅 Original date posted:2016-03-08
📝 Original message:
What about if Alice does not want to disclose R? Bob could have taken
too much fee and Alice does not agree to accept a payment too small.
While there is technically not really a security problem in disclosing
the R values when the payment isn't in the current commitment, the whole
idea of 'proof-of-payment'/'pay-to-contract' relies on only revealing R
for an accepted payment.
Otherwise, knowing R is no longer proof of having made a payment.
Am 08/03/2016 um 07:19 schrieb CJP:
> I was wondering: how does deriving R values from a tree structure work
> for larger Lightning networks? I guess it could work between two nodes,
> if they keep track of the same tree, but if different transactions
> follow different routes, does that mean the tree structure somehow has
> to be shared across all nodes? The alternative is that intermediate
> nodes still have to remember old R values.
>
> CJP
>
>
> Nicolas Dorier schreef op di 08-03-2016 om 13:53 [+0900]:
>> Great, indeed we had same idea, I don't see how it solve the hashes in
>> advance.
>> As Alice knows
>> H(1000000) = <random secret seed>).
>> If she need the hash to the first commitment she need to hash the random secret
>> seed 1000000 times. I think it is exactly the same problem as it is the exact
>> same idea said differently.
>>
>> On Tue, Mar 8, 2016 at 8:31 AM, Rusty Russell <rusty at rustcorp.com.au>
>> wrote:
>> Nicolas Dorier <nicolas.dorier at gmail.com> writes:
>> > One way deterministic RValue Generation
>>
>> Hi Nicolas,
>>
>> Yes, in fact shachain is a variant of this which
>> avoids
>> generating several million hashes in advance. Interesting, I
>> suggested
>> using hashing in the Deployable Lightning paper but didn't
>> actually
>> spell out the idea. Hmm....
>>
>> Seems like it orignated from Adam Back:
>>
>> https://lists.blockstream.io/pipermail/lightning-dev/2015-May/000000.html
>>
>> Cheers,
>> Rusty.
>>
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
--
Mats Jerratsch
Backend Engineer, Blockchain
e: mats at blockchain.com
PGP: https://pgp.mit.edu/pks/lookup?op=get&search=0x7F3EC6CA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160308/a8837477/attachment-0001.sig>

2023-06-09 12:45:16 UTC

- reply

📅 Original date posted:2015-11-27
📝 Original message:
Another way to deal with it is to add two HTLCs to the commit, basically
'I pay you 1.00000001 BTC and you pay me 1 BTC, so effectively I paid
you 1 satoshi'.
In reality we would of course use smaller 'transport-values'. Both of
these payments would pay to the same R value, so they would be atomic.
One issue with this is that it increases the fees by a lot, as the
locked up capital increases by quite a lot. It might also not
translate that well over many hops, when fees are different in each
direction. We might want to have some special protocol for these
payments?
By the way, as far as I know the dust value got increased to 5430? So
even more of a problem for us now... (wow, that's already 2ct, don't
think we can just disallow these, given that we promised the holy
grail of micro payments ;) )
I also don't think just adding these to the change amount is
sustainable. That's a thing I realized some time ago, as soon as there
is some loop hole somewhere, there will be one guy who will move
heaven and earth to make a profit off of it.
Cheers
Mats
2015-11-27 4:58 GMT+01:00 Rusty Russell <rusty at rustcorp.com.au>:
> Anthony Towns <aj at erisian.com.au> writes:
>> Hey,
>>
>> Suppose you have a lightning channel, with balances of exactly 2 BTC
>> on your side, and 1 BTC on the other (and 1mBTC for fees). You send a
>> micropayment of 42 satoshi across the channel, resulting in an updated
>> commitment that looks like:
>>
>> in:
>> anchor (3.001 BTC): [yoursig theirsig redeemscript]
>>
>> out:
>> 1 BTC: [pay2pubkey(theirs)]
>> 1.99999958 BTC: [pay2pubkey(yours)]
>> 0.00000042 BTC: [pay2scripthash(htlc to them with R or you after
>> timeout)]
>>
>> But the third output will hit the IsDust() test (less than 546 satoshi
>> for a min relay fee of 0.01 mBTC) and the entire transaction will be
>> rejected, so the channel can't be closed at all!
>>
>> This is a similar problem to sub 1-satoshi payments, but it's different
>> in that while you can't represent them as an HTLC output, you can
>> represent them as soon as they complete -- ie:
>>
>> out:
>> 1.00000042 BTC: [pay2pubkey(theirs)]
>> 1.99999958 BTC: [pay2pubkey(yours)]
>>
>> is completely legitimate (whereas an output of 1.0 + 0.042e-8 BTC
>> wouldn't be).
>>
>> I assume treating them much the same way is the only real option --
>> account for them exactly in the lightning state, but just approximate the
>> results in the actual commitments. So long as you're closing channels
>> infrequently, losing a few hundred satoshi here and there won't matter
>> much.
>
> Yes, unfortunately we'll have to have a rule to avoid producing those
> outputs.
>
> I've opened https://github.com/ElementsProject/lightning/issues/14
> so we make sure we track this.
>
>> Another option might be to weaken the dust protection in the network --
>> eg if you made the dust output be
>>
>> 0.00000042 BTC: [(them && (R || revoke))
>> || (you && d CSV && t CLTV)
>> || (3 months CSV)]
>>
>> then anyone could clear the dust after 3 months if it weren't otherwise
>> claimed; maybe having some dust for a finite time is okay. But it'd also
>> mean paying to an actual (non-standard) script, rather than a scripthash,
>> which would be annoying in its own way... And, really, adding that output
>> to the txn would probably cost more in additional fees that it's going
>> to pay you in any case.
>
> Agreed, we'll just cull those outputs and let them go to fees.
>
> Cheers,
> Rusty.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 12:45:02 UTC

- reply

📅 Original date posted:2015-11-19
📝 Original message:
Interesting, thanks for the write-up Anthony!
Indeed, if we can somehow prove that R1 = R2 XOR X without revealing
R1 or R2, we can switch R in between the routing an arbitrary amount
of time. This would solve the last obvious privacy attack vector that
we have currently.
I feel like the way ZKPs are constructed, one has to be absolutely
certain everything is perfectly implemented to actually work out the
way we want it.
> A drawback is that you'd either (a) have to do all this on the merchant's
> side (not just sending SHA(R) to whoever wants to pay you, but sending
> SHA(R1), SHA(R2), SHA(R3), SHA(R4), X12, X23, X34, and three proofs,
> which would be pretty painful; or (b) you'd have to generate all the
> R secrets as a consumer, and you wouldn't get to use the fact that you
> know R as evidence that you paid the merchant.
I don't think (a) would be too much of a problem. I am playing around
with the idea of having a messaging system over the same route as the
actual payment. The data that needs to be communicated over regular
channels (QR, ...) would be limited to a rendezvous node and the
encrypted route from that node to the receiver. The sender can contact
the receiver over that route and include the encrypted route back for
further communications.
I also think that - given how young SNARKs still are - efficiency will
further be improved. Especially generation and verification of the
proof, such that it is no longer a major cost factor.
---------------
After a night of sleep and some reassurance with sipa, I thought about
something similar but with EC keys, that will allow us to do the same,
but without SNARKS.
If we would switch from preimage-hash verification to
privatekey-publickey, we can use the arithmetic operations inherited
from the elliptic curve field.
Assume two keypairs, K1(Q, q) and K2(R, r). Further we have a scalar
p, such that
r = p * q
and
R = r * G = ( p * q ) * G = p * ( q * G ) = p * Q.
You can therefore give someone Q, R and p and he is able to verify
that above conditions indeed holds true. For a sufficiently large p it
is not possible to derive that relationship within reasonable time
without p. If he ever gets to know q, he is able to directly compute r
as well.
So instead of making a payment towards a hash, we make a payment
towards a public key. If we ever get to know the private key, the
payment is deemed settled.
This will allow for following construction:
(1) Bob calculates a key pair he wants to receive a payment on
(2) Bob will give the public key Q to Alice
(3) Alice calculates a route, consisting of 10 hops
(4) Alice chooses x random large numbers N_x and calculates x public
keys, such that
Q_y = Q * N_x * N_x-1 * ... * N_y.
(5) Alice constructs an onion object and includes Q_y together with N_y
Each hop is able to translate the public key towards the corresponding
key for the next relay node, only Alice, with the knowledge of the set
N is able to relate the payment though.
There is one caveat. We are currently unable to enforce a payment with
a priv/pub key pair. We would need a new operator
OP_CHECKPRIVPUBKEYPAIR or similar that pops two items from the stack
<Private Key> <Public Key>
and replaces them with true/false. It could also be constructed in a
softfork-manner, where the stack is not touched and it only fails in
case the key pair is not correct.
Revealing the private key has the same effect as revealing a preimage.
Cheers
Mats

2023-06-09 12:44:49 UTC

- reply

📅 Original date posted:2015-10-18
📝 Original message:
> It only works if you actually setup a channel, though -- so you have to
> lock some money into the channel for however many confirmations until
> the channel activates, before you can test, plus the OP_CSV delay if
> the test fails.
And there's the catch. If an attacker achieves nodes opening up
channels with him, he already succeeded in vandalism. Furthermore, an
attacker can always play by the rules and forward all payments up to
one point where he stops. And even worse, if everyone connect to his
nodes, he can relay all payments, but he is able to distinctively
identify payee and payers, even with onion routing.
> [1] Hmm, does forwarding 1 satoshi (2.6 10,000ths of a cent) make
> sense, or would the CPU cycles cost more than the fees you'd make?
> How much does it cost to forward a transaction? In python on my
> laptop, I get about 1000 ECDH operations per second in python, and
> 290k AES ops over a 3kB onion per second, and about 77k SHA256 ops
> per second. So just counting elliptic ops, forwarding a transaction
> requires three ops: an ECDH on the onion message, and an ECDSA on
> the commitment transaction to add the HTLC, and another sometime
> later to remove it. So say 1/350th of a CPU-second. My linode costs
> 3c/hour and seems to be about half as fast on the SHA256 test, but
> gives me two CPUs which evens it out. So so 3/60/60/350 cents is
> about the cost of forwarding a single transaction, which is about
> 2.4e-8 dollars, which is currently about 9.1e-11 bitcoin, which
> is 0.0091 satoshi. Conveniently lightning balances are denominated
> in millisatoshi, so as long as yours increases by 9 or 10, you're
> doing fine. 10 millisatoshi is 1% of 1 satoshi, so that seems like
> the right order of magnitude.
Interesting math, thank you for that!

2023-06-09 12:44:48 UTC

- reply

📅 Original date posted:2015-10-18
📝 Original message:
> This makes some sense (though the anchor transactions don't need to be
> P2SH, it's nicer for bitcoin's UTXO if they are).
Well, currently there is no one working on a malleability fix, so we
should probably work forwards the next available goal. ;)
>> For the current form it would be enough to have
>> SecretAHash || KeyB' || KeyB || KeyA || TxID || SignatureB (L=231B)
>> with KeyB being the node pubkey (lots of key reusage...)
>> or
>> SecretAHash || KeyB' || KeyB || KeyA || TxID || nodePubKey ||
>> SignatureB (L=264B) with KeyB as a channel key that does not need to
>> be equal with the nodePubKey.
>
> Yes, I think avoiding key reuse is good. So, to be clear, the anchor TX
> output looks like:
>
> P2SH (2 KEYA KEYB 2 OP_CHECKMULTISIG)
Having to deal with malleability, the only viable solution for anchor
transactions are with escape and fast-escape?
> I think we can do slightly better with Schnorr signatures (which you can
> simply do multisig by addition, if I understand correctly) where both
> parties cooperate to form:
>
> KEYA KEYB NODE-PUBKEYA NODE-PUBKEYB TXID DUAL-SIGNATURE
>
> That's 33+33+33+33+32+64 = 228 bytes per channel.
Interesting, I kinda feel uncomfortable with Schnorr though. It feels
like some experimental method, and at least for Java, there are very
few implementations around (and I don't feel comfortable implementing
it on my own either..)
I like the idea of adding together one object for the channel to be
sent by both nodes. Even without Schnorr it saves some bytes and the
overhead of gossipping.. We can always switch the signature to Schnorr
too..
> Also, once a node is live, I'm not sure how much of the map it will need
> to keep. It might be able to prune distant parts of the map randomly,
> and get it back from the rest of the network if needed? Requires more
> thought, though.
>
>> As I'm implementing broadcast messages anyways for other purposes (see
>> other ML post), I tent to like (2) the most, it is the most expensive
>> to attack as well I think.
>
> I agree. Least on-chain spam.
Well, all nodes can always refuse to participate in the gossip network
anyway by just never requesting data and never relaying anything
either. For a lot of things, it is very similar to the whole
blockchain. Important to keep at some points, most of it is throw-away
for individual nodes already participating in the network though.. But
I don't see this a problem anywhere soon..
Cheers,
Mats

2023-06-09 12:44:47 UTC

- reply

📅 Original date posted:2015-10-16
📝 Original message:
So being done with encryption and authentication, the next layer for
me now is to figure out how exactly nodes will broadcast their
existence and open channels and everything.
The one problem that we have currently with the way encryption and
authentication works, is that the encryption layer is not protecting
against MITM attacks, such that an attacker could have a connection
with both and establish different encryption with both and just reads
and relays all the data.
This gets defeated with the agreed-on authentication layer, where both
nodes sign a message with their real pubkey and the temp pubkey of the
party they are talking to, where a MITM could not produce these
signatures. However, this only holds true if the nodes actually know
the pubkey of the node they want to talk to. Which raises the point of
- how do we bring this information across securely? A new node joining
the network and obtaining one/some IP of another network participant
will want to get a list with nodes/pubkeys/IPs. Without a central
authority that could provide trust into the data, an attacker could
trick it into a fake network, even if just for vandalism. (Having peer
discovery trust on some hardcoded nodes to obtain IP addresses is
dangerous enough, we don't want to rely on that for pubkeys as well)
There are some possibilities how to mitigate the risk / make an attack expensive
(1)
Have a snapshot of the data hashed and linked to the blockchain.
Similar to the way 'Factom' works. It would provide the data with some
integrity framework, but keeping track of the changes would require
some overhead. Without a central service it would further be difficult
to establish who should make these linking transactions to the
blockchain...
(2)
As long as the malleability issue has not been fixed, the blockchain
can only used with additional techniques to obtain a map of the
channels from it. As the anchor transactions are P2SH, we need to
expose the script, such that others are able to verify we at least
have an anchor tx on the blockchain (associated with costs after all).
For the current form it would be enough to have
SecretAHash || KeyB' || KeyB || KeyA || TxID || SignatureB (L=231B)
with KeyB being the node pubkey (lots of key reusage...)
or
SecretAHash || KeyB' || KeyB || KeyA || TxID || nodePubKey ||
SignatureB (L=264B) with KeyB as a channel key that does not need to
be equal with the nodePubKey.
This is information everyone should store in case a new node joins a
network, similar to the blockchain. New nodes can then check against
the blockchain, whether this data is actually present there. An
attacker can fake a complete network together with lots of
transactions on the blockchain, but the incentive is low (vandalism)
and the costs are high. For 100k nodes and 10 open channels per node,
this adds up to 220MB. Not too bad, considering full nodes are highly
incentivised to run full bitcoin nodes as well, it is actually rather
negligible. This information is pretty static, however we want
everyone to have a decently consistent view of the network, so we
would probably do some rebroadcast of that every few days, just to
ensure everyone knows about it.
(3)
Similar to (2), but instead of broadcasting our script we add a
OP_RETURN output to each anchor transaction. It is cheap to implement
it, as we don't have to broadcast anything specific to this issue. It
is more expensive to attack, but also more expensive to open up a new
channel. And it doesn't help scaling either, so I tend to dislike this
idea.
(4)
Start with one node and just go through a lot of different IP
addresses you get from that node and repeat over and over and compare
what the different nodes are telling you about the system. We can
always add this technique on top of the other 3, and add IP addresses
as an additional cost vector for a successful attack. If most of the
IP addresses the first node gave you are dead, you can assume he gave
you wrong information about the network and start again with another
node.
As I'm implementing broadcast messages anyways for other purposes (see
other ML post), I tent to like (2) the most, it is the most expensive
to attack as well I think.
Mats Jerratsch

2023-06-09 12:44:38 UTC

- reply

📅 Original date posted:2015-09-22
📝 Original message:
So far my impression was that an attacker that only stops one payment
is just a nuisance, as the system can self-correct. The payer and
payee can set a timeout. If the payment has not arrived after the
timeout the payee can issue a refund back to the payer. The refund
will pay to the same secret hash as the initial payment, and it will
pay an amount that is sufficient such that the payer will receive his
initial payment completely back. (That is, he might end up paying more
refund than actual payment)
When the payer does receive the refund in his channel, he can be sure
that the payment got invalidated. The payee must not reveal the
secret, and even if he does, the funds will just circle back again.
(plus the payee will pay fees for both transactions as a disincentive)
This concept has been around already, at least I read it somewhere.
However, I recently thought about it and got a couple of unresolved
issues:
(1)
How do we resolve the complete chain to remove both, the refund and
the payment completely? Do we just wait until they timeout? This does
not seem very efficient and it would maximise the damage the attacker
would do to the network - that is, he is locking up the payment amount
for N1 nodes on the first route and N2 nodes on the refund route for
the maximum amount of time. I thought about letting the nodes resolve
this on their own, but this would need cooperation from the very node
that isn't relaying the payment in the first place.
Lets assume A wants to pay E, and it chose the route
A->B->C->D->E.
However, C is uncooperative in that he does accept the payment in the
channel he has with B, but he is not relaying it further to D. (for
whatever reason)
So we end up with
A->B->C
Now the timeout hits and E is making the refund payment
E->D->F->B->A
with the same secret hash.
A and B can resolve this, both payments are the same amount (as
described above), so the payments net-worth is zero for both parties.
Now B has a binding payment towards C for X-a bitcoin, and he receives
X+a bitcoin from F. (with some fees a)
>From the point of view of B, this is just a normal payment from F
towards C with 2a in fees. And while B can drop the payment he gets
from F (they can just update the channel and remove the payment if B
agrees), he still has a binding agreement towards the payment to C.
Without C agreeing to drop the payment as well, B isn't in the
position to drop the payment towards F, keeping up the complete chain.
(2)
How do we resolve the case, where the refund gets stuck as well? Let's
assume the same case as above, but this time F is uncooperative too.
We end up with two chains of payments, where both payees don't get the
payment:
A->B->C
E->D->F
where C and F are both uncooperative. From the point of view of A, he
has made a final payment that he cannot revoke on his own. He further
has made the payment due to some contract, to which he expects some
kind of service/good. Waiting out one day till the lightning timeout
might not be an option for A.
The same is true other way round, where E has issued the refund and is
awaiting a new payment. Both parties can not sufficiently prove to the
other party they haven't received the payment, and even if they could,
the initial payment could still route correctly after some delay while
the refund doesn't.
Thinking about it, I guess E could give out multiple refunds via other
routes, until one finally arrives at the payer. As he is obliged to
not reveal the secret anyways, these are just for resolving the issue
at hand. However, this would again maximise the damage, as all
additional refunds would need to timeout. Furthermore, a malicious
payer could just claim he never received any refund, locking up lots
of funds of the payee with very few efforts...

2023-06-09 12:44:01 UTC

- reply

📅 Original date posted:2015-08-13
📝 Original message:
Joseph asked, what changes OP_CLTV would bring to my Thunder proposal,
and I started working out, how much is actually possible with only
CLTV implemented.
It is still unclear, how CLTV and CSV are activated, and there are
discussions about adding them in one single softfork, rendering this
design useless of course. Nevertheless, maybe someone can find some
interest in it, I wasn't able to find it on the mailing list or in any
paper.
Excerpt from thunder.network:
Channel Design:
http://thunder.network/images/image09.png
http://imgur.com/nmpRYSe (Mirror)
With OP_CLTV it is possible to replace the
payout-to-multisig-and-give-timelocked-partly-signed-transaction with
a simple OP-code, specifying for how long the output should not be
spent. With this it is able to completely mitigate all the
malleability problems we have in our current solution. Let’s take a
look into some of the changes made and their implications.
Opening Transaction
There are no longer refund transactions that needs to get
interchanged. It is possible to directly make the refund to both
parties part of the opening transaction. This completely removes any
risk problems and allows for large amount of funds within the channel.
As soon as the refund time has come, both parties can get their
respective funds back with just their sole private key. As we cannot
accomplish the exact distribution with just one output and CLTV, we
use two outputs that only differ in the refund private key. By doing
so, any channel transaction has to include both these outputs (and of
course both has to be signed accordingly), leading to (slightly)
larger transactions.
Channel Transaction
Settled Funds
We use the same mechanism as in the opening transaction here, and
added a multi-sig output to ensure that these funds are revocable. If
both parties agree on a new version of the channel, they release their
temporary signatures A2 and B2. If a party broadcasts a channel that
was marked as revoked, the other party can steal those funds.
Furthermore, malleability is no longer an issue, as refunds are only
timelocked using CLTV, and in case of a revoke, the other party has
both private keys. In any case, we are no longer depending on having a
specific transaction presigned by the other party.
Sending HTLC
Making a payment now consists of 3 outputs. We combine the mechanism
for refunds and for revocable transactions (see above) with the
ability of the receiver to claim the payments in case he knows the
secret R. We lowered the refund time to the general timeframe of a
payment, such that it is enforceable by the sender. Again, as we don’t
depend on presigned transactions, malleability is no longer an issue.
Receiving HTLC
The outputs of a receiving HTLC are very similar to those of a sending
one, but with the private keys set accordingly. Also the timeframe is
down to 6 days, such that we have plenty of time to determine if a
payment will get refunded or not.
Now there are a couple of problems with this design, mainly that HTLCs
are not strictly revocable. If one party broadcasts a revoked
transactions with HTLCs inside, the other party can just try to race
against the propagation of the claiming transactions, which will often
be fruitless. This goes for receiving payments, where the party can
claim the funds with the secret R and also for sending payments, where
he can use the refund option (for revoked channels which are older
than the refund timeout). This can however completely mitigated using
a simple reserve strategy (see below for details, it can be applied
for payments in both directions).
Additionally, this new channel design means that a channel will get
closed and broadcasted completely, as soon as the refund condition for
any payment in your channel is met. To counter this as a receiver of a
payment, you have to reveal the secret or settle a new channel without
the payment (manual refund) in time with the other party. As a sender,
you have to check back the payment before the refund, to work out with
the other party if the payment should refund or settle.
Those timeframes are just for illustration, it might be preferable to
play along with those numbers a bit. For example, the one day
difference between the sender and the receiver means that in extreme
cases the sender only has one day for updating his channel.
Furthermore, there isn’t really a reason the receiver has 6 days time
to reveal his secret, where 6 hours would be plenty of time as well.
Finally, we can also extend the period for a payment, resulting in a
longer lock-up time frame at the end of the channel.
With channels being strictly no-trust, we can move towards larger
amounts of funds inside the channels, mitigating the problem with
non-revocable HTLCs and the workaround. It just becomes one additional
rule we have to apply among all the others that are apparent already.
Implementing these changes in the current Thunder implementations is
trivial. It comes down to deleting a lot of methods currently
necessary and switching to the new scripts. This goes for most channel
design changes, as the design of Rusty for example.
Appendix: Payments in older Channel Versions
There is a problem, as settlement transactions are not time-encumbered
(we want that whoever deserves the output of a payment to be able to
claim it instantly, with no one possibly interfering). This means if
one party has a channel transaction with a payments towards it, he can
claim this payment under any circumstances. However, if this party
does broadcast a revoked channel to claim such an output, the
counterparty can still steal all settled funds and all funds towards
his channel.
It is therefore important to keep track of the amounts the other party
is receiving. We have to know, which is the highest amount the other
party ever had as receiving payments in his channel, and we must make
sure that we decline any attempts of him spending money, such that his
balance would drop below this amount.
This will be more clear using this example:
We start with a channel, with Alice and Bob, and both fund the mutual
channel with 10 BTC.
So at t=0 we are at
Alice - 10 BTC
Bob - 10 BTC
Now imagine that for some reason, Alice received payments, such that
she has 5 BTC as uncleared payments in her channel.
t=t1
Alice - 10 BTC ( +5 BTC uncleared )
Bob - 5 BTC
She reveals the secrets and Alice and Bob settle those payments, leading to
t=t2
Alice - 15 BTC
Bob - 5 BTC
Now if Alice were to be free to spend all her money, if we don’t
enforce the above rules, she could spend all her money (leading to
legitimate payment contracts in other channels that we are obliged
to).
t=t3
Alice - 0 BTC
Bob - 20 BTC
But, as reasoned above, payments towards Alice can always be claimed
by Alice, such that she can claim the 5 BTC from the t=t1 channel
transaction and Bob losing those 5 BTC. The t=t1 transaction does
spend 5 BTC directly towards Bob, and he can also claim the 10 BTC
settled balance from Alice, but his net balance compared to the t=t3
is -5 BTC.
To defend against this kind of attack, it is important to keep track
of the maximum the other party has as receiving uncleared payments in
his channel. In this case, the maximum Alice has as uncleared
receiving payments is at t=t1, 5 BTC. This means, we have to make sure
her balance does not drop below 5 BTC anymore. As agreeing on a
channel with a payment is a mutual action, Bob can just refuse to
accept a new channel transaction, where the balance of Alice would
drop below 5 BTC.
This rule also serves as an incentive to clear out receiving payments
as soon as possible. The party who has sent a payment (Carol in this
example) can only remove settle the payment after the receiving party
has cleared the payment, and we don’t want the channel to clog.

2023-06-09 12:43:58 UTC

- reply

📅 Original date posted:2015-08-11
📝 Original message:
Sweet!
Do you mind if I start calling it a Lightning Network Implementation then? ;)
Also note that both these problems can be eliminated with OP_CLTV,
which will be implemented at least somewhat soon.
2015-08-11 22:33 GMT+02:00 Joseph Poon <joseph at lightning.network>:
> Ah I see, if you use a hash-based revocation, then the only primary
> attack vector left is with the Funding and HTLCs (which can be
> partially mitigated with a reserve)
>
> On 8/11/15, Mats Jerratsch <matsjj at gmail.com> wrote:
>> 2015-08-11 22:06 GMT+02:00 Joseph Poon <joseph at lightning.network>:
>>> On Tue, Aug 11, 2015 at 09:26:43PM +0200, Mats Jerratsch wrote:
>>>> > At Commitment 20, the channel state is 0 BTC to Alice and 1 to Bob.
>>>> > At commitment 31, the channel state is 1 BTC to Alice and 0 to Bob.
>>>> >
>>>> > Alice is the client and Bob is the server.
>>>> >
>>>> > Presume Alice deicdes to be a jerk! She broadcasts a mutated
>>>> > (re-signed)
>>>> > version of Commitment 20. The server is out 1 BTC! This is now a
>>>> > hostage
>>>> > negotiation.
>>>>
>>>> But the 1 BTC of Commitment 20 goes straight to Bob (and not to a
>>>> multi-sig address). Mutating a channel transaction only hurts the
>>>> party that is doing the mutation. This is why RBF is a major problem,
>>>> if it ever gets deployed.
>>>
>>> Sorry, I usually use Bob as the attacker in my examples and Alice as the
>>> client, so I got mixed up there. I meant:
>>> At Commitment 20, the channel state is 1 BTC to Alice and 0 to Bob.
>>> At commitment 31, the channel state is 0 BTC to Alice and 1 to Bob.
>>>
>>> In this case, if Alice attacks Bob she's not out any money, but Bob has
>>> funds locked up in a 2-of-2. Bob must now negotiate with Alice to get
>>> his money back. Alice will probably want some 'convenience fee'.
>>>
>>
>> But Bob has both keys of the 2-of-2 multisig. One is his (main) key,
>> and the other one was supplied by Alice as a requirement to update the
>> channel and move funds.
>> But that is what I meant with mitigate it. Even if Bob claims all
>> payments, he will lose funds due to blockchain fees. (see below)
>>
>>> You can't mitigate this by setting some reserve requirement, though. So
>>> long as Alice has more money than Bob, she can do it. If Alice is 10x
>>> richer than Bob, she doesn't *care* and she knows Bob will eventually
>>> give up. "Two-party escrow" doesn't work because one party can have more
>>> money and less time-value than another. Time-value is not a universal
>>> value.
>>
>> It is possible to say that the minimum (stealable) amount of Alice
>> must be higher than any sum of concurrent payments minus the
>> blockchain fees. This way Bob can always claim all the payments of all
>> Commitments of the Channel and still stay in positive net balance. It
>> really comes down to having an incentive to clear out payments of the
>> channel. Only open payments are problematic, settled balance can
>> always be stealed with just one transaction.
>>
>> Mats Jerratsch
>>

2023-06-09 12:43:58 UTC

- reply

📅 Original date posted:2015-08-11
📝 Original message:
2015-08-11 22:06 GMT+02:00 Joseph Poon <joseph at lightning.network>:
> On Tue, Aug 11, 2015 at 09:26:43PM +0200, Mats Jerratsch wrote:
>> > At Commitment 20, the channel state is 0 BTC to Alice and 1 to Bob.
>> > At commitment 31, the channel state is 1 BTC to Alice and 0 to Bob.
>> >
>> > Alice is the client and Bob is the server.
>> >
>> > Presume Alice deicdes to be a jerk! She broadcasts a mutated (re-signed)
>> > version of Commitment 20. The server is out 1 BTC! This is now a hostage
>> > negotiation.
>>
>> But the 1 BTC of Commitment 20 goes straight to Bob (and not to a
>> multi-sig address). Mutating a channel transaction only hurts the
>> party that is doing the mutation. This is why RBF is a major problem,
>> if it ever gets deployed.
>
> Sorry, I usually use Bob as the attacker in my examples and Alice as the
> client, so I got mixed up there. I meant:
> At Commitment 20, the channel state is 1 BTC to Alice and 0 to Bob.
> At commitment 31, the channel state is 0 BTC to Alice and 1 to Bob.
>
> In this case, if Alice attacks Bob she's not out any money, but Bob has
> funds locked up in a 2-of-2. Bob must now negotiate with Alice to get
> his money back. Alice will probably want some 'convenience fee'.
>
But Bob has both keys of the 2-of-2 multisig. One is his (main) key,
and the other one was supplied by Alice as a requirement to update the
channel and move funds.
But that is what I meant with mitigate it. Even if Bob claims all
payments, he will lose funds due to blockchain fees. (see below)
> You can't mitigate this by setting some reserve requirement, though. So
> long as Alice has more money than Bob, she can do it. If Alice is 10x
> richer than Bob, she doesn't *care* and she knows Bob will eventually
> give up. "Two-party escrow" doesn't work because one party can have more
> money and less time-value than another. Time-value is not a universal
> value.
It is possible to say that the minimum (stealable) amount of Alice
must be higher than any sum of concurrent payments minus the
blockchain fees. This way Bob can always claim all the payments of all
Commitments of the Channel and still stay in positive net balance. It
really comes down to having an incentive to clear out payments of the
channel. Only open payments are problematic, settled balance can
always be stealed with just one transaction.
Mats Jerratsch

2023-06-09 12:43:57 UTC

- reply

📅 Original date posted:2015-08-11
📝 Original message:
2015-08-11 21:16 GMT+02:00 Joseph Poon <joseph at lightning.network>:
> On Tue, Aug 11, 2015 at 08:42:50PM +0200, Mats Jerratsch wrote:
>> Can you elaborate, why you think that the client is not able to close
>> the channel? I think this is a misunderstanding on your side, which
>> most of the rest of your post argues from. While there is a slight
>> favor for the server in the channel design, there is nothing what
>> prevents the client from broadcasting (and enforcing) the channel.
>
> Ah, sorry, i'm reading it more closely now. I assumed only the server
> had a copy since that what made the most sense to me under this kind of
> asymmetric model, since it makes sense to not trust the client.
Ah I see, yes, theres a lot of additional documentation needed. When
you have your head that deep into some topic for months, you assume
everyone looks at your notes and understands everything just
perfectly.
[...]
> At Commitment 20, the channel state is 0 BTC to Alice and 1 to Bob.
> At commitment 31, the channel state is 1 BTC to Alice and 0 to Bob.
>
> Alice is the client and Bob is the server.
>
> Presume Alice deicdes to be a jerk! She broadcasts a mutated (re-signed)
> version of Commitment 20. The server is out 1 BTC! This is now a hostage
> negotiation.
But the 1 BTC of Commitment 20 goes straight to Bob (and not to a
multi-sig address). Mutating a channel transaction only hurts the
party that is doing the mutation. This is why RBF is a major problem,
if it ever gets deployed.
> Let's presume that you set up some kind of reserve requirement instead:
> At Commitment 20, the channel state is 0.05 BTC to Alice and 0.95 to Bob.
> At commitment 31, the channel state is 0.95 BTC to Alice and 0.05 to Bob.
>
> Again, Alice deicdes to be a jerk! She broadcasts a mutated (re-signed)
> version of Commitment 20. The server is out 0.95 BTC! But wait, you say,
> Alice might be out 0.05 of her own BTC. This model breaks down because
> it's still a hostage scenario! Alice tells Bob, "hey, I know I have 0.05
> BTC stuck here (and you have 0.9 stuck), but I'm rich. I don't care how
> long it takes, how about you give me a 'tax' of 0.1 BTC. You'll get your
> money back... well most of it, just sign this transaction where I get
> 0.15".
The same as above, if she resignes commitment 20, she is losing 0.05
BTC, while Bob does still get the 0.95 BTC.
There is a problem with channel histories, where Alice holds all the
funds at one point, and Bob holds all the funds at some later point,
as open payments are not as secure as those settled balances. I
mitigate this by setting a hard requirement on the spendable amount. I
will describe this in more detail soon.
Best Regards,
Mats Jerratsch
>
> --
> Joseph Poon

2023-06-09 12:43:57 UTC

- reply

📅 Original date posted:2015-08-11
📝 Original message:
Hey Joseph,
thank you very much for your invaluable feedback!
Can you elaborate, why you think that the client is not able to close
the channel? I think this is a misunderstanding on your side, which
most of the rest of your post argues from. While there is a slight
favor for the server in the channel design, there is nothing what
prevents the client from broadcasting (and enforcing) the channel.
I will of course respect your inquiry - if you really mean it after
that misunderstanding - and stop calling it a Lightning Network
implementation as long as it does not provide the complete no-trust.
I have thought a lot about RBF, and it is definitely a problem with
this implementation.
2015-08-11 20:30 GMT+02:00 Joseph Poon <joseph at lightning.network>:
> Hi Mats,
>
> Interesting work on payment channels, I think a lot of the bitcoinj code
> can be used for further development as the necessary bitcoin softforks
> for LN are incorporated. A bitcoinj implementation for lightning would
> be great!
>
> On Tue, Aug 11, 2015 at 06:12:04PM +0200, Mats Jerratsch wrote:
>> I present you a implementation for a Lightning Network Payment-Hub +
>> Client. Everything is written in Java and can be accessed on
>
> Can you do me a big favor and not call this an implementation for
> Lightning Network, though? I would prefer some name like "payment
> channel networks" or something similar, as it's materially different in
> design and trust models. In particular, if exit scams occur, I don't
> want it to be associated with Lightning Network.
>
>> I made some changes to the channel design to have everything working
>> on the current Blockchain, without the need for softforks. Due to
>> that, the network is no longer no-trust, but low-trust. This will
>> change with the upcoming new OP_CODES.
>
> Yeah, a lot of the code can definitely be used for a full LN
> implementation when the opcodes come in for sure!
>
>> The provided wallet is just a prototype, I will focus on building a
>> potent backend in the future. There are many wallets out there
>> already, it will be much more useful if those add these
>> functionalities.
>
> Some quick feedback (might have more later):
> * I don't think a dual-Commitment structure is necessary if only one
> party can close out the channel. The purpose of having two Commitments
> is so that the payout structure is different. In this case, since only
> the server can broadcast the final balance (and the client has no way
> to close out the channel), only the B Commitment is necessary).
> * HTLCs have significant malleability risks with malicious servers
> (hostage scenarios).
> * If you presume full-RBF (which I think is a game-theoretic
> eventuality), clients can pay a higher fee to mutate the server's
> broadcast of the Commitment, which will result in the server's funds
> being held up permanently until the server is willing to negotiate
> (malleability hostage scenario).
> * Exit Scamming is a distinct and likely possibility. The server can
> develop a good reputation for a while, then decide to screw over
> everyone. The server refuses to do any further transactions in any
> channel which has funds in the clients favor (current channel balance
> for the client is above what was funded). With the timeout, the server
> gets the original deposit back, which is above what they should get
> back, in other words, the server steals your money.
> * This creates an asymmetric playing field. If one cannot be confident
> they will receive their funds back, this is similar to depositing your
> money on a hosted wallet such as Coinbase or whatever. The primary
> value of transacting on bitcoin is that the social costs of
> counterparty risks are minimized -- and counterparty risk is one of
> the primary inputs on interest rates (remove trust -> remove
> counterparty risk -> remove fees/interest). This can only exist if
> you're sufficiently willing to transact with nearly anyone (minimal
> underwriting).
>
>> Furthermore, as there are less everyday payments on the blockchain,
>> there is more space for important transactions of higher value.
>
> I agree that this is one of the primary values of payment channel based
> systems. To extend and take your point in a different direction, there
> is a risk if everyone uses blockchain transactions for every day
> purchases, that high-value transactions will crowd out low-value
> transactions. There is a tension that exists between the need for
> sufficiently high fees to pay miners (when the block rewards decline)
> and allowing low-fee transactions to be on-chain in a timely manner.
>
> --
> Joseph Poon

2023-06-09 12:43:56 UTC

- reply

📅 Original date posted:2015-08-11
📝 Original message:
Good Day everybody
I present you a implementation for a Lightning Network Payment-Hub +
Client. Everything is written in Java and can be accessed on
http://thunder.network
https://github.com/matsjj/thundernetwork
I made some changes to the channel design to have everything working
on the current Blockchain, without the need for softforks. Due to
that, the network is no longer no-trust, but low-trust. This will
change with the upcoming new OP_CODES.
The provided wallet is just a prototype, I will focus on building a
potent backend in the future. There are many wallets out there
already, it will be much more useful if those add these
functionalities.
Using such a payment network will help to greatly release the pressure
in the blocksize-debate. Furthermore, as there are less everyday
payments on the blockchain, there is more space for important
transactions of higher value.
I'm sure there is a lot I'm missing to explain. I'm also around in
most IRC-Channels ( mjerr ).

2023-06-07 18:07:37 UTC

- reply

📅 Original date posted:2017-11-13
📝 Original message:> 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 know of break old txs on one of the chains, even when that's not desirable - ie, they offer no wildcard like nForkId 0.
Exactly!
> One comment on your LN example: users would have to take note that nForkId 0 txs would be valid not only on future forks, but on past forks too. Eg, if BCH had been deployed with nForkId 2, then a user setting up BTC LN txs now with nForkId 0 would have to be aware that those txs would be valid for BCH too. Of course the user could avoid this by funding from a BTC-only address, but it is a potential minor pitfall of nForkId 0. (Which I don't see any clean way around.)
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 transaction in a loose sense).
Now you want to protect the funding transaction, as otherwise you would be subject to a replay-attack on all *past* forks. So you will set `nForkId>=1` for the funding transaction, making this payment channel non-existent on any *past* forks. However, if during the lifetime of the payment channel another fork happens, the payment channel exists for both tokens. So for the commitment transaction, you will have `nForkId=0`, making it valid on both of these chains. While this `nForkId` is valid on all chains, the parent transaction it tries to spend (the funding transaction) does only exist on two chains, the original one you created the channel for and the one that forked away.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171113/6fca842c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171113/6fca842c/attachment.sig>

2023-06-07 18:07:36 UTC

- reply

📅 Original date posted:2017-11-10
📝 Original message: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.
In theory `nForkId=0` could be used for an address too, the sending wallet should display a warning message about unknown side effects though. This address would be future-safe, and you can put it into a safe-deposit box (even though I see little reason to back up an _address_. You would always back up a _private key_, which translates into funds on any fork.)
Furthermore, `nForkId=0` can be used for L2 applications. Let's say Alice and Bob open a payment channel. One week later, project X decides to fork the network into a new token, implementing a custom way of providing strong two-way replay protection. The protocol Alice and Bob use for the payment channel has not implemented this new form of replay protection. Alice and Bob now have to make a choice:
(1) Ignore this new token. This comes with an evaluation of how much this new token could be worth in the future. They will continue normal channel operation, knowing that their funds on the other branch will be locked up until eternity. When they close their payment channel, the closing transaction will get rejected from the other network, because it's not following the format for replay protected transactions.
(2) Close the payment channel before the fork. The transaction, which closes the payment channel has to be mined before the fork, potentially paying a higher-than-normal fee.
With this proposal implemented, there are two additional choices
(3) Create the commitment transactions with `nForkId=0`. This ensures that when the channel gets closed, funds on other chains are released accordingly. This also means that after the fork, payments on the channel move both, the original token and the new token. Potentially, Alice and Bob want to wait before further transacting on the channel, to see if the token has substantial value. If it has, they can *then* close the channel and open a new channel again. (Note: The funding transaction can use a specific `nForkId`, preventing you from locking up multiple coins when funding the channel, but you can choose to settle with `nForkId=0` to not lock up future coins)
(4) Make the protocol aware of different `nForkId`. After the fork, the participants can chose to *only* close the payment channel on the new token, making the payment channel Bitcoin-only again. This is the preferred option, as it means no disruption to the original network.
> I like the idea of specifying the fork in bech32 [0]. On the other hand, the standard already has a human readable part. Perhaps the human readable part can be used as the fork id?
I was considering this too. On the other hand, it's only _human readable_ because thy bytes used currently encode 'bc'. For future forks, this would just be two random letters than, but potentially acceptable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171110/ada18c4a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171110/ada18c4a/attachment-0001.sig>

2023-06-07 18:07:35 UTC

- reply

📅 Original date posted:2017-11-08
📝 Original message: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 this proposal implemented, a 'mis-send' is fundamentally impossible. The address contains the identifier of the token that should be sent.
If anything, it's possible to 'mis-receive'.
That is, the receiving wallet was not aware of a newer chain, and the receiver actually wanted to receive the newer token, but instead his wallet created an address for the old token. It is the responsibility of the receiver to write a correct invoice. This is the case everywhere else in the world too, so this seems like a reasonable trade-off.
I would even argue that this should hold in a legal case, where the receiver cannot claim that he was expecting a payment in another token (contrary to how it is today, like when users send BTC to a BCH address, losing their funds with potentially no legal right for reimbursement). If I sent someone an invoice over 100€, I cannot later proclaim that I actually expected $100.
With this proposal, wallets are finally able to distinguish between different tokens. With this ability, I expect to see different implementations, some wallets which advertise staying conservative, following a strict ruleset, and other wallets being more experimental, following hashing rate or other metrics.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171108/eef251dc/attachment.sig>

2023-06-07 18:07:34 UTC

- reply

📅 Original date posted:2017-11-05
📝 Original message: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 applications).
## Rationale
Currently when a hard fork happens, there is ad-hoc replay protection built within days with little review at best, or no replay protection at all. Often this is either resource problem, where not enough time and developers are available to sufficiently address replay protection, or the idea that not breaking compatibility is favourable. Furthermore, this is potentially a recurring problem with no generally accepted solution yet. Services that want to deal in multiple forks are expected to closely follow all projects. Since there is no standard, the solutions differ for each project, requiring custom code for every fork. By integrating replay protection into the protocol, we advocate the notion of non-hostile forks.
Users are protected against accidentally sending coins on the wrong chain through the introduction of a fork-specific incompatible address space. The coin/token type is encoded in the address itself, removing some of the importance around the question _What is Bitcoin?_. By giving someone an address, it is explicitly stated _I will only honour a payment of token X_, enforcing the idea of validating the payment under the rules chosen by the payee.
## Iterative Forks
In this schema, any hard fork is given an incremented id, `nForkId`. `nForkId` starts at `1`, with `0` being reserved as a wildcard. When project X decides to make an incompatible change to the protocol, it will get assigned a new unique `nForkId` for this fork. A similar approach like for BIP43 can be taken here. Potentially `nForkId` can be reused if a project has not gained any amount of traction.
When preparing the transaction for signing or validation, `nForkId` is appended to the final template as a 4B integer (similar to [1]). Amending BIP143, this would result in
```
Double SHA256 of the serialization of:
1. nVersion of the transaction (4-byte little endian)
2. hashPrevouts (32-byte hash)
3. hashSequence (32-byte hash)
4. outpoint (32-byte hash + 4-byte little endian)
5. scriptCode of the input (serialized as scripts inside CTxOuts)
6. value of the output spent by this input (8-byte little endian)
7. nSequence of the input (4-byte little endian)
8. hashOutputs (32-byte hash)
9. nLocktime of the transaction (4-byte little endian)
10. sighash type of the signature (4-byte little endian)
11. nForkId (4-byte little endian)
```
For `nForkId=0` this step is ommitted. This will immediately invalidate signatures for any other branch of the blockchain than this specific fork. To distinguish between `nForkId=0` and `nForkId` hardcoded into the software, another bit has to be set in the 1B SigHashId present at the end of signatures.
To make this approach more generic, payment addresses will contain the fork id, depending on which tokens a payee expects payments in. This would require a change on bech32 addresses, maybe to use a similar format used in lightning-rfc [2]. A wallet will parse the address, it will extract `nForkId`, and it displays which token the user is about to spend. When signing the transaction, it will use `nForkId`, such that the transaction is only valid for this specific token. This can be generalised in software to the point where replay protection *and* a new address space can be introduced for forks without breaking existing clients.
For light clients, this can be extended by enforcing the coinbase/block header to contain the `nForkId` of the block. Then the client can distinguish between different chains and tokens it received on each. Alternatively, a new P2P message type for sending transactions could be introduced, where prevOut and `nForkId` is transmitted, such that the lite client can check for himself, which token he received.
Allowing signatures with `nForkId=1` can be achieved with a soft fork by incrementing the script version of SegWit, making this a fully backwards compatible change.
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013542.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013542.html>
[2]
https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md <https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171105/41f5276f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171105/41f5276f/attachment.sig>