<unnamed>

Public Key

npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx

Profile Code

nprofile1qqsp80vvr30rkdgg5p7fykvxgutqkydtphh0f3zjpx8zy0jy8sw2gfgpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds3v4zuq

Publishing to

relay.damus.io

nos.lol

Last Notes

2023-07-10 21:01:44 CEST

- reply

📅 Original date posted:2023-07-06
🗒️ Summary of this message: LNbits discovered an exploit that allowed attackers to create fake balances by manipulating invoices, urging users to update their software.
📝 Original message:
Um, this is a super-weird setup AFAICT.
You generate an invoice, but you don't remember anything about it? Um,
OK, stateless invoices are a thing, but there's a metadata field for
that?
Someone pays an invoice, you don't check the place it's going (which,
y'know, signed it), you check some other field?
I've never used lnbits and I'm clearly missing something...
Thanks!
Rusty.
callebtc via Lightning-dev <lightning-dev at lists.linuxfoundation.org>
writes:
> Dear list,
>
> earlier last month, our team at LNbits discovered a rather interesting exploit which wich would enable an attacker to create balances out of thin air by abusing a quirk in how invoices are handled internally. We've patched this in LNbits version 0.10.5 and urge anyone to update ASAP if you haven't done so already. I want to describe the attack here, since my gut feeling is that carrying out the same exploit is possible in other Lightning applications. If you're working on custodial wallets, payment processors, account management software, etc. you probably want to read this.
>
> In short, the attacker was able to insert a bolt-11 payment hash of payment A into a different payment, creating a malicious invoice B that can trick the backend into believing that B == A.
>
> Here is how it goes:
>
> - Attacker creates invoice A of amount 1000 sat in LNbits
> - Attacker creates invoice B' of amount 1 sat on her own node
> - Attacker deserializes B', inserts payment_hash(A) into payment_hash(B), re-signs the invoice, and serializes it again, producing malicious invoice B
> - Attacker creates a new account in LNbits and pays B
>
> - LNbits backend uses payment_hash(B) to check whether this is an internal payment or a payment via LN
> - Backend finds A in its database since we implicitly assume that payment_hash(A) commits to A
>
> ** This is the critical part! Payment hashes do *NOT* commit to any payment details (like amount) but only to the preimage! **
>
> - Backend settles payment internally by crediting A debiting B
> - Attacker has "created" 999 sats
>
> Mitigation:
>
> The mitigation is quite simple. Backends should either use self-generated unique "checking id's" for looking up internal payments or use additional checks to make sure that the invoice details have not been messed around with (e.g., asserting amount(A) == amount(B)).
>
> Lessons:
>
> I think there are two lessons here. First, it's good to realize the level of sophistication of LN-savvy attackers. This attack clearly involves a fundamental understanding of bolt-11 and requires custom tooling to produce the malicious invoice.
>
> The second lesson is more valuable: The "payment hash" of an invoice is not a "payment" hash but merely a "preimage" hash – and nothing else. Naming this field as such increases the chance of developers implicitly assuming that the hash commits to payment details like amount, pubkey, etc. I will from now on call this simply the "preimage hash" and invite you to do so too.
>
> Best
>
> Calle
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 15:05:55 CEST

- reply

📅 Original date posted:2022-04-27
📝 Original message:
Matt Corallo <lf-lists at mattcorallo.com> writes:
>> This same problem will occur if *anyone* does ratelimiting, unless
>> *everyone* does. And with minisketch, there's a good reason to do so.
>
> None of this seems like a good argument for *not* taking the "send updates since the last sync in
> the minisketch" approach to reduce the damage inconsistent policies
> cause, though?
You can't do this, with minisketch. You end up having to keep all the
ratelimited differences you're ignoring *per peer*, and then cancelling
them out of the minisketch on every receive or send.
So you end up doing that LND and core-lightning do, which is "pick 3
peers to gossip with" and tell everyone else to shut up.
Yet the point of minisketch is robustness; you can (at cost of 1 message
per minute) keep in sync with an arbitrary number of peers.
So, we might as well define a preferred ratelimit, so nodes know that
spamming past a certain point is not going to propagate. At the moment,
LND has no effective ratelimit at all, so it's a race to the bottom.
We need that limit eventually, this just makes it more of a priority.
> I'm not really
> sure in a world where you do "update-based-sketch" gossip sync you're any worse off than today even
> with different rate-limit policies, though I obviously agree there are substantial issues with the
> massively inconsistent rate-limit policies we see today.
You can't really do it, since rate-limited junk overwhelms the sketch
really fast :(
Note, we *can* actually change the ratelimit in future, either by
running two sketches (feature bit!), or by changing the rate slowly
enough that they can handle the small differences.
Cheers,
Rusty.

2023-06-09 15:05:19 CEST

- reply

📅 Original date posted:2022-02-16
📝 Original message:
Joost Jager <joost.jager at gmail.com> 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.

2023-06-09 15:05:03 CEST

- reply

📅 Original date posted:2022-01-24
📝 Original message:
Christian Decker <decker.christian at gmail.com> writes:
>> 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.
The rest is true, but spec doesn't disallow extra fields that I can
find?
> 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.
Yeah, I don't think we'll end up with a control standard. But I've been
pleasantly surprised before: certainly a common subset would be nice!
Cheers!
Rusty.

2023-06-09 15:03:22 CEST

- reply

📅 Original date posted:2021-08-12
📝 Original message:
Sorry this took so long.
https://github.com/lightningnetwork/lightning-rfc/pull/895
This changed quite a bit, based on discussion here and more coherent
thinking.
1. You can simply send funding_locked early, no feature needed.
2. It's a bit useless unless you are the (sole) funder or you trust the
other side. Without that, you can neither accept payments nor route
them; in theory if they used push_msat you could send payments out,
but that seems a niche case.
3. We do want to know the short_channel_id they're going to use for the
channel, so we can add it to routehints for incoming payments.
Adding the scid is nice anyway, for chainsplit scenarios.
Here is the new text, a little formatted:
1. `tlv_stream`: `funding_locked_tlvs`
2. types:
1. type: 1 (`short_channel_id`)
2. data:
* [`short_channel_id`:`short_channel_id`]
#### Requirements
The sender:
...
- SHOULD set `short_channel_id`
- if it is the sole contributor to the funding transaction, or
has reason to trust the peer:
- MAY send `funding_locked` before the funding transaction
has reached `minimum_depth`
- MAY set `short_channel_id` to a fake value, if it will
route payments to that `short_channel_id`.
- otherwise:
- MUST wait until the funding transaction has reached
`minimum_depth` before sending this message.
- SHOULD re-transmit `funding_locked` if the
`short_channel_id` for this chanel has changed.
...
The receiver:
- SHOULD ignore the `funding_locked` if it knows the
`short_channel_id` of the channel and it differs from the
value in `funding_locked`.
...
Nodes which have funded the channel or trust their peers to have done,
can simply start using the channel instantly by sending
`funding_locked`. This raises the problem of how to use this new
channel in route hints, since it does not yet have a block number.
For this reason, a convincing fake number can be use; when the real
funding transaction is finally mined, it can re-send `funding_locked`
with the real value.

2023-06-09 15:02:46 CEST

- reply

📅 Original date posted:2021-06-29
📝 Original message:
Bastien TEINTURIER <bastien at acinq.fr> writes:
> Hi Rusty,
>
> On the eclair side, we instead send `funding_locked` as soon as we
> see the funding tx in the mempool.
>
> But I think your proposal would work as well.
This would be backward compatible, I think. Eclair would send
`funding_locked`, which is perfectly legal, but a normal peer would
still wait for confirms before also sending `funding_locked`; it's
just that option_zeroconf_channels would mean it doesn't have to
wait for that before sending HTLCs?
> We may want to defer sending `announcement_signatures` until
> after the funding tx has been confirmed? What `min_depth` should
> we use here? Should we keep a non-zero value in `accept_channel`
> or should it be zero?
You can't send it before you know the channel_id, so it has to be at
least 1. Spec says:
- MUST NOT send `announcement_signatures` messages until `funding_locked`
has been sent and received AND the funding transaction has at least six confirmations.
So still compliant there?
Cheers,
Rusty.

2023-06-09 15:02:45 CEST

- reply

📅 Original date posted:2021-06-29
📝 Original message:
Hi all!
John Carvalo recently pointed out that not every implementation
accepts zero-conf channels, but they are useful. Roasbeef also recently
noted that they're not spec'd.
How do you all do it? Here's a strawman proposal:
1. Assign a new feature bit "I accept zeroconf channels".
2. If both negotiate this, you can send update_add_htlc (etc) *before*
funding_locked without the peer getting upset.
3. Nodes are advised *not* to forward HTLCs from an unconfirmed channel
unless they have explicit reason to trust that node (they can still
send *out* that channel, because that's not their problem!).
It's a pretty simple change, TBH (this zeroconf feature would also
create a new set of channel_types, altering that PR).
I can draft something this week?
Thanks!
Rusty.

2023-06-09 15:02:18 CEST

- reply

📅 Original date posted:2021-04-24
📝 Original message:
Matt Corallo <lf-lists at mattcorallo.com> writes:
> Somehow I missed this thread, but I did note in a previous meeting - these issues are great fodder for fuzzing. We’ve had a fuzzer which aggressively tests for precisely these types of message-non-delivery-and-resending production desync bugs for several years. When it initially landed it forced several rewrites of parts of the state machine, but quickly exhausted the bug fruit (though catches other classes of bugs occasionally as well). The state machine here is really not that big - while I agree simplifying it where possible is nice, ripping things out to replace them with fresh code (which would need similar testing) is probably not the most obvious decrease in complexity.
It's historically had more bugs than anything else in the protocol. We
literally found another one in feerate negotiation since the last
c-lightning release :(
I'd rather not have bugs than try to catch them all.
>> I've been revisiting this because it makes things like splicing easier:
>> the current draft requires stopping changes while splicing is being
>> negotiated, which is not entirely trivial. With the simplified method,
>> you don't have to wait at all.
>
> Hmm, what’s nontrivial about this? How much more complicated is this than having an alternation to updates and pausing HTLC updates for a cycle or two while splicing is negotiated (I assume it would still need a similar requirement, as otherwise you have the same complexity)? We already have a similar update-stopping process for shutdown, though of course it doesn’t include restarting.
You could propose a splice (or update to anchors, or whatever) any time
when it's your turn, as long as you haven't proposed any other updates.
That's simple!
Instead, *both* sides have to send a splice message to synchronize, and
they can only do so once all in-flight changes have cleared. You have
to resolve simultaneous splice attempts (we use "highest feerate"
tiebreak by node_id), and keep track of this stage while you clear
in-flight changes.
Here's the subset of requirements from the draft which relate to this:
The sender:
- MUST NOT send another splice message while a splice is being negotiated.
- MUST NOT send a splice message after sending uncommitted changes.
- MUST NOT send other channel updates until splice negotiation has completed.
The receiver:
- MUST respond with a `splice` message of its own if it has not already.
- MUST NOT reply with `splice` until all commitment updates are resolved by both peers.
- MUST use the higher of the two `funding_feerate_perkw` as the feerate for
the splice.
- MUST NOT send other channel updates until splice negotiation has completed.
Similar requirements exist for other major channel changes.
Cheers,
Rusty.

2023-06-09 15:01:50 CEST

- reply

📅 Original date posted:2021-01-12
📝 Original message:
Lloyd Fournier <lloyd.fourn at gmail.com> writes:
> Rusty, Zman,
>
> A concern I have with only doing one signaling transaction out of the whole
> group of inputs is that it means you don't prove ownership of the other
> inputs.
But that's by design. You can contact two peers and middleman between
them to produce a single tx.
The practical problem with a signalling tx is that it's hard to tell if
it's conflicting. Mallory uses a single UTXO to probe for everyone's
UTXO at once. Poor Bob wants to both wait 60 seconds to see if a
conflicting tx ends up in his mempool, *and* broadcast it ASAP to signal
to others. He wants to do both of these *before* revealing his own
UTXOs.
Not sure how to square this, but I do prefer this approach over PoDLE.
Cheers,
Rusty.

2023-06-09 15:01:49 CEST

- reply

📅 Original date posted:2021-01-07
📝 Original message:
Lloyd Fournier <lloyd.fourn at gmail.com> writes:
> This achieves all properties except for (4 - distinguishable on-chain)
> which is why it was dismissed.
It also seems to require 2 txs per channel open? (Interestingly I
missed that post previously, thanks for the pointer!)
> I think it is possible to extend the idea to achieve (4) and therefore
> obtain all desired properties.
> Simply put peers can just use the SINGLE|ANYONECANPAY signature as back ups
> in case of abort. Here's how it could work in my mind:
>
> 1. Initiator requests dual-funding and provides a TX_temp spending their
> input set to a main output and a change output (does not sign it yet). They
> also provide a sighash SIGNLE|ANYONECANPAY signature on the main output
> spending into TX_backup-fund and a signature on the first commitment
> transaction spending from TX_backup-fund (exactly as in [6]).
> 2. Peer responds with commitment TX signature for TX_backup-fund.
> 3. Initiator responds with the signatures for TX_temp.
> *Peer now has a fully functional transaction chain with which to open the
> channel -- now they can attempt to upgrade to a SIGHASH_ALL opening*.
> 4. Peer (if possible) checks there are no existing transactions in the
> chain or mempool spending from the taker's inputs. If not it responds with
> its inputs, change and commitment tx signature for a SIGHASH_ALL TX_fund.
> 5. Initiator responds with commitment TX signature and TX_fund input
> signatures.
> 6. Peer broadcasts TX_fund.
> *If at any point after step 3 Initiator does not respond for ~2 seconds
> they broadcast TX_temp and TX_backup-funding*
2 seconds is not sufficient; as an Australian (or Tor user) you should
know this :)
But otherwise, it's kinda nice (bar breaking the interactive construction).
> We have (4) because the SINGLE|ANYONECANPAY signature only appears on-chain
> in case of abort (i.e. TX_backup-funding makes it on-chain).
> It appears to be pretty close to the ideal solution in terms of privacy and
> security.
> If the malicious initiator learns an output they will always have to spend
> one of their inputs otherwise they will quickly get hit by the TX_temp +
> TX_backup-funding.
> Note that it is possible the node is just slow in which case even if step
> TX_backup-funding makes it in both parties should just carry on with the
> channel.
>
> The downsides are that it involves six rounds of communication and cannot
> use the "interactive tx building" protocol developed for the original
> proposal
>
> # Signaling Transactions
>
> Finally I present a simple but unintuitive protocol that achieves roughly
> the same properties as the PoDLE protocol but without lightning gossip
> messages.
>
> Whenever the initiator adds an input in the interactive tx building they
> provide signatures on a "signaling" transaction spending that input (and
> any inputs they have added so far).
> The signaling transactions will typically spend the funds back to the
> initiator's wallet.
> Before revealing any of their inputs, the peer checks that none of the
> inputs added by the initiator are in their mempool/chain.
> If the initiator aborts the protocol after learning one of the peer's
> inputs the peer broadcasts one of the signaling transactions.
>
> Like the PoDLE proposal this doesn't achieve (3) since a malicious peer
> could broadcast the signaling transaction making the honest initiator pay a
> transaction fee before using the input in another session.
> To mitigate this a bit, the transactions could be RBF and have a 1
> sat-per-byte feerate to give the initiator a decent amount of time to use
> their input productively before the tx confirms (and paying a low fee if it
> ever does confirm).
>
> The advantages of signaling transactions over PoDLE is that it doesn't
> involve any wonky crypto or new gossip messages.
> The advantage of the PoDLE proposal over this is that a malicious peer can
> only blacklist the UTXO (not necessarily force you to spend it).
We only need a single UTXO for this, which is even better.
So the initiator sends a "good faith" signed tx, which spends one of its
UTXOs, to the accepter. 1sat-per-byte is probably a too low, but the
accepter can provide a feerate for it[1]. Opener aborts if that
"good-faith" feerate is too high. It's implied that this is the first
added input, too.
If the accepter screws the opener by broadcasting it, the opener can
still open a channel with someone else before it's confirmed: they just
can't use *that* utxo if they want another node to DF. Or simply take
the loss, since the feerate is presumably minimal, and use CPFP.
Cheers,
Rusty.
[1] The latest c-lightning implementation of the spec[2] already has the
accepter indicating min, max and preferred feerates (and then the
opener selects within that range). This would simply add another
feerate field, suggest implementing as ceiling(min / 2, 1).
[2] Which Lisa promises she'll publish RSN, so we can add your derived
points proposal to it.

2023-06-09 15:01:29 CEST

- reply

📅 Original date posted:2020-11-18
📝 Original message:
See:
https://github.com/lightningnetwork/lightning-rfc/blob/route-blinding/proposals/route-blinding.md
1. Can we use additive tweaks instead of multiplicative?
They're slightly faster, and supported by the x-only secp API.
2. Can we use x-only pubkeys? It's generally trivial, and a byte
shorter. I'm using them in offers to great effect.
Thanks!
Rusty.

2023-06-09 15:01:20 CEST

- reply

📅 Original date posted:2020-10-14
📝 Original message:
Bastien TEINTURIER <bastien at acinq.fr> writes:
> It's a bit tricky to get it right at first, but once you get it right you
> don't need to touch that
> code again and everything runs smoothly. We're pretty close to that state,
> so why would we want to
> start from scratch? Or am I missing something?
Well, if you've implemented a state-based approach then this is simply a
subset of that so it's simple to implement (I believe, I haven't done it
yet!).
But with a synchronous approach like this, we can do dynamic protocol
updates at any time without having a special "stop and drain" step.
For example, you can decrease the amount of HTLCs you accept, without
worrying about the case where there HTLCs being added right now. This
solves a similar outstanding problem with update_fee.
Cheers,
Rusty.

2023-06-09 15:01:19 CEST

- reply

📅 Original date posted:2020-10-12
📝 Original message:
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

2023-06-09 14:59:46 CEST

- reply

📅 Original date posted:2020-04-27
📝 Original message:
"David A. Harding via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org> writes:
> To avoid the excessive wasting of bandwidth. Bitcoin Core's defaults
> require each replacement pay a feerate of 10 nBTC/vbyte over an existing
> transaction or package, and the defaults also allow transactions or
> packages up to 100,000 vbytes in size (~400,000 bytes). So, without
> enforcement of BIP125 rule 3, an attacker starting at the minimum
> default relay fee also of 10 nBTC/vbyte could do the following:
>
> - Create a ~400,000 bytes tx with feerate of 10 nBTC/vbyte (1 mBTC total
> fee)
>
> - Replace that transaction with 400,000 new bytes at a feerate of 20
> nBTC/vbyte (2 mBTC total fee)
>
> - Perform 998 additional replacements, each increasing the feerate by 10
> nBTC/vbyte and the total fee by 1 mBTC, using a total of 400 megabytes
> (including the original transaction and first replacement) to
> ultimately produce a transaction with a feerate of 10,000 nBTC/vbyte
> (1 BTC total fee)
>
> - Perform one final replacement of the latest 400,000 byte transaction
> with a ~200-byte (~150 vbyte) 1-in, 1-out P2WPKH transaction that pays
> a feerate of 10,010 nBTC/vbyte (1.5 mBTC total fee)
To be fair, if the feerate you want is 100x the minimum permitted, you
can always use 100x as much bandwidth as necessary without extra cost.
If everyone (or some major tx producers) were to do that, it would suck.
To fix this properly, you really need to agressively delay processing
(thus propagation) of transactions which aren't likely to be in the next
(few?) blocks. This is a more miner incentive compatible scheme.
However, I realize this is a complete rewrite of bitcoind's logic, and
I'm not volunteering to do it!
Cheers,
Rusty,

2023-06-09 14:59:24 CEST

- reply

📅 Original date posted:2020-04-05
📝 Original message:
Hi ZmnSCPxj,
This is a rework of the old unwrap-the-onion proposal, with
some important bits missing.
> Secondly, C needs to prove that the channel it is willing to close involves the payment attempt, and is not some other channel closure that it is attempting to use to fulfill its own soft timeout.
> Since the unilateral close transaction *is* the proof-of-closure, B (and A) can inspect the transaction outputs and see (with some additional data from C) that one of the outputs is to an HTLC that matches the payment hash.
>
> Thus, B (and A) can believe that the proof-of-closure proves that whoever is presenting it is free of wrongdoing, as whoever is actually causing the delay has been punished (by someone being willing to close a channel with the culprit), and that the proof-of-closure commits to this particular payment attempt and no other (because it commits to a particular payment hash).
As you note below, the payment might be considered dust, or an
unresponsive peer has not yet acked the HTLC.
My previous proposal was to limit the damage somewhat by requiring that
C offer a signed list of some limited number of HTLCs it is claiming
were caught, alongside the closure proof (you can merkle this, but
that's a detail). That closure claim gets socialized, and if there are
multiple different claim lists for the tx then C is a bad actor and we
no longer respect its closure proof.
You also missed how the timeout would work, which is important. How
long does node N wait for a proof? In my construction, it's 30 seconds,
plus get another 30 seconds for each decryption of the onion it
receives.
Otherwise, you can't know how long you've got to provide this closure
proof, or how long to wait for it.
In addition, for closure proofs to work, nodes need to agree on what is
a valid, standard, high-enough-fee commitment transaction.
Cheers,
Rusty.

2023-06-09 14:59:16 CEST

- reply

📅 Original date posted:2020-03-10
📝 Original message:
ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
> Good morning Rusty, et al.,
>
>
>> Note that this means no payment secret is necessary, since the incoming
>> `blinding` serves the same purpose. If we wanted to, we could (ab)use
>> payment_secret as the first 32-bytes to put in Carol's enc1 (i.e. it's
>> the ECDH for Carol to decrypt enc1).
>
> I confess to not reading everything in detail, but it seems to me that, with payment point + scalar and path decorrelation, we need to establish a secret with each hop anyway (the blinding scalar for path decorrelation), so if you need a secret per hop, possibly this could be reused as well?
Indeed, this could be used the same way, though for that secret it can
simply be placed inside the onion rather than passed alongside.
Cheers,
Rusty.

2023-06-09 14:59:15 CEST

- reply

📅 Original date posted:2020-03-09
📝 Original message:
I recently hit a dead-end on rendezvous routing; the single-use
requirement is a showstopper for offers (which are supposed to be static
and reusable).
Fortunately, t-bast has a scheme for blinded paths (see
https://gist.github.com/t-bast/9972bfe9523bb18395bdedb8dc691faf ) so
I've been examining that more closely. I think it can be simplified
to use more standard primitives.
The problem: Alice wants to present Mallory with a path (Carol, Bob,
Alice) for which he can create an onion, which is obscured in some way,
but can be unobscured by the various nodes. Mallory should be forced to
use the entire path.
Alice can give Mallory two ECDH blobs to place inside the per-hop
payload to establish shared secrets with Bob and Carol. But crucially,
Bob needs the secret *before* he can unwrap the onion, so the ECDH
blob for the next peer needs to be sent alongside the onion itself.
t-bast proposed using the secret to XOR the scid, but Christian
suggested it's more powerful to encrypt a general payload.
What does this leave us with?
1. A new invoice letter `b`. Encodes
1 or more pubkey/feebase/feeprop/cltvdelta/features/encblob.
2. An additional (tlv of course) field to update_add_htlc, `blinding`.
3. New `tlv_payload` field `encblob` (varlen).
4. ECDH on incoming `blinding` to get a shared secret which tells
this node how to tweak its nodeid to decrypt onion, and also how to
decrypt `encblob`. This gives a tlv, which presumably contains
`short_channel_id` as well as `blinding`.
5. Use `blinding` for the next update_add_htlc.
6. If you get an error from downstream and you sent `blinding`, turn it
into your own error for maximum obfuscation. Perhaps a new
"blinded_path_error"? Obviously does not include a channel_update :)
So, if you get an invoice `b`, with path starting at (known) Carol:
Carol/1/1/9/""/enc1
Bob'/1/1/9/""/enc2
[Optional: decoy hops...]
Payer constructs the onion to get to Carol as normal, then:
Carol: No `blinding` in incoming HTLC, but once it decrypts the
onion, she sees `encblob` (value enc1). Uses first 32
bytes of `enc1` as `blinding`: do ECDH to get SS1, uses
SS1 to decrypt rest to get next scid and `blinding`, send
`blinding` with update_add_htlc to Bob.
Bob: Gets `blinding` from update_add_htlc. ECDH -> SS2. Tweak
own key with SS2 to decode onion. Use SS2 to decrypt
`enc2` to get next scid and blinding. Send `blinding`
with update_add_htlc to Alice.
Alice: Gets `blinding` from update_add_htlc. ECDH -> SS3. Tweak
own key with SS3 to decode onion. If it put in decoy
hops, this onion won't be terminal, but otherwise it can
be treated as terminal iff `blinding` is the expected value
for this invoice.
Note that this means no payment secret is necessary, since the incoming
`blinding` serves the same purpose. If we wanted to, we could (ab)use
payment_secret as the first 32-bytes to put in Carol's enc1 (i.e. it's
the ECDH for Carol to decrypt enc1).
Thoughts?
Rusty.

2023-06-09 14:58:40 CEST

- reply

📅 Original date posted:2020-02-13
📝 Original message:
ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> writes:
> Good morning niftynei,
>
>
>> Rusty had some suggestions about how to improve the protocol messages for this, namely adding a serial_id to the inputs and outputs, which can then be reused for deletions.
>>
>> The serial id can then also be used as the ordering heuristic for transaction inputs during construction (replacing current usage of BIP69). Inputs can be shared amongst peers by flipping the bottom bit of the serial_id before relaying them to another peer (as your own).
>
> What happens if the initiator deliberately provides serial IDs 0x1, 0x3, .... while the acceptor naively provides serial IDs from `/dev/urandom`?
This is a feature, and one you might need to use if you have some
SIGHASH_SINGLE or other weirdness for one input.
> Then the balance of probability is that the initiator inputs and outputs are sorted before the acceptor.
> Now, this is probably not an issue, since the initiator and acceptor both know which inputs and outputs are theirs and not theirs, so they could just reveal this information to anyone, so an actor providing such lousy serial IDs is just hurting its own privacy relative to blockchain analysts, so probably will not happen in practice.
>
> My initial reaction was to propose adding a secret-sharing round where the resulting key is XORed to each serial ID before sorting by the XORed serial ID, but this might be too overweight, and again the initiator is only hurting its own privacy, and the two participants already know whose money is whose anyway....
>> > - nLocktime is always set to 0x00000000
>>
>> - If a blockheight to be used as nLocktime is communicated in the initiation step, is set to blockheight-6; otherwise set to zero-
>
> I am unsure what is the purpose of this minus 6.
>
> If you fear blockheight disagreements, this is probably a good time to introduce block headers.
> So for example if the acceptor thinks the initiator blockheight is too high, it could challenge the initiator to give block headers from its known blockheight to the initiator blockheight.
> If the acceptor thinks the initiator blockheight is too low, it could provide block headers itself as proof.
> This could be limited so that gross differences in blockheight are outright rejected by the acceptor (it could `error` the temporary channel ID rather than accept it).
Yes, I would just have the initiator specify nLocktime directly, just
like feerate. If you don't like it, don't contribute to the tx
construction.
> This is SPV, but neither side is actually making or accepting a payment *yet*, just synchronizing clocks, so maybe not as bad as normal SPV.
>
> Massive chain reorgs cannot reduce blockheight, only increase it (else
> the reorg attempt fails in the first place)
This is not quite true, due to difficulty adjustments. It's true in
practice, however, and not relevant since you'd just have to wait one
more block.
>> - Serial ids should be chosen at random
>> - For multiparty constructions, the initiator MUST flip the bottom bit of any received inputs before relaying them to a peer.
>>
>> - Collisions of serial ids between peers is a protocol error
>
> I suppose we should define collision to mean "equal in all bits except the lowest bit".
No, literally equal. i.e. you can only make this error by clashing with
yourself.
Cheers,
Rusty.

2023-06-09 14:58:36 CEST

- reply

📅 Original date posted:2020-02-13
📝 Original message:
Bastien TEINTURIER <bastien at acinq.fr> writes:
> Hi Rusty,
>
> Thanks for the answer, and good luck with c-lightning 0.8.1-rc1 ;)
... Now -rc2. I actually had a RL use for lightning (OMG!), and sure
enough found a bug.
> I've been thinking more about improving my scheme to not require any sender
> change, but I don't think that's possible at the moment. As with all
> Lightning
> tricks though, once we have Schnorr then it's really easy to do.
> Alice simply needs to use `s * d_a` as her "preimage" (and the payment point
> becomes the P_I Bob needs). That may depend on the exact multi-hop locks
> construction we end up using though, so I'm not 100% sure about that yet.
I was starting to think this whole thing was of marginal benefit: note
that solving "private channels need a temp scid" is far simpler[1].
But since your scheme extends to rendevous, it's much more tempting!
We would use this for normal private channels as well as private routes
aka new rendezvous. Even better, this would be a replacement for
current route hints (which lack ability to specify feature bits, which
we would add here, and is also grossly inefficient if you just want to
use it for Routeboost[2]).
Propose we take the `z` to use as bolt11 letter, because even the French
don't pronounce it in "rendez-vous"!)
Then use TLV inside:[3]
* `z` (2): `data_length` variable. One or more entries containing extra
routing information; there may be more than one `z` field. Each entry
looks like:
* `tlv_len` (8 bits)
* `rendezvous_tlv` (tlv_len bytes)
1. tlvs: `rendezvous_tlv`
2. types:
1. type: 1 (`pubkey`)
2. data:
* [`point`:`nodeid`]
1. type: 2 (`short_channel_id`)
2. data:
* [`short_channel_id`:`short_channel_id`]
1. type: 3 (`fee_base_msat`)
2. data:
* [`tu32`:`fee_base_msat`]
1. type: 4 (`fee_proportional_millionths`)
2. data:
* [`tu32`:`fee_proportional_millionths`]
1. type: 5 (`cltv_expiry_delta`)
2. data:
* [`tu16`:`cltv_expiry_delta`]
1. type: 6 (`features`)
2. data:
* [`...*byte`:`features`]
That probably adds 6 bytes entry, but worth it I think.
Cheers,
Rusty.
[1] Add a new field to 'funding_locked': "private_scid". If both sides
support 'option_private_scid' (?) then the "real" scid is no longer
valid for routing, and we use the private scid.
[2] It's enough to give the scid(s) in this case indicating where you
have incoming capacity.
[3] I'm really starting to dislike my bolt11 format. We should probably
start afresh with a TLV-based one, where signature covers the hash
of each entry (so they can be easily externalized!), but that's a
big, unrelated task.

2023-06-09 14:58:35 CEST

- reply

📅 Original date posted:2020-02-10
📝 Original message:
Bastien TEINTURIER <bastien at acinq.fr> writes:
>> But Mallory can do the same attack, I think. Just include the P_I from
>> the wrong invoice for Bob.
>
> Good catch, that's true, thanks for keeping me honest there! In that case
> my proposal
> would need the same mitigation as yours, Bob will need to include the
> `scid` he received
> in `update_add_htlc` (this is in fact not that hard once we allow TLV
> extensions on every
> message).
Yes, I've added this to the PR. Which gives a new validation path, I
think:
## Figuring out what nodeid to use to decode onion
1. Look up scid from HTLC; if it didn't include one, use default.
2. Look up payment_hash; if no invoice is found, use default.
3. If invoice specified this scid, get nodeid and use that.
4. ... and refuse to forward the HTLC (it must terminate here).
My plan is to add an argument to `invoice` which is an array of one or
more scids: we get a temporary scids for each peer and use them in the
routehints. We also assign a random temporary nodeid to that invoice.
The above algo is designed to ensure we behave like any other node which
has no idea about this nodeid if Mallory:
1. tries to use a temporary node id on a normal channel to us.
2. tries to pay another invoice using this temporary node id.
3. tries to probe our outgoing channels using this routing hint
(I think we should probably ban forwarding to private channels,
too, for similar reasons).
---
Note that with any self-assigned SCID schemes, Alice has to respond to
unknown scids in update_add_htlc with some BADONION code (which makes
*Bob* give Carol an error response, since Alice can't without revealing
her identity).
With Bob-assigned SCIDs, Alice simply needs to make him unallocate
it before forgetting the invoice, so she will simply never see old
invoices.
(All these schemes give limited privacy, of course: Bob knows who Alice
is, and fingerprinting and liveness attacks are always possible).
> I'm extremely nervous about custodial lightning services restricting
>> what they will pay to. This is not theoretical: they will come under
>> immense KYC pressure in the near future, which means they cannot pay
>> arbitrary invoices.
1>>
>
> That's a very good point, thanks for raising this. However I believe that
> there are (and will be) enough
> non-custodial wallets to let motivated users pay whatever they want. Users
> can even run their own
> node to pay such invoices if needed.
Not if ln_strike (no, the other one!) is the future.
> If you are using a custodial wallet and KYC pressure kicks in, then
> regardless of that feature law may
> require users to completely reveal who they are paying, so even normal
> payments wouldn't protect
> them, don't you think? Regulation could for example disallow paying via
> unannounced channels entirely
> (or require you to show the funding tx associated to your unannounced
> channel).
Actually, as long as the same method is required for both normal private
channels (which will all use non-tx-based short_channel_ids in the near
future I hope!), I don't really mind. I expect such payments to become
significant, and as long as paying to a temporary id and paying to a
private channel looks identical, it's too draconian to ban. A business
would probably meet any KYC requirements by simply asking the user
(perhaps over a certain amount, etc).
(I've put my implementation on hold for a moment while I'm supposed to
be releasing 0.8.1-rc1 RSN!)
Cheers,
Rusty.

2023-06-09 14:58:34 CEST

- reply

📅 Original date posted:2020-02-04
📝 Original message:
Bastien TEINTURIER <bastien at acinq.fr> writes:
> Hey again,
>
> Otherwise Mallory gets two invoices, and wants to know if they're
>> actually the same node. Inv1 has nodeid N1, routehint Bob->C1, Inv2 has
>> nodeid N2, routehint Bob->C2.
>
> I think this attack is interesting. AFAICT my proposal defends against this
> because of the way
> `payment_secret` and `decoy_key` are both used to derive the `decoy_scid`
> (but don't trust me, do
> verify that I'm not missing something).
>
> If Mallory doesn't use both the right `decoy_node_id` and `payment_secret`
> to compute `P_I`, Bob
> will not decode that to a valid real `scid` and will return an
> `unknown_next_peer` which is good
> for privacy.
But Mallory can do the same attack, I think. Just include the P_I from
the wrong invoice for Bob.
> It seems to me that
> https://github.com/lightningnetwork/lightning-rfc/pull/681 cannot defend
> against this attack. If both invoices are currently valid, Bob will forward
> an HTLC that uses N1
> with C2 (because Bob has no way of knowing N1 from the onion, for privacy
> reasons).
> The only way I'd see to avoid is would be that Alice needs to share her
> `decoy_node_id`s with
> Bob (and the mapping to a `decoy_scid`) which means more state to
> manage...but maybe I'm just
> missing a better mitigation?
No, Bob can include the scid he used in the update_add_htlc message, so
Alice can check.
I'm extremely nervous about custodial lightning services restricting
what they will pay to. This is not theoretical: they will come under
immense KYC pressure in the near future, which means they cannot pay
arbitrary invoices.
Thus my preference for a system which doesn't add any requirements on
the payer.
Cheers,
Rusty.

2023-06-09 14:58:33 CEST

- reply

📅 Original date posted:2020-02-04
📝 Original message:
Rusty Russell <rusty at rustcorp.com.au> writes:
> Bastien TEINTURIER <bastien at acinq.fr> writes:
>> That's of course a solution as well. Even with that though, if Alice opens
>> multiple channels to each of her Bobs,
>> she should use Tor and a different node_id each time for better privacy.
>
> There are two uses for this feature (both of which I started implementing):
>
> 1. Simply always use a temporary id when you have a private channel, to
> obscure your onchain footprint. This is a nobrainer.
>
> 2. For an extra layer of transience, apply a new temporary id and new
> nodeid on every invoice *which applies only for that invoice*.
>
> But implementing the latter securely is fraught!
>
> Firstly, need to brute-force the onion against your N keys. Secondly,
> if you use a temporary key, then you *don't* end up using the HTLC to
> pay an invoice matching that key, you *MUST* pretend you couldn't
> decrypt the onion! This applies to all code paths between the two,
> including parsing the TLV, etc: they must ALL return
> WIRE_INVALID_ONION_HMAC.
>
> Otherwise, Mallory can get an invoice, then send malformed payments to
> Alice using the transient key in the invoice and see if she decrypts it.
Actually, that was too hasty. You can use the payment_hash as a
fastpath:
1. Look up invoice using payment_hash.
2. If there is an invoice, and it has a temporary id associated with it,
try using that to decrypt the onion. If that works, and the onion is
on the final hop, and the TLV decodes, and the payment_secret is
correct, you can go back and use this temporary key to decrypt the onion.
Otherwise, go back and use the normal node key.
That's still quite a bit of tricky code though...
Cheers,
Rusty.

2023-06-09 14:58:33 CEST

- reply

📅 Original date posted:2020-02-04
📝 Original message:
Bastien TEINTURIER <bastien at acinq.fr> writes:
> That's of course a solution as well. Even with that though, if Alice opens
> multiple channels to each of her Bobs,
> she should use Tor and a different node_id each time for better privacy.
There are two uses for this feature (both of which I started implementing):
1. Simply always use a temporary id when you have a private channel, to
obscure your onchain footprint. This is a nobrainer.
2. For an extra layer of transience, apply a new temporary id and new
nodeid on every invoice *which applies only for that invoice*.
But implementing the latter securely is fraught!
Firstly, need to brute-force the onion against your N keys. Secondly,
if you use a temporary key, then you *don't* end up using the HTLC to
pay an invoice matching that key, you *MUST* pretend you couldn't
decrypt the onion! This applies to all code paths between the two,
including parsing the TLV, etc: they must ALL return
WIRE_INVALID_ONION_HMAC.
Otherwise, Mallory can get an invoice, then send malformed payments to
Alice using the transient key in the invoice and see if she decrypts it.
And then I realized that Alice can't do this properly without Bob
telling her what the scid he used to route was.
Otherwise Mallory gets two invoices, and wants to know if they're
actually the same node. Inv1 has nodeid N1, routehint Bob->C1, Inv2 has
nodeid N2, routehint Bob->C2.
Now Mallory uses Bob->C2 to pay to N1 for Inv1. If it works, he knows
it's the same node issuing both invoices.
So, update_add_htlc needs a new scid field.
At this point, I think we should just add a new channel_flag, which if
you set it (and feature flag is offered) you get assigned random SCID
from the peer in funding_locked. This overrides your
funding-transaction-based SCID.
That gets the first case for new channels, without adding much
complexity at all.[1]
Thoughts?
Rusty.
[1] If we want to cover existing channels, we need a new "give me a
replacement scid" msg and reply. But it can be idempotent (you
only ever get one replacement).

2023-06-09 14:58:31 CEST

- reply

📅 Original date posted:2020-02-03
📝 Original message:
Bastien TEINTURIER <bastien at acinq.fr> writes:
> We can easily get rid of (1.) by leveraging the `payment_secret`. The
> improved scheme is:
>
> * Alice draws a random `decoy_key`
> * Alice computes the corresponding `decoy_node_id = decoy_key * G`
> * Alice draws a random `payment_secret`
> * Alice computes `decoy_short_channel_id = H(payment_secret * decoy_key *
> bob_node_id) xor short_channel_id`
> * Alice uses the `decoy_key` to sign the invoice
> * Carol recovers `decoy_node_id` from the invoice signature
> * Carol includes `P_I = payment_secret * decoy_node_id` in the onion
> payload for Bob
> * Bob can compute `short_channel_id = H(bob_private_key * P_I) xor
> decoy_short_channel_id`
>
> But I don't see how to get rid of (2.). If anyone has a clever idea on how
> to do that, I'd love to hear it!
I really don't want a special marker on Carol; she needs to just pay
like normal. Not just because it's simple, but because it means that
Carol can use a custodial wallet without having to flag the payment as
somehow special.
AFAICT, having Bob assign scids is the only viable way to do this. The
current proposal limits to one scid at a time, but it could be extended
to allow multiple scids.
(I'm seeking a clever way that Bob can assign them and trivially tell
which ID is assigned to which peer, but I can't figure it out, so I
guess Bob keeps a mapping and restricts each peer to 256 live scids?).
I've updated and somewhat simplified the PR now.
Cheers,
Rusty.

2023-06-09 14:57:33 CEST

- reply

📅 Original date posted:2019-12-03
📝 Original message:
ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
> 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?
You're right, no wonder I missed this problem :(
OK, so we need to change the key(s) every time. Can we tweak it based
on something the watchtower will know, i.e. something in the update tx
itself? Obviously not the output, as that would create a circular
dependency. Is there some taproot thing we can use to insert some
noise in the input?
Cheers,
Rusty.

2023-06-09 14:57:18 CEST

- reply

📅 Original date posted:2019-11-11
📝 Original message:
Ross Dyson <me at rossdyson.com> writes:
> Hi Rusty,
>
> We spoke in detail about this after your presentation at LNconf. I'm one of
> the contributors to LNURL so I am a little familiar with what you're trying
> to achieve and am very grateful you're considering implementing something
> similar to the mainnet protocol.
>
> I can only see delivery address being a nightmare for the network or wallet
> providers. If you take a quick look at any Shopify website right now and
> try to buy something to be delivered you will see validation of address
> inputs before accepting payment.
>
> This is the 'expected' UX of consumer applications in 2019. If offers were
> to not validate address inputs correctly the user will not receive the
> product, lose money, and have a [very] negative review of both the
> wallet-providing and the offer-providing businesses.
>
> Handling these UX expectations will require either the wallet provider or
> the offer provider to validate the inputs before proceeding with the sale.
>
> 1. If the offer provider handles validation then the network will have
> to accommodate potentially infinite validation attempts (big no no I assume)
> 2. If the wallet provider were to provide the UX for input validation
> they are taking on significant workload to develop a robust address input
> UI, but more importantly the responsibility to correctly validate. There is
> plenty of room to screw up and create a catastrophic user experience.
>
> So I think address validation input is only possible via 2. but I think it
> is too much workload and responsibility to expect from wallet providers.
This is not the area I worry about, TBH, since every shopping website in
existence has implemented address input (and some form of validation).
I'm sure it'll be primitive to start with.
Of course, UBL has a standard 'AddressType' too:
http://docs.oasis-open.org/ubl/os-UBL-2.2/xsd/common/UBL-CommonAggregateComponents-2.2.xsd
>>From what I can see, it would not be impossible to bring delivery address
> functionality into offers retroactively after offers was already in prod.
> Perhaps icebox it?
Quite possibly something we can delay; most current goods are virtual
anyway. However, delivery address standardization would greatly improve
the UX for such things.
Cheers,
Rusty.

2023-06-09 14:57:18 CEST

- reply

📅 Original date posted:2019-11-11
📝 Original message:
Yaacov Akiba Slama <ya at slamail.org> writes:
> Hi Rusty.
>
> On 08/11/2019 05:09, Rusty Russell wrote:
>> Hi Yaacov,
>> I've been pondering this since reading your comment on the PR!
>>
>> As a fan of standards, I am attracted to UBL (I've chaired an
>> OASIS TC in the past and have great respect for them); as a fan of
>> simplicity I am not. Forcing UBL implementation on wallet providers is
>> simply not going to happen, whatever I were to propose.
>
> In fact, using UBL in LN specification is simpler than trying to
> understand the semantic of each field needed by businesses. You are
> right that using such a standard put the burden into wallet providers
> instead of LN developers, but as a wallet (breez) provider, I can say that:
>
> 1) Most money transactions (currently in fiat) are between users and
> companies and not between two users. If we want to replace FIAT by
> bitcoin, we need to create an infrastructure which can be used by
> businesses. That means that LN needs to be able to be integrated easily
> into POS systems. So, as a wallet provider who want to help the
> transition from fiat to bitcoin, I need to be able to support standards
> even if that means that I have to implement using/parsing big and
> complicated standards.
>
> For simple user to user transaction, the wallet can decide to use only a
> subset of the fields defined by the standard.
>
> 2) From a technical point of view, it seems that there are already UBL
> libraries in java and c#. I don't think such library is hard to write in
> go, rust.., so every wallet implementation can use them.
That is not the problem. The problem is that our order flow is simple:
Seller: Offer
Buyer: Invoice Request
Seller: Invoice (or updated Offer)
Buyer/Seller: Payment & Acknowledgement (atomic)
(This could, of course, fit into a larger business flow.)
The closest UBL flow seems to be:
Seller: Quotation
Buyer: Order
Seller: (Prepayment)Invoice (or updated Quotation)
It's also worth noting that, even compressed, none of the UBL examples
fit into the 1023 byte limit of the existing invoice format:
UBL-Quotation-2.1-Example.xml: 1864 bytes (gz)
UBL-Order-2.1-Example.xml: 2515 bytes (gz)
UBL-Invoice-2.1-Example.xml: 3163 bytes (gz)
Indeed, that Quotation alone requires a 32x32 QR code.
>> However, since invoices/offers and UBL are both structures, we
>> should have an explicit mapping between the two. What fields should
>> have their own existence in the invoice/offer and what should be in a
>> general UBL field is a question we have to think on further.
> I agree that we don't want duplication. This is the reason, I propose to
> use only ubl structure and add in the ln standard invoice an ubl
> "opaque" field which will be self-contained and only add in the
> invoice/offer/.. the fields specific to ln.
Except we need to go through the UBL spec and indicate exactly what
fields are permitted, and which are required.
Many UBI fields are not amenable to machine interpretation (eg. note
fields). These must be either explicitly exposed to the buyer (in case
the seller uses them) such as shipping conditions, or explicitly
forbidden/ignored.
This is not a small task, and required intimiate knowledge of the UBL
spec. It's not enough just to make something *look* like UBL.
Does anyone have expertise in this area? Shall we form a sub-group to
investigate this properly?
Thanks!
Rusty.

2023-06-09 14:57:16 CEST

- reply

📅 Original date posted:2019-11-08
📝 Original message:
ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
> First, please confirm my understanding of the message flow.
> Suppose I have a donation offer on my website and Rusty wants to donate to me.
> Then:
>
> ZmnSCPxj Rusty
> | |
> +---------- `lno` ---------->+ (via non-Lightning communication channel e.g. https)
> | |
> +<---- `invoice_request` ----+ (via a normal Rusty->ZmnSCPxj payment)
> | |
> +---- `invoice_or_error` --->| (by failing the above payment and embedding in the failure blob)
> | |
> +<------- `sendpay` ---------+ (via a normal Rusty->ZmnSCPxj payment)
>
> Is it approximately correct?
Sorry for delayed response; yes, this is correct.
>> gets an invoice request (`lni...`), and sends the invoice over the
>> lightning network, retreiving an empty reply.
>
> Here are completely pointless counterproposals for the offer and invoice-request HRPs:
>
> * Offers:
> * `lnpayme`
> * `lnbuyit`
> * `lnforsale`
> * Invoice Requests:
> * `lnpaying`
> * `lnbuying`
> * `lnshutupandtakemymoney`
>
> `lno` and `lni` feel wrong to me.
> Their juxtaposition implies `lno` == output and `lni` == input to me, due to the use of `o` and `i`, though `lno` is where you get money in exchange for product and `lni` is the request-for-service.
lnx and lny? Nobody can interpret them at all, that way :)
>> 3. type: 2 (`description`)
>> 4. data:
>> - [`...*byte`:`description`]
>
> UTF-8?
> Null-terminated?
I was thinking UTF-8 like current field.
>> - MUST include `amount` if it includes `recurrence`.
>> - if it includes `amount`:
>> - MUST specify `currency` as the ISO 4712 or BIP-0173, padded with zero bytes if required
>
> I cannot find ISO 4712, but could find ISO 4217.
Oops, I fixed my typo wrong. Thanks.
> BIP-173 does not have a list of currencies, but refers to SLIP-0173.
> Some of the listed currencies there seem to have more than 4 characters.
Oh, I'd never seen SLIP-0173. Cool, I increased it to 5; SLIP-0173 has
no limit but I find it hard to care about any of them anyway.
> Should I assume encoding is ASCII?
> We will "never" see a non-ASCII currency code?
Not really, but if you don't understand it you can't do much, ASCII or
no.
>> The "default offer" of a node is a nominal offer used to send
>> unsolicited payments. It is generally not actually sent, but can be
>> used by any other node as if it has been. It has the following
>> fields:
>>
>> - `offer_idenfitier`: zero-length
>> - `d`: any
>> - `n`: the node id of the recipient.
>
> In essence, this is an implicitly-existing offer that never expires, and which can be used by any node at any time to construct an invoice request?
Yep!
>> The `refund_proof` refers to a previous invoice paid by the sender for
>> the specific case of a `refund_for` offer. It provides proof of
>> payment (the `payment_preimage` and also a signature of the
>> `payment_hash` from the `key` which requested the being-refunded
>> invoice (which does not have to be the same as this `key`!).
>
> An earlier requirement mentions that writers of offers or invoice request MUST have `paths` in some condition.
> The below does not have `paths`, but there is a "human-readable" alternate encoding which *does* have `paths`.
> It might be better to clarify this point.
The in-wire one doesn't have paths, since you respond by reply; you
don't need (and should not be able to) find the sender.
The non-wire one needs a path, since you need to initiate a reply.
>> The `directed` and `directed_reply` Messages
>>
>> ---------------------------------------------
>>
>> 1. type: 384 (`directed`) (`option_directed_messages`)
>> 2. data:
>> - [`chain_hash`:`chain_hash`]
>> - [`u64`:`id`]
>> - [`1366*byte`:`onion_routing_packet`]
>> 3. type: 384 (`directed_reply`) (`option_directed_messages`)
>> 4. data:
>> - [`chain_hash`:`chain_hash`]
>> - [`u64`:`id`]
>> - [`u16`:`len`]
>> - [`len*byte`:`reply`]
>
> This new `directed` message will be the mechanism for sending invoice requests and receiving invoice request responses?
Yes.
> What incentive is there for a forwarding node to actually forward a `directed` message?
It's a strong liveness indicator to the sender, so they're likely to use
the same path for the actual payment.
Cheers,
Rusty.

2023-06-09 14:57:12 CEST

- reply

📅 Original date posted:2019-11-07
📝 Original message:
Joost Jager <joost.jager at gmail.com> writes:
> In my opinion, the prepayment should be a last resort. It does take away
> some of the attractiveness of the Lightning Network. Especially if you need
> to make many payment attempts over long routes, the tiny prepays do add up.
> For a $10 payment, it's probably nothing to worry about. But for
> micro-payments this can become prohibitively expensive. And it is exactly
> the micro-payment use case where Lightning outshines other payment systems.
> A not yet imagined micro-payment based service could even be the launchpad
> to world domination. So I think we should be very careful with interfering
> with that potential.
I completely agree, yeah. And maybe we'll never need it, but it's one
of my main concerns for the network.
> Isn't spam something that can also be addressed by using rate limits for
> failures? If all relevant nodes on the network employ rate limits, they can
> isolate the spammer and diminish their disruptive abilities.
Sure, once the spammer has jammed up the network, he'll be stopped. So
will everyone else. Conner had a proposal like this which didn't work,
IIRC.
> If a node sees that its outgoing htlc packets stack up, it can reduce
> the incoming flow on the channels where the htlcs originate
> from. Large routing nodes could agree with their peers on service
> levels that define these rate limits.
Unfortunately, if we *don't* address this, then the network will defend
itself with the simple tactic of deanonymizing payments.
And every other solution I've seen ends up the same way :(
Cheers,
Rusty.

2023-06-09 14:57:10 CEST

- reply

📅 Original date posted:2019-11-22
📝 Original message:
Bastien TEINTURIER <bastien at acinq.fr> writes:
> I think there's another alternative than upfront payments to prevent spam,
> which is maybe less
> controversial (but potentially less effective as well - to be investigated).
>
> Why not adapt what has been done with email spam and PoW/merkle puzzles?
If we can't come up with an untracable scheme, this is what we'll have
to do (i.e. remove the sats component).
Unfortunately botnets are really good at generating these. That was
always the hashcash flaw (which is why it was never actually used).
Using a dynamic level is possible, too, so it gets harder in case we're
being spam attacked.
Cheers,
Rusty.
> The high-level idea would be that the sender must solve a small PoW puzzle *for
> each intermediate *
> *node *and communicate the solution in the onion.
> There are many ways we could do that (a new field in each intermediate hop,
> grinding an HMAC
> prefix, etc) so before going into specifics I only wanted to submit the
> high-level idea.
> What's neat with this is that it's simple, doesn't leak any privacy, and
> avoids having to create a
> node reputation system.
>
> We fight spam by forcing the sender to use some resources (instead of sats).
> Maybe this idea has already been proposed and broken, if that's the case
> I'd love to see the
> discussion if someone can surface it.
>
>
> Cheers,
> Bastien
>
> Le lun. 11 nov. 2019 à 00:32, Rusty Russell <rusty at rustcorp.com.au> a
> écrit :
>
>> Anthony Towns <aj at erisian.com.au> writes:
>> > On Fri, Nov 08, 2019 at 01:08:04PM +1030, Rusty Russell wrote:
>> >> Anthony Towns <aj at erisian.com.au> writes:
>> >> [ Snip summary, which is correct ]
>> >
>> > Huzzah!
>> >
>> > This correlates all the hops in a payment when the route reaches its end
>> > (due to the final preimage getting propogated back for everyone to
>> justify
>> > the funds they claim). Maybe solvable by converting from hashes to ECC
>> > as the trapdoor function?
>>
>> I hadn't thought of this, but yes, once we've eliminated the trivial
>> preimage correlation w/scriptless scripts it'd be a shame to reintroduce
>> it here.
>>
>> We need an accumulator with some strange properties though:
>>
>> 1. Alice provides tokens and a base accumulator.
>> 2. Bob et. al can add these tokens to the accumulator.
>> 3. They can tell if invalid tokens have been added to the accumulator.
>> 4. They can tell how many tokens (alt: each token has a value and they
>> can tell the value sum) have been added.
>> 5. They can't tell what tokens have been added (unless they know all
>> the tokens, which is trivial).
>>
>> Any ideas?
>>
>> > The refund amount propogating back also reveals the path, probably.
>> > Could that be obfusticated by somehow paying each intermediate node
>> > both as the funds go out and come back, so the refund decreases on the
>> > way back?
>> >
>> > Oh, can we make the amounts work like the onion, where it stays constant?
>> > So:
>> >
>> > Alice wants to pay Dave via Bob, Carol. Bob gets 700 msat, Carol gets
>> > 400 msat, Dave gets 300 msat, and Alice gets 100 msat refunded.
>> >
>> > Success:
>> > Alice forwards 1500 msat to Bob (-1500, +1500, 0, 0)
>> > Bob forwards 1500 msat to Carol (-1500, 0, +1500, 0)
>> > Carol forwards 1500 msat to Dave (-1500, 0, 0, +1500)
>> > Dave refunds 1200 msat to Carol (-1500, 0, +1200, +300)
>> > Carol refunds 800 msat to Bob (-1500, +800, +400, +300)
>> > Bob refunds 100 msat to Alice (-1400, +700, +400, +300)
>>
>> Or, on success, upfront payment is fully refunded or not refunded at all
>> (since they get paid by normal fees)? Either way, no data leak for that
>> case.
>>
>> > Clean routing failure at Carol/Dave:
>> > Alice forwards 1500 msat to Bob (-1500, +1500, 0, 0)
>> > Bob forwards 1500 msat to Carol (-1500, 0, +1500, 0)
>> > Carol says Dave's not talking
>> > Carol refunds 1100 msat to Bob (-1500, +1100, +400, 0)
>> > Bob refunds 400 msat to Alice (-1100, +700, +400, 0)
>> >
>> > I think that breaks the correlation pretty well, so you just need a
>> > decent way of obscuring path length?
>>
>> I don't see how this breaks correlation?
>>
>> > In the uncooperative routing failure case, I wonder if using an ECC
>> > trapdoor and perhaps scriptless scripts, you could make it so Carol
>> > doesn't even get an updated state without revealing the preimage...
>>
>> I'm not sure. We can make it so Carol has Bob's preimage(s), etc, so
>> that the node which fails doesn't get paid. I initially thought this
>> would just make people pair up (fake) nodes, but it's probably not worth
>> it since their path would be less-selected in that case.
>>
>> Cheers,
>> Rusty.
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>

2023-06-09 14:57:07 CEST

- reply

📅 Original date posted:2019-11-10
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> On Fri, Nov 08, 2019 at 01:08:04PM +1030, Rusty Russell wrote:
>> Anthony Towns <aj at erisian.com.au> writes:
>> [ Snip summary, which is correct ]
>
> Huzzah!
>
> This correlates all the hops in a payment when the route reaches its end
> (due to the final preimage getting propogated back for everyone to justify
> the funds they claim). Maybe solvable by converting from hashes to ECC
> as the trapdoor function?
I hadn't thought of this, but yes, once we've eliminated the trivial
preimage correlation w/scriptless scripts it'd be a shame to reintroduce
it here.
We need an accumulator with some strange properties though:
1. Alice provides tokens and a base accumulator.
2. Bob et. al can add these tokens to the accumulator.
3. They can tell if invalid tokens have been added to the accumulator.
4. They can tell how many tokens (alt: each token has a value and they
can tell the value sum) have been added.
5. They can't tell what tokens have been added (unless they know all
the tokens, which is trivial).
Any ideas?
> The refund amount propogating back also reveals the path, probably.
> Could that be obfusticated by somehow paying each intermediate node
> both as the funds go out and come back, so the refund decreases on the
> way back?
>
> Oh, can we make the amounts work like the onion, where it stays constant?
> So:
>
> Alice wants to pay Dave via Bob, Carol. Bob gets 700 msat, Carol gets
> 400 msat, Dave gets 300 msat, and Alice gets 100 msat refunded.
>
> Success:
> Alice forwards 1500 msat to Bob (-1500, +1500, 0, 0)
> Bob forwards 1500 msat to Carol (-1500, 0, +1500, 0)
> Carol forwards 1500 msat to Dave (-1500, 0, 0, +1500)
> Dave refunds 1200 msat to Carol (-1500, 0, +1200, +300)
> Carol refunds 800 msat to Bob (-1500, +800, +400, +300)
> Bob refunds 100 msat to Alice (-1400, +700, +400, +300)
Or, on success, upfront payment is fully refunded or not refunded at all
(since they get paid by normal fees)? Either way, no data leak for that
case.
> Clean routing failure at Carol/Dave:
> Alice forwards 1500 msat to Bob (-1500, +1500, 0, 0)
> Bob forwards 1500 msat to Carol (-1500, 0, +1500, 0)
> Carol says Dave's not talking
> Carol refunds 1100 msat to Bob (-1500, +1100, +400, 0)
> Bob refunds 400 msat to Alice (-1100, +700, +400, 0)
>
> I think that breaks the correlation pretty well, so you just need a
> decent way of obscuring path length?
I don't see how this breaks correlation?
> In the uncooperative routing failure case, I wonder if using an ECC
> trapdoor and perhaps scriptless scripts, you could make it so Carol
> doesn't even get an updated state without revealing the preimage...
I'm not sure. We can make it so Carol has Bob's preimage(s), etc, so
that the node which fails doesn't get paid. I initially thought this
would just make people pair up (fake) nodes, but it's probably not worth
it since their path would be less-selected in that case.
Cheers,
Rusty.

2023-06-09 14:57:06 CEST

- reply

📅 Original date posted:2019-11-07
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> On Wed, Nov 06, 2019 at 10:43:23AM +1030, Rusty Russell wrote:
>> >> Rusty prepares a nonce, AAAAA and hashes it 25 times = ZZZZZ.
>> >> ZmnSCPxj prepares the onion, but adds extra fields (see below).
>> > It would have made more sense to me for Alice (Zmn) to generate
>> > the nonce, hash it, and prepare the onion, so that the nonce is
>> > revealed to Dave (Rusty) if/when the message ever actually reaches its
>> > destination. Otherwise Rusty has to send AAAAA to Zmn already so that
>> > Zmn can prepare the onion?
>> The entire point is to pay *up-front*, though, to prevent spam.
>
> Hmm, I'm not sure I see the point of paying upfront but not
> unconditionally -- you already commit the funds as part of the HTLC,
> and if you're refunding some of them, you kind-of have to keep them
> reserved or you risk finalising the HTLC causing a failure because you
> don't have enough msats spare to do the refund?
? These are upfront an unconditional. I'm confused. You pay per
HTLC added (or, in future, to send a message).
What part was unclear here?
Alice pays X to Bob. Bob gives X-<num-preimages> back to Alice. Bob
gets preimages from the onion, and from Carol etc.
This happens independent of HTLC success or failure.
>> Bob/ZmnSCPxj doesn't prepare anything in the onion. They get handed the
>> last hash directly: Alice is saying "I'll pay you 50msat for each
>> preimage you can give me leading to this hash".
>
> So my example was Alice paying Dave via Bob and Carol (so Alice/Bob,
> Bob/Carol, Carol/Dave being the individual channels).
>
> What you wrote to Zmn says "Rusty decrypts the onion, reads the prepay
> field: it says 14, LLLL." but Alice doesn't know anything other than
> ZZZZ so can't put LLLL in the onion?
Alice created the onion. Alice knows all the preimages, since she
created the chain AAAAA....ZZZZZ.
>> > I'm not sure why lucky hashing should result in a discount?
>> Because the PoW adds noise to the amounts, otherwise the path length is
>> trivially exposed, esp in the failure case. It's weak protection
>> though.
>
> With a linear/exponential relationship you just get "half the time it's
> 1 unit, 25% of the time it's 2 units, 12% of the time it's 3 units", so
> I don't think that's adding much noise?
It depends how much people are prepared to grind, doesn't it?
>> > You've only got two nonce choices -- the initial AAAA and the depth
>> > that you tell Bob and Carol to hash to as steps in the route;
>> No, the sphinx construction allows for grinding, that was my intent
>> here. The prepay hashes are independent.
>
> Oh, because you're also xoring with the onion packet, right, I see.
>
>> > I think you could just make the scheme be:
>> > Alice sends HTLC(k,v) + 1250 msat to Bob
>> > Bob unwraps the onion and forwards HTLC(k,v) + 500 msat to Carol
>> > Carol unwraps the onion and forwards HTLC(k,v) + 250 msat to Dave
>> > Dave redeems the HTLC, claims an extra 300 msat and refunds 200 msat to Carol
>
> The math here doesn't add up. Let's assume I meant:
>
> Bob keeps 500 sat, forwards 750 sat
> Carol keeps 250 sat, forwards 500 sat
> Dave keeps 300 sat, refunds 200 sat
>
>> > Carol redeems the HTLC and refunds 200 msat to Bob
>> > Bob redeems the HTLC and refunds 200 msat to Alice
>> >
>> > If there's a failure, Alice loses the 1250 msat, and someone in the
>> > path steals the funds.
>> This example confuses me.
>
> Well, that makes us even at least? :)
>
>> So, you're charging 250msat per hop? Why is Bob taking 750? Does Carol
>> now know Dave is the last hop?
>
> No, Alice is choosing to pay 500, 250 and 300 msat to Bob, Carol and
> Dave respectively, as part of setting up the onion, and picks those
> numbers via some magic algo trading off privacy and cost.
OK.
>> Does Alice lose everything on any routing failure?
>
> That was my thought yeah; it seems weird to pay upfront but expect a
> refund on failure -- the HTLC funds are already committed upfront and
> refunded on failure.
AFAICT you have to overpay, since anything else is very revealing of
path length. Which kind of implies a refund, I think.
>> If so, that is strong incentive for Alice to reduce path-length privacy
>> by keeping payments minimal, which I was really trying to avoid.
>
> Assuming v is much larger than 1250msat, and 1250 msat is much lower than
> the cost to Bob of losing the channel with Alice, I don't think that's
> a problem. 1250msat pays for 125kB of bandwdith under your assumptions
> I think?
That's irrelevant? Since retries are common, it's natural for Alice to
want to minimize losses. If she's going to lose everything on any
failure, she'll pay the minimum amount, which exposes her path length
trivially.
Thus my attempt to try to reduce the lossage. I think.
>> > Does that miss anything that all the hashing achieves?
>> It does nothing if Carol is the one who can't route.
>
> If Carol can't route, then ideally she just refunds all the money and
> everyone's happy.
That tells Bob clearly that Carol failed. If Carol claims a variable
amount, it's less obvious (though still pretty bad).
> If Carol tries to steal, then she can keep 750 msat instead of 250 msat.
> This doesn't give any way for Bob to prove Carol cheated on him though;
> but Bob could just refund the 1250 msat and write the 750 msat off as a
> loss of dealing with cheaters like Carol.
What actually happens is that Carol sends a signature on a commitment
which Bob does't agree with (since he expected his money back). They go
onchain.
Now Bob is out the total he fwd to Carol, but he's probably more annoyed
at losing the channel.
Cheers,
Rusty.

2023-06-09 14:57:05 CEST

- reply

📅 Original date posted:2019-11-05
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> On Tue, Nov 05, 2019 at 07:56:45PM +1030, Rusty Russell wrote:
>> Sure: for simplicity I'm sending a 0-value HTLC.
>> ZmnSCPxj has balance 10000msat in channel with Rusty, who has 1000msat
>> in the channel with YAIjbOJa.
>
> Alice, Bob and Carol sure seem simpler than Zmn YAI and Rusty...
Agreed, I should not have directly answered the q.
>> Rusty prepares a nonce, AAAAA and hashes it 25 times = ZZZZZ.
>> ZmnSCPxj prepares the onion, but adds extra fields (see below).
>
> It would have made more sense to me for Alice (Zmn) to generate
> the nonce, hash it, and prepare the onion, so that the nonce is
> revealed to Dave (Rusty) if/when the message ever actually reaches its
> destination. Otherwise Rusty has to send AAAAA to Zmn already so that
> Zmn can prepare the onion?
The entire point is to pay *up-front*, though, to prevent spam.
Bob/ZmnSCPxj doesn't prepare anything in the onion. They get handed the
last hash directly: Alice is saying "I'll pay you 50msat for each
preimage you can give me leading to this hash".
>> He then
>> sends the HTLC to Rusty, but also sends ZZZZZ, and 25x50 msat (ie. those
>> fields are in the update_add_htlc msg). His balance with Rusty is now
>> 8750msat (ie. 25x50 to Rusty).
>>
>> Rusty decrypts the onion, reads the prepay field: it says 14, LLLLL.
>> Rusty checks: the hash of the onion & block (or something) does indeed
>> have the top 8 bits clear, so the cost is in fact 16 - 8/2 == 14. He
>> then hashes LLLLL 14 times, and yes, it's ZZZZZ as ZmnSCPxj said it
>> should be.
>
> I'm not sure why lucky hashing should result in a discount?
Because the PoW adds noise to the amounts, otherwise the path length is
trivially exposed, esp in the failure case. It's weak protection
though.
> You're giving a linear discount for exponentially more luck in hashing
> which also seems odd.
Because you really want some actual payment, not just PoW. Botnets are
really good at PoW, less good at sending msats. And the PoW is hard to
calibrate (I guessed: real numbers will be necessary)/
> You've only got two nonce choices -- the initial AAAA and the depth
> that you tell Bob and Carol to hash to as steps in the route;
No, the sphinx construction allows for grinding, that was my intent
here. The prepay hashes are independent.
> I think you could just make the scheme be:
>
> Alice sends HTLC(k,v) + 1250 msat to Bob
> Bob unwraps the onion and forwards HTLC(k,v) + 500 msat to Carol
> Carol unwraps the onion and forwards HTLC(k,v) + 250 msat to Dave
> Dave redeems the HTLC, claims an extra 300 msat and refunds 200 msat to Carol
> Carol redeems the HTLC and refunds 200 msat to Bob
> Bob redeems the HTLC and refunds 200 msat to Alice
>
> If there's a failure, Alice loses the 1250 msat, and someone in the
> path steals the funds.
This example confuses me.
So, you're charging 250msat per hop? Why is Bob taking 750? Does Carol
now know Dave is the last hop?
Does Alice lose everything on any routing failure?
If so, that is strong incentive for Alice to reduce path-length privacy
by keeping payments minimal, which I was really trying to avoid.
> You could make the accountable by having Alice
> also provide "Hash(AAAA, refund=200)" to everyone, encoding AAAA in the
> onion to Dave, and then each hop reveals AAAA and refunds 200msat to
> demonstrate their honesty.
>
> Does that miss anything that all the hashing achieves?
It does nothing if Carol is the one who can't route.
> I think the idea here is that you're paying tiny amounts for the
> bandwidth, which when it's successful does in fact pay for the bandwidth;
> and when it's unsuccessful results in a channel closure, which makes it
> unprofitable to cheat the system, but doesn't change the economics of
> lightning much overall because channel closures can happen anytime anyway.
Not at all. You can still fail to route, and still get paid. You can't
steal *more* money without channel closure though.
> I think that approach makes sense.
>
> Cheers,
> aj
Cheers,
Rusty.

2023-06-09 14:57:04 CEST

- reply

📅 Original date posted:2019-11-05
📝 Original message:
ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
> Good morning Rusty,
Hi ZmnSCPxj!
> Is this intended to be enforceable onchain if a channel is dropped onchain while a message is being routed?
> By a vague sense of the description, it seems to me, it would require a complicated SCRIPT (or multiple tiny 50-msatoshi UTXOs) to enforce onchain.
No, it's done as a simple subtraction from direct to-local and to-remote
payments. Enforcement is by peer closing the channel, which you
wouldn't do over a few msat.
> Also, it is not exactly clear to me, the mechanism you are proposing in detail.
> Can you give a motivating example, for example in a route from
> ZmnSCPxj, through Rusty, to my imaginary friend YAIjbOJa (who is not
> in fact me)?
Sure: for simplicity I'm sending a 0-value HTLC.
ZmnSCPxj has balance 10000msat in channel with Rusty, who has 1000msat
in the channel with YAIjbOJa.
Rusty prepares a nonce, AAAAA and hashes it 25 times = ZZZZZ.
ZmnSCPxj prepares the onion, but adds extra fields (see below). He then
sends the HTLC to Rusty, but also sends ZZZZZ, and 25x50 msat (ie. those
fields are in the update_add_htlc msg). His balance with Rusty is now
8750msat (ie. 25x50 to Rusty).
Rusty decrypts the onion, reads the prepay field: it says 14, LLLLL.
Rusty checks: the hash of the onion & block (or something) does indeed
have the top 8 bits clear, so the cost is in fact 16 - 8/2 == 14. He
then hashes LLLLL 14 times, and yes, it's ZZZZZ as ZmnSCPxj said it
should be.
So Rusty takes the 14x50 as prepayment, and forwards the HTLC as
normal to YAIjbOJa, along with LLLLL and 11x50msat. His balance with
YAIjbOJa is now 450msat.
YAIjbOJa decrypts the onion. And it says 10,BBBBB. YAIjbOJa checks
that hashing BBBBB 10 times does indeed give LLLLL. Now it takes the
11x50 msat, and fulfils the HTLC. It replies to Rusty with 10,BBBBB
in the update_fulfill_htlc message, returning the (implicit) 1x50msat;
Rusty's balance with YAIjbOJa is now 500msat.
Rusty checks that BBBBB hashed 10 times gives LLLLL. Now it returns
24,BBBBB to ZmnSCPxj with the update_fulfill_htlc, demonstrating to
ZmnSCPxj that he's entitled to it, and (implicity) returning 1x50msat to
ZmnSCPxj, so their balance is now 8800msat.
Now let's look at attacks:
1. Rusty steals the funds and doesn't return them. ZmnSCPxj closes
channel, having lost 26x50msat.
2, YAIjbOJa steals the funds and doesn't return them. Rusty closes
the channel, having lost 11x50msat.
3. ZmnSCPxj doesn't put correct preimages in, or too few, or other
malformation. If it's Rusty's onion, he won't forward it and will
give an error. If it's YAIjbOJa who rejects it, Rusty returns all
but the 14x50msat he has preimages for.
Obviously Rusty needs some upper limit on how much he'll pay out, to
avoid infinite exposure (say limit the total exposure to 10,000 sats).
A reasonable limit for each HTLC would be 20 hops x 16 x 50msat ==
16sat. Even with no other limits, with 486 HTLCs in flight each way,
that's only 15456 satoshis. You'll probably lament the channel closure
more.
Hope that helps!
Rusty.
>> Hi all,
>>
>> It's been widely known that we're going to have to have up-front
>> payments for msgs eventually, to avoid Type 2 spam (I think of Type 1
>> link-local, Type 2 though multiple nodes, and Type 3 liquidity-using
>> spam).
>>
>> Since both Offers and Joost's WhatSat are looking at sending
>> messages, it's time to float actual proposals. I've been trying to come
>> up with something for several years now, so thought I'd present the best
>> I've got in the hope that others can improve on it.
>>
>> 1. New feature bit, extended messages, etc.
>> 2. Adding an HTLC causes a push of a number of msat on
>> commitment_signed (new field), and a hash.
>>
>> 3. Failing/succeeding an HTLC returns some of those msat, and a count
>> and preimage (new fields).
>>
>> How many msat can you take for forwarding? That depends on you
>> presenting a series of preimages (which chain into a final hash given in
>> the HTLC add), which you get by decoding the onion. You get to keep 50
>> msat[1] per preimage you present[2].
>>
>> So, how many preimages does the user have to give to have you forward
>> the payment? That depends. The base rate is 16 preimages, but subtract
>> one for each leading 4 zero bits of the SHA256(blockhash | hmac) of the
>> onion. The blockhash is the hash of the block specified in the onion:
>> reject if it's not in the last 3 blocks[3].
>>
>> This simply adds some payment noise, while allowing a hashcash style
>> tradeoff of sats for work.
>>
>> The final node gets some variable number of preimages, which adds noise.
>> It should take all and subtract from the minimum required invoice amount
>> on success, or take some random number on failure.
>>
>> This leaks some forward information, and makes an explicit tradeoff for
>> the sender between amount spent and privacy, but it's the best I've been
>> able to come up with.
>>
>> Thoughts?
>> Rusty.
>>
>> [1] If we assume $1 per GB, $10k per BTC and 64k messages, we get about
>> 655msat per message. Flat pricing for simplicity; we're trying to
>> prevent spam, not create a spam market.
>> [2] Actually, a number and a single preimage; you can check this is
>> indeed the n'th preimage.
>> [3] This reduces incentive to grind the damn things in advance, though
>> maybe that's dumb? We can also use a shorter hash (siphash?), or
>> even truncated SHA256 (128 bits).
>>
>>
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 14:57:04 CEST

- reply

📅 Original date posted:2019-11-05
📝 Original message:
Hi all,
It's been widely known that we're going to have to have up-front
payments for msgs eventually, to avoid Type 2 spam (I think of Type 1
link-local, Type 2 though multiple nodes, and Type 3 liquidity-using
spam).
Since both Offers and Joost's WhatSat are looking at sending
messages, it's time to float actual proposals. I've been trying to come
up with something for several years now, so thought I'd present the best
I've got in the hope that others can improve on it.
1. New feature bit, extended messages, etc.
2. Adding an HTLC causes a *push* of a number of msat on
commitment_signed (new field), and a hash.
3. Failing/succeeding an HTLC returns some of those msat, and a count
and preimage (new fields).
How many msat can you take for forwarding? That depends on you
presenting a series of preimages (which chain into a final hash given in
the HTLC add), which you get by decoding the onion. You get to keep 50
msat[1] per preimage you present[2].
So, how many preimages does the user have to give to have you forward
the payment? That depends. The base rate is 16 preimages, but subtract
one for each leading 4 zero bits of the SHA256(blockhash | hmac) of the
onion. The blockhash is the hash of the block specified in the onion:
reject if it's not in the last 3 blocks[3].
This simply adds some payment noise, while allowing a hashcash style
tradeoff of sats for work.
The final node gets some variable number of preimages, which adds noise.
It should take all and subtract from the minimum required invoice amount
on success, or take some random number on failure.
This leaks some forward information, and makes an explicit tradeoff for
the sender between amount spent and privacy, but it's the best I've been
able to come up with.
Thoughts?
Rusty.
[1] If we assume $1 per GB, $10k per BTC and 64k messages, we get about
655msat per message. Flat pricing for simplicity; we're trying to
prevent spam, not create a spam market.
[2] Actually, a number and a single preimage; you can check this is
indeed the n'th preimage.
[3] This reduces incentive to grind the damn things in advance, though
maybe that's dumb? We can also use a shorter hash (siphash?), or
even truncated SHA256 (128 bits).

2023-06-09 14:54:29 CEST

- reply

📅 Original date posted:2019-03-20
📝 Original message:
Sorry AJ, my prior email was not constructive :(
I consider the "my software reused my keys" the most reasonable attack
scenario, though still small compared to other lightning attack surfaces.
But I understand the general wariness of third-parties reusing
SIGHASH_NOINPUT signatures.
Since "must have a non-SIGHASH_NOINPUT" rule addresses the first reuse
scenario (as well as the second), I'd be content with that proposal.
Future segwit versions may choose to relax it.[1]
Cheers,
Rusty.
[1] Must be consensus, not standardness; my prev suggestion was bogus.
Rusty Russell <rusty at rustcorp.com.au> writes:
> Anthony Towns <aj at erisian.com.au> writes:
>> If you publish to the blockchain:
> ...
>> 4 can be dropped, state 5 and finish can be altered). Since the CSV delay
>> is chosen by the participants, the above is still a possible scenario
>> in eltoo, though, and it means there's some risk for someone accepting
>> bitcoins that result from a non-cooperative close of an eltoo channel.
>
> AJ, this was a meandering random walk which shed very little light.
>
> I don't find the differentiation between malicious and non-malicious
> double-spends convincing. Even if you trust A, you already have to
> worry about person-who-sent-the-coins-to-A. This expands that set to be
> "miner who mined coins sent-to-A", but it's very hard to see what
> difference that makes to how you'd handle coins from A.
>
>> Beyond that, I think NOINPUT has two fundamental ways to cause problems
>> for the people doing NOINPUT sigs:
>>
>> 1) your signature gets applied to a unexpectedly different
>> script, perhaps making it look like you've being dealing
>> with some blacklisted entity. OP_MASK and similar solves
>> this.
>
> ... followed by two paragraphs describing how it's not a "fundamental
> way to cause problems" that you (or I) can see.
>
>> For the second case, that seems a little more concerning. The nightmare
>> scenario is maybe something like:
>>
>> * naive users do silly things with NOINPUT signatures, and end up
>> losing funds due to replays like the above
>
> As we've never seen with SIGHASH_NONE?
>
>> * initial source of funds was some major exchange, who decide it's
>> cheaper to refund the lost funds than deal with the customer complaints
>>
>> * the lost funds end up costing enough that major exchanges just outright
>> ban sending funds to any address capable of NOINPUT, which also bans
>> all taproot/schnorr addresses
>
> I don't find this remotely credible.
>
>> FWIW, I don't have a strong opinion here yet, but:
>>
>> - I'm still inclined to err on the side of putting more safety
>> measures in for NOINPUT, rather than fewer
>
> In theory, sure. But not feel-good and complex "safety measures" which
> don't actually help in practical failure scenarios.
>
>> - the "must have a sig that commits to the input tx" seems like it
>> should be pretty safe, not too expensive, and keeps taproot's privacy
>> benefits in the cases where you end up needing to use NOINPUT
>
> If this is considered necessary, can it be a standardness rule rather
> than consensus?
>
> Thanks,
> Rusty.

2023-06-09 14:54:28 CEST

- reply

📅 Original date posted:2019-03-19
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> If you publish to the blockchain:
...
> 4 can be dropped, state 5 and finish can be altered). Since the CSV delay
> is chosen by the participants, the above is still a possible scenario
> in eltoo, though, and it means there's some risk for someone accepting
> bitcoins that result from a non-cooperative close of an eltoo channel.
AJ, this was a meandering random walk which shed very little light.
I don't find the differentiation between malicious and non-malicious
double-spends convincing. Even if you trust A, you already have to
worry about person-who-sent-the-coins-to-A. This expands that set to be
"miner who mined coins sent-to-A", but it's very hard to see what
difference that makes to how you'd handle coins from A.
> Beyond that, I think NOINPUT has two fundamental ways to cause problems
> for the people doing NOINPUT sigs:
>
> 1) your signature gets applied to a unexpectedly different
> script, perhaps making it look like you've being dealing
> with some blacklisted entity. OP_MASK and similar solves
> this.
... followed by two paragraphs describing how it's not a "fundamental
way to cause problems" that you (or I) can see.
> For the second case, that seems a little more concerning. The nightmare
> scenario is maybe something like:
>
> * naive users do silly things with NOINPUT signatures, and end up
> losing funds due to replays like the above
As we've never seen with SIGHASH_NONE?
> * initial source of funds was some major exchange, who decide it's
> cheaper to refund the lost funds than deal with the customer complaints
>
> * the lost funds end up costing enough that major exchanges just outright
> ban sending funds to any address capable of NOINPUT, which also bans
> all taproot/schnorr addresses
I don't find this remotely credible.
> FWIW, I don't have a strong opinion here yet, but:
>
> - I'm still inclined to err on the side of putting more safety
> measures in for NOINPUT, rather than fewer
In theory, sure. But not feel-good and complex "safety measures" which
don't actually help in practical failure scenarios.
> - the "must have a sig that commits to the input tx" seems like it
> should be pretty safe, not too expensive, and keeps taproot's privacy
> benefits in the cases where you end up needing to use NOINPUT
If this is considered necessary, can it be a standardness rule rather
than consensus?
Thanks,
Rusty.

2023-06-09 14:53:31 CEST

- reply

📅 Original date posted:2018-12-12
📝 Original message:
Hi all,
In case you're bored with the limited range of improvements
going into the 1.1 spec, you might like to ruminate on:
https://github.com/sipa/minisketch/blob/master/README.md
It's a library for efficient summaries of data, such as bitcoin
transaction gossip. It has an implementation sweet-spot at 64-bits,
which almost works well for our gossip messages. I've a straw-man
protocol below.
===
1. type: 260 (`gossip_sync`) (`option_gossip_sync`)
2. data:
* [`32`:`chain_hash`]
* [`32`:`latest_block_hash`]
* [`minisketch_len`:`minisketch`]
The `latest_block_hash` is because the whole sync is less reliable if
this differs between nodes, so a node may choose to wait, or adapt
accordingly if the other node is behind.
Because there is some overhead in maintaining the minisketch, it'd be
nice if we can have global agreement on the format so each peer need
only maintain one (i.e. no seed, no changing encodings depending on
block height, etc).
Fitting everything we need into 64 bits is possible, with various
degrees of ugliness; I've proposed one here:
We currently use a short_channel_id which has 3-byte block height,
3-byte txindex, 2-byte output index. The biggest win is to combine
block height & txindex into a "txnumber since block 500,000", which only
needs about 27 bits per year; 40 bits for this number is sufficient for
the forseeable future. 2 bits for type, 1 for channel direction,
leaving 21 bits for output number and timestamp.
We can encode output number as N ones followed by a zero followed by
N*2+1 bits (commonly, this means 2 bits, but future mixers may make this
much larger). The remaining bits are used as the lower bits of the
timestamp[1].
A node announcement is encoded by using the scid of the oldest channel
associated with the node, and the direction bit.
Using this direct encoding (rather than a hash of values) allows us to
immediately use an INV-style query, or maybe send automatically the
stuff the peer doesn't have.
The required size of the minisketch we send depends on the number of
differences with our peer. We can use some minimum value (maybe based
on past gossip rates?), and add the number of changes we've received
since last time, increasing if we failed to reconstruct a previous one.
There doesn't need to be consensus between peers on the minisketch size
though, since truncated minisketches regrow into whole ones when tossed
back into the ocean[3].
Cheers,
Rusty.
[1] You're supposed to refresh gossip every week, 17 bits should
be sufficient. And since the originator controls timestamps
they can mitigate collisions themselves.[2]
[2] I wish I'd insisted we use block numbers for timestamps though
[3] I may have misunderstood this part, but it's basically magic.

2023-06-09 14:52:50 CEST

- reply

📅 Original date posted:2018-11-15
📝 Original message:
Hi all,
I want to propose a method of having reusable BOLT11 "offers" which
provide almost-spontaneous payments as well as not requiring generating
a BOLT11 invoice for each potential sale.
An "offer" has a `p` field of 26 bytes (128 bits assuming top two are 0)
(which is ignored by existing nodes). The payer uses a new lightning
probe message using the current onion format we use for HTLCs to
retreive the complete invoice.
The format of the final-hop lightning onion would contain:
[whatever-marker-we-need?][128-bit-`p`-field][[type,len,data]+]
We would probably define a few optional types to start:
1. quantity: for ordering multiple of an item, default 1.
2. delivery-address: steal from https://www.w3.org/TR/vcard-rdf/#Delivery_Addressing_Properties ?
3. signature: basically a blob so payer can prove it was them.
The return lightning message would contain a new bolt11 invoice (perhaps
we optimize some fields by copying from the bolt11 offer if they don't
appear?), and an additional field:
`m` (27) `data_length` 52. Merkle hash of fields payer provided
in onion msg above, and the offer `p` value.
The payer checks the signature is correct, `m` is correct, and uses the
invoice to pay as normal. The bolt11 offer + fields-from-onion + bolt11
invoice + preimage is the complete proof of payment.
Refinements
-----------
We can generate alternate leaves for the merkle tree (using
SHA256(shared-secret | leafnum)) so revealing the `m` value doesn't risk
revealing your delivery-address for example.
The return needs to list the fields it *didn't* include in the merkle
because it didn't accept them (the merchant doesn't want to be bound to
conditions it doesn't understand!).
We could add a `k` field to the bolt11 offer to allow the final invoice
to delegated to a separate key.
The default `x` (expiry) field for an offer which does not have an
old-style 53-byte `p` field (ie. a "pure" offer) could be infinite.
We could merkelize the delivery-address too :)
I've handwaved a bit over the detailed format, because there are other
things we want to put in the onion padding, and because the return is
similar to the "soft-error"/"partial payment ack" proposals.
Results
-------
This gives us static invoicing, and a single static invoice (without an
amount field) can thus be used to approximate "spontaneous" donations,
while still providing proof of payment; indeed, providing
non-transferrable proof-of-payment since the invoice now commits to the
payer-provided signature.
It also provides a platform for recurring payments: while we can do this
with preimage-is-next-payment_hash, that requires pre-generation and
isn't compatible with static invoices.
I apologize that this wasn't fleshed out before the summit, but I
overestimated the power of Scriptless Scripts so had mentally deferred
this.
Thanks!
Rusty.

2023-06-09 14:52:46 CEST

- reply

📅 Original date posted:2018-11-22
📝 Original message:
Conner Fromknecht <conner at lightning.engineering> writes:
> Hi all,
>
>> But it's unnecessary for the recipient to know the total amount I meant
>> to pay; they just need to return the receipt once it exceeds the amount
>> they want.
>
> I think it’s true that the recipient doesn’t need to know necessarily, but
> sending the intended amount is more robust IMO, since it provides an order
> invariant hint for when the receiver can safely settle.
>
> If the sender does amount fuzzing (as CL does) or adds a tip, it’s possible
> for the final partial payment to be less than `amount_to_pay` -
> `invoice_amount`, causing the sender to settle prematurely. Otherwise, we
> might want to specify that no split should be less than the amount
> overpaid.
>
> Of course, if that amount never comes through yet the invoice is satisfied,
> the receiver can always choose to settle even if the remaining amount never
> arrives.
It's more code, and takes 8 more bytes out of the onion. I've started
coding up option_simplfied_commitment and it's making me terrified of
adding any additional complexity :(
The more compelling argument is that partial-payment donations might
want this, but it's marginal, IMHO. We should be aiming for static
invoices for the donate case.
Cheers,
Rusty.

2023-06-09 14:52:45 CEST

- reply

📅 Original date posted:2018-11-20
📝 Original message:
René Pickhardt via Lightning-dev <lightning-dev at lists.linuxfoundation.org> writes:
> Hey List,
>
> as this base AMP proposal seems pretty small I just started to write this
> up to make a PR for BOLT04 and BOLT11. While doing my write up I realize
> that there are smaller things that I would want to verify / double check
> and propose with you.
>
> ## Verifying:
> 1.) I understand the receiving node signals support for Base AMP by setting
> a feature bit in the BOLT11 String
Yes, this seemed a logical reason to add features to BOLT11.
> 2.) The sending node signals a multipath payment by setting a feature bit
> and by using the same `amount to forward` value in the last hop of the
> onion for all paths which will also be bigger that the incoming htlcs whose
> sum has to be at least the size of `amount_to_forward`.
Not a feature bit as such, but some signal for the final node (in the
onion). And do not play with `amount_to_forward`, as it's an important
signal to the final node that the previous node did not offer less value
for the HTLC than it was supposed to. (You could steal the top bit to
signal partial payment if you really want to).
> ## Clarifying:
> 3.) Senders MUST NOT (SHOULD NOT?) create paths which would have to be
> merged by intermediary nodes (as we don't know - and have no means of
> querying - if they support the format of the adepted onion packages for
> partial paths. Also it even seems impossible since the rest of the path for
> at least one partial path could not be stored in the onion / forwarded
> onions can't be seen)
In-path merging is overreach, let's not do it or mention it.
There's a slight preference to avoid sharing intermediary nodes to avoid
correlation. Intermediary nodes know they need to forward all of them
or not get paid for any of them, and they're already supposed to do so.
> ## Proposing:
> Should we specify an algorithm for executing a multipath payment for the
> sending node or should this be left to the implementation. An obvious Idea
> for an algorithm would be a divide and conquer scheme which should be
> obvious with the following python style pseudo code:
>
> def pay_base_amp(amount):
> success = False
> for route in get_available_routes():
> success = send_via_route(route, amount)
> if not success:
> pay_base_amp(amount/2 + 1) # the +1 is to mitigate rounding errors.
> there could be other ways to do so.
> pay_base_amp(amount/2 + 1)
I don't think this is actually useful. For example, I would suggest a
more random split, and start by using some estimate of channel capacity.
> Even if we leave the exact AMP execution to the sender we could still
> suggest this divide and conquer scheme in BOLT 04
>
> Another idea I had (which is probably a bad one as it allows for probing of
> channel balances) would be to allow nodes on a partial path to send back
> some hints of how much additional capacity they can forward if they see
> that the partial payment feature bit is set (this would require to set this
> feature bit in every onion) Also if we want to make use of this information
> every node would have to support base amp. So I guess this idea is bad for
> several reasons. Still we could have a MAY rule out of it?
I think we should adapt a convention for a lower limit at which we
disable the channel if we can't forward (eg 1% of capacity? 100
satoshis?). That gives us a better starting point for AMP, too.
Cheers,
Rusty.

2023-06-09 14:52:06 CEST

- reply

📅 Original date posted:2018-11-05
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> FWIW, I don't see reddit as a particularly viable "court"; there's
> no way for reddit to tell who's actually right in a dispute, eg if I
> say blockstream didn't send stickers I paid for, and blockstream says
> they did; ie there's no need for a sock puppet in the above scenario,
> blockstream can just say "according to our records you signed for
> delivery, stop whinging".
Well, in that case they can show a tracking number and Canada Post link?
We will eventually develop systems of arbitration better than "whining
on reddit/twitter", but that's where bitcoin was in its early days, so I
use it as a useful starting point to think about receipts when we lack
an intermediary.
> I think there's maybe four sorts of "proof of payment" people might
> desire:
>
> 0) no proof: "completely" deniable payments (donations?)
>
> 1) shared secret: ability to prove directly to the payee that an
> invoice was paid (what we have now)
We also, importantly, have the ability to tie the receipt to the
invoice.
> 2) signed payment: ability to prove to a different business unit of
> the payee that payment was made, so that you can keep all the
> secrets in the payment-handling part, and have the service-delivery
> part not be at risk for losing all your money
Hmm, this requires auditing the current commitment transaction I think
("see, I'm holding the money!"). I have to think about this some
more...
> 3) third-party verifiable: so you can associate a payment with real
> world identity information, and take them to court (or reddit) as a
> contract dispute; needs PKI infrastructure so you can be confident
> the pubkey maps to the real world people you think it does, etc
Yes, we're still missing that last mile between the merchant and the
nodeid. There's a proposal to do this with DNS records, there's the
LetsEncrypt-style "serve this URL", but we also need something like
Certificate Transparency so I can reliably get old nodeids...
But the perfect is the enemy of the good, too.
Cheers,
Rusty.

2023-06-09 14:52:05 CEST

- reply

📅 Original date posted:2018-11-04
📝 Original message:
ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
> Good morning Rusty and aj and list,
>
>>
>> > > In the payer-supplied data case, I think 'm' should include a signature
>> > > for a key only the payer knows: this lets them prove they made the
>> > > payment.
>> >
>> > I don't object to that, but I think it's unnecessary; as long as there
>> > was a payment for delivery of the widget to "aj" in "Australia" does it
>> > matter if the payment was technically made by "aj" by "Visa on behalf
>> > of aj" or by "Bank of America on behalf of Mastercard on behalf of aj's
>> > friend who owed him some money" ?
>>
>> You often don't want the vendor to know anything about you, and there's
>> often no reason why they should.
>>
>> And it just doesn't work unless you give over uniquely identifying
>> information. AJ posts to r/bitcoin demonstrating payment, demanding his
>> goods. Sock puppet says "No, I'm the AJ in Australia" and cut & pastes
>> the same proof.
>>
>
> Technically speaking, all that AJ in Australia needs to show is that he or she knows, the private key behind the public key that is indicated on the invoice.
>
> Before payment, only the payee knows this private key.
>
> After payment, both AJ in Australia and the payee know this private key (since the payment is conditional on AJ in Australia learning this key).
But the merchant (payee) knows it too. So the lizard masters[1] at
Blockstream can produce this proof as well?
Cheers,
Rusty.
[1] https://twitter.com/rusty_twit/status/1057794540122206208

2023-06-09 14:52:04 CEST

- reply

📅 Original date posted:2018-11-04
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
>> In the payer-supplied data case, I think 'm' should include a signature
>> for a key only the payer knows: this lets them prove *they* made the
>> payment.
>
> I don't object to that, but I think it's unnecessary; as long as there
> was a payment for delivery of the widget to "aj" in "Australia" does it
> matter if the payment was technically made by "aj" by "Visa on behalf
> of aj" or by "Bank of America on behalf of Mastercard on behalf of aj's
> friend who owed him some money" ?
You often don't want the vendor to know anything about you, and there's
often no reason why they should.
And it just doesn't work unless you give over uniquely identifying
information. AJ posts to r/bitcoin demonstrating payment, demanding his
goods. Sock puppet says "No, I'm the AJ in Australia" and cut & pastes
the same proof.
Even if you did, that's exactly the problem we have now. *In theory*
the invoice should be specific enough that it identifies where they
shipped the item, in practice it never is (even the Blockstream store
gets this wrong!).
Sure, in case of digital delivery there's no proof that delivery
(didn't) happen, but you can at least show you paid.
>> How does this interact with AMP, however?
>
> The way I see it is they're separate: you have a way of getting the
> preimage back over lightning (which is affected by AMP), and you have a
> way of turning a preimage into a third-party-verifiable PoP (with
> Schnorr or whatever).
>
> (That might not be true if there's a clever way of safely feeding the
> nonce R back, so that you can go straight from a generic offer to an
> accepted payment with proof of payment)
>
>> > With seckp256k1 preimages, it's easy to reduce that to sig=(R,s),
>> > and needing to communicate an R to the payer initially, who can then
>> > calculate S and send "m" along with the payment.
>> OK, I buy that.
>
> Crap, do I need to give you proof of payment for it now? :)
Please :)
>> > - just send multiple payments with the same hash:
>> > works with sha256
>> > privacy not improved much (some intermediary nodes no longer know
>> > full invoice value)
>> > can claim partial payments as soon as they arrive
>> > accepting any partial payment provides proof-of-payment
>>
>> Interestingly, if vendor takes part payment, rest can be stolen by
>> intermediaries.
>
> Or you could just see a $5 bill, send $0.50 through, and wait to see
> if the take the partial payment immediately before even trying the
> remaining $4.50.
Sure, that's true today, too?
>> > - secp256k1: ("high AMP" ?)
>> > needs secp256k1 preimages
>> > works fine with decorrelation improving privacy at every step
>> > can set it up so can only claim once all partial payments arrive
>> > accepting partial payment provides proof-of-payment
>> Yes. Though I'm not sure exactly how this works with your scheme
>> above...
>
> Vendor -> *: "I sell widgets for 0.01 BTC, my pubkey is P"
> Customer -> Vendor: "I want to buy a widget"
> Vendor -> Customer: "Here's an R value"
> Customer: calculates S = R + H(P,R,"send $me a widget at $address")*P
> Customer -> Vendor: "here's 0.01 BTC for s corresponding to S, my
> details are R, $me, $address"
> Vendor: looks up r for R=r*G, calculates s = r + H(P,R,"send $me a
> widget at $address")*p, checks S=s*G
> Vendor -> Customer: <accepts payment, revealing s>
>
> Customer -> Court: reveals the invoice ("send $me a widget...") and the
> signature by Vendor's pubkey P, (s,R)
>
> I think the way to do secp256k1 AMP with that is that when sending
> through the payment is for the customer to send three payments to the
> Vendor conditional on preimages for A,B,C calculated as:
>
> A = S + H(1,secret)*G
> B = S + H(2,secret)*G
> C = S + H(3,secret)*G
Note: I prefer the construction H(<secret>,<part-of-secret-in-that-payment>)
which doesn't require an explicit order.
> where "secret" is your xor of info from each of the three message hashes.
Note that this only works if the message "send $me a widget at $address"
includes a nonce, since it may be easily grindable otherwise.
Since I'm suggesting it include a signature in msg, we're covered here.
We could chacha20 the msg in A, and just xor the key between other
payments for a bit of space saving.
>> > In theory, both "just send multiple payments" and "secp256k1" could have
>> > splitting and joining at any hop, if we could encode the instructions
>> > on how to do that in the onion message; joining is probably easy, but
>> > splitting seems like it might be hard?
>> I don't think so. If you can join two payments, it wasn't private?
>
> Sorry, I mean "source-directed splits and joins", so rather than
> your source routing being a linear "me -> A -> B -> C -> D -> you",
> you specify a graph: "me -> A -> B,E ; B -> C ; E -> F -> G ; C,G ->
> D -> you" so you tell "A" how to split the payment into two new routes,
> and tell "D" to join two payments and continue it on. The ECC part works
> fine for that, but the onion routed messages seem difficult and probably
> not worth considering for spec v1.1.
I'm not sure I see the benefit over just treating them independently,
so I also think we should defer.
>> [1] If we're not careful we're going to implement HORNET so we can pass
>> arbitrary messages around, which means we want to start charging for
>> them to prevent spam, which means we reopen the pre-payment debate, and
>> need reliable error messages...
>
> Could leave the interactivity to the "web store" layer, eg have a BOLT
> 11 v1.1 "offer" include a url for the website where you go an enter your
> name and address and whatever other info they need, and get a personalised
> BOLT 11 v1.1 "invoice" back with payment-hash/nonce/signature/whatever?
I think that's out-of-scope, and I generally dislike including a URL
since it's an unsigned externality and in practice has horrible privacy
properties.
Cheers,
Rusty.

2023-06-09 14:52:03 CEST

- reply

📅 Original date posted:2018-11-04
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
>> > - channel announcements: do you support secp256k1 for hashes or just
>> > sha256?
>> Worse, it becomes "I support secp256k1 with ECDSA" then a new "I support
>> secp256k1 with Schnorr". You need a continuous path of channels with
>> the same feature.
>
> I don't think that's correct: whether it's 2p-ecdsa, Schnorr or script
> magic only matters for the two nodes directly involved in the channel
> (who need to be able to understand the commitment transactions they're
> signing, and extract the private key from the on-chain tx if the channel
> gets unilaterally closed). For everyone else, they just need to know that
> they can put in a public key based HTLC, and get back the corresponding
> private key when the HTLC goes through.
I'm not sure. Jonas Nick proposed a scheme, which very much assumes
Schnorr AFAICT:
Jonas Nick wrote:
> How I thought it would work is that the invoice would contain a
> Schnorr nonce R. Then the payer would construct s*G = R +
> H(payee_pubkey,R,"I've bought 5 shirts shipped to Germany")*G. Then
> the payer builds the scriptless script payment path such that when the
> payee claims, the payer learns s and thus has a complete
> signature. However, that doesn’t work with recurrent payments because
> the payee can use the nonce only once.
I would probably enhance this to include a nonce, which allows for AMP
(you have to xor the AMP payments to get the nonce):
R + H(payee_pubkey,R,"I've bought 5 shirts shipped to Germany",NONCE)*G
> I think it makes sense to think of proof-of-payment in terms of a
> verification algorithm (that a third party court could use), that takes:
>
> m - the invoice details, eg
> "aj paid $11 for stickers to be delivered to Australia"
> P - the pubkey of the vendor
> sig - some signature
>
> With the current SHA256 preimages, you can make sig=(R,s,pre)
> where the sig is valid if:
>
> s*G = R + H(P,R,m+SHA256(pre))*P
>
> If you share R,s,SHA256(pre) beforehand, the payer can tell they'll have
> a valid signature if they pay to SHA256(pre). That's a 96B signature,
> and it requires "pre" be different for each sale, and needs pre-payment
> interactivity to agree on m and communicate R,s back to the payer.
For current-style invoices (no payer-supplied data), the payee knows
'm', so no interactivity needed, which is nice.
In the payer-supplied data case, I think 'm' should include a signature
for a key only the payer knows: this lets them prove *they* made the
payment.
How does this interact with AMP, however?
> With seckp256k1 preimages, it's easy to reduce that to sig=(R,s),
> and needing to communicate an R to the payer initially, who can then
> calculate S and send "m" along with the payment.
OK, I buy that.
> Maybe it makes sense to disambiguate the term "invoice" -- when you don't
> know who you might be giving the goods/service to, call it an "offer",
> which can be a write-once/accept-by-anyone deal that you just leave on
> a webpage or your email signature; but an "invoice" should be specific
> to each individual payment, with a "receipt" provided once an invoice
> is paid.
"offer" is a good name, since I landed on the same one while thinking
about this too :)
For an "offer" you would need a (lightning-network-carried) req/resp to
get the per-payment invoice. An offer could use a 128-bit 'p': smaller
would do, but this is too large to brute-force iterate through (hey, I
wonder if they sell other stuff?).
> Rereading through the AMP threads, Christian's post makes a lot of sense
> to me:
>
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/001023.html
>
> I'm not really seeing the benefits in complicated AMP schemes without
> decorrelation...
In practice it should increase reliability of payments through capacity
bottlenecks. But don't underestimate the benefits of PoP: we're so used
to intermediates we take it for granted, but once the middleman is
removed the ability to prove the invoice/payment cycles is vital for
usability.
> It seems to me like there are three levels that could be implemented:
>
> - laolu/conner: ("low AMP" ?)
> works with sha256
> some privacy improvement
> loses proof-of-payment
> can't claim unless all payments arrive
Yep.
> - just send multiple payments with the same hash:
> works with sha256
> privacy not improved much (some intermediary nodes no longer know
> full invoice value)
> can claim partial payments as soon as they arrive
> accepting any partial payment provides proof-of-payment
Interestingly, if vendor takes part payment, rest can be stolen by
intermediaries. This puts pressure on vendor to treat them atomically.
I haven't thought about this before, but it has desirable attributes.
(If the contract is "you will only release preimage once you've got the
payment", all this requires is a single bit to say "I know this is
partial, more are coming, please wait").
> - secp256k1: ("high AMP" ?)
> needs secp256k1 preimages
> works fine with decorrelation improving privacy at every step
> can set it up so can only claim once all partial payments arrive
> accepting partial payment provides proof-of-payment
Yes. Though I'm not sure exactly how this works with your scheme
above...
> In theory, both "just send multiple payments" and "secp256k1" could have
> splitting and joining at any hop, if we could encode the instructions
> on how to do that in the onion message; joining is probably easy, but
> splitting seems like it might be hard?
I don't think so. If you can join two payments, it wasn't private? For
splitting, in the specific case of having two channels between the same
nodes, you might be able to do something, but that's a pretty narrow
case. And as TCP discovered, you're better off failing back to sender
than trying to add fragmentation to the protocol.
Note: if we need an interaction message for BOLT11 features we want in
future[1], then it has the advantage that it decouples the bolt11
features from changing preimages to secp256k1. That makes this question
*critical* for the Summit next week.
Thanks!
Rusty.
[1] If we're not careful we're going to implement HORNET so we can pass
arbitrary messages around, which means we want to start charging for
them to prevent spam, which means we reopen the pre-payment debate, and
need reliable error messages...

2023-06-09 14:52:01 CEST

- reply

📅 Original date posted:2018-11-02
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> On Fri, Nov 02, 2018 at 10:20:46AM +1030, Rusty Russell wrote:
>> There's been some discussion of what the lightning payment flow
>> might look like in the future, and I thought I'd try to look forwards so
>> we can avoid painting ourselves into a corner now. I haven't spent time
>> on concrete design and implementation to be sure this is correct,
>> however.
>
> I think I'd like to see v1.1 of the lightning spec include
> experimental/optional support for using secp256k1 public/private keys
> for payment hashes/preimages. That assumes using either 2-party ECDSA
> magic or script magic until it's viable to do it via Schnorr scriptless
> scripts, but that seems like it's not totally infeasible?
Not totally infeasible, but since every intermediary needs to support
it, I think we'd need considerable buy-in before we commit to it in 1.1.
> I think the
> components would need to be:
>
> - invoices: will the preimage for the hash be a secp256k1 private key
> or a sha256 preimage? (or payer's choice?)
>From BOLT11:
The `p` field supports the current 256-bit payment hash, but future
specs could add a new variant of different length, in which case
writers could support both old and new, and old readers would ignore
the one not the correct length.
So the plan would be you provide two `p` fields in transition.
> - channel announcements: do you support secp256k1 for hashes or just
> sha256?
Worse, it becomes "I support secp256k1 with ECDSA" then a new "I support
secp256k1 with Schnorr". You need a continuous path of channels with
the same feature.
> - node features: how do you support secp256k1? not at all (default),
> via 2p-ecdsa, via script magic, (eventually) via schnorr, ...?
We could make these global feature bits, if you want to preferentually
establish channels with nodes who support a specific feature.
> I think this is (close to) a necessary precondition for payment
> decorrelation, AMP, and third-party verifiable proof-of-payment.
Yes, that's the easy part :)
...
> Even if you calculate r differently, I don't think you can do this
> without Bob and Alice interacting to get the nonce R prior to sending
> the transaction, which seems effectively the same as having dynamic
> invoice hashes, though.
I know Andrew Poelstra thought it was possible, so I'm going to leave a
response to him :)
> Maybe querying for a nonce through the lightning network would make
> sense though, which would allow the "invoice" to be static, and all the
> dynamic things would be via lightning p2p? That step could perhaps be
> combined with the 0 satoshi payment probes that Fabrice proposes in
>
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-October/001484.html
>
> but I think replying with a public nonce value would need a new message
> type of some sort?
We might eventually end up going full HORNET, for other reasons. But it
places demands on the network which need careful consideration, and the
more traffic you send the more chances for analysis. A single pass is
enough.
> I think AMP is independent, other than also using secp256k1 preimages
> rather than SHA256. I think AMP splits and joins are just:
>
> - if you're joining incoming payments, don't forward until you've
> got all the HTLCs, and ensure you can generate the secret for each
> incoming payment from the single outgoing payment
>
> - if you're splitting an incoming payment into many outgoing payments,
> ensure you can claim the incoming payment from *any* outgoing
> payments' secret
>
> Which I think in practice just means knowing x_i for each input, and
> y_j for each output other than the first, and verifying:
>
> I_i = O_1 + x_i*G
> O_j = O_1 + y_j*G
>
> (this gives I_i = O_j + (x_i-y_j)*G and the corresponding secret being
> i_i = o_j + x_i - y_j) allowing you to claim all incoming HTLCs given
> the secret from any outgoing HTLC)
I think a general scheme is: payer creates a random group-marker, sends
<group-marker><32-byte-randomness>[encrypted data...] in each payment.
Receipient collects payments by <group-marker>, xoring the
<32-byte-randomness>; if that xor successfully decrypts the data, you've
got all the pieces.
(For low-AMP, you use payment_hash as <group-marker>, and just use
SHA256(<xor-of-all-randomness><32-byte-randomness>) as the per-payment
preimage so no [encrypted data] needed).
Cheers,
Rusty.

2023-06-09 14:52:01 CEST

- reply

📅 Original date posted:2018-11-01
📝 Original message:
Hi all,
There's been some discussion of what the lightning payment flow
might look like in the future, and I thought I'd try to look forwards so
we can avoid painting ourselves into a corner now. I haven't spent time
on concrete design and implementation to be sure this is correct,
however.
Current Status
--------------
Currently, one invoice can be paid 0 or 1 times. There is no safe
invoice reuse. The payer can prove the node offered the invoice (it is
signed), and that someone paid the invoice, but not that they
specifically did: the lightning nodes along the path and the merchant
themselves also have the preimage. This implies that the invoice itself
should have enough information to make that link, eg. with a description
of "1 T-shirt to Rusty in Australia", otherwise the payer can say "here,
I paid for 1 T-shirt" and the merchant says "no, that invoice was for a
T-shirt we shipped to Austria".
Desired Status
--------------
Ideally, you could create one invoice which could be paid arbitrary many
times, by different individuals. eg. "My donation invoice is on my web
page", or "I've printed out the invoice for a widget and stuck it to the
widget", or "Pay this invoice once a month please".
Also, you should be able to prove you've paid, in a way I can't just
copy the proof and claim I paid, too, even if I'm the merchant, and that
you agreed to my terms, eg. "I'm paying for 500 widgets to be shipped to
Rusty in Australia".
Required Magic
--------------
It seems that scriptless scripts will allow this: an HTLC signature
would commit to the invoice/"payment_hash" as well as "something I sent
to you in the payment onion". That "something" has to be well-defined
in the protocol, of course, since the merchant will have to parse it and
understand the conditions it presents before accepting the payment. I
have an idea that we could merkelize the information to allow you to
partially reveal it if you wanted to.
This also enables full AMP (I think), where you receive the payment
proof despite using AMP. I call this "High AMP" vs the current proposal
("Low AMP") which trusts the merchant to deliver.
This is a subtle change in semantics: currently the lightning layer only
provides assistance metadata (eg. routing), and the entire protocol can
be played out onchain. This is no longer true: the onchain data is not
sufficient for you to accept a payment. However, this was practically
untrue anyway.
Lesser Magic
------------
It's possible to do spontaneous donations *without* proof of payment
today (I simply give you the preimage in the onion). Low-AMP relies on a
similar trick.
It's even possible to do recurring payments, if each preimage you get is
the payment_hash for the next payment.
None of this is supported in the 1.0 protocol, but I'm sure we'll have
vigorous debate over how much of this gets into 1.1 at the Summit next
week.
Cheers,
Rusty.

2023-06-09 14:51:49 CEST

- reply

📅 Original date posted:2018-10-12
📝 Original message:
Hi all,
There have been a number of suggested changes to the commitment
transaction format:
1. Rather than trying to agree on what fees will be in the future, we
should use an OP_TRUE-style output to allow CPFP (Roasbeef)
2. The `remotepubkey` should be a BIP-32-style, to avoid the
option_data_loss_protect "please tell me your current
per_commitment_point" problem[1]
3. The CLTV timeout should be symmetrical to avoid trying to game the
peer into closing. (Connor IIRC?).
It makes sense to combine these into a single `commitment_style2`
feature, rather than having a testing matrix of all these disabled and
enabled.
BOLT #2:
- If `commitment_style2` negotiated, update_fee is a protocol error.
This mainly changes BOLT #3:
- The feerate for commitment transactions is always 253 satoshi/Sipa.
- Commitment tx always has a P2WSH OP_TRUE output of 1000 satoshi.
- Fees, OP_TRUE are always paid by the initial funder, because it's simple,
unless they don't have funds (eg. push_msat can do this, unless we remove it?)
- HTLC-timeout and HTLC-success txs sigs are
SIGHASH_ANYONECANPAY|SIGHASH_SINGLE, so you can Bring Your Own Fees.
- `localpubkey`, `remotepubkey`, `local_htlcpubkey`,
`remote_htlcpubkey`, `local_delayedpubkey`, and `remote_delayedpubkey`
derivation now uses a two-stage unhardened BIP-32 derivation based on
the commitment number. Two-stage because we can have 2^48 txs and
BIP-32 only supports 2^31: the first 17 bits are used to derive the
parent for the next 31 bits?
- `to_self_delay` for both sides is the maximum of either the
`open_channel` or `accept_channel`.
- `to_remote` is now a P2WSH of:
`to_self_delay` OP_CSV OP_DROP <remotepubkey> OP_CHECKSIG
Cheers,
Rusty.
[1] I recently removed checking this field from c-lightning, as I
couldn't get it to reliably work under stress-test. I may just have
a bug, but we could just fix the spec instead, then we can get our
funds back even if we never talk to the peer.

2023-06-09 14:51:39 CEST

- reply

📅 Original date posted:2018-10-16
📝 Original message:
Rusty Russell <rusty at rustcorp.com.au> writes:
> If we're going to do side splice-in like this, I would use a very
> different protocol: the reason for this protocol was to treat splice-in
> and splice-out the same, and inline splice-in requires wait time. Since
> splice-out doesn't, we don't need this at all.
>
> It would look much more like:
>
> 1. Prepare any output with script of specific form. eg:
> OP_DEPTH 3 OP_EQUAL OP_IF
> <funding_pubkey1> <funding_pubkey2> OP_CHECKMULTISIG
> OP_ELSE
> <blockheight> OP_CHECKLOCKTIMEVERIFY OP_DROP
> <myrescue_pubkey> OP_CHECKSIG
> OP_ENDIF
>
> 1. type: 40 (`splice_in`) (`option_splice`)
> 2. data:
> * [`32`:`channel_id`]
> * [`8`: `satoshis`]
> * [`32`: `txid`]
> * [`4`: `txoutnum`]
> * [`4`: `blockheight`]
> * [`33`: `myrescue_pubkey`]
>
> 1. type: 137 (`update_splice_in_accept`) (`option_splice`)
> data:
> * [`32`:`channel_id`]
> * [`32`: `txid`]
> * [`4`: `txoutnum`]
>
> 1. type: 138 (`update_splice_in_reject`) (`option_splice`)
> data:
> * [`32`:`channel_id`]
> * [`32`: `txid`]
> * [`2`:`len`]
> * [`len`:`errorstr`]
>
> The recipient of `splice_in` checks that it's happy with the
> `blockheight` (far enough in future). Once it sees the tx referred to
> buried to its own `minimum_depth`, it checks output is what they
> claimed, then sends `update_splice_in_accept`; it's followed up
> `commitment_signed` like normal, but from this point onwards, all
> commitment txs signatures have one extra sig.
Lisa started asking pointed questions, and so I noticed that parallel
splice doesn't work with Poon-Dryja channels.
The counterparty can spend the old funding txout with a revoked spend.
Sure, I can take all the money from that, but what about the spliced
input?
I came up with increasingly elaborate workarounds, but nothing stuck.
Back to Plan A...
Rusty.

2023-06-09 14:51:38 CEST

- reply

📅 Original date posted:2018-10-12
📝 Original message:
Christian Decker <decker.christian at gmail.com> writes:
> On Thu, Oct 11, 2018 at 3:40 AM Rusty Russell <rusty at rustcorp.com.au> wrote:
>
>> > * Once we have enough confirmations we merge the channels (either
>> > automatically or with the next channel update). A new commitment tx is
>> > being created which now spends each output of each of the two funding tx
>> > and assigns the channel balance to the channel partners accordingly to
>> the
>> > two independent channels. The old commitment txs are being invalidated.
>> > * The disadvantage is that while splicing is not completed and if the
>> > funder of the splicing tx is trying to publish an old commitment tx the
>> > node will only be punished by sending all the funds of the first funding
>> tx
>> > to the partner as the special commitment tx of the 2nd output has no
>> newer
>> > state yet.
>>
>> Yes, this is the alternative method; produce a parallel funding tx
>> (which only needs to support a single revocation, or could even be done
>> by a long timeout) and then join them when it reaches the agreed depth.
>>
>> It has some elegance; particularly because one side doesn't have to do
>> any validation or store anything until it's about to splice in. You get
>> asked for a key and signature, you produce a new one, and sign whatever
>> tx they want. They hand you back the tx and the key you used once it's
>> buried far enough, and you check the tx is indeed buried and the output
>> is the script you're expecting, then you flip the commitment tx.
>>
>> But I chose chose not to do this because every transaction commitment
>> forever will require 2 signatures, and doesn't allow us to forget old
>> revocation information.
>>
>> And it has some strange side-effects: onchain this looks like two
>> channels; do we gossip about both? We have to figure the limit on
>> splice-in to make sure the commitment tx stays under 400kSipa.
>>
>
> This is a lot closer to my original proposal for splicing, and I
> still like it a lot more since the transition from old to new
> channel is bascially atomic (not having to update state on both
> pre-splice and post-splice version). The new funds will remain
> unavailable for the same time, and since we allow only one
> concurrent splice in your proposal we don't even lose any
> additional time regarding the splice-outs.
>
> So pulling the splice_add_input and splice_add_output up to
> signal the intent of adding funds to a splice. Splice_all_added
> is then used to start moving the funds to a pre-allocated 2-of-2
> output where the funds can mature. Once the funds are
> matured (e.g., 6 confirmations) we can start the transition: both
> parties claim the funding output, and the pre-allocated funds, to
> create a new funding tx which is immediately broadcast, and we
> flip over to the new channel state. No need to keep parallel
> state and then disambiguating which one it was.
If we're going to do side splice-in like this, I would use a very
different protocol: the reason for this protocol was to treat splice-in
and splice-out the same, and inline splice-in requires wait time. Since
splice-out doesn't, we don't need this at all.
It would look much more like:
1. Prepare any output with script of specific form. eg:
OP_DEPTH 3 OP_EQUAL OP_IF
<funding_pubkey1> <funding_pubkey2> OP_CHECKMULTISIG
OP_ELSE
<blockheight> OP_CHECKLOCKTIMEVERIFY OP_DROP
<myrescue_pubkey> OP_CHECKSIG
OP_ENDIF
1. type: 40 (`splice_in`) (`option_splice`)
2. data:
* [`32`:`channel_id`]
* [`8`: `satoshis`]
* [`32`: `txid`]
* [`4`: `txoutnum`]
* [`4`: `blockheight`]
* [`33`: `myrescue_pubkey`]
1. type: 137 (`update_splice_in_accept`) (`option_splice`)
data:
* [`32`:`channel_id`]
* [`32`: `txid`]
* [`4`: `txoutnum`]
1. type: 138 (`update_splice_in_reject`) (`option_splice`)
data:
* [`32`:`channel_id`]
* [`32`: `txid`]
* [`2`:`len`]
* [`len`:`errorstr`]
The recipient of `splice_in` checks that it's happy with the
`blockheight` (far enough in future). Once it sees the tx referred to
buried to its own `minimum_depth`, it checks output is what they
claimed, then sends `update_splice_in_accept`; it's followed up
`commitment_signed` like normal, but from this point onwards, all
commitment txs signatures have one extra sig.
Similarly, splice-out:
1. type: 139 (`update_splice_out`) (`option_splice`)
* [`32`:`channel_id`]
* [`8`: `satoshis`]
* [`2`: `scriptlen`]
* [`scriptlen`: `outscript`]
The recipient checks that the output script is standard, and the amount
can be afforded by the other side. From then on, each commitment tx has
a new output.
Note this doesn't put the splice out on the blockchain!
1. type: 140 (`propose_reopen`) (`option_splice`)
* [`32`:`channel_id`]
* [`4`:`feerate_per_kw`]
* [`33`:`funding_pubkey`]
This is initiates a mutually-agreed broadcast of the current state: all
inputs (original and spliced), all spliced outputs, and a funding-style
2x2 which has all the remaining funds. Call this a 'reopen tx'.
This must be done with no outstanding commitments, like closing tx
negotiation, and it's a back-and-forth until both sides agree on
feerate. Then you send:
1. type: 141 (`reopen_accept`) (`option_splice`)
* [`32`:`channel_id`]
* [`4`:`feerate_per_kw`]
* [`64`: `new_commitment_sig`]
Once you've received and sent this, you're ready to sign the reopen tx:
1. type: 142 (`reopen`) (`option_splice`)
* [`32`:`channel_id`]
* [`64`: `reopen_commitment_sig`]
We need similar 'what happens on reconnect at various points' logic to
the previous one <handwave>.
Once you've sent and received the `reopen`, you can broadcast the reopen
tx at will and start updating again. If we recommend that public
channels reuse their old `funding_pubkey` then that means that we should
also have gossip continuity for upgraded nodes, and don't need the
previous channel_update hack.
We could add a new `reopen_locked` message which indicates that both
sides are happy with the reopen depth, if we don't want to allow reopens
back-to-back?
> This is one of the cases where a simpler solution (relatively
> speaking ^^) is to be preferred imho, allowing for future
> iterations.
Unless we can have both :)
Cheers,
Rusty.

2023-06-09 14:51:37 CEST

- reply

📅 Original date posted:2018-10-10
📝 Original message:
René Pickhardt <r.pickhardt at googlemail.com> writes:
> So let us take the example of Splicing in:
> * The situation before splicing is that we have one output in our funding
> tx that is being spent with each commitment tx. (actually if the channel
> was spliced before we have more inputs but that should not change anything)
> * Splice in would create one additional output that can be spent in future
> commitment tx.
> * I propose while splicing in this output should be spent by a special
> commitment tx which goes to the funder of the splicing operation. This
> should happen before the actual funding takes place. The other commitment
> tx spending the original output continues to operate (assuring non blocking
> splice in operation).
> * Once we have enough confirmations we merge the channels (either
> automatically or with the next channel update). A new commitment tx is
> being created which now spends each output of each of the two funding tx
> and assigns the channel balance to the channel partners accordingly to the
> two independent channels. The old commitment txs are being invalidated.
> * The disadvantage is that while splicing is not completed and if the
> funder of the splicing tx is trying to publish an old commitment tx the
> node will only be punished by sending all the funds of the first funding tx
> to the partner as the special commitment tx of the 2nd output has no newer
> state yet.
Yes, this is the alternative method; produce a parallel funding tx
(which only needs to support a single revocation, or could even be done
by a long timeout) and then join them when it reaches the agreed depth.
It has some elegance; particularly because one side doesn't have to do
any validation or store anything until it's about to splice in. You get
asked for a key and signature, you produce a new one, and sign whatever
tx they want. They hand you back the tx and the key you used once it's
buried far enough, and you check the tx is indeed buried and the output
is the script you're expecting, then you flip the commitment tx.
But I chose chose not to do this because every transaction commitment
forever will require 2 signatures, and doesn't allow us to forget old
revocation information.
And it has some strange side-effects: onchain this looks like two
channels; do we gossip about both? We have to figure the limit on
splice-in to make sure the commitment tx stays under 400kSipa.
> I believe splicing out is even safer:
> * One just creates a spent of the funding tx which has two outputs. One
> output goes to the recipient of the splice out operation and the second
> output acts as a new funding transaction for the newly spliced channel.
> Once signatures for the new commitment transaction are exchanged (basically
> following the protocol to open a channel) the splicing operation can be
> broadcasted.
>
> * The old channel MUST NOT be used anymore but the new channel can be
> operational right away without blockchain confirmation. In case someone
> tries to publish an old state of the old channel it will be a double spent
> of the splicing operation and in the worst case will be punished and the
> splicing was not successful.
>
> if one publishes an old state of the new
> channel everything will just work as normal even if the funding tx is not
> yet mined. It could only be replaced with an old state of the previous
> channel (which as we saw is not a larger risk than the usual operation of a
> lightning node)
Right, you're relying on CPFP pushing through the splice-out tx if it
gets stuck. This requires that we check carefully for standardness and
other constraints which might prevent this; for example, we can't allow
more than 20 (?) of these in a row without being sufficiently buried
since I think that's where CPFP calculations top out.
> As mentioned maybe you had this workflow already in your mind but I don't
> see why we need to send around all the messages twice with my workflow. We
> only need to maintain double state but only until it is fair / safe to do
> so. I would also believe that with my approach it should be possible (but
> not really necessary) to have multiple splicing operations in parallel.
The extra sigs are only needed in transition, though; once splicing is
over the channel looks exactly like a newly created one, which is nice.
> One other question: What happens to the short_channel_id of a channel to
> which founds have been spliced in?
In the parallel splice world, they look like two channels. In my
proposal it looks like a new channel, with a channel_update to make sure
modern nodes know that the transition is happening.
Cheers,
Rusty.

2023-06-09 14:51:35 CEST

- reply

📅 Original date posted:2018-10-10
📝 Original message:
Hi all!
We've had increasing numbers of c-lightning users get upset they
can't open multiple channels, so I guess we're most motivated to allow
splicing of existing channels. Hence this rough proposal.
For simplicity, I've chosen to only allow a single splice at a time.
It's still complex :(
Feedback welcome!
--
Splice Negotiation:
1. type: 40 (`splice_add_input`) (`option_splice`)
2. data:
* [`32`:`channel_id`]
* [`8`: `satoshis`]
* [`32`: `prevtxid`]
* [`4`: `prevtxoutnum`]
* [`2`: `scriptlen`]
* [`scriptlen`: `scriptpubkey`]
1. type: 41 (`splice_add_output`) (`option_splice`)
2. data:
* [`32`:`channel_id`]
* [`8`: `satoshis`]
* [`2`: `scriptlen`]
* [`scriptlen`: `outscript`]
1. type: 42 (`splice_all_added`) (`option_splice`)
2. data:
* [`32`:`channel_id`]
* [`4`:`feerate_per_kw`]
* [`4`:`minimum_depth`]
Each side sends 0 or more `splice_add_input` and 0 or more
`splice_add_output` followed by `spice_all_added` to complete the splice
proposal. This is done either to initiate a splice, or to respond to a
`splice_*` from the other party.
`splice_add_input` is checked for the following:
- must not be during a current splice
- scriptpubkey is empty, or of form 'HASH160 <20-byte-script-hash> EQUAL'
- `satoshis` doesn't wrap on addition.
- MAY check that it matches outpoint specified (sig will simply be
invalid if so), and that outpoint is segwit.
`splice_add_output` is checked for the following:
- must not be during a current splice
- `satoshis` is less than or equal to amount owing to proposer, minus
current reserve, and greater than or equal to `dust_limit_satoshis` we
sent in our open_channel/accept_channel ,sg.
- script is one of the approved forms as it is for `shutdown`.
FIXME: Do we disallow splice-out if they specified
option_upfront_shutdown_script?
`splice_all_added` is checked for the following:
- average of `feerate_per_kw` by both sides (round down) is sufficient.
- average of `feerate_per_kw` by both sides not grossly excessive, if we're
paying some of the fees (see below!)
- both sides can afford the fees from their post-splice funds (see
Verification Changes below)
- maximum of the two `minimum_depth` is not grossly excessive.
- There is at least one splice_add_input or splice_add_output.
Splice negotiation, like closing negotiation, does not have persistent
state. Reconnecting forgets previous negotiation.
Splice Signing
--------------
Once `splice_all_added` is both sent and received, we need to create and
sign both the splice tx itself, and the first commitment transaction
which spends it (but not in that order!).
1. One input spends the current funding tx output.
2. There is one additional input for each splice_add_input.
3. One output creates the new funding tx.
4. There is one additional output for each splice_add_output.
5. The entire transaction is sorted into BIP69 order.
6. The feerate is the sum of the two `feerate_per_kw` divided by 2,
rounded down.
1. type: 43 (`splice_commitment_signature`) (`option_splice`)
2. data:
* [`32`:`channel_id`]
* [`64`:`commitment_signature`]
* [`2`:`num_htlcs`]
* [`num_htlcs*64`:`htlc_signature`]
1. type: 44 (`splice_signature`) (`option_splice`)
2. data:
* [`32`:`channel_id`]
* [`64`:`splice_signature`]
1. type: 45 (`splice_witness`) (`option_splice`)
2. data:
* [`32`:`channel_id`]
* [`2`: `num_witness_elements`
* [`2`:`len`]
* [`len`:`witnesses`]
`witnesses` itself is serialized as `num_witness_elements` of:
* `2`:`len`
* `len`: `witness_element`
Each side sends `splice_commitment_signature` and waits to receive and
verify the other side's `splice_commitment_signature` before sending
`splice_signature` and `splice_witness` for each `splice_add_input` it
proposed, in BIP69 input order.
Once a node has sent `splice_commitment_signature` it should remember
the splice proposal across reconnects. Once it has both sent
`splice_signature`, the splice is locked in.
Splice Announcement
-------------------
We have to tell the network about the new channel, otherwise there will
be a distruption when it sees the old funding transaction spent. This
is inevitable for older nodes who won't understand splicing anyway.
We can't send out a `channel_announcement` or `channel_update` for the
new channel until after the new funding transaction has 6 confirmations,
so we append to the existing `channel_update` for the original channel,
using a new `message_flags` field:
| Bit Position | Name | Field |
| ------------- | ------------------------- | -------------------------------- |
| 0 | `option_channel_htlc_max` | `htlc_maximum_msat` |
| 1 | `option_channel_moving` | `moving_txid |
The `channel_update` gains the following field:
* [`32`: moving_txid`] (option_channel_moving)
If a current `channel_update` for a closing channel contains
`option_channel_moving` a node SHOULD ignore the channel close for at
least 100 blocks iff spent by `moving_txid`.
A node SHOULD immediately forward a `channel_update` it sees containing
`option_channel_moving` if neither previous `channel_update` for the
channel contains `option_channel_moving`.
Each side of the splice can send these unilaterally, and SHOULD allow a
few minutes for propagation (remember, average propagation from old
nodes is still 30 seconds) prior to broadcast of the splice transaction.
Message Changes During Splicing
-------------------------------
Once you've sent `splice_commitment_signature` each commitment
transaction is duplicated: one spends the old funding transaction, one
spends the splice transaction:
1. type: 39 (`closing_signed`)
2. data:
* [`32`:`channel_id`]
* [`8`:`fee_satoshis`]
* [`64`:`signature`]
* [`64`:`splice_signature`] (`option_splice`)
1. type: 132 (`commitment_signed`)
2. data:
* [`32`:`channel_id`]
* [`64`:`signature`]
* [`2`:`num_htlcs`]
* [`num_htlcs*64`:`htlc_signature`]
* [`num_htlcs*64`:`htlc_splice_signature`] (`option_splice`)
If a reconnection occurs between between sending and receiving
`splice_commitment_signature`) the peer's status is uncertain (similarly
for closing). This we have a new field in `channel_reestablish` to flag
that we consider ourselves to be splicing:
1. type: 136 (`channel_reestablish`)
2. data:
* [`32`:`channel_id`]
* [`8`:`next_local_commitment_number`]
* [`8`:`next_remote_revocation_number`]
* [`32`:`your_last_per_commitment_secret`] (`option_data_loss_protect`)
* [`33`:`my_current_per_commitment_point`] (`option_data_loss_protect`)
* [`32`:`splice_txid`] (`option_splice`)
The splice_txid field indicates that this side considers itself to be
splicing.
The sender:
- if it has sent `splice_commitment_signature` and not sent the corresponding
`splice_closed`, MUST set `splice_txid` to the txid of the splice tx.
- Otherwise MUST NOT.
The recipient:
- if it has sent `splice_commitment_signature` and not sent the corresponding
`splice_closed`:
- if `splice_txid` does not exist or does not match the current splice:
- SHOULD fail the channel
- otherwise:
- MUST retransmit `splice_signature`
- otherwise:
- if `splice_txid` field exists and is not all zeroes:
- MUST send `splice_closed`
Validation Changes During Splicing
----------------------------------
We track "post-splice" values as well as current values during
splicing.
The post-splice reserve is 1% of post-splice capcacity (rounded down).
The fees for the splicing transaction itself are divided into parts by
the number of `splice_add_input` plus `splice_add_output`, rounded up.
Each side pays as many parts as it proposed `splice_add_input` plus
`splice_add_output`.
(So if Alice proposes two and Bob proposes one, and the total fee is 1000
satoshi, each part is 334 satoshi: Alice pays 668 and Bob pays 334.)
Each side's post-splice funds are debited their `splice_add_output`
amounts, and credited their `splice_add_input` amounts, a debited the
splice tx fees. If any debiting occurs, the funds must be above the
post-splice reserve (ie. you can have below reserve, but you can't spend
if you're below reserve).
All update_add_htlc must be valid for the *both* the current and
post-splice balances.
Completing Splicing
-------------------
Once you've seen both side's `minimum_depth` confirmations of the splice
transaction (ie. the maximum of the two `minimum_depth` values), you can
complete the splice by sending:
1. type: 46 (`splice_closed`) (`option_splice`)
2. data:
* [`32`:`channel_id`]
Once you've sent and received `splice_closed` you can send
`announcement_signatures` for the new channel as per normal rules (ie. 6
confirmations, `announce_channel` bit set).
In addition, you can forget everything about the old channel (including
old HTLCs and revocation requirements).

2023-06-09 14:51:33 CEST

- reply

📅 Original date posted:2018-10-09
📝 Original message:
Pierre <pm+lists at acinq.fr> writes:
>> But there's no reason to believe that the invoicer has more knowledge about all but the last hop.
>
> I disagree: there is a good chance that the receiver is a 24/7 running
> merchant/website, with a full up-to-date view of the network, whereas
> the payer is most likely a mobile wallet with less
> accurate/partial/out of date information.
>
> At least this is what we are seeing on the current mainnet. Routing
> table sync is hard on mobile clients, and I think that it makes sense
> that receivers "help" senders, after all incentives are aligned.
Good qualification; I agree. Certainly if the payer knows its
information is less reliable it should prefer the provided route.
Cheers,
Rusty.

2023-06-09 14:51:33 CEST

- reply

📅 Original date posted:2018-10-08
📝 Original message:
Matt Corallo <lf-lists at mattcorallo.com> writes:
> On a related note, it would be nice to get some clarity on appropriate
> usage of the r= field here.
> The way I had implemented it initially was that if an invoice had an r=
> field any publicly-discovered last-hop routes would be ignored as the r=
> data is most likely more up-to-date than any public route rumor information.
> However, if it's only used as a hint and only one or two out of
> potentially many channels are included in it, that may make little sense.
There were originally two proposed uses of r=:
1. For payments via unannounced channels.
2. For routing hints for nodes which don't have a complete topology.
> Not really sure what the appropriate guidance should be, probably
> something like SHOULD prefer to use invoice-r=-provided-hints over
> publicly-discovered routes however MAY use other last-hops in case a
> substantially better route is known?
Note that r can provide zero-or-more full routes, not just a single hop
as is done here. But there's no reason to believe that the invoicer has
more knowledge about all but the last hop.
So, I'd recommend that the payer SHOULD prefer to use the final hops
specified in `r` fields over other equivalent routes it knows.
(Note the weasel word "equivalent" here: you might bias against these
due to fees, timeouts, or even privacy concerns. Also note that I
haven't implemented this yet!).
Cheers,
Rusty.

2023-06-09 14:50:36 CEST

- reply

📅 Original date posted:2018-05-09
📝 Original message:
Anthony Towns via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> writes:
> On Mon, May 07, 2018 at 09:40:46PM +0200, Christian Decker via bitcoin-dev wrote:
>> Given the general enthusiasm, and lack of major criticism, for the
>> `SIGHASH_NOINPUT` proposal, [...]
>
> So first, I'm not sure if I'm actually criticising or playing devil's
> advocate here, but either way I think criticism always helps produce
> the best proposal, so....
>
> The big concern I have with _NOINPUT is that it has a huge failure
> case: if you use the same key for multiple inputs and sign one of them
> with _NOINPUT, you've spent all of them. The current proposal kind-of
> limits the potential damage by still committing to the prevout amount,
> but it still seems a big risk for all the people that reuse addresses,
> which seems to be just about everyone.
If I can convince you to sign with SIGHASH_NONE, it's already a problem
today.
> I wonder if it wouldn't be ... I'm not sure better is the right word,
> but perhaps "more realistic" to have _NOINPUT be a flag to a signature
> for a hypothetical "OP_CHECK_SIG_FOR_SINGLE_USE_KEY" opcode instead,
> so that it's fundamentally not possible to trick someone who regularly
> reuses keys to sign something for one input that accidently authorises
> spends of other inputs as well.
That was also suggested by Mark Friedenbach, but I think we'll end up
with more "magic key" a-la Schnorr/taproot/graftroot and less script in
future.
That means we'd actually want a different Segwit version for
"NOINPUT-can-be-used", which seems super ugly.
> Maybe a different opcode maybe makes sense at a "philosophical" level:
> normal signatures are signing a spend of a particular "coin" (in the
> UTXO sense), while _NOINPUT signatures are in some sense signing a spend
> of an entire "wallet" (all the coins spendable by a particular key, or
> more accurately for the current proposal, all the coins of a particular
> value spendable by a particular key). Those are different intentions,
> so maybe it's reasonable to encode them in different addresses, which
> in turn could be done by having a new opcode for _NOINPUT.
In a world where SIGHASH_NONE didn't exist, this might be an argument :)
Cheers,
Rusty.

2023-06-09 14:50:29 CEST

- reply

📅 Original date posted:2018-05-18
📝 Original message:
ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
>>> Please describe the below:
>>>
>>> 1. Behavior if payment succeeds after T time.
>>> 2. Behavior if payment fails after T time.
>>>
>>> It seems you only described "Behavior if payment succeeds after T time".
>>
>> Ah, sorry if I didn't make that clear. The reputation is increased in the case of successful payments by the fee collected. The reputation is decreased on the downstream peer proportional to time T regardless of whether the payment succeeds or fails. If a payment succeeds quickly, the increase should outweigh the decrease, but if the payment succeeds after a long time, the change in reputation may be net negative. If the payment fails, the upstream peer's reputation does not change and the downstream peer's reputation always decreases proportional to time T.
>
> Thank you. So:
>
> 1. If payment succeeds after T time, upstream reputation is increased by fee earned, downstream reputation is increased by fee earned, downstream reputation is decreased by T * reputation_loss_rate.
> 2. If payment fails after T time, downstream reputation is decreased by T * reputation_loss_rate.
So, to be clear, there's no *financial* fee on failure, just reputation
fee?
Also, you talked about reputation_loss_rate as being a private per-node
thing, and being an explicit thing in the HTLC. I'm ignoring the
former, and assuming the latter.
OK, let's consider a 1000 satoshi HTLC, paying a 10ppm fee and with a
1ppm-per-second reputation_loss_rate.
If it succeeds in 1 second (measuring reputation in millisatoshi,
because its cute):
reputation[source] += 10
reputation[destination] += 10 - 1
If it succeeds in 10 seconds:
reputation[source] += 10
reputation[destination] += 10 - 10
If it fails in 10 seconds:
reputation[destination] -= 10
And if it falls onto the chain and fails after 144 blocks:
reputation[destination] -= 86400
In this scheme, it seems that I can destroy N reputation points in 18
nodes for cost N:
Mallory1 -> Node1 -> Node2 -> ..... -> Node18 -> Mallory2
\
Mallory3
Mallory2 pays a crapload of fees to Node18 to pay Mallory3, getting a
great reputation. Then Mallory1 sends a payment to Mallory2, which
takes a day to resolve.
Of course, this is why you want ramped reputation_loss_rate, say 1ppm
for Mallory1->Node1, 2ppm ->Node2.... 19ppm for Mallory2. That just
means Mallory can destroy 9*N total reputation points, not 18*N.
You can fix this by making it reputation_loss_rate exponential, but I
don't think Node1 could ever get the 262144x reputation to make the
payment in the first place.
What am I missing?
Thanks,
Rusty.

2023-06-09 14:50:27 CEST

- reply

📅 Original date posted:2018-05-14
📝 Original message:
Jim Posen <jim.posen at gmail.com> writes:
> Thanks for the thoughtful responses.
>
>> You missed the vital detail: that you must prove channel closure if you
>> can't unpeel the onion further. That *will* hit an unresponsive party
>> with a penalty.
>
> Ah, that is a good point. I still find the proposal overall worryingly
> complex in terms of communication overhead, time it takes to prove channel
> closure, all of your points in [1], [2], [3], etc. Furthermore, this
> mandates that immediate channel closure is the only allowed reaction to a
> party delaying an HTLC for a time period above a threshold -- the node
> reputation approach gives more discretion to the preceding hop.
> Deobfuscating the route may turn out to be the right option, but I think
> the reputation system has certain advantages over this.
Agreed, it's a tradeoff.
>> The models we tried in Milan all created an incentive to fail payments,
>> which is a non-starter.
>
> Do you mind elaborating or summarizing the reasons? The way I'm analyzing
> it, even if there's a nominal spam fee paid to routing nodes that fail
> payments, as long as it's low enough (say 2-5% for arguments sake), the
> nodes still have more to gain by forwarding the payment and earning the
> full fee on a completed payment, and possibly the reputation boost
> associated with completing a payment if that system was in effect.
You're forgetting the failure cases, where now I can profit.
If I disconnect from another node, I now have a disincentive to tell
others. At the moment we send an update disabling the channel (though
we should give a few seconds for reconnect first, but whatever).
Similarly, the rewards aren't proportional: being cheaper than other
routes gets you all the traffic, but now you profit even if you can't
service the payments. In fact, once a channel becomes hard to use (low
capacity, transient disconnect, whatever), I *should* advertize it as
cheaper route than anyone else: free money!
I'm sure there are other ways to game it, but the underlying reason is
clear: it misaligns user and node incentives.
> Moreover, a node that constantly fails payments will be blacklisted by the
> sender eventually and stop receiving HTLCs from them at all. Overall, I
> don't think this is a profitable strategy. Furthermore, I think it works
> quite well in combination with the reputation system.
If the system is sufficiently decentralized, managing to cheat everyone
once is very profitable though.
>> This seems like we'd need some serious evaluation to show that this
>> works, because the risks are very high.
>
> I agree that it needs to be evaluated. I may start working on some network
> simulations to test various DOS mitigation strategies.
>
>> I can destroy your node's reputation by routing crap through you; even
>> if it costs me marginaly more reputation than it does you, that just
>> means that the largest players can force failure upon smaller players,
>> centralizing the network. And I think trying to ensure that it costs me
>> more reputation than the sum of downstream reputation loss leaks too
>> much information
>
> I will add to ZmnSCPxj's response, which is mostly on point. The key here
> is that the only way to lose significant reputation is to delay a payment
> yourself or forward to a malicious downstream that delays -- neither of
> these can be forced by the sender alone. This amounts to a system where you
> are on the hook for any malicious behavior of your downstream peers, which
> is why you must keep a reputation score for each which they earn over time.
> This should keep all links in the network high quality and quickly
> disconnect off delaying nodes if the incentives are right.
But I can make you look like a delaying node whenever I want. The only
way to ensure that I lose more reputation than you do is to leak
information about route length for *everyone*. And even then, it's just
a matter of numbers. I can make successful payments to myself through
the same peers (but not you!) to stay above their threshold so my
reputation is intact.
So it's basically a question of how expensive is it for me to throw you
off the network? You have to tune that number carefully.
> While I agree that a lot of reputation is leaked by aggregating the losses
> along the route, this serves exactly to prevent large nodes with high
> reputation from ruining links elsewhere. There are two things a node
> looking to cause reputation loss could do. 1) Identify a node (not itself)
> it thinks will delay a payment and send to them. This locks up funds on
> their behalf, but is actually good behavior because it identifies a faulty
> node and rightfully forces a loss in their reputation, eventually resulting
> in them being booted from the network. Everyone upstream loses some
> reputation for having connectivity to them, but less because of the loss
> aggregation along the route. 2) Delay a payment oneself and force upstream
> reputation loss. This is why I think it's important that the reputation
> loss aggregate so that the malicious party loses the most.
But we're busy trying to remove all the methods of deanonymizing the
network, and you seem to be adding a new one, *and* providing an
incentive to deanonymize.
> As for the amount of information leaked, yes, it helps determine the number
> of upstream hops in a route. However, the CLTV values help determine the
> number of downstream hops in a route in exactly the same way. I see these
> as symmetric in a sense.
Yes, which is why we have mitigations in place (which are still probably
insufficient). I really don't want to add another vector.
> This is exactly the question that your local view of peer reputations helps
> solve: are the potential fees here worth the risk of forwarding this
> payment to this downstream?
So now I'll try to deanonymize all payments so I can determine this.
Those who do this best will be rewarded, and those who don't try will be
knocked off the network, probably by those who can!
So I'd like to see a real design of the reputation system. If it's
practical (which is a significant hurdle), we then need to carefully
evaluate whether we're creating significant disincentives to
neighbourliness.
Cheers,
Rusty.

2023-06-09 14:48:07 CEST

- reply

📅 Original date posted:2017-12-18
📝 Original message:
Andy Schroder <info at AndySchroder.com> writes:
> What's the rational for using millisatoshis as the units for lightning
> channels? Aren't you going to loose up to 1/2 of a satoshi when the
> channel is closed?
You can lose up to 0.999 satoshi per in-progress payment, yes. BOLT #3:
The amounts for each output MUST be rounded down to whole satoshis.
> Is this because it doesn't hurt and you might as well
> be open to the opportunity for these sub satoshi transactions, because
> if you aren't, you are giving up the opportunity to get accumulated
> revenue from many of those small transactions, that could end up being
> greater than 1/2 of a satoshi?
In practice, payments of less than a few thousand satoshi are
impractical, as they cost more than that to spend. Channel closing
costs dwarf the gains to be made from cheating, however.
> Since millisatoshis is used, is there a maximum channel funding size?
Yes, the upper 32 bits must be zero, from BOLT #2:
- for channels with `chain_hash` identifying the Bitcoin blockchain:
- MUST set the four most significant bytes of `amount_msat` to 0.
This gives a maximum HTLC value of .04294967295 BTC, which, back when
we started, was about $10.
> Is the optional initial push of millisatoshis during the channel
> creation there in order to motivate the other party to be willing to
> waste their time with the channel creation in the first place? If not,
> what's it for?
It's for the common case where you want to connect to someone and
make a payment immediately. I'm not sure how widely it will be used,
though. It's also the only mechanism for the payer to have *zero* funds
in channel (ie. below reserve).
> In all of the clients that I've looked at, I can't seem to find out how
> to define the timeout closing out a channel when someone does not
> cooperate. Is there a fixed value for this as part of the protocol? Or
> do most clients have a default that they enforce over all channels that
> they create?
If there's no in-progress payment, there's no reason to close a channel
to an unreachable peer, unless you want to abandon the channel and get
the funds back.
If there is, BOLT #2 has you covered:
https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#requirements-8
Hope that helps,
Rusty.

2023-06-09 14:46:35 CEST

- reply

📅 Original date posted:2016-08-10
📝 Original message:
Tadge Dryja <tadge at lightning.network> writes:
>>
>> 4. When the watcher receives a new block, they HMAC(txid+salt1) all
>> transactions and compare against the key-value store
>>
>> This method does not require significant computation upon receiving a
>> new block and checking against the datastore. I forgot to note, that the
>
> If you're only watching 1 channel, this is OK as you're just doing one HMAC
> operation per incoming tx. This works when the number of states per
> channel is high but the number of channels watched is low.
> If you're watching 1M channels with 1K states each, this requires 1M HMAC
> operations for every incoming tx.
>
> By giving the whole (or a truncated part) of the txid, the observing node
> can put all txids being watched for into the same tree and have seek access
> time independent of the number of separate channels being watched. Whether
> it's 1 channel with 1 billion states, or 100M channels with 10 states each,
> you have the same cpu and I/O cost per incoming tx.
Yes, I think I agree.
> I'm not clear on the advantages of sending encrypted state information to
> the observer. Most information the observer needs to construct a punishing
> transaction is available in the observed commitment tx; the only per-state
> information which needs to be stored is the signature (and in the case of
> HTLCs, the preimage).
Yes. To be precise, watcher needs preimage, pubkeys, a signature,
OP_CSV delay amounts for each side, and HTLCs.
If the pubkeys and OP_CSV delay amounts are fixed, you need a signature
and preimage (required to steal the to-them output as well as htlcs)
every new commit tx (ie. every new watch request). And you'll add a new
HTLC information on average every second commit tx.
But I think you're better attaching every relevant HTLC to every watch
request; otherwise, you're exposing all previous HTLCs. I recalculated:
they're only 24 bytes each (ripemd hash + expiry).
If we really want to optimize that,maybe we can come up with a cleverer
scheme, where you optionally include the key to the previous watch
request with the encrypted information, allowing the sender to control
the privacy/data tradeoff? Then the watcher would gather HTLCs from
those previous requests as well, and see which ones are required?
{Insert bikeshed here}. {No, here}.
> Reconstructing messages from hashes and / or
> signatures isn't possible as long as there's sufficient unknown data in the
> preimage or message. This is achievable by changing the pubkeys used in
> the commit tx script and pubkey hash each state, without needing additional
> data in an OP_RETURN.
FWIW, I take back the idea about using the signature as a key:
1) While the crypto people tell me it's probably OK, they can't prove it.
2) If we go to Schnorr, I think it falls apart as both sigs are combined.
OTOH, changing pubkeys every step isn't required if we go for Laolu's
key-revocation scheme instead of shachain/elkrem. I think? (Roasbeef,
this is your cue to describe it in detail!)
Cheers,
Rusty,

2023-06-09 14:46:34 CEST

- reply

📅 Original date posted:2016-08-09
📝 Original message:
Joseph Poon <joseph at lightning.network> writes:
> Hi Rusty,
>
> On Tue, Aug 09, 2016 at 03:13:57PM +0930, Rusty Russell wrote:
>> We send the observer the "steal" tx every update (not really: we only
>> need to send the to-us/to-them amounts, pubkeys, HTLCs info and sig).
>> This gets encrypted+HMAC with the txid of the commit tx (or, if that's
>> too guessable, the SHA256() of our signature on the commit tx).
>>
>> [snip]
>>
>> If we want to obscure our funding tx, we can simply use a txid qualifier
>> the same way you did (and maybe use the sha256(txid) as the encryption
>> key to avoid weakening that).
>
> I think it may be necessary to identify when the transaction occurs as
> an index for outsourcing services, so the key can't be dervied directly
> from the txid with a single HMAC/sha256. It's possible there are
> millions of transactions to compare, and an index based on txid is
> necessary. The two options I can see are:
This is fun!
Yes, I think we agree some "filter hint" is needed to avoid a crazy
amount of outsourcing work (eg. first 8/16 bytes of txid). I don't
think an HMAC check per registered commitment is quite fast enough.
But there's a problem with most naive filters, if you can guess
commitment tx N-1 from commitment tx N. If the outsourcing service sees
an old commit they can guess at previous commitment txs using that.
Probably unroll the whole channel history if they can guess enough
HTLCs.
> 2. HMAC the transaction itself (not txid) as the secret key (or anything
> part of the transaction, as long as it isn't SHA256(tx) for obvious
> reasons). I like something along these lines better than option #1.
> Whatever computational cost there is will be extremely low, as the
> operations are constrained by block size.
If we include the witness in that HMAC we risk reintroducing
malleability. If we don't, we risk txs being predictable.
I can think of a few fixes: insert some randomness in the tx (OP_RETURN?
Different addresses each time?), or try to extract the input signature
from the witness, which is unguessable, as our filter?
What's simplest?
Rusty.

2023-06-09 14:46:33 CEST

- reply

📅 Original date posted:2016-08-09
📝 Original message:
Tadge Dryja <tadge at lightning.network> writes:
> Blinded outsourcing of channel monitoring
But if we don't steal HTLCs, the lack of channel utilization is a pain:
> States with in-flight HTLCs are another issue... if you want to keep the
> data storage down, you can just not include them, and make a policy that
> the sum of all the HTLCs should be less than either non-HTLC balance in the
> channel. That way the attacker still loses money if they try to attack.
> They potentially might not lose all of it though. You could make it
> variable size and include HTLCs as well but that increases the data rate
> significantly and probably hurts anonymity in various ways.
But now they must *always* keep their balance greater than all the HTLCs
they ever previously received at once, otherwise it's worth them
cheating.
I think we really do want to capture those HTLCs, but I don't think it's
as bad as you think: an HTLC can be described in ~40 bytes. We need to
do some magic to pad it out to hide the number of HTLCs, of course.
So, my method was less ambitious. I'll describe it here:
We send the observer the "steal" tx every update (not really: we only
need to send the to-us/to-them amounts, pubkeys, HTLCs info and sig).
This gets encrypted+HMAC with the txid of the commit tx (or, if that's
too guessable, the SHA256() of our signature on the commit tx).
I had assumed we'd tell the observer our channel funding txid: when it
sees that spent, it tries to use those signatures to decrypt all the txs
we sent. If one succeeds, it spends it.
If we want to obscure our funding tx, we can simply use a txid qualifier
the same way you did (and maybe use the sha256(txid) as the encryption
key to avoid weakening that).
Whatever we do, we might want to offer our own peers to do that watching
for them (for a fee?).
Cheers!
Rusty.

2023-06-09 14:45:54 CEST

- reply

📅 Original date posted:2016-03-07
📝 Original message:
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.

2023-06-09 14:45:42 CEST

- reply

📅 Original date posted:2016-02-08
📝 Original message:
Hi all!
Eliminating all acknowledgements makes for a much simpler
protocol.
Each side sends one or more updates
(ADD/SETTLE/TIMEOUT/FAIL/UNADD), followed by a COMMIT (with sig). Reply
COMPLETE with the old revocation preimage. Each side tracks two commit
txs: its own and the other side's. When you COMMIT you're locking in
your updates to my commit, and staging them for your commit, enforcing
the requirement that you commit to your updates first.
Details
-------
ADD:
Insert this new HTLC from proposer to recipient.
SETTLE:
Recipient collects proposers's committed HTLC with R value.
TIMEOUT:
Proposer removes committed HTLC it added.
FAIL:
Recipient removes committed HTLC it received.
UNADD:
Proposer removes uncommitted HTLC it added.
COMMIT:
Contains a signature for receiver's commit tx, with all the
updates included. Recipient commits updates to its own commit tx,
and stages those same updates to the other side's commit tx, then
sends COMPLETE for its own old commit tx.
COMPLETE:
Completes removal of old commit tx. Recipient commits updates
to other side's commit tx, stages those same updates for its own
commit tx.
So the shortest possible complete exchange looks like:
A B
ADD->
COMMIT->
<-COMPLETE
<-COMMIT
COMPLETE->
Optimizations
-------------
If we want to fail faster, we can add a non-binding ADD_FAIL message,
rather than waiting for a COMMIT. This would be a hint that we will
FAIL an HTLC as soon as it is committed; recipient may UNADD if it
receives it in time.
Fee Negotiation
---------------
lnd has a fee field in their commit msg, c-lightning uses a fixed fee
negotiation at channel establishment and a FIXME. The logical place for
fee negotiation is in the COMMIT message, with a requested fee rate and
a range of acceptable values. Instead of COMPLETE a node may REJECT,
with a fee range; the COMPLETE may then be reattempted.
Similar fee negotiation would be required for mutual close (this isn't
as urgent and so would use a normal fee).
Cheers,
Rusty.

2023-06-09 14:45:16 CEST

- reply

📅 Original date posted:2015-11-27
📝 Original message:
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.

2023-06-09 14:45:06 CEST

- reply

📅 Original date posted:2015-11-19
📝 Original message:
Hi all!
As you know, I designed a lightning variant which used only
non-experimental, in-planning BIPs[1]. One assumption was BIP62: in
particular, that anchor malleability wouldn't be an issue. This was
flawed; BIP62 will never be deployed.
There are several options from here:
1) Ignore it. Malleated txs are non-standard.
2) Add a timeout to the anchor. Limits the lifetime of the channel, and
still means if it does happen you have to wait for the timeout.
3) Propose a reduced BIP62 which (say) only protects P2PKH, for a
specific transaction version.
4) Take a leap of faith and assume Segregated Witness fixes all
malleability.
I was debating between #1 and #3 for a while, but eventually settled on
#4. Here's why:
1) While still pre-BIP, Pieter Wuille is working on a prototype now
(Luke Jr came up with a sanish way of softforking it in).
2) Other parts of the lightning code (in particular, watching bitcoin
transactions) become significantly simpler if malleability is
ignored.
3) It's the right thing for Bitcoin; all smart contract systems want
this.
This result is NOP for lightning in the short term; assuming SW is the
same as pretending malleability doesn't exist. But if we need to add
malleability support later, it's going to be painful, since handling it
correctly in all the places it's missing will be hard.
Cheers,
Rusty.
PS. Remember, every project has 3 major disasters. Just wait until you
see the next two!
[1] https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf

2023-06-09 14:44:48 CEST

- reply

📅 Original date posted:2015-10-19
📝 Original message:
Mats Jerratsch <matsjj at gmail.com> writes:
>> 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. ;)
Oh, I'm pushing BIP 62, as well, in parallel with everything else :)
>>> 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..
Yes, we've not as bound to consensus, which is nice. Schnorr is
something we can decide on later, for sure.
Cheers,
Rusty.

2023-06-09 14:44:47 CEST

- reply

📅 Original date posted:2015-10-16
📝 Original message:
Mats Jerratsch <matsjj at gmail.com> writes:
> 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.
Hi Mats,
Thanks for bringing this on-list!
> (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).
This makes some sense (though the anchor transactions don't need to be
P2SH, it's nicer for bitcoin's UTXO if they are).
> 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)
To prove we control KEYA, we simply need to sign something with it (our
nodePubKey):
KEYA NODE-PUBKEY TXID SIGNATURE
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.
Later on, we can send SPV proofs for TXID.
> 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.
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.
Thanks!
Rusty.

2023-06-09 14:44:26 CEST

- reply

📅 Original date posted:2015-09-20
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> On 19 September 2015 9:39:44 am AEST, Rusty Russell <rusty at rustcorp.com.au> wrote:
>> // Sum of this whole thing after decryption.
>> required sha256_hash sum = 1;
>>
>> // Where to next?
>> oneof next {
>> // Actually, this is the last one
>> bool end = 2;
>> // Next lightning node.
>> pubkey lightning = 3;
>> // Other realms go here...
>> }
>>
>> // How much fee you can take (== all, if last node)
>> required int32 fee = 4;
>>
>> // Remainder (route blob for next node).
>> required bytes route = 5;
>
>>Nodes create the route backwards, to calculate the size. Then picks a
>>total size randomly between 1024 and 4096, and pads to that size (at
>>least 32 bytes of random padding). Then walks backwards to wrap and
>>encrypt it.
>>
>>This offers some protection from guessing the route length.
> Wouldn't it be better to store the expected balance to be forwarded rather than the fee? That way if someone takes too much, the next node can immediately abort the transaction.
Yes, excellent point. I flip-flopped on that; so I flipped again.
> Shouldn't the onion blob be re-padded when forwarded? Otherwise it'd
> sometimes drop below 1024 bytes and you'd be able to tell you're near
> the end of the chain.
Yes and this applies for almost any length selection method.
> Just adding random bytes on to the end should
> work I think - they'll just be treated as extra padding and ignored.
My original plan. But it enables a probing attack where you corrupt the
packet and if it succeeds anyway you know those bytes weren't used.
> Alternatively, maybe you could just append the encrypted bytes that made up your post of the payload from your incoming message: it was encrypted to you so should be effectively random to anyone else and will be garbled further when the next node "decrypts" it. That would save on entropy/crypto ops, and a constant message size would leak minimal info I think.
So rotate the payload? I don't think that's verifiable by the
recipient, so has the same probing attack issue as above.
Hmm, what if we include a pubkey, and you use that to encrypt 0 padding?
The last hop gets the privkey (and boundary information), and she can
verify the padding.
Off the top of my head, that solves both the length problem, and the
"route replacement" problem.
But I've not had coffee yet, plus jetlag. Could be missing a flaw or
simplification!
Thanks,
Rusty.

2023-06-09 14:44:25 CEST

- reply

📅 Original date posted:2015-09-20
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> On 19 September 2015 9:39:44 am AEST, Rusty Russell <rusty at rustcorp.com.au> wrote:
>>Route Probing Attacks
>>=====================
>>Now, there's a weakness here: No MAC! A nosy node can't corrupt the
>>routing past the next hop, but it could replace it entirely (this is
>>fundamental to the scheme of R values). If it guesses the final
>>destination right, the HTLC will succeed, otherwise it will fail, so it
>>can use this to probe.
...
>>I can't see a fix for this in general. :(
>
> I don't think parallel probes work well - if any of your probes succeed, your neighbour knows R and can claim all of your probes. Parallelization is also limited by channel capacity, assuming the payee knows how much to expect.
Channel capacity might not be an issue for tiny micropayments, but
the reveal of R is a good point: such probing should have a real cost
on success. I'll be sure to implement that properly :)
> I'm not sure probing is really plausible given mass deployment, is it? You have to guess the eventual recipient but given randomised routing you have every person or business using lightning as a potential candidate with possibly equal probability?
If someone wants to know whether I'm sending money to you, it would
work. Get a cheap hub near you, and one near me, and probe every
payment which passes through both.
But I guess it's a fairly boutique surveillance, which doesn't scale.
> For a general solution, I think you could completely rule out probing by having two R values, one known only by the recipient, and one by the sender (call it S say). Then make the htlcs payable on presentation of both R and S and include S encrypted to the final recipient in the onion payload. Munging the payload then makes the htlc irredeemable so misrouting it gives no information.
That's clever. And I think it works. I will need more coffee to figure
out if we should revise the transaction structure to include this.
> (Please let me know if the formatting of this mail is too hopeless; trying out a new setup)
No work wrap, but it seemed to work fine.
Cheers,
Rusty.

2023-06-09 14:43:52 CEST

- reply

📅 Original date posted:2015-08-01
📝 Original message:
Christopher Jamthagen <cjamthagen at gmx.com> writes:
>> Sent: Friday, July 31, 2015 at 1:48 AM
>> From: "Rusty Russell" <rusty at rustcorp.com.au>
>> To: "Christopher Jamthagen" <cjamthagen at gmx.com>
>> Cc: "lightning-dev at lists.linuxfoundation.org" <lightning-dev at lists.linuxfoundation.org>
>> Subject: Re: [Lightning-dev] Stealing money from a hub?
>> Christopher Jamthagen <cjamthagen at gmx.com> writes:
>>> Would it be desirable/possible to implement the timestop feature for
>>> CLTV as well? That would make the difference between the number of
>>> blocks until either expiration the same in case of a block-filling
>>> attack. If I'm not mistaken Peter Todds BIP is already merged, but
>>> this feature could be implemented with another soft fork.
>
>> Yes, timestop would logically be a softfork add, and it should apply to
>> both (same logic applies).
>
> If the timestop feature would activate only when the CLTV transaction
> is included in a block, it would allow for a pretty serious DoS attack
> vector where hubs can be forced to close channels with other hubs by
> having the attacker, as the receiver, never reveal R and create a
> block-filling attack.
I don't think so. Let's say the rule is "time doesn't pass if a block
is full".
> This would force the hub connected to the receiver to broadcast the
> commitment transaction
Why? The HTLC wouldn't expire, which would be a pain, but there's no
reason to panic and dump transactions. By definition, during a block
filling attack you've got all the time in the world.
Now, preventing HTLCs from expiring is a DoS, but a lesser one.
What am I missing?
> CLTV transactions would need to include the current block-height
> immediately when a commitment transaction is signed, so that miners
> can know where to start counting full blocks from as soon as it is
> broadcast. So my question is: Is such an upgrade for CLTV, as it is
> now, soft-forkable as it requires additional arguments? I am not
> totally clear on when upgrades are soft-forkable vs. hard-forkable.
Anything which is a furthur restriction (as in "this used to be valid,
and no longer is") is soft-forkable. So delaying timeouts is a soft-fork.
>>> Speaking of being online all the time, checking the blockchain is
>>> outsourceable, right? So it seems that miners would be the perfect
>>> third party to check for cheaters in LN. By offering them a nice chunk
>>> of our counterparty's funds as fees, they should be incentiviced
>>> enough to keep an extra eye for us on the blockchain.
>
>> Outsourcability scales really well; once you're full-time monitoring the
>> blockchain, might as well get as many clients as possible. You can also
>> automate the outsourcee's fee, by including it in the "steal" tx.
>
> Does it scale that well? I guess looking up pre-images in the shachain is fast, but what about R values in HTLCs? Would the third party have to store all those values or is there a nice optimization I have missed?
Indeed, there's a separate thread where Anthony Towns points out that
remembering R values and timeouts is an issue.
I was referring to the part where you watch the chain for spends on the
anchor outputs. You only need to do work to check what happened when
one of them gets spent, should almost never happen (since the client
should tell you they're going to close the channel cooperatively).
Cheers,
Rusty.

2023-06-09 14:43:43 CEST

- reply

📅 Original date posted:2015-07-23
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> If Alice ever tries cheating, and publishes and old commitment:
>
> 800 Alice + DELAY | #Alice_42 + Bob
> 200 Bob
>
> Then Bob needs to work out which of the 100 Alice_N hashes he knows or can
> work out is being abused; prior to the DELAY expiring. With millions of
> transactions that could be a bunch of hash calculations or a 100MB lookup
> table. Might make more sense to have a dummy output of "0: OP_RETURN 42" to
> make that calculation trivial though? That could trivially be verified as
> part of the "forms hash chain as expect" and "txn structure" checks.
It might be millions. What happens is Bob sees the anchor being spent,
checks if it's the latest commitment transaction. It's not, so does a
backwards search to find the revocation key.
The time taken for that search is O(N), where N is the current
commitment transaction number. But measurements on my laptop show that
1M transactions takes 5.4 seconds (see benchmark below), so I don't
think it's worth optimizing this "never happens" case.
> HTLCs are harder if you assume pay2scripthash is used though. If Alice
> published:
>
> 100 Alice + Delay | #Alice_55 + Bob
> 100 Bob
> 200 R1 + Alice + DELAY | Bob + TIMEOUT1 | #Alice_55 + Bob
> 200 R2 + Alice + DELAY | Bob + TIMEOUT2 | #Alice_55 + Bob
> 200 R3 + Alice + DELAY | Bob + TIMEOUT3 | #Alice_55 + Bob
> 200 R4 + Alice + DELAY | Bob + TIMEOUT4 | #Alice_55 + Bob
>
> well after R1..R4 were known and Alice_55 was revealed in order to try
> stealing most of the channel's funds, I think Bob could only claim the
> final outputs if he could unhash the scripts, which would require having
> remembered R1..R4 even after those contracts had long been resolved. I
> guess it could be feasible in that case to have the extra output be "0:
> OP_RETURN 42 #R1 #R2 #R3 #R4"?
Good point! With p2sh you need to know the R hash values and timeouts
to spend the output (40 bytes). Since OP_RETURN is length-limited to 80
bytes, you can't fit more than 2.
And if the HTLC outputs are not P2SH, they're non-standard and won't be
relayed.
What else can we come up with?
Thanks,
Rusty.
> [2] (Unattached footnote) This project's motto is "The lightning network:
> it's off the chain!" right?
> http://www.urbandictionary.com/define.php?term=off+the+chain
Err.... Yeah. It's spelled "caching layer for bitcoin" but it's
pronounced just like that.

2023-06-09 14:43:38 CEST

- reply

📅 Original date posted:2015-07-07
📝 Original message:
Hi all,
http://ozlabs.org/~rusty/diagrams/dual-anchor.svg
Since I posted my first design of HTLC yesterday, and noted that
it doesn't seem to require new sighash modes, I went back and revisited
my discarded ideas for establishing an anchor without new sighash modes.
If we can do that (and my HTLC design stands up), then lightning network
only needs OP_CHECKSEQUENCEVERIFY and OP_CHECKLOCKTIMEVERIFY, which are
fairly low-albedo soft forks.
To recap: the draft paper and current code trade signatures on
the first commitment transaction before signing the anchor transaction.
That way you are sure to have a way to get your funds back before you
put them into the anchor. (The paper uses the term funding transaction;
I prefer anchor).
This can't be done in normal bitcoin, as you don't know the TXID
of the anchor until after its inputs are signed, so you can't sign the
commitment transaction without knowing the txid of the anchor. It works
in Elements Alpha because they have segregated witness; the txid of the
anchor doesn't hash the input scripts. It could work in bitcoin with a
softfork of a new CHECKSIG2 which has new signature modes, but there's
not even a BIP for that, and there are so many things that could be done
there that it's likely to be long delayed.
So, how can we solve this? Well, we can have two anchors
instead of one. I put my inputs into my anchor, you put your inputs
into yours: each one requires both our signatures to spend. The
commitment tx has two inputs, one for each.
We can trade anchor txids, so we can both sign the commitment
tx. But now one of could withhold our anchor, leaving us with an
unusable commitment tx and stuck output from an anchor. We need a way
to get the funds back in that "abort" case.
Thus we add an intermediary transaction (called "Escape"
transactions) which spends the 2 of 2 anchor output, but can be spent
either by 2 of 2 (ie. the commitment tx), OR back to the anchor owner
after a delay (using OP_CHECKSEQUENCEVERIFY).
The order is as follows:
1) We both trade anchor txids and amounts.
2) We both trade signatures for the escape transactions, so either one
can broadcast them.
3) Now we are sure to be able to recover our funds, we each broadcast
our anchor txs.
4) If the other side broadcasts their escape transaction, abort and
broadcast our escape transaction. After the timeout, we can spend
it.
5) If the other side doesn't broadcast their anchor tx, abort and
broadcast our escape transaction.
6) Otherwise, when the anchor txs reach the required depth, we exchange
signatures for the commitment transaction.
7) If the other side broadcasts either escape transaction, broadcast
the other escape transaction and the commitment tx as normal (this is
a unilateral close) before they can reclaim their anchor funds.
I think this works, and doesn't add any new requirements; you now need
to watch out for escape txs being broadcast instead of commitment txs.
The downside is that there are 3 extra transactions involved; 1 extra
for the channel open, and 2 for the channel close.
Feedback, optimizations, horrible holes?
Rusty.

2023-06-09 14:39:53 CEST

- reply

📅 Original date posted:2021-04-19
📝 Original message:
Lloyd Fournier <lloyd.fourn at gmail.com> writes:
> On Wed, Dec 9, 2020 at 4:26 PM Rusty Russell <rusty at rustcorp.com.au> wrote:
>
>>
>> Say r1=SHA256(ss || counter || 0), r2 = SHA256(ss || counter || 1)?
>>
>> Nice work. This would be a definite recovery win. We should add this
>> to the DF spec, because Lisa was almost finished implmenting it, so it's
>> clearly due for a change!
>>
>
> Yes that's certainly a fine way to do it.
> I was also thinking you could eliminate all "basepoints" (not just funding
> pubkey) using something like this. i.e. just use the node pubkey as the
> "basepoint" for everything and randomize it using the shared secret for
> each purpose.
OK, I tried to spec this out, to implement it. One issue is that you
now can't sign the commitment_tx (or htlc_tx) without knowing the node's
secret key (or, equivalently, knowing the tweaked key and being able to
use the derivation scheme to untweak it).
c-lightning currently does a round-trip to the signing daemon for this
already, but it'd be nice to avoid requiring it.
So I somewhat reluctantly added `commit_basepoint` from which the others
are derived: an implementation can use some hardened derivation from its
privkey (e.g. SHA256(node_privkey || ss || counter)) to create
this in a deterministic but still private manner.
Or we could just leave all the other points in and just replace
funding_pubkey.
Cheers,
Rusty.

2023-06-09 14:39:53 CEST

- reply

📅 Original date posted:2021-04-20
📝 Original message:
Lloyd Fournier <lloyd.fourn at gmail.com> writes:
> Hi Rusty,
>
> On Tue, 20 Apr 2021 at 10:55, Rusty Russell <rusty at rustcorp.com.au> wrote:
>
>> Lloyd Fournier <lloyd.fourn at gmail.com> writes:
>> > On Wed, Dec 9, 2020 at 4:26 PM Rusty Russell <rusty at rustcorp.com.au>
>> wrote:
>> >
>> >>
>> >> Say r1=SHA256(ss || counter || 0), r2 = SHA256(ss || counter || 1)?
>> >>
>> >> Nice work. This would be a definite recovery win. We should add this
>> >> to the DF spec, because Lisa was almost finished implmenting it, so it's
>> >> clearly due for a change!
>> >>
>> >
>> > Yes that's certainly a fine way to do it.
>> > I was also thinking you could eliminate all "basepoints" (not just
>> funding
>> > pubkey) using something like this. i.e. just use the node pubkey as the
>> > "basepoint" for everything and randomize it using the shared secret for
>> > each purpose.
>>
>> OK, I tried to spec this out, to implement it. One issue is that you
>> now can't sign the commitment_tx (or htlc_tx) without knowing the node's
>> secret key (or, equivalently, knowing the tweaked key and being able to
>> use the derivation scheme to untweak it).
>>
>
> Using node secret key to sign the commitment_tx seems like something you
> will have to accept to introduce this feature. For the idea to work it has
> to be some public key that is known by others and gossiped through the
> network. Of course you could extend the information that is gossiped about
> a node to include a "commit_tx_point" but the nodeid seems the more natural
> choice.
Duh, yes, of course you need the funding_key secret to sign the
commitment tx.
But you really don't want to access the `remote_pubkey` (which in a
modern option_static_remotekey world is simply the payment_basepoint).
It's generally considered good practice *not* to have this accessible to
your lightning node at all.
>> c-lightning currently does a round-trip to the signing daemon for this
>> already, but it'd be nice to avoid requiring it.
>>
>> So I somewhat reluctantly added `commit_basepoint` from which the others
>> are derived: an implementation can use some hardened derivation from its
>> privkey (e.g. SHA256(node_privkey || ss || counter)) to create
>> this in a deterministic but still private manner.
>>
>> Or we could just leave all the other points in and just replace
>> funding_pubkey.
>>
>
> Another approach is to do things in "soft-fork" like manner.
> Each node that wants to offer this feature sets their funding_pubkey to a
> specified DH tweak of the nodeid. Nodes that want backup-free channel
> recovery can just refuse to carry on the funding protocol if the
> funding_pubkey is not set the way it wanted.
Yeah, you can totally do this in an opt-in manner, except it doesn't
work unless your peer does it too. Since we expect everyone to want to
do this, it's clearer to force everyone to calculate this and not have
redundant and confusing fields in the message.
>>From my pruisit crypto point of view having only one public key is nice but
> I'm not sure how it impacts things architecturally and other protocols like
> watchtowers.
They can operate exactly like the existing scheme, AFAICT.
Here's the spec diff (based on dual-funding, since it's easier to simply
hard change). Please check my EC math! :)
diff --git a/02-peer-protocol.md b/02-peer-protocol.md
index fbc56c8..1114068 100644
--- a/02-peer-protocol.md
+++ b/02-peer-protocol.md
@@ -867,11 +867,9 @@ This message initiates the v2 channel establishment workflow.
* [`u16`:`to_self_delay`]
* [`u16`:`max_accepted_htlcs`]
* [`u32`:`locktime`]
- * [`point`:`funding_pubkey`]
+ * [`u64`:`generation`]
* [`point`:`revocation_basepoint`]
* [`point`:`payment_basepoint`]
- * [`point`:`delayed_payment_basepoint`]
- * [`point`:`htlc_basepoint`]
* [`point`:`first_per_commitment_point`]
* [`byte`:`channel_flags`]
* [`opening_tlvs`:`tlvs`]
@@ -895,13 +893,16 @@ If nodes have negotiated `option_dual_fund`:
The sending node:
- MUST set `funding_feerate_perkw` to the feerate for this transaction
- - MUST ensure `temporary_channel_id` is unique from any
- other channel ID with the same peer.
+ - MUST set `generation` to a number greater than any previous
+ `generation` it has sent to this receiving node which has reached
+ `commitment_signed`.
+ - SHOULD set `generation` to the lowest number which meets this requirement.
The receiving node:
- MAY fail the negotiation if:
- the `locktime` is unacceptable
- the `funding_feerate_per_kw` is unacceptable
+ - the `generation` exceeds expectation by more than the maximum it would scan for recovery.
#### Rationale
`channel_id` for the `open_channel2` MUST be derived using a zero-d out
@@ -926,6 +927,13 @@ Instead, the channel reserve is fixed at 1% of the total channel balance
rounded down to the nearest whole satoshi or the `dust_limit_satoshis`,
whichever is greater.
+`generation` is a number which is used to generate the points used for
+this pair of peers, with the aim of allowing automatic onchain
+scanning for channels if all other information is lost. Since this
+scan would presumably only try a limited number of generations, it is
+best if this number is low, but it also needs to change for each
+successive channel between the peers, to avoid obvious fingerprinting.
+
Note that `push_msat` has been omitted.
### The `accept_channel2` Message
@@ -943,11 +951,9 @@ acceptance of the new channel.
* [`u32`:`minimum_depth`]
* [`u16`:`to_self_delay`]
* [`u16`:`max_accepted_htlcs`]
- * [`point`:`funding_pubkey`]
+ * [`u64`:`generation`]
* [`point`:`revocation_basepoint`]
* [`point`:`payment_basepoint`]
- * [`point`:`delayed_payment_basepoint`]
- * [`point`:`htlc_basepoint`]
* [`point`:`first_per_commitment_point`]
* [`accept_tlvs`:`tlvs`]
@@ -967,6 +973,10 @@ additions.
The accepting node:
- MAY respond with a `funding_satoshis` value of zero.
+ - MUST set `generation` to a number greater than any previous
+ `generation` it has sent to this receiving node which has reached
+ `commitment_signed`.
+ - SHOULD set `generation` to the lowest number which meets this requirement.
#### Rationale
@@ -985,6 +995,31 @@ Funding composition for channel establishment v2 makes use of the
[Interactive Transaction Construction](#interactive-transaction-construction)
protocol, with the following additional caveats.
+#### Point Derivation
+
+The `funding_pubkey` and basepoints are derived from the two
+`node_id`s and the higher of the two `generation` values; the
+`payment_basepoint` is supplied directly.
+
+Derivation is done as follows:
+
+1. Start with two node ids, `N1` and `N2` (`N1` is the lesser of the
+ two SEC1-encoded compressed public keys, `N2` the greater).
+2. Derive a shared secret, `SS`, using ECDH on `N1` and `N2`.
+3. Define tweaks `T` for each peer, using `SHA256(SS || generation || node_id || name)`, where:
+ 1. `generation` is the `u64` larger of the two `generation` fields from `open_channel2` and `accept_channel2`.
+ 2. `node_id` is the SEC1-encoded compressed public key of the peer.
+ 3. `name` is a non-terminated ASCII string, e.g. `htlc` is the four bytes
+ `0x68 0x74 0x6C 0x63`
+4. The `funding_pubkey` is defined as the `node_id` + G*T(`funding`).
+5. The `delayed_payment_basepoint` is defined as `node_id` + G*T(`delayed_payment`).
+6. The `htlc_basepoint` is defined as the `node_id` + G*T(`htlc`).
+
+If the secret for `payment_basepoint` is derived in a similar manner,
+it too can be easily recovered from just the `generation`, node key
+and peer `node_id`. However, it may also point to an address for a
+completely separate system (e.g. cold storage), so it is specified
+explicitly in the protocol.
#### The `tx_add_input` Message

2023-06-08 01:09:29 CEST

- reply

📅 Original date posted:2022-05-10
📝 Original message:Hi all,
TL;DR: a v1 tapscript opcode for generic covenants, but
OP_SUCCESS unless it's used a-la OP_CHECKTEMPLATEVERIFY. This gives an
obvious use case, with clean future expansion. OP_NOP4 can be
repurposed in future as a shortcut, if experience shows that to be a
useful optimization.
(This proposal builds on Russell O'Connor's TXHASH[1], with Anthony
Towns' modification via extending the opcode[2]; I also notice on
re-reading that James Lu had a similar restriction idea[3]).
Details
-------
OP_TX, when inside v1 tapscript, is followed by 4 bytes of flags.
Unknown flag patterns are OP_SUCCESS, though for thoroughness some future
potential uses are documented here. Note that pushing more than 1000
elements on the stack or an element more than 512 bytes will hit the
BIP-342 resource limits and fail.
Defined bits
------------
(Only those marked with * have to be defined for this soft fork; the
others can have semantics later).
OPTX_SEPARATELY: treat fields separately (vs concatenating)
OPTX_UNHASHED: push on the stack without hashing (vs SHA256 before push)
- The first nicely sidesteps the lack of OP_CAT, and the latter allows
OP_TXHASH semantics (and avoid stack element limits).
OPTX_SELECT_VERSION*: version
OPTX_SELECT_LOCKTIME*: nLocktime
OPTX_SELECT_INPUTNUM*: current input number
OPTX_SELECT_INPUTCOUNT*: number of inputs
OPTX_SELECT_OUTPUTCOUNT*: number of outputs
OPTX_INPUT_SINGLE: if set, pop input number off stack to apply to
OPTX_SELECT_INPUT_*, otherwise iterate through all.
OPTX_SELECT_INPUT_TXID: txid
OPTX_SELECT_INPUT_OUTNUM: txout index
OPTX_SELECT_INPUT_NSEQUENCE*: sequence number
OPTX_SELECT_INPUT_AMOUNT32x2: sats in, as a high-low u31 pair
OPTX_SELECT_INPUT_SCRIPT*: input scriptsig
OPTX_SELECT_INPUT_TAPBRANCH: ?
OPTX_SELECT_INPUT_TAPLEAF: ?
OPTX_OUTPUT_SINGLE: if set, pop input number off stack to apply to
OPTX_SELECT_OUTPUT_*, otherwise iterate through all.
OPTX_SELECT_OUTPUT_AMOUNT32x2*: sats out, as a high-low u31 pair
OPTX_SELECT_OUTPUT_SCRIPTPUBKEY*: output scriptpubkey
OPTX_SELECT_19...OPTX_SELECT_31: future expansion.
OP_CHECKTEMPLATEVERIFY is approximated by the following flags:
OPTX_SELECT_VERSION
OPTX_SELECT_LOCKTIME
OPTX_SELECT_INPUTCOUNT
OPTX_SELECT_INPUT_SCRIPT
OPTX_SELECT_INPUT_NSEQUENCE
OPTX_SELECT_OUTPUTCOUNT
OPTX_SELECT_OUTPUT_AMOUNT32x2
OPTX_SELECT_OUTPUT_SCRIPTPUBKEY
OPTX_SELECT_INPUTNUM
All other flag combinations result in OP_SUCCESS.
Discussion
----------
By enumerating exactly what can be committed to, it's absolutely clear
what is and isn't committed (and what you need to think about!).
The bits which separate concatenation and hashing provide a simple
mechanism for template-style (i.e. CTV-style) commitments, or for
programatic treatment of individual elements (e.g. amounts, though the
two s31 style is awkward: a 64-bit push flag could be added in future).
The lack of double-hashing of scriptsigs and other fields means we
cannot simply re-use hashing done for SIGHASH_ALL.
The OP_SUCCESS semantic is only valid in tapscript v1, so this does not
allow covenants for v0 segwit or pre-segwit inputs. If covenants prove
useful, dedicated opcodes can be provided for those cases (a-la
OP_CHECKTEMPLATEVERIFY).
Cheers,
Rusty.
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019819.html
[3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019816.html

2023-06-08 00:51:24 CEST

- reply

📅 Original date posted:2021-04-06
📝 Original message:Jeremy via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> writes:
> We had a very productive meeting today. Here is a summary of the meeting --
> I've done my best to
> summarize in an unbiased way. Thank you to everyone who attended.
>
> 1. On the use of a speedy trial variant:
>
> - There are no new objections to speedy trial generally.
> - There is desire to know if Rusty retracts or reaffirms his NACK in light
> of the responses.
I do not withdraw my NACK (and kudos: there have been few attempts to
pressure me to do so!).
The core question always was: what do we do if miners fail to activate?
Luke-Jr takes the approach that "we (i.e developers) ensure it activates
anyway". I take the approach that "the users must make a direct
intervention". Speedy Trial takes the approach that "let's pretend we
didn't *actually* ask them".
It's totally a political approach, to avoid facing the awkward question.
Since I believe that such prevaricating makes a future crisis less
predictable, I am forced to conclude that it makes bitcoin less robust.
Personally, I think the compromise position is using LOT=false and
having those such as Luke and myself continue working on a LOT=true
branch for future consideration. It's less than optimal, but I
appreciate that people want Taproot activated more than they want
the groundwork future upgrades.
I hope that helps,
Rusty.

2023-06-07 20:15:36 CEST

- reply

📅 Original date posted:2018-12-12
📝 Original message:Rusty Russell <rusty at rustcorp.com.au> writes:
>> However, I’m not sure if there is any useful NOINPUT case with unmasked script.
>
> This is *not* true of Eltoo; the script itself need not change for the
> rebinding (Christian, did something change?).
This is wrong, sorry. I re-checked the paper, and the constant for the
timelock comparison changes on each new update.
(The alternative was a new opcode like OP_TIMELOCKGREATERVERIFY which
required remembering the nLocktime for the UTXO).
So now my opinion is closer to yours: what's the use for NOINPUT &&
!NOMASK?
And is it worthwhile doing the mask complexity, rather than just
removing the commitment to script with NOINPUT? It *feels* safer to
restrict what scripts we can sign, but is it?
Note that NOINPUT is only useful when you can't just re-sign the tx, and
you need to be able to create a new tx even if this input is spent once
(an attacker can do this with SIGHASH_MASK or not!). ie. any other
inputs need to be signed NOINPUT or this one
SIGHASH_SINGLE|ANYONECANPAY.
You already need both key-reuse and amount-reuse to be exploited.
SIGHASH_MASK only prevents you from reusing this input for a "normal"
output; if you used this key for multiple scripts of the same form,
you're vulnerable[1]. Which, given the lightning software will be using
the One True Script, is more likely that your normal wallet using the
same keys.
So I don't think it's worth it. SIGHASH_NOINPUT is simply dangerous
with key-reuse, and Don't Do That.
Cheers,
Rusty.
[1] Attacker can basically clone channel state to another channel.

2023-06-07 20:15:36 CEST

- reply

📅 Original date posted:2018-12-12
📝 Original message:Johnson Lau <jl2012 at xbt.hk> writes:
>> On 12 Dec 2018, at 5:42 PM, Rusty Russell via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Pieter Wuille via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> writes:
>>> Here is a combined proposal:
>>> * Three new sighash flags are added: SIGHASH_NOINPUT, SIGHASH_NOFEE,
>>> and SIGHASH_SCRIPTMASK.
>>> * A new opcode OP_MASK is added, which acts as a NOP during execution.
>>> * The sighash is computed like in BIP143, but:
>>> * If SIGHASH_SCRIPTMASK is present, for every OP_MASK in scriptCode
>>> the subsequent opcode/push is removed.
>>
>> Having the SIGHASH_SCRIPTMASK flag is redundant AFAICT: why not always
>> perform mask-removal for signing?
>
> Because a hardware wallet may want to know what exact script it is signing?
OK, removing OP_MASKs unconditionally would introduce a hole without
some explicit flag to say they've been removed (the "real script" could
be something different with OP_MASKs). We could have the signature
commit to the outputscript, but that's a bit meh.
> Masked script has reduced security, but this is a tradeoff with
> functionality (e.g. eltoo can’t work without masking part of the
> script). So when you don’t need that extra functionality, you go back
> to better security
>
> However, I’m not sure if there is any useful NOINPUT case with unmasked script.
This is *not* true of Eltoo; the script itself need not change for the
rebinding (Christian, did something change?).
So, can we find an example where OP_MASK is useful?
>> If you're signing arbitrary scripts, you're surely in trouble already?
>>
>> And I am struggling to understand the role of scriptmask in a taproot
>> world, where the alternate script is both hidden and general?
>
> It makes sure that your signature is applicable to a specific script branch, not others (assuming you use the same pubkey in many branches, which is avoidable)
If I'm using SIGHASH_NOINPUT, I'm already required to take care with key
reuse.
Without a concrete taproot proposal it's hard to make assertions, but
if the signature flags that it's using the taproot script, it's
no less safe, and more general AFAICT.
Thanks!
Rusty.

2023-06-07 20:11:56 CEST

- reply

📅 Original date posted:2018-05-09
📝 Original message:Johnson Lau <jl2012 at xbt.hk> writes:
> You should make a “0 fee tx with exactly one OP_TRUE output” standard, but nothing else. This makes sure CPFP will always be needed, so the OP_TRUE output won’t pollute the UTXO set
That won't propagate :(
> Instead, would you consider to use ANYONECANPAY to sign the tx, so it
> is possible add more inputs for fees? The total tx size is bigger than
> the OP_TRUE approach, but you don’t need to ask for any protocol
> change.
No, that would change the TXID, which we rely on for HTLC transactions.
> In long-term, I think the right way is to have a more flexible SIGHASH system to allow people to add more inputs and outputs easily.
Agreed:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-April/015862.html
But in the long term we'll have Eltoo and SIGHASH_NOINPUT which both
allow different solutions.
Cheers,
Rusty.

2023-06-07 20:11:54 CEST

- reply

📅 Original date posted:2018-05-08
📝 Original message:Hi all,
The largest problem we are having today with the lightning
protocol is trying to predict future fees. Eltoo solves this elegantly,
but meanwhile we would like to include a 546 satoshi OP_TRUE output in
commitment transactions so that we use minimal fees and then use CPFP
(which can't be done at the moment due to CSV delays on outputs).
Unfortunately, we'd have to P2SH it at the moment as a raw 'OP_TRUE' is
non-standard. Are there any reasons not to suggest such a policy
change?
Thanks!
Rusty.

2023-06-07 20:11:28 CEST

- reply

📅 Original date posted:2018-04-02
📝 Original message:Hi all!
Since there's activity on new signature types, I think it's
worth considering a more flexible alternative to
SIGHASH_SINGLE|SIGHASH_ANYONECANPAY. See Usefulness for why.
Proposal: Two bits: SIGHASH_BUNDLESTART/SIGHASH_INBUNDLE
--------
A signature needs to indicate that signs only part of a transaction's
inputs and outputs (a.k.a. a "bundle"). Bundles can be combined
together into larger transactions, and non-bundled signature inputs /
outputs appended.
Two per-tx counters are kept: bundle_inputs_used and
bundle_outputs_used, both starting at 0.
SIGHASH_BUNDLESTART indicates two var_int sit between the sighash flags
and the signature itself: the first is the number of inputs in this
bundle starting at bundle_inputs_used, the second is the number of
outputs starting at bundle_outputs_used. bundle_inputs_used and
bundle_outputs_used have these values added, for next time.
SIGHASH_INBUNDLE indicates that this signature applies to the current
bundle. The txCopy is reduced to cover only the inputs and
outputs in the current bundle, and the signature commits to the two
var_ints from SIGHASH_BUNDLESTART along with the sighash flags.
(A proper BIP would detail how any weird stuff makes the tx invalid:
take that as read).
Usage
-----
You can use this to sign a transaction just like now, with only two
extra bytes and these SIGHASH flags. But this transaction can now be
aggregated by pasting on another bundle, or attaching other normal
inputs and/or outputs. You can aggregate as many transactions as you
want this way.
Usefulness
----------
One of the issues we've struck with lightning is trying to guess future
fees for commitment transactions: we can't rely on getting another
signature from our counterparty to increase fees. Nor can we use
parent-pays-for-child since the outputs we can spend are timelocked.
This "holding a valid tx but I want to add fees later without
re-signing" seems like a general problem. The only current method would
be to engineer transactions as a single-input-single-output tx and use
SIGHASH_SINGLE|SIGHASH_ANYONECANPAY; this is very limiting.
The other obvious application would be to run public aggregators, which
would provide throughput promises ("if you send me a tx with feerate X,
I will make sure it goes onchain within a week"). This service would
sometimes profit, if it can do so cheaper than it quoted, and sometimes
have to add additional fees. The existence of such services should
smooth the current fee cliff by allowing users and services to offer
"slow mode" payment options without requiring interaction.
Feedback welcome!
Rusty.

2023-06-07 19:50:21 CEST

- reply

📅 Original date posted:2016-05-10
📝 Original message:Gregory Maxwell <greg at xiph.org> writes:
> On Tue, May 10, 2016 at 5:28 AM, Rusty Russell via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> I used variable-length bit encodings, and used the shortest encoding
>> which is unique to you (including mempool). It's a little more work,
>> but for an average node transmitting a block with 1300 txs and another
>> ~3000 in the mempool, you expect about 12 bits per transaction. IOW,
>> about 1/5 of your current size. Critically, we might be able to fit in
>> two or three TCP packets.
>
> Hm. 12 bits sounds very small even giving those figures. Why failure
> rate were you targeting?
That's a good question; I was assuming a best-case in which we have
mempool set reconciliation (handwave) thus know they are close. But
there's also an alterior motive: any later more sophisticated approach
will want variable-length IDs, and I'd like Matt to do the work :)
In particular, you can significantly narrow the possibilities for a
block by sending the min-fee-per-kb and a list of "txs in my mempool
which didn't get in" and "txs which did despite not making the
fee-per-kb". Those turn out to be tiny, and often make set
reconciliation trivial. That's best done with variable-length IDs.
> (*Not interesting because it mostly reduces exposure to loss and the
> gods of TCP, but since those are the long poles in the latency tent,
> it's best to escape them entirely, see Matt's udp_wip branch.)
I'm not convinced on UDP; it always looks impressive, but then ends up
reimplementing TCP in practice. We should be well within a TCP window
for these, so it's hard to see where we'd win.
>> I would also avoid the nonce to save recalculating for each node, and
>> instead define an id as:
>
> Doing this would greatly increase the cost of a collision though, as
> it would happen in many places in the network at once over the on the
> network at once, rather than just happening on a single link, thus
> hardly impacting overall propagation.
"Greatly increase"? I don't see that.
Let's assume an attacker grinds out 10,000 txs with 128 bits of the same
TXID, and gets them all in a block. They then win the lottery and get a
collision. Now we have to transmit ~48 bytes more than expected.
> Using the same nonce means you also would not get a recovery gain from
> jointly decoding using compact blocks sent from multiple peers (which
> you'll have anyways in high bandwidth mode).
Not quite true, since if their mempools differ they'll use different
encoding lengths, but yes, you'll get less of this.
> With a nonce a sender does have the option of reusing what they got--
> but the actual encoding cost is negligible, for a 2500 transaction
> block its 27 microseconds (once per block, shared across all peers)
> using Pieter's suggestion of siphash 1-3 instead of the cheaper
> construct in the current draft.
>
> Of course, if you're going to check your whole mempool to reroll the
> nonce, thats another matter-- but that seems wasteful compared to just
> using a table driven size with a known negligible failure rate.
I'm not worried about the sender: The recipient needs to encode all the
mempool.
>> As Peter R points out, we could later enhance receiver to brute force
>> collisions (you could speed that by sending a XOR of all the txids, but
>> really if there are more than a few collisions, give up).
>
> The band between "no collisions" and "infeasible many" is fairly
> narrow. You can add a small amount more space to the ids and
> immediately be in the no collision zone.
Indeed, I would be adding extra bits in the sender and not implementing
brute force in the receiver. But I welcome someone else to do so.
Cheers,
Rusty.

2023-06-07 19:50:21 CEST

- reply

📅 Original date posted:2016-05-10
📝 Original message:Pieter Wuille via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> writes:
> On 05/03/2016 12:13 AM, lf-lists at mattcorallo.com (Matt Corallo) wrote:
>> Hi all,
>>
>> The following is a BIP-formatted design spec for compact block relay
>> designed to limit on wire bytes during block relay. You can find the
>> latest version of this document at
>> https://github.com/TheBlueMatt/bips/blob/master/bip-TODO.mediawiki.
>
> Hi Matt,
>
> thank you for working on this!
Indeed! Sorry for the delayed feedback.
>> |shortids||List of uint64_ts||8*shortids_length bytes||Little
>> Endian||The short transaction IDs calculated from the transactions which
>> were not provided explicitly in prefilledtxn
>
> I tried to derive what length of short ids is actually necessary (some
> write-up is on
> https://gist.github.com/sipa/b2eb2e486156b5509ac711edd16153ed but it's
> incomplete).
I did this for IBLT testing.
I used variable-length bit encodings, and used the shortest encoding
which is unique to you (including mempool). It's a little more work,
but for an average node transmitting a block with 1300 txs and another
~3000 in the mempool, you expect about 12 bits per transaction. IOW,
about 1/5 of your current size. Critically, we might be able to fit in
two or three TCP packets.
The wire encoding of all those bit arrays was:
[varint-min-numbits] - Shortest bit array length
[varint-array-size] - Number of bit arrays.
[varint-num].... - Number of entries in array N (x varint-array-size)
[packed-bit-arrays...]
Last byte was padded with zeros.
See: https://github.com/rustyrussell/bitcoin-iblt/blob/master/wire_encode.cpp#L12
I would also avoid the nonce to save recalculating for each node, and
instead define an id as:
[<64-bit-short-id>][txid]
Since you only ever send as many bits as needed to distinguish, this only
makes a difference if there actually are collisions.
As Peter R points out, we could later enhance receiver to brute force
collisions (you could speed that by sending a XOR of all the txids, but
really if there are more than a few collisions, give up).
And a prototype could just always send 64-bit ids to start.
Cheers,
Rusty.

2023-06-07 19:47:46 CEST

- reply

📅 Original date posted:2016-01-11
📝 Original message:Gavin Andresen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> writes:
> How many years until we think a 2^84 attack where the work is an ECDSA
> private->public key derivation will take a reasonable amount of time?
vanitygen can generate keypairs pretty fast (on my CPU it's comparable
with hashing time), and there are ways to make it faster. Since you can
generate multiple script variations, too, I think hashing is the
bottleneck.
Antminer S7 can do 4.73 Terahash per second for $1.2k. (Double SHA, but
let's assume RIPEMD160(SHA256()) is the same speed).
766,760,562,123 seconds to do 3*2^80, so you'd need over 200 million
S7s to do it in an hour.[1] If you want to do that for $1M, wait 27
years and hope Moore's Law holds?
Also, a colleague points out you could use this attack against a site
like bitrated.com which publishes one side's pubkey, giving you a much
longer attack window.
Cheers,
Rusty.
[1] Weirdly, the bitcoin network is doing this much work every 57
days, for about $92M. If that's all the attack costs, it's under
1M in 10 years.

2023-06-07 19:47:43 CEST

- reply

📅 Original date posted:2016-01-08
📝 Original message:Matt Corallo <lf-lists at mattcorallo.com> writes:
> Indeed, anything which uses P2SH is obviously vulnerable if there is
> an attack on RIPEMD160 which reduces it's security only marginally.
I don't think this is true? Even if you can generate a collision in
RIPEMD160, that doesn't help you since you need to create a specific
SHA256 hash for the RIPEMD160 preimage.
Even a preimage attack only helps if it leads to more than one preimage
fairly cheaply; that would make grinding out the SHA256 preimage easier.
AFAICT even MD4 isn't this broken.
But just with Moore's law (doubling every 18 months), we'll worry about
economically viable attacks in 20 years.[1]
That's far enough away that I would choose simplicity, and have all SW
scriptPubKeys simply be "<0> RIPEMD(SHA256(WP))" for now, but it's
not a no-brainer.
Cheers,
Rusty.
[1] Assume bitcoin-network-level compute (collision in 19 days) costs
$1B to build today. Assume there will be 100 million dollars a day
in vulnerable txs, and you're on one end of all of them (or can MITM
if you find a collision), *and* can delay them all by 10 seconds,
and none are in parallel so you can attack all of them. IOW, just
like a single $100M opportunity for 3650 seconds each year.
Our machine has a 0.11% chance of finding a collision in 1 hour, so
it's worth about $110,000. We can build it for that in about 20
years.

2023-06-07 19:46:48 CEST

- reply

📅 Original date posted:2015-12-20
📝 Original message:Jonathan Toomim via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
writes:
> On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> 1) The risk of an old full node wallet accepting a transaction that is
>> invalid to the new rules.
>>
>> The receiver wallet chooses what address/script to accept coins on.
>> They'll upgrade to the new softfork rules before creating an address
>> that depends on the softfork's features.
>>
>> So, not a problem.
>
>
> Mallory wants to defraud Bob with a 1 BTC payment for some beer. Bob
> runs the old rules. Bob creates a p2pkh address for Mallory to
> use. Mallory takes 1 BTC, and creates an invalid SegWit transaction
> that Bob cannot properly validate and that pays into one of Mallory's
> wallets. Mallory then immediately spends the unconfirmed transaction
> into Bob's address. Bob sees what appears to be a valid transaction
> chain which is not actually valid.
Pretty sure Bob's wallet will be looking for "OP_DUP OP_HASH160
<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG" scriptSig. The SegWit-usable
outputs will (have to) look different, won't they?
Cheers,
Rusty.

2023-06-07 19:45:26 CEST

- reply

📅 Original date posted:2015-12-03
📝 Original message:Gavin Andresen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
writes:
> On Wed, Dec 2, 2015 at 1:57 PM, Emin Gün Sirer <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> How to Do It
>>
>> If we want to compress Bitcoin, a programming challenge/contest would be
>> one of the best ways to find the best possible, Bitcoin-specific
>> compressor. This is the kind of self-contained exercise that bright young
>> hackers love to tackle. It'd bring in new programmers into the ecosystem,
>> and many of us would love to discover the limits of compressibility for
>> Bitcoin bits on a wire. And the results would be interesting even if the
>> final compression engine is not enabled by default, or not even merged.
>>
>
> I love this idea. Lets build a standardized data set to test against using
> real data from the network (has anybody done this yet?).
https://github.com/rustyrussell/bitcoin-corpus
It includes mempool contents and tx receipt logs for 1 week across 4
nodes. I vaguely plan to update it every year.
A more ambitious version would add some topology information, but we
need to figure out some anonymization strategy for the data.
Cheers,
Rusty.

2023-06-07 19:41:56 CEST

- reply

📅 Original date posted:2015-09-30
📝 Original message:Adam Back <adam at cypherspace.org> writes:
> I think from discussion with Gavin sometime during the montreal
> scaling bitcoin workshop, XT maybe willing to make things easy and
> adapt what it's doing. For example in relation to versionBits Gavin
> said he'd be willing to update XT with an updated/improved
> versionBits, for example.
>
> It seems more sensible to do what is simple and clean and have both
> core do that, and XT follow if there is no particular philosophy
> debate on a given technical topic. This seems a quite constructive
> approach.
That too, but let's not break existing software. This proposal allows
that, and is trivial.
Cheers,
Rusty.

2023-06-07 19:41:56 CEST

- reply

📅 Original date posted:2015-09-30
📝 Original message:John Winslow via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
writes:
> Two observations from a Bitcoin investor and non-programmer:
Please take this off the -dev list.
Thanks,
Rusty.

2023-06-07 19:40:10 CEST

- reply

📅 Original date posted:2015-09-29
📝 Original message:Tom Harding via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
writes:
> On 9/13/2015 11:56 AM, Rusty Russell via bitcoin-dev wrote:
>> '''Success: Activation Delay'''
>> The consensus rules related to ''locked-in'' soft fork will be enforced in
>> the second retarget period; ie. there is a one retarget period in
>> which the remaining 5% can upgrade. At the that activation block and
>> after, the bit B may be reused for a different soft fork.
>>
>
> Rather than a simple one-period delay, should there be a one-period
> "burn-in" to show sustained support of the threshold? During this
> period, support must continuously remain above the threshold. Any lapse
> resets to inactivated state.
>
> With a simple delay, you can have the embarrassing situation where
> support falls off during the delay period and there is far below
> threshold support just moments prior to enforcement, but enforcement
> happens anyway.
Yeah, but Gavin's right. If you can't account for all the corner cases,
all you can do is keep it simple and well defined.
Thanks,
Rusty.

2023-06-07 19:40:10 CEST

- reply

📅 Original date posted:2015-09-17
📝 Original message:Tier Nolan via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> writes:
> On Wed, Sep 16, 2015 at 9:19 PM, Rusty Russell <rusty at rustcorp.com.au>
> wrote:
>> You need a timeout: an ancient (non-mining, thus undetectable) node
>> should never fork itself off the network because someone reused a failed
>> BIP bit.
>>
>
> I meant if the 2nd bit was part of the BIP. One of the 2 bits is "FOR" and
> the other is "AGAINST". If against hits 25%, then it is deemed a failure.
>
> The 2nd bit wouldn't be used normally. This means that proposals can be
> killed quickly if they are obviously going to fail.
This could be added if we approach one failed soft fork every 5 weeks,
I guess (or it could be just for specific soft forks).
Cheers,
Rusty.

2023-06-07 19:31:35 CEST

- reply

2023-06-07 17:36:41 CEST

- reply

📅 Original date posted:2015-06-06
📝 Original message:Title: Canonical Input and Output Ordering
Author: Rusty Russell <rusty at rustcorp.com.au>
Discussions-To: "Bitcoin Dev" <bitcoin-development at lists.sourceforge.net>
Status: Draft
Type: Standards Track
Created: 2015-06-06
Abstract
This BIP provides a canonical ordering of inputs and outputs when
creating transactions.
Motivation
Most bitcoin wallet implementations randomize the outputs of
transactions they create to avoid trivial linkage analysis (especially
change outputs), however implementations have made mistakes in this area
in the past.
Using a canonical ordering has the same effect, but is simpler, more
obvious if incorrect, and can eventually be enforced by IsStandard() and
even a soft-fork to enforce it.
Specification
Inputs should be ordered like so:
index (lower value first)
txid (little endian order, lower byte first)
Outputs should be ordered like so:
amount (lower value first)
script (starting from first byte, lower byte first, shorter wins)
Rationale
Any single wallet is already free to implement this, but if other
wallets do not it would reduce privacy by making those transactions
stand out. Thus a BIP is appropriate, especially if this were to
become an IsStandard() rule once widely adopted.
Because integers are fast to compare, they're sorted first, before the
lexographical ordering.
The other input fields do not influence the sort order, as any valid
transactions cannot have two inputs with the same index and txid.
Reference Implementation
https://github.com/rustyrussell/bitcoin/tree/bip-in-out-ordering

2023-06-07 17:34:02 CEST

- reply

📅 Original date posted:2015-05-17
📝 Original message:Tier Nolan <tier.nolan at gmail.com> writes:
> On Sat, May 16, 2015 at 1:22 AM, Rusty Russell <rusty at rustcorp.com.au>
> wrote:
>> 3) ... or maybe not, if any consumed UTXO was generated before the soft
>> fork (reducing Tier's perverse incentive).
>
> The incentive problem can be fixed by excluding UTXOs from blocks before a
> certain count.
>
> UTXOs in blocks before 375000 don't count.
OK. Be nice if these were cleaned up, but I guess it's a sunk cost.
>> 4) How do we measure UTXO size? There are some constant-ish things in
>> there (eg. txid as key, height, outnum, amount). Maybe just add 32
>> to scriptlen?
>>
>
> They can be stored as a fixed digest. That can be any size, depending on
> security requirements.
>
> Gmaxwell's cost proposal is 3-4 bytes per UTXO change. It isn't
> 4*UXTO.size - 3*UTXO.size
He said "utxo_created_size" not "utxo_created" so I assumed scriptlen?
> It is only a small nudge. With only 10% of the block space to play with it
> can't be massive.
But you made that number up? The soft cap and hard byte limit are
different beasts, so there's no need for soft cost cap < hard byte
limit.
> This requires that transactions include scriptPubKey information when
> broadcasting them.
Brilliant! I completely missed that possibility...
>> 5) Add a CHECKSIG cost. Naively, since we allow 20,000 CHECKSIGs and
>> 1MB blocks, that implies a cost of 50 bytes per CHECKSIG (but counted
>> correctly, unlike now).
>>
>> This last one implies that the initial cost limit would be 2M, but in
>> practice probably somewhere in the middle.
>>
>> tx_cost = 50*num-CHECKSIG
>> + tx_bytes
>> + 4*utxo_created_size
>> - 3*utxo_consumed_size
>>
>> > A 250 byte transaction with 2 inputs and 2 outputs would have an adjusted
>> > size of 252 bytes.
>>
>> Now cost == 352.
>
> That is to large a cost for a 10% block change. It could be included in
> the block size hard fork though.
I don't think so. Again, you're mixing units.
> I think have one combined "cost" for
> transactions is good. It means much fewer spread out transaction checks.
> The code for the cost formula would be in one place.
Agreed! Unfortunately there'll always be 2, because we really do want a
hard byte limit: it's total tx bytes which brings most concerns about
centralization. But ideally it'll be so rarely hit that it can be ~
ignored (and certainly not optimized for).
Cheers,
Rusty.

2023-06-07 17:28:51 CEST

- reply

📅 Original date posted:2015-01-21
📝 Original message:Pieter Wuille <pieter.wuille at gmail.com> writes:
> Hello everyone,
>
> We've been aware of the risk of depending on OpenSSL for consensus
> rules for a while, and were trying to get rid of this as part of BIP
> 62 (malleability protection), which was however postponed due to
> unforeseen complexities. The recent evens (see the thread titled
> "OpenSSL 1.0.0p / 1.0.1k incompatible, causes blockchain rejection."
> on this mailing list) have made it clear that the problem is very
> real, however, and I would prefer to have a fundamental solution for
> it sooner rather than later.
>
> I therefore propose a softfork to make non-DER signatures illegal
> (they've been non-standard since v0.8.0). A draft BIP text can be
> found on:
>
> https://gist.github.com/sipa/5d12c343746dad376c80
Cut and paste bug in the last check:
// Null bytes at the start of R are not allowed, unless it would otherwise be
// interpreted as a negative number.
if (lenS > 1 && (sig[lenR + 6] == 0x00) && !(sig[lenR + 7] & 0x80))
return false;
You mean "null bytes at the start of S".
Cheers,
Rusty.