Christian Decker [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2011-06-13 to 2022-03-06
💬 Posted a total of 127 messages
📚 Participated in the following categories: Bitcoin-development, RFC, BIP 15, BIP, bitcoin-dev, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 13:05:03 UTC

- reply

📅 Original date posted:2022-01-19
📝 Original message:
Hi Will,
> I noticed you are doing RPC stuff... I'm looking to do RPC over
> lightning itself. I started a C library called lnsocket[1], scrounged
> from clightning parts, so that I can send messages from iOS to control
> my lightning node.
Sounds interesting, and similar to commando's goals. Rusty also has a
summer of bitcoin project attempting to expose a websocket directly to
browsers in order to provide another way to communicate with your node,
and of course there's commando.
> I've got to the point with lnsocket where I can send TLVs to my node,
> and now I'm starting to think about what format the RPC commands should
> be.
>
> I noticed the commando c-lightning plugin just uses the JSON-RPC
> payload, but perhaps something more compact and rpc-friendly like grpc
> would be better... which is why this cln-grpc PR peaked my curiosity.
Yep, JSON-RPC is rather bad with binary data, and doesn't have any
concept of streaming. I personally like grpc because it ticks a lot of
boxes: secure transport over TLS, mutual authentication via mTLS,
possibility to add metadata to calls (technically prohibited by the
JSON-RPC spec) which can help us use macaroons/runes in future,
streaming support and compact binary format.
Having an IDL to describe the interface is also rather nice, even though
for cln-grpc we actually generate that from the JSON-RPC schemas, so
it's a bit less expressive than .proto files.
> I think the end goal of an RPC bolt would be super powerful, so that
> lnsocket could talk to any lightning node, but that could be further
> down the line. Choosing the right data format seemed like an important
> step in that direction. Would love to hear your thoughts on this!
I agree. Exchanging the transport layer underneath grpc doesn't change
semantics, but does unlock a number of potential use-cases. I think
either the JSON-RPC or grpc can serve as a basis for a common RPC
definition that can have any number of bindings, since we generate
conversion code to/from JSON-RPC and grpc we can transparently map them
back and forth.
> I've cc'd clightning/lightning-dev as well to see if anyone else is
> working on this or thinking about this stuff right now.
Definitely open to suggestions, comments and criticism: the cln-grpc [1]
crate is rather new, and will see a number of rebases and fixups, but
should be reviewable as is. The cln-plugin [2] crate is a bit less
well-fleshed-out, but has the core functionality needed for
cln-grpc-plugin which was the goal of this first exploration. The
cln-rpc [4] crate is also missing many RPC commands, but that's just
grunt work that I plan to tackle separately :-)
Cheers,
Christian
[1] https://github.com/ElementsProject/lightning/pull/5011
[2] https://github.com/ElementsProject/lightning/pull/5012
[3] https://github.com/ElementsProject/lightning/pull/5013
[4] https://github.com/ElementsProject/lightning/pull/5010

2023-06-09 13:01:21 UTC

- reply

📅 Original date posted:2020-10-15
📝 Original message:
> And you don't get the benefit of the turn-taking approach, which is that
> you can have a known state for fee changes. Even if you change it to
> have opener always the leader, it still has to handle the case where
> incoming changes are not allowed under the new fee regime (and similar
> issues for other dynamic updates).
Good point, I hadn't considered that a change from one side might become
invalid due to a change from the other side. I think however this can only
affect changes that result in other changes no longer being applicable,
e.g., changing the number of HTLCs you'll allow on a channel making the
HTLC we just added and whose update_add is still in flight invalid.
I don't think fee changes are impacted here, since the non-leader only
applies the change to its commitment once it gets back its own change.
The leader will have inserted your update_add into its stream after the
fee update, and so you'll first apply the fee update, and then use the
correct fee to add the HTLC to your commitment, resulting in the same
state.
The remaining edgecases where changes can become invalid if they are in
flight, can be addressed by bouncing the change through the non-leader,
telling him that "hey, I'd like to propose this change, if you're good
with it send it back to me and I'll add it to my stream". This can be
seen as draining the queue of in-flight changes, however the non-leader
may pipeline its own changes after it and take the updated parameters
into consideration. Think of it as a two-phase commit, alerting the peer
with a proposal, before committing it by adding it to the stream. It
adds latency (about 1/2RTT over the token-passing approach since we can
emulate it with the token-passing approach) but these synchronization
points are rare and not on the critical path when forwarding payments.
>> The downside is that we add a constant overhead to one side's
>> operations, but since we pipeline changes, and are mostly synchronous
>> during the signing of the commitment tx today anyway, this comes out to
>> 1 RTT for each commitment.
>
> Yeah, it adds 1RTT to every hop on the network, vs my proposal which
> adds just over 1/2 RTT on average.
Doesn't that assume a change of turns while the HTLC was in-flight?
Adding and resolving an HTLC requires one change coming from either side
of the channel, implying that a turn change must have been performed,
which itself takes 1 RTT. Thus to add an remove an HTLC we add at least
1RTT for each hop.
With the leader-based approach, we add 1RTT latency to the updates from
one side, but the other never has to wait for the token, resulting in
1/2RTT per direction as well, since messages are well-balanced.
> Yes, but it alternates because that's optimal for a non-busy channel
> (since it's usually "Alice adds htlc, Bob completes the htlc").
What's bothering me more about the turn-based approach is that while the
token is in flight, neither endpoint can make any progress, since the
one reliquishing the token promised not to say anything and the other
one hasn't gotten the token yet. This might result in rather a lot of
dead-air if both sides have a constant stream of changes to add. So we'd
likely have to add a timeout to defer giving up the token, to counter
dead-air, further adding delay to the changes from the other end, and
adding yet another parameter.
This is in stark contrast to the leader-based approach, where both
parties can just keep queuing updates without silent times to
transferring the token from one end to the other.
Cheers,
Christian

2023-06-09 13:01:20 UTC

- reply

📅 Original date posted:2020-10-13
📝 Original message:
I wonder if we should just go the tried-and-tested leader-based
mechanism:
1. The node with the lexicographically lower node_id is determined to
be the leader.
2. The leader receives proposals for changes from itself and the peer
and orders them into a logical sequence of changes
3. The leader applies the changes locally and streams them to the peer.
4. Either node can initiate a commitment by proposing a `flush` change.
5. Upon receiving a `flush` the nodes compute the commitment
transaction and exchange signatures.
This is similar to your proposal, but does away with turn changes (it's
always the leader's turn), and therefore reduces the state we need to
keep track of (and re-negotiate on reconnect).
The downside is that we add a constant overhead to one side's
operations, but since we pipeline changes, and are mostly synchronous
during the signing of the commitment tx today anyway, this comes out to
1 RTT for each commitment.
On the other hand a token-passing approach (which I think is what you
propose) require a synchronous token handover whenever a the direction
of the updates changes. This is assuming I didn't misunderstand the turn
mechanics of your proposal :-)
Cheers,
Christian
Rusty Russell <rusty at rustcorp.com.au> writes:
> Hi all,
>
> Our HTLC state machine is optimal, but complex[1]; the Lightning
> Labs team recently did some excellent work finding another place the spec
> is insufficient[2]. Also, the suggestion for more dynamic changes makes it
> more difficult, usually requiring forced quiescence.
>
> The following protocol returns to my earlier thoughts, with cost of
> latency in some cases.
>
> 1. The protocol is half-duplex, with each side taking turns; opener first.
> 2. It's still the same form, but it's always one-direction so both sides
> stay in sync.
> update+-> commitsig-> <-revocation <-commitsig revocation->
> 3. A new message pair "turn_request" and "turn_reply" let you request
> when it's not your turn.
> 4. If you get an update in reply to your turn_request, you lost the race
> and have to defer your own updates until after peer is finished.
> 5. On reconnect, you send two flags: send-in-progress (if you have
> sent the initial commitsig but not the final revocation) and
> receive-in-progress (if you have received the initial commitsig
> not not received the final revocation). If either is set,
> the sender (as indicated by the flags) retransmits the entire
> sequence.
> Otherwise, (arbitrarily) opener goes first again.
>
> Pros:
> 1. Way simpler. There is only ever one pair of commitment txs for any
> given commitment index.
> 2. Fee changes are now deterministic. No worrying about the case where
> the peer's changes are also in flight.
> 3. Dynamic changes can probably happen more simply, since we always
> negotiate both sides at once.
>
> Cons:
> 1. If it's not your turn, it adds 1 RTT latency.
>
> Unchanged:
> 1. Database accesses are unchanged; you need to commit when you send or
> receive a commitsig.
> 2. You can use the same state machine as before, but one day (when
> this would be compulsory) you'll be able signficantly simplify;
> you'll need to record the index at which HTLCs were changed
> (added/removed) in case peer wants you to rexmit though.
>
> Cheers,
> Rusty.
>
> [1] This is my fault; I was persuaded early on that optimality was more
> important than simplicity in a classic nerd-snipe.
> [2] https://github.com/lightningnetwork/lightning-rfc/issues/794
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 12:57:33 UTC

- reply

📅 Original date posted:2019-12-04
📝 Original message:
That is correct, the chain of noinput/anyprevout transactions is broken
as soon as the signers are online and can interactively bind and sign
without noinput/anyprevout.
Conner Fromknecht <conner at lightning.engineering> writes:
> Good evening,
>
>> I didn't think this was the design. The update transaction can spend any
> prior, with a fixed script, due to NOINPUT.
>
> From my reading of the final construction, each update transaction has a
> unique script to bind settlement transactions to exactly one update.
>
>> My understanding is that this is not logically possible?
> The update transaction has no fixed txid until it commits to a particular
> output-to-be-spent, which is either the funding/kickoff txout, or a
> lower-`nLockTime` update transaction output.
>> Thus a settlement transaction *must* use `NOINPUT` as well, as it has no
> txid it can spend, if it is constrained to spend a particular update
> transaction.
>
> This is also my understanding. Any presigned descendants of a NOINPUT txn
> must also use NOINPUT as well. This chain must continue until a signer is
> online to bind a txn to a confirmed input. The unique settlement keys thus
> prevent rebinding of settlement txns since NOINPUT with a shared script
> would be too liberal.
>
> Cheers,
> Conner
>
> On Mon, Dec 2, 2019 at 18:55 ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
>> Good morning Rusty,
>>
>> > > Hi all,
>> > > I recently revisited the eltoo paper and noticed some things related
>> > > watchtowers that might affect channel construction.
>> > > Due to NOINPUT, any update transaction can spend from any other, so
>> > > in theory the tower only needs the most recent update txn to resolve
>> > > any dispute.
>> > > In order to spend, however, the tower must also produce a witness
>> > > script which when hashed matches the witness program of the input. To
>> > > ensure settlement txns can only spend from exactly one update txn,
>> > > each update txn uses unique keys for the settlement clause, meaning
>> > > that each state has a unique witness program.
>> >
>> > I didn't think this was the design. The update transaction can spend
>> > any prior, with a fixed script, due to NOINPUT.
>> >
>> > The settlement transaction does not use NOINPUT, and thus can only
>> > spend the matching update.
>>
>> My understanding is that this is not logically possible?
>> The update transaction has no fixed txid until it commits to a particular
>> output-to-be-spent, which is either the funding/kickoff txout, or a
>> lower-`nLockTime` update transaction output.
>> Thus a settlement transaction *must* use `NOINPUT` as well, as it has no
>> txid it can spend, if it is constrained to spend a particular update
>> transaction.
>>
>> Unless I misunderstand how update transactions work, or what settlement
>> transactions are.
>>
>> Regards,
>> ZmnSCPxj
>>
> --
> —Sent from my Spaceship
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 12:52:43 UTC

- reply

📅 Original date posted:2018-11-15
📝 Original message:
I'm not sure this is an improvement at all over just allowing a single
merge-point, i.e., the destination. You see as long as we don't attempt
intermediate merges the routes are independent and failures of one HTLC
do not impact any other parts. Take for example the network below:
--------
/ \
A----B-----C-----D
\ /
-------E-------
For simplicity let's assume unit capacities on all channels except C-D
and a total payment of 2 from A to D.
If we use C as a merge point for the two partial payments A-C-D and
A-B-C-D, then C can only forward if both partial payment succeed, i.e.,
if for example A-C fails then we'll need to tear down the HTLCs for both
paths because it'll no longer be possible to find an alternative route
to fulfill the forwarding of 2 over C-D.
If however we have two independent routes A-B-C-D and A-C-D, then A-C-D
can fail independently and we can recover by attempting A-E-D, no need
to touch A-B-C-D at all.
Overall it seems we get very little benefit (we save some HTLC setups
and teardown) for a lot of added complexity. In the above case we would
have saved on a single C-D HTLC, and the cost of doing so is many times
larger (2 HTLCs needed to be torn down because we could no longer pass
enough capacity to C in order for it to reach the forward threshold).
Let's please stick with the simple mechanism of having the recipient be
the only merge point.
Cheers,
Christian
ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org>
writes:
> Good morning list,
>
> I propose the below to support Base AMP.
>
> The below would allow arbitrary merges of paths, but not arbitrary splits. I am uncertain about the safety of arbitrary splits.
>
> ### The `multipath_merge_per_hop` type (`option_base_amp`)
>
> This indicates that payment has been split by the sender using Base AMP, and that the receiver should wait for the total intended payment before forwarding or claiming the payment.
> In case the receiving node is not the last node in the path, then succeeding hops MUST be the same across all splits.
>
> 1. type: 1 (`termination_per_hop`)
> 2. data:
> * [`8` : `short_channel_id`]
> * [`8` : `amt_to_forward`]
> * [`4` : `outgoing_cltv_value`]
> * [`8` : `intended_total_payment`]
> * [`4` : `zeros`]
>
> The contents of this hop will be the same across all paths of the Base AMP.
> The `payment_hash` of the incoming HTLCs will also be the same across all paths of the Base AMP.
>
> `intended_total_payment` is the total amount of money that this node should expect to receive in all incoming paths to the same `payment_hash`.
>
> This may be the last hop of a payment onion, in which case the `HMAC` for this hop will be `0` (the same rule as for `per_hop_type` 0).
>
> The receiver:
>
> * MUST impose a reasonable timeout for waiting to receive all component paths, and fail all incoming HTLC offers for the `payment_hash` if they have not totalled equal to `intended_total_payment`.
> * MUST NOT forward (if an intermediate node) or claim (if the final node) unless it has received a total greater or equal to `intended_total_payment` in all incoming HTLCs for the same `payment_hash`.
>
> The sender:
>
> * MUST use the same `payment_hash` for all paths of a single multipath payment.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 12:49:29 UTC

- reply

📅 Original date posted:2018-03-13
📝 Original message:
Hi René,
very good question. I think the simple answer is that this is exactly
the reason why not having a participant in the network that can 51%
attack over a prolonged period is one of the base assumptions in
Lightning. These attacks are deadly to all blockchains, and we are
certainly no different in that regard.
More interesting is the assertion that this may indeed be more dangerous
than a classical 51% attack, in which an attacker can only doublespend
funds that she had control over at some point during the attack
(duration being defined as the period she can build a hidden fork of). I
think the case for Lightning is not more dangerous since what they could
do is enforce an old state in which they had a higher balance than in
the final state, without incurring in a penalty. The key observation is
that in this old state they actually had to have the balance they are
stealing on the channel. So this maps directly to the classical
scenario in which an attacker simply doublespends funds they had control
over during the attack, making the attack pretty much the same.
Another interesting observation is that with Lightning the state that
the attacker is enforcing may predate the attack, e.g., an attacker
could use a state that existed and was replaced before it started
generating its fork. This is in contrast to the classical doublespend
attack in which invalidated spends have to happen after the fork
started, and the attacker just filters them from its fork.
But as I said before, if we can't count on there not being a 51%
attacker, then things are pretty much broken anyway :-)
Cheers,
Christian
René Pickhardt via Lightning-dev
<lightning-dev at lists.linuxfoundation.org> writes:
> Hey everyone,
>
> disclaimer: as mentioned in my other mail (
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-March/001065.html
> ) I am currently studying the revocation system of duplex micropayment
> channels in detail but I am also pretty new to the topic. So I hope the
> attack I am about to describe is not possible and it is just me overseeing
> some detail or rather my lack of understanding.
> That being said even after waiting one week upon discovery and double
> checking the assumptions I made I am still positive that the revocation
> system in its current form allows for a new form of a 51% attack. This
> attack seems to be way more harmful than a successful 51% attack on the
> bitcoin network. Afaik within the bitcoin network I could 'only double
> spend' my own funds with a successful 51% attack. In the lightning case it
> seems that an attacker could steal an arbitrary amount of funds as long as
> the attacker has enough payment channels with enough balance open.
>
> The attack itself follows exactly the philosophy of lightning: "If a tree
> falls in the forest and no one is around to hear it. Does it make a sound?"
> In the context of the attack this would translate to: "If a 51% attacker
> secretly mines enough blocks after fraudulently spending old commitment
> transactions and no one sees it during the the *to_self_delay* period,
> have the commitment transactions been spent? (How) Can they be revoked?"
>
>
> As for the technical details I quote from the spec of BOLT 3:
> "*To allow an opportunity for penalty transactions, in case of a revoked
> commitment transaction, all outputs that return funds to the owner of the
> commitment transaction (a.k.a. the "local node") must be delayed for *
> *to_self_delay** blocks. This delay is done in a second-stage HTLC
> transaction (HTLC-success for HTLCs accepted by the local node,
> HTLC-timeout for HTLCs offered by the local node)*"
>
> Assume an attacker has 51% of the hash power she could open several
> lightning channels and in particular accept any incoming payment channel
> (the more balance is in her channels the more lucrative the 51% attack).
> Since the attacker already has a lot of hash power it is reasonable (but
> not necessary) to assume that the attacker already has a lot of bitcoins
> and is well known to honest nodes in the network which makes it even more
> likely to have many open channels.
>
> The attacker keeps track of her (revocable) commitment transactions in
> which the balance is mostly on the attackers side. Once the attacker knows
> enough of these (old) commitment transactions the attack is being executed
> in the following way:
> 0.) The max value of to_self_delay is evaluated. Let us assume it is 72
> blocks (or half a day).
> 1.) The attacker secretly starts mining on her own but does not broadcasts
> any successfully mined block. Since the attacker has 51% of the hash power
> she will most likely be faster than the network to mine the 72 blocks of
> the safety period in which fraudulent commitment transactions could be
> revoked.
> 2.) The attacker spends all the fraudulent (old) commitment transactions in
> the first block of her secrete mining endeavor.
> 3.) Meanwhile the attacker starts spending her own funds of her payment
> channels e.g on decentralized exchanges for any other (crypto)currency.
> 4.) As soon as the attacker has mined enough blocks that the commitment
> transactions cannot be revoked she broadcasts her secretly minded
> blockchain which will be accepted by the network as it is the longest
> chain. (In Particular she includes all the other bitcoin transactions that
> are also in the original public blockchain so that other people don't even
> realize something suspicious has happened.)
>
> Since according to the spec channels should never be balanced worse than
> 99% to 1% the attacker could steal up to 99% of all the bitcoins allocated
> in the sum of all payment channels the attacker was connected to. This
> amount could obviously be way higher than just double spending her own
> funds. This attack would be interesting in particular for the power nodes
> created by the Barabasi-Albert model of lnd's autopilot (c.f.:
> https://github.com/lightningnetwork/lnd/issues/677 ).
>
> I understand that with the growth of the bitcoin (mining) network a 51%
> attack becomes less and less likely. Also I am very happy to be proven
> false about the attack that I am describing.
>
> Another sad thing about this attack is that I currently do not see any
> (reasonable) way of preventing this form of a 51% attack (other than
> creating payment channels that don't offer the possibility of revocation)
> as it is abusing exactly the core idea of lightning to do something in
> secret without broadcasting it.
>
> Best regards Rene
>
> ---
>
> http://www.rene-pickhardt.de
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev