We always set `nSequence` to `0xFFFFFFFD`, but each node can choose the
`nLockTime` they want to use for the transactions for which they are
paying the fees.
Bitcoin Core version 25+ will not broadcast transactions containing
`OP_RETURN` outputs if their amount is greater than 0, because this
amount would then be unspendable. We thus require that the output
amount is set to 0 when using `OP_RETURN`.
We don't care, as long as it's RBF-able. This will be nicer for
Taproot when mutual closes are otherwise indistinguishable from normal
spends.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
- Make it clear why the OP_RETURN restrictions have two forms.
- Cross-reference existing dust threshold
- Lots of typo fixes
- Don't set closer_and_closee if we're larger/equal, and closee is dust.
- Remove Rationale on delete zero-output tx hack.
This gets around "but both our outputs are dust!" problems, as
recommended by Anthony Towns.
I hope I interpreted the standardness rules correctly (technically,
you can have multiple pushes in an OP_RETURN as long as the total is
under 83 bytes, but let's keep it simple).
Add an explicit note that "OP_RETURN" is never considered "uneconomic".
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If both are dust, you should lowball fees. The next patch adds OP_RETURN
as a valid shutdown scriptpubkey though if you really want to do this.
This also addresses the case where people send a new `shutdown` with a *different* scriptpubkey. This could previously cause a race where you receive a bad signature (because it hasn't received the updated shutdown), so we ignore these cases.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The shutdown section says:
```
- MUST NOT send multiple `shutdown` messages.
```
But the reconnection section says:
```
- upon reconnection:
- if it has sent a previous `shutdown`:
- MUST retransmit `shutdown`.
```
So clearly, remove the former.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a follow-up of #1215, where we keep reworking the announcement
requirements.
We remove the rationale around deferring after `channel_ready` since
that has been changed years ago and shouldn't be an issue anymore.
We slightly rework the wording to minimize future conflicts with the
splicing PR.
While nodes are free to send `announcement_signatures` whenever they
feel that the channel is safe from reorg, we disallow broadcasting the
`channel_announcement` before at least 6 confirmations: this gives nodes
a simple heuristic to ignore `channel_announcement`s for remote channels
that aren't spec-compliant, without having to deal with the extra cost
of managing reorgs.
This commit is adding a link to the ML archive and redirecting
users to the delvingbitcoin forum instead of the obsolete ML.
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Co-authored-by: Bastien Teinturier <31281497+t-bast@users.noreply.github.com>
It's inserted weirdly (splits a paragraph, so otherwise clause is wrong), and all invreq fields
are mirrored in the invoice.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We previously required waiting for 6 confirmations before sending
`announcement_signatures`, but the real criteria is that it should only
be sent once you are confident that a reorg will not invalidate it.
No need to be too prescriptive, but examples are good. This is a
pretty generic Code of Conduct that just says if you disrupt
people's ability to contribute or harass someone, you will be shown
the door.
It describes a Code of Conduct committee, which we'll need to
define.
BIP 353 defines a method for resolving Human Readable Names (in the
form ₿`name`@`domain`) into bitcoin: URIs. In order to use them with
BOLT 12 with a wildcard DNS entry which resolves to a single
BOLT 12 offer for all `name`s in a domain, we need a way to
disambiguate the `name` being paid in an `invoice_request` which we
provide here by simply copying the HRN into the `invoice_request`.
A BOLT11 "invoice" has proven too low-level for human use in many
scenarios. Efforts like lnurl have covered the gap, but integrating
some of such higher layers into the lightning protocol itself has many
advantages.
This draft defines three new things:
1. A new invoice format. I know, this is painful, but it maps almost
1:1 to the current format (though signatures are very different),
is easier to implement, and easier to send via the lightning
network itself.
2. Formats for an "offer", which for all intents and purposes serves
as the new, persistent invoice for users.
3. Format for an "invoice_request": this is a message sent via the
lightning network itself to receive the real invoice, or can
be used directly in a send-money scenario (e.g. ATM).
The offer (for accepting payments) or invoice_request (for sending
payments) are usually presented via a QR code or similar, the replies
are sent using onion messages. Each copies fields from the prior so
it stands alone, to allow statelessness.
Features which have been deliberately omitted for the initial version:
- Recurrence.
- Invoice replacement ("don't accept that old payment!")
- Payer proof for refunds.
This effort has been EPIC, and there is absolutely no way I could have
done this without the often thankless task of implementing,
re-implementing, revising and re-reading this text.
In particular I have been delighted to receive the mental boost from
the following people:
1. Thomas H of ACINQ (https://github.com/thomash-acinq)
2. Jeffrey Czyz of Square Crypto (https://github.com/jkczyz)
3. Joost Jager (https://github.com/joostjager)
4. Aditya Sharma (https://github.com/adi2011)
5. Rene Pickhardt (https://github.com/renepickhardt)
6. Bastien Teinturier of ACINQ (https://github.com/t-bast)
7. Valentine Wallace of LDK (https://github.com/valentinewallace)
8. Matt Corallo of LDK (https://github.com/BlueMatt)
Also @bjarnemagnussen, @ellemouton, @animatedbarber, @617a7a,
@instagibbs, @evansmj, @eupn and @yyforyongyu.
(And no doubt others over the years, who I've accidentally omitted!)
Yes, of course, thanks to my family for their patience with me.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Offers may contain blinded paths to allow for greater recipient privacy.
However, they come at a cost of increased QR code size as the
introduction node requires a 33-byte `point`.
Define a new `sciddir_or_pubkey` fundamental type such that either a point or a
reference to one in a `channel_announcement` can be used. This is
backwards compatible with `point`.
Use this new type for the `blinded_path` subtype's `first_node_id`.
Offers may contain blinded paths to allow for greater recipient privacy.
However, they come at a cost of increased QR code size as each hop
requires a 33-byte `point` for the `next_node_id`. Allow using
`short_channel_id` instead, which only requires 8 bytes.
Still allow for use of `next_node_id` for cases where the blinded path
may not involve channel counterparties or for long-lived offers, which
may outlive the given channels.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It's far easier to validate these on parsing than to hand-validate them
elsewhere.
I didn't turn `alias` or `error` into this, though they're similar
(`alias` can have a nul terminator).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* bolt03: fix link to `bitcoind`'s `policy.cpp` file
The original link is broken, we now replace it with a permalink.
* bolt03: remove 0 `txout` count in closing tx
Txns cannot have zero outputs.
* bolt03: remove wrong ref to `remotepubkey` and fix format
`remotepubkey` has been placed at the wrong place, also fixes the format
so it's easier to read.
All the test vectors use static keys now, which are listed above
already as the local_payment_basepoint and remote_payment_basepoint.
The keys listed here are the pre-static rotated ones: if you use
these, the vectors don't work!
We actually use the same basepoint for the HTLCs, but never spelled it
out. So do that now, and these are the local/remote htlc keys.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
1. Always use the term `encrypted_recipient_data` for the encrypted field:
it's confusing enough without multiple names!
2. Don't give an option for joining blinded payments, since everyone will
use an unblinded payment to the introduction node (at least, for now).
3. Avoid the term "payer" and at least note that encrypted_recipient_data
can be made by the sender themselves, pointing out that the forwarding
node cannot tell.
Thanks t-bast and gijswijs for this feedback!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It's a bit complex, but try to convey the idea of an introduction point,
blinded node ids and encrypted blobs. Since the requirements detail the
two ways to reach the introduction node, I handwaved on that a bit.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Writer parts:
1. Be explicit that the writer creates a route.
2. Make it clear we create shared secrets, then derive blinded points.
3. Refer explicitly to all `blinded_path` fields.
Split reader into the *two* readers:
1. The reader of the blinded path, who uses it to make an onion (which wasn't described at all!)
2. The reader of the encrypted_recipient_data, who decrypts it.
In the latter case, we don't have to discuss unblinding the onion since
that's now covered in the "Onion Decryption" section.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
