Re: [bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`

[Greg Sanders via bitcoin-dev]

> One point of discomfort I have with Eltoo that I think is not universal,
but is shared by some others, is that non-punitive channels may not be good
for high-value channels as you do want, especially in a congested
blockspace world, punishments to incentivize correct behavior (otherwise
cheating may look like a free option).

Without derailing the conversation too far, "fully" punitive channels also
make large value channels more dangerous from the perspective of bugs
causing old states to be published. High value channels you'll need to have
very high uptime. If you're available, your counterparty is incentivized to
do a mutual close to reduce fees and remove timelocks on outputs. I think
these tradeoffs will result in both types existing for N==2.

On Sat, Feb 19, 2022 at 8:56 AM Jeremy Rubin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> This is a fascinating post and I'm still chewing on it.
>
> Chiming in with two points:
>
> Point 1, note with respect to evictions, revivals, CTV, TLUV:
>
> CTV enables 1 person to be evicted in O(log N) or one person to leave in
> O(log N). TLUV enables 1 person to leave in O(1) O(log N) transactions, but
> evictions take (AFAICT?) O(N) O(log N) transactions because the un-live
> party stays in the pool. Hence OP_EVICT helps also make it so you can kick
> someone out, rather than all having to leave, which is an improvement.
>
> CTV rejoins work as follows:
>
> suppose you have a pool with 1 failure, you need to do log N txns to evict
> the failure, which creates R * log_R(N) outputs, which can then do a
> transaction to rejoin.
>
> For example, suppose I had 64 people in a radix 4 tree. you'd have at the
> top level 4 groups of 16, then 4 groups of 4 people, and then 1 to 4 txns.
> Kicking 1 person out would make you do 3 txns, and create 12 outputs total.
> A transaction spending the 11 outputs that are live would capture 63 people
> back into the tree, and with CISA would not be terribly expensive. To be a
> bit more economical, you might prefer to just join the 3 outputs with 16
> people in it, and yield 48 people in one pool. Alternatively, you can
> lazily re-join if fees make it worth it/piggybacking another transaction,
> or operate independently or try to find new, better, peers.
>
> Overall this is the type of application that necessitates *exact* byte
> counting. Oftentimes things with CTV seem inefficient, but when you crunch
> the numbers it turns out not to be so terrible. OP_EVICT seems promising in
> this regard compared to TLUV or accumulators.
>
> Another option is to randomize the CTV trees with multiple outputs per
> party (radix Q), then you need to do Q times the evictions, but you end up
> with sub-pools that contain more people/fractional liquidity (this might
> happen naturally if CTV Pools have channels in them, so it's good to model).
>
>
> Point 2, on Eltoo:
>
> One point of discomfort I have with Eltoo that I think is not universal,
> but is shared by some others, is that non-punitive channels may not be good
> for high-value channels as you do want, especially in a congested
> blockspace world, punishments to incentivize correct behavior (otherwise
> cheating may look like a free option).
>
> Thus I'm reluctant to fully embrace designs which do not permit nested
> traditional punitive channels in favor of Eltoo, when Eltoo might not have
> product-market-fit for higher valued channels.
>
> If someone had a punitive-eltoo variant that would ameliorate this concern
> almost entirely.
>
> Cheers,
>
> Jeremy
>
>
>
> --
> @JeremyRubin 
>
> On Fri, Feb 18, 2022 at 3:40 PM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Good morning ariard,
>>
>>
>> > > A statechain is really just a CoinPool hosted inside a
>> > >  Decker-Wattenhofer or Decker-Russell-Osuntokun construction.
>> >
>> > Note, to the best of my knowledge, how to use LN-Penalty in the context
>> of multi-party construction is still an unsolved issue. If an invalidated
>> state is published on-chain, how do you guarantee that the punished output
>> value is distributed "fairly" among the "honest" set of users ? At least
>> > where fairness is defined as a reasonable proportion of the balances
>> they owned in the latest state.
>>
>> LN-Penalty I believe is what I call Poon-Dryja?
>>
>> Both Decker-Wattenhofer (has no common colloquial name) and
>> Decker-Russell-Osuntokun ("eltoo") are safe with N > 2.
>> The former has bad locktime tradeoffs in the unilateral close case, and
>> the latter requires `SIGHASH_NOINPUT`/`SIGHASH_ANYPREVOUT`.
>>
>>
>> > > In principle, a set of promised outputs, if the owners of those
>> > > outputs are peers, does not have *any* inherent order.
>> > > Thus, I started to think about a commitment scheme that does not
>> > > impose any ordering during commitment.
>> >
>> > I think we should dissociate a) *outputs publication ordering* from the
>> b) *spends paths 

Re: [bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`

[ZmnSCPxj via bitcoin-dev]

Good morning Jeremy,

> This is a fascinating post and I'm still chewing on it.
>
> Chiming in with two points:
>
> Point 1, note with respect to evictions, revivals, CTV, TLUV:
>
> CTV enables 1 person to be evicted in O(log N) or one person to leave in 
> O(log N). TLUV enables 1 person to leave in O(1) O(log N) transactions, but 
> evictions take (AFAICT?) O(N) O(log N) transactions because the un-live party 
> stays in the pool. Hence OP_EVICT helps also make it so you can kick someone 
> out, rather than all having to leave, which is an improvement.
>
> CTV rejoins work as follows:
>
> suppose you have a pool with 1 failure, you need to do log N txns to evict 
> the failure, which creates R * log_R(N) outputs, which can then do a 
> transaction to rejoin.
>
> For example, suppose I had 64 people in a radix 4 tree. you'd have at the top 
> level 4 groups of 16, then 4 groups of 4 people, and then 1 to 4 txns. 
> Kicking 1 person out would make you do 3 txns, and create 12 outputs total. A 
> transaction spending the 11 outputs that are live would capture 63 people 
> back into the tree, and with CISA would not be terribly expensive. To be a 
> bit more economical, you might prefer to just join the 3 outputs with 16 
> people in it, and yield 48 people in one pool. Alternatively, you can lazily 
> re-join if fees make it worth it/piggybacking another transaction, or operate 
> independently or try to find new, better, peers.
>
> Overall this is the type of application that necessitates *exact* byte 
> counting. Oftentimes things with CTV seem inefficient, but when you crunch 
> the numbers it turns out not to be so terrible. OP_EVICT seems promising in 
> this regard compared to TLUV or accumulators.
>
> Another option is to randomize the CTV trees with multiple outputs per party 
> (radix Q), then you need to do Q times the evictions, but you end up with 
> sub-pools that contain more people/fractional liquidity (this might happen 
> naturally if CTV Pools have channels in them, so it's good to model).

Do note that a weakness of CTV is that you *have to* split up the CoinPool into 
many smaller pools, and re-merging them requires waiting for onchain 
confirmation.
This overall means you have no real incentive to revive the original CoinPool 
minus evicted parties.
`OP_EVICT` lets the CoinPool revival be made into the same transaction that 
performs the evict.

> Point 2, on Eltoo:
>
> One point of discomfort I have with Eltoo that I think is not universal, but 
> is shared by some others, is that non-punitive channels may not be good for 
> high-value channels as you do want, especially in a congested blockspace 
> world, punishments to incentivize correct behavior (otherwise cheating may 
> look like a free option).
>
> Thus I'm reluctant to fully embrace designs which do not permit nested 
> traditional punitive channels in favor of Eltoo, when Eltoo might not have 
> product-market-fit for higher valued channels.
>
> If someone had a punitive-eltoo variant that would ameliorate this concern 
> almost entirely.

Unfortunately, it seems the way to any kind of N > 2 construction *with* 
penalty would require bonds, such as the recent PathCoin idea (which is an N > 
2 construction *with* penalty, and is definitely offchain for much of its 
operation).

Having a Decker-Russell-Osuntokun "factory" layer that hosts multiple 
Poon-Dryja channels is not quite a solution; if old state on 
Decker-Russell-Osuntokun layer pushes through, then its obsolete Poon-Dryja 
channels will have all states invalid and unclaimable, but in case of Sybil 
where some participants are sockpuppets, it would still be possible for a thief 
to claim the funds from an "invalidated" Poon-Dryja channel if that channel is 
with a sockpuppet.


Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`

[Jeremy Rubin via bitcoin-dev]

This is a fascinating post and I'm still chewing on it.

Chiming in with two points:

Point 1, note with respect to evictions, revivals, CTV, TLUV:

CTV enables 1 person to be evicted in O(log N) or one person to leave in
O(log N). TLUV enables 1 person to leave in O(1) O(log N) transactions, but
evictions take (AFAICT?) O(N) O(log N) transactions because the un-live
party stays in the pool. Hence OP_EVICT helps also make it so you can kick
someone out, rather than all having to leave, which is an improvement.

CTV rejoins work as follows:

suppose you have a pool with 1 failure, you need to do log N txns to evict
the failure, which creates R * log_R(N) outputs, which can then do a
transaction to rejoin.

For example, suppose I had 64 people in a radix 4 tree. you'd have at the
top level 4 groups of 16, then 4 groups of 4 people, and then 1 to 4 txns.
Kicking 1 person out would make you do 3 txns, and create 12 outputs total.
A transaction spending the 11 outputs that are live would capture 63 people
back into the tree, and with CISA would not be terribly expensive. To be a
bit more economical, you might prefer to just join the 3 outputs with 16
people in it, and yield 48 people in one pool. Alternatively, you can
lazily re-join if fees make it worth it/piggybacking another transaction,
or operate independently or try to find new, better, peers.

Overall this is the type of application that necessitates *exact* byte
counting. Oftentimes things with CTV seem inefficient, but when you crunch
the numbers it turns out not to be so terrible. OP_EVICT seems promising in
this regard compared to TLUV or accumulators.

Another option is to randomize the CTV trees with multiple outputs per
party (radix Q), then you need to do Q times the evictions, but you end up
with sub-pools that contain more people/fractional liquidity (this might
happen naturally if CTV Pools have channels in them, so it's good to model).


Point 2, on Eltoo:

One point of discomfort I have with Eltoo that I think is not universal,
but is shared by some others, is that non-punitive channels may not be good
for high-value channels as you do want, especially in a congested
blockspace world, punishments to incentivize correct behavior (otherwise
cheating may look like a free option).

Thus I'm reluctant to fully embrace designs which do not permit nested
traditional punitive channels in favor of Eltoo, when Eltoo might not have
product-market-fit for higher valued channels.

If someone had a punitive-eltoo variant that would ameliorate this concern
almost entirely.

Cheers,

Jeremy



--
@JeremyRubin 

On Fri, Feb 18, 2022 at 3:40 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning ariard,
>
>
> > > A statechain is really just a CoinPool hosted inside a
> > >  Decker-Wattenhofer or Decker-Russell-Osuntokun construction.
> >
> > Note, to the best of my knowledge, how to use LN-Penalty in the context
> of multi-party construction is still an unsolved issue. If an invalidated
> state is published on-chain, how do you guarantee that the punished output
> value is distributed "fairly" among the "honest" set of users ? At least
> > where fairness is defined as a reasonable proportion of the balances
> they owned in the latest state.
>
> LN-Penalty I believe is what I call Poon-Dryja?
>
> Both Decker-Wattenhofer (has no common colloquial name) and
> Decker-Russell-Osuntokun ("eltoo") are safe with N > 2.
> The former has bad locktime tradeoffs in the unilateral close case, and
> the latter requires `SIGHASH_NOINPUT`/`SIGHASH_ANYPREVOUT`.
>
>
> > > In principle, a set of promised outputs, if the owners of those
> > > outputs are peers, does not have *any* inherent order.
> > > Thus, I started to think about a commitment scheme that does not
> > > impose any ordering during commitment.
> >
> > I think we should dissociate a) *outputs publication ordering* from the
> b) *spends paths ordering* itself. Even if to each spend path a output
> publication is attached, the ordering constraint might not present the same
> complexity.
> >
> > Under this distinction, are you sure that TLUV imposes an ordering on
> the output publication ?
>
> Yes, because TLUV is based on tapleaf revelation.
> Each participant gets its own unique tapleaf that lets that participant
> get evicted.
>
> In Taproot, the recommendation is to sort the hashes of each tapleaf
> before arranging them into a MAST that the Taproot address then commits to.
> This sort-by-hash *is* the arbitrary ordering I refer to when I say that
> TLUV imposes an arbitrary ordering.
> (actually the only requirement is that pairs of scripts are
> sorted-by-hash, but it is just easier to sort the whole array by hash.)
>
> To reveal a single participant in a TLUV-based CoinPool, you need to
> reveal O(log N) hashes.
> It is the O(log N) space consumption I want to avoid with `OP_EVICT`, and
> I believe the reason for that O(log N) revelation 

Re: [bitcoin-dev] [Pre-BIP] Fee Accounts

[Jeremy Rubin via bitcoin-dev]

> As I said, it's a new kind of pinning attack, distinct from other types
of pinning attack.

I think pinning is "formally defined" as sequences of transactions which
prevent or make it less likely for you to make any progress (in terms of
units of computation proceeding).

Something that only increases possibility to make progress cannot be
pinning.

If you want to call it something else, with a negative connotation, maybe
call it "necromancing" (bringing back txns that would otherwise be
feerate/fee irrational).

I would posit that we should be wholly unconcerned with necromancing -- if
your protocol is particularly vulnerable to a third party necromancing then
your protocol is insecure and we shouldn't hamper Bitcoin's forward
progress on secure applications to service already insecure ones. Lightning
is particularly necromancy resistant by design, but pinning vulnerable.
This is also true with things like coinjoins which are necromancy resistant
but pinning vulnerable.

Necromancy in particular is something that isn't uniquely un-present in
Bitcoin today, and things like package relay and elimination of pinning are
inherently at odds with making necromancy either for CPFP use cases.

In particular, for the use case you mentioned "Eg a third party could mess
up OpenTimestamps calendars at relatively low cost by delaying the mining
of timestamp txs.", this is incorrect. A third party can only accelerate
the mining on the timestamp transactions, but they *can* accelerate the
mining of any such timestamp transaction. If you have a single output chain
that you're RBF'ing per block, then at most they can cause you to shift the
calendar commits forward one block. But again, they cannot pin you. If you
want to shift it back one block earlier, just offer a higher fee for the
later RBF'd calendar. Thus the interference is limited by how much you wish
to pay to guarantee your commitment is in this block as opposed to the next.

By the way, you can already do out-of-band transaction fees to a very
similar effect, google "BTC transaction accelerator". If the attack were at
all valuable to perform, it could happen today.

Lastly, if you do get "necromanced" on an earlier RBF'd transaction by a
third party for OTS, you should be relatively happy because it cost you
less fees overall, since the undoing of your later RBF surely returned some
satoshis to your wallet.

Best,

Jeremy
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Pre-BIP] Fee Accounts

[Peter Todd via bitcoin-dev]

On Thu, Feb 10, 2022 at 12:08:59AM -0800, Jeremy Rubin wrote:
> That's not really pinning; painning usually refers to pinning something to
> the bottom of the mempool whereas these mechanisms make it easier to
> guarantee that progress can be made on confirming the transactions you're
> interested in.

As I said, it's a new kind of pinning attack, distinct from other types of
pinning attack.

> Often times in these protocols "the call is coming inside the house". It's
> not a third party adding fees we are scared of, it's a direct party to the
> protocol!

Often times that is true. But other times that is not true! I gave examples of
use-cases where being able to arbitrary add fees to transactions is harmful;
the onus is on you to argue why that is acceptable to burden those users with a
new class of attack.

> Sponsors or fee accounts would enable you to ensure the protocol you're
> working on makes forward progress. For things like Eltoo the internal
> ratchet makes this work well.
> 
> Protocols which depend on in mempool replacements before confirmation
> already must be happy (should they be secure) with any prior state being
> mined. If a third party pays the fee you might even be happier since the
> execution wasn't on your dime.

"Must be able to deal with" is not the same thing as "Must be happy". While
those use-cases do have to deal with those exceptional cases happening
occasionally, it's harmful if an attacker can harass you by making those
exceptional cases happen frequently.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Peter Todd via bitcoin-dev]

On Tue, Jan 18, 2022 at 02:57:30AM +0100, Prayank wrote:
> Hi Peter,
> 
> > that current lacks compelling use-cases clearly beneficial to all users
> 
> All the use cases shared in below links look compelling enough to me and we 
> can do anything that a programmer could think of using such restrictions:
> 
>  https://utxos.org/uses/
> 
> https://rubin.io/archive/

Again, what I said was "compelling use-cases _clearly_ beneficial to _all_
users", not just a small subset. I neither think the use-cases in those links
are clearly compelling in the current form, and they of course, don't benefit
all users. Indeed, the Drivechains use-case arguably *harms* all users, as
Drivechains is arguably harmful to the security of Bitcoin as a whole.
Similarly, the various new uses for on-chain transactions mentioned as a
use-case arguably harms all existing users by competing for scarce blockchain
space - note how ETH has quite high on chain fees for basic transactions,
because there are so many use-cases where the per-tx value can afford much
higher fees. That kind of expansion of use-case also arguably harms Bitcoin as
a whole by providing more fuel for a future contentious blocksize debate.

Bitcoin is an almost $1 trillion dollar system. We have to very carefully weigh
the benefits of making core consensus changes to that system against the risks.
Both for each proposal in isolation, as well as the precedent making that
change sets.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`

[ZmnSCPxj via bitcoin-dev]

Good morning ariard,


> > A statechain is really just a CoinPool hosted inside a
> >  Decker-Wattenhofer or Decker-Russell-Osuntokun construction.
>
> Note, to the best of my knowledge, how to use LN-Penalty in the context of 
> multi-party construction is still an unsolved issue. If an invalidated state 
> is published on-chain, how do you guarantee that the punished output value is 
> distributed "fairly" among the "honest" set of users ? At least
> where fairness is defined as a reasonable proportion of the balances they 
> owned in the latest state.

LN-Penalty I believe is what I call Poon-Dryja?

Both Decker-Wattenhofer (has no common colloquial name) and 
Decker-Russell-Osuntokun ("eltoo") are safe with N > 2.
The former has bad locktime tradeoffs in the unilateral close case, and the 
latter requires `SIGHASH_NOINPUT`/`SIGHASH_ANYPREVOUT`.


> > In principle, a set of promised outputs, if the owners of those
> > outputs are peers, does not have *any* inherent order.
> > Thus, I started to think about a commitment scheme that does not
> > impose any ordering during commitment.
>
> I think we should dissociate a) *outputs publication ordering* from the b) 
> *spends paths ordering* itself. Even if to each spend path a output 
> publication is attached, the ordering constraint might not present the same 
> complexity.
>
> Under this distinction, are you sure that TLUV imposes an ordering on the 
> output publication ?

Yes, because TLUV is based on tapleaf revelation.
Each participant gets its own unique tapleaf that lets that participant get 
evicted.

In Taproot, the recommendation is to sort the hashes of each tapleaf before 
arranging them into a MAST that the Taproot address then commits to.
This sort-by-hash *is* the arbitrary ordering I refer to when I say that TLUV 
imposes an arbitrary ordering.
(actually the only requirement is that pairs of scripts are sorted-by-hash, but 
it is just easier to sort the whole array by hash.)

To reveal a single participant in a TLUV-based CoinPool, you need to reveal 
O(log N) hashes.
It is the O(log N) space consumption I want to avoid with `OP_EVICT`, and I 
believe the reason for that O(log N) revelation is due precisely to the 
arbitrary but necessary ordering.

> > With `OP_TLUV`, however, it is possible to create an "N-of-N With
> > Eviction" construction.
> > When a participant in the N-of-N is offline, but the remaining
> > participants want to advance the state of the construction, they
> > instead evict the offline participant, creating a smaller N-of-N
> > where *all* participants are online, and continue operating.
>
> I think we should dissociate two types of pool spends : a) eviction by the 
> pool unanimity in case of irresponsive participants and b) unilateral 
> withdrawal by a participant because of the liquidity allocation policy. I 
> think the distinction is worthy, as the pool participant should be stable and 
> the eviction not abused.
>
> I'm not sure if TLUV enables b), at least without transforming the unilateral 
> withdrawal into an eviction. To ensure the TLUV operation is correct  (spent 
> leaf is removed, withdrawing participant point removed, etc), the script 
> content must be inspected by *all* the participant. However, I believe
> knowledge of this content effectively allows you to play it out against the 
> pool at any time ? It's likely solvable at the price of a CHECKSIG.

Indeed, that distinction is important.
`OP_TLUV` (and `OP_EVICT`, which is just a redesigned `OP_TLUV`) supports (a) 
but not (b).

> `OP_EVICT`
> --
>
> >  * If it is `1` that simply means "use the Taproot internal
> >    pubkey", as is usual for `OP_CHECKSIG`.
>
> IIUC, this assumes the deployment of BIP118, where if the  public key is a 
> single byte 0x01, the internal pubkey is used
> for verification.

I thought it was part of Taproot?

>
> >  * Output indices must not be duplicated, and indicated
> >    outputs must be SegWit v1 ("Taproot") outputs.
>
> I think public key duplication must not be verified. If a duplicated public 
> key is present, the point is subtracted twice from the internal pubkey and 
> therefore the aggregated
> key remains unknown ? So it sounds to me safe against replay attacks.

Ah, right.

> >  * The public key is the input point (i.e. stack top)
> >    **MINUS** all the public keys of the indicated outputs.
>
> Can you prevent eviction abuse where one counterparty threatens to evict 
> everyone as all the output signatures are known among participants and free 
> to sum ? (at least not considering fees)

No, I considered onchain fees as the only mechanism to avoid eviction abuse.
The individual-evict signatures commit to fixed quantities.
The remaining change is then the only fund that can pay for onchain fees, so a 
single party evicting everyone else has to pay for the eviction of everyone 
else.


> > Suppose however that B is offline.
> > Then A, C, and D then decide to evict B.
> > To do so, they create 

[bitcoin-dev] Sponsor transaction engineering, was Re: Thoughts on fee bumping

[David A. Harding via bitcoin-dev]

On Tue, Feb 15, 2022 at 01:37:43PM -0800, Jeremy Rubin via bitcoin-dev wrote:
> Unfortunately, there are technical reasons for sponsors to not be monotone.
> Mostly that it requires the maintenance of an additional permanent
> TX-Index

Alternatively, you could allow a miner to include a sponsor transaction
in a later block than the sponsored transaction by providing an (SPV)
merkle inclusion proof that the sponsored transaction was a part of a
previous block on the same chain.[1]

This does raise the vbyte cost of including sponsor and sponsored
transactions in different blocks compared to including them both in the
same block, but I wonder if it mitigates the validity concern raised by
Suhas Daftuar in the previous sponsor transaction thread.

-Dave

[1] Bitcoin Core stores the complete headers chain, so it already has
the information necessary to validate such a proof (and the
`verifytxoutproof` RPC already does this).  Utreexo-style nodes might
not store old headers to save space, but I presume they could store a
merkle-like commitment to all headers they previously validated and then
have utreexo proofs include the necessary headers and intermediate
hashes necessary to validate subsequent-block sponsor transactions.


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`

[Antoine Riard via bitcoin-dev]

Hi Zeeman,

> After some thinking, I realized that it was the use of the
> Merkle tree to represent the promised-but-offchain outputs of
> the CoinPool that lead to the O(log N) space usage.
> I then started thinking of alternative representations of
> sets of promised outputs, which would not require O(log N)
> revelations by avoiding the tree structure.

In the context of payment pools, I think the O(log N) revelations can be
avoided already today by pre-signing all the combinations of
promised-but-offchain outputs publications order. However, this approach
presents a factorial complexity and appears as an intractable problem for
high-number of pool users.

I think this factorial complexity issue is the primary problem to enable
scalable payment pools. This issue appears to be solvable by introducing an
accumulator at the script interpreter level. IMO, the efficiency of the
accumulated set representations comes as a second-order issue.

In the comparison of different covenant primitives, I believe we should ask
first if the flexibility offered is enough to solve the factorial
complexity. I would say performance trade-offs analysis can only be
conducted in logically equivalent primitives.

> A statechain is really just a CoinPool hosted inside a
>  Decker-Wattenhofer or Decker-Russell-Osuntokun construction.

Note, to the best of my knowledge, how to use LN-Penalty in the context of
multi-party construction is still an unsolved issue. If an invalidated
state is published on-chain, how do you guarantee that the punished output
value is distributed "fairly" among the "honest" set of users ? At least
where fairness is defined as a reasonable proportion of the balances they
owned in the latest state.

> (To Bitcoin Cashers: this is not an IOU, this is *committed* and
> can be enforced onchain, that is enough to threaten your offchain
> counterparties into behaving correctly.
> They cannot gain anything by denying the outputs they promised,
> you can always drop it onchain and have it enforced, thus it is
> not just merely an IOU, as IOUs are not necessarily enforceable,
> but this mechanism *would* be.
> Blockchain as judge+jury+executioner, not noisy marketplace.)

To be fair towards the Bitcoin Cashers, I think there are still limitations
of LN, we have not solved yet. Especially, w.r.t to mass exits from the
off-chain layers to the chain, where the blocks would stay fulfilled longer
than the standard HTLC timelocks, at  a fee price point that the average
user can't buy... I'm not sure if we have outlawed the "bank runs" scenario
yet of LN.

I would say yes the Blockchain is a juge authority, but in the worst-case
we might be all in market competition to get enforcement.

> In principle, a set of promised outputs, if the owners of those
> outputs are peers, does not have *any* inherent order.
> Thus, I started to think about a commitment scheme that does not
> impose any ordering during commitment.

I think we should dissociate a) *outputs publication ordering* from the b)
*spends paths ordering* itself. Even if to each spend path a output
publication is attached, the ordering constraint might not present the same
complexity.

Under this distinction, are you sure that TLUV imposes an ordering on the
output publication ?

> With `OP_TLUV`, however, it is possible to create an "N-of-N With
> Eviction" construction.
> When a participant in the N-of-N is offline, but the remaining
> participants want to advance the state of the construction, they
> instead evict the offline participant, creating a smaller N-of-N
> where *all* participants are online, and continue operating.

I think we should dissociate two types of pool spends : a) eviction by the
pool unanimity in case of irresponsive participants and b) unilateral
withdrawal by a participant because of the liquidity allocation policy. I
think the distinction is worthy, as the pool participant should be stable
and the eviction not abused.

I'm not sure if TLUV enables b), at least without transforming the
unilateral withdrawal into an eviction. To ensure the TLUV operation is
correct  (spent leaf is removed, withdrawing participant point removed,
etc), the script content must be inspected by *all* the participant.
However, I believe
knowledge of this content effectively allows you to play it out against the
pool at any time ? It's likely solvable at the price of a CHECKSIG.

`OP_EVICT`
--

>  * If it is `1` that simply means "use the Taproot internal
>pubkey", as is usual for `OP_CHECKSIG`.

IIUC, this assumes the deployment of BIP118, where if the  public key is a
single byte 0x01, the internal pubkey is used
for verification.

>  * Output indices must not be duplicated, and indicated
>outputs must be SegWit v1 ("Taproot") outputs.

I think public key duplication must not be verified. If a duplicated public
key is present, the point is subtracted twice from the internal pubkey and
therefore the aggregated
key remains unknown ? So it sounds 

Re: [bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`

[ZmnSCPxj via bitcoin-dev]

Good morning Erik,

> > As I understand your counterproposal, it would require publishing one 
> > transaction per evicted participant.
>
> if you also pre-sign (N-2, N-3, etc), you can avoid this

It also increases the combinatorial explosion.

> > In addition, each participant has to store `N!` possible orderings in which 
> > participants can be evicted, as you cannot predict the future and cannot 
> > predict which partiicpants will go offline first.
>
> why would the ordering matter?  these are unordered pre commitments to move 
> funds, right?   you agree post the one that represents "everyone that's 
> offline"

Suppose `B` is offline first, then the remaining `A` `C` and `D` publish the 
eviction transaction that evicts only `B`.
What happens if `C` then goes offline?
We need to prepare for that case (and other cases where the participants go 
offline at arbitrary orders) and pre-sign a spend from the `ACD` set and evicts 
`C` as well, increasing combinatorial explosion.
And so on.

We *could* use multiple Tapleaves, of the form ` OP_CHECKSIG  
OP_CHECKSIG` for each participant.
Then the per-participant `` signature is signed with 
`SIGHASH_SINGLE|SIGHASH_ANYONECANPAY` and is pre-signed, while the remainder is 
signed by `` with default `SIGHASH_ALL`.
Then if one participant `B` is offline they can evict `B` and then the change 
is put into a new UTXO with a similar pre-signed scheme ` OP_CHECKSIG  
OP_CHECKSIG`.
This technique precludes pre-signing multiple evictions.

>
> > But yes, certainly that can work, just as pre-signed transactions can be 
> > used instead of `OP_CTV` 
>
> i don't see how multiple users can securely share a channel (allowing massive 
> additional scaling with lighting) without op_ctv

They can, they just pre-sign, like you pointed out.
The same technique works --- `OP_CTV` just avoids having ridiculous amounts of 
combinatorial explosion and just requires `O(log n)` per eviction.
Remember, this proposal can be used for channel factories just as well, as 
pointed out, so any objection to this proposal also applies to `OP_CTV`.



Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`

[Erik Aronesty via bitcoin-dev]

> As I understand your counterproposal, it would require publishing one
transaction per evicted participant.

if you also pre-sign (N-2, N-3, etc), you can avoid this

> In addition, each participant has to store `N!` possible orderings in
which participants can be evicted, as you cannot predict the future and
cannot predict which partiicpants will go offline first.

why would the ordering matter?  these are unordered pre commitments to move
funds, right?   you agree post the one that represents "everyone that's
offline"

> But yes, certainly that can work, just as pre-signed transactions can be
used instead of `OP_CTV`

i don't see how multiple users can securely share a channel (allowing
massive additional scaling with lighting) without op_ctv


On Fri, Feb 18, 2022 at 9:48 AM ZmnSCPxj  wrote:

> Good morning Erik,
>
> > hey, i read that whole thing, but i'm confused as to why it's necessary
> >
> > seems like N of N participants can pre-sign an on-chain transfer of
> funds for each participant to a new address that consists of (N-1) or (N-1)
> participants, of which each portion of the signature is encrypted for the
> same (N-1) participants
> >
> > then any (N-1) subset of participants can collude publish that
> transaction at any time to remove any other member from the pool
> >
> > all of the set up  (dkg for N-1), and transfer (encryption of partial
> sigs) is done offchain, and online with the participants that are online
>
>
> As I understand your counterproposal, it would require publishing one
> transaction per evicted participant.
> In addition, each participant has to store `N!` possible orderings in
> which participants can be evicted, as you cannot predict the future and
> cannot predict which partiicpants will go offline first.
>
> Finally, please see also the other thread on lightning-dev:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003479.html
> In this thread, I point out that if we ever use channel factories, it
> would be best if we treat each channel as a 2-of-2 that participates in an
> overall N-of-N (i.e. the N in the outer channel factory is composed of
> 2-of-2).
> For example, instead of the channel factory being signed by participants
> `A`, `B`, `C`, `D`, instead the channel factory is signed by `AB`, `AC`,
> `AD`, `BC`, `BD`, `CD`, so that if e.g. participant B needs to be evicted,
> we can evict the signers `AB`, `BC`, and `BD`.
> This means that for the channel factory case, already the number of
> "participants" is quadratic on the number of *actual* participants, which
> greatly increases the number of transactions that need to be evicted in
> one-eviction-at-a-time schemes (which is how I understand your proposal) as
> well as increasing the `N!` number of signatures that need to be exchanged
> during setup.
>
>
> But yes, certainly that can work, just as pre-signed transactions can be
> used instead of `OP_CTV` or pretty much any non-`OP_CHECKMULTISIG` opcode,
> xref Smart Contracts Unchained.
>
> Regards,
> ZmnSCPxj
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`

[ZmnSCPxj via bitcoin-dev]

Good morning Erik,

> hey, i read that whole thing, but i'm confused as to why it's necessary
>
> seems like N of N participants can pre-sign an on-chain transfer of funds for 
> each participant to a new address that consists of (N-1) or (N-1) 
> participants, of which each portion of the signature is encrypted for the 
> same (N-1) participants
>
> then any (N-1) subset of participants can collude publish that transaction at 
> any time to remove any other member from the pool
>
> all of the set up  (dkg for N-1), and transfer (encryption of partial sigs) 
> is done offchain, and online with the participants that are online


As I understand your counterproposal, it would require publishing one 
transaction per evicted participant.
In addition, each participant has to store `N!` possible orderings in which 
participants can be evicted, as you cannot predict the future and cannot 
predict which partiicpants will go offline first.

Finally, please see also the other thread on lightning-dev: 
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003479.html
In this thread, I point out that if we ever use channel factories, it would be 
best if we treat each channel as a 2-of-2 that participates in an overall 
N-of-N (i.e. the N in the outer channel factory is composed of 2-of-2).
For example, instead of the channel factory being signed by participants `A`, 
`B`, `C`, `D`, instead the channel factory is signed by `AB`, `AC`, `AD`, `BC`, 
`BD`, `CD`, so that if e.g. participant B needs to be evicted, we can evict the 
signers `AB`, `BC`, and `BD`.
This means that for the channel factory case, already the number of 
"participants" is quadratic on the number of *actual* participants, which 
greatly increases the number of transactions that need to be evicted in 
one-eviction-at-a-time schemes (which is how I understand your proposal) as 
well as increasing the `N!` number of signatures that need to be exchanged 
during setup.


But yes, certainly that can work, just as pre-signed transactions can be used 
instead of `OP_CTV` or pretty much any non-`OP_CHECKMULTISIG` opcode, xref 
Smart Contracts Unchained.

Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`

[Erik Aronesty via bitcoin-dev]

hey, i read that whole thing, but i'm confused as to why it's necessary

seems like N of N participants can pre-sign an on-chain transfer of funds
for each participant to a new address that consists of (N-1) or (N-1)
participants, of which each portion of the signature is encrypted for the
same (N-1) participants

then any (N-1) subset of participants can collude publish that transaction
at any time to remove any other member from the pool

all of the set up  (dkg for N-1), and transfer (encryption of partial sigs)
is done offchain, and online with the participants that are online



On Thu, Feb 17, 2022 at 9:45 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`
> ==
>
> In late 2021, `aj` proposed `OP_TAPLEAFUPDATEVERIFY` in order to
> implement CoinPools and similar constructions.
>
> `Jeremy` observed that due to the use of Merkle tree paths, an
> `OP_TLUV` would require O(log N) hash revelations in order to
> reach a particular tapleaf, which, in the case of a CoinPool,
> would then delete itself after spending only a particular amount
> of funds.
> He then observed that `OP_CTV` trees also require a similar
> revelation of O(log N) transactions, but with the advantage that
> once revealed, the transactions can then be reused, thus overall
> the expectation is that the number of total bytes onchain is
> lesser compared to `OP_TLUV`.
>
> After some thinking, I realized that it was the use of the
> Merkle tree to represent the promised-but-offchain outputs of
> the CoinPool that lead to the O(log N) space usage.
> I then started thinking of alternative representations of
> sets of promised outputs, which would not require O(log N)
> revelations by avoiding the tree structure.
>
> Promised Outputs
> 
>
> Fundamentally, we can consider that a solution for scaling
> Bitcoin would be to *promise* that some output *can* appear
> onchain at some point in the future, without requiring that the
> output be shown onchain *right now*.
> Then, we can perform transactional cut-through on spends of the
> promised outputs, without requiring onchain activity ("offchain").
> Only if something Really Bad (TM) happens do we need to actually
> drop the latest set of promised outputs onchain, where it has to
> be verified globally by all fullnodes (and would thus incur scaling
> and privacy costs).
>
> As an example of the above paradigm, consider the Lightning
> Network.
> Outputs representing the money of each party in a channel are
> promised, and *can* appear onchain (via the unilateral close
> mechanism).
> In the meantime, there is a mechanism for performing cut-through,
> allowing transfers between channel participants; any number of
> transactions can be performed that are only "solidified" later,
> without expensive onchain activity.
>
> Thus:
>
> * A CoinPool is really a way to commit to promised outputs.
>   To change the distribution of those promised outputs, the
>   CoinPool operators need to post an onchain transaction, but
>   that is only a 1-input-1-output transaction, and with Schnorr
>   signatures the single input requires only a single signature.
>   But in case something Really Bad (TM) happens, any participant
>   can unilaterally close the CoinPool, instantiating the promised
>   outputs.
> * A statechain is really just a CoinPool hosted inside a
>   Decker-Wattenhofer or Decker-Russell-Osuntokun construction.
>   This allows changing the distribution of those promised outputs
>   without using an onchain transaction --- instead, a new state
>   in the Decker-Wattenhofer/Decker-Russell-Osuntokun construction
>   is created containing the new state, which invalidates all older
>   states.
>   Again, any participant can unilaterally shut it down, exposing
>   the state of the inner CoinPool.
> * A channel factory is really just a statechain where the
>   promised outputs are not simple 1-of-1 single-owner outputs,
>   but are rather 2-of-2 channels.
>   This allows graceful degradation, where even if the statechain
>   ("factory") layer has missing participants, individual 2-of-2
>   channels can still continue operating as long as they do not
>   involve missing participants, without requiring all participants
>   to be online for large numbers of transactions.
>
> We can then consider that the base CoinPool usage should be enough,
> as other mechanisms (`OP_CTV`+`OP_CSFS`, `SIGHASH_NOINPUT`) can be
> used to implement statechains and channels and channel factories.
>
> I therefore conclude that what we really need is "just" a way to
> commit ourselves to exposing a set of promised outputs, with the
> proviso that if we all agree, we can change that set (without
> requiring that the current or next set be exposed, for both
> scaling and privacy).
>
> (To Bitcoin Cashers: this is not an IOU, this is *committed* and
> can be enforced onchain, that is 

Re: [bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`

[Jonas Nick via bitcoin-dev]

On the topic of half aggregation, Chalkias et al. gave a convincing security
proof last year:
https://eprint.iacr.org/2021/350

As an aside, half aggregation is not exactly the scheme in the OP because that
one is insecure. This does not affect Zmn's conclusion and was already
pointed out in the original half aggregation thread:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014306.html

It is required that each of the "s"-values are multiplied with a different
unpredictable value, for example like this:
https://github.com/ElementsProject/cross-input-aggregation/blob/master/slides/2021-Q2-halfagg-impl.org#schnorr-signature-half-aggregation-1
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CTV Signet Parameters

[0x0ff via bitcoin-dev]

Good day,

I've setup the explorer for CTV Signet which is now up and running at 
[https://explorer.ctvsignet.com](https://explorer.ctvsignet.com/)

Best,
[@0x0ff](https://twitter.com/0x0ff_)

--- Original Message ---
On Thursday, February 17th, 2022 at 9:58 PM, Jeremy Rubin via bitcoin-dev 
 wrote:

> Hi devs,
>
> I have been running a CTV signet for around a year and it's seen little use. 
> Early on I had some issues syncing new nodes, but I have verified syncability 
> to this signet using 
> https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify-signet-23.0-alpha.
>  Please use this signet!
>
> ```
> [signet]
> signetchallenge=512102946e8ba8eca597194e7ed90377d9bbebc5d17a9609ab3e35e706612ee882759351ae
> addnode=50.18.75.225
> ```
>
> This should be operational. Let me know if there are any issues you 
> experience (likely with signet itself, but CTV too).
>
> Feel free to also email me an address and I can send you some signet coins -- 
> if anyone is interested in running an automatic faucet I would love help with 
> that and will send you a lot of coins.
>
> 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. Maybe that
>> means we should tentatively merge the feature and deploy it on the
>> default global signet though? Not really sure how best to get more
>> real world testing; but "deploy first, test later" doesn't sit right.
>
> I agree that real experimentation would be great, and think that merging the 
> code (w/o activation) for signet would likely help users v.s. custom 
> builds/parameters.
>
> I am unsure that "learning in public" is required -- personally I do 
> experiments on regtest regularly and on mainnet (using emulators) more 
> occasionally. I think some of the difficulty is that for setting up signet 
> stuff you need to wait e.g. 10 minutes for blocks and stuff, source faucet 
> coins, etc. V.s. regtest you can make tests that run automatically. Maybe 
> seeing more regtest RPC test samples for regtests would be a sufficient 
> in-between?
>
> Best,
>
> Jeremy
>
> --
> [@JeremyRubin](https://twitter.com/JeremyRubin)___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Thoughts on fee bumping

[darosior via bitcoin-dev]

James,

You seem to imply that the scenario described isn't prevented today. It is. The 
mempool acceptance for a replacement not only
depend on the transaction feerate but also the transaction fee [0]. That's why 
i raised it in the first place...

Antoine

[0] 
https://github.com/bitcoin/bitcoin/blob/66636ca438cb65fb18bcaa4540856cef0cee2029/src/validation.cpp#L944-L947

Of course if you are evicting transactions then you don't have the issue i 
mentioned, so it's fine doing so.
 Original Message 
On Feb 17, 2022, 19:18, James O'Beirne < james.obei...@gmail.com> wrote:

>> Is it really true that miners do/should care about that?
>
> De facto, any miner running an unmodified version of bitcoind doesn't
> care about anything aside from ancestor fee rate, given that the
> BlockAssembler as-written orders transactions for inclusion by
> descending ancestor fee-rate and then greedily adds them to the block
> template. [0]
>
> If anyone has any indication that there are miners running forks of
> bitcoind that change this behavior, I'd be curious to know it.
>
> Along the lines of what AJ wrote, optimal transaction selection is
> NP-hard (knapsack problem). Any time that a miner spends deciding how
> to assemble the next block is time not spent grinding on the nonce, and
> so I'm skeptical that miners in practice are currently doing anything
> that isn't fast and simple like the default implementation: sorting
> fee-rate in descending order and then greedily packing.
>
> But it would be interesting to hear evidence to the contrary.
>
> ---
>
> You can make the argument that transaction selection is just a function
> of mempool contents, and so mempool maintenance criteria might be the
> thing to look at. Mempool acceptance is gated based on a minimum
> feerate[1]. Mempool eviction (when running low on space) happens on
> the basis of max(self_feerate, descendant_feerate) [2]. So even in the
> mempool we're still talking in terms of fee rates, not absolute fees.
>
> That presents us with the "is/ought" problem: just because the mempool
> *is* currently gating only on fee rate doesn't mean that's optimal. But
> if the whole point of the mempool is to hold transactions that will be
> mined, and if there's good reason that txns are chosen for mining based
> on fee rate (it's quick and good enough), then it seems like fee rate
> is the approximation that should ultimately prevail for txn
> replacement.
>
> [0]:
> https://github.com/bitcoin/bitcoin/blob/master/src/node/miner.cpp#L310-L320
> [1]:
> https://github.com/bitcoin/bitcoin/blob/master/src/txmempool.cpp#L1106
> [2]:
> https://github.com/bitcoin/bitcoin/blob/master/src/txmempool.cpp#L1138-L1144___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Thoughts on fee bumping

[Prayank via bitcoin-dev]

> If anyone has any indication that there are miners running forks of bitcoind 
> that change this behavior, I'd be curious to know it.
It is possible because some mining pools use bitcoind with custom patches. 

Example: https://twitter.com/0xB10C/status/1461392912600776707 (f2pool)

-- 
Prayank

A3B1 E430 2298 178F
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Thoughts on fee bumping

[Prayank via bitcoin-dev]

> I suspect the "economically rational" choice would be to happily trade off 
> that immediate loss against even a small chance of a simpler policy 
> encouraging higher adoption of bitcoin, _or_ a small chance of more on-chain 
> activity due to higher adoption of bitcoin protocols like lightning and thus 
> a lower chance of an empty mempool in future.

Is this another way of saying a few developers will decide RBF policy for 
miners and they should follow it because it is the only way bitcoin gets more 
adoption? On-chain activity is dependent on lot of things. I suspect any change 
in policy will change it any time soon and miners should have the freedom to 
decide things that aren't consensus rules.

Lightning network contributes to on-chain activity only with opening and 
closing of channels. Based on the chart I see in the below link for channels 
opened/closed per block, its contribution is less than 1% in fees:

https://txstats.com/dashboard/db/lightning-network?orgId=1=now-6M=now

-- 
Prayank

A3B1 E430 2298 178F
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Thoughts on fee bumping

[Antoine Riard via bitcoin-dev]

While I roughly agree with the thesis that different replacement policies
offer marginal block reward gains _in the current state_ of the ecosystem,
I would be more conservative about extending the conclusions to the
medium/long-term future.

> I suspect the "economically rational" choice would be to happily trade
> off that immediate loss against even a small chance of a simpler policy
> encouraging higher adoption of bitcoin, _or_ a small chance of more
> on-chain activity due to higher adoption of bitcoin protocols like
> lightning and thus a lower chance of an empty mempool in future.

This is making the assumption that the economic interests of the different
class of actors in the Bitcoin ecosystem are not only well-understood but
also aligned. We have seen in the past mining actors behaviors delaying the
adoption of protocol upgrades which were expected to encourage higher
adoption of Bitcoin. Further, if miners likely have an incentive to see an
increase of on-chain activity, there is also the possibility that lightning
will be so throughput-efficient to drain mempools backlog, to a point where
the block demand is not high enough to pay back the cost of mining hardware
and operational infrastructure. Or at least not matching the return on
mining investments expectations.

Of course, it could be argued that as a utxo-sharing protocol like
lightning just compresses the number of payments per block space unit, it
lowers the fees burden, thus making Bitcoin as a payment system far more
attractive for a wider population of users. In fine increasing the block
space demand and satisfying the miners.

In the state of today's knowledge, this hypothesis sounds the most
plausible. Though, I would say it's better to be cautious until we
understand better the interactions between the different layers of the
Bitcoin ecosystem ?

> Certainly those percentages can be expected to double every four years as
> the block reward halves (assuming we don't also reduce the min relay fee
> and block min tx fee), but I think for both miners and network stability,
> it'd be better to have the mempool backlog increase over time, which
> would both mean there's no/less need to worry about the special case of
> the mempool being empty, and give a better incentive for people to pay
> higher fees for quicker confirmations.

Intuitively, if we assume that liquidity isn't free on lightning [0], there
should be a subjective equilibrium where it's cheaper to open new channels
to reduce one's own graph traversal instead of paying too high routing fees.

As the core of the network should start to be more busy, I think we should
see more LN actors doing that kind of arbitrage, guaranteeing in the
long-term mempools backlog.

> If you really want to do that
> optimally, I think you have to have a mempool that retains conflicting
> txs and runs a dynamic programming solution to pick the best set, rather
> than today's simple greedy algorithms both for building the block and
> populating the mempool?

As of today, I think power efficiency of mining chips and access to
affordable sources of energy are more significant factors of the
rentability of mining operations rather than optimality of block
construction/replacement policy. IMO, making the argument that small deltas
in block reward gains aren't that much relevant.

That said, the former factors might become a commodity, and the latter one
become a competitive advantage. It could incentivize the development of
such greedy algorithms, potentially in a covert way as we have seen with
AsicBoost ?

> Is there a plausible example where the difference isn't that marginal?

The paradigm might change in the future. If we see the deployment of
channel factories/payment pools, we might have users competing to spend a
shared-utxo with different liquidity needs and thus ready to overbid. Lack
of a "conflict pool" logic might make you lose income.

> Always accepting (package/descendent) fee rate increases removes the
possibility of pinning entirely, I think

I think the pinnings we're affected with today are due to the ability of a
malicious counterparty to halt the on-chain resolution of the channel. The
presence of a  pinning commitment transaction with low-chance of
confirmation (abuse of BIP125 rule 3)
prevents the honest counterparty to fee-bump her own version of the
commitment, thus redeeming a HTLC before timelock expiration. As long as
one commitment confirms, independently of who issued it, the pinning is
over. I think moving to replace-by-feerate allows the honest counterparty
to fee-bump her commitment, thus offering a compelling block space demand,
or forces the malicious counterparty to enter in a fee race.


To gather my thinking on the subject, the replace-by-feerate policy could
produce lower fees blocks in the presence of today's environment of
empty/low-fulfilled blocks. That said, the delta sounds marginal enough
w.r.t other factors of mining business units
to not be worried (or