[Lightning-dev] The Raspberry Standard for Bitcoin
hello community - I wanted to discuss a standard we as open source community should try to follow. I call it the Raspberry Standard for Bitcoin. Which essentially means Bitcoin and bitcoin applications should be light and optimized enough that they can run on a raspberry pi. I discuss it here in detail in a blog post: https://blog.parmu.town/the-raspberry-standard-for-bitcoin/ Your views are appreciated. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [RFC] Lightning gossip alternative
Joost Jager writes:
> Hi Rusty,
>
> Nice to see the proposal in more concrete terms. Few questions:
>
> - The total proved utxo value (not counting any utxos which are spent)
>> is multiplied by 10 to give the "announcable_channel_capacity" for that
>> node.
>>
>
> Could this work as a dynamic value too, similar to the minimum relay fee on
> L1?
I made the number up, so I'm not very attached to it. How would we
choose to scale it though? If nodes don't use the same value it makes
for wasted gossip (and minisketch-based gossip much harder).
>> 1. `tlv_stream`: `channel_update_v2_tlvs`
>>
> 2. types:
>> 1. type: 4 (`capacity`)
>> 2. data:
>> * [`tu64`:`satoshis`]
>>
>
> What does capacity mean exactly outside the context of a real channel? Will
> this be reduced to that maximum htlc amount that the nodes want to route,
> to save as much of the announceable budget as possible?
Yes, it's the old htlc_maximum_msat, but expressed in satoshis because
msat seems to finegrained?
> It is also the question of whether 10 x 10k channels should weigh as much
> on the budget as a 1 x 100k channel. A spammer may be able to do more harm
> with multiple smaller channels because there is more for the sender's
> pathfinding algorithms to explore. Maybe it doesn't matter as long as there
> is some mechanism to discourage spam.
Yes, I suggested a minimum cost to avoid 100k 1sat channels, I don't
know if we should be more sophisticated.
>> 1. type: 5 (`cost`)
>> 2. data:
>>* [`u16`:`cltv_expiry_delta`]
>>* [`u32`:`fee_proportional_millionths`]
>>* [`tu32`:`fee_base_msat`]
>> 1. type: 6 (`min_msat`)
>> 2. data:
>> * [`tu64`:`min_htlc_sats`]
>>
>> - `channel_id_and_claimant` is a 31-bit per-node channel_id which can be
>> used in onion_messages, and a one bit stolen for the `claim` flag.
>
> If you'd increase the budget multiplier from 10 to 20, couldn't this be
> simplified to always applying the cost to both nodes?
Yes! I forgot that capacity doesn't have to be symmetrical; if I open a
giant channel with you, and you don't want to expose more UTXOs, you
just set your capacity to some lower value.
>> - A channel is not considered to exist until both peers have sent a
>> channel_update_v2, at least one of which must set the `claim` flag.
>> - If a node sets `claim`, the capacity of the channel is subtracted from
>> the remaining announcable_channel_capacity for that node (minimum
>> 10,000 sats).
>
> Same question about magic value and whether it can be dynamic.
Yes, 10ksat might be giant one day? We can change it naively with a
feature bit ("I use v2 capacity calcs"), or in some more finegrained
way, but what do we base it on?
Cheers!
Rusty.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Normal operation questions
Hi Benjamin, > 1) Multiple sources indicate that after Alice sends the `update_add_htlc`, > she should then send the `commitment_signed`, but why is it important that > she sends it first (before Bob)? As far as I understand, as long as she > doesn't revoke the old state before Bob commits to the new state, there > shouldn't be a problem. In that case, the order wouldn't matter---they could > even send their commitments concurrently. So does the order matter? You're correct that it isn't absolutely necessary that she sends a new signature after adding a new HTLC to the pending set of HTLCs. Alice may want to delay her signature if she has other HTLCs she wants to add to the commitment transaction, which allows her to batch/pipeline updates to the channel. If Alice is forwarding that HTLC, and Bob's side of the channel has been dormant (not making many updates), then it's her best interest to propose a new state immediately as she may generate some routing fees from a successful forward. Concurrent signatures aren't an issue, but will end up generating additional state transitions for both sides to have the exact same set of locked in HTLCs. > 2) After Bob sends the `update_fulfill_htlc`, both he and Alice exchange > `commitment_signed` and `revoke_and_ack` messages again. Why is this > necessary? After Alice receives the preimage, doesn't she have enough > information to claim her funds (with the new state)? If Bob is sending the pre-image, then _he_ is the one that is claiming the funds. Once Bob learns of the pre-image, he can go to chain if he wants to in order to claim the HTLC. However that'll be a lot slower and also cost more in chain fees than doing an update off-chain to settle the HTLC from the PoV of the commitment transaction of both parties. Both sides exchange those messages in order to update their commitment state _off chain_. Once Alice receives the pre-image (assuming a multi-hop scenario), she can opt to not wait for the full exchange, and instead _pipeline_ the pre-image back upstream in the route. In practice, this can reduce perceived user latency for payments, as you can side step the 1.5 RTTs at each hop in the route, and simply sling the pre-image all the way back to the original sender. -- Laolu On Tue, Feb 15, 2022 at 7:32 AM Benjamin Weintraub < weintrau...@northeastern.edu> wrote: > Hi all, > > I have a couple questions about the Normal Operation protocol. For the > following, consider a single-hop payment between Alice and Bob over a > single channel. > > 1) Multiple sources indicate that after Alice sends the `update_add_htlc`, > she should then send the `commitment_signed`, but why is it important that > she sends it first (before Bob)? As far as I understand, as long as she > doesn't revoke the old state before Bob commits to the new state, there > shouldn't be a problem. In that case, the order wouldn't matter---they > could even send their commitments concurrently. So does the order matter? > > 2) After Bob sends the `update_fulfill_htlc`, both he and Alice exchange > `commitment_signed` and `revoke_and_ack` messages again. Why is this > necessary? After Alice receives the preimage, doesn't she have enough > information to claim her funds (with the new state)? > > > Thanks! > Ben > > -- > Ben Weintraub > PhD Student > Khoury College of Computer Sciences > Northeastern University > https://ben-weintraub.com/ > > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Normal operation questions
Hi all, I have a couple questions about the Normal Operation protocol. For the following, consider a single-hop payment between Alice and Bob over a single channel. 1) Multiple sources indicate that after Alice sends the `update_add_htlc`, she should then send the `commitment_signed`, but why is it important that she sends it first (before Bob)? As far as I understand, as long as she doesn't revoke the old state before Bob commits to the new state, there shouldn't be a problem. In that case, the order wouldn't matter---they could even send their commitments concurrently. So does the order matter? 2) After Bob sends the `update_fulfill_htlc`, both he and Alice exchange `commitment_signed` and `revoke_and_ack` messages again. Why is this necessary? After Alice receives the preimage, doesn't she have enough information to claim her funds (with the new state)? Thanks! Ben -- Ben Weintraub PhD Student Khoury College of Computer Sciences Northeastern University https://ben-weintraub.com/ ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [RFC] Lightning gossip alternative
Hi Rusty, Nice to see the proposal in more concrete terms. Few questions: - The total proved utxo value (not counting any utxos which are spent) > is multiplied by 10 to give the "announcable_channel_capacity" for that > node. > Could this work as a dynamic value too, similar to the minimum relay fee on L1? > 1. `tlv_stream`: `channel_update_v2_tlvs` > 2. types: > 1. type: 4 (`capacity`) > 2. data: > * [`tu64`:`satoshis`] > What does capacity mean exactly outside the context of a real channel? Will this be reduced to that maximum htlc amount that the nodes want to route, to save as much of the announceable budget as possible? It is also the question of whether 10 x 10k channels should weigh as much on the budget as a 1 x 100k channel. A spammer may be able to do more harm with multiple smaller channels because there is more for the sender's pathfinding algorithms to explore. Maybe it doesn't matter as long as there is some mechanism to discourage spam. > 1. type: 5 (`cost`) > 2. data: >* [`u16`:`cltv_expiry_delta`] >* [`u32`:`fee_proportional_millionths`] >* [`tu32`:`fee_base_msat`] > 1. type: 6 (`min_msat`) > 2. data: > * [`tu64`:`min_htlc_sats`] > > - `channel_id_and_claimant` is a 31-bit per-node channel_id which can be > used in onion_messages, and a one bit stolen for the `claim` flag. > If you'd increase the budget multiplier from 10 to 20, couldn't this be simplified to always applying the cost to both nodes? > - A channel is not considered to exist until both peers have sent a > channel_update_v2, at least one of which must set the `claim` flag. > - If a node sets `claim`, the capacity of the channel is subtracted from > the remaining announcable_channel_capacity for that node (minimum > 10,000 sats). > Same question about magic value and whether it can be dynamic. Joost ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] [RFC] Lightning gossip alternative
Hi all, I've floated this idea before, but this is a more concrete proposal for a "v2" gossip protocol. It assumes x-only pubkeys (aka point32) and BIP-340 signatures, and uses modern TLVs for all optional or extensible fields. Timestamps are replaced with block heights. 1. Nodes send out weekly node_announcement_v2, proving they own some UTXOs. 2. This entitles them to broadcast channels, using channel_update_v2; a channel_update_v2 from both peers means the channel exists. 3. This uses UTXOs for anti-spam, but doesn't tie them to channels directly. 4. Future ZKP proofs are could be added. 1. type: 271 (`node_announcement_v2`) 2. data: * [`bip340sig`:`signature`] * [`point32`:`node_id`] * [`u32`:`blockheight`] * [`node_announcement_v2_tlvs`:`tlvs`] 1. `tlv_stream`: `node_announcement_v2_tlvs` 2. types: 1. type: 2 (`features`) 2. data: * [`...*byte`:`featurebits`] 1. type: 3 (`chain_hash`) 2. data: * [`chain_hash`:`chain`] 1. type: 4 (`taproot_utxo_proofs`) 2. data: * [`...*taproot_utxo_proof`:`proofs`] 1. type: 6 (`legacy_utxo_proofs`) 2. data: * [`...*legacy_utxo_proof`:`proofs`] 1. type: 127 (`ipv4_addresses`) 2. data: * [`...*ipv4`:`addresses`] 1. type: 129 (`ipv6_addresses`) 2. data: * [`...*ipv6`:`addresses`] 1. type: 131 (`torv3_addresses`) 2. data: * [`...*torv3`:`addr`] # Maybe alias, color, etc? Taproot proofs are a signature of the v1 output over the `node_id`, `utxo` and `blockheight` with prefix "lightingtaproot_utxo_proofsig" (using the tagged signatures as per BOLT12). (FIXME: what about tapscripts?). Legacy proofs are two signatures, similar to the existing channel_announcement. 1. subtype: `taproot_utxo_proof` 2. data: * [`short_channel_id`:`utxo`] * [`signature`:`sig`] 1. subtype: `legacy_utxo_proof` 2. data: * [`short_channel_id`:`utxo`] * [`point`:`bitcoin_key_1`] * [`point`:`bitcoin_key_2`] * [`signature`:`sig_1`] * [`signature`:`sig_2`] - node_announcement_v2 are discarded after a week (1000 blocks). - If two node_announcement_v2 claim the same UTXO, use the first seen, discard any others. - Nodes do not need to monitor existence of UTXOs after initial check (since they will automatically prune them after a week). - The total proved utxo value (not counting any utxos which are spent) is multiplied by 10 to give the "announcable_channel_capacity" for that node. 1. type: 273 (`channel_update_v2`) 2. data: * [`bip340sig`:`signature`] * [`point32`:`local_node_id`] * [`point32`:`remote_node_id`] * [`u32`:`blockheight`] * [`u32`:`channel_id_and_claimant`] * [`channel_update_v2_tlvs`:`tlvs`] 1. `tlv_stream`: `channel_update_v2_tlvs` 2. types: 1. type: 2 (`features`) 2. data: * [`...*byte`:`featurebits`] 1. type: 3 (`chain_hash`) 2. data: * [`chain_hash`:`chain`] 1. type: 4 (`capacity`) 2. data: * [`tu64`:`satoshis`] 1. type: 5 (`cost`) 2. data: * [`u16`:`cltv_expiry_delta`] * [`u32`:`fee_proportional_millionths`] * [`tu32`:`fee_base_msat`] 1. type: 6 (`min_msat`) 2. data: * [`tu64`:`min_htlc_sats`] - `channel_id_and_claimant` is a 31-bit per-node channel_id which can be used in onion_messages, and a one bit stolen for the `claim` flag. - A channel is not considered to exist until both peers have sent a channel_update_v2, at least one of which must set the `claim` flag. - If a node sets `claim`, the capacity of the channel is subtracted from the remaining announcable_channel_capacity for that node (minimum 10,000 sats). - If there is insufficient total `announcable_channel_capacity` for a node, it is used by the lower `channel_id`s first. Implications This simplifies gossip, requiring only two messages instead of three, and reducing the UTXO validation requirements to per-node instead of per-channel. We can use a convention that a channel_update_v2 with no `capacity` is a permanent close. We might want to add a taproot_utxo_delegated_proof where UTXOs can sign over to another key, so cold storage only needs to sign once, and the other key can sign weekly. It also allows "leasing" of UTXOs: you could pay someone to sign their UTXO for your node_announcement, with some level of trust. They could spend the UTXO, which gives you a slow degredation as new nodes don't accept your channels but existing nodes don't check until it's due for a refresh). Or they could sign one UTXO for multiple node_announcements, which is why preference is given to the first-seen. But it's a weekly business so there's incentive for them not to. Between nodes there's the question of "who claims this new channel?", which I didn't address here. Opener claims is logical, but leaks information (though you could definitely pay for the peer to claim it). With dual-funding, it's more
