Nostr notes by

📅 Original date posted:2023-09-10 🗒️ Summary of this ...

2023-09-12T10:59:58+02:00

In reply to nevent1q…kzvp
_________________________

📅 Original date posted:2023-09-10
🗒️ Summary of this message: There is a tradeoff between trust and capital efficiency when it comes to UTXOs and lightning updates. If a user cheats, it can result in a large number of on-chain transactions. The impact of these transactions depends on the timeframe and can affect fees. Users can calculate the number of transactions based on their desired timeframe and adjust their rollover accordingly. This reduces the capital efficiency for the user who cheated. Casual users cannot easily reduce their timeout by splitting into different UTXOs.
📝 Original message:
On Fri, Sep 08, 2023 at 06:54:46PM +0000, jlspc via Lightning-dev wrote:
> TL;DR
> =====

I haven't really digested this, but I think there's a trust vs
capital-efficiency tradeoff here that's worth extracting.

Suppose you have a single UTXO, that's claimable by "B" at time T+L,
but at time T that UTXO holds funds belonging not only to B, but also
millions of casual users, C_1..C_1000000. If B cheats (eg by not signing
any further lightning updates between now and time T+L), then each
casual user needs to drop their channel to the chain, or else lose all
their funds. (Passive rollovers doesn't change this -- it just moves the
responsibility for dropping the channel to the chain to some other
participant)

That then faces the "thundering herd" problem -- instead of the single
one-in/one-out tx that we expected when B is doing the right thing,
we're instead seeing between 1M and 2M on-chain txs as everyone recovers
their funds (the number of casual users multiplied by some factor that
depends on how many outputs each internal tx has).

But whether an additional couple of million txs is a problem depends
on how long a timeframe they're spread over -- if it's a day or two,
then it might simply be impossible; if it's over a year or more, it
may not even be noticable; if it's somewhere in between, it might just
mean you're paying a modest amount in additional fees than you'd have
normally expected.

Suppose that casual users have a factor in mind, eg "If worst comes to
worst, and everyone decides to exit at the same time I do, I want to be
sure that only generates 100 extra transactions per block if everyone
wants to recover their funds prior to B being able to steal everything".

Then in that case, they can calculate along the following lines: 1M users
with 2-outputs per internal tx means 2M transactions, divide that by 100
gives 20k blocks, at 144 blocks per day, that's 5 months. Therefore,
I'm going to ensure all my funds are rolled over to a new utxo while
there's at least 5 months left on the timeout.

That lowers B's capital efficiency -- if all the causal users follow
that policy, then B is going to own all the funds in Fx for five whole
months before it can access them. So each utxo here has its total
lifetime (L) actually split into two phases: an active lifetime LA of
some period, and an inactive lifetime of LI=5 months, which would have
been used by everyone to recover their funds if B had attempted to block
normal rollover. The capital efficiency is then reduced by a factor of
1/(1+LA/LI). (LI is dependent on the number of users, their willingness
to pay high fees to recover their funds, and global blockchain capacity,
LA is L-LI, L is your choice)

Note that casual users can't easily reduce their LI timeout just by
having the provider split them into different utxos -- if the provider
cheats/fails, that's almost certainly a correlated across all their
utxos, and all the participants across each of those utxos will need
to drop to the chain to preserve their funds, each competing with each
other for confirmation.

Also, if different providers collude, they can cause problems: if you
expected 2M transactions over five months due to one provider failing,
that's one thing; but if a dozen providers fail simultaneously, then that
balloons up to perhaps 24M txs over the same five months, or perhaps 25%
of every block, which may be quite a different matter.

Ignoring that caveat, what do numbers here look like? If you're a provider
who issues a new utxo every week (so new customers can join without too
much delay), have a million casual users as customers, and target LA=16
weeks (~3.5 months), so users don't need to rollover too frequently,
and each user has a balanced channel with $2000 of their own funds,
and $2000 of your funds, so they can both pay and be paid, then your
utxos might look like:

active_1 through active_16: 62,500 users each; $250M balance each
inactive_17 through inactive_35: $250M balance each, all your funds,
waiting for timeout to be usable

That's:
* $2B of user funds
* $2B of your funds in active channels
* $4.5B of your funds locked up, waiting for timeout

In that case, only 30% of the $6.5B worth of working capital that you've
dedicated to lightning is actually available for routing.

Optimising that formula by making LA as large as possible doesn't
necessarily work -- if a casual user spends all their funds and
disappears prior to the active lifetime running out, then those
funds can't be easily spent by B until the total lifetime runs out,
so depending on how persistent your casual users are, I think that's
another way of ending up with your capital locked up unproductively.
(There are probably ways around this with additional complexity: eg,
you could peer with a dedicated node, and have the timeout path be
"you+them+timeout", so that while you could steal from casual users who
don't rollover, you can't steal from your dedicated peer, so that $4.5B
could be rolled into a channel with them, and used for routing)

You could perhaps also vary the timeout at different layers of the
internal tree -- if you have 500k users with a $10 balance, and give them
a timeout of 16 weeks, and give the remaining 500k with an average $2000
balance a timeout of 26 weeks, then each will calculate LI=10 weeks,
and the $10 folks will rollover at 1.5 months, and the remainder will
rollover at about 4 months; but your idle balance will be $5M for 20
weeks plus $1B for 10 weeks, rather than $1.005B for 20 weeks.

Anyway, I think that's an interesting way of capturing a big concern
with this sort of approach (namely, "what happens if the nice, scalable
path doesn't work, and we have to dump *LOTS* of stuff onchain") in a
measurable way.

Cheers,
aj

📅 Original date posted:2023-04-03 🗒️ Summary of this ...

2023-06-09T15:12:57+02:00

In reply to nevent1q…y0xe
_________________________

📅 Original date posted:2023-04-03
🗒️ Summary of this message: A new construction called tunable penalties has been introduced for 2-party lightning channels, allowing for layered commit transactions and preventing loss of funds due to cheating.
📝 Original message:
On Sat, Mar 18, 2023 at 12:41:00AM +0000, jlspc via Lightning-dev wrote:
> TL;DR

Even with Harding's optech write ups, and the optech space, I barely
follow all this, so I'm going to try explaining it too as a way of
understanding it myself; hopefully maybe that helps someone. Corrections
welcome, obviously!

I think understanding all this requires going through each of the four
steps.

Step 1: Tunable penalties;
https://github.com/JohnLaw2/ln-tunable-penalties
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-October/003732.html

This is a clever constructions that lets you do a 2-party lightning
channel with existing opcodes where cheating doesn't result in you
losing all your funds (or, in fact, any of your in-channel funds). It
also retains the ability to do layered commit transactions, that is you can
immediately commit to claiming an HTLC or that it's already timed out,
even while you're waiting for the to_self_delay to expire to ensure
you're not cheating.

The way that it works is by separating the flow of channels funds, from
the control flow. So instead of managing the channel via a single utxo,
we instead manage it via 3 utxos: F (the channel funds), InA (control
flow for a unilateral close by A), InB (control flow for a unilateral
close by B).

For each update to a new state "i", which has "k" HTLCs, we create 4 primary txs, and 8k HTLC claims.

StAi which spends InA, and has k+1 outputs. The first output is used
for controlling broadcast of the commitment tx, the remaining k are for
controlling the resolution of each HTLC.

ComAi is the commitment for the state. It spends the funding output
F, and the first output of StAi. In order to spend StAi, it requires
a to_self_delay (and signature by A), giving B time to object that i
is a revoked state. If B does object, he is able to immediately spend
the first output of StAi directly using the revocation information,
and these funds form the penalty. It has k+2 outputs, one for the
balance of each participant, and one for each HTLC.

For each of the k HTLCs, we construct two success and two timeout
transactions: (HAi-j-s, HAi-j-p); (HAi-j-t, HAi-j-r). HAi-j-s and
HAi-j-t both spend the jth output of StAi, conditional either on a
preimage reveal or a timeout respectively; HAi-j-p and HAi-j-r spend
the output of HAi-j-s and HAi-j-t respectively, as well as the output
of ComAi. (s=success commitment, t=timeout commitment, p=payment on
success, r=refund)

And Bob has similar versions of all of these.

So if Alice is honest, the process is:

* Alice publishes StAi
* Alice publishes HAi-j-{s,t} for any HTLCs she is able to resolve
immediately; as does Bob.
* Alice waits for to_self_delay to complete
* Alice publishes ComAi, and any HAi-j-{r,p} transactions she is able
to, and if desired consolidates her funds.
* As any remaining HTLCs resolve, those are also claimed.
* Bob's InB output is available to do whatever he wants with.

If Alice is dishonest, the process is:

* Alice publishes StAi, and perhaps publishes some HAi-j-{s,t}
transactions.
* Bob spends the first output of StAi unilaterally claiming the
* penalty, meaning ComAi can now never be confirmed.
* Bob publishes StBi', and continues with the honest protocol.

Bob only needs the usual O(log(n)) state in order to be able to
reconstruct the key to spend the first output of revoked StAi txs.
Because that prevents the corresponding ComAi from ever being published,
no revoked HTLC-related state can make it on chain in any way that Bob
needs to care about.

If both Alice and Bob are dishonest (Alice tries to cheat, but Bob
restored from an old backup and also publishes a revoked state) then
both the StAi and StBi' may have their first output claimed by the other
party, in which case the channels funds are lost (unless Alice and Bob
manage to agree to a cooperative close somehow, even after all the
attempts to cheat each other).

While 4+8k transactions per state is a lot, I think you only actually
need 2+4k signatures in advance (StAi and HAi-j-{s,t} only need to be
signed when they're broadcast). Perhaps using ANYPREVOUT would let you
reduce the number of HTLC states?

Step 2: Efficient Factories for Lightning Channels
https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-January/003827.html
https://github.com/JohnLaw2/ln-efficient-factories

This generalizes the tunable penalties setup for more than two
participants.

The first part of this is a straightforward generalisation, and
doesn't cover HTLCs. Where we had 2(2+4k) transactions previously, we
presumably would now have P(2+4k) transactions, where P is the number
of participants.

The second part of this aims to avoid that factor P. It does this by
introducing Trigger and Mold transactions.

To do this, we first establish the number of states that the factory
will support; perhaps 2**40. In that case, the trigger transaction will
spend the funding tx, and have 40+1 outputs. All of them will require a
P-of-P signature to be spend, with the first also requiring a relative
timelock of 3*to_self_delay and containing the channel funds, while the
rest contain dust-ish amounts.

For any given state i, we represent i as a binary number, and the
commitment tx Com_i will spend the outputs corresponding to "0" in
the binary number, as well as the first output containing the channel
funds.

We will also have St{A..Z}_i transactions, spending In{A..Z} as
previously. The sole output of StAi (etc) will be spent either by any
other participant via a revoked pubkey, or else by the Mold{A..Z}_i
transaction. The Mold{A..Z}_i transaction will also spend the remaining
outputs of the Trigger transaction that were not spent by Com_i.

In the honest scenario, this looks like:

* Alice publishes Trigger
* Alice publishes StA_i
* Alice waits to_self_delay
* Alice publishes MoldA_i
* Alice waits an additional 2*to_self_delay
* Alice publishes Com_i
* Alice and everyone else claims their funds

There are various dishonest scenarios available:

* If Alice publishes StA_i before publishing the Trigger, someone else
publishes the Trigger.

* If Alice doesn't publish StA_i quickly, Bob publishes StB_i
and continues. If multiple St{A..Z}_i's are published, whoever does
not publish the Mold transaction simply reclaims their funds by the
"revocation" path.

* If Alice publishes an old StA_i, Bob claims the funds using the
revoked key, penalising A, and then publishes the correct StB_i,
and continues.

* If Alice does not publish MoldA_i, Bob can publish StB_i and MoldB_i.

* Once MoldB_i is confirmed, someone could attempt to broadcast an
outdated Com_i' where i' < i. In that case, the outputs corresponding
to all the 1's in the binary representation of i are already spent
(by MoldB_i), but for any i' < i, the i' necessarily has a 0 somewhere
where i had a 1 (otherwise i' >= i), so Com_i' would be double spending
an input already spent by MoldB_i.

In this case, you need to track P+1 outputs (F+InA..Z), you need
O(P*log(N)) state, and the onchain impact of a unilateral close is ideally
4 transactions (Trigger, StAi, MoldAi, Comi) with size O(log(MaxN)),
but maybe be up to 2*P+2 transactions (Trigger, St{A..Z}i, MoldAi,
refund{B..Z}i, Comi).

Note that this doesn't consider HTLCs at all.

Step 3: Factory Optimized protocols for Lighting
https://github.com/JohnLaw2/ln-factory-optimized
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-December/003782.html
https://bitcoinops.org/en/newsletters/2022/12/14/#factory-optimized-ln-protocol-proposal

Perhaps this should have been step 2, whoopsie. Anyway, this optimises
the construction in step 1 for channels included in factories; mostly
to deal with the fact that closing a factory is tedious and can take a
while. I'm ignoring the Partial-Factory-Optimized step -- it's barely
different to the Tunable Penalty mechanism. The Fully Factory Optimized
protocol is more interesting.

The main idea here is this: if a channel in a factory goes defunct while
an HTLC is pending, we'd like to be able to guarantee we've resolved
the HTLC to our satisfaction while deferring the decision of whether
to shutdown the entire factory in order to close the channel, just
in case our channel partner eventually comes back, and we can resolve
everything properly.

The way we do that is twofold: first, we set things up so that the default
resolution of an HTLC is a refund. That immediately does away with half
of our HTLC transactions, because now we only need the success/payment
paths, not the timeout/refund ones. Second, we require whoever's
going to receive the payment to publish their StXi transaction -- that
avoids us having to do P*k success/payment paths, now we only need 1*k
success/payment paths. Unfortunately, we do introduce a new "kickoff"
transaction to make it a three transaction kickoff/success/payment path,
rather than just two transactions.

In this case your transactions are:

F - the funding output, only available once the factory is closed
InB - as before
StBi - your state commitment, one output that will be spent by ComBi,
k outputs for each pending HTLC paying to B in state i.
HBi-j-k - the kickoff transaction for HTLC "j" paying to B, spends
the appropriate output of StBi, conditional on revealing the
HTLC preimage and B's signature. Spendable either by B after
to-self-delay, or by A after the HTLC's expiry plus
to-self-delay
HBi-j-s - the success transaction, spendable by B
HBi-j-p - the payment transaction, spends HBi-j-s and the HTLC output
from ComB_i
HAi-j-p - the payment transaction, spends HBi-j-s and the HTLC output
from ComA_i

I think there's an error in the paper here; it says as well as being
spendable by H{A,B}i-j-p as above, the HTLC output in ComA_i should be
spendable by A after to-self-delay. I believe it should require both
to-self-delay (relative timelock) and the HTLC expiry (absolute timelock)
before it can be spendable by A.

Anyway, how's that work? If you want to shut the factory down
immediately, it looks like:

* Shut the factory down
* Broadcast StBi, HBi-j-k
* Wait to-self-delay
* Broadcast ComBi, HBi-j-s, HBi-j-p
* Done!

If you were cheating, then:

* Alice steals StBi's first output if i was on old state, and ComBi
cannot be broadcast. Alice publishes the current StAi', ComAi', etc.

* If the HTLC had timed out, Alice claims the output of HBi-j-k before
to-self-delay is finished, so that HBi-j-p cannot be broadcast, then
claims the output of ComBi once both timeouts are complete.

However, what if you don't want to shut the factory down? In that
case:

* Broadcast StBi, HBi-j-k.
* Wait for to_self_delay.
* Spend HBi-j-k to HBi-j-s.
* Wait some more.
* The other guy comes online! Let's recover the channel!
* Propose spending the first output of StBi and the output of HBi-j-s
to a new InB2, but don't sign it.
* Update all the off-chain channel data to a new state i+1 that uses
InB2 instead of InB, and that acknowledges your claim to the HTLC
funds.
* Sign and broadcast InB2
* Continue

If the other guy doesn't come online, you close the factory, immediately
spend F and the first output of StBi via ComBi, and immediately spend
HBi-j-s and the HTLC output of ComBi to claim your funds.

While this is described as an optimisation focussed on improving channels
within factories; it seems to me that the reduction in state compared to
the "tunable penalties" approach in step 1 makes this a strict improvement
in general.

Anyway, combining this step and the previous gives us an idea how to do
both factories and HTLCs. I believe that would look like:

Factory funding output -- multisig of A..Z
Factory In{A..Z}

Factory Trigger, spends the funding output
Factory St{A..Z}i spends In{A..Z}
Factory Mold{A..Z}i spends St{A..Z}i and various Trigger outputs
Factory Com_i spends the other Trigger outputs; its outputs are the
channels in the factory.

Channel F_x - an output of the Factory Com_i
Channel InA, InB
Channel StAi, StBi -- spends InA/InB
Channel ComAi, ComBi -- spends F_x and the first output of StA/StB
Channel H{A,B}i_j_{k,s,p} -- success path funds for active HTLCs

So to update the channel state, the channel participants need:

3*k HTLC transactions (only 1 pre-signed)
2 commitment transactions (both pre-signed)
2 St transactions (neither pre-signed)

Every time the factory updates, every channel state must also update (as
the channel funding outputs will change txid).

Every participant needs 1+c "In" confirmed utxos available -- one for
the factory itself, and one for each channel they're involved in.

Every participant needs to monitor P+c+1 outputs on chain -- the factory
Funding output (which may be spent by the Trigger tx), the P
St{A..Z}i outputs, and their counterparty's InX output for each channel
they're participating in.

That's getting pretttty complicated, so I'm not confident I've got it
all in my head correctly, but I think it still works.

I'm skipping over the watchtower-freedom/casual user section here. cf
https://bitcoinops.org/en/newsletters/2022/10/12/#ln-with-long-timeouts-proposal

Step 4: Resizing Lightning Channels Off-Chain / Hierarchial Channels
https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-March/003886.html
https://github.com/JohnLaw2/ln-hierarchical-channels
https://bitcoinops.org/en/newsletters/2023/03/29/#preventing-stranded-capital-with-multiparty-channels-and-channel-factories

Hey, we made it to this thread!

I'm not entirely sure of the novelty in this proposal; once you have
channels in factories, lots of magic is possible, but it's all very
complex. I believe the particular proposal here is something like:

- Instead of just having Alice/Bob/Carol/etc as identities in
lightning, let them "pair" up, so that AliceBob is considered a node,
and CarolDave is also a node.

- So we have a utxo where AliceBob has a channel with CarolDave, and
another where CarolDave has a channel with Elizabeth, eg.

- But actually the AliceBob/CarolDave utxo is a factory; and there's
an internal channel between Alice and Bob, and another between Carol
and Dave

- Now, because we describe AliceBob and CarolDave as a channel, that
means funds can move between AliceBob and CarolDave; but that is
equivalent to saying the overall capacity of the internal Alice/Bob
channel is actually decreasing without any on-chain activity! Neat!

But... that was always the point of channel factories? And the specific
structure of four participants split into a single pair of channels
doesn't seem particularly compelling? I don't know, I feel like I'm
missing something here. Or maybe it's just the first three steps were
amazing, so merely interesting seems pedestrian by comparison?

Hmm, looking at Harding's email, I see:

> **Liquidity multiplexing:** Alice, Bob, Carol, and Dan each rightfully
> own some portion of a UTXO. Alice and Bob expect to always be
> available; Carol and Dan may sometimes be unavailable. The proposal
> allows Carol and Dan to spend/receive in combination with Alice and
> Bob, but also ensures Alice and Bob can spend back and forth the
> entirety their portions of the UTXO even if Carol, Dan, or both of
> them are unavailable.

I guess I'm not entirely enthusiastic about that because in that case
Alice can only send funds to Carol when Dan (and whoever else is involved
in the factory) eventually come online to signoff on the factory state
update. That's still useful for (slow) offchain channel reallocations,
but it doesn't seem reliable/fast enough for a payment.

For the case where all factory participants are reliably online (perhaps
with some exceptions) I guess I could see that making sense? Then you're
generally just treating it as a 4-party channel of A/B/C/D with everyone
able to easily forward to anyone; but when Alice is offline for system
maintenance for an hour every week, it automatically degrades to just
having the Carol/Dave channel operational, with no other problems.

fin

Cheers,
aj

📅 Original date posted:2023-01-04 🗒️ Summary of this ...

2023-06-09T15:12:26+02:00

In reply to nevent1q…2ne3
_________________________

📅 Original date posted:2023-01-04
🗒️ Summary of this message: A proposal for using a covenant to establish a channel without an expiry date, allowing it to be a first-class citizen among channels.
📝 Original message:
On Wed, Jan 04, 2023 at 01:06:36PM +1100, Lloyd Fournier wrote:
> The advantage of using a covenant
> is that the channel would not have an expiry date and therefore be a first
> class citizen among channels.

I think the approach here would be:

* receive funds on the in-potentiam address with 8000 block CSV
* LSP tracks immediately
* user's wallet wakes up, LSP reports address to user, user signs
a funding tx to establish the channel, and the state 0 close tx
* LSP considers it immediately active
* LSP broadcasts the tx, targeting confirmation within 3 days
* if the funding tx confirms promptly, you just have an ordinary channel
* after 800 blocks, if the tx hasn't confirmed, LSP fee bumps or
closes the channel (relying on the high-feerate unilateral close
tx to do the fee bumping)

ie:

day 0: someone -> in-potentiam address (payment made on-chain, confirmed)

day 7: in-potentiam -> funding (wallet wakes up, tx signed and broadcast,
not necessarily confirmed, channel active)

day 12: in-potentiam -> funding (confirmed)

day 9999: funding -> unilateral/cooperative close

or:

day 0: someone -> in-potentiam address (payment made on-chain, confirmed)

day 14: LSP forgets about in-potentiam utxo as its expiry is only 1000
blocks away

day 420: in-potentiam -> wherever (payment made on-chain by user)

So while the tx introspection approach you advocate *would* allow the
setup phase to skip the "expiry on day 14" restriction, I think the
*bigger* benefit is that you also wouldn't need the on-chain "in-potentiam
-> funding" transaction, but could instead just leave the in-potentiam
tx on chain indefinitely, until it was time to close the channel (which,
if it was a cooperative close, could just be a musig key path spend).

Either approach probably implies that you either have multiple channels
with your LSP (one for each in-potentiam payment you receive), or
that your single channel with your LSP is backed by multiple UTXOs
(maybe you choose an order for them, so that Alice owns 100% of the
balance in utxos 1..(k-1) and Bob owns 100% of the balance in utxos
(k+1)..n?). Otherwise you'd need an on-chain tx anyway to splice the new
funds into your existing channel; and that seems both annoying of itself,
and probably bad for privacy.

Cheers,
aj

📅 Original date posted:2023-04-03 📝 Original message: On ...

2023-06-09T15:08:25+02:00

In reply to nevent1q…sxxd
_________________________

📅 Original date posted:2023-04-03
📝 Original message:
On Sat, Mar 18, 2023 at 12:41:00AM +0000, jlspc via Lightning-dev wrote:
> TL;DR

Even with Harding's optech write ups, and the optech space, I barely
follow all this, so I'm going to try explaining it too as a way of
understanding it myself; hopefully maybe that helps someone. Corrections
welcome, obviously!

I think understanding all this requires going through each of the four
steps.

Step 1: Tunable penalties;
https://github.com/JohnLaw2/ln-tunable-penalties
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-October/003732.html

This is a clever constructions that lets you do a 2-party lightning
channel with existing opcodes where cheating doesn't result in you
losing all your funds (or, in fact, any of your in-channel funds). It
also retains the ability to do layered commit transactions, that is you can
immediately commit to claiming an HTLC or that it's already timed out,
even while you're waiting for the to_self_delay to expire to ensure
you're not cheating.

The way that it works is by separating the flow of channels funds, from
the control flow. So instead of managing the channel via a single utxo,
we instead manage it via 3 utxos: F (the channel funds), InA (control
flow for a unilateral close by A), InB (control flow for a unilateral
close by B).

For each update to a new state "i", which has "k" HTLCs, we create 4 primary txs, and 8k HTLC claims.

StAi which spends InA, and has k+1 outputs. The first output is used
for controlling broadcast of the commitment tx, the remaining k are for
controlling the resolution of each HTLC.

ComAi is the commitment for the state. It spends the funding output
F, and the first output of StAi. In order to spend StAi, it requires
a to_self_delay (and signature by A), giving B time to object that i
is a revoked state. If B does object, he is able to immediately spend
the first output of StAi directly using the revocation information,
and these funds form the penalty. It has k+2 outputs, one for the
balance of each participant, and one for each HTLC.

For each of the k HTLCs, we construct two success and two timeout
transactions: (HAi-j-s, HAi-j-p); (HAi-j-t, HAi-j-r). HAi-j-s and
HAi-j-t both spend the jth output of StAi, conditional either on a
preimage reveal or a timeout respectively; HAi-j-p and HAi-j-r spend
the output of HAi-j-s and HAi-j-t respectively, as well as the output
of ComAi. (s=success commitment, t=timeout commitment, p=payment on
success, r=refund)

And Bob has similar versions of all of these.

So if Alice is honest, the process is:

* Alice publishes StAi
* Alice publishes HAi-j-{s,t} for any HTLCs she is able to resolve
immediately; as does Bob.
* Alice waits for to_self_delay to complete
* Alice publishes ComAi, and any HAi-j-{r,p} transactions she is able
to, and if desired consolidates her funds.
* As any remaining HTLCs resolve, those are also claimed.
* Bob's InB output is available to do whatever he wants with.

If Alice is dishonest, the process is:

* Alice publishes StAi, and perhaps publishes some HAi-j-{s,t}
transactions.
* Bob spends the first output of StAi unilaterally claiming the
* penalty, meaning ComAi can now never be confirmed.
* Bob publishes StBi', and continues with the honest protocol.

Bob only needs the usual O(log(n)) state in order to be able to
reconstruct the key to spend the first output of revoked StAi txs.
Because that prevents the corresponding ComAi from ever being published,
no revoked HTLC-related state can make it on chain in any way that Bob
needs to care about.

If both Alice and Bob are dishonest (Alice tries to cheat, but Bob
restored from an old backup and also publishes a revoked state) then
both the StAi and StBi' may have their first output claimed by the other
party, in which case the channels funds are lost (unless Alice and Bob
manage to agree to a cooperative close somehow, even after all the
attempts to cheat each other).

While 4+8k transactions per state is a lot, I think you only actually
need 2+4k signatures in advance (StAi and HAi-j-{s,t} only need to be
signed when they're broadcast). Perhaps using ANYPREVOUT would let you
reduce the number of HTLC states?

Step 2: Efficient Factories for Lightning Channels
https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-January/003827.html
https://github.com/JohnLaw2/ln-efficient-factories

This generalizes the tunable penalties setup for more than two
participants.

The first part of this is a straightforward generalisation, and
doesn't cover HTLCs. Where we had 2(2+4k) transactions previously, we
presumably would now have P(2+4k) transactions, where P is the number
of participants.

The second part of this aims to avoid that factor P. It does this by
introducing Trigger and Mold transactions.

To do this, we first establish the number of states that the factory
will support; perhaps 2**40. In that case, the trigger transaction will
spend the funding tx, and have 40+1 outputs. All of them will require a
P-of-P signature to be spend, with the first also requiring a relative
timelock of 3*to_self_delay and containing the channel funds, while the
rest contain dust-ish amounts.

For any given state i, we represent i as a binary number, and the
commitment tx Com_i will spend the outputs corresponding to "0" in
the binary number, as well as the first output containing the channel
funds.

We will also have St{A..Z}_i transactions, spending In{A..Z} as
previously. The sole output of StAi (etc) will be spent either by any
other participant via a revoked pubkey, or else by the Mold{A..Z}_i
transaction. The Mold{A..Z}_i transaction will also spend the remaining
outputs of the Trigger transaction that were not spent by Com_i.

In the honest scenario, this looks like:

* Alice publishes Trigger
* Alice publishes StA_i
* Alice waits to_self_delay
* Alice publishes MoldA_i
* Alice waits an additional 2*to_self_delay
* Alice publishes Com_i
* Alice and everyone else claims their funds

There are various dishonest scenarios available:

* If Alice publishes StA_i before publishing the Trigger, someone else
publishes the Trigger.

* If Alice doesn't publish StA_i quickly, Bob publishes StB_i
and continues. If multiple St{A..Z}_i's are published, whoever does
not publish the Mold transaction simply reclaims their funds by the
"revocation" path.

* If Alice publishes an old StA_i, Bob claims the funds using the
revoked key, penalising A, and then publishes the correct StB_i,
and continues.

* If Alice does not publish MoldA_i, Bob can publish StB_i and MoldB_i.

* Once MoldB_i is confirmed, someone could attempt to broadcast an
outdated Com_i' where i' < i. In that case, the outputs corresponding
to all the 1's in the binary representation of i are already spent
(by MoldB_i), but for any i' < i, the i' necessarily has a 0 somewhere
where i had a 1 (otherwise i' >= i), so Com_i' would be double spending
an input already spent by MoldB_i.

In this case, you need to track P+1 outputs (F+InA..Z), you need
O(P*log(N)) state, and the onchain impact of a unilateral close is ideally
4 transactions (Trigger, StAi, MoldAi, Comi) with size O(log(MaxN)),
but maybe be up to 2*P+2 transactions (Trigger, St{A..Z}i, MoldAi,
refund{B..Z}i, Comi).

Note that this doesn't consider HTLCs at all.

Step 3: Factory Optimized protocols for Lighting
https://github.com/JohnLaw2/ln-factory-optimized
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-December/003782.html
https://bitcoinops.org/en/newsletters/2022/12/14/#factory-optimized-ln-protocol-proposal

Perhaps this should have been step 2, whoopsie. Anyway, this optimises
the construction in step 1 for channels included in factories; mostly
to deal with the fact that closing a factory is tedious and can take a
while. I'm ignoring the Partial-Factory-Optimized step -- it's barely
different to the Tunable Penalty mechanism. The Fully Factory Optimized
protocol is more interesting.

The main idea here is this: if a channel in a factory goes defunct while
an HTLC is pending, we'd like to be able to guarantee we've resolved
the HTLC to our satisfaction while deferring the decision of whether
to shutdown the entire factory in order to close the channel, just
in case our channel partner eventually comes back, and we can resolve
everything properly.

The way we do that is twofold: first, we set things up so that the default
resolution of an HTLC is a refund. That immediately does away with half
of our HTLC transactions, because now we only need the success/payment
paths, not the timeout/refund ones. Second, we require whoever's
going to receive the payment to publish their StXi transaction -- that
avoids us having to do P*k success/payment paths, now we only need 1*k
success/payment paths. Unfortunately, we do introduce a new "kickoff"
transaction to make it a three transaction kickoff/success/payment path,
rather than just two transactions.

In this case your transactions are:

F - the funding output, only available once the factory is closed
InB - as before
StBi - your state commitment, one output that will be spent by ComBi,
k outputs for each pending HTLC paying to B in state i.
HBi-j-k - the kickoff transaction for HTLC "j" paying to B, spends
the appropriate output of StBi, conditional on revealing the
HTLC preimage and B's signature. Spendable either by B after
to-self-delay, or by A after the HTLC's expiry plus
to-self-delay
HBi-j-s - the success transaction, spendable by B
HBi-j-p - the payment transaction, spends HBi-j-s and the HTLC output
from ComB_i
HAi-j-p - the payment transaction, spends HBi-j-s and the HTLC output
from ComA_i

I think there's an error in the paper here; it says as well as being
spendable by H{A,B}i-j-p as above, the HTLC output in ComA_i should be
spendable by A after to-self-delay. I believe it should require both
to-self-delay (relative timelock) and the HTLC expiry (absolute timelock)
before it can be spendable by A.

Anyway, how's that work? If you want to shut the factory down
immediately, it looks like:

* Shut the factory down
* Broadcast StBi, HBi-j-k
* Wait to-self-delay
* Broadcast ComBi, HBi-j-s, HBi-j-p
* Done!

If you were cheating, then:

* Alice steals StBi's first output if i was on old state, and ComBi
cannot be broadcast. Alice publishes the current StAi', ComAi', etc.

* If the HTLC had timed out, Alice claims the output of HBi-j-k before
to-self-delay is finished, so that HBi-j-p cannot be broadcast, then
claims the output of ComBi once both timeouts are complete.

However, what if you don't want to shut the factory down? In that
case:

* Broadcast StBi, HBi-j-k.
* Wait for to_self_delay.
* Spend HBi-j-k to HBi-j-s.
* Wait some more.
* The other guy comes online! Let's recover the channel!
* Propose spending the first output of StBi and the output of HBi-j-s
to a new InB2, but don't sign it.
* Update all the off-chain channel data to a new state i+1 that uses
InB2 instead of InB, and that acknowledges your claim to the HTLC
funds.
* Sign and broadcast InB2
* Continue

If the other guy doesn't come online, you close the factory, immediately
spend F and the first output of StBi via ComBi, and immediately spend
HBi-j-s and the HTLC output of ComBi to claim your funds.

While this is described as an optimisation focussed on improving channels
within factories; it seems to me that the reduction in state compared to
the "tunable penalties" approach in step 1 makes this a strict improvement
in general.

Anyway, combining this step and the previous gives us an idea how to do
both factories and HTLCs. I believe that would look like:

Factory funding output -- multisig of A..Z
Factory In{A..Z}

Factory Trigger, spends the funding output
Factory St{A..Z}i spends In{A..Z}
Factory Mold{A..Z}i spends St{A..Z}i and various Trigger outputs
Factory Com_i spends the other Trigger outputs; its outputs are the
channels in the factory.

Channel F_x - an output of the Factory Com_i
Channel InA, InB
Channel StAi, StBi -- spends InA/InB
Channel ComAi, ComBi -- spends F_x and the first output of StA/StB
Channel H{A,B}i_j_{k,s,p} -- success path funds for active HTLCs

So to update the channel state, the channel participants need:

3*k HTLC transactions (only 1 pre-signed)
2 commitment transactions (both pre-signed)
2 St transactions (neither pre-signed)

Every time the factory updates, every channel state must also update (as
the channel funding outputs will change txid).

Every participant needs 1+c "In" confirmed utxos available -- one for
the factory itself, and one for each channel they're involved in.

Every participant needs to monitor P+c+1 outputs on chain -- the factory
Funding output (which may be spent by the Trigger tx), the P
St{A..Z}i outputs, and their counterparty's InX output for each channel
they're participating in.

That's getting pretttty complicated, so I'm not confident I've got it
all in my head correctly, but I think it still works.

I'm skipping over the watchtower-freedom/casual user section here. cf
https://bitcoinops.org/en/newsletters/2022/10/12/#ln-with-long-timeouts-proposal

Step 4: Resizing Lightning Channels Off-Chain / Hierarchial Channels
https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-March/003886.html
https://github.com/JohnLaw2/ln-hierarchical-channels
https://bitcoinops.org/en/newsletters/2023/03/29/#preventing-stranded-capital-with-multiparty-channels-and-channel-factories

Hey, we made it to this thread!

I'm not entirely sure of the novelty in this proposal; once you have
channels in factories, lots of magic is possible, but it's all very
complex. I believe the particular proposal here is something like:

- Instead of just having Alice/Bob/Carol/etc as identities in
lightning, let them "pair" up, so that AliceBob is considered a node,
and CarolDave is also a node.

- So we have a utxo where AliceBob has a channel with CarolDave, and
another where CarolDave has a channel with Elizabeth, eg.

- But actually the AliceBob/CarolDave utxo is a factory; and there's
an internal channel between Alice and Bob, and another between Carol
and Dave

- Now, because we describe AliceBob and CarolDave as a channel, that
means funds can move between AliceBob and CarolDave; but that is
equivalent to saying the overall capacity of the internal Alice/Bob
channel is actually decreasing without any on-chain activity! Neat!

But... that was always the point of channel factories? And the specific
structure of four participants split into a single pair of channels
doesn't seem particularly compelling? I don't know, I feel like I'm
missing something here. Or maybe it's just the first three steps were
amazing, so merely interesting seems pedestrian by comparison?

Hmm, looking at Harding's email, I see:

> **Liquidity multiplexing:** Alice, Bob, Carol, and Dan each rightfully
> own some portion of a UTXO. Alice and Bob expect to always be
> available; Carol and Dan may sometimes be unavailable. The proposal
> allows Carol and Dan to spend/receive in combination with Alice and
> Bob, but also ensures Alice and Bob can spend back and forth the
> entirety their portions of the UTXO even if Carol, Dan, or both of
> them are unavailable.

I guess I'm not entirely enthusiastic about that because in that case
Alice can only send funds to Carol when Dan (and whoever else is involved
in the factory) eventually come online to signoff on the factory state
update. That's still useful for (slow) offchain channel reallocations,
but it doesn't seem reliable/fast enough for a payment.

For the case where all factory participants are reliably online (perhaps
with some exceptions) I guess I could see that making sense? Then you're
generally just treating it as a 4-party channel of A/B/C/D with everyone
able to easily forward to anyone; but when Alice is offline for system
maintenance for an hour every week, it automatically degrades to just
having the Carol/Dave channel operational, with no other problems.

fin

Cheers,
aj

📅 Original date posted:2023-01-30 📝 Original message: After ...

2023-06-09T15:07:57+02:00

In reply to nevent1q…wckj
_________________________

📅 Original date posted:2023-01-30
📝 Original message:
After listening to the optech space on the topic, thought it might be
worth having a second go at explaining the idea...

Alice is trying to pay Bob. Alice has an LSP, Louise. Bob has an LSP
Larry. Louise and Larry are online 24/7 but don't have access to Alice
and Bob's private keys. We want the payment flow to be something like:

1) Larry gets some setup info from Bob, Bob goes offline.

* Alice hears about Bob's address, and decides to pay Bob $50.
2) Alice coordinates a unique invoice id with Larry, which we'll call S.
3) Alice tells Louise that she's trying to pay Bob $50 for invoice S.
* Louise registers with Larry to be told when Bob is online.
* Alice goes offline.

* Bob goes online.
* Larry tells Louise that Bob is online.
4) Louise sends the payment to Bob conditional on S.
5) Bob accepts the payment.
* Louise claims the $50 from Alice and closes out the transaction.
6) Alice receives a receipt from Bob.

The goal of a receipt is that if two people want to pay Bob $50, they'll
be able to guarantee that (a) Bob was paid, rather than someone else; (b)
that the receipts are different (so Bob received $100 total, rather than
$50 going somewhere else and one of them just got a photocopied receipt);
and (c) after the fact they can prove that the receipt was theirs,
not someone else's. (a) and (b) prevent the funds getting misdirected;
(c) potentially allows you to use the receipt as evidence to a third
party if you paid for something in advance, then didn't receive it.

To get all those things, what we want is really more like a signature,
than just a hash/preimage. But PTLC preimages and schnorr signatures
aren't much different: with a PTLC preimage, you pay to point S and then
receive back the preimage s, where s*G = S. Meanwhile schnorr signatures
are made up of a number (s) and a point (R), which satisfy the equation:

s*G = R + H(R,P,m)*P

But, if you're willing to squint a bit, you can just wrap the whole
right side of the equation up as "S", and treat it as a PTLC.

(notation: I use capital letters to represent points, and lower case
letters to represent numbers; so if A is a point, a is it's discrete log,
and a*G = A)

To calculate S, you need to know three things: R, P and m -- P is just
the signer's public key, m is the message being signed, but "R" is the
public "nonce" part of the signature, that has to be chosen by the signer
(otherwise whoever does choose it can probably arrange to discover the
signer's private key after a signature or two).

So in that case, the protocol looks like:

Alice proposes that Bob signs a message, eg
m = "Alice paid me $50 -- Bob"
(perhaps this can be some standard nostr message, eg)
Bob chooses an R for this signature, and tells Alice what R is
Alice calculates "S"
Alice pays Bob $50 via a PTLC conditional on S
If Bob accepts the $50, Alice receives the preimage of S, ie s
Alice combines (R,s) and that is a Bob's signature on her message

Having Bob be offline with Alice only able to talk to his
not-fully-trusted representative Larry complicates things. Bob now can't
just choose a brand new R after already knowing Alice's message m, and
that introduces cryptographic attacks [0], where if Alice can request
nonces for many messages she may be able to find a lucky combination
of messages/nonces where she can combine the signatures Bob ends up
generating to steal Bob's private key.

[0] https://medium.com/blockstream/insecure-shortcuts-in-musig-2ad0d38a97da

I *think* those attacks can be avoided by using the same musig2 approach
to generating nonces:

Bob prepares a nonce *pair* R1, R2
Alice chooses the message m
The nonce for the message m is calculated as H(R1,R2,m)*R1 + R2

Note that this doesn't allow you to safely reuse nonces -- if you have
three messages signed with the same R1/R2 pair, the schnorr signing
equation (s = r + H(R,P,m)*p) over each of the three messages gives you
three equations with just three unknowns (r1, r2, and the secret key
p), which you can use regular maths to solve, no fancy attacks needed.
(Presumably if you just reuse a pair twice you open yourself back up to
a Wagner attack)

So that adds up to:

1) Bob shares with Larry a bunch of (R1,R2) points that will form the
basis of his signature nonces. They can be constructed via a
(hardened) HD scheme so that Bob can easily regenerate them just
from an index, eg.

2) Alice obtains a unique (R1,R2) pair from Larry
Alice determines the message she wants Bob to sign (presumably Bob
provides a standard template, and Alice fills in her name and perhaps
what she's paying for) -- this is "m".
Alice calculates R from R1,R2,m; and S from R,P,m

3) Alice passes "m" and "S" onto Louise and starts the payment, locking
up her funds

4) Louise passes "m", "R1", "R2" onto Bob once he's online and sends
the payment to Bob.

5) Bob checks that R1/R2 were what he generated and haven't already
been used; Bob checks that "m" is something he's willing to sign;
Bob calculates s and S, and accepts the payment for S, provided it's
the correct amount as specified in "m", by revealing s.

6) Alice already calculated R and now receives s from Louise when
Louise claims her funds, and (R,s) is a BIP340 signature of m by
Bob, satisfying s*G = R + H(R,P,m)*P, and that signature serves as
her payment receipt from Bob.

Cheers,
aj

On Thu, Jan 26, 2023 at 11:04:12AM +1000, Anthony Towns wrote:
> On Tue, Jan 10, 2023 at 07:41:09PM +0000, vwallace via Lightning-dev wrote:
> > The open research question relates to how the sender will get an invoice from the receiver, given that they are offline at sending-time.
>
> Assuming the overall process is:
>
> * Alice sends a payment to Bob, who has provided a reusable address
> AddrBob
> * Bob is offline at the time the payment is sent, but his semi-trusted
> LSP Larry is online
> * Alice is willing/able to do bidirectional communication with Larry
> * The payment does not complete until Bob is online (at which point
> Alice may be offline)
>
> I think in this case you want to aim for the receipt to be a BIP340
> signature of the message "Alice has paid me $50 -- signed Bob".
>
> Given Bob's public signature nonce, R, Alice (and Larry) can calculate
> S = R + H(R,P,m)*P (m is the receipt message, P is Bob's public key),
> and then Alice can send a PTLC conditional on revealing the log of S, ie
> s where s*G=S; and at that point (s, R) is a valid signature by Bob of a
> message confirming payment to Bob, which then serves as the final receipt.
>
> However for this to work, Alice needs to discover "R" while Bob is
> offline. I think this is only doable if Bob pre-generates a set of
> nonces and shares the public part with Larry, who can then share them
> with potential payers. I think to avoid attacks via Wagner's algorithm,
> you probably need to do a similar setup as musig2 does, ie share (R1,R2)
> pairs, and calculate R = H(P,R1,R2,m)*R1+R2.
>
> So a setup like:
>
> Alice gets AddrBob. Decodes Bob's pubkey, Larry's pubkey, and the
> route to Larry.
>
> Alice -> Larry: "Hi, I want to send Bob $50, and get a receipt"
> Larry -> Alice: "The nonce for that will be R"
> Alice: calculates m = "Hash("Alice paid Bob $50"), S = R+H(R,P,m)*P
> Alice -> Larry(for Bob): PTLC[$50, S]
>
> Larry -> Bob: PTLC[$50, S]
> Alice wants to pay you $50, using nonce pair #12345
> Bob: verifies nonce #12345 has not been previously used, calculates R,
> calculates m, calculates s, and checks that s*G = S, checks
> there's a $50 PTLC conditional on S waiting for confirmation.
> Bob -> Alice: claims $50 from PTLC by revealing s
>
> Alice: receives s; (R,s) serves as Bob's signature confirming payment
>
> seems plausible?
>
> Every "S" here commits to a value chosen by the sender (ie, their
> "identity"), so there's no way for Larry to get two different payers
> to use the same S. Using the same nonce twice will just mean Bob has to
> reject the payment (and find a new LSP).
>
> It may make sense to require Alice to make a micropayment to Larry in
> order to claim a nonce. You'd want a standard template for "m" so that
> it's easy to generate and parse consistently, of course.
>
> I think you could even have separate LSPs if you wanted: one to issue
> nonces while you're offline, and the other to actually hold onto incoming
> PTLCs while you're offline.
>
> FWIW, some previous discussion, which didn't focus on offline recipients:
>
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/001034.html
>
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001490.html

----- End forwarded message -----

📅 Original date posted:2022-12-13 📝 Original message: On ...

2023-06-09T15:07:42+02:00

In reply to nevent1q…d43s
_________________________

📅 Original date posted:2022-12-13
📝 Original message:
On Mon, Dec 12, 2022 at 08:38:43PM -0500, Antoine Riard wrote:
> The attack purpose is to delay the confirmation of the final settlement
> transaction S, to double-spend a HTLC forwarded by a routing hop.
> The cltv_expiry_delta requested by Ned is equal to N=144.

I believe what you're suggesting here is:

Mallory has two channels with Bob, M1 and M2. Both have a to_self_delay
of 144 blocks. In that case cltv_expiry_delay should include some slack,
I'm going to assume it's 154 blocks in total.

Mallory forwards a large payment, M1->Bob->M2.

Mallory claims the funds on M2 just prior to the timeout, but
goes offline on M1.

Bob chose the timeout for M2 via cltv_expiry_delay, so now has 154
blocks before the CLTV on the M1->Bob payment expires.

In this scenario, under the two-party eltoo scheme, Bob should:

1) immediately broadcast the most recent UB.n state for M1/Bob,
aiming for this to be confirmed within 5 blocks

2) wait 144 blocks for the relative timelock to expire

3) broadcast SB.n to finalise the funds, and immediately claim the
large HTLC. providing this confirms within 5 blocks, it will confirm
before the HTLC timelock expires, and Mallory will have been unable
to claim the funds.

The only transactions Mallory could broadcast are:

prior to (1): UA.k (k <= n) -- However this allows Bob to immediately
broadcast one of either CA.n or RA.n, and will then have ~150 blocks
to claim the HTLC before its timeout

during (2): CA.n -- Again, this allows Bob to claim the HTLC
immediately, prior to its timeout

The only delaying attack with repeated transactions comes if Bob
broadcasts an old state UB.k (k < n), in which case Mallory can broadcast
(n-k) WA.i watchtower transactions prior to finalising the state. However
if Bob *only* has old state, Mallory can simply broadcast WA.n, at which
point Bob can do nothing, as (by assumption) he doesn't have access
to current state and thus doesn't have SB.n to broadcast it.

> The attack scenario works in the following way: Malicia updates the Eltoo
> channel N time, getting the possession of N update transactions. At block
> A, she breaks the channel and confirms the update transaction 0 by
> attaching a feerate equal to or superior to top mempool block space + 1
> sat. At each new block, she iterates by confirming the next update
> transaction, i.e update transaction 1 at block A+1, update transaction
> transaction 2 at block A+2, update transaction 3 at block A+3, ...

I think traditional eltoo envisages being able to spend update transaction
1 immediately, without having to wait for the next block. This might
not be compatible with the version 3 relay rules that are being thought
about, though, and presumably would hit ancestor limits.

I think a simple way to avoid that problem would be for eltoo nodes
to have a priority tx relay network -- if they see a channel close to
state N, always replace any txs closing to an earlier state K<N, and
always quickly relay that close to all other peers. There's no reason
to assume the bad guys have the best access to the network when we can
write code so that the honest participants have it instead.

> From Ned's viewpoint, there is limited rationality of the network mempools,
> as such each punishment transaction R, as it's confirmation could have been
> delay due to "honest" slow propagation on the network is likely to be
> pre-signed with top mempool block space feerate, but not more to save on
> fees. Therefore, transaction RN.0 should fail to punish update transaction
> 0 as it's double-spent by update transaction 1, transaction RN.1 should
> fail to punish update transaction 1 as it's double-spent by update
> transaction 2, transaction RN.2 should fail to punish update transaction 2
> as it's double-spent by update transaction 3...

In the two-party scheme, the only transaction Mallory can broadcast
after sending UA.k and having it confirmed on chain is SA.k, and that
only after a 144 block relative timelock. UA.(k+1) etc only spend the
funding output, but that has already been spent by UA.k.

Cheers,
aj

📅 Original date posted:2022-09-26 📝 Original message: On ...

2023-06-09T15:06:53+02:00

In reply to nevent1q…j4ss
_________________________

📅 Original date posted:2022-09-26
📝 Original message:
On Mon, Sep 26, 2022 at 01:26:57AM +0000, ZmnSCPxj via Lightning-dev wrote:
> > > * you're providing a way of throttling payment traffic independent of
> > > fees -- since fees are competitive, they can have discontinuous effects
> > > where a small change to fee can cause a large change to traffic volume;
> > > but this seems like it should mostly have a proportional response,
> > > with a small decrease in htlc_max_msat resulting in a small decrease in
> > > payment volume, and conversely. Much better for stability/optimisation!

> > This may depend on what gets popular for sender algorithms.
> > Senders may quantize their payments, i.e. select a "standard" value and divide all payments into multipath sub-payments of this value.

I don't think that's really the case.

One option is that you quantize based on the individual payment -- you
want to send $100, great, your software splits it into 50x $2 payments,
and routes them. But that doesn't have an all or nothing effect: if you
reject anything over $1.99, then instead of routing 1/50th of payments
up to $100, you're routing 1/50th of payments up to $99.50.

The other approach is to quantize by some fixed value no matter what the
payment is (maybe for better privacy?). I don't think that's a good idea
in the first place -- it trades off maybe a small win for your privacy
for using up everyone else's HTLC slots -- but if it is, it'll need to be
quite a small value so as not to force you to round up the overall payment
too much, and to allow small payments in the first place. But in that case
most channels will have their html_max_msat well above that value anyway.

> Basically, the intuition "small decrease in `htlc_max_msat` == small decrease in payment volume" inherently assumes that HTLC sizes have a flat distribution across all possible sizes.

The intuition is really the other way around: if you want a stable,
decentralised network, then you need the driving decision on routing to
be something other than just "who's cheaper by 0.0001%" -- otherwise
everyone just chooses the same route at all times (which becomes
centralised towards the single provider who can best monetise forwarding
via something other than fees), and probably that route quickly becomes
unusable due to being drained (which isn't stable).

(But of course, I hadn't had any ideas on what such a thing could be,
otherwise I'd have suggested something like this earlier!)

So, to extend the intuition further: that means that if using
htlc_max_msat as a valve/throttle can fill that role, then that's a reason
to not do weird things like force every HTLC to be 2**n msats or similar.

If there is a conflict, far better to have a lightning network that's
decentralised, stable, and doesn't require node operators to spy on
transactions to pay for their servers.

It's not quite as bad as you suggest though -- the payment sizes
don't need to have a flat distribution, they only need to have a
smooth/continuous distribution.

> * Coffee or other popular everyday product may settle on a standard price, which again implies a spike around that standard price.

Imagine the price of coffee is $5, and you find three potential paths
to pay for that coffee:

Z -> A -> X
Z -> B -> C -> X
Z -> B -> D -> X

(I think you choose both the fee and max_msat for Z->A and Z->B hops,
so we'll assume they're 0%/infinite, respectively)

Suppose the fee on AX is 0.01%, and the total fee for BCX is 0.02%
and the total fee for BDX is 0.1%.

If AX's max_msat is $5, they'll get the entire transaction. If it's
$4.99, you might instead optimise fees by doing AMP: send $4.99 through
AX and $0.01 through BCX, for a total fee rate of 0.01002%.

If everyone quantizes at 10c (500sat?) instead of 1c (50sat?) or lower
then that just means instead of getting maybe a 0.2% reduction in payment
flow, AX gets a 2% reduction in payment flow.

Likewise, if AX's max_msat is $1, BCX's max_msat is $3, and BDX's max_msat
is $20, then you split your payment up as $1/$3/$1 and pay a fee of
0.034%. Meanwhile AX's payment flow has been reduced by perhaps 80%
(if everyone's buying $5 coffees), and BCX's by perhaps 25% (from $4 to
$3), allowing them to maintain balanced channels.

> So the reliability of `htlc_max_msat` as a valve is dependent on market forces, and may be as non-linear as feerates, which *are* the sum total of the market force.

No: without some sort of external throttle, fees have a tendency to be all
or nothing. If there's no metric other than fees, why would I ever choose
to pay 0.02% (let alone 0.1%!) in fees? And if a new path comes along
offering a fee rate of 0.00999% fees, why would I continue paying 0.01%?

Even if everyone does start quantizing their payments -- and does so with
an almost 6 order of magnitude jump from 1msat to 500sats -- you're only
implying traffic bumps of perhaps 2% when tweaking parameters that are
near important thresholds, rather than 100%.

> Feerates on the other hand are always going to be something that senders optimize for, [...]

Sure, but that can't be the end of the story, since it has a clear winner
that everyone immediately agrees upon, and there's no point anyone else
participating in trying to route lightning transactions.

There's plenty of other possible throttling mechanisms: at the very least,
senders can *not* optimise for fees, and instead randomly select routes
within a budget; or you can maintain external "reliability" scores for
nodes and factor those in along with fee rates.

What's novel and interesting about this approach (IMO) is it's one that
the channel operator can use directly (so the person who's meant to know
the private channel state is making the decision that depends on the
private channel state), and that they don't have a particular incentive
to lie about (with random choice, maybe you want to pretend you have many
nodes/channels so you get selected more often; if reliability is factored
in, maybe you're tempted to pretend to be more reliable than you are).

Cheers,
aj

📅 Original date posted:2022-09-24 📝 Original message: On ...

2023-06-09T15:06:49+02:00

In reply to nevent1q…60qv
_________________________

📅 Original date posted:2022-09-24
📝 Original message:
On Fri, Sep 23, 2022 at 03:13:53PM -0500, lisa neigut wrote:
> Some interesting points here. Will try to respond to some of them.
> > pathfinding algorithms which depend on unscalable data collection
> Failed payment attempts are indistinguishable from data collection probing.

Even so, data collection probing is *preferable* -- it can happen out
of band, and doesn't need to cause latency when you're trying to finish
paying for your coffee so you can sit down and get back to doomscrolling.

In general: if you need to know channel capacities to efficiently make
payments, doesn't that fundamentally mean that that information should
be gossipped?

For instance, in a world where everyone's doing rate cards, maybe every
channel is advertising fees at -0.05, +0.01, +0.1, +1.0 bps because that's
just what turns out to be "best". But then when you're trying to find a
route, it becomes critically important to know which channels are at which
capacity quartile. If you're not gossipping that information, then someone
making a payment needs to either probe every plausible path, or subscribe
to an information provider that is regularly probing every channel.

I still think what I wrote in June applies; from [0], what you want
to maintain is a balanced flow over time, not any particular channel
balance -- so collecting less fees at 25% balance than at 75% balance
is generally a false optimisation; and from [1], having fee rate cards
that just depend on time of day/week is probably a much better method of
optimising for what actually matters -- "these are the times my channel
is in high demand in this direction, so fees are high; these are the
times demand is low, so fees are low".

[0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003624.html
[1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003627.html

> I like to think that the introduction of negative fees make channel
> balance data a competitive advantage and will actually cause node
> operators to more closely guard their balances / the balance data
> they've collected about peers, which should hopefully reduce the current
> trend of sharing this information with centralized parties.

Having fees depend on the channel balance makes the data a competitive
advantage to the people trying to use the channel; for the channel owner,
the optimal situation is everyone knows the balance, so that more payments
get routed over the channel (because people don't overestimate the fee
rate). That encourages channel owners to broadcast the information,
not keep it private. If they can't broadcast it, that just creates a
market for centralised information brokers...

Cheers,
aj

📅 Original date posted:2022-06-29 📝 Original message: On ...

2023-06-09T15:06:09+02:00

In reply to nevent1q…sk7t
_________________________

📅 Original date posted:2022-06-29
📝 Original message:
On Sun, Jun 05, 2022 at 02:29:28PM +0000, ZmnSCPxj via Lightning-dev wrote:

Just sharing my thoughts on this.

> Introduction
> ============
> Optimize for reliability+
> uncertainty+fee+drain+uptime...
> .--~~--.
> / \
> / \
> / \
> / \
> / \
> _--' `--_
> Just Just
> optimize optimize
> for for
> low fee low fee

I think ideally you want to optimise for some combination of fee, speed
and reliability (both liklihood of a clean failure that you can retry
and of generating stuck payments). As Matt/Peter suggest in another
thread, maybe for some uses you can accept low speed for low fees,
while in others you'd rather pay more and get near-instant results. I
think drain should just go to fee, and uncertainty/uptime are just ways
of estimating reliability.

It might be reasonable to generate local estimates for speed/reliability
by regularly sending onion messages or designed-to-fail htlcs.

Sorry if that makes me a midwit :)

> Rene Pickhardt also presented the idea of leaking friend-of-a-friend balances, to help payers increase their payment reliability.

I think foaf (as opposed to global) gossip of *fee rates* is a very
interesting approach to trying to give nodes more *current* information,
without flooding the entire network with more traffic than it can
cope with.

> Now we can consider that *every channel is a marketplace*.
> What is being sold is the sats inside the channel.

(Really, the marketplace is a channel pair (the incoming channel and
the outgoing channel), and what's being sold is their relative balance)

> So my concrete proposal is that we can do the same friend-of-a-friend balance leakage proposed by Rene, except we leak it using *existing* mechanisms --- i.e. gossiping a `channel_update` with new feerates adjusted according to the supply on the channel --- rather than having a new message to leak friend-of-a-friend balance directly.

+42

> Because we effectively leak the balance of channels by the feerates on the channel, this totally leaks the balance of channels.

I don't think this is true -- you ideally want to adjust fees not to
maintain a balanced channel (50% on each side), but a balanced *flow*
(1:1 incoming/outgoing payment volume) -- it doesn't really matter if
you get the balanced flow that results in an average of a 50:50, 80:20
or 20:80 ratio of channel balances (at least, it doesn't as long as your
channel capacity is 10 or 100 times the payment size, and your variance
is correspondingly low).

Further, you have two degrees of freedom when setting fee rates: one
is how balanced the flows are, which controls how long your channel can
remain useful, but the other is how *much* flow there is -- if halving
your fee rate doubles the flow rate in sats/hour, then that will still
increase your profit. That also doesn't leak balance information.

> ### Inverting The Filter: Feerate Cards
> Basically, a feerate card is a mapping between a probability-of-success range and a feerate.
> * 00%->25%: -10ppm
> * 26%->50%: 1ppm
> * 51%->75%: 5ppm
> * 76%->100%: 50ppm

Feerate cards don't really make sense to me; "probability of success"
isn't a real measure the payer can use -- naively, if it were, they could
just retry at 1ppm 10 times and get to 95% chances of success. But if
they can afford to retry (background rebalancing?), they might as well
just try at -10ppm, 1ppm, 5ppm, 10ppm (or perhaps with a binary search?),
and see if they're lucky; but if they want a 1s response time, and can't
afford retries, what good is even a 75% chance of success if that's the
individual success rate on each hop of their five hop path?

And if you're not just going by odds of having to retry, then you need to
get some current information about the channel to plug into the formula;
but if you're getting *current* information, why not let that information
be the feerate directly?

> More concretely, we set some high feerate, impose some kind of constant "gravity" that pulls down the feerate over time, then we measure the relative loss of outgoing liquidity to serve as "lift" to the feerate.

If your current fee rate is F (ppm), and your current volume (flow) is V
(sats forwarded per hour), then your profit is FV. If dropping your fee
rate by dF (<0) results in an increase of V by dV (>0), then you want:

(F+dF)(V+dV) > FV
FV + VdF + FdV + dFdV > FV
FdV > -VdF
dV/dF < -V/F (flip the inequality because dF is negative)

(dV/V)/(dF/F) < -1 (fee-elasticity of volume is in the elastic
region)

(<-1 == elastic == flow changes more than the fee does == drop the fee
rate; >-1 == ineleastic == flow changes less than the fee does == raise
the fee rate; =-1 == unit elastic == you've found a locally optimal
fee rate)

You could optimise base fee in the same way, if you set F to be sats/tx
and V to be txs/hour, but then you're trying to optimise two variables
on a 2 dimensional plane, which is harder. So probably better to do
zero base fees and just set it to 0 and ignore it, or use your actual
computation costs -- perhaps about 20msat if you're paying $100USD/month
for your lightning node, a channel update takes 10ms, each forwarded HTLC
accounts for 4 updates, 2 on the incoming channel, 2 on the outgoing,
with no batching, and only 40% of payments are successful, at $20k/BTC.

It's likely more important to have balanced flows than maximally
profitable ones though, as that's what allows you to keep your channel
open. That's probably pretty hard to optimise, since a changed fee on
one channel will affect the volume on ther channels as well.

Relatedly:

> I want to propose that all published nodes support some kind of
> onchain/offchain swap capability.

If you're running a forwarding node, and collecting fees for forwarding,
considered in net your channels won't be balanced: the fees you collect
are all coming in, and there's nothing to compensate for that. Having some
way to send those fees "out" is necessary to keep your channels balanced
and avoid the need to have to close them. Having a swap capability like
this is perhaps a relatively easy way to be able to (automatically)
fix imbalances caused by collecting fees, and thus preserve your older
channels.

Cheers,
aj

📅 Original date posted:2021-12-21 📝 Original message: On ...

2023-06-09T15:04:41+02:00

In reply to nevent1q…v8kk
_________________________

📅 Original date posted:2021-12-21
📝 Original message:
On Tue, Dec 21, 2021 at 04:25:41PM +0100, Bastien TEINTURIER wrote:
> The reason we have "toxic waste" with HTLCs is because we commit to the
> payment_hash directly inside the transaction scripts, so we need to
> remember all the payment_hash we've seen to be able to recreate the
> scripts (and spend the outputs, even if they are revoked).

I think "toxic waste" refers to having old data around that, if used,
could cause you to lose all the funds in your channel -- that's why it's
toxic. This is more just regular landfill :)

> *_anchor: dust, who cares -- might be better if local_anchor used key =
> > revkey
> I don't think we can use revkey,

musig(revkey, remote_key)
--> allows them to spend after you've revealed the secret for revkey
you can never spend because you'll never know the secret for
remote_key

but if you just say:

(revkey)

then you can spend (because you know revkey) immediately (because it's
an anchor output, so intended to be immediately spent) or they can spend
if it's an obsolete commitment and you've revealed the revkey secret.

> this would prevent us from bumping the
> current remote commitment if it appears on-chain (because we don't know
> the private revkey yet if this is the latest commitment). Usually the
> remote peer should bump it, but if they don't, we may want to bump it
> ourselves instead of publishing our own commitment (where our main
> output has a long CSV).

If we're going to bump someone else's commitment, we'll use the
remote_anchor they provided, not the local_anchor, so I think this is
fine (as long as I haven't gotten local/remote confused somewhere along
the way).

Cheers,
aj

📅 Original date posted:2021-12-09 📝 Original message: On ...

2023-06-09T15:04:40+02:00

In reply to nevent1q…kcs7
_________________________

📅 Original date posted:2021-12-09
📝 Original message:
On Thu, Dec 09, 2021 at 12:34:00PM +1100, Lloyd Fournier wrote:
> I wanted to add a theoretical note that you might be aware of. The final
> message "Bob -> Alice: revoke_and_ack" is not strictly necessary. Alice
> does not care about Bob revoking a commit tx that gives her strictly more
> coins.

That's true if Alice is only sending new tx's paying Bob; and Rusty's
examples in the `option_simplified_update` proposal do only include new
HTLCs...

But I think it's intended to cover *all* update messages, and if Alice is
also including any `update_fulfill_htlc` or `update_fail_htlc` messages in
the commitment, she's potentially gaining funds, both for the amount of
fees she saves by avoiding extra transactions, but for the fulfill case,
potentially also because she doesn't need to worry about the fulfilled
htlc reaching its timeout.

Actually, as an alternative to the `option_simplified_update` approach,
has anyone considered an approach more like this:

* each node can unilaterally send various messages that always update
the state, eg:
+ new htlc/ptlc paying the other node (update_add_htlc)
+ secret reveal of htlc/ptlc paying self (update_fulfil_htlc)
+ rejection of htlc/ptlc paying self (update_fail_htlc)
+ timeout of htlc/ptlc paying the other node (not currently allowed?)
+ update the channel fee rate (update_fee)

* continue to allow these to occur at any time, asynchronously, but
to make it easier to keep track of them, add a uint64_t counter
to each message, that each peer increments by 1 for each message.

* each channel state (n) then corresponds to the accumulation of
updates from each each peer, up to message (a) for Alice, and message
(b) for Bob.

* so when updating to a new commitment (n+1), the proposal message
should just include both update values (a') and (b')

* nodes can then track the state by having a list of
htlcs/ptlcs/balances, etc for state (n), and a list of unapplied
update messages for themselves and the other party (a+1,...,a') and
(b+1,...,b'), and apply them in order when constructing the new state
(n+1) for a new commitment signing round

I think that retains both the interesting async bits (anyone can queue
state updates immediately) but also makes it fairly simple to maintain
the state?

> Bob's new commit tx can use the same revocation key as the previous
> one

That's a neat idea, but I think the fail/fulfill messages break it.
_But_ I think that means it would still be an interesting technique to
use for fast forwards which get updated for every add message...

> Not sending messages you don't need to is usually
> both more performant and simpler

The extra message from Bob allows Alice to discard the adaptor sigs
associated with the old state, which I think is probably worthwhile
anyway?

Cheers,
aj

📅 Original date posted:2021-12-08 📝 Original message: On ...

2023-06-09T15:04:38+02:00

In reply to nevent1q…gkp7
_________________________

📅 Original date posted:2021-12-08
📝 Original message:
On Tue, Dec 07, 2021 at 11:52:04PM +0000, ZmnSCPxj via Lightning-dev wrote:
> Alternately, fast-forwards, which avoid this because it does not change commitment transactions on the payment-forwarding path.
> You only change commitment transactions once you have enough changes to justify collapsing them.

I think the problem t-bast describes comes up here as well when you
collapse the fast-forwards (or, anytime you update the commitment
transaction even if you don't collapse them).

That is, if you have two PTLCs, one from A->B conditional on X, one
from B->A conditional on Y. Then if A wants to update the commitment tx,
she needs to

1) produce a signature to give to B to spend the funding tx
2) produce an adaptor signature to authorise B to spend via X from his
commitment tx
3) produce a signature to allow B to recover Y after timeout from his
commitment tx spending to an output she can claim if he cheats
4) *receive* an adaptor signature from B to be able to spend the Y output
if B posts his commitment tx using A's signature in (1)

The problem is, she can't give B the result of (1) until she's received
(4) from B.

It doesn't matter if the B->A PTLC conditional on Y is in the commitment
tx itself or within a fast-forward child-transaction -- any previous
adaptor sig will be invalidated because there's a new commitment
transaction, and if you allowed any way of spending without an adaptor
sig, B wouldn't be able to recover the secret and would lose funds.

It also doesn't matter if the commitment transaction that A and B will
publish is the same or different, only that it's different from the
commitment tx that previous adaptor sigs committed to. (So ANYPREVOUT
would fix this if it were available)

So I think this is still a relevant question, even if fast-forwards
make it a rare problem, that perhaps is only applicable to very heavily
used channels.

(I said the following in email to t-bast already)

I think doing a synchronous update of commitments to the channel state,
something like:

Alice -> Bob: propose_new_commitment
channel id
adaptor sigs for PTLCs to Bob

Bob -> Alice: agree_new_commitment
channel id
adaptor sigs for PTLCs to Alice
sigs for Alice to spend HTLCs and PTLCs to Bob from her own
commitment tx
signature for Alice to spend funding tx

Alice -> Bob: finish_new_commitment_1
channel id
sigs for Bob to spend HTLCs and PTLCs to Alice from his own
commitment tx
signature for Bob to spend funding tx
reveal old prior commitment secret
new commitment nonce

Bob -> Alice: finish_new_commitment_2
reveal old prior commitment secret
new commitment nonce

would work pretty well.

This adds half a round-trip compared to now:

Alice -> Bob: commitment_signed
Bob -> Alice: revoke_and_ack, commitment_signed
Alice -> Bob: revoke_and_ack

The timings change like so:

Bob can use the new commitment after 1.5 round-trips (previously 0.5)

Alice can be sure Bob won't use the old commitment after 2 round-trips
(previously 1)

Alice can use the new commitment after 1 round-trip (unchanged)

Bob can be sure Alice won't use the old commitment after 1.5 round-trips
(unchanged -- note: this is what's relevant for forwarding)

Making the funding tx a musig setup would mean also supplying 64B
of musig2 nonces along with the "adaptor sigs" in one direction,
and providing the other side's 64B of musig2 nonces back along with the
(now partial) signature for spending the funding tx (a total of 256B of
nonce data, not 128B).

Because it keeps both peers' commitments synchronised to a single channel
state, I think the same protocol should work fine with the revocable
signatures on a single tx approach too, though I haven't tried working
through the details.

Fast forwards would then be reducing the 2 round-trip protocol to
update the state commitment to a 0.5 round-trip update, to reduce
latency when forwarding by the same amount as before (1.5 round-trips
to 0.5 round-trips).

Cheers,
aj

📅 Original date posted:2021-10-11 📝 Original message: On ...

2023-06-09T15:04:09+02:00

In reply to nevent1q…lr05
_________________________

📅 Original date posted:2021-10-11
📝 Original message:
On Sat, Oct 09, 2021 at 11:12:07AM +1000, Anthony Towns wrote:
> 2. The balance transaction - tracks the funding transaction, contains
> a "balance" output for each of the participants.
> 3. The inflight transactions - spends a balance output from the balance
> transaction and provides outputs for any inflight htlc/ptlc transactions.
> 4. Layered transactions - spends inflight htlc/ptlc outputs by revealing
> the preimage, while still allowing for the penalty path.

I don't think the layering here quite works: if Alice forwarded a payment
to Bob, with timeout T, then the only way she can be sure that she can
either reclaim the funds or know the preimage by time T is to close the
channel on-chain at time T-to_self_delay.

Any time later than that, say T-to_self_delay+x+1, would allow Bob to
post the inflight tx at T+x (prior to Alice being able to claim her
balance directly due to the to_self_delay) and then immediately post the
layered transaction (4, above) revealing the preimage, and preventing
Alice from claiming the refund.

Cheers,
aj

📅 Original date posted:2021-10-12 📝 Original message: On ...

2023-06-09T15:04:09+02:00

In reply to nevent1q…p6hm
_________________________

📅 Original date posted:2021-10-12
📝 Original message:
On Mon, Oct 11, 2021 at 09:23:19PM +1100, Lloyd Fournier wrote:
> On Mon, 11 Oct 2021 at 17:30, Anthony Towns <aj at erisian.com.au> wrote:
> I don't think the layering here quite works: if Alice forwarded a payment
> to Bob, with timeout T, then the only way she can be sure that she can
> either reclaim the funds or know the preimage by time T is to close the
> channel on-chain at time T-to_self_delay.
> This problem may not be as bad as it seems.

Maybe you can break it down a little bit further. Consider *three*
delays:

1) refund delay: how long you have before a payment attempt starts
getting refunded

2) channel recovery delay: how long you have to recover from node
failure to prevent an old state being committed to, potentially losing
your entire channel balance

3) payment recovery delay: how long you have to recover from node
failure to prevent losing funds due to a forwarded payment (eg,
Carol claimed the payment, while Alice claimed the refund, leaving
Bob out of pocket)

(Note that if you allow payments up to the total channel balance, there's
not really any meaningful distinction between (2) and (3), at least in
the worst case)

With layered transactions, (2) and (3) are different -- if Bob's node
fails near the timeout, then both Alice and Carol drop to the blockchain,
and Carol knows the preimage, Bob may have as little as the channel
"delay" parameter to extract the preimage from Carol's layered commitment
tx to be able to post a layered commitment on top of Alice's unilateral
close to avoid being out of pocket.

(Note that that's a worst case -- Carol would normally reveal the preimage
onchain earlier than just before the timeout, giving Bob more time to
recover his node and claim the funds from Alice)

If you're willing to accept that "worst case" happening more often, I
think you could then retain the low latency forwarding, by having the
transaction structure be:

commitment tx
input:
funding tx
outputs:
Alice's balance
(others)

low-latency inflight tx:
input:
Alice's balance
output:
(1) or (2)
Alice's remaining balance

Bob claim:
input:
(1) [<payment-recovery-delay> CSV bob CHECKSIG]
output:
[<bob-revoke> checksigverify <alice> checksig
ifdup notif <channel-recovery-delay> csv endif]

Too-slow:
input:
(2) [<payment-timeout> CLTV alice CHECKSIG]
output:
Alice

The idea being:

* Alice sends the low-latency inflight tx which Bob then forwards
immediately.

* Bob then tries to update the base channel state with Alice, so both
sides have a commitment to the new payment, and the low-latency
inflight tx is voided (since it's based on a revoked channel state)
If this succeeds, everything is fine as usual.

* If Alice is unavailable to confirm that update, Bob closes the
channel prior to (payment-timeout - payment-recover-delay), and posts
"Bob claim". After an additional pyment recovery delay (and prior
to payment-timeout) Bob posts Bob claim, ensuring that the only way
Alice can claim the funds is if he had posted a revoked state.

* In this case, Alice has at least one payment-recovery-delay period
prior to the payment-timeout to notice the transaction onchain and
recover the preimage.

* If Bob posted the low-latency inflight tx later than
(payment-timeout - payment-recovery-delay) then Alice will have
payment-recovery-delay time to notice and post the "too-slow" tx and
claim the funds via the timeout path.

* If Bob posted a revoked state, Alice can also claim the funds via
Bob claim, provided she notices within the channel-recovery-delay

That only allows one low-latency payment to be inflight though, which I'm
not sure is that interesting... It's also kinda complicated, and doesn't
cover both the low-latency and offline cases, which is disappointing...

Cheers,
aj

📅 Original date posted:2021-10-12 📝 Original message: On ...

2023-06-09T15:04:08+02:00

In reply to nevent1q…rf9v
_________________________

📅 Original date posted:2021-10-12
📝 Original message:
On Mon, Oct 11, 2021 at 05:05:05PM +1100, Lloyd Fournier wrote:
> ### Scorched earth punishment
> Another thing that I'd like to mention is that using revocable signatures
> enables scorched earth punishments [2].

I kind-of think it'd be more interesting to simulate eltoo's behaviour.
If Alice's current state has balances (A, B) and P in in-flight
payments, and Bob posts an earlier state with (A', B') and P' (so A+B+P
= A'+B'+P'), then maybe Alice's justice transaction should pay:

A+P + max(0, B'-B)*0.1 to Alice
B-f - max(0, B'-B)*0.1 to Bob

(where "f" is the justice transaction fees)

Idea being that in an ideal world there wouldn't be a hole in your pocket
that lets all your coins fall out, but in the event that there is such
a hole, it's a *nicer* world if the people who find your coins give them
back to you out of the kindness of their heart.

> Note that we number each currently inflight transaction by "k",
> starting at 0. The same htlc/ptlc may have a different value for k
> between different inflight transactions.
> Can you expand on why "k" is needed in addition to "n" and "i". k sounds like
> the same thing as i to me.

"k" is used to distinguish the inflight payments (htlcs/ptlcs), not the
inflight state (which is "i").

> Also what does RP/2/k notation imply given the definition of RP you gave above?

I defined earlier that if P=musig(A,B) then P/x/y = musig(A/x/y,B/x/y);
so RP/2/k = musig(A/2/n/i/2/k,RB2(n,i)/2/k).

> * if the inflight transaction contains a ptlc output, [...]
> What about just doing a scriptless PTLC to avoid this (just CSV input of
> presigned tx)? The cost is pre-sharing more nonces per PTLC message.

Precisely that reason. Means you have to share "k+1" nonce pairs in
advance of every inflight tx update. Not a show stopper, just seemed
like a headache. (It's already a scriptless-script, this would let you
use a key path spend instead of a script path spend)

> This does not support option_static_remotekey, but compensates for that
> by allowing balances to be recovered with only the channel setup data
> even if all revocation data is lost.
> This is rather big drawback but is this really the case? Can't "in-flight"
> transactions send the balance of the remote party to their unencumbered static
> remote key?

They could, but there's no guarantee that there is an inflight
transaction, or that the other party will post it for you. In those case,
you have to be able to redeem your output from the balance tx directly,
and if you can do that, might as well have every possible address be
derived differently to minimise the amount of information any third
parties could glean.

Cheers,
aj

📅 Original date posted:2021-10-08 📝 Original message: On ...

2023-06-09T15:04:06+02:00

In reply to nevent1q…d6ya
_________________________

📅 Original date posted:2021-10-08
📝 Original message:
On Sat, Oct 09, 2021 at 01:49:38AM +0000, ZmnSCPxj wrote:
> A transaction is required, but I believe it is not necessary to put it *onchain* (at the cost of implementation complexity in the drop-onchain case).

The trick with that is that if you don't put it on chain, you need
to calculate the fees for it in advance so that they'll be sufficient
when you do want to put it on chain, *and* you can't update it without
going onchain, because there's no way to revoke old off-chain funding
transactions.

> This has the advantage of maintaining the historical longevity of the channel.
> Many pathfinding and autopilot heuristics use channel lifetime as a positive indicator of desirability,

Maybe that's a good reason for routing nodes to do shadow channels as
a matter of course -- call the currently established channel between
Alice and Bob "C1", and leave it as bolt#3 based, but establish a new
taproot based channel C2 also between Alice and Bob. Don't advertise C2
(making it a shadow channel), just say that C1 now supports PTLCs, but
secretly commit to those PTLCs to C2 instead C1. Once the C2 funding tx
is buried enough, start advertising C2 instead taking advantage of its
now sufficiently buried funding transaction, and convert C1 to a shadow
channel instead.

In particular, that setup allows you to splice funds into or out of the
shadow channel while retaining the positive longevity heuristics of the
public channel.

Cheers,
aj

📅 Original date posted:2021-10-08 📝 Original message: Hi ...

2023-06-09T15:04:05+02:00

In reply to nevent1q…kryc
_________________________

📅 Original date posted:2021-10-08
📝 Original message:
Hi all,

Here's my proposal for replacing BOLT#2 and BOLT#3 to take advantage of
taproot and implement PTLCs.

It's particularly inspired by ZmnSCPxj's thoughts from Dec 2019 [0], and
some of his and Lloyd Fournier's posts since then (which are listed in
references) -- in particular, I think those allow us to drop the latency
for forwarding a payment *massively* (though refunding a payment still
requires roundtrips), and also support receiving via a mostly offline
lightning wallet, which seems kinda cool.

I somehow hadn't realised it prior to a conversation with @brian_trollz
via twitter DM, but I think switching to PTLCs, even without eltoo,
means that there's no longer any need to permanently store old payment
info in order to recover the entirety of the channel's funds. (Some brute
force is required to recover the timeout info, but in my testing I think
that's about 0.05 seconds of work per ptlc output via python+libsecp256k1)

This doesn't require any soft-forks, so I think we could start work on
it immediately, and the above benefits actually seem pretty worth it,
even ignoring any privacy/efficiency benefits from doing taproot key
path spends and forwarding PTLCs.

I've sketched up the musig/musig2 parts for the "balance" transactions
in python [1] and tested it a little on signet [2], which I think is
enough to convince me that this is implementable. There'll be a bit of
preliminary work needed in actually defining specs/BIPs for musig and
musig2 and adaptor signatures, I think.

Anyway, details follow. They're also up on github as a gist [3] if that
floats your boat.

[0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002375.html

[1] https://github.com/ajtowns/bitcoin/blob/202109-ptlc-lnpenalty/test/functional/feature_ln_ptlc.py

[2] The balance transaction (spending the funding tx and with outputs
being Alice's and Bob's channel balance is at):
https://explorer.bc-2.jp/tx/ba58d99dfaad83e105a0de1a9becfcf8eaf897aaaada54bd7b08134ff579997c?input:0&expand

[3] https://gist.github.com/ajtowns/12f58fa8a4dc9f136ed04ca2584816a2/

Goals
=====

1. Support HTLCs
2. Support PTLCs
3. Minimise long-term data storage requirements
4. Minimise latency when forwarding payments
5. Minimise latency when refunding payments
6. Support offline receiving
7. Minimise on-chain footprint
8. Minimise ability for third-parties to analyse

Setup
=====

We have two participants in the channel, Alice and Bob. They each have
bip32 private keys, a and b, and share the corresponding xpubs A and B
with each other.

Musig
-----

We will use musig to combine the keys, where P = musig(A,B) = H(A,B,1)*A
+ H(A,B,2)*B. We'll talk about subkeys of P, eg P/4/5/6, which are
calculated by taking subkeys of the input and then applying musig,
eg P/4/5/6 = musig(A/4/5/6, B/4/5/6). (Note that we don't use hardened
paths anywhere)

Musig2
------

We'll use musig2 to sign for these keys, that is both parties will
pre-share two nonce points each, NA1, NA2, NB1, NB2, and the nonce will be
calculated as: R=(NA1+NB1)+k(NA2+NB2), where k=Hash(P,NA1,NA2,NB1,NB2,m),
where P is the pubkey that will be signing and m is the message to be
signed. Note that NA1, NA2, NB1, NB2 can be calculated and shared prior
to knowing what message will be signed.

The partial sig by A for a message m with nonce R as above is calculated as:

sa = (na1+k*na2) + H(R,A+B,m)*a

where na1, na2, and a are the secrets generating NA1, NA2 and A respectively.
Calculating the corresponding partial signature for B,

sb = (nb1+k*nb2) + H(R,A+B,m)*b

gives a valid signature (R,sa+sb) for (A+B):

(sa+sb)G = R + H(R,A+B,m)*(A+B)

Note that BIP340 sepcifies x-only pubkeys, so A+B and R implicitly have
even y, however since those values are caluclated via musig and musig2
respectively, this cannot be ensured in advance. Instead, if we find:

H(A,B,1)*A + H(A,B,2)*B

does not have even y, we calculate:

P = (-H(A,B,1))*A + (-H(A,B,2))*B

instead, which will have even y. Similarly, if (NA1+NB1+k(NA2+NB2)) does
not have even y, when signing, we replace each partial nonce by its negation,
eg: sa = -(na1+k*na2) + H(R,A+B,m).

Adaptor Sigs
------------

An adaptor signature for P for secret X is calculated as:

s = r + H(R+X, P, m)*p

which gives:

(s+x)G = (R+X) + H(R+X, P, m)*P

so that (R+X,s+x) is a valid signature by P of m, and the preimage for
X can be calculated as the difference between the published sig and the
adaptor sig, x=(s+x)-(s).

Note that if R+X does not have even Y, we will need to negate both R and X,
and the recovered secret preimage will be -x instead of x.

Revocable Secrets
-----------------

Alice and Bob have shachain secrets RA(n) and RB(n) respectively,
and second level shachain secrets RA2(n,i) and RB2(n,i), with n and i
counting up from 0 to a maximum.

Summary
=======

We'll introduce four layers of transactions:

1. The funding transaction - used to establish the channel, provides
the utxo backing the channel while the channel is open.
2. The balance transaction - tracks the funding transaction, contains
a "balance" output for each of the participants.
3. The inflight transactions - spends a balance output from the balance
transaction and provides outputs for any inflight htlc/ptlc transactions.
4. Layered transactions - spends inflight htlc/ptlc outputs by revealing
the preimage, while still allowing for the penalty path.

Funding transaction
===================

The funding transaction simply pays to P/0/f via taproot, where f starts
at 0 and increases any time the funding transaction is updated onchain
(eg when splicing funds in or out).

Balance transaction
===================

The balance transaction spends the funding transaction, and has two
outputs, one for Alice's balance and one for Bob's balance (omitting a
zero/dust balance).

We count the number of balance updates, starting at 0, and call it "n".
"n" is encoded in the transaction locktime and the input nsequence, so
if a balance transaction appears on chain, "n" can be decoded from the
nsequence and locktime.

Alice's balance is paid to an address with internal pubkey P/1/n/0
and a script path of "<A/1/n> CHECKSIGVERIFY <D> CSV" where D is
Alice's to_self_delay. Bob's balance is similar, with internal pubkey
P/1/n/1.

In order to update to a new balance transaction, the process is as follows.
First, nonces are exchanged in advance:

Alice:
Generates a nonce pair NA1, NA2 derived from RA(n). Shares this with
Bob.
Bob:
Generates a nonce pair NB1, NB2 derived from RB(n). Shares this with
Alice.

Then, presuming Alice initiates the update:

Alice:
Generates deterministic nonce pair, DA1, DA2. Combines this with
Bob's NB1, NB2 nonce pair. Generates partial signature for nonce
(DA, NB) for the transaction. Sends DA1 and DA2 and the partial
signature to Bob.

Bob:
Checks the partial signature is valid. Updates to the new balance
transaction. Generates a nonce pair, DB1, DB2, and gnerates a partial
signature for the balance transaction for nonce (NA, DB). Sends DB1,
DB2, and the partial signature to Alice. Generates a new revocable
secret RB(n+1). Revokes the previous secret RB(n) and sends the
details of both to Alice.

Alice:
Checks the partial signature is valid. Updates to the new balance
transaction. Checks the secret revocation info is correct and stores
it. Generates a new revocable secret RA(n+1). Revokes the previous
secret RA(n) and sends the details of both to Bob.

Bob:
Checks the secret revocation info is correct an stores it.

This means that both Alice and Bob have the same balance transaction here
(with the same txid) but have different signatures for it (and thus
differing wtxids).

Because updating the balance transaction involves two round trips
before Bob can be sure Alice cannot use the old state, we move all the
transaction information to the inflight transactions, which we will be
able to update immediately, without requiring a round trip at all.

Note that if Bob publishes the signature for an old state, then the
signature is:

s = ((DA1+NB1) + k(DA2+NB2)) + H(R,A+B,m)(a+b)

but Alice can calculate the secrets for both DA1 and DA2 (she generated
those deterministically herself in the first place), and NB1 and NB2 (she
has the secret revocation information, and verified that it correctly
generated the nonces Bob was using), which allows her to calculate Bob's
private key using modular arithmetic:

b = H(R,P,m) / (s - (DA1+NB1) - b(DA2+NB2)) - a

which means she can then directly sign without Bob's assistance, allowing
her to claim any funds.

Inflight and Layered Transactions
=================================

We construct two inflight transactions on top of the current balance
transaction, one spending Alice's balance, and one spending Bob's balance.

We will use "i" to represent the number of times a given inflight
transaction has been updated for the nth update to the balance
transaction.

At any time Alice can update the inflight transaction spending her balance
to transfer funds towards Bob, either by updating the balances directly,
or adding a htlc/ptlc entry to conditionally transfer funds to Bob. (And
conversely for Bob)

We will define RP=musig(A/2/n/i, RB2(n,i)).

The inflight transaction spending Alice's balance can have multiple
types of outputs:

* Alice's remaining balance: pays directly to A/2/n/i

* Bob's remaining balances: pays to RP/2 with script path
"<B/2/n/i> CHECKSIGVERIFY <D> CSV"

* An htlc paying to Bob: pays to RP/2/k with script paths:
+ "LENGTH 32 EQUALVERIFY HASH160 <X> EQUALVERIFY <B/2/n/i/k> CHECKSIGVERIFY <A/2/n/i/k> CHECKSIG"
+ "<A/2/n/i/k/1> CHECKSIGVERIFY <T> CLTV"

* A ptlc paying to Bob: pays to RP/2/k with script paths:
+ "<B/2/n/i/k> CHECKSIG NOTIF <T> CLTV DROP ENDIF <A/2/n/i/k> CHECKSIG"

Any outputs that would be zero or dust are not included.

Note that we number each currently inflight transaction by "k",
starting at 0. The same htlc/ptlc may have a different value for k
between different inflight transactions.

The inflight transation's locktime is set to the current block
height. This enables brute force searching for the locktime of any
inflight ptlcs (so that in a penalty scenario when the other party posts
an out of date inflight transaction, you can search through a small
number of possible timeout values simply by not sending any ptlcs with
a timeout more that L blocks in the future).

The balance input's nsequence is used to encode the value of the lower
24 bits of i in the same way the balance transaction's fund input's
nsequence encodes the upper 24 bits of n.

The layered transaction will spend the htlc/ptlc outputs, with an
ANYONECANPAY|SINGLE signature by Alice using the A/2/n/i/k path.
The output committed to is:

* pays to RP/3/k with script path:
+ <B/3/n/i/k> CHECKSIGVERIFY <D> CSV

with no absolute or relative locktime.

To update the inflight transaction spending Alice's balance as well as
any dependent layered transactions, the process is as follows:

Bob:
Generates a second level revocable secret, RB2(n,i) and sends Alice
the corresponding point, PB2. Calculates a nonce pair, NB1, NB2, and
sends that to Alice. This is done in advance.

Alice:
Calculates the new inflight transaction. Calculates new nonces NA1,
NA2, and partially signs the spend of her balance via the key path,
with musig2 nonces NA1, NB1, NA2, NB2. For each inflight htlc,
Alice provides a signature via A/2/n/i/k. For each inflight ptlc,
Alice provides an adaptor signature via the A/2/n/i/k/0 path that
is conditional on the ptlc's point.

Bob:
Bob verifies the new proposed inflight state and each of the
signatures. Bob may now rely on the new state. Bob revokes their
prior secret, RB2(n, i-1), and sends a new point/nonce pair (PB2',
NB1', NB2') to Alice to prepare for the next round.

Note that Bob could stream multiple point/nonce pairs in advance,
allowing Alice to do multiple inflight tx updates within the time taken
for a roundtrip.

Alice can unilaterally do the following safely:

1. transfer from Alice's balance to Bob's balance
2. accept that a htlc/ptlc succeeded, removing the corresponding output
and allocating the funds associated with it directly to Bob's balance
3. introduce a htlc/ptlc, spending funds from Alice's balance

However refunding/cancelling a htlc/ptlc requires a two-phase commit
with 1.5 round trips:

- Bob proposes refunding a htlc/ptlc
- Alice agrees and sends a partial signature for the new transaction
with the htlc/ptlc funds transferred back to her balance,
- Bob records the new transaction, and revokes the earlier second
level secret RB2(n, i-1).
- Alice verifies the revocation, and can safely treat the funds as
refunded (and thus refund back to the original payer, eg).

The advantage of doing this over negotiating a new balance transaction
is that only the second level revocation secrets need to be online,
allowing for operation by semi-offline lightning nodes (ie, having the
channel private key and first level revocation secrets offline). Such
semi-offline nodes risk losing funds in the "inflight" transaction
(either by revealing the second level revocation secrets or by simply
data loss of the current inflight/layered transactions) but do not risk
losing or spending funds in their own output of the balance transaction.

This means the funds locked in Alice's balance can be spent in the
following ways:

* Alice can claim them directly if Bob does not post the inflight
transaction before the delay expires, via the script balance output's
script path. Alice gets the entire balance in this case.

* Bob can post a revoked inflight transaction, for which Alice knows the
secret for RB(n,i). In this case Alice recovers the value of i from
the nsequence (using brute force for the upper bits if she has
provided more than 16M updates of the inflight tx for any given
balance transaction), and then calculates the secret key for PB,
and hence PB/2/k and PB/3/k, at which point she can claim every
output via a key path spend, even if Bob posts some or all of the
layered transactions. Alice gets the entire balance in this case
(though spends more on fees).

* Bob can post a current inflight transaction, along with layered
transactions for any of the inflight htlc/ptlcs for which he knows the
corresponding preimage, allowing Alice to recover the preimages from
the on-chain spends immediately. Alice can claim her balance output and
any timed out funds immediately as well. Bob can finish claiming his
balance and any claimed htlc/ptlc funds after the delay has finished.

Note that Bob never shares his signature to spend Alice's balance prior
to posting the inflight transaction, so Alice can never post an inflight
transaction that spends her own balance.

The cases where Alice may have difficulty claiming funds is Bob posts
a revoked inflight transaction (possibly spending a revoked balance
transaction) are:

* if the inflight transaction contains a htlc output, then if Alice
has not retained the old htlc details (the hash160 and the timeout)
she will not be able to reconstruct the script path, and thus will
not be able to calculate the TapTweak to sign for the key path.
However if Bob attempts to claim the output (via the pre-signed
layered transaction), that will reveal the information she was missing,
and she can immediately claim the funds via the layered transaction
output, prior to Bob being able to spend that output.

* if the inflight transaction contains a ptlc output, then if Alice
has not retained the old ptlc details (the point and the timeout)
she will not trivially be able to reconstruct the script path,
which includes the timeout. However, presuming the timeout was
within 5000 blocks, then the only possible timeouts are the inflight
tx's nlocktime+i with 0<i<=5000, and she will only need to calculate
5000*k cases and match the corresponding scriptPubKeys to exhaustively
enumerate every possible ptlc output, which should take under a minute,
and be easily achievable. In addition, if Bob attempts to claim the
funds, he will reveal the script path, and Alice will be either able
to claim the inflight output directly or the layered output.

Misc
====

In order to transition from BOLT#3 format to this proposal, an onchain
transaction is required, as the "revocable signatures" arrangement cannot
be mimicked via the existing 2-of-2 CHECKMULTISIG output.

To allow splicing in/out, it may be important to maintain multiple
concurrent funding transactions (paying to P/0/f and P/0/f+1 eg),
which then requires maintaining multiple current balance transactions
(paying to P/1/n/* and P/1/n+1/x eg) and likewise multiple current
inflight/layered transactions. This will require ensuring the states
for all those transactions are synchoronised when verifying upates,
and requires sharing multiple nonces for signing (eg RA(n) and RA(n+1)
and RB2(n,i), and RB2(n+1,i)).

Fees for the balance and inflight transactions must be considered upfront,
and paid for from the channel balance (or perhaps via additional anchor
outputs that allocate more than the dust threshold and are immediately
spendable). Fees for the layered transactions however can (and must)
be provided by whoever is attempting to claim the funds.

Bob having a current inflight transaction spending Alice's balance is
advantageous to Alice as Bob posting the inflight transaction allows
her to immediately claim her balance, rather than having to wait for
the delay to complete.

If two nodes agree to only forward ptlcs in future, then updating the
funding transaction (to P/0/f+1 eg) and ignoring any proposed inflight
transactions that include htlc outputs is enough to ensure that all htlc
records can be forgotten without risking any part of the channel balance
being unclaimable.

This does not support option_static_remotekey, but compensates for that
by allowing balances to be recovered with only the channel setup data
even if all revocation data is lost.

References
==========

Hopefully the above includes enough explanation to be understood on its own,
but here's references for a bunch of the concepts.

* musig: https://blockstream.com/2018/01/23/en-musig-key-aggregation-schnorr-signatures/

* musig2: https://medium.com/blockstream/musig2-simple-two-round-schnorr-multisignatures-bf9582e99295

* adaptor sigs: https://github.com/ElementsProject/scriptless-scripts/blob/master/md/atomic-swap.md

* fast forwards [ZmnSCPxj]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-April/001986.html
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003043.html
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003265.html

* revocable signatures [LLFourn]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-August/002785.html

📅 Original date posted:2021-08-16 📝 Original message: On ...

2023-06-09T15:03:27+02:00

In reply to nevent1q…agez
_________________________

📅 Original date posted:2021-08-16
📝 Original message:
On Sun, Aug 15, 2021 at 10:21:52PM -0400, Matt Corallo wrote:
> On 8/15/21 22:02, Anthony Towns wrote:
> > > In
> > > one particular class of applicable routing algorithms you could use for
> > > lightning routing having a base fee makes the algorithm intractably slow,
> > I don't think of that as the problem, but rather as the base fee having
> > a multiplicative effect as you split payments.
> Yes, matching the real-world costs of forwarding an HTLC.

Actually, no, not at all.

The base+proportional fees paid only on success roughly match the *value*
of forwarding an HTLC, they don't match the costs particularly well
at all.

Why not? Because the costs are incurred on failed HTLCs as well, and
also depend on the time a HTLC lasts, and also vary heavily depending
on how many other simultaneous HTLCs there are.

> Yes. You have to pay the cost of a node. If we're really worried about this,
> we should be talking about upfront fees and/or refunds on HTLC fulfillment,
> not removing the fees entirely.

(I don't believe either of those are the right approach, but based on
previous discussions, I don't think anyone's going to realise I'm right
until I implement it and prove it, so *shrug*)

> > Being denominated in sats, the base fee also changes in value as the
> > bitcoin price changes -- c-lightning dropped the base fee to 1sat (from
> > 546 sat!) in Jan 2018, but the value of 1sat has increased about 4x
> > since then, and it seems unlikely the fixed costs of a successful HTLC
> > payment have likewise increased 4x. Proportional fees deal with this
> > factor automatically, of course.
> This isn't a protocol issue, implementations can automate this without issue.

I don't think anyone's proposing the protocol be changed; just that node
operators set an option to a particular value?

Well, except that Lisa's maybe proposing that 0 not be allowed, and a
value >= 0.001 sat be required? I'm not quite sure.

> > > There's real cost to distorting the fee structures on the network away from
> > > the costs of node operators,
> > That's precisely what the base fee is already doing.
> Huh? For values much smaller than a node's liquidity, the cost for nodes is
> (mostly) a function of HTLCs, not the value.

Yes, the cost for nodes is a function of the requests that come in, not
how many succeed. The fees are proportional to how many succeed, which
is at best a distorted reflection of the number of requests that come in.

> The cost to nodes is largely [...]

The cost to nodes is almost entirely the opportunity cost of not being
able to accept other txs that would come in afterwards and would pay
higher fees.

And all those costs can be captured equally well (or badly) by just
setting a proportional fee and a minimum payment value. I don't know why
you keep ignoring that point.

> so I'd argue for many HTLCs forwarded
> today per-payment costs mirror the cost to a node much, much, much, much
> better than some proportional fees?

You're talking yourself into a *really* broken business model there.

> > Additionally, I don't think HTLC slot usage needs to be kept as a
> > limitation after we switch to eltoo;
> The HTLC slot limit is to keep transactions broadcastable. I don't see why
> this would change, you still get an output for each HTLC on the latest
> commitment in eltoo, AFAIU.

eltoo gives us the ability to have channel factories, where we divide
the overall factory balance amongst different channels, all updated
off-chain. It seems likely we'll want to do factories from day one,
so that we don't implicitly limit either the lifetime of the channel
or its update rate (>1 update/sec ~= <4 year lifetime otherwise if I
did the maths right). Once we're doing factories, if we have more than
however many htlcs for a channel, we can re-divide the factory balance
and add a new channel. If the limit is 500 HTLCs per tx, you'd have to
amortize 0.2% of the new tx across each HTLC, in addition to the cost
of the HTLC itself, but that seems trivial.

> > and in the meantime, I think it can
> > be better managed via adjusting the min_htlc_amount -- at least for the
> > scenario where problems are being caused by legitimate payment attempts,
> > which is also the only place base fee can help.
> Sure, we could also shift towards upfront fees or similar solutions,

Upfront fees seem extremely vulnerable to attacks, and are certainly a
(pretty large) protocol change.

> > > Instead, we should investigate how we can
> > > apply the ideas here with the more complicated fee structures we have.
> > Fee structures should be *simple* not complicated.
> > I mean, it's kind of great that we started off complicated -- if it
> > turns out base fee isn't necessary, it's easy to just set it to zero;
> > if we didn't have it, but needed it, it would be much more annoying to
> > add it in later.
> Fee structures should also match reality, and allow node operators
> sufficient flexibility to capture their costs. I think we have a design that
> does so quite well - its pretty simple, there's only two knobs, but the two
> knobs capture exactly the two broad categories of costs a node operator has.

I don't know how you can think these "exactly" capture node operators'
costs. They're missing the time factor, and don't capture any of the
costs due to failed payments.

> Sure, the great thing about today is because the protocol exposes decent
> knobs operators can tune

Knobs are great for experimenting; but they're also something to work
at reducing once the experiments have come up with some results. I
think #zerobasefee is more in the experiment stage: "hey, this seems
like a great idea, let's set this knob to zero and focus on these other
ones instead".

> > For an experimental plugin that aggressively splits payments up, I think
> > either ignoring channels with >0 base fee entirely, or deciding that
> > you're happy to spend a total of X sats on base fees, and then ignoring
> > channels whose base fee is greater than X/paths/path-length sats is fine.
> Sure, experimental plugins can do whatever they want!

Is there any reason to think any of this would be something other than
node configuration options and experimental plugins any time soon?

(By "any time soon" I mean, I could see software defaults changing if
over 50% of the network deliberately switched to zero base fees and found
it worked fine; and I could see deprecating non-zero fees if that ended
up with 90% of the network on zero base fees, no good reasons for node
operators wanting to stick with running non-zero base fees, and the
experimental algos that relied on zero base fees being significantly
easier to maintain or faster/better)

> > But long term, I also think that the base fee is an entirely unhelpful
> > complication that will eventually just be hardcoded to zero by everyone,
> > and eventually channels that propose non-zero base fees won't even be
> > gossiped. I don't expect that to happen any time soon though.
> I very strongly disagree, as discussed, and am left highly dubious
> that it is a practical complication in any case.

That's okay! Long term predictions would be pretty boring if everyone
agreed with them.

Cheers,
aj

📅 Original date posted:2021-08-14 📝 Original message: Hey ...

2023-06-09T15:03:24+02:00

In reply to nevent1q…ll3u
_________________________

📅 Original date posted:2021-08-14
📝 Original message:
Hey *,

There's been discussions on twitter and elsewhere advocating for
setting the BOLT#7 fee_base_msat value [0] to zero. I'm just writing
this to summarise my understanding in a place that's able to easily be
referenced later.

Setting the base fee to zero has a couple of benefits:

- it means you only have one value to optimise when trying to collect
the most fees, and one-dimensional optimisation problems are
obviously easier to write code for than two-dimensional optimisation
problems

- when finding a route, if all the fees on all the channels are
proportional only, you'll never have to worry about paying more fees
just as a result of splitting a payment; that makes routing easier
(see [1])

So what's the cost? The cost is that there's no longer a fixed minimum
fee -- so if you try sending a 1sat payment you'll pay 0.1% of the fee
to send a 1000sat payment, and there may be fixed costs that you have
in routing payments that you'd like to be compensated for (eg, the
computational work to update channel state, the bandwith to forward the
tx, or the opportunity cost for not being able to accept another htlc if
you've hit your max htlcs per channel limit).

But there's no need to explicitly separate those costs the way we do
now; instead of charging 1sat base fee and 0.02% proportional fee,
you can instead just set the 0.02% proportional fee and have a minimum
payment size of 5000 sats (htlc_minimum_msat=5e6, ~$2), since 0.02%
of that is 1sat. Nobody will be asking you to route without offering a
fee of at least 1sat, but all the optimisation steps are easier.

You could go a step further, and have the node side accept smaller
payments despite the htlc minimum setting: eg, accept a 3000 sat payment
provided it pays the same fee that a 5000 sat payment would have. That is,
treat the setting as minimum_fee=1sat, rather than minimum_amount=5000sat;
so the advertised value is just calculated from the real settings,
and that nodes that want to send very small values despite having to
pay high rates can just invert the calculation.

I think something like this approach also makes sense when your channel
becomes overloaded; eg if you have x HTLC slots available, and y channel
capacity available, setting a minimum payment size of something like
y/2/x**2 allows you to accept small payments (good for the network)
when you're channel is not busy, but reserves the last slots for larger
payments so that you don't end up missing out on profits because you
ran out of capacity due to low value spam.

Two other aspects related to this:

At present, I think all the fixed costs are also incurred even when
a htlc fails, so until we have some way of charging failing txs for
incurring those costs, it seems a bit backwards to penalise successful
txs who at least pay a proportional fee for the same thing. Until we've
got a way of handling that, having zero base fee seems at least fair.

Lower value HTLCs don't need to be included in the commitment transaction
(if they're below the dust level, they definitely shouldn't be included,
and if they're less than 1sat they can't be included), and as such don't
incur all the same fixed costs that HTLCs that are committed too do.
Having different base fees for microtransactions that incur fewer costs
would be annoying; so having that be "amortised" into the proportional
fee might help there too.

I think eltoo can help in two ways by reducing the fixed costs: you no
longer need to keep HTLC information around permanently, and if you do
a multilevel channel factory setup, you can probably remove the ~400
HTLCs per channel at any one time limit. But there's still other fixed
costs, so I think that would just lower the fixed costs, not remove them
altogether and isn't a fundamental change.

I think the fixed costs for forwarding a HTLC are very small; something
like:

0.02sats -- cost of permanently storing the HTLC info
(100 bytes, $500/TB/year, 1% discount rate)
0.04sats -- compute and bandwidth cost for updating an HTLC ($40/month
at linode, 1 second of compute)

The opportunity cost of having HTLC slots or Bitcoin locked up until
the HTLC succeeds/fails could be much more significant, though.

Cheers,
aj

[0] https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#the-channel_update-message
[1] https://basefee.ln.rene-pickhardt.de/

📅 Original date posted:2021-07-12 📝 Original message: Hello ...

2023-06-09T15:03:08+02:00

In reply to nevent1q…kxkc
_________________________

📅 Original date posted:2021-07-12
📝 Original message:
Hello world,

Suppose you have some payments going from Alice to Bob to Carol with
eltoo channels. Bob's lightning node crashes, and he recovers from an
old backup, and Alice and Carol end up dropping newer channel states
onto the blockchain.

Suppose the timeout for the payments is a few hours away, while the
channels have specified a week long CSV delay to rectify any problems
on-chain.

Then I think that that means that:

1) Carol will reveal the point preimages on-chain via adaptor
signatures, but Bob won't be able to decode those adaptor signatures
because those signatures will need to change for each state

2) Even if Bob knows the point preimages, he won't be able to
claim the PTLC payments on-chain, for the same reason: he needs
newer adaptor signatures that he'll have lost with the state update

3) For any payments that timeout, Carol doesn't have any particular
incentive to make it easy for Bob to claim the refund, and Bob won't
have the adaptor signatures for the latest state to do so

4) But Alice will be able to claim refunds easily. This is working how
it's meant to, at least!

I think you could fix (3) by giving Carol (who does have all the adaptor
signatures for the latest state) the ability to steal funds that are
meant to have been refunded, provided she gives Bob the option of claiming
them first.

However fixing (1) and (2) aren't really going against Alice or Carol's
interests, so maybe you can just ask: Carol loses nothing by allowing
Bob to claim funds from Alice; and Alice has already indicated that
knowing P is worth more to her than the PTLC's funds -- otherwise she
wouldn't have forwarded the PTLC to Bob in the first place.

Likewise, everyone's probably incentivised to negotiate cooperative
closes instead of going on-chain -- better privacy, less fees, and less
delay before the funds can be used elsewhere.

FWIW, I think a similar flaw exists even in the original eltoo spec --
Alice could simply decline to publish the settlement transaction until
the timeout has been reached, preventing Bob from revealing the HTLC
preimage before Alice can claim the refund.

So I think that adds up to:

a) Nodes should share state on reconnection; if you find a node that
doesn't do this, close the channel and put the node on your enemies
list. If you disagree on what the current state is, share your most
recent state, and if the other guy's state is more recent, and all
the signatures verify, update your state to match theirs.

b) Always negotiate a mutual/cooperative close if possible, to avoid
actually using the eltoo protocol on-chain.

c) If you want to allow continuing the channel after restoring an old
state from backup, set the channel state index based on the real time,
eg (real_time-start_time)*(max_updates_per_second). That way your
first update after a restore from backup will ensure that any old
states that your channel partner may not have told you about are
invalidated.

d) Accept that if you lose connectivity to a channel partner, you will
have to pay any PTLCs that were going to them, and won't be able
to claim the PTLCs that were funding them. Perhaps limit the total
value of inbound PTLCs for forwarding that you're willing to accept
at any one itme?

Also, layered commitments seem like they make channel factories
complicated too. Nobody came up with a way to avoid layered commitments
while I wasn't watching did they?

Cheers,
aj

📅 Original date posted:2020-02-20 📝 Original message: On ...

2023-06-09T14:58:57+02:00

In reply to nevent1q…lsa9
_________________________

📅 Original date posted:2020-02-20
📝 Original message:
On Thu, Feb 20, 2020 at 03:42:39AM +0000, ZmnSCPxj wrote:
> A thought that arises here is, what happens if I have forwarded a payment, then the outgoing channel is dropped onchain and that peer disconnects from me?
>
> Since the onchain HTLC might have a timelock of, say, a few hundred blocks from now, the outgoing peer can claim it up until the timelock.
> If the peer does not claim it, I cannot claim it in my incoming as well.
> I also cannot safely fail my incoming, as the outgoing peer can still claim it until the timelock expires.

Suppose the channel state looks like:

Bob's balance: $150
Carol's balance: $500
Bob to Carol: $50, hash X, timelock +2016 blocks

The pre-signed close transaction will have already deducted maybe $1 in
fees, say 50c from each balance.

At 5% pa, that's $50*0.05*2/52, so about 10 cents worth of "holding"
fees, so that seems like it's worth just committing to up-front, ie:

Bob's balance: $149.60 (-.50+.10)
Carol's balance: $499.40 (-.50-.10)
Bob to Carol: $50, hash X, timelock +2016 blocks
Fees: $1

And that seems necessary anyway: if the channel does drop to the chain,
then the HTLC can't be cancelled, so if it never confirms, Bob will have
had to pay, say, 9.5c to Alice waiting for the timeout, and can then
immediately cancel the HTLC with Alice allowing it to finish unwinding.

So I think the idea would be not to accept a (rate, amount, timelock)
tuple for an incoming HTLC unless the rate*amount*timelock product
is substantially less than what you're putting towards the blockchain
fees anyway, as otherwise you've got bad incentives for the other guy to
drop to the chain.

Note the rate increases with number of hops, so if it's 1% pa per hop,
the 11th peer will be emitting 10% pa. I think that's probably okay,
because BTC's deflationary nature probably means you don't need to earn
much interest on it, and you can naturally choose the rate dynamically
based on how many HTLCs you currently have open and how much of your
channel funds are being used up by the HTLC?

Also, you'd presumably update your channel state every hundred blocks,
reducing the 10c by half a cent or so each time, so you could have your
risk reduce. Maybe there could be some way of bumping the timelock across
a HTLC path so that the risk is capped, but if the HTLC is still being
paid for it doesn't have to be cancelled?

Cheers,
aj

📅 Original date posted:2020-02-20 📝 Original message: On ...

2023-06-09T14:58:56+02:00

In reply to nevent1q…hhv7
_________________________

📅 Original date posted:2020-02-20
📝 Original message:
On Tue, Feb 18, 2020 at 10:23:29AM +0100, Joost Jager wrote:
> A different way of mitigating this is to reverse the direction in which the
> bond is paid. So instead of paying to offer an htlc, nodes need to pay to
> receive an htlc. This sounds counterintuitive, but for the described jamming
> attack there is also an attacker node at the end of the route. The attacker
> still pays.

I think this makes a lot of sense. I think the way it would end up working
is that the further the route extends, the greater the payments are, so:

A -> B : B sends A 1msat per minute
A -> B -> C : C sends B 2msat per minute, B forwards 1msat/min to A
A -> B -> C -> D : D sends C 3 msat, etc
A -> B -> C -> D -> E : E sends D 4 msat, etc

so each node is receiving +1 msat/minute, except for the last one, who's
paying n msat/minute, where n is the number of hops to have gotten up to
the last one. There's the obvious privacy issue there, with fairly
obvious ways to fudge around it, I think.

But that's rational, because that last node can either (a) collect the
payment, covering their cost; or (b) forward the payment, at which point
they'll start collecting funds rather than paying them; or (c) cancel
the payment releasing all the locked up funds all the way back.

I think it might make sense for the payments to have a grace period --
ie, "if you keep this payment open longer than 20 seconds, you have to
start paying me x msat/minute, but if it fulfills or cancels before
then, it's all good".

I'm not sure if there needs to be any enforcement for this beyond "this
peer isn't obeying the protocol, so I'm going to close the channel"; not
even sure it's something that needs to be negotiated as part of payment
routing -- it could just be something each peer does for HTLCs on their
channels? If that can be made to work, it doesn't need much crypto or
bitcoin consensus changes, or even much deployment coordination, all of
which would be awesome.

I think at $10k/BTC then 1msat is about the fair price for locking up $5
worth of BTC (so 50k sat) for 1 minute at a 1% pa interest rate, fwiw.

Maybe this opens up some sort of an attack where a peer lies about the
time to make the "per minute" go faster, but if msats-per-minute is the
units, not sure that really matters.

Maybe this also implies a different protocol for HTLC forwarding,
something like:

1. A sends the HTLC onion packet to B
2. B decrypts it, makes sure it makes sense
3. B sends a half-signed updated channel state back to A
4. A accepts it, and forwards the other half-signed channel update to B

so that at any point before (4) Alice can say "this is taking too long,
I'll start losing money" and safely abort the HTLC she was forwarding to
Bob to avoid paying fees; while only after (4) can she start the time on
expecting Bob to start paying fees that she'll forward back. That means
1.5 round-trips before Bob can really forward the HTLC on to Carol;
but maybe it's parallelisable, so Bob/Carol could start at (1) as soon
as Alice/Bob has finished (2).

Cheers
aj

📅 Original date posted:2019-12-17 📝 Original message: On ...

2023-06-09T14:57:42+02:00

In reply to nevent1q…w206
_________________________

📅 Original date posted:2019-12-17
📝 Original message:
On Sun, Dec 15, 2019 at 03:43:07PM +0000, ZmnSCPxj via Lightning-dev wrote:
> For now, I am assuming the continued use of the existing Poon-Dryja update mechanism.
> Decker-Russell-Osuntokun requires `SIGHASH_NOINPUT`/`SIGHASH_ANYPREVOUT`, and its details seem less settled for now than taproot details.

Supporting PTLCs instead of HTLCs is a global upgrade in that you need
all nodes along your payment path to support it; moving from Poon-Dryja
to Decker-Russell-Osuntokun is only relevant to individual peers. So I
think it makes sense to do PTLCs first if the required features aren't
both enabled at the same time.

> Poon-Dryja with Schnorr
> -----------------------

I think MuSig between the two pairs is always superior to a NUMS point
for the taproot internal key; you definitely want to calculate a point
rather than use a constant, or you're giving away that it's lightning,
and if you're calculating you might as well calculate something that can
be used for a cooperative key path spend if you ever want to.

> A potential issue with MuSig is the increased number of communication rounds needed to generate signatures.

I think you can reduce this via an alternative script path. In
particular, if you want a script that the other guy can spend if they
reveal the discrete log of point X, with musig you do:

P = H(H(A,B),1)*A + H(H(A,B),2)*B
[exchange H(RA),H(RB),RA,RB]

[send X]

sb = rb + H(RA+RB+X,P,m)*H(H(A,B),2)*b

[wait for sb]

sa = ra + H(RA+RB+X,P,m)*H(H(A,B),1)*a

[store RA+RB+X, sa+sb, supply sa, watch for sig]

sig = (RA+RB+X, sa+sb+x)

So the 1.5 round trips are "I want to do a PTLC for X", "okay here's
sb", "great, here's sa".

But with taproot you can have a script path as well, so you could have a
script:

A CHECKSIGVERIFY B CHECKSIG

and supply a partial signature:

R+X,s,X where s = r + H(R+X,A,m)*a

to allow them to satisfy "A CHECKSIGVERIFY" if they know the discrete
log of X, and of course they can sign with B at any time. This is only
half a round trip, and can be done at the same time as sending the "I
want to do a PTLC for X" message to setup the (ultimately cheaper) MuSig
spend. It's an extra signature on the sender's side and an extra verification
on the receiver's side, but I think it works out fine.

> Pointlocked Timelocked Contracts
> --------------------------------
> First, I will discuss how to create a certain kind of PTLCs, which I call "purely scriptless" PTLCs.
> In particular, I would like to point out that we *actually* use in current Poon-Dryja Lightning Network channels is *revocable* HTLCs, thus we need to have *revocable* PTLCs to replace them.
> * First, we must have a sender A, who is buying a secret scalar, and knows the point equivalent to that scalar.
> * Second, we have a receiver B, who knows this secret scalar (or can somehow learn this secret scalar).
> * A and B agree on the specifications of the PTLC: the point, the future absolute timelock, the value.
> * A creates (but *does not* sign or broadcast) a transaction that pays to a MuSig of A and B and shares the txid and output number with the relevant MuSig output.
> * A and B create a backout transaction.
> * This backout has an `nLockTime` equal to the agreed absolute timelock.
> * It spends the above MuSig output (this input must enable `nLockTime`, e.g. by setting `nSequence` to `0xFFFFFFFE`).
> * It creates an output that is solely controlled by A.
> * A and B perform a MuSig ritual to sign the backout transaction.
> * A now signs and broadcast the first transaction, the one that has an output that represents the PTLC.
> * A and B wait for the above transaction to confirm deeply.
> This completes the setup phase for the PTLC.
> * After this point, if the agreed-upon locktime is reached, A broadcasts the backout transaction and aborts the ritual.
> * A and B create a claim transaction.
> * This has an `nLockTime` of 0, or a present or past blockheight, or disabled `nLockTime`.
> * This spends the above MuSig output.
> * This creates an output that is solely controlled by B.
> * A and B generate an adaptor signature for the claim transaction, which reveals the agreed scalar.
> * This is almost entirely a MuSig ritual, except at `s` exchange, B provides `t + r + h(R | MuSig(A,B) | m) * MuSigTweak(A, B, B) * b` first, then demands `r + h(R | MuSig(A,B) | m) * MuSigTweak(A, B, A) * a` from A, then reveals `r + h(R | MuSig(A,B) | m) * MuSigTweak(A, B, B) * b` (or the completed signature, by publishing onchain), revealing the secret scalar `t` to A.
> * A is able to learn the secret scalar from the above adaptor signature followed by the full signature, completing the ritual.

(I think it makes more sense to provide "r + H(R+T, P, m)*b" instead of
"r+t + H(R,P,m)*b" -- you might not know "t" at the point you need to
start the signature exchange)

I think the setup can be similar to BOLT-3:

Funding TX output: MuSig(A,B)

Commitment Tx Held by A:
- locktime: obscured commitment number
- input: funding tx
- outputs:
balance A
balance B
PTLC paying to A
PTLC paying to B
[etc]

balance B can pay directly to B

balance A pays to MuSig(Rn,B) -- where Rn is the revocation key for the
nth commitment, and A holds a presigned tx by B with relative locktime
set, paying the funds to A.

PTLCs also pay to MuSig(Rn,B) --

for the one paying to A, A holds a tx
partially presigned by B that needs the point's discrete log added to x
with relative timelock; for the one paying to B, A holds a presigned tx
by B that has absolute locktime set and pays to MuSig(Rn,B) for which
A has another presigned tx by B that has relative locktime set.

HTLC's also pay to MuSig(Rn,B) but they're tweaked by a script -- if
they're paying to B, A just holds the same timelocked presigned tx's as
for PTLCs; if they're paying to A, A will use a "HASH160 X EQUALVERIFY
A CHECKSIGVERIFY delay CSV" script path instead.

B has a similar commitment Tx; and A holds pre-signed tx's for the
PTLC's there, except without the relative timelock txs.

This adds up to B needing to provide A with signatures for:

the funding tx
A's balance
each PTLC/HTLC paying/refunding to A from A's commitment and the sub tx for each of those
each PTLC/HTLC paying/refunding to B from B's commitment

and each of those signatures need to be updated every commitment update.

Note that you need to receive all the partial signatures to spend the
commitment tx before you provide your partial signature over the funding
tx to authorise the commitment tx. So yet more rounds of communication.

I think this approach would let you upgrade existing channels to support
PTLCs without closing/reopening, though.

I think you could do something eltoo-ish to simplify watchtowers:

Funding TX output: MuSig(A,B)

Commitment Tx Held by A:
- locktime: obscured commitment number
- inputs: funding tx
- outputs: MuSig(Rn,B)

Settlement Tx Held by A:
- nsequence: to_self_delay
- input: commitment tx held by A
- outputs:
balance A
balance B
PTLC paying to A
PTLC paying to B

Secondary Settlement Tx Held by B:
- no abs/relative locktime
- input: commitment tx held by A
- outputs:
balance A
balance B
PTLC paying to A
PTLC paying to B

in which case once the commitment is revoked, B only needs to do a single
signature of MuSig(Rn,B) to claim all the funds if A publishes the
old commitment, without having to worry about any HTLC/PTLC info? The
settlement tx can be a bit simplified I think too. Maybe the edge case
when the absolute locktime is close to the relative locktime makes this
painful, though I think it would make eltoo painful then too? Not sure
if I'm missing something here.

(Note that this gives symmetric delays: if A unilaterally closes the
channel by publishing the commitment tx, and B wants their funds, B can
either immediately claim all the funds via the revocation secret if A
was cheating, or has to publish the settlement tx first, at which point
A can get all A's funds immediately as well)

> Revocable Outputs and PTLCs
> ---------------------------
> * No wallet uses relative-timelock for ordinary spends, unlike abolute-locktime where Bitcoin Core always uses absolute-locktime `nLockTime` for ordinary spends.

I think the fact lightning relative timelocks will be "round" numbers,
and the timelocked tx will be published as soon as possible will make
it relatively easy to distinguish them from other spends anyway. Doing
it scriptlessly is cheaper on chain though.

Anyway, my picks are:

- [x] Poon-Dryja PTLCs prior to eltoo
- [x] scriptless revocation via MuSig(Rn,B) internal keys
- [x] support HTLCs via taproot
- [x] (optionally) allow use of script paths to minimise round trip
delay

Cheers,
aj

📅 Original date posted:2019-12-03 📝 Original message: On ...

2023-06-09T14:57:34+02:00

In reply to nevent1q…uthf
_________________________

📅 Original date posted:2019-12-03
📝 Original message:
On Tue, Nov 26, 2019 at 03:41:14PM -0800, Conner Fromknecht wrote:
> I recently revisited the eltoo paper and noticed some things related
> watchtowers that might affect channel construction.
> 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 don't believe that's necessary with the ANYPREVOUT design, see

https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-May/001996.html

The design I'm thinking of use a common taproot internal key
P=muSig(A,B) for update transactions. The tapscript paths are
(with the chaperone sigs dropped):

Update n: [nLockTime = 500e6+n]
script: OP_1 CHECKSIGVERIFY [500e6+n+1] CLTV
witness: [ANYPREVOUTANYSCRIPT sig]

Settlement n: [nSequence = delay; nLockTime=500e6+n+1]
witness: [ANYPREVOUT sig]

(This relies on having the two variants of ANYPREVOUT, one of which
commits to the state number via commiting to the [500e6+n+1] value in
the update tx's script, so that you don't need unique keys to ensure
settlement tx n can't spend settlement tx n+k)

With this you can tell which update was posted by subtracting 500e6 from
the nLocktime, and use that to calculate the tapscript the update tx used,
and the internal key is constant.

The watchtower only needs to post the update tx -- as long as the latest
update is posted, the only tx that can spend it is the correct settlement,
so you can post that whenever you're back online, even if that's weeks
or months later, and likewise for actually claiming your funds from the
settlement tx's outputs.

Cheers,
aj

📅 Original date posted:2019-11-08 📝 Original message: On ...

2023-06-09T14:57:07+02:00

In reply to nevent1q…5jg5
_________________________

📅 Original date posted:2019-11-08
📝 Original message:
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?

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)

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?

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...

Cheers,
aj

📅 Original date posted:2019-11-06 📝 Original message: On ...

2023-06-09T14:57:05+02:00

In reply to nevent1q…94u9
_________________________

📅 Original date posted:2019-11-06
📝 Original message:
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?

If you refund on routing failure, why wouldn't a spammer just add a fake
"Ezekiel" at the end of the route after Dave, so that the HTLCs always
fail and all the fees are returned?

> 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?

Are you using Hornet so that every intermediary can communicate a nonce
back to the source of the route? If not, "Rusty" generating the nonce
seems like you're informing Rusty that you're actually the origin of the
HTLC, and not just innocently forwarding it along; if so, it seems like
you have independent nonces at each step, rather than
AAAA/BBBB/LLLL/ZZZZ in a direct chain.

> > 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?

> > 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.

> 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.

> 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?

> > 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.

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.

Cheers,
aj

📅 Original date posted:2019-10-01 📝 Original message: On ...

2023-06-09T14:56:21+02:00

In reply to nevent1q…4xcn
_________________________

📅 Original date posted:2019-10-01
📝 Original message:
On Mon, Sep 30, 2019 at 11:28:43PM +0000, ZmnSCPxj via bitcoin-dev wrote:
> Suppose rather than `SIGHASH_NOINPUT`, we created a new opcode, `OP_CHECKSIG_WITHOUT_INPUT`.

I don't think there's any meaningful difference between making a new
opcode and making a new tapscript public key type; the difference is
just one of encoding:

3301<key>AC [CHECKSIG of public key type 0x01]
32<key>B3 [CHECKSIG_WITHOUT_INPUT (replacing NOP4) of key]

> This new opcode ignores any `SIGHASH` flags, if present, on a signature,

(How sighash flags are treated can be redefined by new public key types;
if that's not obvious already)

Cheers,
aj

📅 Original date posted:2019-09-25 📝 Original message: On ...

2023-06-09T14:56:13+02:00

In reply to nevent1q…w78q
_________________________

📅 Original date posted:2019-09-25
📝 Original message:
On Wed, Sep 25, 2019 at 01:30:39PM +0000, ZmnSCPxj wrote:
> > Since it's off chain, you could also provide R and C and a zero knowledge
> > proof that you know an r such that:
> > R = SHA256( r )
> > C = SHA256( x || r )

> > in which case you could do it with lightning as it exists today.
> I can insist on paying only if the server reveals an `r` that matches some known `R` such that `R = SHA256(r)`, as currently in Lightning network.
> However, how would I prove, knowing only `R` and `x`, and that there exists some `r` such that `R = SHA256(r)`, that `C = SHA256(x || r)`?

If you know x and r, you can generate C and R and a zero knowledge proof
of the relationship between x,C,R that doesn't reveal r (eg, I think
you could do that with bulletproofs). Unfortunately that zkp already
proves that C was generated based on x, so you get your timestamp for
free. Ooops. :(

Cheers,
aj

📅 Original date posted:2019-09-25 📝 Original message: On ...

2023-06-09T14:56:12+02:00

In reply to nevent1q…lgwd
_________________________

📅 Original date posted:2019-09-25
📝 Original message:
On Wed, Sep 25, 2019 at 11:01:28AM +0200, Konstantin Ketterer wrote:
> Motivation: If I had to timestamp multiple messages I could simply aggregate
> them in a merkle tree and pay relatively low fees per message. However, if I
> only need to timestamp something once in a while I need to rely on free
> services or pay high fees.

Maybe model the timestamping service as having fixed and floating users,
in which case the fixed users pay a subscription fee that covers the costs
and get placed relatively high in the merkle tree, while the floating
users are placed low in the merkle tree and are basically free money?

Your merkle tree might then have 2**N-1 fixed slots, all at height N,
then 2**K floating slots, all at height N+K, but you don't need to charge
the floating slots anything up front, because your fixed costs are all
paid for by subscription income from the fixed slots.

You might still want to charge some up front fee to prevent people
spamming you with things to timestamp that they're never going to pay
for though.

> Solution: buy a place in a merkle tree "risk-free"
> 1. send hash x of my message (or the merkle root of another tree) to the
> timstamping server
> 2. server calculates Pedersen commit: C = x*H + r*G, hashes it, builds merkle
> tree with other commits in it and publishes a valid transaction containing the
> merkle root to the Bitcoin blockchain
> 3. after a certain number of block confirmations and with the given proof I can
> confirm that the commitment C is indeed part of the Bitcoin blockchain
> 4. I now have to send a lightning payment with C - x*H = r*G as the payment
> point to the timestamping server and as a proof of payment the server must
> reveal r to receive the money.

Nice.

Since it's off chain, you could also provide R and C and a zero knowledge
proof that you know an r such that:

R = SHA256( r )
C = SHA256( x || r )

in which case you could do it with lightning as it exists today.

Cheers,
aj

📅 Original date posted:2019-03-18 📝 Original message: On ...

2023-06-09T14:54:28+02:00

In reply to nevent1q…hxhp
_________________________

📅 Original date posted:2019-03-18
📝 Original message:
On Thu, Mar 14, 2019 at 01:00:56PM +0100, Christian Decker wrote:
> Anthony Towns <aj at erisian.com.au> writes:
> > I'm thinking of tagged outputs as "taproot plus" (ie, plus noinput),
> > so if you used a tagged output, you could do everything normal taproot
> > address could, but also do noinput sigs for them.
> > So you might have:
> > funding tx -> cooperative claim
> > funding tx -> update 3 [TAGGED] -> settlement 3 -> claim
> > funding tx -> update 3 [TAGGED] ->
> > update 4 [TAGGED,NOINPUT] ->
> > settlement 4 [TAGGED,NOINPUT] ->
> > claim [NOINPUT]
> > In the cooperative case, no output tagging needed.
> I might be missing something here, but how do you bind update 3 to the
> funding tx output, when that output is not tagged? Do we keep each
> update in multiple separate states, one bound to the funding tx output
> and another signed with noinput?

I don't know that "separate states" is a great description -- until it
hits the blockchain "update N" is a template that can be filled out in a
variety of ways -- in the above the ways are:
- with a NOINPUT sig and a previous "update" tx as its input
- or with a SINGLE|ANYONECANPAY sig and the funding tx as input

The important thing is that approach means two sigs for each update tx.
The above also has two sigs for each settlement tx (and likewise two sigs
for each HTLC claim if using scriptless scripts) -- one using NOINPUT
in case multiple update tx's make it to the blockchain, and one assuming
everything works as expected that can just use direct key path spending.

I think you can do SINGLE,ANYCANPAY and combine multiple channel closures
if you're directly spending the funding tx, but can't do that if you're
using a NOINPUT sig, because the NOINPUT sig would commit to the tx's
locktime and different channel's states will generally have different
locktimes. You still probably want SINGLE,ANYCANPAY in that case so you
can bump fees though.

> If that's the case we just doubled our
> storage and communication requirements for very little gain.

There's three potential gains:
* it lets us make a safer version of NOINPUT
* it makes the common paths give fewer hints that you're using eltoo
* it puts less data/computation load on the blockchain

With tagged outputs your update tx already indicates you're maybe going
to use NOINPUT, so that probably already gives away that you're using
eltoo, so, at least with output tagging, the second benefit probably
doesn't exist. Using a key path spend (without a script) is probably
going to be cheaper on the blockchain though.

But while I think output tagging is probably better than nothing,
requiring a non-NOINPUT signature seems a better approach to me. With
that one, having a dedicated sig for the normal "publish the latest
state spending the funding tx" case, reduces a unilateral close to only
being special due to the settlement tx having a relative timelock, and
the various tx's using SINGLE|ANYCANPAY, which seems like a win. In that
scenario, just using a single sig is much cheaper than revealing a taproot
point, a pubkey or two, and using two sigs and a CLTV check of course.

It does goes from 1+n signatures per update today to 4+n signatures,
if you're using scriptless scripts. If you don't mind revealing the
HTLCs are HTLCs, and could do them with actual scripts, that reduces to
4 signatures. You could reduce it to 2 signatures by also always posting
"funding tx -> update 0 -> update N -> settlement N", or you could reduce
it to 2+2/k signatures by only doing the non-NOINPUT sigs for every k'th
state (or no more often than every t seconds or similar).

> An
> alternative is to add a trigger transaction that needs to be published
> in a unilateral case, but that'd increase our on-chain footprint.

(The above essentially uses update tx's as optional trigger tx's)

Also, I'd expect the extra latency introduced by the interactive signing
protocol for muSig would be more of a hit (share the nonce hash, share
the nonce, calculate the sig). Particularly if you're doing multiparty
channels with many participants, rather than just two.

Cheers,
aj

📅 Original date posted:2019-03-12 📝 Original message: Hi ...

2023-06-09T14:54:26+02:00

In reply to nevent1q…k2hy
_________________________

📅 Original date posted:2019-03-12
📝 Original message:
Hi all,

The following has some more thoughts on trying to make a NOINPUT
implementation as safe as possible for the Bitcoin ecosystem.

One interesting property of NOINPUT usage like in eltoo is that it
actually reintroduces the possibility of third-party malleability to
transactions -- ie, you publish transactions to the blockchain (tx A,
which is spent by tx B, which is spent by tx C), and someone can come
along and change A or B so that C is no longer valid). The way this works
is due to eltoo's use of NOINPUT to "skip intermediate states". If you
publish to the blockchain:

funding tx -> state 3 -> state 4[NOINPUT] -> state 5[NOINPUT] -> finish

then in the event of a reorg, state 4 could be dropped, state 5's
inputs adjusted to refer to state 3 instead (the sig remains valid
due to NOINPUT, so this can be done by anyone not just holders of some
private key), and finish would no longer be a valid tx (because the new
"state 5" tx has different inputs so a different txid, and finish uses
SIGHASH_ALL for the signature so committed to state 5's original txid).

There is a safety measure here though: if the "finish" transaction is
itself a NOINPUT tx, and has a a CSV delay (this is the case in eltoo;
the CSV delay is there to give time for a hypothetical state 6 to be
published), then the only way to have a problem is for some SIGHASH_ALL tx
that spends finish, and a reorg deeper than the CSV delay (so that state
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.

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.

2) your signature is applied to some transaction and works
perfectly; but then someone else sends money to the same address
and reuses your prior signature to forward it on to the same
destination, without your consent

I still like OP_MASK as a solution to (1), but I can't convince myself that
the problem it solves is particularly realistic; it doesn't apply to
address blacklists, because for OP_MASK to make the signature invalid
the address has to be different, and you could just short circuit the
whole thing by sending money from a blacklisted address to the target's
personal address directly. Further, if the sig's been seen on chain
before, that's probably good evidence that someone's messing with you;
and if it hasn't been seen on chain before, how is anyone going to tell
it's your sig to blame you for it?

I still wonder if there isn't a real problem hiding somewhere here,
but if so, I'm not seeing it.

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

* 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

That's not super likely to happen by chance: NOINPUT sigs will commit
to the value being spent, so to lose money, you (Alice) have to have
done a NOINPUT sig spending a coin sent to your address X, to someone
(Bob) and then have to have a coin with the exact same value sent from
someone else again (Carol) to your address X (or if you did a script
path NOINPUT spend, to some related address Y with a script that uses the same
key). But because it involves losing money to others, bad actors might
trick people into having it happen more often than chance (or well
written software) would normally allow.

That "nightmare" could be stopped at either the first step or the
last step:

* if we "tag" addresses that can be spent via NOINPUT then having an
exchange ban those addresses doesn't also impact regular
taproot/schnorr addresses, though it does mean you can tell when
someone is using a protocol like eltoo that might need to make use
of NOINPUT signatures. This way exchanges and wallets could simply
not provide NOINPUT capable addresses in the first place normally,
and issue very large warnings when asked to send money to one. That's
not a problem for eltoo, because all the NOINPUT-capable address eltoo
needs are internal parts of the protocol, and are spent automatically.

* or we could make it so NOINPUT signatures aren't replayable on
different transactions, at least by third parties. one way of doing
this might be to require NOINPUT signatures always be accompanied by a
non-NOINPUT signature (presumably for a different public key, or there
would be no point). This would prevent NOINPUT key-path spends, you'd
always have to use the taproot script-path for a NOINPUT signature so
that you could specify both public keys, and would also increase the
witness size due to needing two signatures and specifying an additional
public key -- this would increase the cost in fees by about 25% compared
to a plain key-path spend.

Conversely, this "nightmare" scenario *can't* be stopped if we allow
key-path spending of (untagged) taproot addresses with NOINPUT signatures:
exchanges could not distinguish such addresses from regular addresses, and
the only way to prevent the signature from applying to two tx's with the
same value and address would be for the sig to commit to info from the tx.

It seems like there's one big choice then:

- just ignore this concern

- drop NOINPUT from normal taproot key path spending

If we drop NOINPUT from taproot key path spending, then we can do NOINPUT
as a logically separate upgrade to taproot, rather than it needing to
be done at the same time. There's two ways we could do proceed:

- introduce a new NOINPUT-capable scriptPubKey format (ie, "tag"
NOINPUT spendable addresses); either a different length segwit v1
output, or a different segwit version entirely. Using version "16" in
this scenario might be appealing: we could reserve all v16 addresses
for "not intended to be used by humans directly" and update BIP 173
to say these aren't even something you should use bech32 to represent.

- alternatively, we could require every script to have a valid signature
that commits to the input. In that case, you could do eltoo with a
script like either:

<A> CHECKSIGVERIFY CHECKSIG
or CHECKSIGVERIFY <Q> CHECKSIG

where A is Alice's key and B is Bob's key, P is muSig(A,B) and Q is
a key they both know the private key for. In the first case, Alice
would give Bob a NOINPUT sig for the tx, and when Bob wanted to publish
Bob would just do a SIGHASH_ALL sig with his own key. In the second,
Alice and Bob would share partial NOINPUT sigs of the tx with P, and
finish that when they wanted to publish.

This is a bit more costly than a key path spend: you have to reveal
the taproot point to do a script (+33B) and you have two signatures
instead of one (+65B) and you have to reveal two keys as well
(+66B), plus some script overhead. If we did the <P,Q> variant,
we could provide a "PUSH_TAPROOT_KEY" opcode that would just push
the taproot key to stack, saving 33B from pushing P as a literal,
but you can't do much better than that. All in all, it'd be about 25%
overhead in order to prevent cheating. [0]

I think that output tagging doesn't provide a workable defense against the
third party malleability via a deeper-than-the-CSV-delay reorg mentioned
earlier; but requiring a non-NOINPUT sig does: you'd have to replace
the non-NOINPUT sig to make state 5 spend state 3 instead of state 4,
and only the holders of the appropriate private key can do that.

In any event, if we get some experience with NOINPUT in practice, we can
reconsider whether NOINPUT key path spends are a good idea when we do
the next segwit version -- both cross-input signature aggregation and
graftroot will need an upgrade anyway.

(Also, note that, at least for eltoo, all of the above only applies to
non-cooperative closes: the funding tx's txid is known from the start,
so you can always arrange to spend it via SIGHASH_ALL, so it doesn't
need to be tagged, and a cooperative/mutual close of the channel will
still just be a simple key path spend)

Anyway, presented for your consideration.

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

- 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

Cheers,
aj

📅 Original date posted:2019-03-13 📝 Original message: On ...

2023-06-09T14:54:26+02:00

In reply to nevent1q…edyk
_________________________

📅 Original date posted:2019-03-13
📝 Original message:
On Wed, Mar 13, 2019 at 06:41:47AM +0000, ZmnSCPxj via Lightning-dev wrote:
> > - alternatively, we could require every script to have a valid signature
> > that commits to the input. In that case, you could do eltoo with a
> > script like either:
> > <A> CHECKSIGVERIFY CHECKSIG
> > or CHECKSIGVERIFY <Q> CHECKSIG
> > where A is Alice's key and B is Bob's key, P is muSig(A,B) and Q is
> > a key they both know the private key for. In the first case, Alice
> > would give Bob a NOINPUT sig for the tx, and when Bob wanted to publish
> > Bob would just do a SIGHASH_ALL sig with his own key. In the second,
> > Alice and Bob would share partial NOINPUT sigs of the tx with P, and
> > finish that when they wanted to publish.
> At my point of view, if a NONINPUT sig is restricted and cannot be
> used to spend an "ordinary" 2-of-2, this is output tagging regardless
> of exact mechanism.

With taproot, you could always do the 2-of-2 spend without revealing a
script at all, let alone that it was meant to be NOINPUT capable. The
setup I'm thinking of in this scenario is something like:

0) my key is A, your key is B, we want to setup an eltoo channel

1) post a funding tx to the blockchain, spending money to an address
P = muSig(A,B)

2) we cycle through a bunch of states from 0..N, with "0" being the
refund state we establish before publishing the funding tx to
the blockchain. each state essentially has two corresponding tx's,
and update tx and a settlement tx.

3) the update tx for state k spends to an output Qk which is a
taproot address Qk = P + H(P,Sk)*G where Sk is the eltoo ratchet
condition:
Sk = (5e8+k+1) CLTV A CHECKDLS_NOINPUT B CHECKDLS_NOINPUT_VERIFY

we establish two partial signatures for update state k, one which
is a partial signature spending the funding tx with key P and
SIGHASH_ALL, the other is a NOINPUT signature via A (for you) and
via B (for me) with locktime set to (k+5e8), so that we can spend
any earlier state's update tx's, but not itself or any later
state's update tx's.

4) for each state we have also have a settlement transaction,
Sk, which spends update tx k, to outputs corresponding to the state
of the channel, after a relative timelock delay.

we have two partial signatures for this transaction too, one with
SIGHASH_ALL assuming that we directly spent the funding tx with
update state k (so the input txid is known), via the key path with
key Qk; the other SIGHASH_NOINPUT via the Sk path. both partially
signed tx's have nSequence set to the required relative timelock
delay.

5) if you're using scriptless scripts to do HTLCs, you'll need to
allow for NOINPUT sigs when claiming funds as well (and update
the partial signatures for the non-NOINPUT cases if you want to
maximise privacy), which is a bit fiddly

6) when closing the channel the process is then:

- if you're in contact with the other party, negotiate a new
key path spend of the funding tx, publish it, and you're done.

- otherwise, if the funding tx hasn't been spent, post the latest
update tx you know about, using the "spend the funding tx via
key path" partial signature

- otherwise, trace the children of the funding tx, so you can see
the most recent published state:
- if that's newer than the latest state you know about, your
info is out of date (restored from an old backup?), and you
have to wait for your counterparty to post the settlement tx
- if it's equal to the latest state you know about, wait
- if it's older than the latest state, post the latest update
tx (via the NOINPUT script path sig), and wait

- once the CSV delay for the latest update tx has expired, post
the corresponding settlement tx (key path if the update tx
spent the funding tx, NOINPUT if the update tx spent an earlier
update tx)

- once the settlement tx is posted, claim your funds

So the cases look like:

mutual close:
funding tx -> claimed funds

-- only see one key via muSig, single signature, SIGHASH_ALL
-- if there are active HTLCs when closing the channel, and they
timeout, then the claiming tx will likely be one-in, one-out,
SIGHASH_ALL, with a locktime, which may be unusual enough to
indicate a lightning channel.

unilateral close, no cheating:
funding tx -> update N -> settlement N -> claimed funds

-- update N is probably SINGLE|ANYONECANPAY, so chain analysis
of accompanying inputs might reveal who closed the channel
-- settlement N has relative timelock
-- claimed funds may have timelocks if they claim active HTLCs via
the refund path
-- no NOINPUT signatures needed, and all signatures use the key path
so don't reveal any scripts

unilateral close, attempted cheating:
funding tx -> update K -> update N -> settlement N -> claimed funds

-- update K, update N are probably SINGLE|ANYONECANPAY, so chain
analysis might reveal the identity of both sides of the channel
-- update N and settlement N both use NOINPUT signatures and
reveal CLTV script that looks like eltoo
-- update N has timelock set
-- settlement N has a relative timelock
-- claimed funds may have timelocks if they claim active HTLCs via
the refund path

Notes:
* cheating isn't 100% accurate: could be due to someone having to
restore from an old backup

* you could end up with:

funding tx -> update K -> update W -> update N
-> settlement N -> claimed funds

if someone restored from an old backup and posted K, a watchtower
had a newer but not current state W, and finally you posted
state N directly. with multiple watchtowers you might have more
intermediate states' update tx's posted. afaics it has similar
privacy results to the 2-update-tx case.

> So the restriction to add a non-NOINPUT sig in addition to a NOINPUT sig is still output tagging, as a cooperative close would still reveal that the output is not a 2-of-2.

With the above setup, you don't discover that NOINPUT was possible unless it
is actually needed because someone cheated.

As long as you're using muSig key path spending for a cooperative close,
you're not even revealing the output is 2-of-2, let alone a weird
2-of-2 variant.

> Ideally, historical data of whether onchain coin was used in Lightning or not should be revealed as little as possible.
> So in a cooperative close (which we hope, to be a common case), ideally the spend should look no different from an ordinary 2-of-2 spend.

With taproot, the goal is it shouldn't look different from an ordinary
"pay to public key" spend, and I think that's pretty achievable.

> Of course if the channel is published on Lightning, those who participated in Lightning at the time will learn of it, but at least the effort to remember this information is on those who want to remember this fact.

Well, presumaby lightning will continue to support private channels that
don't get published, and the concern's definitely valid for them!

> Now, this can be worked around by adding a "kickoff" transaction that spends the eltoo setup transaction.
> The eltoo setup transaction outputs to an ordinary 2-of-2.
> The kickoff outputs to an output that allows NOINPUT.
> Then the rest of the protocol anchors on top of the kickoff.
> [...]

I think this is possible too, but I think the scheme I describe above
is superior: iit means calculating a few more signatures each update,
but keeps more information off chain, which is better for privacy, and
probably cheaper (unless you have very high-frequency channel updates?).

Cheers,
aj

📅 Original date posted:2018-11-16 📝 Original message: On ...

2023-06-09T14:52:44+02:00

In reply to nevent1q…9vys
_________________________

📅 Original date posted:2018-11-16
📝 Original message:
On Thu, Nov 15, 2018 at 11:54:22PM +0000, ZmnSCPxj via Lightning-dev wrote:
> The improvement is in a reduction in `fee_base_msat` in the C->D path.

I think reliability (and simplicity!) are the biggest things to improve
in lightning atm. Having the flag just be incuded in invoices and not
need to be gossiped seems simpler to me; and I think endpoint-only
merging is better for reliability too. Eg, if you find candidate routes:

A -> B -> M -- actual directed capacity $6
A -> C -> M -- actual directed capacity $5.50
M -> E -> F -- actual directed capacity $6
A -> X -> F -- actual directed capacity $7

and want to send $9 form A to F, you might start by trying to send
$5 via B and $4 via C.

With endpoint-only merging you'd do:

$5 via A,B,M,E,F -- partial success
$4 via A,C,M,E -- failure
$4 via A,X,F -- payment completion

whereas with in-route merging, you'd do:

$5 via A,B,M -- held
$4 via A,C,M -- to be continued
$9 via M,E -- both partial payments fail

which seems a fair bit harder to incrementally recover from.

> Granted, current `fee_base_msat` across the network is very low currently.
> So I do not object to restricting merge points to ultimate payees.
> If fees rise later, we can revisit this.

So, while we already agree on the approach to take, I think the above
provides an additional rationale :)

Cheers,
aj

📅 Original date posted:2018-11-05 📝 Original message: On ...

2023-06-09T14:52:06+02:00

In reply to nevent1q…32tp
_________________________

📅 Original date posted:2018-11-05
📝 Original message:
On Mon, Nov 05, 2018 at 01:05:17AM +0000, ZmnSCPxj via Lightning-dev wrote:
> > 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.

Interesting. I think what you're saying is that with secp256k1 preimages
(with decorrelation), if you have the payment hash Q, then the payment
preimage q (Q=q*G) is only known to the payee and the payer (and not
any intermediaries thanks to decorrelation), so if you see a statement

m="This invoice has been paid but not delivered as at 2018-11-05"

signed by "Q" (so, some s,R s.t. s*G = R + H(Q,R,m)*Q) then that means
either the payee signed it, in which case there's no dispute, or the
payer signed it... And that's publicly verifiable with only the original
invoice information (ie "Q").

(I don't think there's any need for multiple rounds of signatures)

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". (And if we both agree that it did or didn't
arrive, there's no need to post cryptographic proofs to reddit afaics)

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)

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

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

Cheers,
aj

📅 Original date posted:2018-11-04 📝 Original message: On ...

2023-06-09T14:52:04+02:00

In reply to nevent1q…x4un
_________________________

📅 Original date posted:2018-11-04
📝 Original message:
On Sun, Nov 04, 2018 at 01:30:48PM +1030, Rusty Russell wrote:
> 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.

(Note this means the "invoice" must be unique for each payment)

> > 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.

So that's totally fine to do however you receive the "s" value -- the
message that's getting the Schnorr signature isn't a valid bitcoin
transaction, so it's something that only needs to be validated by
BOLT-aware courts.

I also think you can get recurrent payments easily by extending the
verification algorithm. Basically instead of Verify(m,P,sig) have
Verify(m,P,n,sig) to verify you've made n payments of the invoice "m".

Construct "m" to include the postimage X = H(pre,1000) which indicates
"pre" has been hashed 1000 times, so X = H(H(pre,1000-n),n).

Calculate the original signature as:

s = r + H(P,R,m+X)*p

and verify that n payments have been made by checking:

Verify(m,P,n,(s,R,rcpt)) :: s*G = R + H(P,R,m+H(rcpt,n))*P

You'd provide s,R,X when setting up the subscription, then reveal the
preimage to X, the preimage to the preimage of X etc on each payment.
(Maybe shachain would work here?)

I think that approach is independent of using sha256/secp256k1 for
preimages over lightning too.

> 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

R is already a unique nonce under the hash here, so I don't think a
second one adds any value fwiw.

> > 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.

I'm looking at it as needing interactivity to determine m prior to
the payment going through -- the payer needs to send through "aj" and
"Australia" in the example above, before the payee can generate s,R to
send back, at which point the payer can make the payment knowing they'll
either get a cryptographic proof of payment or a refund.

> 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" ?

> 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? :)

> > 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 :)

Yay!

> > 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.

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.

> > - 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

where "secret" is your xor of info from each of the three message hashes.

> > 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.

> 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...

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?

Cheers,
aj

📅 Original date posted:2018-11-03 📝 Original message: On ...

2023-06-09T14:52:02+02:00

In reply to nevent1q…pffv
_________________________

📅 Original date posted:2018-11-03
📝 Original message:
On Fri, Nov 02, 2018 at 03:45:58PM +1030, Rusty Russell wrote:
> 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.

"every intermediary" just means "you have to find a path where every
channel supports it"; nodes/channels that aren't in the route you choose
aren't a problem, and can still pass on the gossiped announcements,
I think?

> > 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.

Yeah, that sounds workable.

> > - 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.

It's also (theoretically) upgradable afaics: if two nodes have a channel
that supports 2p-ecdsa, and eventually both upgrade to support segwit
v1 scriptless schnorr sigs or whatever, they just need to change the
addresses they use in new commitment txs, even for existing HTLCs.

> > 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 :)

AFAICT, in general, if you're going to have n signatures with a public
key P, you need to generate the n R=r*G values from n*32B worth of random data,
that's previously unknown to the signature recipients. If you've got
less than that, then you will have calculated each R by doing something
like based on <n*32B of data you've been given:

R = a*R1 + b*R2 + ..

and the n signatures you eventually receive will give you n simultaneous
linear equations along the lines of:

s = (a*r1 + b*r2 + c*r3 + ..) + H(..)*p

with <= n unknowns (p and less than n r1,r2,.. values). (If you don't
known the values a,b,c you won't be able to calculate the R values for
your signatures in the first place)

Willing to be surprised by a different approach, but I'm pretty
skeptical...

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.

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.

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.

AMP:

> 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).

Hmm, right, I've got decorrelation and AMP combined in my head. I'm also
a bit confused about what exactly you mean by "low-AMP"...

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...

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

- 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

- 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

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?

Cheers,
aj

📅 Original date posted:2018-07-18 📝 Original message: ...

2023-06-09T14:51:10+02:00

In reply to nevent1q…v8ll
_________________________

📅 Original date posted:2018-07-18
📝 Original message:
(bitcoin-dev dropped from cc)

On Mon, Apr 30, 2018 at 05:41:38PM +0200, Christian Decker wrote:
> eltoo is a drop-in replacement for the penalty based invalidation
> mechanism that is used today in the Lightning specification. [...]

I think you can simplify eltoo further, both in the way the transactions
work and in the game theory ensuring people play fair.

In essence: rather than having a funding transaction spending to address
"X", and a set of ratcheting states that spend from-and-to the same
address "X", I think it's feasible to have a simpler ratchet mechanism:

(1) funding address: multisig by A and B as usual

(2) commit to state >=N by A

(3a) commit to state N by A after delay D; or
(3b) commit to state M (M>=N) by B

I believe those transactions (while partially signed, before posting to
the blockchain) would look like:

(1) pay to "2 A1 B1 2 OP_CHECKMULTISIG"

(2) signed by B1, nlocktime set to (N+E)
pay to "(N+E) OP_CLTV OP_DROP 2 A2a B2a 2 OP_CHECKMULTISIG"

(3a) signed by B2a, nSequence set to the channel pay to self delay,
nlocktime set to (N+E)
pays to the channel balances / HTLCs, with no delays or
revocation clauses

(3b) signed by A2a with SIGHASH_NOINPUT_UNSAFE, nlocktime set to (M+E)
pays to the channel balances / HTLCs, with no delays or
revocation clauses

You spend (2)+delay+(3a)+[claim balance/HTLC] if your counterparty
goes away. You spend (2) and your counterparty spends (3b) if you're
both monitoring the blockchain. (3a) and (3b) should have the same tx
size, fee rate and outputs.

(A1, A2a are keys held by A; B1, B2a are keys held by B; E is
LOCKTIME_THRESHOLD; N is the current state number)

That seems like it has a few nice features:

- txes at (3a) and (3b) can both pay current market fees with minimal
risk, and can be CPFPed by a tx spending your own channel balance

- txes at (2) can pay a non-zero fee, provided it's constant for the
lifetime of the channel (to conform with the NOINPUT rules)

- if both parties are monitoring the blockchain, then the channel
can be fully closed in a single block, by (2)+(3b)+[balance/HTLC
claims], and the later txes can do CPFP for tx (2).

- both parties can claim their funds as soon as the other can, no
matter who initiates the close

- you only need 3 pre-signed txes for the current state; the txes
for claiming HTLCs/balances don't need to be half-signed (unless
you're doing them via schnorr scriptless scripts etc)

The game theory looks fine to me. If you're posting transaction (2), then
you can choose between a final state F, paying you f and your counterparty
b-f, or some earlier state N, paying you n, and your counterparty b-n. If
f>n, it makes sense for you to choose F, in which case your counterparty
is also forced to choose state F for (3b) and you're forced to choose F
for (3a). If n>f, then if you choose N, your counterparty will either
choose state F because b-f>b-n and you will receive f as before, or
will choose some other state M>N, where b-m>b-f, and you will receive
m<f<n, which is a worse result. So the rational strategy seems to me
to be to choose either F all the time, or at worst an earlier state N
where every payment since then went from you towards your counterparty,
on the off-chance they're not watching the blockchain and you can get
that money back.

Note that unlike eltoo, dealing with attempted cheating in this scenario
has no extra cost over a completely fair/honest close. Always attempting
to cheat by trying to reclaim the last few payments if they were towards
your counterparty might help ensure implementations handle cheating well?

> eltoo addresses some of the issues we encountered while speficying and
> implementing the Lightning Network. For example outsourcing becomes very
> simple since old states becoming public can't hurt us anymore.

The scheme above isn't great for (untrusted) outsourcing, because if
you reveal enough for an adversary to post tx (3b) for state N, then
they can then collaborate with your channel counterparty to roll you
back from state N+1000 back to state N.

With eltoo if they do the same, then you have the opportunity to catch
them at it, and play state N+1000 to the blockchain -- but if you're
monitoring the blockchain carefully enough to catch that, why are you
outsourcing in the first place? If you're relying on multiple outsourcers
to keep each other honest, then I think you run into challenges paying
them to publish the txes for you.

Thoughts? Apart from still requiring NOINPUT and not working with
adversarial outsourcing, this seems like it works nicely to me, but
maybe I missed something...

Cheers,
aj

📅 Original date posted:2018-05-14 📝 Original message: On ...

2023-06-09T14:50:36+02:00

In reply to nevent1q…yqf3
_________________________

📅 Original date posted:2018-05-14
📝 Original message:
On Thu, May 10, 2018 at 08:34:58AM +0930, Rusty Russell wrote:
> > 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.

So, I don't find that very compelling: "there's already a way to lose
your money, so it's fine to add other ways to lose your money". And
again, I think NOINPUT is worse here, because a SIGHASH_NONE signature
only lets others take the coin you're trying to spend, messing up when
using NOINPUT can cause you to lose other coins as well (with caveats).

> [...]
> In a world where SIGHASH_NONE didn't exist, this might be an argument :)

I could see either dropping support for SIGHASH_NONE for segwit
v1 addresses, or possibly limiting SIGHASH_NONE in a similar way to
limiting SIGHASH_NOINPUT. Has anyone dug through the blockchain to see
if SIGHASH_NONE is actually used/useful?

> 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.

Taproot and graftroot aren't "less script" at all -- if anything they're
the opposite in that suddenly every address can have a script path.
I think NOINPUT has pretty much the same tradeoffs as taproot/graftroot
scripts: in the normal case for both you just use a SIGHASH_ALL
signature to spend your funds; in the abnormal case for NOINPUT, you use
a SIGHASH_NOINPUT (multi)sig for unilateral eltoo closes or watchtower
penalties, in the abnormal case for taproot/graftroot you use a script.

> That means we'd actually want a different Segwit version for
> "NOINPUT-can-be-used", which seems super ugly.

That's backwards. If you introduce a new opcode, you can use the existing
segwit version, rather than needing segwit v1. You certainly don't need
v1 segwit for regular coins and v2 segwit for NOINPUT coins, if that's
where you were going?

For segwit v0, that would mean your addresses for a key "X", might be:

[pubkey] X
- not usable with NOINPUT
[script] 2 X Y 2 CHECKMULTISIG
- not usable with NOINPUT
[script] 2 X Y 2 CHECKMULTISIG_1USE_VERIFY
- usable with NOINPUT (or SIGHASH_ALL)

CHECKMULTISIG_1USE_VERIFY being soft-forked in by replacing an OP_NOP,
of course. Any output spendable via a NOINPUT signature would then have
had to have been deliberately created as being spendable by NOINPUT.

For a new segwit version with taproot that likewise includes an opcode,
that might be:

[taproot] X
- not usable with NOINPUT
[taproot] X or: X CHECKSIG_1USE
- usable with NOINPUT

If you had two UTXOs (with the same value), then if you construct
a taproot witness script for the latter address it will look like:

X [X CHECKSIG_1USE] [sig_X_NOINPUT]

and that signature can't be used for addresses that were just intending
to pay to X, because the NOINPUT sig/sighash simply isn't supported
without a taproot path that includes the CHECKSIG_1USE opcode.

In essence, with the above construction there's two sorts of addresses
you generate from a public key X: addresses where you spend each coin
individually, and different addresses where you spend the wallet of
coins with that public key (and value) at once; and that remains the
same even if you use a single key for both.

I think it's slightly more reasonable to worry about signing with NOINPUT
compared to signing with SIGHASH_NONE: you could pretty reasonably setup
your (light) bitcoin wallet to not be able to sign (or verify) with
SIGHASH_NONE ever; but if you want to use lightning v2, it seems pretty
likely your wallet will be signing things with SIGHASH_NOINPUT. From
there, it's a matter of having a bug or a mistake cause you to
cross-contaminate keys into your lightning subsystem, and not be
sufficiently protected by other measures (eg, muSig versus checkmultisig).

(For me the Debian ssh key generation bug from a decade ago is sufficient
evidence that people you'd think are smart and competent do make really
stupid mistakes in real life; so defense in depth here makes sense even
though you'd have to do really stupid things to get a benefit from it)

The other benefit of a separate opcode is support can be soft-forked in
independently of a new segwit version (either earlier or later).

I don't think the code has to be much more complicated with a separate
opcode; passing an extra flag to TransactionSignatureChecker::CheckSig()
is probably close to enough. Some sort of flag remains needed anyway
since v0 and pre-segwit signatures won't support NOINPUT.

Cheers,
aj

📅 Original date posted:2015-11-27 📝 Original message: On ...

2023-06-09T14:45:18+02:00

In reply to nevent1q…4wgg
_________________________

📅 Original date posted:2015-11-27
📝 Original message:
On Fri, Nov 27, 2015 at 04:37:04PM +0900, Nicolas Dorier wrote:
> By adapting an idea from gmaxwell (
> https://bitcointalk.org/index.php?topic=303088.0) it is possible to open a
> channel without suffering from malleability attack.
> The process for A to open channel with B is the following:
> * A asks B pubkey
> * A create the first commitment transaction
> * A extract the hash that B needs to sign to be able to broadcast the
> commitment
> * A asks B to sign the hash, but do not disclose the commitment
> * A broadcast the anchor
> * After confirmation, A announce the anchor to B.

A also passes the original unsigned commitment to B, who verifies that
it's in the right format (ie, can be revoked), and hashes to the hash
that he signed.

> B can't identify A's anchor before announcement because he does not know
> the P2SH of the multisig.
> Am I missing something ?

Someone other than B (ie a third party) could malleate the anchor between
broadcast and confirmation just for their own amusement.

B can't reuse pubkeys between different channels with this protocol
either, but that's good practice anyway.

>From the same forum post, using child-pays-for-parent seems plausible.
Doing:

txA: spend 6 BTC to
5 BTC to A&B
1 BTC to A

txB: spend 1 BTC from txA:1 to
0.999 BTC to A

should be pretty safe: either someone malleates txA and mines it for
0 fee; or they mine both txA+txB for 0.001 BTC fee, and txA can't be
malleated. But CPFP doesn't work yet, and segregated witness seems like
it'll happen sooner anyway?

Cheers,
aj

📅 Original date posted:2015-11-27 📝 Original message: On ...

2023-06-09T14:45:17+02:00

In reply to nevent1q…qcra
_________________________

📅 Original date posted:2015-11-27
📝 Original message:
On Fri, Nov 27, 2015 at 07:14:54AM +0100, Mats Jerratsch wrote:
> Another way to deal with it is to add two HTLCs to the commit, basically
> 'I pay you 1.00000001 BTC and you pay me 1 BTC, so effectively I paid
> you 1 satoshi'.

True! Doubles the cost of the HTLC if it gets published to the
blockchain though...

> One issue with this is that it increases the fees by a lot, as the
> locked up capital increases by quite a lot. It might also not
> translate that well over many hops, when fees are different in each
> direction.

I don't think number of hops matters; it only affects each channel
directly (so hop1 pays a+b one way, and b the other way; hop2 pays
a-f+c one way, c the other way; etc), a as the transaction amount,
f as b's fee, b and c arbitrary channel parameters for a/b and b/c
channels respectively.

You only have to lock up a little more than the dust amount, so call that
1c per HTLC, assume a locktime of 20 days, and a time cost of bitcoin
of 20% pa, then that's an extra cost of 0.01 of a cent per transaction.
If you're aiming for a 1% per-hop fee, you can still handle transactions
worth about a cent with that approach. If you've got a time cost of
bitcoin at about 5% pa and a lock time of 10 days, you can do a 2c
transaction with a per-hop fee of about 0.1%.

> We might want to have some special protocol for these
> payments?

I don't think that helps?

> By the way, as far as I know the dust value got increased to 5430? So
> even more of a problem for us now... (wow, that's already 2ct, don't
> think we can just disallow these, given that we promised the holy
> grail of micro payments ;) )

I don't think so? minrelayfee got increased to .05 mBTC, but that's for
1000 bytes while the dust threshold is for 546 bytes, so that's 2730
satoshi (a little under 1c at $351 USD/BTC).

According to Visa, anything less than $20 is a micropayment though, so
there's still plenty of leeway ;)

http://www.techworld.com.au/article/351015/visa_payclick_takes_paypal_micropayments/

> I also don't think just adding these to the change amount is
> sustainable. That's a thing I realized some time ago, as soon as there
> is some loop hole somewhere, there will be one guy who will move
> heaven and earth to make a profit off of it.

Yeah, and with onion routing and so on, I could be that guy!!

If you anonymously setup two channels with another node, and route a whole
bunch of dust payments to yourself, ie me1 -> them -> me2, then:

- if the HTLCs are in both txns, you can't do anything

- if the second channel's commitment unconditionally pays you for a
bunch of transactions, close the channel, and never reveal any of
the secrets. you eventually get all your money back in me1, and made
a profit in me2.

- if the first channel's commitment doesn't debit you for a bunch
of transactions, reveal the corresponding secrets in the second
channel, updating its commitment, but refuse to follow protocol to
update the transactions in the first channel, closing it, but keeping
your money.

- if txns in the second channel are credited to fees, but have HTLCs
in the first channel; close the second channel, and the txns timeout,
refunding your money, but costing the other node the sum of those
HTLCs.

Yay, more problems!

Maybe you could tweak the dual HTLC approach to make attacks unattractive:

42 satoshi from A -> B

10042 satoshi for (B && R || A && 20days CLTV)
10000 satoshi for (A && R && 15 days CLTV || B && 20days CLTV)

If it resolves on channel, fine; but if it hits the blockchain, A has to
wait 15 days even if R gets revealed to get her 3.5c back.

Not actually sure if that does any real good though...

Cheers,
aj

> 2015-11-27 4:58 GMT+01:00 Rusty Russell <rusty at rustcorp.com.au>:
> > 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.

📅 Original date posted:2015-11-27 📝 Original message: Hey, ...

2023-06-09T14:45:16+02:00

In reply to nevent1q…utgt
_________________________

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

The important thing is that adding dust to your commitment might mean you
can't access _any_ of your funds if your channel counterparty goes AWOL.
Even though the amount mightn't matter, you can't just treat it like
any other case in the code.

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.

Cheers,
aj

📅 Original date posted:2015-11-17 📝 Original message: Hi ...

2023-06-09T14:45:02+02:00

In reply to nevent1q…ldde
_________________________

📅 Original date posted:2015-11-17
📝 Original message:
Hi all,

An obvious privacy limitation with lightning is that even with onion
routing, differents hops can be associated as being part of the same
transaction due to sharing a common R value. So if you see a HTLC from
Alice to Bob, paying $5 to Bob on receipt of R where SHA(R)=12345..;
and you see another HTLC from Carol to Dave, paying $4.95 to Bob on
receipt of R under the same condition, SHA(R)=12345..., then you know
it's part of the same transaction.

If you could change R at each step in the route, this would go away,
improving payment anonymity and making it harder to attack the system in
general.

That's hard, because as a forwarding node, if you receive a HTLC payable
on R1, then to send a HTLC payable on R2, you need to be able to
calculate R1 from R2 or you'll be out of pocket. But you also can't be
able to calculate R1 *without* R2, or you could just rip off whoever's
making the payment. And, of course you have to know SHA(R2) to forward the
payment at all. And if you only know SHA(R1) and SHA(R2) it's hard to
say anything at all about R1 and R2 because cryptographic hash functions
are designed to make any structural relationships go away.

BUT! I think the magic of SNARKs [0] lets you do this!

With a SNARK, you can "prove" that you have some secrets (ie, R1 and R2)
that satisfy some programmable condition (ie, SHA(R1)=H1 and SHA(R2)=H2
and R1=R2 XOR X), based on public inputs (H1, H2 and X), without revealing
those secrets.

I think that's pretty safe, because if you receive an HTLC asking for a
preimage for H1, along with instructions in the onion saying ask Bob for
a preimage for H2, and here's X and a proof, then either:

- your forwarded HTLC will fail, and everything's fine

- you'll receive R2, calculate R1=R2 XOR X and see SHA(R1)=H1 as
expected, and everything's fine

- you'll receive R2, calculate R1=R2 XOR X and see SHA(R1) != H1,
which is only possible if the cryptography behind SNARKs are broken

- you'll receive RX, such that H2=SHA(RX) but RX being too
long or too short. If SNARKs aren't broken, this means that you know
R2alt and someone else knows R2 that are different but hash to the
same value, meaning SHA has been broken.

It seems like there are research-level tools out there that actually
make this practical to try out. I've had a go at implementing this using
snarkfront [1]. Using it looks like:

1) initial setup of proof/verification keys

$ ./test_lightning -m keygen > keygen.txt # global setup

2) generate a proof, using a 32 byte secret, and XOR key (64 hex digits)

$ SECRET="the quick brown fox jumps lazily"
$ XOR=$(echo "she sells sea shells" | sha256sum | head -c64)
$ cat keygen.txt |
./test_lightning -m proof -s "$SECRET" -x "$XOR" > proof.txt
m: proof.
f: .
b: .
x: 5677d356ccd6ff29b296a697791d109a1703557ecbbcf52b4f38d4b680858912.
F: 74686520717569636b2062726f776e20666f78206a756d7073206c617a696c79
B: 221fb676bda3964ad9b6c4e5166a7eba716c2d5ea1c9985b3c18b8d7faece56b
#F: ae4d48f71fdb6f74149fab591e88f2cc07d4e696968def1aa7ca1e07096c5b85
#B: 166e4f9b8ec5895e870f0f0508327d73ba9ad9af4e9841599bafb1bf55c8a245
generate proof
(6) ..................................................
(5) ..................................................
(4) ..................................................
(3) ..................................................
(2) ..................................................
(1) ..................................................

3) Verify the proof:

$ F=ae4d48f71fdb6f74149fab591e88f2cc07d4e696968def1aa7ca1e07096c5b85
$ B=166e4f9b8ec5895e870f0f0508327d73ba9ad9af4e9841599bafb1bf55c8a245
$ cat keygen.txt proof.txt |
./test_lightning -m verify -h "$F" -b "$B" -x "$XOR"
m: verify.
f: ae4d48f71fdb6f74149fab591e88f2cc07d4e696968def1aa7ca1e07096c5b85.
b: 166e4f9b8ec5895e870f0f0508327d73ba9ad9af4e9841599bafb1bf55c8a245.
x: 5677d356ccd6ff29b296a697791d109a1703557ecbbcf52b4f38d4b680858912.
verify proof (6) (5) (4) (3) (2) (1)
proof is verified

4) Verify it doesn't report a valid proof with different inputs:

$ cat keygen.txt proof.txt |
./test_lightning -m verify -h "$B" -b "$F" -x "$XOR"
m: verify.
f: 166e4f9b8ec5895e870f0f0508327d73ba9ad9af4e9841599bafb1bf55c8a245.
b: ae4d48f71fdb6f74149fab591e88f2cc07d4e696968def1aa7ca1e07096c5b85.
x: 5677d356ccd6ff29b296a697791d109a1703557ecbbcf52b4f38d4b680858912.
verify proof (6) (5) (4) (3) (2)
proof is rejected

Some results:

* the proof/verification key data take up about 100MB -- in theory
one set of this data can be used by everyone; the only catch is
that everyone has to trust that nobody has kept the original random
numbers used to generate it.

* proof/verification key data takes about a minute to generate,
and about 650MB of RAM.

* the proof data itself (which would need to be sent to the node that's
going to switch R's) is just 864 bytes; so it'd use up about 5 hops
worth of onion routing at 192B per hop -- in a 4096 byte packet eg,
you could have four hops, changing R each time; or you could have 9
hops, changing R only three times.

* generating the proof data for a given R1,X pair takes about 10
seconds, and 260MB of RAM

* verifying the proof is quick-ish -- it takes 0.5s on my laptop,
and uses about 150MB of RAM.

For comparison, that last point makes a SNARK verification 500+ times
more expensive than an ECDH operation. If I got my maths right, you
can translate 3c for a linode CPU-hour into 2.5 satoshi for a linode
CPU-second (at $338/BTC), so you're probably looking at a minimum fee
of a few satoshi per SNARK verification, but that's still pretty okay
for transactions of 500 satoshi or more, ie anything more than about a
fifth of a US cent.

The 10s proof generation time is probably more of a limitation -- though
you could generate them in advance easily enough and just store them until
you need to use them, which would avoid lag being a problem at least. But
even then it's still essentially adding up to 30c of additional costs to
your transaction (ie 10s cpu time valued at up to 3c/s), which probably
isn't worthwhile for transactions smaller than a dollar or two.

A drawback is that you'd either (a) have to do all this on the merchant's
side (not just sending SHA(R) to whoever wants to pay you, but sending
SHA(R1), SHA(R2), SHA(R3), SHA(R4), X12, X23, X34, and three proofs,
which would be pretty painful; or (b) you'd have to generate all the
R secrets as a consumer, and you wouldn't get to use the fact that you
know R as evidence that you paid the merchant.

Anyway, it's obviously not ready for prime time today: SNARKs are still
pretty new as a concept; I'm definitely not familiar enough with SNARK
theory to be sure I'm not misusing the concept somehow; snarkfront may not
have implemented the theory fully correctly; and I might not have captured
everything I needed to in order for my "proof" to actually say what I
want it to. So not a great idea to use this to protect real money today.

But still, this seems like it's not all /that/ far from being practical,
and if the crypto's not fundamentally broken, seems like it goes a long
way to filling in the biggest privacy hole in lightning today [3]...

Code is at https://github.com/ajtowns/snarkfront/ or more directly at:
https://github.com/ajtowns/snarkfront/blob/lightning-sha/test_lightning.cpp

Cheers,
aj

[0] https://tahoe-lafs.org/trac/tahoe-lafs/wiki/SNARKs

[1] https://github.com/jancarlsson/snarkfront

[2] This would also improve privacy/anonymity for other applications of
HTLCs, such as atomic swaps across chains:

1 bitcoin, payable on R1 + Alice's sig or timeout + Bob's sig
100 litecoin, payable on R2 + Robert's sig or timeout + Ally's sig

Alice and Bob communicate privately, agreeing to trade 1 BTC for 100
litecoin and revealing their aliases Robert and Ally; Alice generates
R1, R2, and reveals SHA(R1), SHA(R2), R1^R2 and the SNARK proof and
publishes the litecoin payment. Bob verifies the proof, and publishes
the bitcoin payment. Alice claims the bitcoin payment, revealing R1;
Bob calculates R2 and claims the litecoin payment. The swap can take
place trustlessly because Bob knows the only way Alice can claim his
bitcoin is by revealing enough info so he can claim the corresponding
litecoin. But there isn't any on-chain information linking the two
transactions, because R1 and R2 are independent (and could even be
using different hash functions as well as different preimages).
After the funds have been claimed, the private communication is
also completely deniable, since anyone could generate R1^R2 and a
corresponding SNARK proof just using the info on the blockchain.

📅 Original date posted:2015-10-16 📝 Original message: On ...

2023-06-09T14:44:48+02:00

In reply to nevent1q…gan9
_________________________

📅 Original date posted:2015-10-16
📝 Original message:
On Fri, Oct 16, 2015 at 02:22:25PM +0100, Mats Jerratsch wrote:
> [...] an attacker could trick it into a fake network, [...]

How do you tell the difference between the "real" network and a "fake"
one? (ie, what does a Turing test for the lightning network look like?)

I think there's two things:

1) you can figure out a route to people you want to pay (and
vice-versa)

2) payments on those routes actually go through

Even better, you can test this! Get a couple of merchant ids you find
interesting, and pay 1 satoshi to each of them, setting the R value as
the (double) SHA256 of the decrypted onion message. [0]

If you spent 1 satoshi to each of 10 merchants every day for a year to
verify connectivity, that'd still only amount to about $0.01 USD total
at current exchange rates, so it seems pretty affordable. [1]

It only works if you actually setup a channel, though -- so you have to
lock some money into the channel for however many confirmations until
the channel activates, before you can test, plus the OP_CSV delay if
the test fails.

But I think that would let people trustlessly avoid "fake" lightning
networks, even with a sybil-esque attack; no extra infrastructure needed.

Cheers,
aj

[0] If you're already on the lightning network, and you're establishing
a new channel as backup, you can just pay yourself 1 satoshi to verify
connectivity. If you have friends on lightning, you could pay them
1 satoshi to verify connectivity rather than a random merchant too.

[1] Hmm, does forwarding 1 satoshi (2.6 10,000ths of a cent) make
sense, or would the CPU cycles cost more than the fees you'd make?
How much does it cost to forward a transaction? In python on my
laptop, I get about 1000 ECDH operations per second in python, and
290k AES ops over a 3kB onion per second, and about 77k SHA256 ops
per second. So just counting elliptic ops, forwarding a transaction
requires three ops: an ECDH on the onion message, and an ECDSA on
the commitment transaction to add the HTLC, and another sometime
later to remove it. So say 1/350th of a CPU-second. My linode costs
3c/hour and seems to be about half as fast on the SHA256 test, but
gives me two CPUs which evens it out. So so 3/60/60/350 cents is
about the cost of forwarding a single transaction, which is about
2.4e-8 dollars, which is currently about 9.1e-11 bitcoin, which
is 0.0091 satoshi. Conveniently lightning balances are denominated
in millisatoshi, so as long as yours increases by 9 or 10, you're
doing fine. 10 millisatoshi is 1% of 1 satoshi, so that seems like
the right order of magnitude.

📅 Original date posted:2015-09-18 📝 Original message: On 19 ...

2023-06-09T14:44:26+02:00

In reply to nevent1q…cqvm
_________________________

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

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. Just adding random bytes on to the end should work I think - they'll just be treated as extra padding and ignored. 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.

Cheers,
aj
--
Sent from my phone.

📅 Original date posted:2015-09-22 📝 Original message: On ...

2023-06-09T14:44:25+02:00

In reply to nevent1q…rela
_________________________

📅 Original date posted:2015-09-22
📝 Original message:
On Tue, Sep 22, 2015 at 11:22:57AM +1000, Anthony Towns wrote:
> If you use OFB or CTR mode for the symmetric cypher, you can calculate
> D_KD() of all the padding and use that to work out the hash H of the
> plaintex message:
> here's $15
> grbg grbg ... grbg
> D_KD(
> D_KC( D_KB( E_KA( 0000 ) ) )
> D_KC( E_KB( 0000 ) )
> E_KC( 0000 )
> )

On Mon, Sep 21, 2015 at 06:18:37AM +0930, Rusty Russell wrote:
> > 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.

You could combine these two approaches actually. If X is the plaintext
routing message the payee gets ("here's $15 grbg grbg ..."), and H is
its hash that was prefixed to the plaintext, then set S=sha256(H+X),
and require revealing S as well as R for payment redemption (ie, include
"OP_SHA256 sha256(S) OP_EQ" in the HTLC).

That way *any* attempt to garble the padding makes S unrecoverable
and renders the payment unredeemable, without relying on any
verification/cooperation from anyone else on the network.

Cheers,
aj

📅 Original date posted:2015-07-24 📝 Original message: On 24 ...

2023-06-09T14:43:43+02:00

In reply to nevent1q…w7f0
_________________________

📅 Original date posted:2015-07-24
📝 Original message:
On 24 July 2015 at 10:49, Rusty Russell <rusty at rustcorp.com.au> wrote:

> 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.

If a channel is updated ~100 of times a second, and lasts for a month, that
would be 259M updates, which on your laptop would be 22 minutes of search
time. If we're talking 3 days worth of OP_CSV delay, even that would be
pretty fine. So yeah, okay, seems plausible.

> 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.
>

You could have multiple OP_RETURN outputs though? Your txn would look like:

version
n inputs: 2
input 1: [txn] [idx] [len] [SIGA SIGB] [seq]
input 2: [txn] [idx] [len] [SIGB SIGA] [seq]
n outputs: 2 + x
output 1: [value] [len] [p2sh] # Alice
output 2: [value] [len] [p2sh] # Bob
output 3: [value] [len] [p2sh] # R1
output 4: [value] [len] [p2sh] # R2
output 5: [value] [len] [OP_RETURN R1R2]
...

p2sh outputs are 32 bytes total I think; OP_RETURN is 51 bytes, so you're
increasing the txn size by about 80%.

Otherwise I think you have to remember all the R's you see. But if that's
okay -- 100/second for a month is just 5GB if you just store them in the
order you see them; you can probably do something like:

- at the time of this transaction, I've seen 0 < N < 2^32 R's on this
channel
- here's a 288 bit bloom filter telling you which of the first N R's that
I've seen are worth checking
- add a single 0btc "OP_RETURN [N | bloomfilter]" output
- (or if there are 10 or less R outputs, just concatenate their indexes as
the OP_RETURN data)

Actually, I forgot about the TIMEOUT values which you'd presumably also
need; so I guess that's an extra 4 bytes to include in the database of
every R (+25%), and if you're not storing, I guess an extra OP_RETURN
output that covers 10 R's for an additional overhead of 16%, so ~96%
overhead all up.

If you consider your counterparty very reliable, then having 100% overhead
in the commitment txns might not be a big deal -- you'll almost always
close the channel cooperatively anyway, so the commitments don't get used
and the fees for the overhead won't get paid; OTOH, if your counterparty
isn't known to you, and you think it's likely they might randomly disappear
off the net and you'll have to use the commitment, then trading off disk
for fees might be sensible. You could change the choice while the channel's
operating -- if a new R value is verbatim in the output, no need to store
it locally, whether or not you've stored previous R values locally.

Cheers,
aj

--
Anthony Towns <aj at erisian.com.au>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150724/268e220f/attachment.html>;

📅 Original date posted:2015-07-23 📝 Original message: Hi *, ...

2023-06-09T14:43:43+02:00

In reply to nevent1q…xl6k
_________________________

📅 Original date posted:2015-07-23
📝 Original message:
Hi *,

For my own understanding I've been trying to work out what the lightning
protocol looks like at a network-protocol level. I think the following
works, maybe it's interesting for others:

For notational convenience I'm going to just list the secrets that need to
be known to use to spend an output. "Alice" and "Bob" are Alice and Bob's
respective keys, Alice_N and Bob_N are the Nth numbers in shachain
sequences [0]. I'm using TIMEOUT for the checktimelockverify construction;
DELAY for the checksequenceverify construction.

Assume Alice and Bob already have a channel setup. Then their current
commitments might be:

Alice's commitment txn: (fully signed)
500 Alice + DELAY | #Alice_101 + Bob
500 Bob

Bob's commitment txn: (fully signed)
500 Alice
500 Bob + DELAY | #Bob_101 + Alice

Alice knows the hash of #Bob_101 and Bob knows the hash of #Alice_101
(because they've respectively seen the full txns to sign them).

If Alice wants to update the channel to reflect a conditional payment from
Bob once R is revealed, they can follow the following steps:

1) Alice proposes: (unsigned)
500 Alice + DELAY | #Alice_102 + Bob
400 Bob
100 R + Alice + DELAY | Bob + TIMEOUT | #Alice_102 + Bob

[1]

Bob checks: txn structure, amounts, R, Bob key is correct
Bob stores the hash of #Alice_102

2a) Bob declines; proposal never happened
2b) Bob approves, replies:
signing Alice's proposal
requesting sig of:
500 Alice
400 Bob + DELAY | #Bob_102 + Alice
100 R + Alice | Bob + TIMEOUT + DELAY | #Bob_102 + Alice

Alice checks: signature, txn structure, amounts, R, Alice key is correct
Alice signs and stores new txn.
Alice stores the hash of #Bob_102

3) Alice discards old commitment txn.
Alice replies:
signing Bob's transaction
revealing Alice_101

Bob checks: signature,
Alice_101 hashes correctly (ie matches the hash of #Alice_101, stored
previously),
Alice_101 forms hash chain with prior secrets (Alice_100, Alice_99..)
as expected

Bob signs and stores his new commitment txn
Bob discards the hash of #Alice_101.

4) Bob discards old commitment txn
Bob replies:
revealing Bob_101

Alice checks:
Bob_101 hashes correctly (ie #Bob_101 does clear the old txn),
Bob_101 forms hash chain with prior secrets (Bob_100, Alice_99..) as
expected
Alice discards the hash of #Bob_101

If the protocol follows through to completion, then they each have
matching, updated, signed commitment transactions; along with the secrets
necessary to void attempts to use older commitments. If the protocol goes
off track (checks fail, or no response from partner within a protocol
timeout), then either party can safely close the channel after any step:

Alice can close at (500/500) up until step (3)
Alice can close at (500/400/100) after step (2b)

Bob can close at (500/500) up until step (4)
Bob can close at (500/400/100) after step (3)

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.

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"?

Cheers,
aj

[0] It's easy to calculate Alice_N given Alice_M for some M > N, but
unfeasible for any M < N.

[1] I don't understand the construction for HTLCs in 0.5.9 of the
lightning paper; what I'm doing instead is taking an underlying output of
"Alice + R | Bob + TIMEOUT" and mapping it through "my key becomes my key +
DELAY" + "they get everything with my secret sequence and their key". I'll
post about that separately so it can get shot down :)

[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

--
Anthony Towns <aj at erisian.com.au>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150723/b330b01a/attachment.html>;

📅 Original date posted:2023-03-09 🗒️ Summary of this ...

2023-06-08T01:20:02+02:00

In reply to nevent1q…gwq6
_________________________

📅 Original date posted:2023-03-09
🗒️ Summary of this message: The email discusses the use of OP_FORWARD_SELF as a JET of OP_FLU in the revaulting common case, with a suggestion to use a special case instead.
📝 Original message:On 10 March 2023 4:45:15 am AEST, Greg Sanders via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>1) OP_FORWARD_SELF is a JET of OP_FLU in the revaulting common case. Maybe
>obvious but I missed this initially and thought it was useful to be pointed
>out.

That was true for TLUV - iirc "FALSE FALSE 0 TLUV" would preserve the spk - but I don't think it's true for OP_FLU: you can't commit to preserving the current script without a way to observe the current script; trying to include a copy of the script in the script makes the script size infinite, and trying to include a hash of the script inside the script is cryptographically infeasible.

You could just special case "0 0 OP_FLU" to result in the same script rather than an empty one though, which would avoid the need for a dedicated FWD_SELF opcode.

(Not convinced calling things Jets when they're unrelated to simplicity makes sense)

Cheers,
aj

--
Sent from my phone.

📅 Original date posted:2023-03-24 🗒️ Summary of this ...

2023-06-08T01:20:02+02:00

In reply to nevent1q…9yxz
_________________________

📅 Original date posted:2023-03-24
🗒️ Summary of this message: A proposed update to Bitcoin's scripting language includes new opcodes for conditional transactions. These could enable non-custodial, on-chain auctions of ordinals.
📝 Original message:On Tue, Mar 07, 2023 at 10:45:34PM +1000, Anthony Towns via bitcoin-dev wrote:
> I think there are perhaps four opcodes that are interesting in this class:
>
> idx sPK OP_FORWARD_TARGET
> -- sends the value to a particular output (given by idx), and
> requires that output have a particular scriptPubKey (given
> by sPK).
>
> idx [...] n script OP_FORWARD_LEAF_UPDATE
> -- sends the value to a particular output (given by idx), and
> requires that output to have almost the same scriptPubKey as this
> input, _except_ that the current leaf is replaced by "script",
> with that script prefixed by "n" pushes (of values given by [...])
>
> idx OP_FORWARD_SELF
> -- sends the value to a particular output (given by idx), and
> requires that output to have the same scriptPubKey as this input
>
> amt OP_FORWARD_PARTIAL
> -- modifies the next OP_FORWARD_* opcode to only affect "amt",
> rather than the entire balance. opcodes after that affect the
> remaining balance, after "amt" has been subtracted. if "amt" is
> 0, the next OP_FORWARD_* becomes a no-op.

The BIP 345 draft has been updated [0] [1] and now pretty much defines
OP_VAULT to have the behaviour specced for OP_FORWARD_LEAF_UPDATE above,
and OP_VAULT_RECOVER to behave as OP_FORWARD_TARGET above. Despite
that, for this email I'm going to continue using the OP_FORWARD_*
naming convention.

Given the recent controversy over the Yuga labs ordinal auction [2],
perhaps it's interesting to consider that these proposed opcodes come
close to making it possible to do a fair, non-custodial, on-chain auction
of ordinals [3].

The idea here is that you create a utxo on chain that contains the ordinal
in question, which commits to the address of the current leading bidder,
and can be spent in two ways:

1) it can be updated to a new bidder, if the bid is raised by at least
K satoshis, in which case the previous bidder is refunded their
bid; or,

2) if there have been no new bids for a day, the current high bidder
wins, and the ordinal is moved to their address, while the funds
from their winning bid are sent to the original vendor's address.

I believe this can be implemented in script as follows,
assuming the opcodes OP_FORWARD_TARGET(OP_VAULT_RECOVER),
OP_FORWARD_LEAF_UPDATE(OP_VAULT), OP_FORWARD_PARTIAL (as specced above),
and OP_PUSHCURRENTINPUTINDEX (as implemented in liquid/elements [4])
are all available.

First, figure out the parameters:

* Set VENDOR to the scriptPubKey corresponding to the vendor's address.
* Set K to the minimum bid increment [5].
* Initially, set X equal to VENDOR.
* Initially, set V to just below the reserve price (V+K is the
minimum initial bid).

Then construct the following script:

[X] [V] [SSS] TOALT TOALT TOALT
0 PUSHCURRENTINPUTINDEX EQUALVERIFY
DEPTH NOT IF
0 10000 FORWARD_PARTIAL
0 FROMALT FORWARD_TARGET
1 [VENDOR] FWD_TARGET
144
ELSE
FROMALT SWAP TUCK FROMALT
[K] ADD GREATERTHANOREQUAL VERIFY
1 SWAP FORWARD_TARGET
DUP FORWARD_PARTIAL
0 ROT ROT
FROMALT DUP 3 SWAP FORWARD_LEAF_UPDATE
0
ENDIF
CSV
1ADD

where "SSS" is a pushdata of the rest of the script ("TOALT TOALT TOALT
.. 1ADD").

Finally, make that script the sole tapleaf, accompanied by a NUMS point
as the internal public key, calculate the taproot address corresponding
to that, and send the ordinal to that address as the first satoshi.

There are two ways to spend that script. With an empty witness stack,
the following will be executed:

[X] [V] [SSS] TOALT TOALT TOALT
-- altstack now contains [SSS V X]
0 PUSHCURRENTINPUTINDEX EQUALVERIFY
-- this input is the first, so the ordinal will move to the first
output
DEPTH NOT IF
-- take this branch: the auction is over!
1 [VENDOR] FWD_TARGET
-- output 1 gets the entire value of this input, and pays to
the vendor's hardcoded scriptPubKey
0 10000 FORWARD_PARTIAL
0 FROMALT FORWARD_TARGET
-- we forward at least 10k sats to output 0 (if there were 0 sats,
the ordinal would end up in output 1 instead, which would be a
bug), and output 0 pays to scriptPubKey "X"
144
ELSE .. ENDIF
-- skip over the other branch
CSV
-- check that this input has baked for 144 blocks (~1 day)
1ADD
-- leave 145 on the stack, which is true. success!

Alternatively, if you want to increase the bid you provide a stack with
two items: your scriptPubKey and the new bid [X' V']. Execution this
time looks like:

[X] [V] [SSS] TOALT TOALT TOALT
-- stack contains [X' V'], altstack now contains [SSS V X]
0 PUSHCURRENTINPUTINDEX EQUALVERIFY
-- this input is the first, so the ordinal will move to the first
output
DEPTH NOT IF ... ELSE
-- skip over the other branch (without violating minimalif rules)
FROMALT SWAP TUCK FROMALT
-- stack contains [X' V' X V' V], altstack contains [SSS]
[K] ADD GREATERTHANOREQUAL VERIFY
-- check V' >= V+K, stack contains [X' V' X]
1 SWAP FORWARD_TARGET
-- output 1 pays to X (previous bidder's scriptPubKey), and the
entire value of this input goes there; stack contains [X' V']
DUP FORWARD_PARTIAL
-- execute "V' FORWARD_PARTIAL", stack contains [X' V']
0 ROT ROT
-- stack contains [0 X' V']
FROMALT DUP 3 SWAP FORWARD_LEAF_UPDATE
-- execute "0 X' V' SSS 3 SSS FORWARD_LEAF_UPDATE" which checks
that output 0 spends at least V' satoshis back to the same
script (because that's how we defined SSS), except the first
three pushes (previously X V SSS) are replaced by X' V' SSS.
0
ENDIF
CSV
-- "0 CSV" requires nSequnce to be set, which makes the tx rbf'able,
which hopefully makes it harder to pin
1ADD
-- ends with 1 on the stack; success!

(The "SSS n SSS FORWARD_LEAF_UPDATE" construct is more or less a quine,
ie a program that outputs its own source code)

I think that script is about 211 witness bytes, with an additional 40
witness bytes for X'/V', so when making a bid, your tx would be
something like:

tx header, 10vb
input 0: 103vb for the old bid including witness and control block
input 1: 58vb for a taproot key path spend
output 0: 43vb for the new bid
output 1: 43vb for your change

for a total of about 257vb -- slightly larger than a regular 2-in-2-out
transaction, but not terribly much. Mostly because input 0 doesn't require
a signature -- it's size is effectively 6 pubkeys: X, X' VENDOR twice,
and the script code twice, along with a little extra to encode the
various numbers (10000, 144, K, V, V').

This approach seems pretty "MEV" resistant: you pay fees via input 1 if
your bid succeeds; if it doesn't, you don't pay any fees. A potential
scalper might want to put in an early low ball bid, then prevent
higher bidders from winning the auction, take control of the ordinal,
and resell it later, but unless they can prevent another miner from
mining alternative bids for 144 blocks, they will fail at that. The bid
is fixed by the bidder and committed to by the signature on input 1, so
frontrunning a bid can't do anything beyond invalidate the bid entirely.

Obviously, this is a pretty limited auction mechanism in various ways;
eg maybe you'd rather specify K as a percentage than an absoute increment;
maybe you'd like to have the auction definitely finish by some particular
time; maybe you'd like to be able to have the auction be able to continue
above 21.47 BTC (2**31 sats); maybe you'd like to do a dutch auction
rather than an english auction. I think you can probably do all those
things with this set of opcodes and clever scripting, though it probably
gets ugly.

I don't think this is easily extensible to taro or rgb style assets,
as rather than being able to ensure the asset is transferred by
controlling the input/output positions, I think you'd need to build
up merkle trees and do point tweaks beyond what's supported by
OP_FORWARD_LEAF_UPDATE/OP_VAULT. Of course, without something like
OP_PUSHCURRENTINPUTINDEX I don't think you could do it for ordinals
either.

Cheers,
aj

[0] https://github.com/bitcoin/bips/blob/7f747fba82675f28c239df690a07b75529bd0960/bip-0345.mediawiki

[1] https://twitter.com/jamesob/status/1639019107432513537

[2] https://cointelegraph.com/news/scammers-dream-yuga-s-auction-model-for-bitcoin-nfts-sees-criticism

[3] Inscriptions remain a wasteful way of publishing/committing
to content, however!

[4] https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md

[5] Setting K too low probably invites griefing, where a bidder may be
able to use rbf pinning vectors to prevent people who would be willing
to bid substantially higher from getting their bid confirmed on
chain.

📅 Original date posted:2023-03-07 🗒️ Summary of this ...

2023-06-08T01:20:00+02:00

In reply to nevent1q…yaks
_________________________

📅 Original date posted:2023-03-07
🗒️ Summary of this message: A proposal to introduce the concept of "forwarding" input amounts to specified outputs with various restrictions on output scripts using new opcodes.
📝 Original message:On Mon, Mar 06, 2023 at 10:25:38AM -0500, James O'Beirne via bitcoin-dev wrote:
> What Greg is proposing above is to in essence TLUV-ify this proposal.

FWIW, the way I'm thinking about this is that the "OP_VAULT" concept is
introducing two things:

a) the concept of "forwarding" the input amount to specified
outputs in a way that elegantly allows merging/splitting

b) various restrictions on the form of the output scripts

These concepts go together well, because restricting an output script is
only an interesting thing to do if you're moving value from this input
into it. And then it's just a matter of figuring out a nice way to pick
opcodes that combine those two concepts in interesting ways.

This is different from TLUV, in that TLUV only did part (b), and
assumed you'd do part (a) manually somehow, eg via "OP_IN_OUT_AMOUNT"
and arithmetic opcodes. The advantage of this new approach over that
one is that it makes it really easy to get the logic right (I often
forgot to include the IN_OUT_AMOUNT checks at all, for instance), and
also makes spending multiple inputs to a single output really simple,
something that would otherwise require kind-of gnarly logic.

I think there are perhaps four opcodes that are interesting in this class:

idx sPK OP_FORWARD_TARGET
-- sends the value to a particular output (given by idx), and
requires that output have a particular scriptPubKey (given
by sPK).

idx [...] n script OP_FORWARD_LEAF_UPDATE
-- sends the value to a particular output (given by idx), and
requires that output to have almost the same scriptPubKey as this
input, _except_ that the current leaf is replaced by "script",
with that script prefixed by "n" pushes (of values given by [...])

idx OP_FORWARD_SELF
-- sends the value to a particular output (given by idx), and
requires that output to have the same scriptPubKey as this input

amt OP_FORWARD_PARTIAL
-- modifies the next OP_FORWARD_* opcode to only affect "amt",
rather than the entire balance. opcodes after that affect the
remaining balance, after "amt" has been subtracted. if "amt" is
0, the next OP_FORWARD_* becomes a no-op.

Then each time you see OP_FORWARD_TARGET or OP_FORWARD_LEAF_UPDATE, you
accumulate the value that's expected to be forwarded to the output by
each input, and verify that the amount for that output is greater-or-equal
to the accumulated value.

> ## Required opcodes
> - OP_VAULT: spent to trigger withdrawal
> - OP_VAULT_RECOVER: spent to recover

Naming here is OP_VAULT ~= OP_FORWARD_LEAF_UPDATE; OP_VAULT_RECOVER ~=
OP_FORWARD_TARGET.

> For each vault, vaulted coins are spent to an output with the taproot
> structure
>
> taproot(internal_key, {$recovery_leaf, $trigger_leaf, ...})
>
> where
>
> $trigger_leaf =
> <trigger> <auth> <script> <spend-delay> OP_VAULT

With the opcodes above, the trigger_leaf (for spending some of the
vaulted funds via your hot wallet) script might look like:

OP_FORWARD_PARTIAL OP_FORWARD_SELF
1 "288 OP_CSV OP_DROP OP_CTV" OP_FORWARD_LEAF_UPDATE
key CHECKSIG

So if you have 2.0 BTC in a vault utxo, you might spend 0.4 BTC by
supplying the witness data:

160000000 (1.6BTC in sats)
0 (output 0 puts 1.6BTC goes back into the vault)
<ctvhash> (the outputs where you want the remaining 0.4 BTC to end up)
1 (the output idx that will be spend via the CTV path once the CSV
delay is done)
<sig> (a signature of this transaction via the hot wallet "key")

That is, the script becomes:

160000000 FORWARD_PARTIAL
0 FORWARD_SELF
1 <ctvhash> 1 "288 CSV DROP CTV" FORWARD_LEAF_UPDATE
sig key CHECKSIG

Output 1 would then have a tapscript of "<ctvhash> 288 OP_CSV OP_DROP
OP_CTV", satisfied with an empty witness stack (along with the recovery
path, etc).

Output 0 is just 1.6BTC back in your vault, and immediately available
for use.

Other inputs/outputs (for fees etc) would still be committed to by <sig>,
so nothing here is malleable. The script here is about 45 bytes (compared
to 34 for a simple "key CHECKSIG") and the witness data is about 105 bytes
(compared to 65 bytes for just a signature), which seems pretty nice.

> ... =
> other (optional) leaves in the taptree

This would allow you to have multiple hot wallets (if any of them are
compromised you can still use the recovery path to avoid loss of funds;
but if some hot wallet becomes temporarily *inaccessible* you can still
easily spend the funds via one of the alternative hot wallets), or,
if you have multiple watchtowers validating your spends and recovering
funds to your cold wallet on a violation, you could have multiple recovery
paths to provide some auditability for who triggered the recovery.

> Happens via script-path spend to $expr_withdraw, i.e. a timelocked
> OP_CTV.

Note that if you calculated the OP_CTV incorrectly (eg, you don't set a
correct nSequence timelock, so that any tx that passes OP_CTV won't pass
the OP_CSV check, and vice-versa) then this spend path becomes invalid,
and the funds can only be reclaimed via some other path (key path spend,
recovery tapscript, potentially an alternative hotwallet script path).

OP_FORWARD_LEAF_UPDATE is equivalent to a very specific form of TLUV,
namely "FALSE <h> 2 TLUV", where "<h>" is calculated by building the
script, prefixing the pushes, then doing the Hash_TapLeaf calculation.

Not being able to tweak the internal public key ("FALSE" rather than
"<x>") means this can't be used to build a coinpool with unilateral
exit -- you can't remove your key from the key path, which screws over
everyone who's still in the coinpool.

On the other hand, not tweaking the internal public key avoids introducing
all the x-only pubkey complications, and keeps it relatively simple,
which is nice, and keeping things simple and targeted now means there's
still plenty of OP_SUCCESS opcodes available later for something more
general, if that turns out to be desirable.

Cheers,
aj

📅 Original date posted:2023-03-02 🗒️ Summary of this ...

2023-06-08T01:19:56+02:00

In reply to nevent1q…9lac
_________________________

📅 Original date posted:2023-03-02
🗒️ Summary of this message: A proposed replacement for two opcodes in Bitcoin involves a new opcode called OP_TRIGGER_FORWARD, which takes three arguments and can be generalized for more flexibility. The proposed opcode can be embedded in a tapscript and used to modify a TLUV-ish script. The existing OP_VAULT cleverness can be used to spend two inputs to the same output, but there is no way to refund values.
📝 Original message:On Wed, Mar 01, 2023 at 10:05:47AM -0500, Greg Sanders via bitcoin-dev wrote:
> Below is a sketch of a replacement for the two opcodes.

I like this! I tried to come up with something along similar lines for
similar reasons, but I think I tried too hard to reduce it to two opcodes
or something and got myself confused.

> `OP_TRIGGER_FORWARD`: Takes exactly three arguments:
> 1) output index to match against (provided at spend time normally)
> 2) target-outputs-hash: 32 byte hash to be forwarded to output given at (1)
> (provided at spend time normally)
> 3) spend-delay: value to be forwarded to output given at (1)

I think you could generalise this as follows:

idx .. npush script OP_FORWARD_LEAF_UPDATE

(OP_FLU :) with the behaviour being:

pop script from the stack
pop npush from the stack (error if non-minimal or <0)
pop npush entries from the stack,
prefix script with a minimal push of that entry
pop idx off the stack (error if idx is not a valid output)
calculate the spk corresponding to taking the current
input's spk and replacing the current leaf with the
given script
check the output at idx matches this spk, and the
value from this input accumulates to that output

Then instead of `idx hash delay OP_TRIGGER_FORWARD` you
write `idx hash delay 2 "OP_CSV OP_DROP OP_FORWARD_OUTPUTS"
OP_FORWARD_LEAF_UPDATE`

That's an additional 5 witness bytes, but a much more generic/composable
opcode.

Being able to prefix a script with push opcodes avoids the possibility
of being able to add OP_SUCCESS instructions, so I think this is a fairly
safe way of allowing a TLUV-ish script to be modified, especially compared
to OP_CAT.

I do recognise that it makes it take a variable number of stack elements
though :)

> As the derived tapscript, embedded in a output scriptpubkey of the form:
> `tr(NUMS,{...,EXPR_WITHDRAW})`, meaning we literally take the control block
> from the spending input, swap the inner pubkey for `NUMS`, use
> `EXPR_WITHDRAW` as the tapleaf, reconstruct the merkle root. If the output
> scriptpubkey doesnt match, fail.

I don't think replacing the internal-public-key makes sense -- if it
was immediately spendable via the keypath before there's no reason for
it not to be immediately spendable now.

> Could save 2 WU having OP_FORWARD_OUTPUTS take the <spend-delay> directly
> as an argument, or keep it more general as I did.

Having OP_FORWARD_OUTPUTS not leave its input on the stack would let
you move the OP_CSV to the end and drop the OP_DROP too, saving 1 WU.

> Would love to know what you and others think about this direction. I
> apologies for any misunderstandings I have about the current OP_VAULT BIP!

I think the existing OP_VAULT cleverness would work here, allowing you
to spend two inputs to the same output, accumulating their values.

I don't think it quite gives you a way to "refund" values though -- so
that you can take a vault with 3 BTC, start the <delay> wait to spend
1.4 BTC, and then immediately decide to spend an additional 0.8 BTC on
something else, without the 0.8 BTC effectively having a doubled delay.

I think you could fix that with something as simple as an additional
"idx OP_FORWARD_REFUND" opcode, though -- then the restriction is just
that the output at the refund idx has the same sPK as this input, and
the total value of this input is accumulated amongst all the outputs
specified by OP_FORWARD opcodes. (Maybe you need to specify the refund
amount explicitly as well, to keep verification easy)

That would make maybe three new opcodes to cover the "accumulate value
from one or more inputs into specified outputs":

- OP_FORWARD_LEAF_UPDATE --> forward input value to modified spk
- OP_FORWARD_DESTINATION --> forward input value to given spk
- OP_FORWARD_REFUND --> forward part of input value to same spk

along with OP_CTV:

- OP_FORWARD_OUTPUTS --> pay to specific outputs

OP_VAULT's "accumulate value" behaviour here makes the OP_IN_OUT_AMOUNT
things from TLUV more implicit and automatic, which is nice. I think
doing TLUV payment pools wouldn't require much more than the ability to
combine OP_FLU and OP_FDEST in a single script, explicitly specifying
how much value is extracted via OP_FDEST with the rest assigned to OP_FLU.

Cheers,
aj

📅 Original date posted:2023-02-17 🗒️ Summary of this ...

2023-06-08T01:19:50+02:00

In reply to nevent1q…weey
_________________________

📅 Original date posted:2023-02-17
🗒️ Summary of this message: The Bitcoin community is discussing solutions to the problem of 1 byte message type IDs lacking a coordination mechanism when multiple in-flight BIPs are proposing new message types. One solution is to use uniform encoding using the high-bit to increase the available ID space, but there is still the issue of ensuring that the most frequent message types get the shorter IDs. Another solution is to make type IDs negotiable per direction per connection, but this adds complexity. The community is considering restricting type IDs to [1, 127] and removing 1 byte allocations for messages that are sent at most once per connection per direction.
📝 Original message:On Thu, Feb 16, 2023 at 05:43:22PM +0000, Dhruv M via bitcoin-dev wrote:
> Problem:
> - 1 byte message type IDs are lacking a co-ordination mechanism when multiple in-flight BIPs are proposing new message types as the id space is reduced form 12 ASCII bytes to 1 byte.
> - 1 byte IDs are scarce and should be allocated judiciously, especially given that gains on bandwidth are very much non-uniform across message types.

ACK.

> Solutions:
> - Uniform encoding using the high-bit increases the available ID space drastically, however, there's still the issue of making sure that the most frequent message types get the shorter IDs.
> - Making type IDs negotiable(editable, really) per direction per connection solves that issue at the cost of some increased complexity.
>
> Since we don't really know the extent to which the protocol will ossify over time and that BIP324 is already quite a large change, we might want to optimize for the least additional complexity that doesn't close the doors on any of the solutions.

I think it's probably less complex to close *some* of the doors?

In particular, I think there's two questions that have to get answered:

1) how do you distinguish the command from the payload for
non short-ids -- by a length prefix, or by setting the high-bit
of the final command byte?

2) are short ids available/meaningful to send prior to VERACK being
completed?

> How about this:
> - BIP324 restricts type IDs to [1, 127]

Is this for short ids (currently [13-255] per the bip) or for every byte
in a non-short-id command (for p2p v1, IsCommandValid() restricts each
byte to being in the printable ascii range, ie [32-126])?

Here's another approach:

idea: we use short ids to minimise bandwidth, and don't care about
bandwidth for long ids

implementation:
short id 0 is reserved for long commands. when received, we
decode the first 12 bytes of the payload and treat them
exactly the same as a v1 p2p message (trailing 0-bytes, etc)
(if there's not 12 bytes of payload, it's just treated as an
invalid command and dropped)

short ids 1-255 are available for use as aliases of particular
long commands

(That's exactly compatible with p2p v1, and also avoids the temptation
to try to choose short command names rather than descriptive ones -- the
0-padding to 12 bytes prevents you from saving any bandwidth that way;
but that's what we have short ids for anyway)

If we decide we want >255 short ids, we can figure out how to extend
them later, in a fairly open ended way I think, eg by having [128-255]
imply a 2 byte short id, so that seems fine?

> - We remove 1 byte allocations for messages that are sent at most once per connection per direction

I think this leaves 32 commands that get short ids initially:

misc: ADDR, ADDRV2, BLOCK, FEEFILTER, GETBLOCKS, GETDATA, GETHEADERS,
HEADERS, INV, NOTFOUND, PING, PONG, TX
bip 35/37: FILTERADD, FILTERCLEAR, FILTERLOAD, MEMPOOL, MERKLEBLOCK
bip 152: BLOCKTXN, CMPCTBLOCK, GETBLOCKTXN
bip 157: CFCHECKPT, CFHEADERS, CFILTER, GETCFCHCKPT, GETCFHEADERS,
GETCFILTERS
bip 330: RECONCILDIFF, REQRECON, REQSKETCHEXT, SENDCMPCT, SKETCH

which drops:

VERSION, VERACK, GETADDR, SENDADDRV2, SENDHEADERS, SENDTXRCNCL,
WTXIDRELAY

compared to bip 324 currently.

I think the things missing from the current list (and not currently in
use by bitcoin core) are:

bip 61: REJECT
bip 331: GETPKGTXNS, PKGTXNS, ANCPKGINFO

> - Optionally, in the implementation we can attempt to move the type id mapping to the p2p layer away from the transport layer. I suspect this could also be done after the implementation is merged but might be cleaner as the mapping is a p2p concern.

I agree that's fine, though I expect that we'll probably want to do it
not long after bip 331 is ready for merge (or some other p2p improvement
comes along)...

Cheers,
aj

📅 Original date posted:2023-02-11 🗒️ Summary of this ...

2023-06-08T01:19:29+02:00

In reply to nevent1q…2z9g
_________________________

📅 Original date posted:2023-02-11
🗒️ Summary of this message: A bug in Taproot allows the same Tapleaf to be repeated multiple times, incurring different Tapfee rates, but a fix is available.
📝 Original message:On 9 February 2023 12:04:16 am AEST, Russell O'Connor via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>The fix for the bug is to sign the entire tapbranch instead of the tapleaf.
>
>On Wed., Feb. 8, 2023, 04:35 Michael Folkson, <michaelfolkson at protonmail.com>
>wrote:
>
>> Hi Andrew
>>
>> > There is a bug in Taproot that allows the same Tapleaf to be repeated
>> multiple times in the same Taproot, potentially at different Taplevels
>> incurring different Tapfee rates.
>> >
>> > The countermeasure is that you should always know the entire Taptree
>> when interacting with someone's Tapspend.
>>
>> I wouldn't say it is a "bug" unless there is a remedy for the bug that
>> wasn't (and retrospectively should have been) included in the Taproot
>> design. In retrospect and assuming you could redesign the Taproot consensus
>> rules again today would you prevent spending from a valid P2TR address if a
>> repeated Tapleaf hash was used to prove that a spending path was embedded
>> in a Taproot tree? That's the only thing I can think of to attempt to
>> remedy this "bug" and it would only be a partial protection as proving a
>> spending path exists within a Taproot tree only requires a subset of the
>> Tapleaf hashes.
>>
>> I only point this out because there seems to be a push to find "bugs" and
>> "accidental blowups" in the Taproot design currently. No problem with this
>> if there are any, they should definitely be highlighted and discussed if
>> they do exist. The nearest to a possible inferior design decision thus far
>> that I'm aware of is x-only pubkeys in BIP340 [0].
>>
>> Thanks
>> Michael
>>
>> [0]:
>> https://btctranscripts.com/london-bitcoin-devs/2022-08-11-tim-ruffing-musig2/#a-retrospective-look-at-bip340
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at protonmail.com
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>
>> ------- Original Message -------
>> On Tuesday, February 7th, 2023 at 18:35, Russell O'Connor via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> There is a bug in Taproot that allows the same Tapleaf to be repeated
>> multiple times in the same Taproot, potentially at different Taplevels
>> incurring different Tapfee rates.
>>
>> The countermeasure is that you should always know the entire Taptree when
>> interacting with someone's Tapspend.
>>
>>
>> On Tue, Feb 7, 2023 at 1:10 PM Andrew Poelstra via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>>
>>> Some people highlighted some minor problems with my last email:
>>>
>>> On Tue, Feb 07, 2023 at 01:46:22PM +0000, Andrew Poelstra via bitcoin-dev
>>> wrote:
>>> >
>>> > <snip>
>>> >
>>> > [1] https://bitcoin.sipa.be/miniscript/
>>> > [2] In Taproot, if you want to prevent signatures migrating to another
>>> > branch or within a branch, you can use the CODESEPARATOR opcode
>>> > which was redisegned in Taproot for exactly this purpose... we
>>> > really did about witness malleation in its design!
>>>
>>> In Taproot the tapleaf hash is always covered by the signature (though
>>> not in some ANYONECANPAY proposals) so you can never migrate signatures
>>> between tapbranches.
>>>
>>> I had thought this was the case, but then I re-confused myself by
>>> reading BIP 341 .... which has much of the sighash specified, but not
>>> all of it! The tapleaf hash is added in BIP 342.
>>>
>>> >
>>> > If you want to prevent signatures from moving around *within* a
>>> > branch,
>>> >
>>>
>>> And this sentence I just meant to delete :)
>>>
>>>
>>> --
>>> Andrew Poelstra
>>> Director of Research, Blockstream
>>> Email: apoelstra at wpsoftware.net
>>> Web: https://www.wpsoftware.net/andrew
>>>
>>> The sun is always shining in space
>>> -Justin Lewis-Webster
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>

Is this something that should be fixed in bip118 signatures then?

Cheers,
aj
--
Sent from my phone.

📅 Original date posted:2023-02-02 🗒️ Summary of this ...

2023-06-08T01:19:07+02:00

In reply to nevent1q…qczs
_________________________

📅 Original date posted:2023-02-02
🗒️ Summary of this message: Casey Rodarmor proposes using ordinal numbers to create non-fungible tokens whose ownership can be transferred by a bitcoin transaction. Inscriptions can be moved off-chain.
📝 Original message:Hi *,

Casey Rodarmor's ordinals use the technique of tracking the identity of
individual satoshis throughout their lifetime:

On Tue, Feb 22, 2022 at 04:43:52PM -0800, Casey Rodarmor via bitcoin-dev wrote:
> Briefly, newly mined satoshis are sequentially numbered in the order in
> which they are mined. These numbers are called "ordinal numbers" or
> "ordinals". When satoshis are spent in a transaction, the input satoshi
> ordinal numbers are assigned to output satoshis using a simple
> first-in-first-out algorithm.

This is proposed as a BIP at https://github.com/bitcoin/bips/pull/1408

When accompanied by a standard for associating some data or right with
such an identity, this allows the creation of non-fungible tokens (or
semi-fungible tokens) whose ownership can be transferred by a bitcoin
transaction.

The proposed BIP doesn't document any method for associating data or a
right with an ordinal, but the "ord" tool defines "inscriptions" to fill
this gap [0], providing a way of including mime-encoded data in a taproot
witness. To make such an inscription, two transactions are required:
one paying some sats to a special scriptPubKey that commits to the
inscribed data, and a second that spends those sats to the owner of the
newly inscribed ordinal, and in so doing revealing the full inscription.

[0] https://docs.ordinals.com/inscriptions.html

I think, however, that you can move inscriptions entirely off-chain. I
wrote a little on this idea on twitter already [1], but after a bit more
thought, I think pushing things even further off-chain would be plausible.

[1] https://twitter.com/ajtowns/status/1619554871166013441

In particular, rather than looking at it as being the owner of the sats
that inscribes some content on those sats (analogously to signing a $100
bill [2]), you could look at it as saying "the owner of this thing is
whoever owns this particular sat" (eg instead of "whoever owns this
share certificate is a shareholder", it's "whoever owns the $1 bill with
serial number X is a shareholder").

[2] https://www.espn.com/nfl/story/_/id/14375536/owner-100-bill-autograph-cleveland-browns-qb-johnny-manziel-getting-offers

Implementing that is fairly straightforward: you just need a protocol
for creating an asset offchain and associating it with an ordinal --
nothing needs to happen on-chain at all. That is, you can do something
as simple as posting a single nostr message:

{
"pubkey": <creator's pubkey>
"kind": 0,
"tags": [
["ord", "txid:vout:sat"]
],
"content": [jpeg goes here],
"id": <hash of the above>
"sig": <signature of id by creator's pubkey>
}

You can prove current ownership of the message by showing a custody
chain, that is the transaction specified by "txid" in the "ord" tag,
then every transaction that spent the given sat, until you get to one
that's still in the utxo set [3]. You don't need to provide witness
data or validate any of these tx's signatures, as that is already
implicit in that you end up at a tx in the utxo set. Just calculating
the txids and comparing against the output containing the sat you're
interested in is sufficient.

[3] If the satoshi was lost to fees at some point, you could continue to
follow ownership by including an entire block in the custody chain.
But seems better to just consider it as "abandoned" or "lost to the
public domain" at that point.

This approach allows all the "inscription" data to be entirely off-chain,
the only thing that requires a transaction on-chain is transferring
ownership to someone else. That allows the NFT's existance can be kept
entirely private if desired; it also makes it cheap to create a new NFT
(you don't need to pay any on-chain fees at all); and it doesn't impose
an outsized overhead on people who aren't interested in your inscriptions,
but may be interested either in bitcoin per se, or in other inscriptions.

For things that have real intrinsic value -- equity rights in a company,
bragging rights for supporting an artist, etc -- this seems like it's
probably a viable approach: owners can "self-custody" all the information
about the things they own without having to rely on third parties,
transfers are no more censorable than any other bitcoin transaction
(especially if the association of the NFT with some particular sat is
not widely known), etc.

The "inscription" approach might still be desirable for broadcasting
information that might otherwise be subject to heavy censorship; presuming
that the censoring entity isn't also willing and able to censor bitcoin
itself. It's not clear that there's any "rights" to be owned for such a
case -- you can't buy the right to be the person that first published
it, and the point of widely broadcasting the information is so it's
not a secret only known to a few anymore. Also, claiming ownership of
such information would presumably make you a target for the censor,
even if just as an example for others. So I'm dubious of the value of
associating an inscription with an ordinal for that use case.

It's also possible that the perceived value of the NFT isn't due to
the inscription, but rather due to the scarcity of the blockspace it
was inscribed in (eg [4]). This is different from Bitcoin's scarcity
-- by 2100 or so there'll be a total of 2100T satoshis available,
but in that same time there will only have been about 4T vbytes of
blockspace available, and perhaps it could make sense to value spent
vbytes proportionally, so 4 spent vbytes is worth 2100 sats. In that
case if you spent 50kvb inscribing a jpeg, perhaps the "rights" to that
jpeg should be worth the same as 50k/4*2100 sats or 0.26 BTC. Doesn't
seem like a sound argument to me -- there's always more blockspace being
created, by fewer and fewer sats being created, and ordinals are far more
awkward to deal with, but I suppose it's still conceivable, and people
at least claim to believe it. If it were true, this argument suggests
the price for blockspace today should be around 2488sat/vB (19.28MBTC /
774700 MvB), rather than 1sat/vB.

[4] https://twitter.com/vnprc/status/1619876888687820801

Anyway, comparisons to ordinal inscriptions aside, I think there's
another interesting point from all this.

Presume you have a tool that implements the nostr ordinal assignment
suggested above: that is, a small modification of the "ord" tool that
can track a chain of custody for an ordinal specified in a nostr event
like the above. That allows you to do NFTs completely unobservably --
you don't have to publish anything to the blockchain apart from ordinary
looking transactions to transfer ownership of your NFT. To your benefit,
that makes it hard for anyone to censor you; but to bitcoin more broadly,
I think it means that the possibility of coloured bitcoins is largely
unavoidable and simply something that must be dealt with, rather than
something we should spend time trying to prevent/avoid. Compare with:

> My personal, and possibly controversial, opinion is that colored coin
> protocols have no business being on the Bitcoin chain, possibly beyond
> committing to an occasional batched state update or so. Both because
> there is little benefit for tokens with a trusted issuer already, and
> because it competes with using Bitcoin for BTC - the token that pays
> for its security (at least as long as the subsidy doesn't run out).
>
> Of course, personal opinions are no reason to dictate what people should
> or can use the chain for, but I do think it's reason to voice hesitancy
> to worsening the system's scalability properties only to benefit what
> I consider misguided use.

-- https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019500.html

I don't think this actually results in majorly misaligned incentives
though: in the nostr-nfts-on-btc world, everyone is still optimising
bitcoin transactions for the same thing -- transfer of value. It's just
that in some cases some sats are valued differently than others --
perhaps my uninscribed sats are worth 0.025 cents each, but you have
a particular inscribed sat that's worth $100k. But we're both dealing
just spending utxos and creating new utxos, doing signatures and maybe
some timelocks or hash reveals. And it's always been possible that
your transaction transferring $100k won't get charged higher fees than
my transfer of $50 -- we care about transaction size, not value after
all. How much does it matter if your tx matters more to your because
someone wants your particular sat, rather than what could happen today
where you have a utxo with 4 BTC while my utxo only has 0.002 BTC?

I think the only way to prevent that sort of NFT structure would be
to have every transaction use fancy zero-knowledge proofs that make it
impossible to associate who received bitcoin with who spent it -- *even
if* both the sender and recipient were willing to cooperate to reveal
that information. I think it would be hard to achieve that while still
making it easy to audit bitcoin's total supply, but I might be wrong.

Note that off-chain colouring here means that someone can create an NFT
that you don't want it, and just assign it to a sat that's already in your
wallet. However, they can do this anyway, by first creating the NFT, then
sending it to your wallet address. A difference though is that they could
create an NFT and assign it to the same ordinal/sat as some existing NFT
that you do value, at which point it's (presumably) impossible to discard
one without discarding both. But again, this is simply something they
can do, just be writing a patch to ord and composing a nostr message;
it's not something you can actually prevent even if you dislike it.

Particularly for semi-fungible tokens, this is perhaps inferior to
Liquid's multi-asset model -- here if you have a utxo with 1M sats, 500
of which are inscribed to each represent rights to $1 worth of USDT,
then rather than acting like a stable coin and being worth $500; it's
actually worth $500+0.01BTC, which is more like $750, and changes as
the value of bitcoin changes.

Cheers,
aj

📅 Original date posted:2023-01-11 🗒️ Summary of this ...

2023-06-08T01:18:20+02:00

In reply to nevent1q…jme7
_________________________

📅 Original date posted:2023-01-11
🗒️ Summary of this message: Discussion on optimizing witness scripts for Bitcoin transactions, including the use of OP_VAULT and pay-to-contract constructions for recovery paths.
📝 Original message:On Tue, Jan 10, 2023 at 03:22:54PM -0500, James O'Beirne wrote:
> > I don't think that makes sense? With a general scheme, you'd only be
> > bloating the witness data (perhaps including the witness script) not
> > the scriptPubKey?
> Sorry, sloppy language on my part. To be charitable, I'm talking about
> the "figurative sPK," which of course these days lives in the witness
> for script-path-ish spends. Maybe the witness discount means that
> "complicated" scripts aren't as big a deal, depending on the actual
> difference in raw script size.

Sure. I think there's three aspects that matter for the witness script:

1) it shouldn't be long/costly to do things that are common and easy:
if you can express "OP_VAULT" in ~70 bytes, you shouldn't have to
spend 1000 bytes to do so; if it can be cheap to validate, you
shouldn't have to pay 100x markup in fees to use it. With the
exception of things that build up from basics (like
CAT/CHECKSIGFROMSTACK approaches), I think this is mostly fine
though.

2) once someone figures out a design, it should be easy to reuse;
but I think that's not a big deal: you just write up a spec for
your script, and people use that in their different wallet software,
much like the specialised scripts for lightning HTLCs

3) primitives should be designed to be easy to safely build on and
scripts should be as easy as possible to analyse once written;
ie, we want things more like miniscript than "The story of Mel,
a Real Programmer"

With some caveats (like that using the cold wallet xpub to scan the
blockchain before you've frozen all your funds is dangerous), OP_VAULT
seems really good on all those fronts, of course.

> > I think it might be better to use a pay-to-contract construction for
> > the recovery path, rather than an empty witness.
> So I guess the one advantage that what you're proposing has over just
> using a recovery-path key signature is that it's all derivable from your
> cold privkey; you don't have to worry about accidentally losing the
> recovery-path key.
> Of course you're still vulnerable to spurious sweeps if the
> sha256(secret) value gets found out, which presumably you'd want in an
> accessible cache to avoid touching the cold secret every time you want
> to sweep.

Sure, "sha256(secret)" itself needs to be semi-secret -- it allows anyone
who knows it to freeze your funds, even if it doesn't allow anyone to
steal them. You could presumably do all the usual things to protect that
secret: split it up with secret sharing; put it in a hardware wallet;
keep it offline; etc.

> What do you think about the idea of making the recovery-path
> authorization behavior variable on a single byte flag preceding the 32
> byte data push, as I mentioned in another post?

] "if
] <recovery-path-hash> is 32 bytes, treat it as it's currently used. If it's
] 33 bytes, use the first byte as a parameter for how to interpret it." To
] start with, an extra prefix byte of 0x00 could mean "require a witness
] satisfying the scriptPubKey that hashes to the remaining 32 bytes" in the
] same way we do the unvault signing.

I don't think 33 bytes would be enough? There isn't really a way to
commit to the recovery destination within the script? So I think you'd
need "<32 byte recovery-path-hash><n byte scriptPubKey>"

Aside from that, my opinion's one/all of:

a) sounds fine

b) maybe you could just always have it include a scriptPubKey? for the
times when you just want "reveal the cold wallet preimage" just have
the scriptPubKey be the single byte "OP_TRUE"; for the times when you
it to be "reveal random preimage" you'd have it be the 22 byte "HASH160
<hash160(sha256(secret))> EQUAL"?

c) delegation to a script is a great idea, that's come up multiple times
(OP_EVAL, BIP117, graftroot) -- it's probably better to have it
available as a generic feature, than bolted on to particular features

> > I think a generic OP_UNVAULT can be used to simulate OP_CTV: replace
> > "<h> OP_CTV" with "<000..0> 0 <h> OP_UNVAULT".
> Yup, that's an inefficient way of emulating CTV.

Sure; I think it's only interesting in establishing how powerful the
construct is in the abstract. It's not an exact match for CTV since it
hashes some things differently.

I don't really think it's necessarily that inefficient fwiw; "0 SHA256
0 <h> UNVAULT" is only 3 more bytes than "<h> CTV", could give you an
unspendable recovery path, provided UNVAULT wants either a BIP341 tagged
hash (which is what the implementation does, by the looks), or a HASH256
for the recovery path.

(Again, this assumes UNVAULT is available in script, and isn't just a
special scriptPubKey type)

> > I think there's maybe a cleverer way of batching / generalising
> > checking that input/output amounts match.
> > [...]
> > * set C = the sum of each output that has a vault tag with
> > #recovery=X
> This would also need to take into account that the <spend-delay>s are
> compatible, but your point is well taken.

Sure, I guess output/UNVAULT delay >= input/VAULT delay would be
sufficient for that.

I guess having all that stuff exposed in the scriptPubKey would be
slightly annoying for griefing -- you set your wallet delay to be 1008
blocks, and someone sends to your vault with a 1007 block delay, or a
6 block delay: does your wallet notice the tx? if it does, what do you
do with those funds?

Maybe that would be a(nother) good reason to hide the OP_VAULT side of
things in taproot (or p2wsh): then you just have a (shorter) taproot
sPK that encodes both things, and people normally don't even have enough
information to correctly tweak your sPK to have a different delay.

> I can see what you're saying about having more generic "group amounts by
> compatible vault params, and then compare to similarly grouped outputs,"

I mostly wrote that up because that's what I imagined your batching
doing before I'd finished reading...

A big disadvantage of that approach compared to yours is that you have
to analyse a potentially arbitrarily large transaction as a whole while
validating each input -- this input uses recovery key XXX which output's
match; this input uses recovery key YYY; oh, this one uses XXX again;
etc. With your approach, you only have to look at particular outputs.

An advantage of that extra complexity is that you could combine operations
from multiple different vaults into a single transaction, potentially
along with fees or a coinjoin or whatever else. Maybe that would be
interesting if this were something you could code in script via some
generic opcodes; but here it would be extra complexity in consensus code,
and it doesn't seem like a good match for OP_VAULT's design parameters.

Cheers,
aj

📅 Original date posted:2022-11-02 📝 Original message:On ...

2023-06-08T01:16:15+02:00

In reply to nevent1q…2txv
_________________________

📅 Original date posted:2022-11-02
📝 Original message:On Mon, Oct 31, 2022 at 12:25:46PM -0400, Greg Sanders via bitcoin-dev wrote:
> For 0-conf services we have potential thieves who are willing
> to *out-bid themselves* to have funds come back to themselves. It's not a
> "legitimate" use-case, but a rational one.

I think that's a huge oversimplification of "rational" -- otherwise
you might as well say that deliberately pinning txs is also rational,
because it allows the person doing the pinning to steal funds from their
counterparty by forcing a timeout to expire.

There's no need for us as developers, or us as node operators, to support
every use case that some individual might find rational at some point in
time. After all, it might be individually rational for someone to want the
subsidy to stop decreasing, or to include 8MB of transactions per block.

Note that it's also straightforwardly rational and incentive compatible
for miners to not want this patch to be available, under the following
scenario:

- a significant number of on-chain txs are for zeroconf services
- fee income would be reduced if zeroconf services went away
(both directly due to the absence of zeroconf payments, and by
reducing mempool pressure, reducing fee income from the on-chain txs
that remain)
- miners adopting fullrbf would cause zeroconf services to go away,
(and won't enable a comparable volume of new services that generates
comparable transaction volume)
- including the option in core would make other miners adopting
fullrbf more likely

I think the first three of those are fairly straightforward and objective,
at least at this point in time. The last is just a risk; but without
any counterbalancing benefit, why take it?

Gaining a few thousand sats due to high feerate replacement txs from
people exploiting zeroconf services for a few months before all those
services shutdown doesn't make up for the lost fee income over the months
or years it might have otherwise taken people to naturally switch to
some better alternative.

Even if fullrbf worked for preventing pinning that likely doesn't directly
result in much additional fee income: once you know that pinning doesn't
work, you just don't try it, which means there's no opportunity for
miners to profit from a bidding war from the pinners counterparties
repeatedly RBFing their preferred tx to get it mined.

That also excludes second order risks: if you can't do zeroconf with BTC
anymore, do you switch to ERC20 tokens, and then trade your BTC savings
for ETH or USDT, and do enough people do that to lower the price of BTC?
If investors see BTC being less used for payments, does that lower their
confidence in bitcoin's future, and cause them to sell?

> Removing a
> quite-likely-incentive-compatible option from the software just encourages
> miners to adopt an additional patch

Why shouldn't miners adopt an additional patch if they want some unusual
functionality?

Don't we want/expect miners to have the ability to change the code in
meaningful ways, at a minimum to be able to cope with the scenario where
core somehow gets coopted and releases bad code, or to be able to deal
with the case where an emergency patch is needed?

Is there any evidence miners even want this option? Peter suggested
that some non-signalling replacements were being mined already [0], but
as far as I can see [1] all of those are simply due to the transaction
they replaced not having propagated in the first place (or having been
evicted somehow? hard to tell without any data on the original tx).

[0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021012.html
[1] https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1292692367

> 2) Forcing miners to honor fees left on the table with respect to 0-conf,
> or forcing them to run a custom patchset to go around it, is a step
> backwards.

As you already acknowledged, any miner that wants this behaviour can just
pick up the patch (or could run Knots, which already has the feature
enabled by default). It's simply false to say miners are being forced
to do anything, no matter what we do here.

If the direction you're facing is one where you're moving towards making
life easier for people to commit fraud, and driving away businesses
that aren't doing anyone harm, without achieving anything much else;
then taking a step backwards seems like a sensible thing to do to me.

(I remain optimistic about coming up with better RBF policy, and willing
to be gung ho about everyone switching over to it even if it does kill
off zeroconf, provided it actually does some good and we give people 6
months or more notice that it's definitely happening and what exactly
the new rules will be, though)

Cheers,
aj

📅 Original date posted:2022-10-29 📝 Original message:On ...

2023-06-08T01:16:02+02:00

In reply to nevent1q…fyyu
_________________________

📅 Original date posted:2022-10-29
📝 Original message:On Fri, Oct 28, 2022 at 09:45:09PM -1000, David A. Harding via bitcoin-dev wrote:
> I think this might be understating the problem. A 95% chance of having
> an outbound peer accept your tx conversely implies 1 in 20 payments will
> fail to propagate on their initial broadcast.

Whether that's terrible or not depends on how easy it is to retry (and how
likely the retry is to succeed) after a failure -- if a TCP packet fails,
it just gets automatically resent, and if that succeeds, there's a little
lag, but your connection is still usable. I think it's *conceivable* that
a 5% failure rate could be detectable and automatically rectified. Not
that I have a good idea how you'd actually do that, in a way that's
efficient/private/decentralised...

> Some napkin math: there are about 250,000 transactions a day; if
> we round that up to 100 million a year and assume we only want one
> transaction per year to fail to initially propagate on a network where
> 30% of nodes have adopted a more permissive policy, lightweight clients
> will need to connect to over 50 randomly selected nodes.[1]

A target failure probability of 1-in-1e8 means:

* with 8 connections, you need 90% of the network to support your txs
* with 12 connections, you need ~79%
* with 24 connections (eg everyone running a long-lived node is
listening, so long lived nodes make 12 outbound and receive about
~12 inbound; shortlived nodes just do 24 outbound), you need ~54%

So with that success target, and no preferential peering, you need
a majority of listening nodes to support your tx's features in most
reasonable scenarios, I think.

> For a more
> permissive policy only adopted by 10% of nodes, the lightweight client
> needs to connect to almost 150 nodes.

I get 175 connections needed for that scenario; or 153 with a target
failure rate of 1-in-10-million.

Cheers,
aj

📅 Original date posted:2022-10-30 📝 Original message:On ...

2023-06-08T01:16:00+02:00

In reply to nevent1q…0m4l
_________________________

📅 Original date posted:2022-10-30
📝 Original message:On Thu, Oct 27, 2022 at 09:29:47PM +0100, Antoine Riard via bitcoin-dev wrote:
> Let's take the contra.

(I don't think I know that phrase? Is it like "play devil's advocate"?)

> I would say the current post describes the state of Bitcoin Core and
> beyond policy
> rules with a high-degree of exhaustivity and completeness, though itt what
> is, mostly a description. While I think it ends with a set of
> recommendations

It was only intended as a description, not a recommendation for anything.

At this point, the only thing I think I could honestly recommend
that doesn't seem like it comes with massive downsides, is for core to
recommend and implement a particular mempool policy, and only have options
that either make it feasible to scale that policy to different hardware
limitations, and provide options that users can activate en-masse if it
turns out people are doing crazy things in the mempool (eg, a new policy
turns out to be ill-conceived, and it's better to revert to a previous
policy; or a potential spam vector gets exploited at scale).

> What should be actually the design goals and
> principles of Core's transaction-relay propagation rules
> of which mempool accepts ones is a subset?

I think the goals of mempool/relay policy are _really_ simple; namely:

* relay transactions from users to all potential miners, so that
non-mining nodes don't have to directly contact miners to announce
their tx, both for efficiency (your tx can appear in the next block
anyone mines, rather than just the next block you mine) and privacy
(so that miners don't know who a transaction belongs to, so that
users don't have to know who miners are, and so there's no/minimal
correlation between who proposed a tx and who mined the block it
appears in)

* having most of the data that makes up the next block pre-validated
and pre-distributed throughout the network, so that block validation
and relay is much more efficient

> By such design goals, I'm
> thinking either, a qualitative framework, like attacks game for a concrete
> application ("Can we prevent pinning against multi-party Coinjoin ?").

I don't think that even makes sense as a question at that level: you can
only ask questions like that if you already have known mempool policies
across the majority of nodes and miners. If you don't, you have to allow
for the possibility that 99% of hashrate is receiving private blacklists
from OFAC and that one of your coinjoin counterparties is on that list,
eg, and at that point, I don't think pinning is even conceivably solvable.

> I believe we would come up with a
> second-order observation. That we might not be able to satisfy every
> use-case with the standard set of policy rules. E.g, a contracting protocol
> could look for package size beyond the upper bound anti-Dos limit.

One reason that limit is in place is that it the larger the tx is
compared to the block limit, the more likely you are to hit corner cases
where greedily filling a block with the highest fee ratex txs first
is significantly suboptimal. That might mean, eg, that there's 410kvB
of higher fee rate txs than your 600kvB large package, and that your
stuff gets delayed, because the miner isn't clever enough to realise
dropping the 10kvB is worthwhile. Or it might mean that your tx gets
delayed because the complicated analysis takes a minute to run and a
block was mined using the simpler algorithm first. Or it might mean that
some mining startup with clever proprietary software that can calculate
this stuff quickly make substantially more profit than everyone else,
so they start dominating block generation, despite the fact that they're
censoring transactions due to OFAC rules.

> Or even the
> global ressources offered by the network of full-nodes are not high enough
> to handle some application event.

Blocks are limited on average to 4MB-per-10-minutes (6.7kB/second),
and applications certainly shouldn't be being designed to only work if
they can monopolise the entirety of the next few blocks. I don't think
it makes any sense to imagine application events in Bitcoin that exceed
the capacity of a random full node. And equally, even if you're talking
about some other blockchain with higher capacity; I don't really think
it makes sense to call it a "full" node if it can't actually cope with
the demands placed on it by any application that works on that network.

> E.g a Lightning Service Provider doing a
> liquidity maintenance round of all its counterparties, and as such
> force-closing and broadcasting more transactions than can be handled at the
> transaction-relay layer due to default MAX_PEER_TX_ANNOUNCEMENTS value.

MAX_PEER_TX_ANNOUNCEMENTS is 5000 txs, and it's per-peer. If you're an
LSP that's doing that much work, it seems likely that you'd at least
be running a long-lived listening node, so likely have 100+ peers, and
could conceivably simultaneously announce 500k txs distributed across
them, which at 130vB each (1-taproot-in, 2-p2wpkh out, which I think is
pretty minimal) adds up to 65 blocks worth of transactions. And then,
you could run more than one node, as well.

Your real limitation is likely that most nodes on the network
will only relay your txs onwards at an average rate of ~7/second
(INVENTORY_BROADCAST_PER_SECOND), so even 5000 txs will likely take over
700s to propagate anyway.

> My personal take on those subjects, we might have to realize we're facing
> an heterogeneity of Bitcoin applications and use-cases [1].

Sure; but that's why you make your policy generic, rather than having
to introduce a new, different policy targeted at each new use case.

> And this sounds
> like a long-term upward trend, akin to the history of the Internet: mail
> clients, web browser, streaming applications, etc, all with different
> service-level requirements in terms of latency, jitters and bandwidth.

Back in the mid/late 90s, people argued that real-time communication,
(like audio chat, let alone streaming video) wasn't suitable for IP,
but would require a different network like ATM where dedicated circuits
were established between the sender and recipient to avoid latency,
jitter and bandwidth competition. Turns out that separate networks
weren't optimal for that.

> To put it simply, some advanced Bitcoin
> applications might have to outgrow the "mempool policy rules" game,

I think if you stick to the fundamentals -- that relay/mempool is about
getting transactions to miners and widely preseeding the contents of
whatever the next block will be -- then it's pretty unlikely that any
Bitcoin application will outgrow the mempool policy game.

> I think this has been historically the case with
> some miners deciding to join FIBER, to improve their view of mined blocks.

FIBRE (it doesn't use the US spelling) is a speedup on top of compact
block relay -- it still gets you exactly the same data if you don't use,
it's just everything is slightly faster if you do. Even better, if you
get a block via FIBRE, then you relay it on to your peers over regular
p2p, helping them get it faster too.

Doing something similar with mempool txs -- having some high bandwidth
overlay network where the edges then feed txs back into the main p2p
network at a slower rate that filters out spam or whatever -- would
probably likewise be a fine addition to bitcoin, provided it had the
same policy rules as regular bitcoin nodes employ for tx relay. If it
had different ones, it would become a signficant centralisation risk: app
developers who make use of the different rules would need to comply with
the overlay networks ToS to avoid getting banned, and miners would need
to subscribe to the feed to avoid missing out on txs and thus fee income.

> What I'm expressing is a long-term perspective, and we might be too early
> in the evolutionary process that is Bitcoin Core development to abandon yet
> the "one-size-fits-all" policy rules conception that I understand from
> your post.

I don't think "one-size-fits-all" is a principle at all; I think
decentralisation/censorship-resistance, privacy, and efficiency are the
fundamental principles. As far as I can see, a one-size-fits-all approach
(or, more precisely, an approach where >90% of the network converges to
the same set of rules) is far better at achieving those principles than
a heterogenous policy approach.

> After exposure and exploration of more Bitcoin use-cases and applications,
> and even among the different requirement among types of use-cases nodes
> (e.g LN mobile vs LSP), I believe more heterogeneity in the policy rules
> usage makes more sense

I think when you say "more heterogeneity" what you're actually assuming
is that miners will implement a superset of all those policies, so that
if *any* node on the network accepts a tx X, *every* miner will also
accept a tx X, with the only exception being if there's some conflicting
tx Y that allows the miner to collect more fees.

But that's not really a heterogenous policy: in that case all miners
are employing exactly the same policy.

In that scenario, I don't think you'll end up with nodes running
heteregenous policies either: part of the point of having mempool
policies is to predict the next block, so if all miners really do have
a common policy, it makes sense for nodes to have the same policy. The
only potential difference is miners might be willing to dedicate more
resources, so might set some knobs related to memory/bandwidth/cpu
consumption differently.

I think what you're actually assuming is that this scenario will mean
that miners will quickly expand their shared policy to accept *any*
set of txs that are accepted by a small minority of relay nodes: after
all, if there are some txs out there that pay fees, why wouldn't miners
want to include them? That's what incentive compatible means, right? And
that's great from a protocol reasearch point-of-view: it allows you to
handwave away people complaining that your idea is bad -- by assumption,
all you need to do is deploy it, and it immediately starts working,
without anyone else needing to adopt it.

I don't think that's actually a realistic assumption though: first,
updating miners' policy rules requires updated software to be tested
and deployed, so isn't trivial enough that it should be handwaved away,
second, as in the "big packages" example above, constructing an efficient
block becomes harder the more mempool rules you throw away, so even if
there are txs violating those rules that are offering extra fees, they
may not actually cover the extra costs to generate a block when you're
no longer able to rely on those rules to reduce the complexity of the
problem space.

Note also that "relay nodes will want to use the same policy as mining
nodes" goes both ways -- if that doesn't happen, and compact block
relay requires an extra round trip to reconstruct the block, miners'
blocks won't relay as quickly, and they'll have an increased orphan rate.

Cheers,
aj

📅 Original date posted:2022-10-27 📝 Original message:On ...

2023-06-08T01:15:56+02:00

In reply to nevent1q…hxyw
_________________________

📅 Original date posted:2022-10-27
📝 Original message:On Thu, Oct 27, 2022 at 01:36:47PM +0100, Gloria Zhao wrote:
> > The cutoff for that is probably something like "do 30% of listening
> > nodes have a compatible policy"? If they do, then you'll have about a
> > 95% chance of having at least one of your outbound peers accept your tx,
> > just by random chance.
> Yes, in most cases, whether Bitcoin Core is restricting or loosening
> policy, the user in question is fine as long as they have a path from their
> node to a miner that will accept it. This is the case for something like
> -datacarriersize if the use case is putting stuff into OP_RETURN outputs,
> or if they're LN and using CPFP carveout, v3, package relay, etc.

> But
> replacement is not only a question of "will my transaction propagate" but
> also, "will someone else's transaction propagate, invalidating mine" or, in
> other words, "can I prevent someone else's transaction from propagating."

"Can I prevent someone else's transaction from propagating" is almost
the entirety of the question with -datacarrier, -datacarriersize and
-permitbaremultisig though: "we" don't want people to spam the utxo
set or the blockchain with lots of data (cf BSV's gigabytes worth of
dog pictures [0]), so for the people who are going to find some way
of putting data in we'd like to encourage them to make it small, and
do it in a way that's prunable and doesn't bloat the utxo set, whose
size matters even more than the overall blockchain's size does. As I
understand it, people were doing that by creating bare multisig utxos,
ie a bare (non-p2sh) scriptPubKey that perhaps looks like:

1 my_key data1 data2 data3 data4 data5 5 CHECKMULTISIG

which is "bad" in two ways: you're only committing to the data, so why
not save 128 bytes by doing hash(data1 data2 data3 data4 data5) instead;
and even more so, that data is only interesting to you, not everyone else,
so why not do it in a way that doesn't bloat the utxo set, which we want
to keep small so that it's easier to efficiently look up potential spends.

Hence the -datacarriersize limitation that limits you to about 2.5
"dataN" entries per tx ("we'll prevent your tx from propagating if you
do much more than publish a hash") and hence at least the potential for
doing the same for baremultisig in general.

[0] https://twitter.com/bsvdata/status/1427866510035324936

> A
> zeroconf user relies on there *not* being a path from someone else's full
> RBF node to a full RBF miner. This is why I think RBF is so controversial
> in general,

Yes; but I think it's also true to say that this is why *zeroconf* is as
controversial as it is.

Likewise OP_RETURN has had its own "controversies" to some extent, too:

https://blog.bitmex.com/dapps-or-only-bitcoin-transactions-the-2014-debate/
https://github.com/bitcoin/bitcoin/pull/3715
https://github.com/bitcoin/bitcoin/pull/3939

> why -mempoolfullrbf on someone else's node is considered more
> significant than another policy option, and why full RBF shouldn't be
> compared with something like datacarriersize.

It's definitely a different scenario: unexpected RBF can cause you to
have less money than you expected; whereas more OP_RETURN data just
bloats the blockchain, and losing money that you thought was yours is
definitely more painful than more spam.

But while the level of pain is different; I don't think the mechanism is:
whether you're trying to preserve zeroconf or prevent utxo set spam,
you're still relying on a vast majority of nodes working together to
prevent even a small minority of hashpower from doing "bad" things, with
no cryptographic assurances that will continue to work well or at all.

> I don't think past patterns can be easily applied here,

I mean, technically they trivially could? We *could* roll out support for
full RBF in exactly the same way we rolled out support for opt-in RBF:
making it the default for all nodes, but supplying an option that node
operators can use to disable the feature for seven releases / ~4 years:

https://bitcoin.org/en/release/v0.12.0#opt-in-replace-by-fee-transactions
https://bitcoin.org/en/release/v0.19.0.1#deprecated-or-removed-configuration-options

If we don't want to do that immediately, but also want to make a definite
move forward, then we could:

* just say that, and then keep our word about it
* keep the feature in master, but remove it in 24.x
* put a time delay on the feature so that it doesn't happen immediately
but is locked in in the code for whenever we are ready to do it

> and I don't think this necessarily shows a
> different "direction" in thinking about mempool policy in general.

If we're not applying past patterns, then this is a different direction
in how we're thinking about things than what we did in the past.

That's not necessarily a bad thing -- maybe we should be thinking
differently; but I don't see how you can honestly dispute it: those are
just two ways of saying the exact same thing.

Cheers,
aj

📅 Original date posted:2022-10-26 📝 Original message:Hi *, ...

2023-06-08T01:15:50+02:00

In reply to nevent1q…rkls
_________________________

📅 Original date posted:2022-10-26
📝 Original message:Hi *,

TLDR: Yes, this post is too long, and there's no TLDR. If it's any
consolation, it took longer to write than it does to read?

On Tue, Jun 15, 2021 at 12:55:14PM -0400, Antoine Riard via bitcoin-dev wrote:
> Subject: Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0
> I'm writing to propose deprecation of opt-in RBF in favor of full-RBF

> If there is ecosystem agreement on switching to full-RBF, but 0.24 sounds
> too early, let's defer it to 0.25 or 0.26. I don't think Core has a
> consistent deprecation process w.r.t to policy rules heavily relied-on by
> Bitcoin users, if we do so let sets a precedent satisfying as many folks as
> we can.

One precedent that seems to be being set here, which to me seems fairly
novel for bitcoin core, is that we're about to start supporting and
encouraging nodes to have meaningfully different mempool policies. From
what I've seen, the baseline expectation has always been that while
certainly mempools can and will differ, policies will be largely the same:

Firstly, there is no "the mempool". There is no global mempool. Rather
each node maintains its own mempool and accepts and rejects transaction
to that mempool using their own internal policies. Most nodes have
the same policies, but due to different start times, relay delays,
and other factors, not every node has the same mempool, although they
may be very similar.

- https://bitcoin.stackexchange.com/questions/98585/how-to-find-if-two-transactions-in-mempool-are-conflicting

Up until now, the differences between node policies supported by different
nodes running core have been quite small, with essentially the following
options available:

-minrelaytxfee, -maxmempool - changes the lowest fee rate you'll accept

-mempoolexpiry - how long to keep txs in the mempool

-datacarrier - reject txs creating OP_RETURN outputs

-datacarriersize - maximum size of OP_RETURN data

-permitbaremultisig - prevent relay of bare multisig

-bytespersigop - changes how SIGOP accounting works for relay and
mining prioritisation

as well as these, marked as "debug only" options (only shown with
-help-debug):

-incrementalrelayfee - make it easier/harder to spam txs by only
slightly bumping the fee; marked as a "debug only" option

-dustrelayfee - make it easier/harder to create uneconomic utxos;
marked as a "debug only" option

-limit{descendant,ancestor}{count,size} - changes how large the
transaction chains can be; marked as a "debug only" option

and in theory, but not available on mainnet:

-acceptnonstdtxn - relay/mine non standard transactions

There's also the "prioritisetransaction" rpc, which can cause you to keep
a low feerate transaction in your mempool longer than you might otherwise.

I think that -minrelaytxfee, -maxmempool and -mempoolexpiry are the only
ones of those options commonly set, and those only rarely result in any
differences in the txs at the top of the mempool.

There are also quite a few parameters that aren't even runtime
configurable:

- MAX_STANDARD_TX_WEIGHT
- MIN_STANDARD_TX_NONWITNESS_SIZE (see also #26265)
- MAX_P2SH_SIGOPS (see also #26348)
- MAX_STANDARD_TX_SIGOPS_COST
- MAX_STANDARD_P2WSH_STACK_ITEMS
- MAX_STANDARD_P2WSH_STACK_ITEM_SIZE
- MAX_STANDARD_TAPSCRIPT_STACK_ITEM_SIZE
- MAX_STANDARD_P2WSH_SCRIPT_SIZE
- MAX_STANDARD_SCRIPTSIG_SIZE
- EXTRA_DESCENDANT_TX_SIZE_LIMIT
- MAX_REPLACEMENT_CANDIDATES

And other plausible options aren't configurable even at compile time
-- eg, core doesn't implement BIP 125's inherited signalling rule so
there's no way to enable it; core doesn't allow opting out of BIP 125
rule 3 ratchet on absolute fee; core doesn't allow CPFP carveout with
more than 1 ancestor; core doesn't allow opting out of LOW_S checks
(even via -acceptnonstdtxn); etc.

We also naturally have different mempool policies between different
releases: eg, expansions of policy, such as allowing OP_RETURN or
expanding it from 40 to 80 bytes or new soft forks where old nodes won't
relay transactions that use the new; and also occassional restrictions
in policy, such as the LOW_S requirement.

While supporting and encouraging different mempool polices might be new
for core, it's not new for knots: knots changes some of these defaults
(-permitbaremultisig defaults to false, -datacarriersize is reduced to
42), allows the use of -acceptnonstdtxn on mainnet, and introduces new
options including -spkreuse and -mempoolreplacement (giving the latter
full rbf behaviour by default). Knots also includes a `-corepolicy`
option to make it easy to get a configuration matching core's defaults.

I think gmaxwell's take from Feb 2015 (in the context of how restrictive
policy on OP_RETURN data should be) was a reasonable description for
core's approach up until now:

There is also a matter of driving competent design rather than lazy
first thing that works. E.g. In stealth addresses the early proposals
use highly inefficient single ECDH point per output instead of simply
pooling them. Network behavior is one of the few bits of friction
driving good technical design rather than "move fast, break things, and
force everyone else onto my way of doing thing rather than discussing
the design in public". No one wants to be an outright gatekeeper,
but the network is a shared resource and it's perfectly reasonable
node behavior to be stingy about the perpetual storage impact of the
transactions they're willing to process, especially when it comes to
neutral technical criteria like the amount of network irrelevant data
stuffed in transactions.

There is also a very clear pattern we've seen in the past where
people take anything the system lets them do as strong evidence that
they have a irrevocable right to use the system in that way, and that
their only responsibility-- and if their usage harms the system it's
the responsibility of the system to not permit it. [...
...] For mitigating these risks it's optimal if transactions
seem as uniform and indistinguishable as reasonably possible.

- https://github.com/bitcoin/bitcoin/pull/5286#issuecomment-72564175

Perhaps see also sdaftuar in Nov 2015,

To me the most important question is, is priority something that miners
want to use?

If a non-negligible amount of hashpower intends to use it in their
transaction selection, then I think it makes sense for nodes to use it
too, because it's generally helpful to have your mempool predict the
UTXO as much as possible, and for nodes to be able to have reasonable
fee and priority estimates (which won't happen unless they track the
priority transactions somehow -- I'm presuming that miners run with
much bigger mempools than regular nodes).

If the answer is no, then that's fine and I don't see a reason to push
in this direction. I sort of assumed there was enough hashpower mining
with priority, since last time I checked estimatepriority was still
giving meaningful results for low-ish blockheights, but I haven't done
any kind of real analysis.

- https://github.com/bitcoin/bitcoin/pull/6992#issuecomment-155969455

or in June 2019,

What this PR is proposing is to get rid of a command-line option that is
(a) a footgun for users and (b) does not reflect what I believe to be
the understanding most users have, which is that [X txs] are expected
to propagate well on the network.

..

I don't think this rises to the level that Luke is concerned about,
namely a prelude to forcing a common relay policy on all nodes. In
particular I do agree it makes sense that we offer some ways of
customizing policy parameters (eg the mempool size, min relay fee,
etc). Instead, I think the justification for this change is that we
should not support behaviors we think are harmful to the ecosystem
overall and have no legitimate use-case, and we should eliminate ways
that users might inadvertently shoot themselves in the foot.

- https://github.com/bitcoin/bitcoin/pull/16171#issuecomment-500393271

(or see discussion in https://github.com/bitcoin/bitcoin/pull/7219)

I don't mean to imply the above are saying "there's one way to do
things and it's this way", or that the old way of doing things should
necessarily be the way we keep doing things. Just that previously core
has tended towards designing a single policy that works as well as it
can for everyone and the ecosystem as a whole. (I'm also not saying that
fullrbf can't work well for everyone or the ecosystem as a whole)

By contrast, I think the most common response to pushback against the
full rbf option has been along the lines of "it's just an option, we
don't want to force people", eg:

Blaming the default false -mempoolfullrbf option for a full RBF network
would be holding Bitcoin Core developers responsible for the decisions
of individual node operators and miners. I don't think having the
option (again, default false) can directly cause a full RBF network,
and likewise, I don't think removing this option removes the "risk"
of a full RBF network.
- glozow
https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1274949400

NACK. This is a default false option.
- achow101
https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1274953204

Erecting artificial barriers to prevent or make it difficult for users
to do what they want to do, is not appropriate behaviour.
- luke-jr
https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1290721905

I'm in general against removing options.
- instagibbs
https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1292030700

I think this differs from what core has done in the past, in that
previously we've tried to ensure a new policy is good for everyone (or as
nearly as it can be), and then enabled it as soon as it's implemented.
Any options that have been added have either been to control resource
usage in ways that don't significantly effect tx propagation, to
allow people to revert to the old behaviour when the new behaviour is
controversial (eg the -mempoolreplacement=0 option from 0.12 to 0.18),
and to make it easier to test/debug the implementation.

Giving people a new relay behaviour they can opt-in to when we aren't
confident enough to turn on by default doesn't match the approach I've
seen core take in the past.

If this is going to be an ongoing shift in how core sees relay/mempool
policy, I think that's significant and worth paying attention to.

I don't think it's necessary to have that shift to roll out full rbf.
The other approach would be either:

* set -mempoolfullrbf=true as the default for 24.0, and just have the
command line param there in case people want to do a
"UserRejectedMempoolPolicy" campaign to get everyone to opt-out

* revert it for now because we don't think mainnet is ready for fullrbf
yet, and introduce it as default true for 25.0 or 26.0 or 27.0 or
to activate at some scheduled date in that timeframe (potentially
backporting it to previous releases to help with adoption too,
whatever). same effect as the previous option, just with a bit more
advanced notice and time to prepare

I don't think anyone's proposed the first (which I interpret as "most of
us don't think mainnet is ready for fullrbf today"), but the comments
above are all pushback by people arguing against (the first step of)
the second approach, and they seem to be winning the day.

It's also possible that this is something of a one time thing: full rbf
has been controversial for ages, but widely liked by devs, and other
attempts (eg making it available in knots) haven't actually achieved
much of a result in practice. So maybe this is just a special case and
not a precedent, and when people propose other default false options,
there will be substantially more resistance to them being merged,
despite all the talk about users having options that's going on right now.

Assuming it is the change of direction it appears to be -- and all of
the above is really just justification for that assumption -- then like
I said, I think it's worth seriously considering what it means for people
to choose their own relay/mempool policies and for you to expect to have
different mempool policies to many or most of your potential peers.

One thing maybe worth noting is that is that you can still only choose
your policy from options that people write code for -- if it wasn't
something you could get by running knots or compiling a rejected PR
yourself, it won't magically become more possible now. Presumably it
would mean that once a PR is written, it might get better review (rather
than being dismissed as not suitable for everyone), and there would be
less maintenance burden than if it had to be manually rebased every
release, though (or at least the maintenance burden would be shared
across everyone working on the codebase).

The second thing is that whatever your relay policy is, you still
need a path all the way to miners through nodes that will accept your
transaction at every step. If you're making your mempool more restrictive
(eg -permitbaremultisig=0, -datacarrier=0), that's easy for you (though
you're making life more difficult for people who do create those sorts
of txs); but if you want a more permissive policy (package relay,
version-3-rbf, full-rbf), you might need to do some work.

The cutoff for that is probably something like "do 30% of listening
nodes have a compatible policy"? If they do, then you'll have about a
95% chance of having at least one of your outbound peers accept your tx,
just by random chance. If erlay allows increasing your outbound count to
12 connections instead of 8; that might reduce down to needing just 20%
of listening nodes (~93%).

But for cases where less than 30% (20%) of network supports your preferred
policy, you probably need to do something cleverer.

One approach is to set a service bit and preferentially peer with other
nodes that advertise that service bit; knots does the first half of this
for fullrbf, and both halves have been proposed for core in #25600.
Preferential peering was previously done for the segwit deployment,
though in that case it was necessary not just for tx propogation but
also for ensuring block propogation, making it effectively a consensus
critical issue.

Another approach is having a separate relay network -- eg, lightning nodes
already have a gossip network, and might want to help their own ecosystem
by ensuring unilateral channel closes and justice transactions are quickly
relayed. Using their own gossip network to relay the transaction around,
and each lightning node adding it to their local bitcoind's mempool and
allowing it to propogate (or not) from there as normal, would also be a
way of allowing transactions to propogate well. It does mean that miners
would either need to also participate in lightning gossip directly, or
that miners would need to connect to *many* peers to be confident of
seeing those transactions (eg, if only 2% of the network would see a
tx, you'd need to make 228 connections to have a 99% chance of seeing
the tx). You can't currently do something like this, because all the
relay policies are also applied when adding txs to the mempool via RPC,
and there's no convenient way to remove txs from the mempool.

A case where something like that might occur is in preventing L2
transactions from pinning attacks -- so you might have a high-fee,
low-feerate transaction that's been widely propogated, sitting in the
bottom of people's mempools, and you want to replace it with a smaller,
higher-feerate transaction, but don't want to pay a higher absolute fee,
and are thus blocked by BIP 125 rule 3. Perhaps 98% of the network is
unwilling to deviate from BIP 125 rule 3 for you; because that would
make it easy for random griefers to spam their mempool with large txs
then delete them while only paying a small fee; but your L2 peers may be
able to decode your replacement transaction and be sure that you aren't
going to spam them, and thus will happily relay it.

>From a technical point-of-view, that's largely fine; the downside is it
increases the centralisation pressure on mining: whether that's by having
to connect to substantially more nodes, or having to parse through more
spam, you can't just run your mining operation off a standard install
of bitcoin core anymore, but need to actively opt-in to find all the
weird unusual ways people are sending transactions around in order to
actually collect as much in fees as your competitors are.

That's probably moderately bad for privacy as well -- if lightning or
coinjoins need special relay rules that most nodes haven't opted into,
it's potentially easy to use that to find the bitcoin nodes on the
network that are participating in those protocols, and from there to
either identify the operator, or run a DoS attack to make it hard for you
to keep doing what you want. Obviously if you're setting a service bit to
get better routing, you've given up that privacy already. Likewise if the
government or random vandals are opposed to bitcoin mining, and miners
have to have special configuration on their nodes that distinguish them
from regular users, then perhaps that makes it easier to find or shut
down their operations.

There are a few efficiencies to be gained from similar mempool policies as
well: more reliable compact block reconstruction (if you're not missing
any transactions, you avoid a round-trip) and presumably more efficient
set reconstruction with erlay. You'll also waste less bandwidth sending
transactions that the other node is only going to reject. Both those
depend on how many transactions are going to rely on unusual mempool
policies in the first place though.

ariard wrote:

I know I've advocated in the past to turn RBF support by default in
the past. Though after gathering a lot of feedbacks, this approach
of offering the policy flexiblity to the interested users only and
favoring a full-rbf gradual deployment sounds better to me.

- https://github.com/bitcoin/bitcoin/pull/25353#issuecomment-1157137026

I guess all the above leads me to think that gradual deployments of
mempool policies are likely the worse approach: even when they're not
hurting anyone, it makes them hard to use during the gradual phase,
and getting around that comes with worrying compromises on privacy and
centralisation; and when they are problematic for some, the indeterminate
nature of a gradual deployment means it's hard to plan for when that
risk is going to eventuate.

Theoretically, one way to recover the good parts of core deciding on
what's good for the network might be for people outside of core to
recommend a mempool configuration; then core can just have an option
to make that easy, similar to "-std=c++17" for a C++ compiler, and much
the same as knots' "-corepolicy" option.

Presuming anyone actually wants to take on that job, and listen to the
concerns of zeroconf businesses, lightning and coinjoin devs, miners, etc;
and can come up with something that keeps most of them happy, and that
70% or 90% of the network ends up just following those recommendations
because it's easy, it works, and it's recommended by all the apps they
want to use, then that could work great:

* miners don't need to do anything special, so there's no new
mining centralisation pressure
* miners and users don't reveal what they're doing with bitcoin by the way
they configure their nodes, so there's no privacy problems
* devs can be fairly confident in how they have to design their apps
in order to get their transactions to most hashpower
* devs don't have to add new p2p layers to make it happen
* at least there's someone to talk to when you're trying to figure out
how to make some new project possible when it's inhibited by current
relay policies and you don't have to try to convince everyone to
upgrade on your own
* core devs just provide options, and don't have to worry about being
seen as gatekeepers

The "downside" in that scenario is that users/dev aren't making much
actual use of all the choices core is offering by making different
options available; but the upside is that that choice is at least readily
available should whoever is coming up with these policy become out of
step with what people actually want.

One thing that might make an approach like that difficult is that core
has historically been happy to remove options that don't seem useful
anymore: eg the ability to turn of BIP 125 support (#16171), and priority
transactions (#9602). Perhaps that's fine if you're trying to actively
craft a single mempool/relay policy that's good enough for almost everyone
(after all, it makes the code simpler and more efficient, and reduces
the number of footguns); all you're doing is leaving a minority of people
who want weird things to run a fork, and that's going to happen anyway.

But if people are following policy developed outside of core, core
might well disagree with them and decide "no that's a stupid policy,
no one should do that" and remove some feature that others thing should
continue to be normal. Beyond the examples above, there's already talk of
removing the ability to disable fullrbf support in #26305, for instance.
If that happens, then the people maintaining the policy will instead
end up maintaining an entire fork of bitcoin core, and all we've done
is transition to people running software from a different repo, and a
different set of maintainers.

If we're really going to a world where core's eager to add new options,
and reluctant to remove them, at least if anyone at all finds them
interesting, that's presumably a non-issue, though.

Cheers,
aj

📅 Original date posted:2022-10-20 📝 Original message:On ...

2023-06-08T01:14:46+02:00

In reply to nevent1q…vff5
_________________________

📅 Original date posted:2022-10-20
📝 Original message:On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev wrote:
> The
> biggest risk in accepting bitcoin payments is in fact not zeroconf risk
> (it's actually quite easily managed),

You mean "it's quite easily managed, provided the transaction doesn't
opt-in to rbf", right? At least, that's what I understood you saying last
time; ie that if the tx signals rbf, then you just don't do zeroconf no
matter what other trustworthy signals you might see:

https://twitter.com/ziggamon/status/1435863691816275970

(rbf txs seem to have increased from 22% then to 29% now)

> it's FX risk as the merchant must
> commit to a certain BTCUSD rate ahead of time for a purchase. Over time
> some transactions lose money to FX and others earn money - that evens out
> in the end.

> But if there is an _easily accessible in the wallet_ feature to
> "cancel transaction" that means it will eventually get systematically
> abused. A risk of X% loss on many payments that's easy to systematically
> abuse is more scary than a rare risk of losing 100% of one occasional
> payment. It's already possible to execute this form of abuse with opt-in
> RBF,

If someone's going to systematically exploit your store via this
mechanism, it seems like they'd just find a single wallet with a good
UX for opt-in RBF and lowballing fees, and go to town -- not something
where opt-in rbf vs fullrbf policies make any difference at all?

It's not like existing wallets that don't let you set RBF will suddenly
get a good UX for replacing transactions just because they'd be relayed
if they did, is it?

> To successfully fool (non-RBF)
> zeroconf one needs to have access to mining infrastructure and probability
> of success is the % of hash rate controlled.

I thought the "normal" avenue for fooling non-RBF zeroconf was to create
two conflicting txs in advance, one paying the merchant, one paying
yourself, connect to many peers, relay the one paying the merchant to
the merchant, and the other to everyone else.

I'm just basing this off Peter Todd's stuff from years ago:

https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/

https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py

> Currently Lightning is somewhere around 15% of our total bitcoin payments.

So, based on last year's numbers, presumably that makes your bitcoin
payments break down as something like:

5% txs are on-chain and seem shady and are excluded from zeroconf
15% txs are lightning
20% txs are on-chain but signal rbf and are excluded from zeroconf
60% txs are on-chain and seem fine for zeroconf

> This is very much not nothing, and all of us here want Lightning to grow,
> but I think it warrants a serious discussion on whether we want Lightning
> adoption to go to 100% by means of disabling on-chain commerce.

If the numbers above were accurate, this would just mean you'd go from 60%
zeroconf/25% not-zeroconf to 85% not-zeroconf; wouldn't be 0% on-chain.

> For me
> personally it would be an easier discussion to have when Lightning is at
> 80%+ of all bitcoin transactions.

Can you extrapolate from the numbers you've seen to estimate when that
might be, given current trends? Or perhaps when fine-for-zeroconf txs
drop to 20%, since opt-in-RBF txs and considered-unsafe txs would still
work the same in a fullrbf world.

> The benefits of Lightning are many and obvious,
> we don't need to limit onchain to make Lightning more appealing.

To be fair, I think making lightning (and coinjoins) work better is
exactly what inspired this -- not as a "make on-chain worse so we look
better in comparison", but as a "making lightning work well is a bunch
of hard problems, here's the next thing we need in order to beat the
next problem".

> Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
> After interacting with users during high-fee periods I've come to not
> appreciate RBF as a solution to that issue. Most users (80% or so) simply
> don't have access to that functionality, because their wallet doesn't
> support it, or they use a custodial (exchange) wallet etc. Of those that
> have the feature - only the power users understand how RBF works, and
> explaining how to do RBF to a non-power-user is just too complex, for the
> same reason why it's complex for wallets to make sensible non-power-user UI
> around it. Current equilibrium is that mostly only power users have access
> to RBF and they know how to handle it, so things are somewhat working. But
> rolling this out to the broad market is something else and would likely
> cause more confusion.
> CPFP is somewhat more viable but also not perfect as it would require lots
> of edge case code to handle abuse vectors: What if users abuse a generous
> CPFP policy to unstuck past transactions or consolidate large wallets. Best
> is for CPFP to be done on the wallet side, not the merchant side, but there
> too are the same UX issues as with RBF.

I think if you're ruling out both merchants and users being able to add
fees to a tx to get it to confirm, then you're going to lose either way.
Txs will either expire because they've been stuck for more than a week,
and be vulnerable to replacement at that point anyway, or they'll be
dropped from mempools because they've filled up and they were the lowest
fee tx, and be vulnerable to replacement for that reason. In the expiry
case, the merchant can rebroadcast the original transaction to keep it
alive, perhaps with a good chance of beating an attacker to the punch,
but in the full mempool case, you could only do that if you were also
CPFPing it, which you already ruled out.

Cheers,
aj

📅 Original date posted:2022-10-12 📝 Original message:On ...

2023-06-08T01:14:18+02:00

In reply to nevent1q…y48l
_________________________

📅 Original date posted:2022-10-12
📝 Original message:On Tue, Oct 11, 2022 at 04:18:10PM +0000, Pieter Wuille via bitcoin-dev wrote:
> On Friday, October 7th, 2022 at 5:37 PM, Dario Sneidermanis via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Thanks for the fast answer! It seems I missed the link to the PR, sorry for the
> > confusion. I'm referring to the opt-in flag for full-RBF from #25353
> > (https://github.com/bitcoin/bitcoin/pull/25353).
> It is not clear to me why you believe the merging of this particular pull request poses an immediate risk to you.

Did you see the rest of Dario's reply, bottom-posted after the quoted
text? Namely:

On Fri, Oct 07, 2022 at 06:37:38PM -0300, Dario Sneidermanis via bitcoin-dev wrote:
> The "activation" of full-RBF after deployment works in a pretty interesting
> way:
>
> 1. If no miner is running full-RBF or there aren't easily accessible
> connected components of nodes running full-RBF connected to the miners, then
> full-RBF is mostly ineffective since replacements aren't relayed and/or mined.
> 2. There's a middle ground where *some* connected components of full-RBF
> nodes can relay and mine replacements, where some full-RBF nodes will be
> able to replace via full-RBF and some won't (depending on their peers).
> 3. With high enough adoption, the relay graph has enough density of full-RBF
> nodes that almost all full-RBF nodes can replace transactions via
> full-RBF.
>
> While there have been forks of Bitcoin Core (like Bitcoin Knots) running
> full-RBF for a while, today most nodes (by far) are running Bitcoin Core.
> So,
> Bitcoin Core adding an opt-in flag (ie. off by default) makes it easier to
> be
> picked up by most node operators. Making the flag opt-out (ie. on by
> default)
> would make it easier still. We are dealing with a gradient going from hard
> enough that we are still in 1, to easy enough that we get to 3.
>
> The question then is whether an opt-in flag for full-RBF will have enough
> adoption to get us from 1 to 2. If it isn't, then #25353 won't meet its
> objective of allowing nodes participating in multi-party funding protocols
> to assume that they can rely on full-RBF. If it is, then zero-conf applications
> will be at severe risk (per the logic in the initial email).

That logic seems reasonably sound to me:

- if adding the option does nothing, then there's no point adding it,
and no harm in restricting it to test nets only

- if adding the option does do something, then businesses using zero-conf
need to react immediately, or will go from approximately zero risk of
losing funds, to substantial risk

(I guess having the option today may allow you to manually switch your
node over to supporting fullrbf in future when the majority of the network
supports it, without needing to do an additional upgrade in the meantime;
but that seems like a pretty weak benefit)

Cheers,
aj

📅 Original date posted:2022-07-11 📝 Original message:On ...

2023-06-08T01:11:45+02:00

In reply to nevent1q…dv74
_________________________

📅 Original date posted:2022-07-11
📝 Original message:On Mon, Jul 11, 2022 at 11:12:52AM -0700, Bram Cohen via bitcoin-dev wrote:
> If transaction fees came in at an even rate over time all at the exact same
> level then they work fine for security, acting similarly to fixed block
> rewards. Unfortunately that isn't how it works in the real world.

That just becomes a market design question. There's been some trivial
effort put into that for bitcoin (ie, getting people to actually chooses
fees based on the weight of their transaction, and having weight be the
sole limiting factor for miners), but not a lot, and there's evidence
both from previous times in Bitcoin's history and from altcoin's that
the market can support higher fees.

Should we work on that today, though? It doesn't seem smart to me:
the subsidy is already quite substantial ($6.5 billion USD per year at
current prices) so raising fees to 10% of block reward would transfer
another $650M USD from bitcoin users to miners (or ASIC manfucturers
and electricity producers) each year, achieving what? Refuting some FUD?

Cheers,
aj

📅 Original date posted:2022-07-13 📝 Original message:On ...

2023-06-08T01:11:42+02:00

In reply to nevent1q…zgld
_________________________

📅 Original date posted:2022-07-13
📝 Original message:On Mon, Jul 11, 2022 at 08:21:40PM -0400, Russell O'Connor via bitcoin-dev wrote:
> Oops, you are right. We need the bribe to be the output of the coinbase,
> but due to the maturity rule, it isn't really a bribe.
> Too bad coinbases cannot take other coinbase outputs as inputs to bypass
> the maturity rule.

Sufficiently advanced tx introspection could be used for this; spend the
fees in the coinbase to address A, but also create a 0sat output via a
regular tx to the scriptPubKey "1 CSV". Note that tx's txid as B. The
next miner claims the bribe B, by spending the 0sat output to itself
with a 1-in, 1-out tx, with scriptPubKey C.

nVersion = 1
inputs = [txid=B, vout=0, scriptSig="", nSeq=1]
outputs = [value=0, scriptPubKey=C]
nLocktime = 0

Now we get back to A, and say that it's scriptPubKey uses a script that
takes "C" as input, has "B" hardcoded, calculates the txid of the tx
above, call it D, and then uses tx introspection to check that one of
the inputs of the tx has D as the txid.

> I guess that means the bribe has to be by leaving transactions in the
> mempool.

You *could* make that work if you allow tx's to use the annex to commit
to a recent block.

That is, if you just mined block 740,000 and its hash was
00000000000000000005f28764680afdbd8375216ff8f30b17eeb26bd98aac63,
you construct a bribe tx paying to "OP_1", but when you sign it,
you add "50ee070b4aa0d98aac63" as the annex (tag=ee, length=07,
value[0:3]=height=0b4aa0=470k, value[3:]=d98aac63), and (via a soft fork)
nodes then only consider that tx valid if the block at "height" ends in
"d98aac63". There's then only a 1-in-4B chance that someone who extends
a competitor to your block could claim the bribe, at a cost of 11 extra
witness bytes.

But such txs (and anything that descends from them) would become invalid
with as little as a 1-block reorg, which would pretty much defeat the
entire purpose of the maturity delay...

Cheers,
aj

📅 Original date posted:2022-07-11 📝 Original message:On ...

2023-06-08T01:11:36+02:00

In reply to nevent1q…x0mm
_________________________

📅 Original date posted:2022-07-11
📝 Original message:On Mon, Jul 11, 2022 at 08:56:04AM -0400, Erik Aronesty via bitcoin-dev wrote:
> > Alternatively, losses could be at a predictable rate that's entirely
> > different to the one Peter assumes.
> No, peter only assumes that there *is* a rate.

No, he assumes it's a constant rate. His integration step gives a
different result if lambda changes with t:
https://www.wolframalpha.com/input?i=dN%2Fdt+%3D+k+-+lambda%28t%29*N

On Mon, Jul 11, 2022 at 12:59:53PM -0400, Peter Todd via bitcoin-dev wrote:
> Give me an example of an *actual* inflation rate you expect to see, given a
> disaster of a given magnitude.

All I was doing was saying your proof is incorrect (or, rather, relies
on a highly unrealistic assumption), since I hadn't seen anybody else
point that out already.

But even if the proof were correct, I don't think it provides a useful
mechanism (since there's no reason to think miners gaining all the coins
lost in a year will be sufficient for anything), and I don't really
think the "security budget" framework (ie, that the percentage of total
supply given to miners each year is what's important for security)
you're implicitly relying on is particularly meaningful.

So no, not particularly interested in diving into it any deeper.

Cheers,
aj

📅 Original date posted:2022-07-10 📝 Original message:On ...

2023-06-08T01:11:34+02:00

In reply to nevent1q…y84t
_________________________

📅 Original date posted:2022-07-10
📝 Original message:On Sat, Jul 09, 2022 at 08:46:47AM -0400, Peter Todd via bitcoin-dev wrote:
> title: "Surprisingly, Tail Emission Is Not Inflationary"

> Of course, this isn't realistic as coins are constantly being lost due to
> deaths, forgotten passphrases, boating accidents, etc. These losses are
> independent:

This isn't necessarily true: if the losses are due to a common cause,
then they'll be heavily correlated rather than independent; for example
losses could be caused by a bug in a popular wallet/exchange software
that sends funds to invalid addresses, or by a war or natural disaster
that damages key storage hardware. They're also not independent over
time -- people improve their key storage habits over time; eg switching
to less buggy wallets/exchanges, validating addresses before using them,
using distributed multisig to prevent a localised disaster from being
catastrophic.

> the *rate* of coin loss at time $$t$$ is
> proportional to the total supply *at that moment* in time.

This is the key assumption that produces the claimed result.

If you're losing a constant fraction, x (Peter's \lambda), of Bitcoins
each year, then as soon as the supply increases enough that the constant
reward, k, corresponds to the constant fraction, ie k = x*N(t), then
you've hit an equilibrium. (Likewise if you're losing more than you're
increasing -- you just need to wait until N(t) decreases enough that you
reach the same equilibrium point) You don't really need any fancy maths.

But that assumption doesn't need to be true; coins could primarily be
lost in "black swan" events (due to bugs, wars or disasters) rather
than at a predictable rate -- with actions taken thereafter such that
the same event repeating is no longer the same level of catastrophe,
but instead another new black swan event is required to maintain the same
loss rate. If that's the case, then the rate at which funds are lost will
vary chaotically, leading to "inflationary" periods in between events,
and comparatively strong deflationary shocks when these events occur.

Alternatively, losses could be at a predictable rate that's entirely
different to the one Peter assumes.

One alternative predictable rate that seems plausible to me is if funds
are lost due to people not be careful about losing small amounts; even
though they are careful when amounts are larger. So when 10k BTC was
worth $40, maybe it doesn't matter if you misplace a hard drive with
7500 BTC on it since that's only worth $30; but by the time 7500 BTC
is worth $150M, maybe you take a bit more care with that, but are still
not too worried if you lose 1.5mBTC, since that's also only worth $30.

To mathematise that, perhaps there are K people holding Bitcoin, and with
probability p, each loses $100 (in constant 2009 dollars say, so that we
can ignore inflation) of that Bitcoin a year through carelessness. For
an equilibrium to occur in that case, you need:

N(t) + k - (100/P * Kp) = N(t)

where P is the price of Bitcoin (again in constant 2009 dollars) and k
is Peter's fixed tail subsidy. Simplifying gives:

P = K * 100p/k

But k and p are constant by assumption in this scenario, so equilibrium
is reached only if price (P) is exactly proportional to number of
users (K). That requires you to have a non-inflationary currency
(supply is constant) with constant adoption (assume K doesn't change)
that maintains a constant price (P=K*100p/k) in real terms even if the
economy is otherwise expanding or contracting.

More importantly, just from a goals point of view, x is something we
should be finding ways to minimise it over time, not leave constant.
In fact, you could argue for an even stronger goal: "the real value held
in BTC lost each year should decrease", that is, x should be decreasing
faster than 1/(N(t)*P).

Cheers,
aj

📅 Original date posted:2022-05-23 📝 Original message:On ...

2023-06-08T01:09:47+02:00

In reply to nevent1q…xs68
_________________________

📅 Original date posted:2022-05-23
📝 Original message:On Wed, May 18, 2022 at 02:40:58PM -0400, Gloria Zhao via bitcoin-dev wrote:
> > Does it make sense for these to be configurable, rather than implied
> > by the version?
> > … would it be better to either just not do sendpackages
> > at all if you're limiting ancestors in the mempool incompatibly
> Effectively: if you’re setting your ancestor/descendant limits lower than
> the default, you can’t do package relay. I wonder if this might be
> controversial, since it adds pressure to adhere to Bitcoin Core’s current
> mempool policy? I would be happy to do it this way, though - makes things
> easier to implement.

How about looking at it the other way: if you're writing a protocol that's
dependent on people seeing that a package as a whole pays a competitive
feerate, don't you want to know in advance what conditions the network
is going to impose on your transactions in order to consider them as a
package? In that case, aren't the "depth" and "size" constraints things
we should specify in a standard?

(The above's not a rhetorical question; I'm not sure what the answer is.
And even if it's "yes", maybe core's defaults should be reconsidered
rather than standardised as-is)

Worst case, you could presumably do a new package relay version with
different constraints, if needed.

> > > 5. If 'fRelay==false' in a peer's version message, the node must not
> > > send "sendpackages" to them. If a "sendpackages" message is
> > > received by a peer after sending `fRelay==false` in their version
> > > message, the sender should be disconnected.
> > Seems better to just say "if you set fRelay=false in your version
> > message, you must not send sendpackages"? You already won't do packages
> > with the peer if they don't also announce sendpackages.
> I guess, theoretically, if you allow bloom filters with this peer, it’s
> plausible they’re saying “fRelay=false, I’ll send you a bloom filter later,
> and I’ll also want to talk about packages.”

I was just meaning "it's okay to send VERSION fRelay=true then immediately
send WTXIDRELAY then immediately send SENDPACKAGES" without having to
first verify what the other guy's fRelay was set to. On the other hand,
you do already have to verify the other guy's version is high enough,
but it would be kind-of nice to move towards just announcing the features
you support, and not having to make it a multistep negotiation...

> > Maybe: "You must not send sendpackages unless you also send wtxidrelay" ?
> Do you mean if we get a verack, and the peer sent “sendpackages” but not
> “wtxidrelay,” we should disconnect them?

Yes.

> I have it as: we send a PCKG INV when this transaction’s feerate is above
> the fee filter, but one or more of its parents don’t. I don’t think using
> ancestor feerate is better.
> See this counterexample:
>
> A (0fee) has 2 kids, B (3sat/vB) and C (20sat/vB), everything’s the same
> vsize. Let’s say the fee filter is 3sat/vB.
> If we do it based on ancestor feerate, we won’t send B. But B is actually
> fine; C is paying for A.

But that only works if the receiver also has C, in which case they also
have A, and you don't need package relay to do anything with B? If they
didn't have C already, then relaying {A,B} would be a waste of time,
because {A,B} would be rejected as only paying 1.5sat/vB or whatever..

If you switch it to being:

A (0 sats, 200vB)
B (2000 sats, 200vB, spends A:0)
C (200 sats, 200vB)
D (1000 sats, 200vB, sepnds A:1, C:0)

then you get:

A alone = 0s/vB
B+A = 5s/vB

C alone = 1s/vB
D+C+A = 2s/vB
D+C = 3s/vB (B+A already at 5s/vB)

which I think recovers your point, while also having all the details
only be dealing with direct parents.

> > Are "getpckgtxns" / "pcktxns" really limited to packages, or are they
> > just a general way to request a batch of transactions?
> > Maybe call those messages "getbatchtxns" and "batchtxns" and allow them to
> > be used more generally, potentially in ways unrelated to packages/cpfp?
> Indeed, it’s a general way to request a batch of transactions. I’ll
> highlight that it is “all or nothing,” i.e. if the sender is missing any of
> them, they’ll just send a notfound.
> The idea here was to avoid downloading any transactions that can’t be
> validated right away.

Right; maybe I should just be calling a "batch of packages to be validated
together" a "tx package" in the first place.

Maybe it would be worth emphasising that you should be expecting to
validate all the txs you receive as a response to getpckgtxns (getpkgtxs
:) all at the same time, and immediately upon receiving them?

> > The "only be sent if both peers agreed to do package relay" rule could
> > simply be dropped, I think.
> Wouldn’t we need some way of saying “hey I support batchtxns?” Otherwise
> you would have to guess by sending a request and waiting to see if it’s
> ignored?

Sure, perhaps I should have said leave that rule, but drop the following
"should be disconnected" rule, so that other BIPs could add in other
ways of negotiating the connection in future? *shrug*

> > Shouldn't the sender only be sending package announcements when they know
> > the recipient will be interested in the package, based on their feefilter?
> I think there are cases where the sender doesn’t necessarily know.
> Consider this example:
>
> D (5sat/vB) has 2 parents, A (0sat/vB) and B (20sat/vB). All same size.
> Feefilter is 3sat/vB.
> If the receiver already has B, they’ll know they can just reject the
> package already based on the pckginfo.
> But the sender doesn’t really know that. The sender just knows A is below
> feerate and D is above. D is above the fee filter, and its ancestor feerate
> is above the fee filter.

The sender would also need to know whether or not there's some other
child E that pays for A sufficiently?

If you're asking for the package for "D", would a response telling you:

txid_D (500 sat, 100vB)
txid_A (0 sat, 100vB)
txid_B (2000 sat, 100 vB)

be better, in that case? Then the receiver can maybe do the logic
themselves to figure out that they already have A in their mempool
so it's fine, or not?

If you've got a package for X, and its direct parents P1..Pn, then
I think the logic would be:

* is X alone above my fee rate? no, then forget it
* otherwise, s := X.size, f := X.fees, R := [X]
* for P = P1..Pn:
* do I already have P? then skip to the next parent
* s += P.size, f += P.fees, R += [P]
* if f/s above my fee rate floor? if so, request all the txs in R

and you'd request txs if-and-only-if they're a match for you mempool rate?

If you have a tx with 20 in-mempool parents, then the pkginfo1 message
as proposed would be 737 bytes; including all the fee/size info would be
957 bytes, maybe a 30% increase. Might be worth it though?

Cheers,
aj

📅 Original date posted:2022-05-17 📝 Original message:On ...

2023-06-08T01:09:44+02:00

In reply to nevent1q…qgc5
_________________________

📅 Original date posted:2022-05-17
📝 Original message:On Tue, May 17, 2022 at 12:01:04PM -0400, Gloria Zhao via bitcoin-dev wrote:
> ====New Messages====
> Three new protocol messages are added for use in any version of
> package relay. Additionally, each version of package relay must define
> its own inv type and "pckginfo" message version, referred to in this
> document as "MSG_PCKG" and "pckginfo" respectively. See
> BIP-v1-packages for a concrete example.

The "PCKG" abbreviation threw me for a loop; isn't the usual
abbreviation "PKG" ?

> =====sendpackages=====
> |version || uint32_t || 4 || Denotes a package version supported by the
> node.
> |max_count || uint32_t || 4 ||Specifies the maximum number of transactions
> per package this node is
> willing to accept.
> |max_weight || uint32_t || 4 ||Specifies the maximum total weight per
> package this node is willing
> to accept.

Does it make sense for these to be configurable, rather than implied
by the version?

I presume the idea is to cope with people specifying different values for
-limitancestorcount or -limitancestorsize, but if people are regularly
relaying packages around, it seems like it becomes hard to have those
values really be configurable while being compatible with that?

I guess I'm asking: would it be better to either just not do sendpackages
at all if you're limiting ancestors in the mempool incompatibly; or
alternatively, would it be better to do the package relay, then reject
the particular package if it turns out too big, and log that you've
dropped it so that the node operator has some way of realising "whoops,
I'm not relaying packages properly because of how I configured my node"?

> 5. If 'fRelay==false' in a peer's version message, the node must not
> send "sendpackages" to them. If a "sendpackages" message is
> received by a peer after sending `fRelay==false` in their version
> message, the sender should be disconnected.

Seems better to just say "if you set fRelay=false in your version
message, you must not send sendpackages"? You already won't do packages
with the peer if they don't also announce sendpackages.

> 7. If both peers send "wtxidrelay" and "sendpackages" with the same
> version, the peers should announce, request, and send package
> information to each other.

Maybe: "You must not send sendpackages unless you also send wtxidrelay" ?

As I understand it, the two cases for the protocol flow are "I received
an orphan, and I'd like its ancestors please" which seems simple enough,
and "here's a child you may be interested in, even though you possibly
weren't interested in the parents of that child". I think the logic for
the latter is:

* if tx C's fee rate is less than the peer's feefilter, skip it
(will maybe treat it as a parent in some package later though)
* if tx C's ancestor fee rate is less than the peer's feefilter, skip
it?
* look at the lowest ancestor fee rate for any of C's in-mempool
parents
* if that is higher than the peer's fee filter, send a normal INV
* if it's lower than the peer's fee filter, send a PCKG INV

Are "getpckgtxns" / "pcktxns" really limited to packages, or are they
just a general way to request a batch of transactions? Particularly in
the case of requesting the parents of an orphan tx you already have,
it seems hard for the node receiving getpckgtxns to validate that the
txs are related in some way; but also it doesn't seem very necessary?

Maybe call those messages "getbatchtxns" and "batchtxns" and allow them to
be used more generally, potentially in ways unrelated to packages/cpfp?
The "only be sent if both peers agreed to do package relay" rule could
simply be dropped, I think.

> 4. The reciever uses the package information to decide how to request
> the transactions. For example, if the receiver already has some of
> the transactions in their mempool, they only request the missing ones.
> They could also decide not to request the package at all based on the
> fee information provided.

Shouldn't the sender only be sending package announcements when they know
the recipient will be interested in the package, based on their feefilter?

> =====pckginfo1=====
> {|
> | Field Name || Type || Size || Purpose
> |-
> |blockhash || uint256 || 32 || The chain tip at which this package is
> defined.
> |-
> |pckg_fee||CAmount||4|| The sum total fees paid by all transactions in the
> package.

CAmount in consensus/amount.h is a int64_t so shouldn't this be 8
bytes? If you limit a package to 101kvB, an int32_t is enough to cover
any package with a fee rate of about 212 BTC/block or lower, though.

> |pckg_weight||int64_t||8|| The sum total weight of all transactions in the
> package.

The maximum block weight is 4M, and the default -limitancestorsize
presumably implies a max package weight of 404k; seems odd to provide
a uint64_t rather than an int32_t here, which easily allows either of
those values?

> 2. ''Only 1 child with unconfirmed parents.'' The package must consist
> of one transaction and its unconfirmed parents. There must not be
> any other transactions in the package. Other dependency relationships
> may exist within the package (e.g. one parent may spend the output of
> another parent) provided that topological order is respected.

I think this means that some of the parents could also have unconfirmed
parents, but they won't be included in the package, and must be requested
via the recipient-initiated approach?

> 5. ''Total fees and weight.'' The 'total_fee' and 'total_weight'
> fields must accurately represent the sum total of all transactions'
> fees and weights as defined in BIP141, respectively.

Presumably this excludes any unconfirmed grandparents and earlier
ancestors since they aren't part of the package, in this approach? Doesn't
that make this both harder to calculate (assuming we already have
ancestor summaries) and less useful, in the case where those ancestors
have a lower fee rate?

> ''Q: Can "getpckgtxns" and "pckgtxns" messages contain only one
> transaction?''
> Yes.

This would be normal if you're requesting a single missing parent for
an orphan you've received, I think?

I'm slightly surprised the process is:

-> INV PCKG1 C
<- GETDATA PCKG1 C
-> PCKGINFO1 blockhash A B C fee weight

rather than announcing the package fee info in the first message.
But if the sender is already applying the feefilter to the package before
announcing it, it probably doesn't matter, and means you're only getting
a 32B INV from every peer, rather than a 32*(n+2) PCKGINFO1 message from
every peer.

I guess tx relay is low priority enough that it wouldn't be worth tagging
some peers as "high bandwidth" and having them immediately announce the
PCKGINFO1 message, and skip the INV/GETDATA step?

Cheers,
aj

📅 Original date posted:2022-04-19 📝 Original message:On ...

2023-06-08T01:07:23+02:00

In reply to nevent1q…fhxv
_________________________

📅 Original date posted:2022-04-19
📝 Original message:On Thu, Feb 17, 2022 at 01:58:38PM -0800, Jeremy Rubin via bitcoin-dev wrote:
> AJ Wrote (in another thread):
> > I'd much rather see some real
> > third-party experimentation *somewhere* public first, and Jeremy's CTV
> > signet being completely empty seems like a bad sign to me.

There's now been some 2,200 txs on CTV signet, of which (if I haven't
missed anything) 317 have been CTV spends:

- none have been bare CTV (ie, CTV in scriptPubKey directly, not via
p2sh/p2wsh/taproot)

- none have been via p2sh

- 3 have been via taproot:
https://explorer.ctvsignet.com/tx/f73f4671c6ee2bdc8da597f843b2291ca539722a168e8f6b68143b8c157bee20
https://explorer.ctvsignet.com/tx/7e4ade977db94117f2d7a71541d87724ccdad91fa710264206bb87ae1314c796
https://explorer.ctvsignet.com/tx/e05d828bf716effc65b00ae8b826213706c216b930aff194f1fb2fca045f7f11

The first two of these had alternative merkle paths, the last didn't.

- 314 have been via p2wsh
https://explorer.ctvsignet.com/tx/62292138c2f55713c3c161bd7ab36c7212362b648cf3f054315853a081f5808e
(don't think there's any meaningfully different examples?)

As far as I can see, all the scripts take the form:

[PUSH 32 bytes] [OP_NOP4] [OP_DROP] [OP_1]

(I didn't think DROP/1 is necessary here? Doesn't leaving the 32 byte
hash on the stack evaluate as true? I guess that means everyone's using
sapio to construct the txs?)

I don't think there's any demos of jamesob's simple-ctv-vault [0], which
I think uses a p2wsh of "IF n CSV DROP hotkey CHECKSIG ELSE lockcoldtx CTV
ENDIF", rather than taproot branches.

[0] https://github.com/jamesob/simple-ctv-vault

Likewise I don't think there's any examples of "this CTV immediately;
or if fees are too high, this other CTV that pays more fees after X
days", though potentially they could be hidden in the untaken taproot
merkle branches.

I don't think there's any examples of two CTV outputs being combined
and spent in a single transaction.

I don't see any txs with nSequence set meaningfully; though most (all?)
of the CTV spends seem to set nSequence to 0x00400000 which I think
doesn't have a different effect from 0xfffffffe?

That looks to me like there's still not much practical (vs theoretical)
exploration of CTV going on; but perhaps it's an indication that CTV
could be substantially simplified and still get all the benefits that
people are particularly eager for.

> I am unsure that "learning in public" is required --

For a consensus system, part of the learning is "this doesn't seem that
interesting to me; is it actually valuable enough to others that the
change is worth the risk it imposes on me?" and that's not something
you can do purely in private.

One challenge with building a soft fork is that people don't want to
commit to spending time building something that relies on consensus
features and run the risk that they might never get deployed. But the
reverse of that is also a concern: you don't want to deploy consensus
changes and run the risk that they won't actually turn out to be useful.

Or, perhaps, to "meme-ify" it -- part of the "proof of work" for deploying
a consensus change is actually proving that it's going to be useful.
Like sha256 hashing, that does require real work, and it might turn out
to be wasteful.

Cheers,
aj

📅 Original date posted:2022-04-25 📝 Original message:On ...

2023-06-08T01:07:06+02:00

In reply to nevent1q…afyd
_________________________

📅 Original date posted:2022-04-25
📝 Original message:On Mon, Apr 25, 2022 at 10:11:45AM -0600, Keagan McClelland via bitcoin-dev wrote:
> > Under *any* other circumstance, when they're used to activate a bad soft
> > fork, speedy trial and bip8 are the same. If a resistance method works
> > against bip8, it works against speedy trial; if it fails against speedy
> > trial, it fails against bip8.
> IIRC one essential difference between ST (which is a variant of BIP9) and
> BIP8 is that since there is no mandatory signaling during the lockin
> period,

BIP8 doesn't have mandatory signaling during the lockin period, it has
semi-mandatory [0] signalling during the must_signal period.

> you can't do a counter soft fork as easily.

The "counter" for bip8 activation is to reject any block during either
the started or must_signal phases that would meet the threshold. In that
case someone running bip8 might see blocks:

[elapsed=2010, count=1813, signal=yes]
[elapsed=2011, count=1813, signal=no]
[elapsed=2012, count=1814, signal=yes]
[elapsed=2013, count=1815, signal=yes, will-lockin!]
[elapsed=2014, count=1816, signal=yes]
[elapsed=2015, count=1816, signal=no]
[elapsed=2016, count=1816, signal=no]
[locked in!]

But running software to reject the soft fork, you would reject the
elapsed=2013 block, and any blocks that build on it. You would wait for
someone else to mine a chain that looked like:

[elapsed=2013, count=1814, signal=no]
[elapsed=2014, count=1814, signal=no]
[elapsed=2015, count=1814, signal=no]
[elapsed=2016, count=1814, signal=no]
[failed!]

That approach works *exactly* the same with speedy trial.

Jeremy's written code that does exactly this using the getdeploymentinfo
rpc to check the deployment status, and the invalidateblock rpc to
reject a block. See: https://github.com/JeremyRubin/forkd

The difference to bip8 with lot=true is that nodes running speedy trial
will reorg to follow the resisting chain if it has the most work. bip8
with lot=true nodes will not reorg to a failing chain, potentially
creating an ongoing chain split, unless one group or the other gives up,
and changes their software.

Cheers,
aj

[0] Semi-mandatory in that only "threshold" blocks must signal, so if
only 4% or 9% of miners aren't signalling and the threshold is set
at 95% or 90%, no blocks will be orphaned.

📅 Original date posted:2022-04-24 📝 Original message:On ...

2023-06-08T01:07:05+02:00

In reply to nevent1q…29ll
_________________________

📅 Original date posted:2022-04-24
📝 Original message:On Sun, Apr 24, 2022 at 12:13:08PM +0100, Jorge Timón wrote:
> You're not even considering user resistance in your cases.

Of course I am. Again:

> > My claim is that for *any* bad (evil, flawed, whatever) softfork, then
> > attempting activation via bip8 is *never* superior to speedy trial,
> > and in some cases is worse.
> >
> > If I'm missing something, you only need to work through a single example
> > to demonstrate I'm wrong, which seems like it ought to be easy... But
> > just saying "I disagree" and "I don't want to talk about that" isn't
> > going to convince anyone.

The "some cases" where bip8 with lot=true is *worse* than speedy trial
is when miners correctly see that a bad fork is bad.

Under *any* other circumstance, when they're used to activate a bad soft
fork, speedy trial and bip8 are the same. If a resistance method works
against bip8, it works against speedy trial; if it fails against speedy
trial, it fails against bip8.

> Sorry for the aggressive tone, but I when people ignore some of my points
> repeteadly, I start to wonder if they do it on purpose.

Perhaps examine the beam in your own eye.

Cheers,
aj

📅 Original date posted:2022-04-11 📝 Original message:On ...

2023-06-08T01:07:03+02:00

In reply to nevent1q…ts3w
_________________________

📅 Original date posted:2022-04-11
📝 Original message:On Fri, Apr 08, 2022 at 11:58:48AM +0200, Jorge Timón via bitcoin-dev wrote:
> On Wed, Mar 30, 2022 at 6:21 AM Anthony Towns <aj at erisian.com.au> wrote:
> > > Let's discuss those too. Feel free to point out how bip8 fails at some
> > > hypothetical cases speedy trial doesn't.
> > Any case where a flawed proposal makes it through getting activation
> > parameters set and released, but doesn't achieve supermajority hashpower
> > support is made worse by bip8/lot=true in comparison to speedy trial
> I disagree. Also, again, not the hypothetical case I want to discuss.

You just said "Let's discuss those" and "Feel free to point out how bip8
fails at some hypothetical cases speedy trial doesn't", now you're
saying it's not what you want to discuss?

But the above does include your "evil soft fork" hypothetical (I mean,
unless you think being evil isn't a flaw?). The evil soft fork gets
proposed, and due to some failure in review, merged with activation
parameters set (via either speedy trial or bip8), then:

a) supermajority hashpower support is achieved quickly:
- both speedy trial and bip8+lot=true activate the evil fork

b) supermajority hashpower support is achieved slowly:
- speedy trial does *not* activate the evil fork, as it times out
quickly
- bip8 *does* activate the fork

c) supermajority hashpower support support is never achieved:
- speedy trial does *not* activate the evil fork
- bip8+lot=false does *not* activate the evil fork, but only after a
long timeout
- bip8+lot=true *does* activate the evil fork

In case (a), they both do the same thing; in case (b) speedy trial is
superior to bip8 no matter whether lot=true/false since it blocks the
evil fork, and in case (c) speedy trial is better than lot=false because
it's quicker, and much better than lot=true because lot=true activates
the evil fork.

> > > > 0') someone has come up with a good idea (yay!)
> > > > 1') most of bitcoin is enthusiastically behind the idea
> > > > 2') an enemy of bitcoin is essentially alone in trying to stop it
> > > > 3') almost everyone remains enthusiastic, despite that guy's
> > incoherent
> > > > raving
> > > > 4') nevertheless, the enemies of bitcoin should have the power to stop
> > > > the good idea
> > > "That guy's incoherent raving"
> > > "I'm just disagreeing".
> >
> > Uh, you realise the above is an alternative hypothetical, and not talking
> > about you? I would have thought "that guy" being "an enemy of bitcoin"
> > made that obvious... I think you're mistaken; I don't think your emails
> > are incoherent ravings.
> Do you realize IT IS NOT the hypothetical case I wanted to discuss.

Yes, that's what "alternative" means: a different one.

> I'm sorry, but I'm tired of trying to explain. and quite, honestly, you
> don't seem interested in listening to me and understanding me at all, but
> only in "addressing my concerns". Obviously we understand different things
> by "addressing concerns".
> Perhaps it's the language barrier or something.

My claim is that for *any* bad (evil, flawed, whatever) softfork, then
attempting activation via bip8 is *never* superior to speedy trial,
and in some cases is worse.

If I'm missing something, you only need to work through a single example
to demonstrate I'm wrong, which seems like it ought to be easy... But
just saying "I disagree" and "I don't want to talk about that" isn't
going to convince anyone.

I really don't think the claim above should be surprising; bip8 is meant
for activating good proposals, bad ones need to be stopped in review --
as "pushd" has said in this thread: "Flawed proposal making it through
activation is a failure of review process", and Luke's said similar things
as well. The point of bip8 isn't to make it easier to reject bad forks,
it's to make it easier to ensure *good* forks don't get rejected. But
that's not your hypothetical, and you don't want to talk about all the
ways to stop an evil fork prior to an activation attempt...

Cheers,
aj

📅 Original date posted:2022-03-30 📝 Original message:On ...

2023-06-08T01:06:18+02:00

In reply to nevent1q…cgxy
_________________________

📅 Original date posted:2022-03-30
📝 Original message:On Mon, Mar 28, 2022 at 09:31:18AM +0100, Jorge Timón via bitcoin-dev wrote:
> > In particular, any approach that allows you to block an evil fork,
> > even when everyone else doesn't agree that it's evil, would also allow
> > an enemy of bitcoin to block a good fork, that everyone else correctly
> > recognises is good. A solution that works for an implausible hypothetical
> > and breaks when a single attacker decides to take advantage of it is
> > not a good design.
> Let's discuss those too. Feel free to point out how bip8 fails at some
> hypothetical cases speedy trial doesn't.

Any case where a flawed proposal makes it through getting activation
parameters set and released, but doesn't achieve supermajority hashpower
support is made worse by bip8/lot=true in comparison to speedy trial.

That's true both because of the "trial" part, in that activation can fail
and you can go back to the drawing board without having to get everyone
upgrade a second time, and also the "speedy" part, in that you don't
have to wait a year or more before you even know what's going to happen.

> > 0') someone has come up with a good idea (yay!)
> > 1') most of bitcoin is enthusiastically behind the idea
> > 2') an enemy of bitcoin is essentially alone in trying to stop it
> > 3') almost everyone remains enthusiastic, despite that guy's incoherent
> > raving
> > 4') nevertheless, the enemies of bitcoin should have the power to stop
> > the good idea
> "That guy's incoherent raving"
> "I'm just disagreeing".

Uh, you realise the above is an alternative hypothetical, and not talking
about you? I would have thought "that guy" being "an enemy of bitcoin"
made that obvious... I think you're mistaken; I don't think your emails
are incoherent ravings.

It was intended to be the simplest possible case of where someone being
able to block a change is undesirable: they're motivated by trying to
harm bitcoin, they're as far as possible from being part of some economic
majority, and they don't even have a coherent rationale to provide for
blocking the idea.

Cheers,
aj

📅 Original date posted:2022-03-25 📝 Original message:On ...

2023-06-08T01:06:16+02:00

In reply to nevent1q…5fvx
_________________________

📅 Original date posted:2022-03-25
📝 Original message:On Thu, Mar 24, 2022 at 07:30:09PM +0100, Jorge Timón via bitcoin-dev wrote:
> Sorry, I won't answer to everything, because it's clear you're not listening.

I'm not agreeing with you; that's different to not listening to you.

> In the HYPOTHETICAL CASE that there's an evil for, the fork being evil
> is a PREMISE of that hypothetical case, a GIVEN.

Do you really find people more inclined to start agreeing with you when
you begin yelling at them? When other people start shouting at you,
do you feel like it's a discussion that you're engaged in?

> Your claim that "if it's evil, good people would oppose it" is a NON
> SEQUITUR, "good people" aren't necessarily perfect and all knowing.
> good people can make mistakes, they can be fooled too.
> In the hypothetical case that THERE'S AN EVIL FORK, if "good people"
> don't complain, it is because they didn't realize that the given fork
> was evil. Because in our hypothetical example THE EVIL FORK IS EVIL BY
> DEFINITION, THAT'S THE HYPOTHETICAL CASE I WANT TO DISCUSS, not the
> hypothetical case where there's a fork some people think it's evil but
> it's not really evil.

The problem with that approach is that any solution we come up with
doesn't only have to deal with the hypotheticals you want to discuss.

In particular, any approach that allows you to block an evil fork,
even when everyone else doesn't agree that it's evil, would also allow
an enemy of bitcoin to block a good fork, that everyone else correctly
recognises is good. A solution that works for an implausible hypothetical
and breaks when a single attacker decides to take advantage of it is
not a good design.

And I did already address what to do in exactly that scenario:

> > But hey what about the worst case: what if everyone else in bitcoin
> > is evil and supports doing evil things. And maybe that's not even
> > implausible: maybe it's not an "evil" thing per se, perhaps [...]
> >
> > In that scenario, I think a hard fork is the best choice: split out a new
> > coin that will survive the upcoming crash, adjust the mining/difficulty
> > algorithm so it works from day one, and set it up so that you can
> > maintain it along with the people who support your vision, rather than
> > having to constantly deal with well-meaning attacks from "bitcoiners"
> > who don't see the risks and have lost the plot.
> >
> > Basically: do what Satoshi did and create a better system, and let
> > everyone else join you as the problems with the old one eventually become
> > unavoidably obvious.

> Once you understand what hypothetical case I'm talking about, maybe
> you can understand the rest of my reasoning.

As I understand it, your hypothetical is:

0) someone has come up with a bad idea
1) most of bitcoin is enthusiastically behind the idea
2) you are essentially alone in discovering that it's a bad idea
3) almost everyone remains enthusiastic, despite your explanations that
it's a bad idea
4) nevertheless, you and your colleagues who are aware the idea is bad
should have the power to stop the bad idea
5) bip8 gives you the power to stop the bad idea but speedy trial does not

Again given (0), I think (1) and (2) are already not very likely, and (3)
is simply not plausible. But in the event that it does somehow occur,
I disagree with (4) for the reasons I describe above; namely, that any
mechanism that did allow that would be unable to distinguish between the
"bad idea" case and something along the lines of:

0') someone has come up with a good idea (yay!)
1') most of bitcoin is enthusiastically behind the idea
2') an enemy of bitcoin is essentially alone in trying to stop it
3') almost everyone remains enthusiastic, despite that guy's incoherent
raving
4') nevertheless, the enemies of bitcoin should have the power to stop
the good idea

And, as I said in the previous mail, I think (5) is false, independently
of any of the other conditions.

> But if you don't understand the PREMISES of my example,

You can come up with hypothetical premises that invalidate bitcoin,
let alone some activation method. For example, imagine if the Federal
Reserve Board are full of geniuses and know exactly when to keep issuance
predictable and when to juice the economy? Having flexibility gives more
options than hardcoding "21M" somewhere, so clearly the USD's approach
is the way to go, and everything is just a matter of appointing the
right people to the board, not all this decentralised stuff.

The right answer is to reject bad premises, not to argue hypotheticals
that have zero relationship to reality.

Cheers,
aj

📅 Original date posted:2022-03-22 📝 Original message:On ...

2023-06-08T01:06:14+02:00

In reply to nevent1q…wwxv
_________________________

📅 Original date posted:2022-03-22
📝 Original message:On Thu, Mar 17, 2022 at 03:04:32PM +0100, Jorge Timón via bitcoin-dev wrote:
> On Tue, Mar 15, 2022 at 4:45 PM Anthony Towns <aj at erisian.com.au> wrote:
> > On Fri, Mar 11, 2022 at 02:04:29PM +0000, Jorge Timón via bitcoin-dev wrote:
> > People opposed to having taproot transactions in their chain had over
> > three years to do that coordination before an activation method was merged
> > [0], and then an additional seven months after the activation method was merged before taproot enforcement began [1].
> >
> > [0] 2018-01-23 was the original proposal, 2021-04-15 was when speedy
> > trial activation parameters for mainnet and testnet were merged.
> > [1] 2021-11-14
> People may be opposed only to the final version, but not the initial
> one or the fundamental concept.
> Please, try to think of worse case scenarios.

I mean, I've already spent a lot of time thinking through these worst
cast scenarios, including the ones you bring up. Maybe I've come up with
wrong or suboptimal conclusions about it, and I'm happy to discuss that,
but it's a bit hard to avoid taking offense at the suggestion that I
haven't even thought about it.

In the case of taproot, the final substantive update to the BIP was PR#982
merged on 2020-08-27 -- so even if you'd only been opposed to the changes
in the final version (32B pubkeys perhaps?) you'd have had 1.5 months to
raise those concerns before the code implementing taproot was merged,
and 6 months to raise those concerns before activation parameters were
set. If you'd been following the discussion outside of the code and BIP
text, in the case of 32B pubkeys, you'd have had an additional 15 months
from the time the idea was proposed on 2019-05-22 (or 2019-05-29 if you
only follow optech's summaries) until it was included in the BIP.

> Perhaps there's no opposition until after activation code has been
> released and miners are already starting to signal.
> Perhaps at that moment a reviewer comes and points out a fatal flaw.

Perhaps there's no opposition until the change has been deployed and in
wide use for 30 years. Aborting activation isn't the be-all and end-all
of addressing problems with a proposal, and it's not going to be able to
deal with every problem. For any problems that can be found before the
change is deployed and in use, you want to find them while the proposal
is being discussed.

More broadly, what I don't think you're getting is that *any* method you
can use to abort/veto/revert an activation that's occuring via BIP8 (with
or without mandatory activation), can also be used to abort/veto/revert
a speedy trial activation.

Speedy trial simply changes two things: it allows a minority (~10%)
of hashpower to abort the activation; and it guarantees a "yes" or "no"
answer within three months, while with BIP343 you initially don't know
when within a ~1 year period activation will occur.

If you're part of an (apparent) minority trying to abort/veto/reject
activation, this gives you an additional option: if you can get support
from ~10% of hashpower, you can force an initial "no" answer within
three months, at which point many of the people who were ignoring your
arguments up until then may be willing to reconsider them.

For example, I think Mark Friedenbach's concerns about unhashed pubkeys
and quantum resistance don't make sense, and (therefore) aren't widely
held; but if 10% of blocks during taproot's speedy trial had included a
tagline indicating otherwise and prevented activation, that would have
been pretty clear objective evidence that the concern was more widely
held than I thought, and might be worth reconsidering. Likewise, there
could have somehow been other problems that somehow were being ignored,
that could have similarly been reprioritised in the same way.

That's not the way that you *want* things to work -- ideally people
should be raising the concerns beforehand, and they should be taken
seriously and fixed or addressed beforehand. That did happen with Mark's
concerns -- heck, I raised it as a question ~6 hours after Greg's original
taproot proposal -- and it's directly addressed in the rationale section
of BIP341.

But in the worst case; maybe that doesn't happen. Maybe bitcoin-dev and
other places are somehow being censored, or sensible critics are being
demonised and ignored. The advantage of a hashrate veto here is that it's
hard to fake and hard to censor -- whereas with mailing list messages and
the like, it's both easy to fake (setup sockpuppets and pay troll farms)
and easy to censor (ban/moderate people for spamming say). So as a last
ditch "we've been censored, please take us seriously" method of protest,
it seems worthwhile to have to me.

(Of course, a 90% majority might *still* choose to not take the concerns
of the 10% minority seriously, and just continue to ignore the concern
and followup with an immediate mandatory activation. But if that's what
happening, you can't stop it; you can't only choose whether you want to
be a part of it, or leave)

Another example: if we'd had a 3-month speedy trial for segwit, that would
presumably have run from 2016-11-15 to 2017-02-15, and been successfully
blocked by people objecting to segwit activation. That would have left a
clean slate for either a simple and safe BIP149 style UASF activation of
segwit (shaolinfry introduced the concept of "user activated softfork
activation" in a post on 2017-02-25), or redesigning segwit to be
compatible with covert ASICBoost (which Greg Maxwell revealed publicly
on 2017-04-05, after apparently realising the potential interaction
with segwit a month earlier) and retrying segwit activation with that
approach via a new speedy trial later in the year.

> > For comparison, the UASF activation attempt for segwit took between 4
> > to 6 months to coordinate, assuming you start counting from either the
> > "user activated soft fork" concept being raised on bitcoin-dev or the
> > final params for BIP 148 being merged into the bips repo, and stop
> > counting when segwit locked in.
> That was extremely risky and could have been a disaster.

The question that comment was addressing wasn't whether BIP148 was a
good idea, it was how quickly users can coordinate a software update to
respond to consensus rules heading in a direction they find unacceptable.

All the risk and potential for disaster was due to the goals of BIP148:
to get segwit locked in prior to its activation timeout in Nov 2017,
even if only supported by a minority of hashrate.

> > 2) If that somehow doesn't work, and people are pushing ahead with a
> > consensus change despite significant reasonable opposition; the next
> > thing to do would be to establish if either side is a paper tiger
> > and setup a futures market. That has the extra benefit of giving
> > miners some information about which (combination of) rules will be
> > most profitable to mine for.
> >
> > Once that's setup and price discovery happens, one side or the other
> > will probably throw in the towel -- there's not much point have a
> > money that other people aren't interested in using. (And that more
> > or less is what happened with 2X)
> Future markets can be manipulated.

Futures markets measure people's beliefs weighted by wealth and
confidence; and unlike with hashrate signalling there's a real cost to
lying/being wrong. They're certainly not perfect, but nothing is.

> Regarding 2x, that's not how I remember it. If I remember correctly,
> "discovered" a price in btc for bcash that was
> orders of magnitude higher than what it is today.

2x and BCH were two different things.

For BCH, the only futures market was run by viabtc (one of the main
advocates of BCH), was only available a week before the split, and was
(I think?) only available to Chinese investors (at least, it was only
traded against CNY). Nevertheless, the price stabilised at around
$300USD equivalent (0.1 BTC) prior to the split, and that was fairly
in line with the spot price after the split had occurred. That price
dropped during the next two weeks to ~0.07 BTC, then rose to ~0.2 BTC,
and has since dropped to ~0.008 BTC. Coincidentally that's about $300USD
in today's market, so if you're pricing things in USD, the futures market
was actually weirdly accurate.

Viabtc also launched a market for BIP148, though in addition to the
problems with its BCH market, it was pretty unusable in that if the
BIP148-valid chain was the most-work chain, the BIP148 token wouldn't
be redeemed.

But the 2x market I was thinking of was bitfinex's; afaik bitfinex is
reasonably unbiased, the market was fairly accessible and could be traded
against the USD, and it was open for a month before the question of 2x
was definitevely resolved. The discovered price was about 0.2 BTC up
until it was announced that 2x was being abandoned at which point it
dropped to something like 0.02 BTC, representing holding costs until
the market was finalised about 2 months later.

> > If a futures market like that is going to be setup, I think it's
> > best if it happens before signalling for the soft fork starts --
> > the information miners will get from it is useful for figuring out
> > how much resources to invest in signalling, eg. I think it might even
> > be feasible to set something up even before activation parameters are
> > finalised; you need something more than just one-on-one twitter bets
> > to get meaningful price discovery, but I think you could probably
> > build something based on a reasonably unbiassed oracle declaring an
> > outcome, without precisely defined parameters fixed in a BIP.
> Whatever miners signal, until there are two chains and their real
> rewards can be traded, it's hard to know what they will mine
> afterwards.

I don't agree. The BCH futures market accurately predicted the rewards
(and hence hashrate) for mining BCH in the first couple of weeks after
the split.

On the same basis, the 2x futures market predicted that mining the 2x
chain would be massively unprofitable: immediately after the split,
both the 2x chain and the original-rules chain would have the same
difficulty and hence have the same expected cost to mine a block; but
the 2x chain would only have 25% of the reward (0.2 vs 0.8 valuation per
the futures market). Without someone subsidising the first 2016 blocks on
the 2x chain to the tune of about ~15,000 pre-split bitcoin (or ~75,000
post-split 2x coins; or between $80M-$150M USD), either directly, or by
mining at an economic loss, the 2x chain could only collapse.

BCH avoided that fate by having a new difficulty adjustment algorithm
that allowed the difficulty to drop immediately, rather than only on
the next 2016 block boundary.

> They could signal a change with 100% and then after it is activated on
> one chain and resisted on another, they 95% of them may switch to the
> old chain simply because its rewards are 20 times more valuable. This
> may happen 3 days after activation or 3 months, or more.

If it's an either-or choice, it's likely that 99.9% of hashrate will
switch even if the rewards are only 0.1 times more valuable (or 1.1
times as valuable if you prefer). That's why you run a futures market,
to figure out which will be more valuable and by how much.

We saw the either-or case happen with BCH vs BTC; the difficulty of BCH
would drop quickly due to the "EDA", but only rise slowly, making BCH
mining more profitable for an extended period so that opportunistic miners
would switch to BCH for a while until it got expensive again then switch
back to BTC, causing both chains' hashrate to be unstable.

But if you don't hard fork to a different difficulty adjustment algorithm
the way BCH did on day one, then it doesn't matter how long miners
don't mine on your chain, your chain's difficulty won't adjust, and so
you'll need to instead wait until BTC's difficulty doubles or more,
or its reward halves or more, or some combination of the two. That's
likely much more than 3 months away. I can't imagine why anyone would
still care about your proposed chain months or years later.

So hardforking in merge-mining (so it's not an either-or question) or
a new difficulty adjustment algorithm (so you don't have to wait months
or years) seems a much more realistic approach.

> > So if acting like reasonable people and talking it through doesn't
> > work, this seems like the next step to me.
> Not to me, but you're free to create your future markets or trade in them.
> I wouldn't do any of them, and I would advice against it.

*shrug* Do what you like (and I mean, I don't trade in futures markets
either) but I think you'd be missing out on very useful information,
and losing a chance for people who aren't devs to offer tangible and
objective support for your cause.

> > I think the speedy trial approach here is ideal for a last ditch
> > "everyone stays on the same chain while avoiding this horrible change"
> > attempt. The reason being that it allows everyone to agree to not
> > adopt the new rules with only very little cost: all you need is for
> > 10% of hashpower to not signal over a three month period.
> No, 10% of hashpower is not "very little cost", that's very expensive.

If we're talking about consensus changes, the target is 100% of hashpower,
and also something approaching 100% of nodes. By comparison 10% of
hashpower is *much* cheaper, especially when the 100% have to actively
upgrade in order to support, while the 10% just have to not do anything
in order to oppose.

To be clear: You don't have to setup the 10% of hashpower yourself,
you just have to convince the existing owners of 10% of hashpower to
not actively support the change.

> > That's cheaper than bip9 (5% over 12 months requires 2x the
> > cumulative hashpower), and much cheaper than bip8 which requires
> > users to update their software
> Updating software is not expensive. the code for bip8 could have been
> merged long before taproot was even initially proposed.
> It could be merged now before another proposal.

The BIP8 spec we have today is very different to the BIP8 spec when
taproot was merged, let alone before it was even proposed. As it was,
it had serious problems that hadn't been addressed, and the version we
have today likewise has significant problems that haven't been addressed,
which is why it wasn't and shouldn't be merged.

> Updating software is certainly not more expensive than getting 10% of
> the hashrate.

Updating software (or not updating software) is precisely *how* to get
10% of hashrate. It's not more or less expensive -- it *is* the expense.

> > 4) At this point, if you were able to prevent activation, hopefully
> > that's enough of a power move that people will take your concerns
> > seriously, and you get a second chance at step (1). If that still
> > results in an impasse, I'd expect there to be a second, non-speedy
> > activation of the soft fork, that either cannot be blocked at all, or
> > cannot be blocked without having control of at least 60% of hashpower.
> And if you never got 10% hashpower, we move to the next step, I guess.

Yes; you then move to the next step knowing that what level of
interest/support you actually have.

> > 5) If you weren't able to prevent activation (whether or not you
> > prevented speedy trial from working), then you should have a lot
> > of information:
> >
> > - you weren't able to convince people there was a problem
> >
> > - you either weren't in the economic majority and people don't
> > think your concept of bitcoin is more valuable (perhaps they
> > don't even think it's valuable enough to setup a futures market
> > for you)
> >
> > - you can't get control of even 10% of hashpower for a few months
> >
> > and your only option is to accept defeat or create a new chain.
> What if it's still the other people who are lacking information?

If it's other people that lack information, there's two options. One,
you might be able to explain things to them, so that they learn and gain
the information. The other is that for whatever reason they're not willing
to listen to the truth and will remain ignorant. If it's the first case,
you'd have succeeded in an earlier step. If it's the latter, then it's
not something you can change, and it doesn't really matter in how you
decide what to do next.

> It wouldn't be a new chain, it would be the old chain without the new
> evil change, until you manage to show the other people that the change
> was indeed evil.
> Remember, in this example, the new change being evil is not a
> possibility, but an assumption.

It's extremely unhelpful to call things "evil" if what you want is a
reasonable discussion. And if reasonable discussion isn't what you want,
you're in the wrong place.

At this point in the hypothetical you're in a small minority, and have
been unable to convince people of your point of view. Calling the people
you disagree with "evil" (and saying they support something that's evil
is exactly that) isn't going to improve your situation, and doing it in
a hypothetical sure feels like bad faith.

> What you're arguing is "if you haven't been able to stop the evil
> change, then perhaps it wasn't evil all along and the people trying to
> resist it were wrong and don't know it".

If it's an evil change, then good people will oppose it. You've tried
convincing devs in the "discuss the proposal" stage, whales in the
"futures market" stage, and miners in the "hashpower signalling" phase,
and failed each time because the good people in each of those groups
haven't opposed it. So yes, I think the most likely explanation is that
you're wrong in thinking it's evil.

But hey what about the worst case: what if everyone else in bitcoin
is evil and supports doing evil things. And maybe that's not even
implausible: maybe it's not an "evil" thing per se, perhaps it's simply
equally "misguided" as the things that central banks or wall street or
similar are doing today. Perhaps bitcoin becomes the world currency,
and in 100 or 200 years time, whether through complacency and forgetting
the lessons of the past, or too much adherence to dogma that no longer
matches reality, or just hitting some new problem that's never been seen
before and an inability to perfectly predict the future, and as a result
most of the world opts into some change that will cause bitcoin to fail.

In that scenario, I think a hard fork is the best choice: split out a new
coin that will survive the upcoming crash, adjust the mining/difficulty
algorithm so it works from day one, and set it up so that you can
maintain it along with the people who support your vision, rather than
having to constantly deal with well-meaning attacks from "bitcoiners"
who don't see the risks and have lost the plot.

Basically: do what Satoshi did and create a better system, and let
everyone else join you as the problems with the old one eventually become
unavoidably obvious.

> But that contradicts the premise: an evil change being deployed using
> speedy trial.

Again: any change that could be avoided if it were deployed via BIP8,
can also be avoided *by the exact same techniques* if it were deployed
via speedy trial or a similar approach.

> > Since your new chain won't have a hashpower majority, you'll likely
> > have significant problems if you don't hard fork in a change to
> > how proof-of-work works; my guess is you'd either want to switch
> > to a different proof-of-work algorithm, or make your chain able
> > to be merge-mined against bitcoin, though just following BCH/BSV's
> > example and tweaking the difficulty adjustment to be more dynamic
> > could work too.
> No, I disagree. You'll just get the hashpower you pay for with subsidy and fees.

The value of the subsidy is something you can directly figure out from
running a futures market; and unless you're deliberately subsidising fees,
they'll almost certainly be ~0.

> > (For comparison, apparently BCH has 0.8% of bitcoin's hashrate,
> > BSV has 0.2%. Meanwhile, Namecoin, RSK and Syscoin, which support
> > merge-mining, are apparently at 68%, 42% and 17% respectively)
> Google tells me 0.0073BTC.

I think you're reading too much precision into those numbers? When
I looked again the other day, I got a figure of 0.66%; today I get
0.75%. I'm sure I rounded whatever figure I saw to one significant figure,
so it might have been 0.75% then too.

https://bitinfocharts.com/comparison/bitcoin-hashrate.html#3y
https://bitinfocharts.com/comparison/bitcoin%20cash-hashrate.html#3y

> In perfect competition and leaving fees aside (in which probably
> bitcoin wins too), BCH should have approximately 0.0073% the hashrate
> bitcoin hash.

Oh, or you're just getting the percentage conversion wrong -- 0.0073
BTC is 0.73% of a BTC, and thus it would be expected to have about 0.73%
of the hashrate.

> > At the point that you're doing a hard fork, making a clean split is
> > straightforward: schedule the hard fork for around the same time as
> > the start of enforcement of the soft fork you oppose, work out how
> > to make sure you're on your own p2p network, and figure out how
> > exchanges and lightning channels and everything else are going to
> > cope with the coin split.
> You shouldn't need to do a hardfork to resist a consensus change you don't like.

Of course; that's why option (1) is to talk to people about why it's a
bad idea so it doesn't get proposed in the first place.

But if you want to resist a consensus change that is overwhelmingly
supported by the rest of the bitcoin economy, and for which your reasons
aren't even considered particularly logical by everyone else, then yeah,
if you really want to go off on your own because everyone else is wrong,
you *should* do a hardfork.

If a change doesn't have overwhelming support, then hopefully the costs
to get 90% of hashrate signalling is a significant impediment. If you do
have overwhelming support, then the cost to get 90% of hashrate signalling
(or even apparently 99.8%, see getdeploymentinfo on block 693503) --
doesn't seem to be too bad.

> "around the same time", with bip8 and the resistance mechanism
> proposed by luke, it doesn't need to be "around the same time
> according to some expert who will tell you what to put in your
> software", but "exactly at the same time, and you only need to know
> which pproposal version bit you're opposing".

(Arguing semantics: You can't do the split at exactly the same time,
because the split starts with each chain finding a new block, and blocks
are found probabilistically depending on hashrate, so they won't be found
at the same time. Or, alternatively, the split happens whenever either
client considers the other chain invalid, and always happens at the
"same" time)

If you want to do things at exactly the same height, you can do that if
the soft fork is activated by speedy trial as well.

I'd say the same height approach works better on speedy trial than
with BIP8/BIP343, since with speedy trial signalling is only for a
short period, and hence you know well in advance if and when you'll be
splitting, whereas with an extended signalling period that goes for a
year past the minimum activation height, you may find yourself splitting
at any point in that year with as little as two week's notice.

If I were doing a hardfork coin split to avoid following some new soft
forked rules that I think were horrible, I think I'd prefer to do the
split in advance of the softfork -- that way exchanges/wallets/lightning
channels/etc that have to do work to deal with the coinsplit aren't
distracted by simultaneously having to pay attention to the new softfork.
YMMV of course.

> Yeah, great example. It doesn't have to be an "evil change" as such,
> it can just be a "deeply wrong change" or something.
> Or if we were using BIP8 and had the resistance mechanism proposed by
> luke, all we would need to do is change one line and recompile:
> I don't remember his enumeration constants but, something like...
> - bip8Params.EvilProposalActivationMode = FORCE_ACTIVATION;
> + bip8Params.EvilProposalActivationMode = FORBID_ACTIVATION;
> Say we discover it 3 days before forced activation.
> Well, that would still be much less rushed that the berkeleyDB thing,
> wouldn't it?

No, exactly the opposite.

In order to abort a BIP8 activation, 100% of hashpower and 100% of
node software needs to downgrade from anything that specifies BIP8 with
mandatory activation.

The "berkelyDB thing" was an accidental hard fork due to the updated
software with leveldb being able to accept larger blocks than the old
bdb-based bitcoind could.

The result was two chains: one with a large block in it, that could
only be validated by the newer software, and a less work chain with only
smaller chains, that could be validated by both versions of the software;
the problem was ~60% of hashpower was on the larger-block chain, but
many nodes including those with ~40% hashpower. The problem was quickly
mitigated by encouraging a majority of hashpower to downgrade to the
old software, resulting in them rejecting the larger-block chain,
at which point a majority of hashpower was mining the smaller-block
chain, and the smaller-block chain eventually having more work than
the larger-block chain. At that point any newer nodes reorged to the
more-work, smaller-block chain, and everyone was following the same chain.

What that means is that the operators of *two* pools downgraded their
software, and everything was fixed. That's a *lot* less work than
everyone who upgraded their node having to downgrade/re-update, and
it was done that way to *avoid* having to rush to get everyone to do
an emergency update of their node software to be compatible with the
larger-block chain.

See https://bitcoin.org/en/alert/2013-03-11-chain-fork
and https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki

On the other hand, that approach only works because it takes advantage
of a lot of hashrate being centralised around a few pools; if we succeed
in making block construction more decentralised, solutions here will
only become harder.

> If there's only opposition after it is deployed, whatever the
> activation mechanism, in that particular case, would be irrelevant.

Once you've released software with a softfork activated via BIP8 with
mandatory activation (ie, lot=true), and it has achieved any significant
adoption, the soft fork is already deployed and you need to treat it as
such. If you want to have an easier way of undoing the softfork than
you would have for one that's already active on the network, you need
a different activation method than BIP8/lot=true.

Cheers,
aj

📅 Original date posted:2022-03-15 📝 Original message:On ...

2023-06-08T01:06:13+02:00

In reply to nevent1q…pkrc
_________________________

📅 Original date posted:2022-03-15
📝 Original message:On Fri, Mar 11, 2022 at 02:04:29PM +0000, Jorge Timón via bitcoin-dev wrote:
> > Thirdly, if some users insist on a chain where taproot is
> > "not activated", they can always softk-fork in their own rule that
> > disallows the version bits that complete the Speedy Trial activation
> > sequence, or alternatively soft-fork in a rule to make spending from (or
> > to) taproot addresses illegal.
> Since it's about activation in general and not about taproot specifically,
> your third point is the one that applies.
> Users could have coordinated to have "activation x" never activated in
> their chains if they simply make a rule that activating a given proposal
> (with bip8) is forbidden in their chain.
> But coordination requires time.

People opposed to having taproot transactions in their chain had over
three years to do that coordination before an activation method was merged
[0], and then an additional seven months after the activation method was merged before taproot enforcement began [1].

[0] 2018-01-23 was the original proposal, 2021-04-15 was when speedy
trial activation parameters for mainnet and testnet were merged.
[1] 2021-11-14

For comparison, the UASF activation attempt for segwit took between 4
to 6 months to coordinate, assuming you start counting from either the
"user activated soft fork" concept being raised on bitcoin-dev or the
final params for BIP 148 being merged into the bips repo, and stop
counting when segwit locked in.

> Please, try to imagine an example for an activation that you wouldn't like
> yourself. Imagine it gets proposed and you, as a user, want to resist it.

Sure. There's more steps than just "fork off onto a minority chain"
though.

1) The first and most important step is to explain why you want to
resist it, either to convince the proposers that there really is
a problem and they should stand down, or so someone can come up
with a way of fixing the proposal so you don't need to resist it.
Ideally, that's all that's needed to resolve the objections. (That's
what didn't happen with opposition to segwit)

2) If that somehow doesn't work, and people are pushing ahead with a
consensus change despite significant reasonable opposition; the next
thing to do would be to establish if either side is a paper tiger
and setup a futures market. That has the extra benefit of giving
miners some information about which (combination of) rules will be
most profitable to mine for.

Once that's setup and price discovery happens, one side or the other
will probably throw in the towel -- there's not much point have a
money that other people aren't interested in using. (And that more
or less is what happened with 2X)

If a futures market like that is going to be setup, I think it's
best if it happens before signalling for the soft fork starts --
the information miners will get from it is useful for figuring out
how much resources to invest in signalling, eg. I think it might even
be feasible to set something up even before activation parameters are
finalised; you need something more than just one-on-one twitter bets
to get meaningful price discovery, but I think you could probably
build something based on a reasonably unbiassed oracle declaring an
outcome, without precisely defined parameters fixed in a BIP.

So if acting like reasonable people and talking it through doesn't
work, this seems like the next step to me.

3) But maybe you try both those and they fail and people start trying
to activate the soft fork (or perhaps you just weren't paying
attention until it was too late, and missed the opportunity).

I think the speedy trial approach here is ideal for a last ditch
"everyone stays on the same chain while avoiding this horrible change"
attempt. The reason being that it allows everyone to agree to not
adopt the new rules with only very little cost: all you need is for
10% of hashpower to not signal over a three month period.

That's cheaper than bip9 (5% over 12 months requires 2x the
cumulative hashpower), and much cheaper than bip8 which requires
users to update their software

4) At this point, if you were able to prevent activation, hopefully
that's enough of a power move that people will take your concerns
seriously, and you get a second chance at step (1). If that still
results in an impasse, I'd expect there to be a second, non-speedy
activation of the soft fork, that either cannot be blocked at all, or
cannot be blocked without having control of at least 60% of hashpower.

5) If you weren't able to prevent activation (whether or not you
prevented speedy trial from working), then you should have a lot
of information:

- you weren't able to convince people there was a problem

- you either weren't in the economic majority and people don't
think your concept of bitcoin is more valuable (perhaps they
don't even think it's valuable enough to setup a futures market
for you)

- you can't get control of even 10% of hashpower for a few months

and your only option is to accept defeat or create a new chain.

Since your new chain won't have a hashpower majority, you'll likely
have significant problems if you don't hard fork in a change to
how proof-of-work works; my guess is you'd either want to switch
to a different proof-of-work algorithm, or make your chain able
to be merge-mined against bitcoin, though just following BCH/BSV's
example and tweaking the difficulty adjustment to be more dynamic
could work too.

(For comparison, apparently BCH has 0.8% of bitcoin's hashrate,
BSV has 0.2%. Meanwhile, Namecoin, RSK and Syscoin, which support
merge-mining, are apparently at 68%, 42% and 17% respectively)

At the point that you're doing a hard fork, making a clean split is
straightforward: schedule the hard fork for around the same time as
the start of enforcement of the soft fork you oppose, work out how
to make sure you're on your own p2p network, and figure out how
exchanges and lightning channels and everything else are going to
cope with the coin split.

6) There's potentially also the case where a soft fork locks-in
and later everyone realises the people who were opposing it were
right all along and the fork is a really bad idea.

If everyone agreed that some idea was irredeemably bad -- eg,
OP_VERIF -- then we could soft fork them out and just forbid
blocks/transactions that attempt to use them. Or conceivably we could
do a hardfork and have more options about how to fix the problem.

That's already true for various features that satoshi included and
that are still available today -- eg the CHECKMULTISIG bug where
it pops one too many things from the stack, or the timewarp bug,
or CODESEP/FindAndDelete validation complexity.

Those can be complicated to fix though; if people have lost their
private keys and are sitting on (timelocked?) pre-signed transactions,
even fixing the problem via a hard fork could cause loss of funds.

But those are really progressively worse options -- just talking to each
other and solving the problem before it's a problem is a better approach
than risking money on futures markets; and that's better than having to
buy hashpower to try to block something that other people want; and that's
better than forking the chain; and even that's better than doing things
that might cause irretrievable loss of funds from random other bitcoiners.

Cheers,
aj

📅 Original date posted:2022-03-10 📝 Original message:On ...

2023-06-08T01:05:22+02:00

In reply to nevent1q…cvhz
_________________________

📅 Original date posted:2022-03-10
📝 Original message:On Tue, Mar 08, 2022 at 06:54:56PM -0800, Bram Cohen via bitcoin-dev wrote:
> On Mon, Mar 7, 2022 at 5:27 PM Anthony Towns <aj at erisian.com.au> wrote:
> > One way to match the way bitcoin do things, you could have the "list of
> > extra conditions" encoded explicitly in the transaction via the annex,
> > and then check the extra conditions when the script is executed.
> The conditions are already basically what's in transactions. I think the
> only thing missing is the assertion about one's own id, which could be
> added in by, in addition to passing the scriptpubkey the transaction it's
> part of, also passing in the index of inputs which it itself is.

To redo the singleton pattern in bitcoin's context, I think you'd have
to pass in both the full tx you're spending (to be able to get the
txid of its parent) and the full tx of its parent (to be able to get
the scriptPubKey that your utxo spent) which seems klunky but at least
possible (you'd be able to drop the witness data at least; without that
every tx would be including the entire history of the singleton).

> > > A nice side benefit of sticking with the UTXO model is that the soft fork
> > > hook can be that all unknown opcodes make the entire thing automatically
> > > pass.
> > I don't think that works well if you want to allow the spender (the
> > puzzle solution) to be able to use opcodes introduced in a soft-fork
> > (eg, for graftroot-like behaviour)?
> This is already the approach to soft forking in Bitcoin script and I don't
> see anything wrong with it.

It's fine in Bitcoin script, because the scriptPubKey already commits to
all the opcodes that can possibly be used for any particular output. With
a lisp approach, however, you could pass in additional code fragments
to execute. For example, where you currently say:

script: [pubkey] CHECKSIG
witness: [64B signature][0x83]

(where 0x83 is SINGLE|ANYONECANPAY) you might translate that to:

script: (checksig pubkey (bip342-txmsg 3) 2)
witness: signature 0x83

where "3" grabs the sighash byte, and "2" grabs the signature. But you
could also translate it to:

script: (checksig pubkey (sha256 3 (a 3)) 2)
witness: signature (bip342-txmsg 0x83)

where "a 3" takes "(bip342-txmsg 0x83)" then evaluates it, and (sha256
3 (a 3)) makes sure you've signed off on both how the message was
constructed as well as what the message was. The advantage there is that
the spender can then create their own signature hashes however they like;
even ones that hadn't been thought of when the output was created.

But what if we later softfork in a bip118-txmsg for quick and easy
ANYPREVOUT style-signatures, and want to use that instead of custom
lisp code? You can't just stick (softfork C (bip118-txmsg 0xc3)) into
the witness, because it will evaluate to nil and you won't be signing
anything. But you *could* change the script to something like:

script: (softfork C (q checksigverify pubkey (a 3) 2))
witness: signature (bip118-txmsg 0xc3)

But what happens if the witness instead has:

script: (softfork C (q checksigverify pubkey (a 3) 2))
witness: fake-signature (fakeopcode 0xff)

If softfork is just doing a best effort for whatever opcodes it knows
about, and otherwise succeeding, then it has to succeed, and your
script/output has become anyone-can-spend.

On the other hand, if you could tell the softfork op that you only wanted
ops up-to-and-including the 118 softfork, then it could reject fakeopcode
and fail the script, which I think gives the desirable behaviour.

Cheers,
aj

📅 Original date posted:2022-03-07 📝 Original message:On ...

2023-06-08T01:05:15+02:00

In reply to nevent1q…l7yw
_________________________

📅 Original date posted:2022-03-07
📝 Original message:On Sun, Mar 06, 2022 at 10:26:47PM -0800, Bram Cohen via bitcoin-dev wrote:
> > After looking into it, I actually think chia lisp [1] gets pretty much all
> > the major design decisions pretty much right. There are obviously a few
> > changes needed given the differences in design between chia and bitcoin:
> Bitcoin uses the UTXO model as opposed to Chia's Coin Set model. While
> these are close enough that it's often explained as Chia uses the UTXO
> model but that isn't technically true. Relevant to the above comment is
> that in the UTXO model transactions get passed to a scriptpubkey and it
> either assert fails or it doesn't, while in the coin set model each puzzle
> (scriptpubkey) gets run and either assert fails or returns a list of extra
> conditions it has, possibly including timelocks and creating new coins,
> paying fees, and other things.

One way to match the way bitcoin do things, you could have the "list of
extra conditions" encoded explicitly in the transaction via the annex,
and then check the extra conditions when the script is executed.

> If you're doing everything from scratch it's cleaner to go with the coin
> set model, but retrofitting onto existing Bitcoin it may be best to leave
> the UTXO model intact and compensate by adding a bunch more opcodes which
> are special to parsing Bitcoin transactions. The transaction format itself
> can be mostly left alone but to enable some of the extra tricks (mostly
> implementing capabilities) it's probably a good idea to make new
> conventions for how a transaction can have advisory information which
> specifies which of the inputs to a transaction is the parent of a specific
> output and also info which is used for communication between the UTXOs in a
> transaction.

I think the parent/child coin relationship is only interesting when
"unrelated" spends can assert that the child coin is being created -- ie
things along the lines of the "transaction sponsorship" proposal. My
feeling is that complicates the mempool a bit much, so is best left for
later, if done at all.

(I think the hard part of managing the extra conditions is mostly
in keeping it efficient to manage the mempool and construct the most
profitable blocks/bundles, rather than where the data goes)

> But one could also make lisp-generated UTXOs be based off transactions
> which look completely trivial and have all their important information be
> stored separately in a new vbytes area. That works but results in a bit of
> a dual identity where some coins have both an old style id and a new style
> id which gunks up what

We've already got a txid and a wtxid, adding more ids seems best avoided
if possible...

> > Pretty much all the opcodes in the first section are directly from chia
> > lisp, while all the rest are to complete the "bitcoin" functionality.
> > The last two are extensions that are more food for thought than a real
> > proposal.
> Are you thinking of this as a completely alternative script format or an
> extension to bitcoin script?

As an alternative to tapscript, so when constructing the merkle tree of
scripts for a taproot address, you could have some of those scripts be
in tapscript as it exists today with OP_CHECKSIG etc, and others could
be in lisp. (You could then have an entirely lisp-based sub-merkle-tree
of lisp fragments via sha256tree or similar of course)

> They're radically different approaches and
> it's hard to see how they mix. Everything in lisp is completely sandboxed,
> and that functionality is important to a lot of things, and it's really
> normal to be given a reveal of a scriptpubkey and be able to rely on your
> parsing of it.

The above prevents combining puzzles/solutions from multiple coin spends,
but I don't think that's very attractive in bitcoin's context, the way
it is for chia. I don't think it loses much else?

> > There's two ways to think about upgradability here; if someday we want
> > to add new opcodes to the language -- perhaps something to validate zero
> > knowledge proofs or calculate sha3 or use a different ECC curve, or some
> > way to support cross-input signature aggregation, or perhaps it's just
> > that some snippets are very widely used and we'd like to code them in
> > C++ directly so they validate quicker and don't use up as much block
> > weight. One approach is to just define a new version of the language
> > via the tapleaf version, defining new opcodes however we like.
> A nice side benefit of sticking with the UTXO model is that the soft fork
> hook can be that all unknown opcodes make the entire thing automatically
> pass.

I don't think that works well if you want to allow the spender (the
puzzle solution) to be able to use opcodes introduced in a soft-fork
(eg, for graftroot-like behaviour)?

> Chia's approach to transaction fees is essentially identical to Bitcoin's
> although a lot fewer things in the ecosystem support fees due to a lack of
> having needed it yet. I don't think mempool issues have much to do with
> choice of scriptpubkey language. which is mostly about adding in covenants
> and capabilities.

Having third parties be able to link their spends to yours complicates
mempool behaviour a fair bit (see the discussions on pinning wrt
lightning txs -- and that's only with direct participants being able to
link transactions). But it's very much a second-order effect compared
to having fees being a meaningful thing at all. It took, what, six or
seven years for people to start actually using dynamic fees in bitcoin?

> I previously posted some thoughts about this here:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019722.html

I'm pretty skeptical about having a database of large script snippets
that will hopefully be reused in the future.

On Mon, Mar 07, 2022 at 10:56:38PM +0000, ZmnSCPxj via bitcoin-dev wrote:
> > while in the coin set model each puzzle (scriptpubkey) gets run and either assert fails or returns a list of extra conditions it has, possibly including timelocks and creating new coins, paying fees, and other things.
> Does this mean it basically gets recursive covenants?

In chia the "scriptPubKey" is the hash of a lisp program, and when you
create a new coin, the "scriptPubKey" of the newly generated coin is
also the output of a lisp program. So writing a quine gets you general
recursive covenants in a pretty straight forward way, as I understand it.

> > > - serialization seems to be a bit verbose -- 100kB of serialized clvm
> > > code from a random block gzips to 60kB; optimising the serialization
> > > for small lists, and perhaps also for small literal numbers might be
> > > a feasible improvement; though it's not clear to me how frequently
> > > serialization size would be the limiting factor for cost versus
> > > execution time or memory usage.
> > A lot of this is because there's a hook for doing compression at the consensus layer which isn't being used aggressively yet. That one has the downside that the combined cost of transactions can add up very nonlinearly, but when you have constantly repeated bits of large boilerplate it gets close and there isn't much of an alternative. That said even with that form of compression maxxed out it's likely that gzip could still do some compression but that would be better done in the database and in wire protocol formats rather than changing the format which is hashed at the consensus layer.
> How different is this from "jets" as proposed in Simplicity?

Rather than a "transaction" containing "inputs/outputs", chia has spend
bundles that spend and create coins; and spend bundles can be merged
together, so that a block only has a single spend bundle. That spend
bundle joins all the puzzles (the programs that, when hashed match
the scriptPubKey) and solutions (scriptSigs) for the coins being spent
together.

I /think/ the compression hook would be to allow you to have the puzzles
be (re)generated via another lisp program if that was more efficient
than just listing them out. But I assume it would be turtles, err,
lisp all the way down, no special C functions like with jets.

> > > Pretty much all the opcodes in the first section are directly from chia
> > > lisp, while all the rest are to complete the "bitcoin" functionality.
> > > The last two are extensions that are more food for thought than a real
> > > proposal.
> >
> > Are you thinking of this as a completely alternative script format or an extension to bitcoin script? They're radically different approaches and it's hard to see how they mix. Everything in lisp is completely sandboxed, and that functionality is important to a lot of things, and it's really normal to be given a reveal of a scriptpubkey and be able to rely on your parsing of it.
>
> I believe AJ is proposing a completely alternative format to OG Bitcoin SCRIPT.
> Basically, as I understand it, nothing in the design of Tapscript versions prevents us from completely changing the interpretation of Tapscript bytes, and use a completely different language.
> That is, we could designate a new Tapscript version as completely different from OG Bitcoin SCRIPT.

BIP342 defines tapscript, and it's selected by the taproot leaf version
0xc0; this hypothetical lispy "btcscript" might be selected via taproot
leaf version 0xc2 or similar (elements' tapscript variant is selected
via version 0xc4).

Cheers,
aj

📅 Original date posted:2022-03-03 📝 Original message:On ...

2023-06-08T01:05:11+02:00

In reply to nevent1q…6yn7
_________________________

📅 Original date posted:2022-03-03
📝 Original message:On Sun, Feb 27, 2022 at 04:34:31PM +0000, ZmnSCPxj via bitcoin-dev wrote:
> In reaction to this, AJ Towns mailed me privately about some of his
> thoughts on this insane `OP_EVICT` proposal.
> He observed that we could generalize the `OP_EVICT` opcode by
> decomposing it into smaller parts, including an operation congruent
> to the Scheme/Haskell/Scala `map` operation.

At much the same time Zman was thinking about OP_FOLD and in exactly the
same context, I was wondering what the simplest possible language that
had some sort of map construction was -- I mean simplest in a "practical
engineering" sense; I think Simplicity already has the Euclidean/Peano
"least axioms" sense covered.

The thing that's most appealing to me about bitcoin script as it stands
(beyond "it works") is that it's really pretty simple in an engineering
sense: it's just a "forth" like system, where you put byte strings on a
stack and have a few operators to manipulate them. The alt-stack, and
supporting "IF" and "CODESEPARATOR" add a little additional complexity,
but really not very much.

To level-up from that, instead of putting byte strings on a stack, you
could have some other data structure than a stack -- eg one that allows
nesting. Simple ones that come to mind are lists of (lists of) byte
strings, or a binary tree of byte strings [0]. Both those essentially
give you a lisp-like language -- lisp is obviously all about lists,
and a binary tree is just made of things or pairs of things, and pairs
of things are just another way of saying "car" and "cdr".

A particular advantage of lisp-like approaches is that they treat code
and data exactly the same -- so if we're trying to leave the option open
for a transaction to supply some unexpected code on the witness stack,
then lisp handles that really naturally: you were going to include data
on the stack anyway, and code and data are the same, so you don't have
to do anything special at all. And while I've never really coded in
lisp at all, my understanding is that its biggest problems are all about
doing things efficiently at large scales -- but script's problem space
is for very small scale things, so there's at least reason to hope that
any problems lisp might have won't actually show up for this use case.

So, to me, that seemed like something worth looking into...

After looking into it, I actually think chia lisp [1] gets pretty much all
the major design decisions pretty much right. There are obviously a few
changes needed given the differences in design between chia and bitcoin:

- having secp256k1 signatures (and curve operations), instead of
BLS12-381 ones

- adding tx introspection instead of having bundle-oriented CREATE_COIN,
and CREATE/ASSERT results [10]

and there are a couple of other things that could maybe be improved
upon:

- serialization seems to be a bit verbose -- 100kB of serialized clvm
code from a random block gzips to 60kB; optimising the serialization
for small lists, and perhaps also for small literal numbers might be
a feasible improvement; though it's not clear to me how frequently
serialization size would be the limiting factor for cost versus
execution time or memory usage.

- I don't think execution costing takes into account how much memory
is used at any one time, just how much was allocated in total; so
the equivalent of (OP_DUP OP_DROP OP_DUP OP_DROP ..) only has the
allocations accounted for, with no discount given for the immediate
freeing, so it gets treated as having the same cost as (OP_DUP
OP_DUP .. OP_DROP OP_DROP ..). Doing it that way would be a worse
than how bitcoin script is currently costed, but doing better might
mean locking in an evaluation method at the consensus level. Seems
worth looking into, at least.

But otherwise, it seems a pretty good match.

I think you'd need about 40 opcodes to match bitcoin script and (roughly)
chia lisp, something like:

q - quote
a - apply
x - exception / immediately fail (OP_RETURN style)
i - if/then/else
softfork - upgradability
not, all, any - boolean logic
bitand, bitor, bitxor, bitnot, shift - bitwise logic
= - bitwise equality
> - + * / divmod - (signed, bignum) arithmetic
ashift - arithmetic shift (sign extended)
>s - string comparison
strlen, substr, concat - string ops
f, r, c, l - list ops (head, tail, make a list, is this a list?)
sha256 - hashing

numequal - arithmetic equal, equivalent to (= (+ a 0) (+ b 0))
ripemd160, hash160, hash256 - more hashing
bip342-txmsg - given a sighash byte, construct the bip342 message
bip340-verify - given a pubkey, message, and signature bip340 verify it
tx - get various information about the tx
taproot - get merkle path/internalpubkey/program/annex information
ecdsa - same as bip340-verify, except for traditional ecdsa?
secp256k1-muladd - given (a B C) where B,C are points, calculate a*B+C?

That compares to about 60 (non-disabled) opcodes in current script.
Pretty much all the opcodes in the first section are directly from chia
lisp, while all the rest are to complete the "bitcoin" functionality.
The last two are extensions that are more food for thought than a real
proposal.

Using a lisp-style approach seems an improvement in general to me.
For example, rather than the streaming-sha256 approach in Elements,
where you could write:

"a" SHA256INITIALIZE
"b" SHA256UPDATE
"c" SHA256UPDATE
"d" SHA256FINALIZE

to get the sha256 of "abcd" without having to CAT them first (important
if they'd potentially overflow the 520B stack item limit), in chia lisp
you write:

(sha256 "a" "b" "c" "d")

which still has the benefit of streaming the inputs into the function,
but only adds a single opcode, doesn't involve representing the internal
sha256 midstate on the stack, and generally seems easier to understand,
at least to me.

As another example, following the traditional functional "tail recursion
instead of for-loops" approach, doing CHECKMULTISIG might become
something like:

(defun checksig (sig key)
bip340-verify (f sig) (bip342-txmsg (r sig)) key)

(defun checkmultisig (sigs keys k)
if (= k 0)
1
(if (l sigs)
(if (checksig (f sigs) (f keys))
(checkmultisig (r sigs) (r keys) (- k 1))
(checkmultisig sigs (r keys) k)
)
0
)
)

Here each "sig" is a pair of a 64B bip340 signature and a 1B sighash;
instead of a 65B string combining both, and sigs, keys are lists, and k
is the number of successful signature checks you're requiring for
success.

Of course, "defun" and "if" aren't listed as opcodes above; instead you
have a compiler that gives you nice macros like defun and translates them
into correct uses of the "a" opcode, etc. As I understand it, those sort
of macros and translations are pretty well understood across lisp-like
languages, and, of course, they're already implemented for chia lisp.

I think with the "tx" opcode defined similarly to how Rusty suggested it
[2] you could implement OP_CTV-like behaviours in similar way, and also
replace "bip342-txmsg" with your own code to generate SIGHASH_ANYPREVOUT
or SIGHASH_GROUP style messages to sign. (This would mean also being able
to pull information about the utxo being spent to obtain its amount and
scriptpubkey, which are committed to wit ANYPREVOUT. If it was also able
to obtain the "is_coinbase" flag, that might allow you a more accurate
covenant-based implementation of drivechains...)

Likewise, with the "taproot" opcode defined in a way that lets you extract
out the internal public key and merkle path, I think you could implement
OP_TLUV and OP_EVICT with a similar recursive approach.

There's two ways to think about upgradability here; if someday we want
to add new opcodes to the language -- perhaps something to validate zero
knowledge proofs or calculate sha3 or use a different ECC curve, or some
way to support cross-input signature aggregation, or perhaps it's just
that some snippets are very widely used and we'd like to code them in
C++ directly so they validate quicker and don't use up as much block
weight. One approach is to just define a new version of the language
via the tapleaf version, defining new opcodes however we like.

The other is to use the "softfork" opcode -- chia defines it as:

(softfork cost code)

though I think it would probably be better if it were

(softfork cost version code)

where the idea is that "code" will use the "x" opcode if there's a
problem, and anyone supporting the "version" softfork can verify that
there aren't any problems at a cost of "cost". However, whether you
do or don't support that softfork, as far as the rest of the script is
concerned, the expression will either fail entirely or evaluate as zero;
so anyone who doesn't support the softfork can just replace it with zero
and continue on, treating it as if it had costed "cost" units.

One thing worth noting: "softfork" behaves more like OP_NOP than
tapscript's OP_SUCCESS -- I think it's just not possible in general to
have OP_SUCCESS-like behaviour if you're trying to allow accepting code
from the witness data -- otherwise as soon as you reveal that your script
does accept arbitrary code supplied by the spender, someone could stick
in an OP_SUCCESS code, and remove all the restrictions on spending and
steal your funds.

To me, it seems like chia lisp is a better answer to the problem here
than the Simplicity language. Simplicity is complicated in a few ways:

- it defines over 100 jets (plus another 6 for sha3, and another 45 for
individual libsecp256k1 functions) that need to be implemented
natively to efficiently track consensus [3]

- as far as I know, how to soft-fork in new jets isn't yet well
established. I think the ideal is that you just write everything in
raw simplicity, and either the interpreter has a jet and does things
quickly, or doesn't, and gets the same result much more slowly [4]. But
that approach doesn't seem compatible with maintaining consensus,
when "slowly" can be slower by more than 6 orders of magnitude [5].

- to understand what's going on with a smart contract, you need to
understand both simplicity (to define the program) and the bit machine
(to follow how it's computed), both of which are fairly novel --
and if nobody's directly coding in simplicity which seems likely,
you're adding a third layer on top of that: you want to understand
what the programmer asked for (the source), what is included in the
transaction (the simplicity code) and how that's executed by consensus
code (via the bit machine).

There's a branch for enabling simplicity on elements/liquid [6]
to see what enabling simplicity might involve in concrete terms; it
just... doesn't seem at all simple in practice to me. I can't see how
you'd reasonably translate that simplicity code into a BIP series that
anyone could understand, or how you'd do a thorough review of all the
changes...

By contrast, chia lisp has fewer opcodes than Simplicity's jets, has
feasible approaches to low-impact soft forks to increase functionality,
can be used with only two levels of abstraction (lisp with macros and
the opcodes-only vm level) that seem not too bad to understand, and
(in my opinion) doesn't seem too hard to implement/maintain reasonably.

On the other hand, Simplicity's big advantage over *everything* else
is in formal verification. But I'm not really seeing why you couldn't
preserve that advantage by writing simplicity definitions for the "lisp"
opcodes [7], so that you can "compile" the lisp programs to simplicity,
and then verify them however you like.

One of the things people sometimes claim about bitcoin as an asset,
is that it's got both the advantage of having been first to market,
but also that if some altcoin comes along with great new ideas, then
those ideas can just be incorporated into bitcoin too, so bitcoin can
preserve it's lead even from innovators. Granted, I've only really been
looking at chia lisp for a bit over a week, but it really seems to me
like a case where it might be worth putting that philosophy into practice.

If we were to adopt this, obviously we shouldn't call it "chia lisp"
anymore, since it wouldn't work the same in important ways. But since
the program would be encoded as a binary-tree of car/cdr pairs, maybe
we could call it "binary-tree coded script", or "btc-script" for short...

PS: related tweets: [8]

Cheers,
aj

[0] You could also allow things to be pushed onto the stack that
(recursively) can push things onto the stack -- the language "Joy"
takes this approach. It seems to end up equivalent to doing things
in a list oriented way to me.

[1] https://chialisp.com/docs/ref/clvm

[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019871.html

[3] https://raw.githubusercontent.com/ElementsProject/simplicity/pdf/Simplicity-TR.pdf

[4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015244.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-October/015227.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-October/015228.html

[5] https://medium.com/blockstream/simplicity-jets-release-803db10fd589

[6] https://github.com/ElementsProject/elements/compare/simplicity

[7] At least I think so? chia lisp does multibyte math, that is "+"
can accept "arbitrary" length bytestrings, which it interprets as
numbers and adds together; whereas Simplicity requires finite types.
I think you could decide "a program that only costs X can't have any
bytestrings greater than length k*X" and construct a finite type up to
that length, maybe? So long as you're only using it for verification,
maybe that stays feasible? Or perhaps you could arbitrarily limit
the strings to a max of 520 bytes at a consensus level, and the
corresponding Simplicity types to 4160 bits and go from there?

[8] https://twitter.com/brian_trollz/status/1499048316956549123
https://twitter.com/jb55/status/1499045998315724801

[9] Oops, out of order footnotes. Anyway...

[10] [9] The CREATE/ASSERT bundling stuff is interesting; and could be
used to achieve functionality like the "transaction sponsorship"
stuff. It doesn't magically solve the issues with maintaining the
mempool and using that to speed up block acceptance, though, and
the chia chain has apparently suffered from mempool-flooding attacks
recently [11] so I don't think they've solved the broader problem,
and thus I think it still makes more sense to stick with bitcoin's
current model here.

[11] https://thechiaplot.net/2021/11/03/interview-with-the-chia-dust-stormer/
https://github.com/Chia-Network/post-mortem/blob/main/post-mortem.md

📅 Original date posted:2022-02-26 📝 Original message:On ...

2023-06-08T01:03:36+02:00

In reply to nevent1q…vt9u
_________________________

📅 Original date posted:2022-02-26
📝 Original message:On Thu, Feb 24, 2022 at 12:03:32PM +0000, ZmnSCPxj via bitcoin-dev wrote:
> > > Logically, if the construct is general enough to form Drivechains, and
> > > we rejected Drivechains, we should also reject the general construct.
> > Not providing X because it can only be used for E, may generalise to not
> > providing Y which can also only be used for E, but it doesn't necessarily
> > generalise to not providing Z which can be used for both G and E.
> Does this not work only if the original objection to merging in BIP-300 was of the form:
> * X implements E.
> * Z implements G and E.
> * Therefore, we should not merge in X and instead should merge in the more general construct Z.

I'd describe the "original objection" more as "E is not worth doing;
X achieves nothing but E; therefore we should not work on or merge X".

Whether we should work on or eventually merge some other construct that
does other things than E, depends on the (relative) merits of those
other things.

> I think we really need someone who NACKed BIP-300 to speak up.

Here's some posts from 2017:

] I think it's great that people want to experiment with things like
] drivechains/sidechains and what not, but their security model is very
] distinct from Bitcoin's and, given the current highly centralized
] mining ecosystem, arguably not very good. So positioning them as a
] major solution for the Bitcoin project is the wrong way to go. Instead
] we should support people trying cool stuff, at their own risk.

- https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014726.html

] Regardless, people are free experiment and adopt such an approach. The
] nice thing about it not being a hardfork is that it does not require
] network-wide consensus to deploy. However, I don't think they offer a
] security model that should be encouraged, and thus doesn't have a
] place on a roadmap.

- https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014729.html

> If my understanding is correct and that the original objection was "Drivechains are bad for reasons R[0], R[1]...", then:
> * You can have either of these two positions:
> * R[0], R[1] ... are specious arguments and Drivechains are not bad [...]
> * R[0], R[1] ... are valid arguments are Drivechains are bad, therefore we should **NOT** merge in a feature that implements Recursive Covenants [...]
> You cannot have it both ways.

I guess you mean to say that I've got to pick one, rather than can't
pick both. But in any event, I don't pick either; my view is more along
the lines of:

* drivechains shouldn't be used
* it's okay if other people think drivechains are worth using, and go
ahead and do so, if they're not creating a direct burden on everyone
else

That's the same position I hold for other things, like using lightning
on mainnet in January 2018; or giving your bitcoin to an anonymous
custodian so it it can be borrowed via a flash loan on some novel third
party smart contract platform.

> Admittedly, there may be some set of restrictions that prevent Turing-Completeness from implementing Drivechains, but you have to demonstrate a proof of that set of restrictions existing.

Like I said; I don't think the drivechains game theory works without
the implicit threat of miner censorship, and therefore you need a
"from_coinbase" flag as well as covenants. That's not a big objection,
though. (On the other hand, if I'm wrong and drivechains *do* work
without that threat; then drivechains don't cause a block size increase,
and can be safely ignored by miners and full node operators, and the
arguments against drivechains are specious; and implementing them purely
via covenants so miners aren't put in a privileged position seems an
improvement)

> > I think it's pretty reasonable to say:
> >
> > a) adding dedicated consensus features for drivechains is a bad idea
> > in the absence of widespread consensus that drivechains are likely
> > to work as designed and be a benefit to bitcoin overall
> >
> > b) if you want to risk your own funds by leaving your coins on an
> > exchange or using lightning or eltoo or tumbling/coinjoin or payment
> > pools or drivechains or being #reckless in some other way, and aren't
> > asking for consensus changes, that's your business
>
> *Shrug* I do not really see the distinction here --- in a world with Drivechains, you are free to not put your coins in a Drivechain-backed sidechain, too.

Well, yes: I'm saying there's no distinction between putting funds in
drivechains and other #reckless things you might do with your money?

My opinion is (a) we should be conservative about adding new consensus
features because of the maintenance cost; (b) we should design
consensus/policy in a way to encourage minimising the externality costs
users impose on each other; and (c) we should make it as easy as possible
to use bitcoin safely in general -- but if people *want* to be reckless,
even knowing the consequences, that's fine.

> (Admittedly, Drivechains does get into a Mutually Assured Destruction argument, so that may not hold.
> But if Drivechains going into a MAD argument is an objection, then I do not see why covenant-based Drivechains would also not get into the same MAD argument --- and if you want to avoid the MADness, you cannot support recursive covenants, either.

I think the argument you believe, but aren't quite actually making,
is along the lines of:

a) drivechain technology doen't just potentially harm people who use
them; it is an existential threat to bitcoin if used by anyone

b) therefore the ability for anyone to implement them must be prevented

c) (a) is well known and widely agreed upon by all reasonable
well-informed people

(b) is definitely a reasonable consequence of (a), but I don't agree
with (a). Drivechains have certainly been criticised as a bad idea,
but there are plenty of bad ideas that don't need to be outlawed.

But I think the simplest *method* of preventing drivechains from having
significant adoption is just "users encourage miners to steal funds
deposited into drivechains" (eg, by declining to do a UASF to prevent
such theft), which then obviously discourages people from putting funds
into drivechains. Since that can still be done even if bip300 or an
implementation of drivechains-via-covenants is deployed, I don't think
drivechains are an existential threat to bitcoin.

> Remember, 51% attackers can always censor the blockchain, regardless of whether you put the Drivechain commitments into the coinbase, or in an ostensibly-paid-by-somebody-else transaction.)

I think you could make the analogy between drivechains and covenants a
fair bit stronger in the following way:

The idea behind drivechains and the liquid sidechain is, in both cases,
that funds can be moved to some other blockchain with its own rules, and
then moved back to the bitcoin blockchain, via the assistance of some
group that will hopefully follow the stated rules of the sidechain. In
liquid's case it's a group of semi-known functionaries who are also
directly responsible for transactions appearing on the liquid sidechain,
and it's done by them signing via multisig. For bip300, it's bitcoin
miners, and done by putting entries in the coinbase.

But because just letting any miner alone immediately move funds
would be obviously too risky to consider, bip300 adds additional
restrictions, adding both multisig-like aspects, delays, and the ability
to back-out/correct a theft attempt before it's final, which provides
the opportunity for honest participants to react to miners attempting to
cheat and hopefully achieve a legitimate outcome instead. Whether that's
enough is still debatable -- but it's certainly an improvement to go from
"too risky to consider" to "debatable".

But the same incentive can apply to liquid too: it might be good to be
able to have liquid funds encumbered on the bitcoin blockchain in such a
way that it's even harder for people with liquid's private keys to cheat
than it currently is -- ie, it would be good to be able to specify more
"vault-like" behaviours for the liquid funds, perhaps in relation to the
"backup recovery keys" [0], eg.

As a result, while it's not obvious, I think it shouldn't be *surprising*
that the same technology that allows "vaults" also enables (something
like) drivechains -- since the goal in both cases is just constraining
how withdrawals work.

Cheers,
aj

[0] https://medium.com/blockstream/patching-the-liquid-timelock-issue-b4b2f5f9a973

📅 Original date posted:2022-02-24 📝 Original message:On ...

2023-06-08T01:03:34+02:00

In reply to nevent1q…2md5
_________________________

📅 Original date posted:2022-02-24
📝 Original message:On Wed, Feb 23, 2022 at 11:28:36AM +0000, ZmnSCPxj via bitcoin-dev wrote:
> Subject: Turing-Completeness, And Its Enablement Of Drivechains

> And we have already rejected Drivechains,

That seems overly strong to me.

> for the following reason:
> 1. Sidechain validators and mainchain miners have a strong incentive to
> merge their businesses.
> 2. Mainchain miners end up validating and commiting to sidechain blocks.
> 3. Ergo, sidechains on Drivechains become a block size increase.

I think there are two possible claims about drivechains that would make
them unattractive, if true:

1) that adding a drivechain is a "block size increase" in the sense
that every full node and every miner need to do more work when
validating a block, in order to be sure whether the majority of hash
rate will consider it valid, or will reject it and refuse to build
on it because it's invalid because of some external drivechain rule

2) that funds deposited in drivechains will be stolen because
the majority of hashrate is not enforcing drivechain rules (or that
deposited funds cannot be withdrawn, but will instead be stuck in
the drivechain, rather than having a legitimate two-way peg)

And you could combine those claims, saying that one or the other will
happen (depending on whether more or less than 50% of hashpower is
enforcing drivechain rules), and either is bad, even though you don't
know which will happen.

I believe drivechain advocates argue a third outcome is possible where
neither of those claims hold true, where only a minority of hashrates
needs to validate the drivechain rules, but that is still sufficient
to prevent drivechain funds from being stolen.

One way to "reject" drivechains is simply to embrace the second claim --
that putting money into drivechains isn't safe, and that miners *should*
claim coins that have been drivehcain encumbered (or that miners
should not assist with withdrawing funds, leaving them trapped in the
drivechain). In some sense this is already the case: bip300 rules aren't
enforced, so funds committed today via bip300 can likely expect to be
stolen, and likely won't receive the correct acks, so won't progress
even if they aren't stolen.

I think a key difference between tx-covenant based drivechains and bip300
drivechains is hashpower endorsement: if 50% of hashpower acks enforcement
of a new drivechain (as required in bip300 for a new drivechain to exist
at all), there's an implicit threat that any block proposing an incorrect
withdrawal from that blockchain will have their block considered invalid
and get reorged out -- either directly by that hashpower majority, or
indirectly by users conducting a UASF forcing the hashpower majority to
reject those blocks.

I think removing that implicit threat changes the game theory
substantially: rather than deposited funds being withdrawn due to the
drivechain rules, you'd instead expect them to be withdrawn according to
whoever's willing to offer the miners the most upfront fees to withdraw
the funds.

That seems to me to mean you'd frequently expect to end up in a scorched
earth scenario, where someone attempts to steal, then they and the
legitimate owner gets into a bidding war, with the result that most
of the funds end up going to miners in fees. Because of the upfront
payment vs delayed collection of withdrawn funds, maybe it could end up
as a dollar auction, with the two parties competing to lose the least,
but still both losing substantial amounts?

So I think covenant-based drivechains would be roughly the same as bip300
drivechains, where a majority of hashpower used software implementing
the following rules:

- always endorse any proposed drivechain
- always accept any payment into a drivechain
- accept bids to ack/nack withdrawals, then ack/nack depending on
whoever pays the most

You could probably make covenant-based drivechains a closer match to
bip300 drivechains if a script could determine if an input was from a
(100-block prior) coinbase or not.

> Logically, if the construct is general enough to form Drivechains, and
> we rejected Drivechains, we should also reject the general construct.

Not providing X because it can only be used for E, may generalise to not
providing Y which can also only be used for E, but it doesn't necessarily
generalise to not providing Z which can be used for both G and E.

I think it's pretty reasonable to say:

a) adding dedicated consensus features for drivechains is a bad idea
in the absence of widespread consensus that drivechains are likely
to work as designed and be a benefit to bitcoin overall

b) if you want to risk your own funds by leaving your coins on an
exchange or using lightning or eltoo or tumbling/coinjoin or payment
pools or drivechains or being #reckless in some other way, and aren't
asking for consensus changes, that's your business

Cheers,
aj

📅 Original date posted:2022-02-17 📝 Original message:On ...

2023-06-08T01:03:30+02:00

In reply to nevent1q…zah2
_________________________

📅 Original date posted:2022-02-17
📝 Original message:On Fri, Feb 11, 2022 at 12:12:28PM -0600, digital vagabond via bitcoin-dev wrote:
> Imagine a covenant design that was
> flexible enough to create an encumbrance like this: a script specifies a
> specific key in a multisig controlled by some authority figure (or a branch
> in the script that would allow unilateral control by such an authority),
> and the conditions of the covenant would perpetually require than any spend
> from the covenant can only be sent to a script involving that key from said
> authority, preventing by consensus any removal of that central authorities
> involvement in control over that UTXO.

> I know that such a walled garden could easily be constructed now with
> multisig and restrictions on where coins can be withdrawn to from exchanges
> or whatever [...], but I think the important distinction
> between such non-consensus system designed to enforce such restrictions and
> a recursive covenant to accomplish the same is that in the case of a
> multisig/non-consensus based system, exit from that restriction is still
> possible under the consensus rules of the protocol.

I think that sort of encumberance is already possible: you send bitcoin
to an OP_RETURN address and that is registered on some other system as a
way of "minting" coins there (ie, "proof of burn") at which point rules
other than bitcoin's apply. Bitcoin consensus guarantees the value can't
be extracted back out of the OP_RETURN value.

I think spacechains effectively takes up this concept for their one-way
peg:

https://bitcoin.stackexchange.com/questions/100537/what-is-spacechain

https://medium.com/@RubenSomsen/21-million-bitcoins-to-rule-all-sidechains-the-perpetual-one-way-peg-96cb2f8ac302

(I think spacechains requires a covenant construct to track the
single-tx-per-bitcoin-block that commits to the spacechain, but that's
not directly used for the BTC value that was pegged into the spacechain)

If we didn't have OP_RETURN, you could instead pay to a pubkey that's
constructed from a NUMS point / or a pedersen commitment, that's (roughly)
guaranteed unspendable, at least until secp256k1 is broken via bitcoin's
consensus rules (with the obvious disadvantage that nodes then can't
remove these outputs from the utxo set).

That was also used for XCP/Counterparty's ICO in 2014, at about 823 uBTC
per XCP on average (depending on when you got in it was between 666
uBTC/XCP and 1000 uBTC/XCP apparently), falling to a current price of
about 208 uBTC per XCP. It was about 1000 uBTC/XCP until mid 2018 though.

https://counterparty.io/news/why-proof-of-burn/
https://github.com/CounterpartyXCP/Documentation/blob/master/Basics/FAQ-XCP.md

These seem like they might be bad things for people to actually do
(why would you want to be paid to mine a spacechain in coins that can
only fall in value relative to bitcoin?), and certainly I don't think
we should do things just to make this easier; but it seems more like a
"here's why you're hurting yourself if you do this" thing, rather than a
"we can prevent you from doing it and we will" thing.

Cheers,
aj

📅 Original date posted:2022-02-02 📝 Original message:On ...

2023-06-08T01:03:12+02:00

In reply to nevent1q…83l9
_________________________

📅 Original date posted:2022-02-02
📝 Original message:On Tue, Feb 01, 2022 at 10:30:12AM +0100, Bastien TEINTURIER via bitcoin-dev wrote:
> But do you agree that descendants only matter for DoS resistance then,
> not for miner incentives?

There's an edge case where you're replacing tx A with tx X, and X's fee
rate is higher than A's, but you'd be obsoleting descendent txs (B, C,
D...) and thus replacing them with unrelated txs (L, M, N...), and the
total feerate/fees of A+B+C+D... is nevertheless higher than X+L+M+N...

But I think that's probably unusual (transactions D and L are adjacent
in the mempool, that's why L is chosen for the block; but somehow
there's a big drop off in value somewhere between B/C/D and L/M/N),
and at least today, I don't think miners consider it essential to eke
out every possible sat in fee income.

(If, as per your example, you're actually replacing {A,B,C,D} with
{X,Y,Z,W} where X pays higher fees than A and the package in total pays
either the same or higher fees, that's certainly incentive compatible.
The tricky question is what happens when X arrives on its own and it
might be that no one ever sends a replacement for B,C,D)

> The two policies I proposed address miner incentives. I think they're
> insufficient to address DoS issues. But adding a 3rd policy to address
> DoS issues may be a good solution?

>>> 1. The transaction's ancestor absolute fees must be X% higher than the
>>> previous transaction's ancestor fees
>>> 2. The transaction's ancestor feerate must be Y% higher than the
>>> previous transaction's ancestor feerate

Absolute fees only matter if your backlog's feerate drops off. If you've
got 100MB of txs offering 5sat/vb, then exchanging 50kB at 5sat/vb for
1kB at 6sat/vb is still a win: your block gains 1000 sats in fees even
though your mempool loses 245,000 sats in fees.

But if your backlog's feerate does drop off, *and* that matters, then
I don't think you can ignore the impact of the descendent transactions
that you might not get a replacement for.

I think "Y% higher" rather than just "higher" is only useful for
rate-limiting, not incentive compatibility. (Though maybe it helps
stabilise a greedy algorithm in some cases?)

Cheers,
aj

📅 Original date posted:2022-01-31 📝 Original message:On ...

2023-06-08T01:03:10+02:00

In reply to nevent1q…83lr
_________________________

📅 Original date posted:2022-01-31
📝 Original message:On Mon, Jan 31, 2022 at 04:57:52PM +0100, Bastien TEINTURIER via bitcoin-dev wrote:
> I'd like to propose a different way of looking at descendants that makes
> it easier to design the new rules. The way I understand it, limiting the
> impact on descendant transactions is only important for DoS protection,
> not for incentive compatibility. I would argue that after evictions,
> descendant transactions will be submitted again (because they represent
> transactions that people actually want to make),

I think that's backwards: we're trying to discourage people from wasting
the network's bandwidth, which they would do by publishing transactions
that will never get confirmed -- if they were to eventually get confirmed
it wouldn't be a waste of bandwith, after all. But if the original
descendent txs were that sort of spam, then they may well not be
submitted again if the ancestor tx reaches a fee rate that's actually
likely to confirm.

I wonder sometimes if it could be sufficient to just have a relay rate
limit and prioritise by ancestor feerate though. Maybe something like:

- instead of adding txs to each peers setInventoryTxToSend immediately,
set a mempool flag "relayed=false"

- on a time delay, add the top N (by fee rate) "relayed=false" txs to
each peer's setInventoryTxToSend and mark them as "relayed=true";
calculate how much kB those txs were, and do this again after
SIZE/RATELIMIT seconds

- don't include "relayed=false" txs when building blocks?

- keep high-feerate evicted txs around for a while in case they get
mined by someone else to improve compact block relay, a la the
orphan pool?

That way if the network is busy, any attempt to do low fee rate tx spam
will just cause those txs to sit as relayed=false until they're replaced
or the network becomes less busy and they're worth relaying. And your
actual mempool accept policy can just be "is this tx a higher fee rate
than the txs it replaces"...

> Even if bitcoin core releases a new version with updated RBF rules, as a
> wallet you'll need to keep using the old rules for a long time if you
> want to be safe.

All you need is for there to be *a* path that follows the new relay rules
and gets from your node/wallet to perhaps 10% of hashpower, which seems
like something wallet providers could construct relatively quickly?

Cheers,
aj

📅 Original date posted:2021-10-14 📝 Original message:On ...

2023-06-08T01:00:03+02:00

In reply to nevent1q…qn5e
_________________________

📅 Original date posted:2021-10-14
📝 Original message:On Mon, Oct 11, 2021 at 12:12:58PM -0700, Jeremy via bitcoin-dev wrote:
> > ... in this post I will argue against frequent soft forks with a single or
> minimal
> > set of features and instead argue for infrequent soft forks with batches
> > of features.
> I think this type of development has been discussed in the past and has been
> rejected.

> AJ: - improvements: changes might not make everyone better off, but we
> don't want changes to screw anyone over either -- pareto
> improvements in economics, "first, do no harm", etc. (if we get this
> right, there's no need to make compromises and bundle multiple
> flawed proposals so that everyone's an equal mix of happy and
> miserable)

I don't think your conclusion above matches my opinion, for what it's
worth.

If you've got two features, A and B, where the game theory is:

If A happens, I'm +100, You're -50
If B happens, I'm -50, You're +100

then even though A+B is +50, +50, then I do think the answer should
generally be "think harder and come up with better proposals" rather than
"implement A+B as a bundle that makes us both +50".

_But_ if the two features are more like:

If C happens, I'm +100, You're +/- 0
If D happens, I'm +/- 0, You're +100

then I don't have a problem with bundling them together as a single
simultaneous activation of both C and D.

Also, you can have situations where things are better together,
that is:

If E happens, we're both at +100
If F happens, we're both at +50
If E+F both happen, we're both at +9000

In general, I think combining proposals when the combination is better
than the individual proposals were is obviously good; and combining
related proposals into a single activation can be good if it is easier
to think about the ideas as a set.

It's only when you'd be rejecting the proposal on its own merits that
I think combining it with others is a bad idea in principle.

For specific examples, we bundled schnorr, Taproot, MAST, OP_SUCCESSx
and CHECKSIGADD together because they do have synergies like that; we
didn't bundle ANYPREVOUT and graftroot despite the potential synergies
because those features needed substantially more study.

The nulldummy soft-fork (bip 147) was deployed concurrently with
the segwit soft-fork (bip 141, 143), but I don't think there was any
particular synergy or need for those things to be combined, it just
reduced the overhead of two sets of activation signalling to one.

Note that the implementation code for nulldummy had already been merged
and were applied as relay policy well before activation parameters were
defined (May 2014 via PR#3843 vs Sep 2016 for PR#8636) let alone becoming
an active soft fork.

Cheers,
aj

📅 Original date posted:2021-09-08 📝 Original message:On ...

2023-06-08T00:58:48+02:00

In reply to nevent1q…dc8z
_________________________

📅 Original date posted:2021-09-08
📝 Original message:On Tue, Sep 07, 2021 at 06:07:47PM +0200, 0xB10C via bitcoin-dev wrote:
> The reorg-interval X very much depends on the user's needs. One could
> argue that there should be, for example, three reorgs per day, each 48
> blocks apart.

Oh, wow, I think the last suggestion was every 100 blocks (every
~16h40m). Once every ~8h sounds very convenient.

> Such a short reorg interval allows developers in all time
> zones to be awake during one or two reorgs per day.

And also for there to reliably be reorgs when they're not awake, which
might be a useful thing to be able to handle, too :)

> Developers don't
> need to wait for, for example, a week until they can test their reorgs
> next. However, too frequent reorgs could hinder other SigNet users.

Being able to run `bitcoind -signet -signetacceptreorg=0` and never
seeing any reorgs should presumably make this not a problem?

For people who do see reorgs, having an average of 2 or 3 additional
blocks every 48 blocks is perhaps a 6% increase in storage/traffic.

> # Scenario 1: Race between two chains
>
> For this scenario, at least two nodes and miner scripts need to be
> running. An always-miner A continuously produces blocks and rejects
> blocks with the to-be-reorged version bit flag set. And a race-miner R
> that only mines D blocks at the start of each interval and then waits X
> blocks. A and R both have the same hash rate. Assuming both are well
> connected to the network, it's random which miner will first mine and
> propagate a block. In the end, the A miner chain will always win the race.

I think this description is missing that all the blocks R mines have
the to-be-reorged flag set.

> 3. How deep should the reorgs be on average? Do you want to test
> deeper reorgs (10+ blocks) too?

Super interested in input on this -- perhaps we should get optech to
send a survey out to their members, or so?

My feeling is:

- 1 block reorgs: these are a regular feature on mainnet, everyone
should cope with them; having them happen multiple times a day to
make testing easier should be great

- 2-3 block reorgs: good for testing the "your tx didn't get enough
confirms to be credited to your account" case, even though it barely
ever happens on mainnet

- 4-6 block reorgs: likely to violate business assumptions, but
completely technically plausible, especially if there's an attack
against the network

- 7-100 block reorgs: for this to happen on mainnet, it would probably
mean there was a bug and pools/miners agree the chain has to
be immediately reverted -- eg, someone discovers and exploits an
inflation bug, minting themselves free bitcoins and breaking the 21M
limit (eg, the 51 block reorg in Aug 2010); or someone discovers a
bug that splits the chain, and the less compatible chain is reverted
(eg, the 24 block reorg due to the bdb lock limit in Mar 2013);
or something similar. Obviously the bug would have to have been
discovered pretty quickly after it was exploited for the reorg to be
under a day's worth of blocks.

- 100-2000+ block reorgs: severe bug that wasn't found quickly, or where
getting >50% of miners organised took more than a few hours. This will
start breaking protocol assumptions, like pool payouts, lightning's
relative locktimes, or liquid's peg-in confirmation requirements, and
result in hundres of MBs of changes to the utxo set

Maybe it would be good to do reorgs of 15, 150 or 1500 blocks as a
special fire-drill event, perhaps once a month/quarter/year or so,
in some pre-announced window?

I think sticking to 1-6 block reorgs initially is a fine way to start
though.

> After enough testing, the default SigNet can start to do periodical
> reorgs, too.

FWIW, the only thing that concerns me about doing this on the default
signet is making sure that nodes that set -signetacceptreorg=0 don't
end up partitioning the p2p network due to either rejecting a higher
work chain or rejecting txs due to double-spends across the two chains.

A quick draft of code for -signetacceptreorg=0 is available at

https://github.com/ajtowns/bitcoin/commits/202108-signetreorg

Cheers,
aj

📅 Original date posted:2021-03-01 📝 Original message:On ...

2023-06-07T20:29:42+02:00

In reply to nevent1q…8dlw
_________________________

📅 Original date posted:2021-03-01
📝 Original message:On Sun, Feb 28, 2021 at 07:33:30PM +0000, Luke Dashjr via bitcoin-dev wrote:
> As we saw in 2017 with BIP 9, coordinating activation by miner signal alone,
> despite its potential benefits, also leaves open the door to a miner veto.

To the contrary, we saw in 2017 that miners could *not* successfully
veto a BIP 9 activation. It was certainly more effort and risk than was
desirable to override the attempted veto, but the attempt at vetoing
nevertheless failed.

> It wouldn't be much different than adding back the inflation bug
> (CVE-2018-17144) and trusting miners not to exploit it.

That is ridiculous FUD.

> With LOT=False in the picture, however, things can get messy:

LOT=false is always in the picture if we are talking about a soft-fork:
the defining feature of a soft-fork is that old node software continues
to work, and old node software will be entirely indifferent to whether
activation is signalled or not.

> some users will
> enforce Taproot(eg) (those running LOT=True), while others will not (those
> with LOT=False)

If you are following bip8 with lockinontimeout=false, you will enforce
taproot rules if activation occurs, you will simply not reject blocks if
activation does not occur.

> Users with LOT=True will still get all the safety thereof,
> but those with LOT=False will (in the event of miners deciding to produce a
> chain split) face an unreliable chain, being replaced by the LOT=True chain
> every time it overtakes the LOT=False chain in work.

This assumes anyone mining the chain where taproot does not activate is
not able to avoid a reorg, despite having majority hashpower (as implied
by the lot=true chain having to overtake them repeatedly). That's absurd;
avoiding a reorg is trivially achieved via running "invalidateblock", or
via pool software examining block headers, or via a patch along the lines
of MUST_SIGNAL enforcement, but doing the opposite. For concreteness,
here's a sketch of such a patch:

https://github.com/ajtowns/bitcoin/commit/f195688bd1eff3780f200e7a049e23b30ca4fe2f

> For 2 weeks, users with LOT=False would not have a usable network.

That's also ridiculous FUD.

If it were true, it would mean the activation mechanism was not
acceptable, as non-upgraded nodes would also not have a usable network
for the same reason.

Fortunately, it's not true.

More generally, if miners are willing to lose significant amounts of
money mining orphan blocks, they can do that at any time. If they're
not inclined to do so, it's incredibly straightforward for them to avoid
doing so, whatever a minority of other miners might do.

> The overall risk is maximally reduced by LOT=True being the only deployed
> parameter, and any introduction of LOT=False only increases risk probability
> and severity.

LOT=false is the default behaviour of everything single piece of node
software out there. That behaviour doesn't need to be introduced, it's
already universal.

Cheers,
aj

📅 Original date posted:2021-02-22 📝 Original message:On ...

2023-06-07T20:28:58+02:00

In reply to nevent1q…dl59
_________________________

📅 Original date posted:2021-02-22
📝 Original message:On Mon, Feb 22, 2021 at 09:00:29AM -0500, Matt Corallo wrote:
> I think it should be clear that a UASF-style command line option to allow
> consensus rule changes in the node in the short term, immediately before a fork
> carries some risk of a fork, even if I agree it may not persist over months. We
> can’t simply ignore that.

I don't think a "-set-bip8-lockinontimeout=taproot" option on its own
would be very safe -- if we were sure it was safe, because we were sure
that everyone would eventually set lockinontimeout=true, then we would
set lockinontimeout=true from day one and not need an option. I haven't
seen/had any good ideas on how to make the option safe, or at least make
it obvious that you shouldn't be setting it if you don't really
understand what you're getting yourself into. [0]

And that's even if you assume that the code was perfectly capable of
handling forks in some theoretically optimal way.

So at least for the time being, I don't think a config param / command
line option is a good idea for bip8. IMHO, YMMV, IANABDFL etc.

> I think the important specific case of this is something like "if a chain
> where taproot is impossible to activate is temporarily the most work,
> miners with lockinontimeout=true need to be well connected so they don't
> end up competing with each other while they're catching back up".
> Between this and your above point, I think we probably agree - there is
> material technical complexity hiding behind a “change the consensus rules“
> option. Given it’s not a critical feature by any means, putting resources into
> fixing these issues probably isn’t worth it.

For reference, the "preferentially peer with other UASF nodes" PR for
the BIP148 client was

https://github.com/UASF/bitcoin/pull/24

List discussion was at

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014618.html

I think I'll add playing around with that and reorgs on a signet to my
todo list to see how it goes in cases other than ones that are (hopefully)
vanishingly unlikely to ever happen in practice.

Cheers,
aj

[0] In some sense, this is exactly the opposite sentiment compared to
earonesty's comment:

https://github.com/bitcoin/bitcoin/pull/10900#issuecomment-317333312

I mean, I guess could solve the unsafe-now-but-maybe-safe-later
problem generally with a signature:

-authorise-dangerous-options-key=XXXX
-lockinontimeout=taproot:YYYY

where YYYY is a signature of "dangerous:lockinontimeout=taproot" or
similar by the key XXXX, and XXXX defaults to some (multisig?) key
controlled by some bitcoin people, who'll only sign that when
there's clear evidence that it will be reasonably safe, and maybe to
"cert-transparency" or something as well. So that allows having an
option become available by publishing a signature, without having
to recompile the code. And it could still be overriden by people who
know what they're doing if the default key owners are being weird. And
maybe the "dangerous" part is enough to prevent people from randomly
cut-and-pasting it from a website into their bitcoin.conf.

I dunno. No bad ideas when brainstorming...

📅 Original date posted:2021-02-22 📝 Original message:On ...

2023-06-07T20:28:58+02:00

In reply to nevent1q…mvtv
_________________________

📅 Original date posted:2021-02-22
📝 Original message:On Mon, Feb 22, 2021 at 01:44:55AM -0500, Matt Corallo wrote:
> A node feeding you invalid headers (used to be) cause for a ban [...]

Headers that are invalid due to MUST_SIGNAL rules are marked as
BLOCK_RECENT_CONSENSUS_CHANGE so don't directly result in a ban. If you're
doing headers-first relay, I think that will also prevent hitting the
BLOCK_MISSING_PREV case, which would result in a ban.

If a lockinontimeout=true node is requesting compact blocks from a
lockinontimeout=false node during a chainsplit in the MUST_SIGNAL phase,
I think that could result in a ban.

> More importantly, nodes on both sides of the fork need to find each other.

(If there was going to be an ongoing fork there'd be bigger things to
worry about...)

I think the important specific case of this is something like "if a chain
where taproot is impossible to activate is temporarily the most work,
miners with lockinontimeout=true need to be well connected so they don't
end up competing with each other while they're catching back up".

Actually, that same requirement might be more practically for a signet
feature we were thinking about -- namely having "optional reorgs", ie
every now and then we'd mine 1-6 blocks and then reorg them out; but
also flag the soon-to-be-stale blocks in some way so that if you didn't
want to have to deal with reorgs you could easily ignore them. Having
it be possible for the "I want to see reorgs!" nodes to be able to find
each other seems like it might be a similar problem (avoiding having the
"don't-want-reorgs" nodes ban the "want-reorgs" nodes too perhaps).

Cheers,
aj

📅 Original date posted:2021-02-22 📝 Original message:On ...

2023-06-07T20:28:57+02:00

In reply to nevent1q…td2v
_________________________

📅 Original date posted:2021-02-22
📝 Original message:On Fri, Feb 19, 2021 at 12:48:00PM -0500, Matt Corallo via bitcoin-dev wrote:
> It was pointed out to me that this discussion is largely moot as the
> software complexity for Bitcoin Core to ship an option like this is likely
> not practical/what people would wish to see.
> Bitcoin Core does not have infrastructure to handle switching consensus
> rules with the same datadir - after running with uasf=true for some time,
> valid blocks will be marked as invalid,

I don't think this is true? With the current proposed bip8 code,
lockinontimeout=true will cause headers to be marked as invalid, and
won't process the block further. If a node running lockinontimeout=true
accepts the header, then it will apply the same consensus rules as a
lockinontimeout=false node.

I don't think an invalid header will be added to the block index at all,
so a node restart should always cleanly allow it to be reconsidered.

The test case in

https://github.com/bitcoin/bitcoin/pull/19573/commits/bd8517135fc839c3332fea4d9c8373b94c8c9de8

tests that a node that had rejected a chain due to lockinontimeout=true
will reorg to that chain after being restarted as a byproduct of the way
it tests different cases (the nodes set a new startheight, but retain
their lockinontimeout settings).

(I think with the current bip8 code, if you switch from
lockinontimeout=false to lockinontimeout=true and the tip of the current
most work chain is after the timeoutheight and did not lockin, then you
will continue following that chain until a taproot-invalid transaction
is inclued, rather than immediately reorging to a shorter chain that
complies with the lockinontimeout=true rules)

Cheers,
aj

📅 Original date posted:2020-05-02 📝 Original message:On ...

2023-06-07T20:24:13+02:00

In reply to nevent1q…qc9e
_________________________

📅 Original date posted:2020-05-02
📝 Original message:On Fri, May 01, 2020 at 08:23:07AM -0400, Russell O'Connor wrote:
> Regarding specifics, I personally think it would be better to keep the
> hashes of the ScriptPubKeys separate from the hashes of the input values.

I think Andrew's original suggestion achieves this:

>> The obvious way to implement this is to add another hash to the
>> signature message:
>> sha_scriptPubKeys (32): the SHA256 of the serialization of all
>> scriptPubKeys of the previous outputs spent by this
>> transaction.

presumably with sha_scriptPubKeys' inclusion being conditional on
hash_type not matching ANYONECANPAY.

We could possibly also make the "scriptPubKey" field dependent on
hash_type matching ANYONECANPAY, making this not cost any more
in serialised bytes per signature.

This would basically mean we're committing to each component of the
UTXOs being spent:

without ANYONECANPAY:
sha_prevouts commits to the txid hashes and vout indexes (COutPoint)
sha_amounts commits to the nValues (Coin.CTxOut.nValue)
sha_scriptpubkeys commits to the scriptPubKey (Coin.CTxOut.scriptPubKey)

with ANYONECANPAY it's the same but just for this input's prevout:
outpoint
amount
scriptPubKey

except that we'd arguably still be missing:

is this a coinbase output? (Coin.fCoinBase)
what was the height of the coin? (Coin.nHeight)

Maybe committing to the coinbase flag would have some use, but committing
to the height would make it hard to chain unconfirmed spends, so at
least that part doesn't seem worth adding.

> I would also (and independently) propose
> separating the hashing of the output values from the output ScriptPubKeys in
> `sha_outputs` so again, applications interested only in summing the values of
> the outputs (for instance to compute fees) do not have to wade through those
> arbitrarily long ScriptPubKeys in the outputs.

If you didn't verify the output scriptPubKeys, you would *only* be able
to care about fees since you couldn't verify where any of the funds went?
And you'd only be able to say fees are "at least x", since they could be
more if one of the scriptPubKeys turned out to be OP_TRUE eg. That might
almost make sense for a transaction accelerator that's trying to increase
the fees; but only if you were doing it for someone else's transaction
(since otherwise you'd care about the output addresses) and only if you
were happy to not receive any change? Seems like a pretty weird use case?

There's some prior discussion on this topic at:

http://www.erisian.com.au/taproot-bip-review/log-2020-03-04.html
http://www.erisian.com.au/taproot-bip-review/log-2020-03-05.html

Cheers,
aj

📅 Original date posted:2019-06-20 📝 Original message:On ...

2023-06-07T20:18:27+02:00

In reply to nevent1q…danz
_________________________

📅 Original date posted:2019-06-20
📝 Original message:On Tue, Jun 18, 2019 at 04:57:34PM -0400, Russell O'Connor wrote:
> So with regards to OP_SECURETHEBAG, I am also "not really seeing any reason to
> complicate the spec to ensure the digest is precommitted as part of the
> opcode."

Also, I think you can simulate OP_SECURETHEBAG with an ANYPREVOUT
(NOINPUT) sighash (Johnson Lau's mentioned this before, but not sure if
it's been spelled out anywhere); ie instead of constructing

X = Hash_BagHash( version, locktime, [outputs], [sequences], num_in )

and having the script be "<X> OP_SECURETHEBAG" you calculate an
ANYPREVOUT sighash for SIGHASH_ANYPREVOUTANYSCRIPT | SIGHASH_ALL:

Y = Hash_TapSighash( 0, 0xc1, version, locktime, [outputs], 0,
amount, sequence)

and calculate a signature sig = Schnorr(P,m) for some pubkey P, and
make your script be "<sig> CHECKSIG".

That loses the ability to commit to the number of inputs or restrict
the nsequence of other inputs, and requires a bigger script (sig and P
are ~96 bytes instead of X's 32 bytes), but is otherwise pretty much the
same as far as I can tell. Both scripts are automatically satisfied when
revealed (with the correct set of outputs), and don't need any additional
witness data.

If you wanted to construct "X" via script instead of hardcoding a value
because it got you generalised covenants or whatever; I think you could
get the same effect with CAT,LEFT, and RIGHT: you'd construct Y in much
the same way you construct X, but you'd then need to turn that into a
signature. You could do so by using pubkey P=G and nonce R=G, which
means you need to calculate s=1+hash(G,G,Y)*1 -- calculating the hash
part is easy, multiplying it by 1 is easy, and to add 1 you can probably
do something along the lines of:

OP_DUP 4 OP_RIGHT 1 OP_ADD OP_SWAP 28 OP_LEFT OP_SWAP OP_CAT

(ie, take the last 4 bytes, increment it using 4-byte arithmetic,
then cat the first 28 bytes and the result. There's overflow issues,
but I think they can be worked around either by allowing you to choose
different locktimes, or by more complicated script)

Cheers,
aj

📅 Original date posted:2019-06-05 📝 Original message:On ...

2023-06-07T20:18:26+02:00

In reply to nevent1q…8eac
_________________________

📅 Original date posted:2019-06-05
📝 Original message:On Fri, May 31, 2019 at 10:35:45PM -0700, Jeremy via bitcoin-dev wrote:
> OP_CHECKOUTPUTSHASHVERIFY is retracted in favor of OP_SECURETHEBAG*.

I think you could generalise that slightly and make it fit in
with the existing opcode naming by calling it something like
"OP_CHECKTXDIGESTVERIFY" and pull a 33-byte value from the stack,
consisting of a sha256 hash and a sighash-byte, and adding a new sighash
value corresponding to the set of info you want to include in the hash,
which I think sounds a bit like "SIGHASH_EXACTLY_ONE_INPUT | SIGHASH_ALL"

FWIW, I'm not really seeing any reason to complicate the spec to ensure
the digest is precommitted as part of the opcode.

Cheers,
aj

📅 Original date posted:2019-02-10 📝 Original message:On ...

2023-06-07T20:16:12+02:00

In reply to nevent1q…r8h7
_________________________

📅 Original date posted:2019-02-10
📝 Original message:On Sun, Feb 10, 2019 at 12:48:40AM +0800, Johnson Lau wrote:
> In a 3 parties channel, let’s say the balance for A, B, C is 2, 3, 6BTC respectively, there are few ways they could make the settlement tx.

The way I look at this is:

* you can have a "channel factory" of 3 or more members (A,B,C,...)
* it's protected by an n-of-n multisig output
* it contains some combination of:
- spends directly to members
- lightning channels between pairs of members
- channel factories between subgroups of members
* when initially setup, the factory just has direct spends to each
member matching the amount they contributed to the factory
* whether you create a lightning channel or a sub-factory is the same
decision as whether you create a lightning channel or a factory
on-chain, so there's no combinatorial explosion.

You can close any channel factory by publishing it (and any higher level
channel factories it was a subgroup of) to the blockchain (at which point
the lower level channel factories and lightning channels remain open),
or you can update a channel factory off-chain by having everyone agree
to a new state -- which is only possible if everyone is online, of course.

Updates to transactions in a lightning channel in a factory, or updates
to a subfactory, don't generally involve updating the containing factory
at all, I think.

I don't think there's much use to having sub-factories -- maybe if you
have a subgroup that's much more active and wants to change channel
balances between each other more frequently than the least active member
of the main factory is online?

As far as NOINPUT goes; this impacts channel factories because cheating
could be by any member of the group, so you can't easily penalise the
cheater. So an eltoo-esque setup where you publish a commitment to the
state that's spendable only by any later state, and is then redeemed
after a timelock seems workable. In that case closing a factory when
you can't get all group members to cooperatively close looks like:

funding tx: n-of-n multisig

state commitment: n-of-n multisig
spends funding tx or earlier state commitment
spendable by later state commitment or settlement

settlement: n-of-n multisig
relative timelock
spends state commitment
spends to members, channels or sub-factories

The settlement tx has to spend with a NOINPUT sig, because the state
commitment could have had to spend different things. If it's a
sub-factory, the funding tx will have been in a factory, so the state
commitment would also have had to be a NOINPUT spend. So tagging
NOINPUT-spendable outputs would mean:

- tagging state commitment outputs (which will be spent shortly with
NOINPUT by the settlement tx, so no real loss here)

- tagging settlement tx outputs if they're lightning channels or
sub-factories (which is something of a privacy loss, I think, since
they could continue off-chain for an indefinite period before being
spent)

I think Johnson's suggested elsewhere that if you spend an input with a
NOINPUT signature, you should make all the outputs be tagged NOINPUT (as
a "best practice rule", rather than consensus-enforced or standardness).
That would avoid the privacy loss here, I think, but might be confusing.

If you wanted to close your factory and send your funds to an external
third-party (a cold-wallet, custodial wallet, or just paying someone
for something), you'd presumably do that via a cooperative close of the
factory, which doesn't require the state/settlement pair or NOINPUT
spends, so the NOINPUT-in means NOINPUT-tagged-outputs doesn't cause
a problem for that use case.

FWIW, I think an interesting way to improve this model might be to *add*
centralisation and trust; so that instead of having the factory have
an n-of-n multisig, have it be protected by k-of-n plus a trusted third
party. If you have the trusted third party check that the only balances
that change in the factory are from the "k" signers, that allows (n-k)
members to be offline at any time, but the remaining members to rebalance
their channels happily. (Theoretically you could do this trustlessly
with covenants, but the spending proofs on chain would be much larger)

Of course, this allows k-signers plus the trusted party to steal funds.
It might be possible for the trusted party to store audit logs of the
partial signatures from each of the k-signers for each transaction to
provide accountability -- where the lack of such logs implies the
trusted third party was cheating.

Cheers,
aj

>
>
>
> > On 9 Feb 2019, at 6:01 PM, Alejandro Ranchal Pedrosa via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > Hi all,
> >>
> >> Side note: I was not able to come up with an similar, eltoo-like protocol that works
> >> if you can't predict in advance who will become absent.
> >>
> > An eltoo-like protocol that works (without going on-chain) if you can't predict in advance who will become absent would be a childchain. If the off-chain protocol can continue updating in the abscence of other parties, it means that other parties' signatures must not be required when they are not involved in the off-chain state update. If other parties' signatures must not be required, there must be a way of having a common verifiable 'last state' to prevent a party to simultaneously 'fork' the state with two different parties, and double-spend. A solution for this is a childchain for Bitcoin. An example of this is what is known as a 'Broken Factory' attack [1] (https://bitcoin.stackexchange.com/questions/77434/how-does-channel-factory-act/81005#81005)
> >
> >> If the expectation is that the unresponsive party returns, fungibility is
> >> not reduced due to output tagging because the above scheme can be used
> >> off-chain until the original channel can be continued.
> >
> > I believe that in many cases other parties won't be able to continue until the unresponsive parties go back online. That might be true in particular scenarios, but generally speaking, the party might have gone unresponsive during a factory-level update (i.e. off-chain closing and opening of channels), while some parties might have given out their signature for the update without receiving a fully signed transaction. In this case they do not even know which channel they have open (the one of the old state that they have fully signed, or the one for the new state that they have given out their signature for). This is known as a 'Stale Factory', and can be exploited by an adversary in a 'Stale Factory' attack [1]. Even if they knew which state they are in (i.e. the party went unresponsive but not during a factory-level update), some of them might have run out of funds in some of their channels of the factory, and might want to update, while they will not be willing to wait for a party to go back online (something for which they also have zero guarantees of).
> >
> > An eltoo-like protocol that works (allowing going on-chain) if you can't in advance who will become absent, then this is precisely why 'Transaction Fragments' have been suggested. They allow an eltoo-like protocol even when one cannot predict in advance who will become absent, or malicious (by publishing invalid states), cause the non-absent parties can unite their fragments and create a valid spendable factory-level transaction that effectively kicks out the malicious parties, while leaving the rest of the factory as it was. To the best of my understanding, the eltoo original proposal also allows this though.
> >
> > Best,
> >
> > Alejandro.
> >
> > [1]: Scalable Lightning Factories for Bitcoin, https://eprint.iacr.org/2018/918.pdf
> >
> >
> > On 08/02/2019 20:01, Jonas Nick via bitcoin-dev wrote:
> >> Output tagging may result in reduced fungibility in multiparty eltoo channels.
> >> If one party is unresponsive, the remaining participants want to remove
> >> the party from the channel without downtime. This is possible by creating
> >> settlement transactions which pay off the unresponsive party and fund a new
> >> channel with the remaining participants.
> >>
> >> When the party becomes unresponsive, the channel is closed by broadcasting the
> >> update transaction as usual. As soon as that happens the remaining
> >> participants can start to update their new channel. Their update signatures
> >> must use SIGHASH_NOINPUT. This is because in eltoo the settlement txid is not
> >> final (because update tx is not confirmed and may have to rebind to another
> >> output). Therefore, the funding output of the new channel must be NOINPUT
> >> tagged. Assuming the remaining parties later settle cooperatively, this loss
> >> of fungibility would not have happened without output tagging.
> >>
> >> funding output update output settlement outputs update output
> >> [ A & B & C ] -> ... -> [ (A & B & C & state CLTV) | (As & Bs & Cs) ] -> [ NOINPUT tagged: (A' & B'), -> ...
> >> C' ]
> >> If the expectation is that the unresponsive party returns, fungibility is
> >> not reduced due to output tagging because the above scheme can be used
> >> off-chain until the original channel can be continued.
> >>
> >> Side note: I was not able to come up with an similar, eltoo-like protocol that works
> >> if you can't predict in advance who will become absent.
> >>
> >> On 12/13/18 12:32 PM, Johnson Lau via bitcoin-dev wrote:
> >>> NOINPUT is very powerful, but the tradeoff is the risks of signature replay. While the key holders are expected not to reuse key pair, little could be done to stop payers to reuse an address. Unfortunately, key-pair reuse has been a social and technical norm since the creation of Bitcoin (the first tx made in block 170 reused the previous public key). I don’t see any hope to change this norm any time soon, if possible at all.
> >>>
> >>> As the people who are designing the layer-1 protocol, we could always blame the payer and/or payee for their stupidity, just like those people laughed at victims of Ethereum dumb contracts (DAO, Parity multisig, etc). The existing bitcoin script language is so restrictive. It disallows many useful smart contracts, but at the same time prevented many dumb contracts. After all, “smart” and “dumb” are non-technical judgement. The DAO contract has always been faithfully executed. It’s dumb only for those invested in the project. For me, it was just a comedy show.
> >>>
> >>> So NOINPUT brings us more smart contract capacity, and at the same time we are one step closer to dumb contracts. The target is to find a design that exactly enables the smart contracts we want, while minimising the risks of misuse.
> >>>
> >>> The risk I am trying to mitigate is a payer mistakenly pay to a previous address with the exactly same amount, and the previous UTXO has been spent using NOINPUT. Accidental double payment is not uncommon. Even if the payee was honest and willing to refund, the money might have been spent with a replayed NOINPUT signature. Once people lost a significant amount of money this way, payers (mostly exchanges) may refuse to send money to anything other than P2PKH, native-P2WPKH and native-P2WSH (as the only 3 types without possibility of NOINPUT)
> >>>
> >>> The proposed solution is that an output must be “tagged” for it to be spendable with NOINPUT, and the “tag” must be made explicitly by the payer. There are 2 possible ways to do the tagging:
> >>>
> >>> 1. A certain bit in the tx version must be set
> >>> 2. A certain bit in the scriptPubKey must be set
> >>>
> >>> I will analyse the pros and cons later.
> >>>
> >>> Using eltoo as example. The setup utxo is a simple 2-of-2 multisig, and should not be tagged. This makes it indistinguishable from normal 1-of-1 utxo. The trigger tx, which spends the setup utxo, should be tagged, so the update txs could spend the trigger utxo with NOINPUT. Similarly, all update txs should be tagged, so they could be spent by other update txs and settlement tx with NOINPUT. As the final destination, there is no need to tag in the settlement tx.
> >>>
> >>> In payer’s perspective, tagging means “I believe this address is for one-time-use only” Since we can’t control how other people manage their addresses, we should never do tagging when paying to other people.
> >>>
> >>> I mentioned 2 ways of tagging, and they have pros and cons. First of all, tagging in either way should not complicate the eltoo protocol in anyway, nor bring extra block space overhead.
> >>>
> >>> A clear advantage of tagging with scriptPubKey is we could tag on a per-output basis. However, scriptPubKey tagging is only possible with native-segwit, not P2SH. That means we have to disallow NOINPUT in P2SH-segwit (Otherwise, *all* P2SH addresses would become “risky” for payers) This should be ok for eltoo, since it has no reason to use P2SH-segwit in intermediate txs, which is more expensive.
> >>>
> >>> Another problem with scriptPubKey tagging is all the existing bech32 implementations will not understand the special tag, and will pay to a tagged address as usual. An upgrade would be needed for them to refuse sending to tagged addresses by default.
> >>>
> >>> On the other hand, tagging with tx version will also protect P2SH-segwit, and all existing wallets are protected by default. However, it is somewhat a layer violation and you could only tag all or none output in the same tx. Also, as Bitcoin Core has just removed the tx version from the UTXO database, adding it back could be a little bit annoying, but doable.
> >>>
> >>> There is an extension to the version tagging, which could make NOINPUT even safer. In addition to tagging requirement, NOINPUT will also sign the version of the previous tx. If the wallet always uses a randomised tx version, it makes accidental replay very unlikely. However, that will burn a few more bits in the tx version field.
> >>>
> >>> While this seems fully compatible with eltoo, is there any other proposals require NOINPUT, and is adversely affected by either way of tagging?
> >>> _______________________________________________
> >>> bitcoin-dev mailing list
> >>> bitcoin-dev at lists.linuxfoundation.org
> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>>
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

📅 Original date posted:2018-12-12 📝 Original message:On ...

2023-06-07T20:15:34+02:00

In reply to nevent1q…76ja
_________________________

📅 Original date posted:2018-12-12
📝 Original message:On Tue, Dec 11, 2018 at 05:50:24PM -0500, Russell O'Connor via bitcoin-dev wrote:
> On Sun, Dec 9, 2018 at 2:13 PM Johnson Lau <jl2012 at xbt.hk> wrote:
> The current proposal is that a 64-byte signature will be used for the
> default “signing all” sighash, and 65-byte for other sighash types. The
> space saved will allow a few more txs in a block, so I think it worths
> doing. However, this also makes witness weight estimation more difficult in
> multisig cases.

This seems strange to me -- why wouldn't you just assume every signature
is 65 witness bytes, and just be grateful for the prioritisation benefit
if someone chooses a shorter signature? Your error margin is just 0.25
vbytes per signature.

> I tend to think in opposite terms. Is there a proof that any script can be
> transformed into an equivalent one that avoids witness weight malleability?

An alternative generalisation: is there a proof that all valid witnesses
will have a weight within some small range?

> Moreover, even if witness weight malleability is entirely avoidable, it always
> seems to come at a cost. Taking as an example libwally's proposed "
> csv_2of3_then_2" Script, it begins with "OP_DEPTH OP_1SUB OP_1SUB"

(DEPTH 2 NUMNOTEQUAL seems like it would have been more obvious...)

Cheers,
aj

📅 Original date posted:2018-11-23 📝 Original message:On ...

2023-06-07T20:15:17+02:00

In reply to nevent1q…x2wj
_________________________

📅 Original date posted:2018-11-23
📝 Original message:On Wed, Nov 21, 2018 at 12:15:44PM +0100, Christian Decker via bitcoin-dev wrote:
> One minor thing that I noticed a while ago and that I meant
> to fix on BIP118 is that `hashSequence` does not need to be blanked for
> eltoo to work (since where it is needed we also use `sighash_single`),
> so I'm tempted to remove that redundant blanking. It may not make a lot
> of difference but it'd limit the ability to change the number of inputs
> to a NOINPUT transaction (this now being the only field that commits to
> the set of inputs).

Commiting to just the sequence numbers seems really weird to me; it
only really prevents you from adding inputs, since you could still
replace any input that was meant to be there by almost any arbitrary
other transaction...

I could see this *maybe* making sense if you at least committed to the
values of each input's outpoint; since that would be an actual constraint?

I don't think you can commit to anything else about the other inputs:

-- txids of the other transactions wouldn't work if you had other
NOINPUT txes, and would introduce O(N^2) validation cost if someone
signed every input with NOINPUT but committed to the txids of
every other input

-- scriptPubKeys wouldn't really work for eltoo-like constructions
that want to vary the scripts but apply the same sig, but might
work sometimes?

-- witness scripts for the other inputs could be unknown at your
signing time, or arbitrarily large and thus a pain to have to send
to a hardware wallet

Just treating NOINPUT as a subset of ANYONECANPAY seems simpler to
me though...

> As for your proposal, I really like the `sighash_scriptmask` proposal,
> and committing to the fees (with the `nofee` escape hatch) also works
> seems also a nice fix. My one concern is that introducing a new opcode
> to mask things in the sighash looks like a similar layering violation as
> `codeseparator` was, but that's just a minor issue imho.

I think OP_MASK is okay as far as layering goes, if you just think of it
as a (set of) multibyte "OP_MASKED_PUSH" opcode(s). So when you
pseudocode a script like:

<n> OP_CSV OP_DROP OP_CHECKSIG

and then decide <n> needs to be masked, you rewrite it as:

[n] OP_CSV OP_DROP OP_CHECKSIG

indicating n is masked, and don't worry about the exact bytes that will
encode the push, anymore than you currently worry about whether it's
OP_0, OP_1..16, <1..75>+1..75-bytes, PUSHDATA[1,2,3]+n+n-bytes.

As long as OP_MASK only applies to a PUSH and it's an error for OP_MASK
not to be immediately followed by that PUSH, I think that all works
out fine.

Cheers,
aj

📅 Original date posted:2018-11-20 📝 Original message:On ...

2023-06-07T20:15:15+02:00

In reply to nevent1q…arfv
_________________________

📅 Original date posted:2018-11-20
📝 Original message:On Mon, Nov 19, 2018 at 02:37:57PM -0800, Pieter Wuille via bitcoin-dev wrote:
> 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.
> * The scriptPubKey being spent is added to the sighash, unless
> SIGHASH_SCRIPTMASK is set.
> * The transaction fee is added to the sighash, unless SIGHASH_NOFEE is set.
> * hashPrevouts, hashSequence, and outpoint are set to null when
> SIGHASH_NOINPUT is set (like BIP118, but not for scriptCode).

Current flags are {ALL, NONE, SINGLE} and ANYONECANPAY, and the BIP143
tx digest consists of the hash of:

1 nVersion
4 outpoint
5 input scriptCode
6 input's outpoint value
7 input's nSeq
9 nLocktime
10 sighash

2 hashPrevOuts (commits to 4,5,6; unless ANYONECANPAY)
3 hashSequence (commits to 7; only if ALL and not ANYONECANPAY)
8 hashOutputs
- NONE: 0
- SINGLE: {value,scriptPubKey} for corresponding output
- otherwise: {value,scriptPubKey} for all outputs

The fee is committed to by hashPrevOuts and hashOutputs, which means
NOFEE is only potentially useful if ANYONECANPAY or NONE or SINGLE is set.

For NOINPUT, (2),(3),(4) are cleared, and SCRIPTMASK (which munges (5))
is only useful given NOINPUT, since (4) indirectly commits to (5).

Given this implementation, NOINPUT effectively implies ANYONECANPAY,
I think. (I think that is also true of BIP 118's NOINPUT spec)

Does it make sense to treat this as two classes of options, affecting
the input and output side:

output: (pick one, using bits 0,1)
* NONE -- don't care where the money goes
* SINGLE -- want this output
* ALL -- want exactly this set of outputs

input: (pick one, using bits 4,5)
* PARTIALSCRIPT -- spending from some tx with roughly this script (and
maybe others; SCRIPTMASK|NOINPUT|ANYONECANPAY)
* KNOWNSCRIPT -- spending from some tx with exactly this script (and
maybe others; NOINPUT|ANYONECANPAY)
* KNOWNTX -- spending from this tx (and maybe others; ANYONECANPAY)
* ALL_INPUTS -- spending from exactly these txes

combo: (flag, bit 6)
* NOFEE -- don't commit to the fee

I think NONE without NOFEE doesn't make much sense, and
NOFEE|ALL|ALL_INPUTS would also be pretty weird. Might make sense to
warn/error on signing when asking for those combinations, and maybe even
to fail on validating them.

(Does it make sense to keep SIGHASH_NONE? I guess SIGHASH_NONE|ALL_INPUTS
could be useful if you just use sigs on one of the other inputs to commit
to a useful output)

FWIW, OP_MASK seems a bit complicated to me. How would you mask a script
that looks like:

OP_MASK IF ENDIF <q> ...

or:

IF OP_MASK ENDIF ...

I guess if you make the rule be "for every OP_MASK in scriptCode the
*immediately* subsequent opcode/push is removed (if present)" it would
be fine though -- that would make OP_MASK in both the above not have
any effect. (Maybe a more explicit name like "MASK_PUSH_FOR_SIGHASH"
or something might be good?)

I don't have a reason why, but committing to the scriptCode feels to me
like it reduces the "hackiness" of NOINPUT a lot.

Cheers,
aj

📅 Original date posted:2018-03-14 📝 Original message:On 14 ...

2023-06-07T20:11:13+02:00

In reply to nevent1q…rvwf
_________________________

📅 Original date posted:2018-03-14
📝 Original message:On 14 March 2018 5:46:55 AM GMT-04:00, Kalle Rosenbaum via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>Thank you.
>
>I can't really see from your proposal if you had thought of this: A
>soft
>fork can make old nodes accept invalid message signatures as valid. For
>example, a "signer" can use a witness version unknown to the verifier
>to
>fool the verifier. Witness version is detectable (just reject unknown
>witness versions) but there may be more subtle changes. Segwit was not
>"detectable" in that way, for example.
>
>This is the reason why I withdrew BIP120. If you have thought about the
>above, I'd be very interested.
>
>/Kalle
>
>Sent from my Sinclair ZX81
>
>Den 14 mars 2018 16:10 skrev "Karl Johan Alm via bitcoin-dev" <
>bitcoin-dev at lists.linuxfoundation.org>:
>
>Hello,
>
>I am considering writing a replacement for the message signing tools
>that are currently broken for all but the legacy 1xx addresses. The
>approach (suggested by Pieter Wuille) is to do a script based
>approach. This does not seem to require a lot of effort for
>implementing in Bitcoin Core*. Below is my proposal for this system:
>
>A new structure SignatureProof is added, which is a simple scriptSig &
>witnessProgram container that can be serialized. This is passed out
>from/into the signer/verifier.
>
>RPC commands:
>
>sign <address> <message> [<prehashed>=false]
>
>Generates a signature proof for <message> using the same method that
>would be used to spend coins sent to <address>.**
>
>verify <address> <message> <proof> [<prehashed>=false]
>
>Deserializes and executes the proof using a custom signature checker
>whose sighash is derived from <message>. Returns true if the check
>succeeds, and false otherwise. The scriptPubKey is derived directly
>from <address>.**
>
>Feedback welcome.
>
>-Kalle.
>
>(*) Looks like you can simply use VerifyScript with a new signature
>checker class. (h/t Nicolas Dorier)
>(**) If <prehashed> is true, <message> is the sighash, otherwise
>sighash=sha256d(message).
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Wouldn't it be sufficient for old nodes to check for standardness of the spending script and report non-standard scripts as either invalid outright, or at least highly questionable? That should prevent confusion as long as soft forks are only making nonstandard behaviours invalid.

Cheers,
aj

--
Sent from my phone.

📅 Original date posted:2017-09-29 📝 Original message:On ...

2023-06-07T20:06:36+02:00

In reply to nevent1q…jq5z
_________________________

📅 Original date posted:2017-09-29
📝 Original message:On Thu, Sep 28, 2017 at 06:06:29PM -0700, Mark Friedenbach via bitcoin-dev wrote:
> Unlike other proposed fixes to the fee model, this is not trivially
> broken by paying the miner out of band.

I think CPFP allows this to break: a miner getting paid out of band
would just make the block look like:

(1) 100kB of 5s/byte transactions
(2) 850kB of 35s/byte transactions
(3) 50kB of 95s/byte transactions, miner paying themselves

As long as every transaction in (1) has an output spent in (3), that seems
like it would be perfectly legitimate for CPFP.

I think it would be cheaper overall than the fee refund transactions
as well. People making arrangements with miners directly would have to
pay for block space to cover:

out:
30-40B dest address
30-40B change address
10B cpfp link
in:
36B cpfp txid

then to actual spend their change:

in:
36B+70B txid+idx + witness for change

for a total of 142-162B plus 70B witness, as well as some sort of out of
band payment to the miner (paying fees directly to miners via a lightning
channel, comes to mind).

If I understand your suggestion correctly, it would look like:

coinbase:
30-40B fee overflow payment back to transactor

out:
30-40B dest address
30-40B change address
30-40B fee-overflow output marker

and to spend their change:

in:
36B+70B txid+idx + witness for change
36B+70B txid+idx + witness for fee overflow

for a total of 192-232B plus 140B witness; so that's 40%-50% more block
weight used. The fee overflow would probably be pretty small amounts,
as well, so kind of annoying to actually collect.

If you end up with two change addresses per tx generally, that also seems
like it might it annoyingly easy to link your transactions together
(unless fees end up getting coinjoined or run through satoshidice or
something). If you end up sending lots of fee overflows to a single
address, that links your txes too of course.

A miner might be willing to do that in order to charge a two-part tariff:
ie, a very high "subscription" fee that's paid once a year or similar,
along with very low per-tx fees. The only reason I can think of why
someone would buy a subscription is if the miner's effectively a monopoly
and submitting transactions via the p2p network isn't reliable enough;
the whole point of a two-part tariff is to be as expensive as each user
can bear, so it won't ever be any cheaper.

FWIW, I think reliability-based-price-discrimination might allow higher
mining revenue via having txes with differing fee rates in the same
block: eg if people are happy to pay 100s/byte for confirmation within
30 minutes, and likewise willing to pay 10s/byte for confirmation within
3 hours, and there aren't enough transactions of either type to hit the
block size limit, then a monopoly miner / mining cartel would do better
by accepting 100s/byte txes at any time, while accepting 10s/byte txes
in any given block, but only with about a 1-in-7 chance for any given tx.

Looking at estimatefee.com, there's currently apparently ~200kB of 82s/B
or more transactions, while to fill a 1MB block you'd have to go all the
way down to 2.1s/B -- so if you have to charge all txes at the marginal
fee rate, that's 200kB at 82s/B for 0.16 BTC rather than 1MB at 2.1s/B
for 0.021 BTC.

I think ideally, it would probably be better to let the block weight
limit adjust to deal with high-frequency components to changes in demand,
and have fee rates adjust more slowly to address the long-term trends
in changes to demand: if fee rates only adjust slowly, then they're
(by definition) easily predictable and you don't *have* to have much
concern about getting them wrong. (You'd still need to add the correct
fee at the time you want to publish a pre-signed transaction that was
very old, but CPFP isn't too bad at that).

Cheers,
aj

📅 Original date posted:2017-09-14 📝 Original message:On ...

2023-06-07T20:05:54+02:00

In reply to nevent1q…55dh
_________________________

📅 Original date posted:2017-09-14
📝 Original message:On Tue, Sep 12, 2017 at 09:10:18AM -0700, Simon Liu wrote:
> It would be a good starting point if the current policy could be
> clarified, so everyone is on the same page, and there is no confusion.

Collecting various commentary from here and reddit, I think current de
facto policy is something like:

* Vulnerabilities should be reported via security at bitcoincore.org [0]

* A critical issue (that can be exploited immediately or is already
being exploited causing large harm) will be dealt with by:
* a released patch ASAP
* wide notification of the need to upgrade (or to disable affected
systems)
* minimal disclosure of the actual problem, to delay attacks
[1] [2]

* A non-critical vulnerability (because it is difficult or expensive to
exploit) will be dealt with by:
* patch and review undertaken in the ordinary flow of development
* backport of a fix or workaround from master to the current
released version [2]

* Devs will attempt to ensure that publication of the fix does not
reveal the nature of the vulnerability by providing the proposed fix
to experienced devs who have not been informed of the vulnerability,
telling them that it fixes a vulnerability, and asking them to identify
the vulnerability. [2]

* Devs may recommend other bitcoin implementations adopt vulnerability
fixes prior to the fix being released and widely deployed, if they
can do so without revealing the vulnerability; eg, if the fix has
significant performance benefits that would justify its inclusion. [3]

* Prior to a vulnerability becoming public, devs will generally recommend
to friendly altcoin devs that they should catch up with fixes. But this
is only after the fixes are widely deployed in the bitcoin network. [4]

* Devs will generally not notify altcoin developers who have behaved
in a hostile manner (eg, using vulnerabilities to attack others, or
who violate embargoes). [5]

* Bitcoin devs won't disclose vulnerability details until >80% of bitcoin
nodes have deployed the fixes. Vulnerability discovers are encouraged
and requested to follow the same policy. [1] [6]

Those seem like pretty good policies to me, for what it's worth.

I haven't seen anything that indicates bitcoin devs will *ever* encourage
public disclosure of vulnerabilities (as opposed to tolerating other
people publishing them [6]). So I'm guessing current de facto policy is
more along the lines of:

* Where possible, Bitcoin devs will never disclose vulnerabilities
publically while affected code may still be in use (including by
altcoins).

rather than something like:

* Bitcoin devs will disclose vulnerabilities publically after 99% of the
bitcoin network has upgraded [7], and fixes have been released for
at least 12 months.

Instinctively, I'd say documenting this policy (or whatever it actually
is) would be good, and having all vulnerabilities get publically released
eventually would also be good; that's certainly the more "open source"
approach. But arguing the other side:

- documenting security policy gives attackers a better handle on where
to find weak points; this may be more harm than there is benefit to
improving legitimate users' understanding of and confidence in the
development process

- the main benefit of public vulnerability disclosure is a better
working relationship with security researchers and perhaps better
understanding of what sort of bugs happen in practice in general;
but if most of your security research is effectively in house [6],
maybe those benefits aren't as great as the harm done by revealing
even old vulnerabilities to attackers

If the first of those arguments holds, well, hopefully this message has
egregious errors that no one will correct, or it will quickly get lost
in this list's archives...

Cheers,
aj

[0] http://bitcoincore.org/en/contact
referenced from .github/ISSUE_TEMPLATE.md in git

[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/014986.html

[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/014990.html

[3] https://www.reddit.com/r/btc/comments/6zf1qo/peter_todd_nicely_pulled_away_attention_from_jjs/dmxcw70/

[4] https://www.reddit.com/r/btc/comments/6z827o/chris_jeffrey_jj_discloses_bitcoin_attack_vector/dmxdg83/

[5] https://www.reddit.com/r/btc/comments/6zb3lp/maxwell_admits_core_sat_on_vulnerability/dmv4y7g/

[6] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/014991.html

[7] Per http://luke.dashjr.org/programs/bitcoin/files/charts/branches.html
it seems like 1.7% of the network is running known-vulnerable versions
0.8 and 0.9; but only 0.37% are running 0.10 or 0.11, so that might argue
revealing any vulnerabilities fixed since 0.12.0 would be fine...
(bitnodes.21.co doesn't seem to break down anything earlier than 0.12)