Mats Jerratsch [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-07-20 to 2017-11-14
💬 Posted a total of 48 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev, PATCH v3
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1hz386xq4qszumlx5fsxa3kuxpaf8qvfrqqjg8zdl2l892hrcg55q6q5x8w

Profile Code

nprofile1qqst3gnarq2sgpwdln2ycrwcmwrq75nsxy3sqfyr3xl40nj4t3uy22q5x8zem

Author Public Key

npub1hz386xq4qszumlx5fsxa3kuxpaf8qvfrqqjg8zdl2l892hrcg55q6q5x8w

Show more details

Last Notes

2023-06-09 12:46:19

- reply

📅 Original date posted:2016-05-30
📝 Original message:
Thats a cool idea! Instead of directed 1-to-1 payment channels, it would rather look like a cloud with multiple parties connected.
Apart from the (*huge*) added complexity and engineering work to make that happen, I see another problem with it though.
In case a participant cheats and broadcasts an old channel transaction - how do you determine the correct payout to the other participants?
Say there are 5 parties, each contributing 1 BTC.
Now after numerous payments, we end up in a state where Alice gets 4 BTC and B-E get 0.25 each. If one of the party now broadcasts an old transaction which held the initial state, how could you possibly make the blockchain cognitive to the correct payout? And what would be a correct payout to begin with?
Is it:
A: 4.0625
B: 0.3125
C: 0.3125
D: 0.3125
E: nothing (cheated)
so splitting up the balance of the cheating party equally, or is it more correct to split it proportionally?
The only way how I see this working right now is returning back to the schema of decreasing nLocktime with each update. It would make broadcasting old states impossible, as the current state has a lower nLocktime. It also means returning to very limited lifetime per channel though (you talked about timeout, is that what you meant?). With so many parties involved, it would lead to drastically increased on-chain activity (or very high refund timeouts where you can’t access your money).
It seems like you have it all thought out already, can you go into a bit more detail on your proposal? :)
I’m also interested in how exactly you would make it work, with only needing the spending party to resign the transaction. (which I cannot think of how to work out combined with the nLocktime-approach)
Cheers!
Mats
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160530/f8dd3cc6/attachment.sig>

2023-06-09 12:46:18

- reply

📅 Original date posted:2016-05-30
📝 Original message:
>> A basic schema with one included payment can be seen here:
>>
>> https://raw.githubusercontent.com/blockchain/thunder/master/docs/dual-tx-diagram.png
>>
>> The idea is that each payment and each refund does not directly pay to their respective owner, but to a intermediate 2-of-2 transaction. For redeeming a payment, one has to also use R to broadcast Redeem-TX, for broadcasting Refund-TX one has to wait the agreed refund time. Having broadcasted the additional transaction, one basically *secured* the funds, under the premise that one has not cheated by using an old commitment transaction. If he did cheated though, the other party can claim all funds directly from the commitment outputs or from the Redeem-TX outputs.
>>
>> This makes it possible to set revocation delay and payment timeouts to completely separate values (if it is not obvious why this was not possible before, I suggest reading the thread linked above).
>>
>> Now there are two downsides to this approach:
>>
>> (1) Clearing a payment on the blockchain is more expensive. Because we have an additional transaction for each payment, fees for redeeming the payment are higher. One has to take into account the fee for the additional transaction when producing the outputs for the commitment transaction. However, as most channels will not get settled on the blockchain anyways, this is a minor issue.
>>
>> (2) Updating the commitment transaction, one has produce and send a new signature for each currently included payment. For channels that have lots of uncleared payments for a long time this might be problematic, however, uncleared payments are undesirable for many reasons and adding disincentives for delaying the clearing process is on the TODO anyways.
>>
>> However, having a clean solution to the problem of high refund times (>30d) and low revocation times (<3d) is more important in the long run.
>
> At first I wasn't sure that anyone would really set 30 day CSV delays.
> I'm not sure that I want my funds locked for 30 days, or even to deal
> with a node which indicates it's likely to be offline for anything like
> that long.
>
> But I'm wrong. If you're just an occasional end-user, this might make
> perfect sense to ask for a 30 day timeout as an alternative to
> outsourcing enforcement. And since it's a private arrangement between
> two nodes, it could easily be added as an option.
>
> The main downside I see is the slight additional complexity for the
> on-chain case, so I really like the idea of making it an option.
Yes exactly, this high of a revocation timeout is not for 24/7 nodes, but rather to ease problems for endusers when adopting to this new way of transacting.
Keep in mind though that only the revocation value is a private arrangement.
The dual-tx approach is backward compatible, meaning it is possible relaying payments with the old setup, with the cost of using long refund times. It is not possible to relay a payment that is optimised for dual-tx over hops that don’t support it, because they would deduct their usual refund-time (often between 1-2 days per hop), leaving no room for the rest of the route.
Yes when having multiple payments with different timeouts one has to keep track of when to broadcast which transaction, but this is similar to the current approach. It does make it significantly harder to transact sub-dust amounts though. For a 1 satoshi payments one would often pay >500 satoshi for claiming it on-chain.
What we can do, however, is to use the old schema for these low-amount payments, given that a long clearance time isn’t that much of a problem for these either way.
Cheers
Mats
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160530/188f3b8d/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 using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160530/188f3b8d/attachment.sig>

2023-06-09 12:46:17

- reply

📅 Original date posted:2016-05-17
📝 Original message:
Hey everybody,
Using SegWit, I thought of a more elegant way to solve the coupling problem between revocation delay and payment timeouts. ( https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000339.html and following)
A basic schema with one included payment can be seen here:
https://raw.githubusercontent.com/blockchain/thunder/master/docs/dual-tx-diagram.png
The idea is that each payment and each refund does not directly pay to their respective owner, but to a intermediate 2-of-2 transaction. For redeeming a payment, one has to also use R to broadcast Redeem-TX, for broadcasting Refund-TX one has to wait the agreed refund time. Having broadcasted the additional transaction, one basically *secured* the funds, under the premise that one has not cheated by using an old commitment transaction. If he did cheated though, the other party can claim all funds directly from the commitment outputs or from the Redeem-TX outputs.
This makes it possible to set revocation delay and payment timeouts to completely separate values (if it is not obvious why this was not possible before, I suggest reading the thread linked above).
Now there are two downsides to this approach:
(1) Clearing a payment on the blockchain is more expensive. Because we have an additional transaction for each payment, fees for redeeming the payment are higher. One has to take into account the fee for the additional transaction when producing the outputs for the commitment transaction. However, as most channels will not get settled on the blockchain anyways, this is a minor issue.
(2) Updating the commitment transaction, one has produce and send a new signature for each currently included payment. For channels that have lots of uncleared payments for a long time this might be problematic, however, uncleared payments are undesirable for many reasons and adding disincentives for delaying the clearing process is on the TODO anyways.
However, having a clean solution to the problem of high refund times (>30d) and low revocation times (<3d) is more important in the long run.
This means adding a few more fields to the way a new commitment status is negotiated, you can see the full exchange thunder is using here:
https://github.com/matsjj/lightning/blob/master/communications/high/%5BTN%5DPaymentNegotiation.md
—————————————————————————————
Also, following the tradition of the other releases here on the mailing list I like to bring it over here more formally.
thunder.network is a full lightning network implementation, based on my ongoing development for the past 15 months. The software is now at a point where it can be actively used and also integrated into other projects. If you have not tried the wallet out and made a basic payment, feel invited to start up two instances and try it out.
The implementation already uses CSV and will utilize SegWit (in progress). It’s a small change, about 250 LoC[1]. The intention is to build as trustless a system as possible. SegWit was not prioritized any higher than it is since it will be awhile before it can be utilized for any mainnet system.
This release contains two executables, a node and a wallet, and they both use the same library.
The node is a passive participant of the network. On startup the user can specify which nodes to build payment channels with. It will broadcast its existence into the network, such that other peers can also build payment channels with it. If you do want to start up the node, make sure you forwarded port 2204, such that you can receive incoming connections.
The wallet is the counterpart, an active participants. The wallet is used to make and receive payments, but it will not broadcast its existence. Once we have RP routing sorted out, it will not broadcast anything anymore (for routing it still broadcasts any payment channel it has). It also provides some GUI as an example and for easier usage.
By default wallet and nodes do not communicate with the bitcoin network yet, as this makes it easier to debug and to try out. If you want to use testcoins, toggle the setting in Constants. Also, if you do want to see which messages are sent under the hood, toggle EncryptionProcessorImpl.OUTPUT_MESSAGE.
Both, Node and Wallet software can be downloaded at
https://github.com/blockchain/thundernetwork/releases
Further information can be found at
https://github.com/blockchain/thundernetwork
https://blockchain.com/thunder
Cheers!
[1]
https://github.com/blockchain/thunder/commit/e9132c9f30719f430385e88cc1c04d7611b5dfd0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160517/d9d64c5a/attachment.html>

2023-06-09 12:46:02

- reply

📅 Original date posted:2016-03-21
📝 Original message:
> I think the layout is a bit too nested (which makes sense coming from
> the Java implementor, I guess? :) and I think it'd be good to have a
> simple way to decide how to move ideas into/through the repo, without
> making it a place where there's any point trying to politicise proposals.
> (It's kind of telling that something's wrong when even matsjj hasn't
> been able to get his pull requests accepted :)
Hehe I was waiting for you guys to merge those, as I don’t consider this ‘my repository’ but rather the specification of the protocol eventually.
I do agree that the format isn’t perfect yet. I still like these nested packages, because it separates the different parts of the application (and I don’t see why plain numbers are any better than an actual structure? ;) ).
When I started the repository, my goal was to
(1) bring together all the different implementations
(2) agree on a common denominator.
We have to finish (1) first before we actually can concentrate on (2) though.
I suppose it makes sense to have the different parts of the application and have the different implementations side-by-side within that package. Then we can decide how we compose the ‘final’ specifications of that part.
While we still work on the very 1.0 specifications, isn’t it favourable to stick to named proposals, instead of throwing around with numbers? (even though I like the “BOLT” names…)
Cheers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160321/8ef66b64/attachment.sig>

2023-06-09 12:45:56

- 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:56

- reply

📅 Original date posted:2016-03-08
📝 Original message:
Hah I see, I didn't knew you weren't talking about HTLCs.
But why would you use R values in the first place then? Maybe I'm a
little bit confused about what exact use case we are talking here, mind
elaborating? :)
Am 08/03/2016 um 16:14 schrieb Nicolas Dorier:
> I don't understand your point, but that may come from me not having
> deep enough knowledge about the latest great things happening on
> Lightning.
>
> I exposed the case of a simple bipayment channel, without HTLC in the
> equation, where all payments are sequential.
>
> You can't make commitment n+2 before accepting commitment n+1.
>
> My mental model might be incomplete as I'm followed only remotely
> the improvements of lightning until now.
>
> On Wed, Mar 9, 2016 at 12:53 AM, Mats Jerratsch <mats at blockchain.com
> <mailto:mats at blockchain.com>> wrote:
>
> 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 <mailto:mats at blockchain.com>
> PGP: https://pgp.mit.edu/pks/lookup?op=get&search=0x7F3EC6CA
>
>
--
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/1a07bd25/attachment-0001.sig>

2023-06-09 12:45:55

- 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:49

- reply

📅 Original date posted:2016-03-21
📝 Original message:
> OK, let me get the proposal straight:
>
> 1. Each node will publish its MIN_TIMEOUT (along
> with its other info as per Option 2 in
> http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-October/000262.html )
>
> 2. The payer sums the MIN_TIMEOUT to the payee, adds some random value
> (keeping it under the max value allowed by protocol) to give the
> initial HTLC timeout.
>
> 3. The payer puts the 'expected_timeout' in each layer of the onion, by
> subtracting the last hops' MIN_TIMEOUT from the initial timeout.
>
> eg. Say maximum allowed timeout is 20 * 12 hours, and route is:
>
> A (12 hours) -> B (6 hours) -> C (6 hours) -> D (4 hours)
>
> Initial timeout has to be at least 12 + 6 + 6 + 4 == 28 hours, plus
> some padding for transmission delays, say 29 hours.
I take a multiply of the MIN_TIMEOUT, a factor around 2, but yes, that sounds about right
>
> It picks a random timeout between 29 and 240 hours, say now+100 hours,
> and onion looks like:
>
> [ A: now+100 [ B: now+88 [ C: now+82 [ D: now+76 ] ] ] ]
I would not use the MIN_TIMEOUT here, but use it as the minimum time I deduct each hop and add some randomness into it.
It also means that you need two values in the onion object:
(1) the value you expect to receive
(2) the value you should use for the next hop (and therefore the (1) value of the next hop))
So somewhere along this:
[ A: now+100;now+80 [ B: now+80;now+65 [ C: now+65;now+54 [ D: now+54;now+40 ] ] ] ]
which can obviously be saved in a less redundant way
Cheers
Mats
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160321/e28421a3/attachment.sig>

2023-06-09 12:45:48

- reply

📅 Original date posted:2016-03-09
📝 Original message:
> If A sends many HTLCs through B, B can simply plot what the timeouts
> are and know that A is likely originating the HTLCs rather than relaying
> them for someone else.
Hm, right. If all payments that come from A have a timeout larger than
some minimum value X, he is generating all of them and is just trying to
randomize those. However, if he creates a payment with an initial refund
value lower than X, the payment might not succeed, because the
intermediate nodes deducted too much.
However, if we take into account that the amount of nodes in the route
is not a constant, and only known to the sender, this adds another
degree of freedom to choose the initial value.
>> However, I am inclined to use those timestamps in the onion object, as
>> the described attackvector still exists.
>
> Doesn't including timestamps in the onion provide explicit information
> on the number of previous hops though?
Not if they are randomized. The initial sender will choose a good
starting value (see above), and deduct MIN_TIMEOUT * MIN_OVERLAY *
RANDOM from it. Actually it doesn't provide any additional data, as that
is the very same mechanism the intermediate hops come to that value.
--
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/20160309/d067aae0/attachment.sig>

2023-06-09 12:45:48

- reply

📅 Original date posted:2016-03-08
📝 Original message:
Only mitigates it such that you can't do for free, and it adds some
complexity and we might barricade some future feature with it (like
having multiple payments to one R value, over the same route).
For now I start with
MAX_HOPS * MAX_OVERLAY * MIN_TIMEOUT
where MAX_OVERLAY is some 'consensus' value of how much buffer time each
node should deduct from the refund time at most. That way each node can
use the full range to randomize the refund time, without running out of
time in the end. I do not see how a pattern should emerge from that though.
However, I am inclined to use those timestamps in the onion object, as
the described attackvector still exists.
Cheers
Am 05/03/2016 um 09:28 schrieb Rusty Russell:
> Mats Jerratsch via Lightning-dev
> <lightning-dev at lists.linuxfoundation.org> writes:
>> Just discovered that it is possible to attack the onion routing with
>> probing too short of an absolute CLTV refund timeout.
>>
>> When accepting a payment, one will check if the remaining timeout >
>> MIN_TIMEOUT.
>
> One mitigation for this particular attack would be to remember the onion
> and always fail an identical one. That would allow a single probe,
> however (basically, "are you the final destination?").
>
> Also the timeout for the next hop should probably be somewhat
> randomized, at least subtracting (MIN_TIMEOUT to MIN_TIMEOUT*2).
>
> The question remains as to what HTLC timeout should be set to initially.
> Even if you randomize it, over time the pattern would reveal to your
> peer if you are originating all the HTLCS, for example.
>
> Cheers,
> Rusty.
>
--
Mats Jerratsch
Backend Engineer, Blockchain
e: mats at blockchain.com
PGP: https://pgp.mit.edu/pks/lookup?op=get&search=0x7F3EC6CA

2023-06-09 12:45:47

- reply

📅 Original date posted:2016-03-02
📝 Original message:
Just discovered that it is possible to attack the onion routing with
probing too short of an absolute CLTV refund timeout.
When accepting a payment, one will check if the remaining timeout >
MIN_TIMEOUT.
When relaying the payment to the next node, one can either decide to
check directly if the next node would accept it, or just relay and see
what happens (the next node would then refuse to include the payment).
Checking directly is equivalent of checking for 2 * MIN_TIMEOUT before
accepting it. However, as the next node will check for 2 * MIN_TIMEOUT
again, this is running in circles and just blindly increasing the final
MIN_TIMEOUT.
For an attacker it is now possible to choose a timeout that is lower
than 2 * MIN_TIMEOUT. If the payment succeeds, he knows that the next
node was the final receiver, if it doesn't he can redo the payment with
a larger timeout without any drawback, basically probing all payments once.
As discussed above, testing for a larger timeout before accepting /
relaying does not solve this problem. If all nodes only accept payments
with timeout > 10 * MIN_TIMEOUT, you can still probe with 10.5 *
MIN_TIMEOUT.
I think the only way to solve this would be to include
(1) the timeout the previous node should have sent you
(2) the timeout you should use for the next node
into the onion object and test it accordingly.
If you discover that the previous node messed with the timeout, you
directly refund it. It further complicates routing though, as the source
of the payment needs to know all MIN_TIMEOUT of the nodes in the route.
It also needs more coordination when doing RP-routing, as the receiver
has to include the timeout he chose for the first hop of his route.
It probably also opens up another attack vector for attacking the
network with unroutable payments.
Cheers
--
Mats Jerratsch
Backend Engineer, Blockchain
e: mats.jerratsch 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/20160302/06cb6a52/attachment.sig>

2023-06-09 12:45:33

- reply

📅 Original date posted:2016-01-27
📝 Original message:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Great point Rusty, given how many implementations are emerging, we
should press more for compatibility.
Before making comments, just a quick reminder that everyone is invited
in cloning
https://github.com/lightning-core/lightning
and writing up their specifications so others do not have to search
through code, plus separating code from design is good practice. It
will also be easier to commit to them once the discussion is done.
> For this email I'll simply list the changes or proposals I'm aware
> of, then we can dissect and comment on each one: defer, accept or
> close.
I am so free and add changes from TN :)
>
> Direct wire format stuff ------------------------
>
> - Protobufs vs open-coded structures - lnd open-coded their own
> protocol; I haven't finished reading their code though. - protobufs
> are easy to extend with new fields; with an open-coded proto we
> simply need a rule that too-long packets are valid. - protobufs are
> annoying for fixed-length blobs which we use a lot (keys,
> signatures, hashes). - The protocol is currently simple with very
> few variable-length
fields.
- - TN currently is using JSON encoded objects. It is by no standard
efficient, but allows for easy integration of other systems and
it's easy to extend/modify.
Right now I think the open-coded messaging is a bit too much. You
don't get the efficiency of protobufs, nor the readibility of JSON,
but still have to manually code each serialisation/deserialisation,
and each change to the messages has to be carefully inserted into
these functions.
I still don't think JSON is a bad choice for the beginning. If it
actually turns out to be a bottleneck it is a very low-hanging fruit.
I would rather adapt something like protobufs if it comes to it. (I
heard there are other *bufs, maybe some of these serve us better?)
> - Length prefix for initial key exchange - Both lnd and c-lightning
> begin by exchanging a 33-byte EC key
for DH.
> - We should prefix with a length word, so we can extend this later
> (eg. for new crypto)
Agree, same on TN.
Won't new crypto be non-compatibily anyways?
> - Length prefix for other packets - lightning-c sends an 8 byte
> prefix indicating the offset of the
end of
> the current packet: this effectively encodes both length and
ordering.
> - lnd uses a 4 byte network ID, 4 byte type, 4 byte length.
- - TN uses 4 byte length, type is JSON encoded (message types are
completely taken care of of GSON)
I agree that a network ID prefix might make sense. Probably worth
designing for an equivalent of testnet (and they should not just
differ by the standard port they run on... )
>
> - HTLC pipelining - lnd's protocol supports multiple in-flight HTLC
> negotiations; this would allow much greater throughput, with some
> complexity. - lightning-c uses a simple one-at-a-time scheme, with
> alternating priority in case of simultaneous sends.
- - TN allows for adding / settling / refunding arbitrary amount of
HTLCs at the same time.
Agree with lnd here, the complexity is worth it IMO.
> - HTLC abort stage - Setting up a new HTLC involves both sides
> accepting, then revocation message exchange. Currently there's no
> way to abort this process. - Allow the initator to abort any time
> before the revocation exchange, for weird corner cases such as
> timeouts.
- - TN allows for any party to start a new exchange to abort the
current one. I adapted the dice-rolling from CJP, in case both
initiate at the same time.
- - It is important be careful with revocation hashes when aborting.
You don't want the other party to hold on to an unrevoked tx...
>
> - Version bits - If we use an open-coded protocol, initial
> handshake after key setup should exchange two sets of version bits:
> one for compulsory features, one for optional features. You hang
> up if there's a compulsory feature you don't grok.
Good point, agree here.
> Wire protocol crypto -------------------- - Crypto AES/HMAC-SHA256
> or Chacha20/Poly1305 - AES has the word Standard in the name, but
> chacha20 is faster w/o accel (ie. ARM) and almost as widely
> supported.
>
> - Use separate encoding stream for packet lengths - Laolu's
> suggestion; encode the packet lengths as well which makes traffic
> analysis a bit harder. - Makes it a bit harder to detect
> re-transmissions (required on node restart), but probably not
> enough to kill the idea?
>
> Misc ---- - shachain vs elkrem - We use this to generate the
> revocation secrets, to minimize storage and computation for a huge
> number of old commitment txs. - They're actually very similar, but
> elkrem is much easier to grok.[6]
TBD on TN, they both sound solid, I agree with elkrem being easier to
implement.
>
> - Anchor tx renegotiation - We should allow re-anchoring of
> channels, to add or remove funds. - This would allow easy payment
> from lightning channel to normal bitcoin addresses, for example. -
> During transition, signatures for both commit txs must be
> exchanged.
This sounds like a 1.1 feature. Agree that we should allow it, but
does not seem urgent right now.
> - R value vs keypair - Using a simple secret "redeemhash" allows
> easy tracing of transactions through the network. - Mats Jeratsch
> proposed a keypair scheme which decorrelates them[3], Greg Maxwell
> optimized it slightly, and Anthony Towns[4] and Andrew Poelstra
> independently came up with a way to do it without any bitcoin
> mods.
Currently I am using R value, I am still a bit afraid of the lengthy
scripts when doing it without bitcoin mods. Might make sense to just
design the system in a way that it's easy to change later than to
implement it already.
> - Multi-sig txs - Joseph pointed out that by simply allowing more
> than one
signature on
> commit txs[5], we can enable escrow-style services (including
> things like GreenAddress.it which does this for normal wallets).
>
> I'm sure I've missed things; what are they?
Would be great to discuss connection/node failures. TN currently does
not support 'picking up' a lost connection again. I feel like anything
that MUST be finished on resume should rather be saved on hard disk in
advance, designing for various node failure modes.
Restarting a fresh connection seems to be much cleaner for me?
Cheers
- --
Mats Jerratsch
Backend Engineer, Blockchain
e: mats.jerratsch at blockchain.com
PGP: https://pgp.mit.edu/pks/lookup?op=get&search=0x7F3EC6CA
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJWqGslAAoJEAYZmwZ/PsbK5kkP/Rp1tANr8BDVBLRW6VftoEFr
6loMF49SUDvOoc21chem+y/eimnazRWzu6Kvcz19jHPZlDJLz3O+YLL//8QY+9Rc
1ufhNzqy4lQ42Kxqo7wxLQbvaJCL0tlFk/fPjO5pCZY60+FmZQ8MxHemBxRWtNc9
0BpMq5vUlcxC6AcsGtSaFNWVaoP5Y5FLi1InFVDUTfu9Fpko6hczjCu1MRMDk4DO
N6db6MOGyi4NTb2sdEGW89deBzuK/hne9CGw+OH3Fi/+gTIWjmYO6OcSA8mCfqhp
GvSS5CIBn5hzBY0IGd4Y3/KrivSRDfqnBOPUv1Sk9RIdqF+1tePB5u0vlsktM2EN
ZTz/0Ps3pn4PGzKJ76HRE3Qm994rymC9+ulW7f5xLON5ME53owT+GalTJ4oQfhL8
9k9U0gOKbQFdSj1tQbJPsVhK0MbHdj2FQPv+Ky0dkeuO4n9lsrrNOPEfIayyVtis
f9yVJ9dhKLU+U9oqE7pBOAVeYX+eqwJlKeqtsTQLGKuG60KjJav/LanPR8u1kkEX
jZN0hWToMfe9Sgu2dhMXl4L6lMn8KOXQTFNcGr+DDw+OVNc9X4YaaYHzIYLz+uTV
sVL0VTe5ftALGMSYdhYt/i98REQ2+Kd3fzYFUF4QoeepRKdR0HPPaWmtB0XSN4Qi
GrsltMsYqc/a3Zk59Hli
=ODl1
-----END PGP SIGNATURE-----

2023-06-09 12:45:21

- reply

📅 Original date posted:2015-12-08
📝 Original message:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
I've been thinking a lot about the Onion Routing we designed a couple
of weeks ago and how we would use it in practice.
So I am in full privacy mode currently and I would prefer to design a
system in which sender and receiver of a payment by default do not
learn any additional information about each other. This means that
payments will - by default - get routed over a rendezvous point(RP)
and encrypted using a onion scheme.
So if A wants to make a payment to E, E will choose a RP C and create
an onion object which will allow C to route the payment further
towards E. A will not know which node is receiving the payment, A only
knows that it should route the payments towards C. So A uses the
object E sent him and wraps the onion layers for the routing towards C
around it. When C receives it, it does not know that A sent it, nor
that it should be relayed to E finally. It will just follow the
instructions E put in the onion object.
In practice E can use a (reasonably sized) QR code to transmit this
blob of data to A.
However, we have to decide whether we want this whole onion-routing to
be one-time and one-directional or not.
The design where we stopped few weeks ago did fill up the onion
objects with zeros, so unless the nodes store some data to relate to
that message later, it is not possible for the receiver to send a
message back to the sender. (or to have any additional communications
at all for that matter)
This means we would need to transmit the payment hash together with
the blob in the QR code. Furthermore, if the payment goes missing, we
need some additional communications channel to address routing of the
refund payment. (NFC would qualify for that if we are using a mobile
wallet)
It also means that payment requests are one-time only, as they include
the payment hash. (even though we could try to do some fancy things if
we settle for EC keys for payments)
On the other hand, it would be possible to have a message system
integrated. When parsing the onion object, each node could encrypt and
append the pubkey of the node it received the object from together
with the ephemeral key used initially. When the receiver wants to send
a message back, he encrypts it using some designated ephemeral key
included by the sender and uses the onion object to send it back. The
nodes on the route can unwrap the onion object again to route it back
to the original sender.
This means that a payment request is just a way of contacting the
receiver to obtain information about making a payment. It can be
stored and reused whenever you want to make a payment. You can also
send the necessary signatures for the pay-to-contract scheme as
include other data necessary if we want to implement something like
Proof-of-Payment. In general, it would allow for very general purposes.
Which - on the other hand - is also problematic. It is difficult to
provide a reasonable DoS protection against nodes just spamming the
network with unnessesary messages. We could assign super tiny payments
to the process of sending a message to counter spam, but it might be
difficult to implement.
Additionally it serves a security risk, as someone obtaining the onion
object can 'hunt down' the sender by targeting the nodes consisting
the route one by one. Currently this is only possible for tracking
down the receiver. For one to succeed in such a task, it is necessary
to extract the private key used for encryption for ALL nodes in the rout
e.
- --
Mats Jerratsch
Backend Engineer, Blockchain
e: mats.jerratsch at blockchain.com
PGP: https://pgp.mit.edu/pks/lookup?op=get&search=0x7F3EC6CA
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJWZw+yAAoJEAYZmwZ/PsbK7soQAILSfSsENE9a87YU7xBj5Cws
B35rPYBVHcUCLWRIEOsEd3FCRmMDNQUGkzMFMaMXwWEBkVV5+csDhSCQxP8WdV3V
b8Y/ZzkpiMj7FUdFp64dNtUken24ixgbPK1tCGyhTiDb47uUWr1GeeF+wL51oSXp
ua2XM+y07RO9ghO7Sl25vAjQqeuN4tmoEU6u0AWGw9L0vVIFz/J6IXCjUG4w/ruo
7ljMUaSwir65euEmr1OEMGyB1doB6YBB5TmcRCP2sDENSdGizc9wQ0xeGeb9h8Kd
ZrggdX/NXpU4PS6Mn+SGNdJoVjv/NincQ5ZBBm6qtWC0f4Nq2nXgb/ISuEk/01Lp
3MNZu3r1pM5GJ7VH+zbmJxxv4sfI7GCY+D9is8hAN5IXCSaeTwkSJY3qzevWrP/h
5DSStjPU8K6h1JAiD+TDX1XtVNSmx7IKrRH1rEcQC6SmePYe871fQNFU1qdUro/P
JMIza4uRrHcyI/RjLGLQoy+EHCO+LbkXzmW/7k/trAZZWZ6f6F/wtCpDAKHPsl9q
udzjWIqv+3FHrjpgGW6WwrYzvkxDQ4rJPrSm+C/96Us4ePLn1syq+Z9m40xF/jZU
XXmGuu8Cx9mYk8/Dthv7Zs0muK2QC0UoAYpMuWQnAYWikeTWHYgaGD33hAz43Xwt
96Mt8FoNhSGLKoL+5YuI
=qWKx
-----END PGP SIGNATURE-----

2023-06-09 12:45:21

- reply

📅 Original date posted:2015-12-09
📝 Original message:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
> I have sort of lost track of preferences regarding what is to be
> sent through onion routing versus what's not...
Agree, it hasn't been on list for quite some time, the last time we
discussed it, we only included the route in there.
http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-October/00
0247.html
Back then only the pubkey of the next hop has been part of the onion
object, with no additional message to the final receiver. For having
the added privacy of changing R value we would probably add a random
number in there as well.
> Originally I had assumed that some out-of-band messaging would be
> taking place (like an equivalent to a BIP70-style payment
> protocol). Rather than a single QR code, I was expecting an
> interactive wallet-to-wallet protocol while both sides are busy
> communicating with the onion routing network for the actual payment
> route negotiation stuff. When they ultimately find that no
> sufficiently cheap route exists, then the wallets would opt to
> create a new payment channel in some circumstances.
Interesting. I think the important term here is 'out-of-band', as I
would implement above using the actual lightning network. But I also
fail to see how to implement a secure and private communications. I
guess one way would be to have wallets open up a hidden service on TOR
and take payment requests on a service listening there. But it would
not exactly reduce complexity nor would provide sufficient defense
against DoS attacks. Everything simplifies a bit when we assume these
communications using non-private way as simple
HTTPS-requests-responses, but I think we are sacrificing too much
privacy on the way.
> Once a path is found, the recipient would then communicate over
> the wallet-to-wallet channel to pass over the fully-constructed
> onion routing information. Sending that data back over the onion
> routing network may not be necessary. Unfortunately this increases
> the complexity of the payment side (wallet-to-wallet), but
> meanwhile makes for less message passing in onion land, which could
> make the problem easier to think about?
Do you mind defining wallet-to-wallet channel a bit more? Which
techniques could/should they use without leaking information?
Yes, we would increase the total load for the nodes if they should
handle these additional messages. But I think we can go with a
simplified message-delivery-system where each hop costs like 1 satoshi.
I call it simplified, because we are not using the a HTLC, but just
rebalancing the unencumbered outputs of the commit transaction.
As the sender of a message you can go to the first node and give him
30 satoshis for opening the onion object and passing the message to
the next node as instructed in the onion object. It would pay the next
node 29 satoshis, and so on. These would not be enforcable on the
blockchain, so a dishonest node could just keep the 29 satoshis and
not deliver anything at all. However, if you receive a message to
relay it, it is a strong indication that there is a payment to follow
up to that message. The general incentive is to relay these messages,
as fees of payment are likely higher. Given that we can have
sub-satoshi payments too, we might want to tune the cost-per-hop to
make it substantially less than any fees you could get of the payment.
If it remains a problem (and some people could just join the network
and not relay anything just for the sake of it), we might either find
a way to proof this behavior or even use HTLCs for these, even though
that would probably be not practical and bloat commit transactions
waay too much.
- --
Mats Jerratsch
Backend Engineer, Blockchain
e: mats.jerratsch at blockchain.com
PGP: https://pgp.mit.edu/pks/lookup?op=get&search=0x7F3EC6CA
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJWZ/gwAAoJEAYZmwZ/PsbKv4MQAKxoeZ+G3ozifODlY7nhqYeE
GQChU8DyDal8tAn1Bgb44s7SZMltSgpL9RR2G51/Cn0pygPMPUkT9OS5mRNMlEA1
s1JZ3annaxkJslUlFeF86Tw1MC8LhFYi/WbnJoCPElTmR1PljOtCmpUpjlrDMx7N
YNyjD/zUR+N1ZMqZh0q5okoZegyOkgo0biT5RHrjALUEnK3qWh/PCwUHXYdN/l22
h0LaEi0ajTFhEPNygSFz3Z13KmwYvsmsHl9MydweLbKARx6wo7OPxOWbuNVqD7xF
4eGgkniQZgZM+8owYFifXn/XVGj65PLQaqCN0o/gmCKphqjgoPWtbcJtKg8NtShN
6AI54ZqAtqh4IxpOZRBm2OiFW5TTou/XICDrCS/mfCNtv0wYNANop9+WQ/KTfStx
KnL986TDww5XkLws30Q9C6qFpBjwEgmTmGibvCM8z+HPe223kW0ElofLrWmvqyso
Ncj+iKj91cJLbs3XuzZ6pMgBwhW0ERSRj4bUm6r/oApSRyxYNNLVchOFhU9eWJxu
dhJul2ACFpcTql2zQOUhUe3PXD6M3cRpyLgeqRMNGNNs4+3eTnFdNiqWjK+QIIvZ
uFWpUDcPh3TJSh7TBZCHSxtAIHpCUyPL8u/LV6oZ4PHSd5aLMMm5tq95ViDNzAvm
ARTMgJtNA6q4CYlUflr3
=b/hD
-----END PGP SIGNATURE-----

2023-06-09 12:45:19

- reply

📅 Original date posted:2015-11-27
📝 Original message:
Hm interesting.
Couple of remarks:
(1) 'without timeout' is only possible with OP_CSV - not naturally
with what we have currently. ;)
(2) To be able to build a valid payment channel on top of the anchor,
B has to be sure that A cannot get her money back at any point in the
future. Given just a hash that B should sign, B has no clue what is
the output of the transaction he just signed. But I guess we can solve
this by B demanding the transaction he signed before proceeding to
accept any payments. B can then reassure himself that this transaction
indeed resolves to the hash he signed and that it is revocable by B
with any following commitments. Beside the pubkey we also need some
revocation hash provided by B for creating the commitment transaction.
(3) While this is a fair setup already, it does only protect us
against targeted attacks against a specific transaction. An attacker
could still mine a block with all P2SH transactions (probably not even
that many) changed. If you have a large amount of hashing power, you
can open up channels with hundreds of parties and then start attacking
the network. It can be mitigated by waiting some time before
broadcasting his anchor, but even then it remains some hack, and
theres some chance someone will lose money doing that.
2015-11-27 8:37 GMT+01:00 Nicolas Dorier <nicolas.dorier at gmail.com>:
> By adapting an idea from gmaxwell
> (https://bitcointalk.org/index.php?topic=303088.0) it is possible to open a
> channel without suffering from malleability attack.
>
> The process for A to open channel with B is the following:
>
> * A asks B pubkey
> * A create the first commitment transaction
> * A extract the hash that B needs to sign to be able to broadcast the
> commitment
> * A asks B to sign the hash, but do not disclose the commitment
> * A broadcast the anchor
> * After confirmation, A announce the anchor to B.
>
> B can't identify A's anchor before announcement because he does not know the
> P2SH of the multisig.
>
> Am I missing something ?
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>

2023-06-09 12:45:16

- 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:13

- reply

📅 Original date posted:2015-11-24
📝 Original message:
While working on the payment layer and messing around with timeouts /
timeframes for CSV and CLTV, I noticed a few things...
(1)
It is indeed not possible for HTLCs to have a long revocation time and
a short refund time. And it makes sense the way we designed the
scripts and the commit transaction. As it's a single output, we either
can prevent the other side from doing ANYTHING for the revocation
timeout T1, or the other party is able to claim the complete output
without any encumbering... In long chains of multiple hops, I might
need R to settle the payment normally, while you still wait out the
revocation timeout before you can reveal R...
I described that some time ago, but was unsure if I was right
http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-September/000182.html
(2)
As revocation-time and refund time are equal, we have some problematic
race conditions, where both parties can technically claim the payment,
depending on propagation time of the transaction. Further, if you
claim the payment that I was actually entitled to per refund, I may be
out of luck getting my money back on the next hop...
(3)
As the absolute CLTV timeout has to increase with each hop, it can
give us insight about our position within the route, even with onion
routing. It is possible to have the sender add some delay, but this
just increases the (already long) total refund time.
I played with the numbers back and forth, but I don't really see any
way out of this problem. Anything below one day might be dangerous
already for DDoS attacks, with 20 hops we might end up with 30-40 days
for a refund though...
If we go back to the original design, we are able to separate
'claiming-a-payment-using-R' and 'revoke-an-output' into two layers
and such, we can enforce revealing R within a separate timeframe than
the revocation timeframe. To do this, we need either SIGHASH_NOINPUT
or SW, as we can't construct the transaction on top of the 'reveal-R'
transaction without knowing R currently. Short refund timeouts would
also mitigate the problems of (3)
I would really love to stick with the current design, as not having to
keep another set of signatures makes everything easier ...
Cheers
Mats

2023-06-09 12:45:05

- reply

📅 Original date posted:2015-11-27
📝 Original message:
I love how people come up with sneaky solutions to force the other
party to reveal the private key somehow. But given that we might have
dozens of HTLCs in a commit transactions or also payments that pay to
two (or more) payment keys (is this the new term for it now?) we
should maybe strive for a more clean solution.
I have summarized most of the information of this discussion and
'handed in' a BIP request to the bitcoin-dev mailing list. If the use
case is good enough (and I think it is) and there are little draw
backs (can't think of any security-relevant one), there should not be
too much resistance.
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011827.html
Cheers,
Mats
2015-11-27 5:42 GMT+01:00 Anthony Towns <aj at erisian.com.au>:
> On Fri, Nov 27, 2015 at 02:25:09PM +1030, Rusty Russell wrote:
>> Anthony Towns <aj at erisian.com.au> writes:
>> > The alternative approach, which andytoshi and I came up with
>> > independently is a lot more complicated:
>> > revealP( Q, R, sigA, sigB, sigC ) {
>> > check_multisig_verify(2, P, R, 2, sigA, sigB); code_separtor();
>> > check_multisig_verify(2, Q, R, 2, sigA, sigC); code_separtor();
>> > check_multisig_verify(2, P, Q, 2, sigC, sigB);
>> > }
>> > If sigA, sigB and sigC all share the same r and SIGHASH settings,
>> I don't think this works? We can't provide the signatures in the
>> scriptPubkey, since that requires them signing themselves.
>
> The scriptPubkey has the pubkey P, and a whole mess of stack operations
> to implement the function above; the scriptSig just has Q, R and the
> three signatures.
>
>> We can't
>> have them provide it in the scriptSig, since theres no "do these have
>> the same r value" operator in script.
>
> There's six sig ops, but only three different signatures. Getting the
> various combinations to have the same signature forces the same r value
> between each of the signatures, without needing a separate op to check
> it explicitly.
>
> It's mathematically possible to come up with Q, R, sigA, sigB, sigC where
> sigA.r, sigB.r and sigC.r are all different; but it requires being able
> to come up with a transaction with a particular hash, or calculating the
> discrete log of a weird value to do so, so should be safely intractable.
>
> Cheers,
> aj
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 12:45:02

- 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:58

- reply

📅 Original date posted:2015-10-26
📝 Original message:
Hey everybody,
I created a new OSS-organisation on GitHub lightning-core and opened a
new repository dedicated to hold the specifications of any lightning
node.
https://github.com/lightning-core/lightning
This has several positive effects:
(1)
I am positive this will help to ensure we all build somewhat
compatible software. As we all only come together every once and again
on IRC (and rarely on the mailing list), we end up building the same
things in parallel that are not compatible at the end of the day.
While it is great to have implementations in different languages for
different systems, would be even better if they end up being one large
network at the end of the day.
(2)
It is in general a good idea to have the product specifications and
implementations in separate repositories. This way we have the
contract each implementation has to abide separate and clear in view.
(3)
It is easier to work towards different targets that may seem out of
reach right now, but still have them structurally on the same
repository. If some guy decides to work on an implementation on some
advanced topic, he will have a difficult time getting it across on the
mailing list. I think a github repo is a much better place to share
these ideas.
(4)
Anyone doing a complete new implementation does not have to search
across different implementations and mailing list posts to find
answers how his software should behave to communicate with the
network. The specification will be a great guideline for new
implementations
As I just started it, practically everything is still missing. I
started writing together the current implementation on the encryption
layer, but even there I noticed how much of it I have to scramble
together from different sources.
Feel free to fork and write up, we can always discuss the status quo
before pushing it to master. The skeleton is missing a lot too, but we
have to start at some point...
Cheers
Mats

2023-06-09 12:44:57

- reply

📅 Original date posted:2015-10-27
📝 Original message:
>> 3) All packets from then on are encrypted of form:
>> /* HMAC, covering totlen and data */
>> struct sha256 hmac;
>> /* Total data transmitted (including this). */
>> le64 totlen;
>> /* Encrypted contents, rounded up to 16 byte boundary. */
>> u8 data[];
> Looking at your code it seems totlen is actually the size of the
> unencrypted serialized protobuf message, not the total data
> transmitted right ? If so, the comment is a bit misleading, and why
> make totlen include the length of itself since it doesn't define the
> encrypted message boundaries anyway ?
> Also, why encode the length on 64 bits rather than 32 bits ?
Actually I think we do not need this field. Initially, the idea was to
provide replay protection. You keep track of totlen locally, and
compare it with the value the other party sends to you.
However, as we are using AES-CTR, we do not need to do that. We have a
dedicated counter in the IV that does keep track of all messages in
each direction respectively. If some attacker tries to replay the same
message towards us, we are unable to decrypt it, as the IV is not
correct (as it is assuming a different counter)

2023-06-09 12:44:53

- reply

📅 Original date posted:2015-10-19
📝 Original message:
Hm interesting. So far the IP-PubKey-Relationship was public for me
(furthermore, I even think about adding it to the gossip protocol, see
other post).
I think we can mitigate the risks associated fairly well. Suppose
lightning nodes run on dedicated machines, firewalled against any
incoming connections (except ones on the lightning port).
Against DDoS attacks it could be sufficient to just close this port as
soon as you are connected to all of the nodes you want to be
connected. Open connections are not affected by this.
However, I think it will be more difficult to establish a connection
between 'Real identity'-'PubKey'. And this relationship should really
be more sensitive. When you pay to someone, he will only provide you
with a rendezvous point and the onion object towards him, which is
encrypted. Lightning nodes can always have a dedicated IP address, to
make it more difficult to relate merchant IP and pubkey.
I think it is important to have a map of IP/PubKey for those who want
to provide it at least. The object which relates your pubkey and IP
will be signed with your private key. If you never sign and send such
an object, no one will be able to tell your IP other than your direct
neighbors. I think though that most nodes should be able to receive
new connections and build channels with foreign nodes. It is a direct
consequence of sufficiently hardening the network against failure. If
you observe a high fee rate for a specific route, you should be able
to establish new connections to help the network.
Against MITM and eavesdropping your pubkey to a stranger connecting to
your node, we can change the protocol such that the one initiating the
connection always sends his signed pubkey object first. It is up to
you to accept it and send yours if you know the other guy or don't
care, or to abort the connection if you don't like strangers.
Cheers
Mats Jerratsch
2015-10-19 7:30 GMT+02:00 Anthony Towns <aj at erisian.com.au>:
> On Sat, Oct 17, 2015 at 06:53:55AM +1000, Anthony Towns wrote:
>> I think treating the relationship between a network address (IPv4/IPv6
>> addr and port, tor service) and the lightning network address as sensitive
>> is valuable. Revealing a network address helps reveal physical identity,
>> makes denial-of-service attacks straightforward, and gives a point of
>> entry for targetted hacking to steal your money.
>
> I guess the attacks I'm thinking of are something like:
>
> Exploits leading to theft:
>
> - if you're a merchant, it's easy to find out your lightning id (just
> buy something from you!) and during the trading day you'll probably
> have a relatively large balance in your lightning channels (up until
> you close it out by committing your profits to the blockchain eg). If
> I can find your IP address and hack into your system, I can steal
> that money.
>
> - if you're making lots of money routing payments, I might be able to
> deduce that from public information (like how cheap your fees are,
> how rarely your fees change, how many connections you have, ...)
> and thus know that you have a lot of money in lightning channels that
> I can steal
>
> - if you're just being a consumer, however, I can't think of a reason
> your lightning id would matter -- if I can snoop on your IP connection,
> I can probably tell you're mostly a consumer by traffic analysis,
> and conclude that you've probably got $10-$100 that could be
> stolen. failure of imagination on my behalf?
>
> Denial of service:
>
> - I might know the lightning id of someone I don't like; a merchant who
> sells something unpopular, or a node that routes payment for people I
> don't like. If I can translate that into an IP address, I might be
> able to DoS them using botnets etc.
>
> Exploits that help you exploit others:
>
> - if I know X has a channel with you; figuring out X's IP might let
> me monitor X's TCP connections (by hacking into their system, or
> by subpoena'ing their ISP), which in turn would help me figure out
> your IP.
>
> I guess there's three ways you can associate the info:
>
> a) given a lightning id, cheaply work out the IP that provides it
>
> b) given an IP, cheaply work out the lightning id associated with it
>
> c) given an IP and a lightning id, confirm/deny whether that lightning
> id is provided by that IP
>
> (a) is what you want if you're planning theft or DoS
>
> (c) is enough if you've got other information about whoever you want to
> attack that can narrow down the lightning ids and IP addresses (eg, you
> want to attack a local business, so you can find out their lightning id
> directly, and narrow down their IP based on local ISPs)
>
> (c) is obviously trivial if you've already got (a) or (b).
>
> You can get to (a) from (b) if (b) is cheap enough and you can build up
> a database that you can query in reverse.
>
> If you're not an attacker, then (a) is useful if you want to have new
> channels not be totally random (eg, to have people be able to connect
> to newly announced beacons). And (c) is presumably necessary if you
> want to reconnect to someone you had a channel with, when you lose your
> internet connction.
>
> One "clever" way to handle (a) might be via a "fund a new channel by
> lightning transaction" operation. ie, if you (Alice) want to open a
> channel with Bob, route a payment to Bob with instructions to forward to
> Alice, and to do that by connecting to a given IP/port and establishing
> a new channel; ie rather than just telling Bob to route to Alice in the
> onion payoad, also included Alice's network address. That way Alice
> reveals her IP precisely to Bob; and Bob only reveals his IP if he
> decides he is interested in opening a channel.
>
> That'd also provide a way of reconnecting with a peer if you lose your
> connection and both of you change your IPs. It assumes that you both
> have an alternative channel that's still functional though.
>
>
> Okay... so how about the following. When making a new p2p connection, when
> you know who you're talking to, you rely on a shared secret X, and send:
>
> Alice: "Hi. I'm <session key A>. My nonce is X."
> Bob: "Good to meet you, I'm <session key B>."
>
> Rest is encrypted to ECDH(A,B).
>
> Alice: SIG_Alice(Alice || Bob || A || ECDH(A,B))
> Bob: SIG_Bob(Bob || Alice || B || ECDH(A,B))
>
> Alice: "Hi Bob!"
> Bob: "Hi Alice!"
>
>
> If you don't know who you're talking to, you don't send a nonce and
> you do the current protocol. Once you're connected (or once you have a
> channel setup) they'll tell you a nonce to use next time:
>
> Alice: "Hi. I'm <session key A>."
> Bob: "Good to meet you, I'm <session key B>."
>
> Rest is encrypted to ECDH(A,B).
>
> Alice: I'm Alice, SIG(Alice || A || ECDH(A,B))
> Bob: I'm Bob, SIG(Bob || B || ECDH(A,B))
> Bob: BTW, next time you connect, use nonce <Y>.
>
> If Bob wants some degree of privacy, while still accepting anonymous
> connections, then he generates a new id to hand out to anonymous
> connections every so often, linking it up to one of his other ids, or
> to one of his neighbours by reusing a pre-existing channel. If you're
> asking someone to connect to you and have a bunch of ids, you give them
> a nonce to use that will select the correct one. You use nonces as a
> hash key to lookup your id, their id, and any channels you have open.
> You don't share or reuse nonces.
>
> (If an attacker knows Alice and Bob have a connection, and can MITM
> Alice trying to connect to X, the above lets them verify which of Alice's
> connections is Bob. If that's a reasonable attack, it'd be avoidable if
> the nonce X was replaced by X and Y; X sent in cleartext as above, but
> Y simply included in the info being signed. That prevents the attacker
> from being able to verify the signature info at all)
>
> Not convinced that's quite right, but maybe something along those lines
> might work out.
>
> Until there's a substantial number of lightning nodes (1000s?), it's
> probably trivial to link network address and lightning id by traffic
> analysis, so I think it's probably sane to leave implementing any of
> the above until later.
>
> Cheers,
> aj
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 12:44:51

- reply

📅 Original date posted:2015-10-16
📝 Original message:
Other post was quite long already and they are actually dealing with
two different issues.
So currently I can think of 3 different broadcast messages, that are
differently dynamic and needs different handling, so I attach them
each with a new signature (which bloats a lot unfortunately).
(1) Pubkey-Channel-Relationships (see other post on ML)
Very static, relayed every 10 days
264 Bytes
(2) Node addresses/IP
Depends on the nodes (dynamic/static IP), approx every 12h
133 Bytes (some estimate, as I want to support addresses too, not just IPs)
(3) Channel-Status (capacity, fee, ...)
Highly depending on actual traffic and node usage - once an hour?
176 Bytes (estimated, depends on actual content)
I would love to combine (1) and (3) to save the 80B of an additional
signature, but at the same time (1) is not worth an hourly broadcast.
Furthermore, I would spare some additional bytes in (1) for some
reputation system (yes, I really am into these.)
These three add up to 2.5GB daily data, or 30kb/s constant load.
For hard drive space it is around 330MB.
I think we can either realise it as some kind of gossip protocol (easy
to implement, overhead of an efficient gossip protocol can be very
low) or use some DHT approach (difficult to bootstrap, has to be
designed to be highly resistant to failure/highly redundant).
A new node would want to retrieve the full dataset similar to the
blockchain before actually opening a channel with a new node. So we
need to design a way of retrieving the full dataset for fresh nodes,
probably in some load-distributed way, although 330MB isn't too much
to retrieve from 1-5 nodes. (and 100k nodes is a pretty optimistic
view of the network too currently, although rusty usually starts even
higher...)
Mats Jerratsch

2023-06-09 12:44:50

- reply

📅 Original date posted:2015-10-20
📝 Original message:
> But you can tell, just by seeing whether a well-known third party's
> lightning address is routable? If every node on your network is an
> attacker's, then you won't see the third party's address.
>
> If you do see a route to the third party (ie, Me -> Attacker -> Attacker
> -> Attacker -> Bob -> Carol -> Third party), then you could work backwards
> asking Carol and Bob to connect directly to you, which would get you a
> non-attacker node with reasonable probability, assuming there are any.
No you can't, that's the whole point. ;)
Just because they are attacking you personally does not mean they do
not have a working link to the rest of the network. They can still
route all your payment and (1) monitor all your activity (2) gain some
profit by charging some high fees off of you.
Maybe I am missing something though..

2023-06-09 12:44:49

- reply

📅 Original date posted:2015-10-19
📝 Original message:
All of your assumptions have the premise though, that choosing a
'good' vs a 'bad' guy is pure probability, like picking the right ball
out of a bag. There are other systematic attacks though, where an
attacker can trick you into his network for practically zero costs,
especially if there is no other solution in place (like checking the
blockchain for all of the networks anchors).
Think about an attacker who is able to MITM your internet connection,
like the hotspot you connect to at a Cafe (or your ISP if hijacked).
They can build locally a gigantic network, all pointing to the same
node. You can't tell, and they don't have to necessarily just block
your payments. (see above)
I am mainly concerned over those. Especially since there is not really
anything we can do about dishonest nodes joining our network, but it's
encouraging to see your math. Since everything security-wise so far
stands only with knowing pubkeys of nodes actually connected to the
network, this should be the first thing to tackle. (that is, making it
expensive to attack it this way)
Only nuisance is that it requires either SPV or full node to check the
anchor, but I kinda like the idea of having all (or a good amount) of
lightning nodes be full bitcoin nodes as well.
cheers
Mats Jerratsch
2015-10-19 3:41 GMT+02:00 Anthony Towns <aj at erisian.com.au>:
> On Sun, Oct 18, 2015 at 01:25:29PM +0200, Mats Jerratsch wrote:
>> > 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.
>
> I'm not sure this is true? Supposing there are V vandals on the system,
> compared to T total nodes, so V/T is your probability of selecting a
> vandal. Then, to join the lightning network, you open up N channels
> with randomly chosen nodes at $1 each, committing $N in total, and
> (if they're all run by vandals and have to get closed) spending about
> 2*N*2c (so 4%?) in fees. If there are 1000 nodes (ie, lots), then the
> probability of finding at least one good node is about 1-(V/T)^N. If you
> want a probability of 99% of getting a good node on your first try, then:
>
> V/T = 10%: N = 2
> V/T = 20%: N = 3
> V/T = 30%: N = 4
> V/T = 40%: N = 6
> V/T = 50%: N = 7
> V/T = 60%: N = 9
> V/T = 70%: N = 13
> V/T = 80%: N = 21
> V/T = 90%: N = 43
> V/T = 95%: N = 86
> V/T = 99%: N = 368
>
> So with 90% of nodes being hostile, that'd be getting expensive, but
> not completely implausible. If 40%-plus of the network is legit, though,
> just trying out 10 random nodes seems like it works fine, and only locks
> up $10 for a couple of days and costs about 40c in bitcoin fees...
>
> Also, if you've got to run 2.5 times as many vandal nodes as there are
> legitimate nodes for people to even really be bothered, I don't think
> you'll see many vandals in the first place...
>
> (Once you've got a node that actually works, you can expand your channel
> from $1 to $10 or $100, and/or open additional channels, and at that point
> (afaics) you're set.)
>
> That's only necessary if you don't know anyone with a lightning account
> already, though. Since anyone can forward for you, you could start with
> someone you trust in real life -- eg, a friend, a bank, a government,
> etc. If Rusty tells me he'll route my payments (as long as they're made
> between 10am and 3pm Adelaide time on a weekday, maybe) then I can open
> a $5 channel with him, and use that to send 1 satoshi payments to test
> connectivity. So, if I'm wondering whether BOBSBANK is reliable, I work
> out a route:
>
> aj -> rusty -> a -> b -> c -> BOBSBANK -> x -> y -> z -> rusty -> aj
>
> apply it as an onion so it can't get short-circuited, and see if it gets
> back to me, at a cost of maybe 10% of a satoshi (10 hops at 1% each)...
> If it does, BOBSBANK is connected and functional, and I can try opening a
> channel. If it doesn't, I can try a different route to BOBSBANK, or try
> someone else entirely.
>
>> Furthermore, an
>> attacker can always play by the rules and forward all payments up to
>> one point where he stops.
>
> (For example, he could happily route payments on $1 channels, but refuse
> to do likewise when the channel capacity was upped to $10)
>
> In the general case though, does that even count as an attack? Isn't
> that just like a web site going down or being put behind a paywall? ie,
> annoying, but completely legitimate? I mean, if someone downloads the
> lightning software to try it out, runs it for a while, then decides it's
> no fun and stops, they'll be "playing by the rules up to one point where
> they stop"; but they're not trying to "attack" the system.
>
> Coping with unreliability is definitely important, but running a node that
> works sometimes but is deliberately unreliable is a lot more effort than
> running a node that claims to work, but never does. It's also more work
> (and less profitable) than just running a node that actually work...
>
>> 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.
>
> That's a different attack isn't it? To get everyone to connect to your
> nodes, you'd have to be running the majority of nodes -- ie, there's
> 5000 different organisations running lightning nodes, but 4999 of them
> run one or two nodes each, but one of them runs 100,000 nodes.
>
> But if it were cheap enough for one org to run 100k nodes, why wouldn't
> the others treat it as an arms race and end up running, say, 20-50
> nodes each? They'd have an economic incentive to do so, in that it
> increases their odds of collecting fees... At that point the attacker's
> already reduced to 28%-50% of nodes. ie, I think that's likely to be
> self-correcting?
>
> But! An arms race in nodes-per-person would probably cause a scaling
> problem for the network (depending on how routing actually works), and
> you'd have to address that by creating some cost to run (or at least
> register?) a node/channel. But if they're all legitimate nodes, I think
> that's just a scaling problem, rather than vandalism per se.
>
> (An additional but: even if spamming the list of nodes doesn't work as
> an effective attack, if you can spam the list of *channels* with valid
> looking edges that won't actually route payments successfully, you can
> screw over the network pretty well)
>
> Cheers,
> aj
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 12:44:49

- 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

- 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

- 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:39

- reply

📅 Original date posted:2015-09-24
📝 Original message:
Hey Pierre,
I was mainly talking about the case where one node in the chain does
not relay the payment to the next node. So this is mainly about
recovering, such that we can finish the payment without waiting for
the timeout (which would piss off users so much). And this is possible
in general. I feel I was either very unclear or you should reread my
post again, as you just talk about timeouts (which is more of a
layer-0 variable than a layer-1 mitigating technique).
I have discussed in
http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-September/000182.html
that the revocation time and timeout time must be identical. I'm still
not sure if I am missing something, but it does seem logical. It is
the one drawback we have from having all outputs directly to the
parties, instead of spending them to another set of multisig
addresses.
Indeed, one day payment timeout is a lot, but one day revocation time
is quite low, as it means all parties has to check the blockchain at
least once a day, every day...
Cheers,
Mats
2015-09-24 13:13 GMT+01:00 Pierre <pm+lists at acinq.fr>:
> Hi Mats,
>
> I am not sure I understand what you meant, so forgive me if my answer
> is a bit off topic.
>
> Let's consider A->B->C->D->E.
>
> The way lightning works is that A does *not* pay B, instead it locks
> the corresponding funds in a contract that can end up two ways :
> 1) B provides a secret R which means E got the funds, and the contract
> is fulfilled.
> 2) a timeout occurs in which case the contract is voided. So there is
> no refund because the payment never actually took place.
>
> But what you might have meant is that you are aware how this works,
> but you still want a way for A to cancel the contract before the
> timeout, in case A and E cooperate and C is unresponsive.
>
> I would say this is a bit contradictory because when A signed the
> initial contract, it basically acknowledged the fact that it is
> willing to take the risk to have its funds locked for at most $timeout
> if things go bad, right ? This is the essence of lightning after all.
>
> That been said, I see two ways for A to reduce the timeout :
> - either find a shorter path (maybe even A->E)
> - or convince B/C/D to use small timeouts, maybe just a few blocks
> between each node. That would reduce A's timeout to a few hours, and I
> don't see why that wouldn't work. This might be the real answer to
> your problem, but I am certainly missing something!
>
> Now that I think of it, I actually don't know why the default timeout
> is 1 day on the original lightning presentation, that seems really
> high.
>
> Cheers,
>
> Pierre

2023-06-09 12:44:38

- 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:34

- reply

📅 Original date posted:2015-09-23
📝 Original message:
> Indeed. Random selection helps, here, but analysis will be interesting.
How have you ended up with a number of beacons you need? 12 seems so low, I can’t imagine so few nodes to support all transacting for even 10 minutes.. And it’s very difficult to estimate how much bitcoin they might need for that timeframe, as some people might want to transact only few satoshi, while others send multiple bitcoin. We can abstract the network towards two nodes at each end and N beacon nodes in the middle doing all the transacting. The two nodes at either side are separate networks then, which need to figure out their own routing.
Furthermore, I don’t really see the big advantage in this scheme. We still need to find a route towards these beacons, and often one might not be interested in the cheapest one, but would want to add more privacy. I think propagating the node-map is pretty efficient in general…
> Short term I'm thinking we'll have an IRC channel (a-la early bitcoin)
> and everyone will advertise their channels there. This is design for
> the next, more ambitious phase.
Hm I think this would be a wasted effort. While there are probably good libraries to do the job out there, it would still need some implementation. As soon as we can solve the node discovery (and if we want to go with a central server, we might just as well hard-code some reliable nodes into the code for now), we can communicate over the network..
>
>> Furthermore, we can also include
>> some byte for a reputation / web-of-trust system. It is completely
>> optional, if you are able to figure out how to route the payment
>> across your nodes you are not forced to use this system, and I don't
>> think it will have severe privacy problems.
>
> I think reputation systems will become an overlay, if the basic system
> proves vulnerable. It's nicer if we don't have to though, as reputation
> is both hard to encode in normal behaviour, and deeply centralizing.
Yea centralisation is an issue with reputation, we might want to have it rather limited. Have it some way, such that there isn’t much difference between a big node that has been around for long and a relatively new node, as long as both are
(1) low latency
(2) highly available
(3) honest.
>> Is there any plan how we handle connections currently? I am thinking
>> about sending the current IP address with this update, such that nodes
>> can connect to each other after one broke down again, and it would
>> further support dynamic IPs as well. Could be possible to extend this
>> to hidden service notation, although this would need some more bytes
>> to store.
>
> So, I'm assuming the basic network comms is organized along channel
> lines; you have to communicate to the other end of the channel anyway,
> so that makes sense.
>
> This doesn't solve "how do I connect to the network" or "how do I start
> a channel with this particular node", though. For that, I've floated
> the idea of reusing the bittorrent DHT, which has extensions to allow
> just this.
Yea exactly, we can squeeze these information in there. The packages are very small. If we end up in a situation where they impede the payment transactions, we might want to have some priority mechanism..
The ‘how to connect to the network’ can be solved with basic peer discovery schemes, like IRC or stable-nodes. Having received the topology of the mesh, you can decide which nodes you want to create a channel with (maybe we should add a flag somewhere, whether this node wants to open a channel with strangers and under which conditions). He can directly connect to that node and open a channel with him, or am I missing something?
> You can squeze some more bytes out of you want:
> 1) Signature should be 64 bytes (never DER encode).
> 2) Pubkey can be hashed bitcoin-address style, and recovered from sig.
You can recover the pubkey from the hash and the sig? Why are we putting the pubkey in the scriptSig then? ;)
> If we're using protobufs, they're extensible, so you can add reputation
> later if we need it.
>
> You also want two signatures, I think: one from each side. Though it
> makes sense to have a separate teardown message which only needs one
> sig.
Yea was thinking about this as well, I thought as both nodes will propagate their own message, other nodes can puzzle it out, whether the channel has been confirmed by both parties. It saves one signature too..
>
>> These two would be spread as one message.
>> This allows to keep two separate databases, and be able to bootstrap
>> new nodes with this information, while we do not have to store old
>> beacon data.
>
>> As reputation will be stored for quite some time, we should really
>> save them with separate signatures. (This will make it more difficult
>> / costly to share the complete database with new nodes, and we need to
>> store old data (reputation should be stored for some time) to validate
>> the signatures.
>
> Unclear what reputation means, here?
I was thinking about storing reputation for some time for all nodes. I’m not sure this is a good idea anymore, as it may lead to some amount of centralization.. It would be beneficial in this case to have the reputation data along with the signature only, to be efficient. That way you can always recover the reputation data of all nodes of the network for a new node, as you can send along all signatures..
> BTW I've not been separating nodes and clients in my head-design. Of
> course, some nodes might not ever generate payments, and some nodes
> might never route others' payments, but it increases privacy vastly if
> they *can*, so I'm trying to think about them that way.
For me it is more a connection issue. Nodes should have a 99+% uptime and allow for direct incoming connections. Still have to figure it out, but of course as a node provider you can always issue a payment directly (I think for any outsider, there is no difference between the node issuing the payment or some client connected to that node)
> Yes, reputation is hard.
>
> What do you think about the idea of using the anchor transactions in the
> blockchain as a map of the network? You could use an OP_RETURN to stash
> two pubkeysx, that is the two node IDs.
Hm isn’t this difficult to prove? Anyone could have put those pubkeys in there, so unless we further put a signature in there, this information holds little value I think.. I like the idea in general, as it would make fake-nodes more difficult, but I think it is difficult to implement in the bitcoin blockchain. Furthermore, how do you plan to have the scriptPubKey for the anchor tx then? Ultimately it is still P2SH, so no one is really able to recover any data from it..
As a plus, I am currently working on some simulation project for lightning. A lot of the metrics are very difficult to estimate (let alone calculate), and often we want to depend on random selection. We will be able to deduct a lot of properties from it, and be able to determine, whether we need something like the reputation system at all, and how many dishonest nodes it takes for some attacks, and how efficient routing is, all the good stuff...
Cheers,
Mats
PS.: This was the last time I opened a new thread incidentally -.- Just disabled the digest option… ;) Sorry for the inconvenience...

2023-06-09 12:44:33

- reply

📅 Original date posted:2015-09-21
📝 Original message:
> On Mon, Sep 21, 2015 at 11:46:13AM +0930, Rusty Russell wrote:
>> We regularly choose a dozen "beacon" nodes at random (using proximity to
>> the SHA of latest block hash or something). Everyone propagates the
>> cheapest route to & from those nodes (which is pretty efficient, similar
>> to your scheme).
I don't know, using the beacon kind of technique does seem a little
bit cumbersome and you really have to think about a lot of possible
attacks that might render the whole network unusable, because all
beacons are maliciously sabotaging the network..
> If you do know the entire graph, you don't need to give away any
> information about who you want to pay prior to sending the transaction.
> Knowing the graph is potentially interesting for commercial and academic
> reasons beyond wanting privacy. (Knowing the fees others charge helps you
> work out what fees you should charge; but just querying your neighbours'
> routes is probably sufficient to work that out too)
I initially thought about going with a Node Directory. That is, a
central server collecting the routing data that could be sent there by
choice. We can work out with signature and if both nodes submit the
route towards the other node, whether this is indeed correct. But as
this isn't too much data in the first place, I am very much in favour
of just using some gossip-protocol. Furthermore, we can also include
some byte for a reputation / web-of-trust system. It is completely
optional, if you are able to figure out how to route the payment
across your nodes you are not forced to use this system, and I don't
think it will have severe privacy problems.
Payer and payee can further work out a rendezvous node. The payee will
send the encrypted routing data from that node on to himself and the
payer can build the rest of the routing from his viewpoint.
Having this data distributed really allows for making payments without
leaving too many visible traces on the network.
I would also spread data about how much can be spent and received with
this route and fees for receiving and spending. Again, this data can
be very vague and does not need to reflect the real world. You can say
you support payments up to 10k satoshis, even though the channel has
5BTC in it.
Is there any plan how we handle connections currently? I am thinking
about sending the current IP address with this update, such that nodes
can connect to each other after one broke down again, and it would
further support dynamic IPs as well. Could be possible to extend this
to hidden service notation, although this would need some more bytes
to store.
The protocol on my side does look like this currently:
General beacon for our node
- pubkey [32]
- timestamp [4]
- IP/connectionDetails [8+...]
- signature [70]
Routing information
- pubkey_from_us [32]
- pubkey_from_you [32]
- fee_sending [4]
- max_sending [4]
- current_reputation [1]
- timestamp [4]
- signature [70]
These two would be spread as one message.
This allows to keep two separate databases, and be able to bootstrap
new nodes with this information, while we do not have to store old
beacon data.
As reputation will be stored for quite some time, we should really
save them with separate signatures. (This will make it more difficult
/ costly to share the complete database with new nodes, and we need to
store old data (reputation should be stored for some time) to validate
the signatures.
I was calculating with two updates a day, but only 100k nodes. Each
node would make a connection to around 10 other nodes, resulting in
114+10*147 = 1.5kB per update. Each node would only use around 3kb/s
up/down and would do around 3 signature verifications per second in
idle mode, while allowing everyone a full copy of the routing. Making
sure messages spread efficiently is another problem, as we have so
many tiny messages. Storing the hashes you received in a bloom table
and asking other peers if they want to receive it as well does work,
but just the hashes of all messages do add up already..
In the end, the nodes themselves don't really need the routing
information, we just need a way to transport the information to the
clients that make payments. Nodes will just stupidly obey the orders
given in the blob of data they'll receive.
This design opens up for some DDoS attacks, as we don't want other
nodes to just spam information all day long that would be relayed
through the complete network. Furthermore, one attacker can just
emulate a complete network that is vouching for him, and he can use
those 'nodes' to push spam through the network as well. This does
screw a little bit with the reputation system, but I think it would be
possible to detect a cluster of nodes that is only connected to the
rest of the network through that one attacker (some graph theory I
guess). Furthermore, we can check nodes by pinging them randomly, and
dropping any reputation if we cannot reach them.
Mats Jerratsch

2023-06-09 12:44:22

- reply

📅 Original date posted:2015-09-03
📝 Original message:
I just messed around, thinking about reasonable timeframes for
payments and revocation. I ended up thinking that 7 days would be
okayish as the revocation timeframe for most usecases, as we also have
to think about the everyday users that are not online (or don't even
have access to their computer) for a couple of days..
I further think 1 day is plenty of time to reveal R. We really don't
want to give the receiver too much time to accept and clear the
payment. (It locks up funds for everyone else in the route..)
Considering these values with the HTLC Receiver Redeemscript
HTLC Receiver
OP_HASH160 OP_DUP
<R-HASH> OP_EQUAL
OP_IF
<7 DAYS> OP_CSV
OP_2DROP
<KEY-B>
OP_ELSE
<REVOKE-HASH> OP_EQUAL
OP_NOTIF
<8 DAYS> OP_CLTV OP_DROP
OP_ENDIF
<KEY-A>
OP_ENDIF
OP_CHECKSIG
So if A has REVOKE-PREIMAGE he can claim the payment anytime.
If B has R he has to wait 7 days until he can claim the output (and
reveal R doing so..)
Furthermore, if he has R and wants to clear the payment, he has to act
within one day. He has to either settle the payment with the other
party or broadcast the channel within this time.
If he broadcasts the channel within one day, B can claim the output,
but A has to wait for full 7 days until he learns R. However, A might
not be the original sender, but just one of the nodes on the route,
and if A does not provide R to the node before him within 2 days (we
have 1 day per hop), he cannot pull the funds, although B can pull
his. This means all nodes along the route has to broadcast their
channel in order to not lose money.
In conclusion the payment-timeout and the revoke-time must be the same
in this channel design (which is inconvenient I think..). While the
payment-timeout should be as short as possible, a long revoke-time is
healthy in many instances.. 1 or maybe 2 days will probably be the
optimal trade-off then, although this can also be dangerously short in
case of full blocks..
Any thoughts?

2023-06-09 12:44:02

- reply

📅 Original date posted:2015-08-13
📝 Original message:
Ah nice,
Yea this is pretty much the same. :)
It seemed too trivial for me as well. I wonder why everyone thinks
that CLTV+CSV is the mandatory minimum we need for a full LN though.
Granted, it's not as much 'fun' as you put it, but it would work very
nice in most instances.
2015-08-13 22:06 GMT+02:00 Joseph Poon <joseph at lightning.network>:
> Hi Mats,
>
> Yes, I agree that this is a possibility.
>
> I had discussed this model of OP_CLTV without OP_CSV using a balance
> reserve on the mailing list, along with some caveats on the
> risks/effects of doing so.
>
> Message ID: 20150727193714.GA16768 at lightning.network
> Link:
> http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000070.html
>
> On Thu, Aug 13, 2015 at 08:37:18PM +0200, Mats Jerratsch wrote:
>> 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.
>
> I think very minor changes to the code would result in full lightning
> channels, as per Rusty's doc, yes. I think there will be huge benefits
> to Bitcoin if bitcoinj has an implementation ready when OP_CLTV/OP_CSV
> is implemented.
>
> --
> Joseph Poon

2023-06-09 12:44:01

- 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

- 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

- 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

- 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

- 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

- 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-09 12:43:42

- reply

📅 Original date posted:2015-07-20
📝 Original message:
Hey everybody,
I'm currently working on a Lightning Implementation Client/Server in
Java, building on bitcoinj (just as a basic framework, I wrote my own
classes to realize LN). Will push it into GitHub within a few weeks I
guess.
I had an implementation ready, that would not need any further changes
for bitcoin (works today already), but I just threw it all off the
ship, reading through your paper. It was based on some trust
dependencies and channel transactions were highly asynchronous,
meaning that a LN-Network would not be possible (since one party will
always be assumed lower trust and therefore has a disadvantage in
enforcing the ruleset). I can share further details if there is any
interest (it further needed to exchange 3 transactions for each
payment in the channel, building up huge amount of data within a few
hundred payments....)
First I wanted to write up my solution for the anchor problem, but
then I realized, your solution makes it possible to have channels open
indefinitely, while mine doesn't. And while it really looks fishy,
indefinite channels are really worth it. However, it is important to
wait for the anchor tx of the other party. Otherwise the server has to
pay transaction fees for releasing his funds again and again (which
can really add up..).
While implementing the new redeemscripts, I noticed there is no delay
for the 'HTLC Receiver Redeemscript', when redeeming the contract
using R. Doesn't this mean that revoked or not, if the receiver has R,
he can instantly claim these outputs. Let's assume a channel with 4
states:
t=t0 - client has no funds in the channel (or very little, he wants to
receive money)
t=t1 - client has received funds and has lots of unsettled payments in
his channel
t=t2 - client settled with the server (revealed R)
t=t3 - client has spent all funds again
At t=t3, the client has no incentive anymore to play with the rules,
since there's nothing he can lose (his balance is zero after all..).
So he can broadcast the channel transaction from t1 and instantly
claim all outputs using R. While the server can technically claim the
funds aswell, using the COMMIT-REVOCATION-HASH, it boils down to a
race. I'm not really sure if this will solve the issue completely, but
I think OP_CSV after OP_DROP will mitigate this by ensuring some
delay. This is especially important other way round, as clients won't
be online all the time and the delay here really determines how often
the client has to check back.
Really good work though, although I just had to delete and rewrite a
good share of my work. ;)

2023-06-07 18:07:38

- reply

📅 Original date posted:2017-11-14
📝 Original message:> 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 for both, post-fork for only one, and gets round the issue of who gets to decide the nForkid value.. since you don't need one. Also, all the old outputs work fine, and LN not an issue.
>
> I'm missing why this scheme would be better ?
I do agree that solutions like `SIGHASH_BLOCKCOMMIT` are superior in the sense that they are very difficult to circumvent. However, a fork could also follow the original chain in SPV mode and allow transactions protected with these mechanism. Since it's fundamentally impossible to disallow transactions in future projects, the goal shouldn't be to make this overly complicated.
Furthermore, this schema is not just adding replay protection. It makes transacting safer overall (due to a dedicated address format per fork) and allows light clients to differentiate between multiple forks. In the past three months, at least $600k has been lost by users sending BCH to a BTC address [1].
> Thanks for the clarification. How would a tx specify a constraint like "nForkId>=1"? I was thinking of it just as a number set on the tx.
Whether the transaction is replay protected or not is specified by setting a bit in the `SigHashId`. If this bit is set, then the signature *preimage* MUST have `nForkId` appended. `nForkId` is not part of the final transaction, someone who wants to verify the transaction must know which `nForkId` it was created with.
If the bit isn't set, it means `nForkId=0`, which allows other forks to validate the signature.
> Also note that since forks form a partial order, but IDs (numbers) form a total order, ">=" will miss some cases. Eg, suppose BCH had forked with nForkId 2, and then you set up a LN funding tx on BCH with nForkId>=2, and then Segwit2x forked (from BTC!) with nForkId 3. The BCH funding tx would be valid on Segwit2x. This is more of a fundamental problem than a bug - to avoid it you'd have to get into stuff like making each fork reference its parent-fork's first block or something, someone has written about this...
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 IFF `nForkId` matches exactly the `nForkId` of the software validating it. As described above, the transaction doesn't even contain `nForkId`, and the node surely is not starting to guess which one it could be.
[1]
https://twitter.com/khannib/status/930223617744437253 <https://twitter.com/khannib/status/930223617744437253>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171114/8a6b0269/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/20171114/8a6b0269/attachment.sig>

2023-06-07 18:07:37

- 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

- 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

- 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

- 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>

2023-06-07 17:49:09

- reply

📅 Original date posted:2016-02-29
📝 Original message: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
<bitcoin-dev at lists.linuxfoundation.org>:
> On Fri, Feb 12, 2016 at 5:02 AM, <jl2012 at xbt.hk> wrote:
>>
>> Seems it could be done without any new opcode:
>
>
> The assumption was that the altcoin would only accept standard output
> scripts. Alice's payment in step 2 pays to a non-standard script.
>
> This is an improvement over the cut and choose, but it will only work for
> coins which allow non-standard scripts (type 2 in the BIP).
>
> I guess I was to focused on maintaining standard scripts on the altcoin.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 17:45:18

- reply

📅 Original date posted:2015-11-27
📝 Original message: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 to make a payment to someone. In this context,
onion-routing means encrypting the data about subsequent hops in a way
that each node only knows where it received a payment from and the
direct next node it should send the payment to. This way we can route
a payment over N nodes, and none of these will know
(1) at which position it is within the route (first, middle, last?)
(2) which node initially issued the payment (payer)
(3) which node consumes the payment (payee).
However, given the way payments in LN work, each payment is uniquely
identifiable by a preimage-hash pair R-H. H is included in the output
script of the commit transaction, such that the payment is enforceable
if you ever get to know the preimage R.
In a payment network each node makes a promise to pay the next node,
if they can produce R. They can pass on the payment, as they know that
they can enforce the payment from a previous node using the same
preimage R. This severely damages privacy, as it lowers the amount of
nodes an attacker has to control to gain information about payer and
payee.
---
Problem:
The problem was inherited by using RIPEMD-160 for preimage-hash
construction. For any cryptographic hash-function it is fundamentally
unfeasible to correlate preimage and hash in such a way, that
F1(R1) = R2 and
F2(H1) = H2, while
SHA(R1) = H1 and SHA(R2) = H2.
In other words, I cannot give a node H1 and H2 and ask it to receive
my payment using H1, but pass it on using H2, as the node has no way
of verifying it can produce R1 out of the R2 it will receive. If it
cannot produce R1, it is unable to enforce my part of the contract.
---
Solution:
While above functions are merely impossible to construct for a
cryptographic hash functions, they are trivial when R and H is a EC
private/public key pair. The original sender can make a payment using
H1 and pass on a random number M1, such that the node can calculate a
new public key
H2 = H1 + M1.
When he later receives the private key R2, he can construct
R1 = R2 - M1
to be able to enforce the other payment. M1 can be passed on in the
onion object, such that each node can only see M for that hop.
Furthermore, it is unfeasible to brute-force, given a sufficiently
large number M.
---
Example:
Given that E wants to receive a payment from A, payable to H. (if A
can produce R, it can be used as a prove he made the payment and E
received it)
A decides to route the payment over the nodes B, C and D. A uses four
numbers M1...M4 to calculate H1...H4. The following payments then take
place
A->B using H4
B->C using H3
C->D using H2
D->E using H1.
When E receives H1, he can use attached M1 to calculate R1 from it.
The chain will resolve itself, and A is able to calculate R using
M1...M4. It also means that all privacy is at the sole discretion of
the sender, and that not even the original pair R/H is known to any of
the nodes.
To improve privacy, E could also be a rendezvous point chosen by the
real receiver of the payment, similar constructions are similar in
that direction as well.
---
Caveats:
Currently it is difficult to enforce a payment to a private-public key
pair on the blockchain. While there exists OP_HASH160 OP_EQUAL to
enforce a payment to a hash, the same does not hold true for EC keys.
To make above possible we would therefore need some easy way to force
a private key, given a public key. This could be done by using one of
the unused OP_NOP codes, which will verify
<private key> <public key> OP_CHECKPRIVPUBPAIR
and fails if these are not correlated or NOP otherwise. Would need
OP_2DROP afterwards. This would allow deployment using a softfork.
As there are requests for all sort of general crypto operations in
script, we can also introduce a new general OP_CRYPTO and prepend one
byte for the operation, so
0x01 OP_CRYPTO = OP_CHECKPRIVPUBPAIR
0x02-0xff OP_CRYPTO = OP_NOP
to allow for extension at some later point.
---
Alternatives:
In the attached discussion there are some constructions that would
allow breaking the signature scheme, but they are either very large in
script language or expensive to calculate. Given that the blocksize is
a difficult topic already, it would not be beneficial to have a 400B+
for each open payment in case one party breaches the contract. (or
just disappears for a couple of days)
It is also possible to use a NIZKP - more specifically SNARK - to
prove to one node that it is able to recover a preimage R1 = R2 XOR
M1, given only H1, H2 and M1. However, these are expensive to
calculate and experimental in it's current state.
---
Acknowledgements:
Gregory Maxwell for pointing out addition of M1 for EC points is much
less expensive
Pieter Wuille for helping with general understanding of EC math.
Anthony Towns for bringing up the issue and explaining SNARKs
[1]
http://lightning.network/