Rusty Russell
Rusty Russell
A simple protocol for upgrades, splices and other things which are easier when no updates are in-flight.
With AMP, we'll effectively be probing for channel capacity. Returning how far out a payment was provides a hint. You can determine the order required, then fuzz it a little,...
This is the simplest upgrade mechanism I could come up with. It's ready for option_anchors_zero_fee_htlc_tx, too. Note the reason it's on reconnect: whatever we do, we need to handle reconnect...
Features are assigned along with spec approval, so they don't happen in this order, but here's a list of things with made-up assignments for testing: New local / node features:...
We can't say "MUST spend via HTLC-success" and "MUST NOT reveal preimage", since the HTLC-success does exactly that! Let's simplify it. If you get the preimage from the outgoing HTLC,...
Hi all, this is the framework I've been using to test various event scenarios. So far it has found twofour significant issues in our implementation. It has some simple coverage...
For 1.1 we should aim for JSON test vectors, outside the spec document itself. eg. bolt01/test-x-y-x.json.
It was pointed out to me at thelightningconference.com that it's often a legal requirement to list the vendor on a receipt. It also makes perfect sense. It can be done...
And use that term in BOLT 2's retransmission section, to avoid confusion. In particular: a node can't send `announcement_signatures` before both sides have agreed on `funding_locked` and thus consider the...
c-lightning uses a dumb system where the secrets (including the delayed_payment_point_secret and payment_point_secret which aren't needed for normal channel operation) are derived from a single seed using HKDF. Since we're...