Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Paul Sztorc via bitcoin-dev]

On 3/4/2022 7:35 AM, Billy Tetrud wrote:

sidechains cannot exist without their mainchain ...


A sidechain could stop supporting deposits from or withdrawals to 
bitcoin and completely break any relationship with the main chain.

I agree this is not as sure of a thing as starting with an altcoin
(which of course never has that kind of relationship with bitcoin).
So I do think there are some merits to sidechains in your scenario.
However, I don't think its quite accurate to say it completely
solves the problem (of a less-secure altcoin becoming dominant).



It is hard to see how this "sidechain cuts off the mainchain" scenario 
could plausibly be in enough people's interest:


* Miners would lose the block subsidy (ie, the 6.25 BTC, or whatever of 
it that still remains), and txn fees from the mainchain and all other 
merged mined chains.
* Developers would lose the ability to create a dissenting new piece of 
software (and would instead be forced into a permanent USSR-style "one 
party system" intellectual monoculture).
* Users would lose --permanently-- the ability to take their coins to 
new blockchains, removing almost all of their leverage.


Furthermore, because sidechains cannot exist without their parent (but 
not vice-versa), we can expect a large permanent interest in keeping 
mainchain node costs low. Aka: very small mainchain blocks forever. So, 
the shut-it-down mainchain-haters, would have to meet the question "why 
not just leave things the way they are?". And the cheaper the 
mainchain-nodes are, the harder that question is to answer.


However, if a sidechain really were so overwhelmingly popular as to 
clear all of these hurdles, then I would first want to understand why it 
is so popular. Maybe it is a good thing and we should cheer it on.



Your anecdote about not running a full node is amusing, and I've often 
found myself in that position. I certainly agree different people are 
different and so different trade offs can be better for different 
people. However, the question is: what tradeoffs does a largeblock 
sidechain do better than both eg Visa and lightning?


Yes, that's true. There are very many tradeoffs in general:

1. Onboarding
2. Route Capacity / Payment Limits
3. Failed Payments
4. Speed of Payment
5. Receive while offline / need for interaction/monitoring/watchtowers
6. Micropayments
7. Types of fees charged, and for what
8. Contribution to layer1 security budget
9. Auditability (re: large organizations) / general complexity

LN is certainly better for 4 and 6. But everything else is probably up 
for grabs. And this is not intended to be an exhaustive list. I just 
made it up now.


(And, if the layer2 is harmless, then its existence can be justified via 
one single net benefit, for some users, somewhere on the tradeoff-list.)


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

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[vjudeu via bitcoin-dev]

> The Taproot address itself has to take up 32 bytes onchain, so this saves 
> nothing.

There is always at least one address, because you have a coinbase transaction 
and a solo miner or mining pool that is getting the whole reward. So, instead 
of using separate OP_RETURN's for each sidechain, for each federation, and for 
every "commitment to the blockchain", all we need is just tweaking that miner's 
key and placing everything inside unused TapScript. Then, we don't need 
separate 32 bytes for this and separate 32 bytes for that, we only need a 
commitment and a MAST-based path that can link such commitment to the address 
of this miner.

So, instead of having:




...


We could have:



On 2022-03-04 09:42:23 user ZmnSCPxj  wrote:
> Good morning vjudeu,

> > Continuous operation of the sidechain then implies a constant stream of 
> > 32-byte commitments, whereas continuous operation of a channel factory, in 
> > the absence of membership set changes, has 0 bytes per block being 
> > published.
>
> The sidechain can push zero bytes on-chain, just by placing a sidechain hash 
> in OP_RETURN inside TapScript. Then, every sidechain node can check that 
> "this sidechain hash is connected with this Taproot address", without pushing 
> 32 bytes on-chain.

The Taproot address itself has to take up 32 bytes onchain, so this saves 
nothing.

Regards,
ZmnSCPxj

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

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Billy Tetrud via bitcoin-dev]

> "these sidechains are terrible" on Monday and then "these sidechains are
so good they will replace the mainchain" on Tuesday

Your premise is that a sidechain might come to dominate bitcoin, and that
this would be better than an altcoin dominating bitcoin. Did I
misunderstand you? Not quite sure why you're balking at me simply
confirming your premise.

> sidechains cannot exist without their mainchain .. imagine .. a zcash
sidechain, and someone claims they deposited 1000 BTC

A sidechain could stop supporting deposits from or withdrawals to bitcoin
and completely break any relationship with the main chain. I agree this is
not as sure of a thing as starting with an altcoin (which of course never
has that kind of relationship with bitcoin). So I do think there are some
merits to sidechains in your scenario. However, I don't think its quite
accurate to say it completely solves the problem (of a less-secure altcoin
becoming dominant).

Your anecdote about not running a full node is amusing, and I've often
found myself in that position. I certainly agree different people are
different and so different trade offs can be better for different
people. However,
the question is: what tradeoffs does a largeblock sidechain do better than
both eg Visa and lightning?

>Wouldn't life be better, if we Bitcoiners could easily sweep those fiat 
>transactions into *some* part of the BTC universe? (For example, a family of 
>largeblock sidechains). To me the answer is clearly yes.

I guess its not as clear to me. We agree it wouldn't significantly burden
Bitcoin-only nodes, but not being a burden is not a sufficient reason to do
something, only reason to not prevent it. But what are the benefits to a
user of that chain? Slightly lower fees than main bitcoin? More
decentralization than Visa or Venmo? Doesn't lightning already do better on
both accounts?



On Tue, Mar 1, 2022 at 6:00 PM Paul Sztorc  wrote:

> On 3/1/2022 12:39 AM, Billy Tetrud wrote:
>
> This entire issue is avoided completely, if all the chains --decentralized 
> and centralized-- and in the same monetary unit. Then, the monetary network 
> effects never interfere, and the decentralized chain is always guaranteed to 
> exist.
>
> It sounds like what you're saying is that without side chains, everyone might 
> switch entirely to some altcoin and bitcoin will basically die. And at that 
> point, the insecurity of that coin people switched to can be heavily 
> exploited by some attacker(s). Is that right?
>
> Yes, precisely.
>
> Its an interesting thought experiment. However, it leads me to wonder: if a 
> sidechain gets so popular that it dominates the main chain, why would people 
> keep that main chain around at all?
>
> For some reason, this is a very popular question. I suppose if you believe in 
> "one size fits all" chain philosophy (see comment below), it makes sense to 
> say "these sidechains are terrible" on Monday and then "these sidechains are 
> so good they will replace the mainchain" on Tuesday.
>
> In any event, sidechains cannot exist without their mainchain (as I see it). 
> For example, imagine that you are on a zcash sidechain, and someone claims 
> they deposited 1000 BTC, from Bitcoin Core into this sidechain? Do you give 
> them 1000 z-BTC, or not? Without the mainchain,
> you can't tell.
>
> If you run the Bip300 DriveNet demo software (drivechain.info/releases), you 
> will see for yourself: the test-sidechains are absolutely inert, UNTIL they 
> have rpc access to the mainchain. (Exactly the same way that a LN node needs 
> a Bitcoin Core node.)
>
>
>
> > someone is actually in the wrong, if they proactively censor an experiment 
> > of any type. If a creator is willing to stand behind something, then it 
> > should be tried.
>
> > it makes no difference if users have their funds stolen from a centralized 
> > Solana contract or from a bip300 centralized bit-Solana sidechain. I don't 
> > see why the tears shed would be any different.
>
> I agree with you. My point was not that we should stop anyone from doing 
> this. My point was only that we shouldn't advocate for ideas we think aren't 
> good. You were advocating for a "largeblock sidechain", and unless you have 
> good reasons to think that is an idea likely to succeed and want to share 
> them with us, then you shouldn't be advocating for that. But certainly if 
> someone *does* think so and has their own reasons, I wouldn't want to censor 
> or stop them. But I wouldn't advocate for them to do it unless their ideas 
> were convincing to me, because I know enough to know the dangers of large 
> block blockchains.
>
> Yes, I strongly agree, that we should only advocate for ideas we believe in.
>
> I do not believe in naive layer1 largeblockerism. But I do believe in 
> sidechain largeblockism.
>
> Something funny once happened to me when I was on a Bitcoin conference 
> panel*. There were three people: myself, a Blockstream person, and an 
> (ex)BitPay person. The first two of 

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[ZmnSCPxj via bitcoin-dev]

Good morning vjudeu,

> > Continuous operation of the sidechain then implies a constant stream of 
> > 32-byte commitments, whereas continuous operation of a channel factory, in 
> > the absence of membership set changes, has 0 bytes per block being 
> > published.
>
> The sidechain can push zero bytes on-chain, just by placing a sidechain hash 
> in OP_RETURN inside TapScript. Then, every sidechain node can check that 
> "this sidechain hash is connected with this Taproot address", without pushing 
> 32 bytes on-chain.

The Taproot address itself has to take up 32 bytes onchain, so this saves 
nothing.

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

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Paul Sztorc via bitcoin-dev]

On 3/1/2022 12:39 AM, Billy Tetrud wrote:

This entire issue is avoided completely, if all the chains 
--decentralized and centralized-- and in the same monetary unit. 
Then, the monetary network effects never interfere, and the 
decentralized chain is always guaranteed to exist.
It sounds like what you're saying is that without side chains, 
everyone might switch entirely to some altcoin and bitcoin will 
basically die. And at that point, the insecurity of that coin people 
switched to can be heavily exploited by some attacker(s). Is that right?


Yes, precisely.


Its an interesting thought experiment. However, it leads me to wonder: 
if a sidechain gets so popular that it dominates the main chain, why 
would people keep that main chain around at all?


For some reason, this is a very popular question. I suppose if you believe in "one size fits all" 
chain philosophy (see comment below), it makes sense to say "these sidechains are terrible" on 
Monday and then "these sidechains are so good they will replace the mainchain" on Tuesday.

In any event, sidechains cannot exist without their mainchain (as I see it). 
For example, imagine that you are on a zcash sidechain, and someone claims they 
deposited 1000 BTC, from Bitcoin Core into this sidechain? Do you give them 
1000 z-BTC, or not? Without the mainchain,
you can't tell.

If you run the Bip300 DriveNet demo software (drivechain.info/releases), you 
will see for yourself: the test-sidechains are absolutely inert, UNTIL they 
have rpc access to the mainchain. (Exactly the same way that a LN node needs a 
Bitcoin Core node.)


> someone is actually in the wrong, if they proactively censor an 
experiment of any type. If a creator is willing to stand behind 
something, then it should be tried.
> it makes no difference if users have their funds stolen from a 
centralized Solana contract or from a bip300 centralized bit-Solana 
sidechain. I don't see why the tears shed would be any different.
I agree with you. My point was not that we should stop anyone from 
doing this. My point was only that we shouldn't advocate for ideas we 
think aren't good. You were advocating for a "largeblock sidechain", 
and unless you have good reasons to think that is an idea likely to 
succeed and want to share them with us, then you shouldn't be 
advocating for that. But certainly if someone *does* think so and has 
their own reasons, I wouldn't want to censor or stop them. But I 
wouldn't advocate for them to do it unless their ideas were convincing 
to me, because I know enough to know the dangers of large block 
blockchains.


Yes, I strongly agree, that we should only advocate for ideas we believe in.

I do not believe in naive layer1 largeblockerism. But I do believe in sidechain 
largeblockism.

Something funny once happened to me when I was on a Bitcoin conference panel*. 
There were three people: myself, a Blockstream person, and an (ex)BitPay 
person. The first two of us, were valiantly defending the small block position. 
I gave my usual speech: that node costs must remain low, so that people can run 
full nodes. The largeblocker mentioned that they ran many nodes (including BCH 
nodes etc) and didn't mind the cost, so I disclosed --in a good-natured way-- 
that I do not even run a BTC full node myself (out of choice). Thus, I was 
yammering about software I wasn't even running, I had no skin in the game! Lo 
and behold -- my Blockstream smallblocker ally-on-the-panel, immediately 
admitted to everyone that he did not run a full node either. The only 
node-runner was the largeblocker. The audience found this very amusing (as did 
I).

We smallblockers, justified our sinful nodeless behavior, as follows 
(paraphrasing): we receive BTC mainly from people that we know (and have a 
long-term relationship with); our receipts are not time sensitive; we are not 
paid in BTC that often; if payments turned out to be forged we would have 
enormous recourse against our counterparties; etc.

We did not run full nodes, because we did not need to draw on the blockchain's 
powers, **for those transactions**.

Which is my point: people are different, and transactions are different. I make 
many transactions today, with VISA or Venmo. These are not 
censorship-resistant, but somehow I survive the month, without bursting into 
flames.

Wouldn't life be better, if we Bitcoiners could easily sweep those fiat 
transactions into *some* part of the BTC universe? (For example, a family of 
largeblock sidechains). To me the answer is clearly yes.

Unlike layer1-largeblockism, no one running Bitcoin Core ever needs to see 
these 'btc' transactions (the same as we don't see them today, on account of 
them not existing at all); they do not burden Bitcoin Core full nodes. Hence 
why it seems like a good idea to me.

An SPV-wallet-of-a-largeblock-sidechain, is of course, a *disgrace* compared to a 
full-node-of-smallblock-mainchain-Bitcoin-Core. But, it is emphatically superior to Venmo 
/ VISA 

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Billy Tetrud via bitcoin-dev]

@Paul
> I believe that money has very strong network effects. ... users will
"clump up" and get "stuck".

I'm of the same opinion.

> This entire issue is avoided completely, if all the chains
--decentralized and centralized-- and in the same monetary unit. Then, the
monetary network effects never interfere, and the decentralized chain is
always guaranteed to exist.

It sounds like what you're saying is that without side chains, everyone
might switch entirely to some altcoin and bitcoin will basically die. And
at that point, the insecurity of that coin people switched to can be
heavily exploited by some attacker(s). Is that right? Its an interesting
thought experiment. However, it leads me to wonder: if a sidechain gets so
popular that it dominates the main chain, why would people keep that main
chain around at all? A sidechain could eject the main chain and all its
baggage if it got so big. So I don't think it can really be said that the
problem can be avoided "completely". But in any case, I see your line of
thinking.

> someone is actually in the wrong, if they proactively censor an
experiment of any type. If a creator is willing to stand behind something,
then it should be tried.
> it makes no difference if users have their funds stolen from a
centralized Solana contract or from a bip300 centralized bit-Solana
sidechain. I don't see why the tears shed would be any different.

I agree with you. My point was not that we should stop anyone from doing
this. My point was only that we shouldn't advocate for ideas we think
aren't good. You were advocating for a "largeblock sidechain", and unless
you have good reasons to think that is an idea likely to succeed and want
to share them with us, then you shouldn't be advocating for that. But
certainly if someone *does* think so and has their own reasons, I wouldn't
want to censor or stop them. But I wouldn't advocate for them to do it
unless their ideas were convincing to me, because I know enough to know the
dangers of large block blockchains.



On Mon, Feb 28, 2022 at 4:55 PM Paul Sztorc via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 2/28/2022 1:49 AM, ZmnSCPxj wrote:
>
> ...
>
> ...
>
> Perhaps, someone will invent a way, to LN-onboard WITHOUT needing new layer1 
> bytes.
>
> If so, a "rich man" could open a LN channel, and gradually transfer it to new 
> people.
>
> Such a technique would need to meet two requirements (or, so it seems to me):
> #1: The layer1 UTXO (that defines the channel) can never change (ie, the 
> 32-bytes which define the p2sh/tapscript/covenant/whatever, must stay 
> what-they-were when the channel was opened).
> #2: The new part-owners (who are getting coins from the rich man), will have 
> new pubkeys which are NOT known, until AFTER the channel is opened and 
> confirmed on the blockchain.
>
> Not sure how you would get both #1 and #2 at the same time. But I am not up 
> to date on the latest LN research.
>
> Yes, using channel factories.
>
> I think you may be wrong about this.
> ...
>
> I am not wrong about this.
>
> Well, let's take a closer look then.
>
> The topic was: "a way, to LN-onboard [a new pubkey] WITHOUT needing new 
> layer1 bytes".
>
> By which I meant, that I could generate a new pubkey right now, and add it to 
> the LN, without any onchain action.
>
> I can shorten and restate the two requirements (and reorder them) as:
> #2: Can later add a new public key to the membership set.
> #1: Without an onchain action.
>
> And yet you yourself say, very clearly:
>
>
> ... That is why I said changing the membership set requires onchain action.
>
> Which would seem to directly contradict what you say about channel
> factories. Unless you can show me how to add my new pubkey_4, to a 3-of-3
> channel factory opened last year. Without using an onchain action. You seem
> to want to instead change the subject. (To something like: 'we can do
> better the rate (32 bytes per 5 onboards), from your footnote'.) Which is
> fine. But it is not what I bought up.
>
> ***
>
> In general, you seem to have a future in mind, where new users onboard via 
> factory.
> For example, 50,000 new users want to onboard in the next block. These 
> strangers, spontaneously organize into 1000 factories of 55 people each, (50 
> newbies with zero coins + 5 wealthier BTCs who have lots of coins). They then 
> broadcast into the block and join Bitcoin.
> And this one factory provides them with many channels, so it can meet 
> most/all of their needs.
>
> I am not here to critique factories. I was simply observing that your logic 
> "sidechains don't scale, because you have to share your messages" is not 
> quite airtight, because in the case of onboarding the situation is reversed 
> and so supports the exact opposite conclusion.
> I believe I have made my point by now. It should be easy for people to see 
> what each of us has in mind, and the strengths and weaknesses.
>
> I am curious about something, though. Maybe you can help 

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Paul Sztorc via bitcoin-dev]

On 2/28/2022 1:49 AM, ZmnSCPxj wrote:


...

...

Perhaps, someone will invent a way, to LN-onboard WITHOUT needing new layer1 
bytes.

If so, a "rich man" could open a LN channel, and gradually transfer it to new 
people.

Such a technique would need to meet two requirements (or, so it seems to me):
#1: The layer1 UTXO (that defines the channel) can never change (ie, the 
32-bytes which define the p2sh/tapscript/covenant/whatever, must stay 
what-they-were when the channel was opened).
#2: The new part-owners (who are getting coins from the rich man), will have 
new pubkeys which are NOT known, until AFTER the channel is opened and 
confirmed on the blockchain.

Not sure how you would get both #1 and #2 at the same time. But I am not up to 
date on the latest LN research.

Yes, using channel factories.

I think you may be wrong about this.
...

I am not wrong about this.


Well, let's take a closer look then.

The topic was: "a way, to LN-onboard [a new pubkey] WITHOUT needing new layer1 
bytes".

By which I meant, that I could generate a new pubkey right now, and add it to 
the LN, without any onchain action.

I can shorten and restate the two requirements (and reorder them) as:
#2: Can later add a new public key to the membership set.
#1: Without an onchain action.

And yet you yourself say, very clearly:


... That is why I said changing the membership set requires onchain action.


Which would seem to directly contradict what you say about channel factories.

Unless you can show me how to add my new pubkey_4, to a 3-of-3 channel factory 
opened last year. Without using an onchain action.

You seem to want to instead change the subject. (To something like: 'we can do 
better the rate (32 bytes per 5 onboards), from your footnote'.)

Which is fine. But it is not what I bought up.

***

In general, you seem to have a future in mind, where new users onboard via 
factory.
For example, 50,000 new users want to onboard in the next block. These 
strangers, spontaneously organize into 1000 factories of 55 people each, (50 
newbies with zero coins + 5 wealthier BTCs who have lots of coins). They then 
broadcast into the block and join Bitcoin.
And this one factory provides them with many channels, so it can meet most/all 
of their needs.

I am not here to critique factories. I was simply observing that your logic 
"sidechains don't scale, because you have to share your messages" is not quite 
airtight, because in the case of onboarding the situation is reversed and so supports the 
exact opposite conclusion.
I believe I have made my point by now. It should be easy for people to see what 
each of us has in mind, and the strengths and weaknesses.

I am curious about something, though. Maybe you can help me.
Presumably there are risks to large factories. Perhaps an attacker could join 
each new factory with just $1 of BTC, spend this $1, and then refuse to 
cooperate with the factory any further. Thus they can disable the factory at a 
cost of $1 rented dollar.
If 1000 factories are opened per block, this would be 52.5 M factories per 
year, $52.5 million USD per year to disable all the factories out of spite. 
(All of which they would eventually get back.) I can think of a few people who 
might try it.


I mean, like, LN ... has a lot more onboarding activity than half-hearted 
sidechains like Liquid or Rootstock.

I don't see the relevance of this. We are talking about the future 
(theoretical), not the past (empirical).
For example, someone could say "Ethereum has a lot more onboarding activity than LN 
..." but this would also make no difference to anything.


...The onboarding rate only needs to be as fast as the rate at which people 
want to join Bitcoin.
...

As I pointed out in the other thread:

* LN:
   * Funds can be stolen IF:
 * There is a 51% miner, AND
 * The 51% miner is a member of a channel/channel factory you are in.
* Drivechains:
   * Funds can be stolen IF:
 * There is a 51% miner.
...
So there is a real degradation of security in Drivechains, and if you compute 
the numbers, I am reasonably sure that 33% of the world is unlikely to want to 
use Bitcoin within one month.
I mean we already had a pandemic and everyone going online and so on, and yet 
Bitcoin blockchain feerates are *still* small, I had to fix a bug in CLBOSS 
that came up only due to hitting the minimum feerate, so no --- people are not 
joining Bitcoin at a rate faster than Bitcoin + LN can handle it, even with a 
pretty good reason to move payments online.

Worse, once 100% of the world is onboarded, the extra onboarding capacity is 
useless since the onboarding rate can only match the birth rate (including 
birth of legal persons such as corporations), which we expect is much lower 
than 33% increase per ***month***.

You are buying too much capacity at a real degradation in security, and I am 
not convinced the extra capacity is worth the loss of security.

Separating the onboarding rate from the payment rate 

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[vjudeu via bitcoin-dev]

> Continuous operation of the sidechain then implies a constant stream of 
> 32-byte commitments, whereas continuous operation of a channel factory, in 
> the absence of membership set changes, has 0 bytes per block being published.

The sidechain can push zero bytes on-chain, just by placing a sidechain hash in 
OP_RETURN inside TapScript. Then, every sidechain node can check that "this 
sidechain hash is connected with this Taproot address", without pushing 32 
bytes on-chain.

On 2022-02-28 08:13:03 user ZmnSCPxj via bitcoin-dev 
 wrote:
> Good morning Paul,

> On 2/26/2022 9:00 PM, ZmnSCPxj wrote:
>
> > ...
> >
> > > Such a technique would need to meet two requirements (or, so it seems to 
> > > me):
> > > #1: The layer1 UTXO (that defines the channel) can never change (ie, the 
> > > 32-bytes which define the p2sh/tapscript/covenant/whatever, must stay 
> > > what-they-were when the channel was opened).
> > > #2: The new part-owners (who are getting coins from the rich man), will 
> > > have new pubkeys which are NOT known, until AFTER the channel is opened 
> > > and confirmed on the blockchain.
> > >
> > > Not sure how you would get both #1 and #2 at the same time. But I am not 
> > > up to date on the latest LN research.
> >
> > Yes, using channel factories.
>
> I think you may be wrong about this.
> Channel factories do not meet requirement #2, as they cannot grow to onboard 
> new users (ie, new pubkeys).
> The factory-open requires that people pay to (for example), a 5-of-5 
> multisig. So all 5 fixed pubkeys must be known, before the factory-open is 
> confirmed, not after.

I am not wrong about this.
You can cut-through the closure of one channel factory with the opening of 
another channel factory with the same 5 fixed pubkeys *plus* an additional 100 
new fixed pubkeys.
With `SIGHASH_ANYPREVOUT` (which we need to Decker-Russell-Osuntokun-based 
channel factories) you do not even need to make new signatures for the existing 
channels, you just reuse the existing channel signatures and whether or not the 
*single*, one-input-one-output, close+reopen transaction is confirmed or not, 
the existing channels remain usable (the signatures can be used on both 
pre-reopen and post-reopen).

That is why I said changing the membership set requires onchain action.
But the onchain action is *only* a 1-input-1-output transaction, and with 
Taproot the signature needed is just 64 bytes witness (1 weight unit per byte), 
I had several paragraphs describing that, did you not read them?

Note as well that with sidechains, onboarding also requires action on the 
mainchain, in the form of a sideblock merge-mined on the mainchain.

>
> > We assume that onboarding new members is much rarer than existing members 
> > actually paying each other
>
> Imagine that Bitcoin could only onboard 5 new users per millennium, but once 
> onboarded they had payment nirvana (could transact hundreds of trillions of 
> times per second, privately, smart contracts, whatever).
> Sadly, the payment nirvana would not matter. The low onboarding rate would 
> kill the project.

Fortunately even without channel factories the onboarding rate of LN is much 
much higher than that.
I mean, like, LN *is* live and *is* working, today, and (at least where I have 
looked, but I could be provincial) has a lot more onboarding activity than 
half-hearted sidechains like Liquid or Rootstock.

> The difference between the two rates [onboarding and payment], is not 
> relevant. EACH rate must meet the design goal.
> It is akin to saying: " Our car shifts from park to drive in one-millionth of 
> a second, but it can only shift into reverse once per year; but that is OK 
> because 'we assume that going in reverse is much rarer than driving forward' 
> ".

Your numbers absolutely suck and have no basis in reality, WTF.
Even without batched channel openings and a typical tranaction of 2 inputs, 1 
LN channel, and a change output, you can onboard ~1250 channels per mainchain 
block (admittedly, without any other activity).
Let us assume every user needs 5 channels on average and that is still 250 
users per 10 minutes.
I expect channel factories to increase that by about 10x to 100x more, and then 
you are going to hit the issue of getting people to *use* Bitcoin rather than 
many users wanting to get in but being unable to due to block size limits.

>
> > Continuous operation of the sidechain then implies a constant stream of 
> > 32-byte commitments, whereas continuous operation of a channel factory, in 
> > the absence of membership set changes, has 0 bytes per block being 
> > published.
>
> That's true, but I think you have neglected to actually take out your 
> calculator and run the numbers.
>
> Hypothetically, 10 largeblock-sidechains would be 320 bytes per block 
> (00.032%, essentially nothing).
> Those 10, could onboard 33% of the planet in a single month [footnote], even 
> if each sc-onboard required an average of 800 sc-bytes.
>
> 

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[ZmnSCPxj via bitcoin-dev]

Good morning Paul,

> On 2/26/2022 9:00 PM, ZmnSCPxj wrote:
>
> > ...
> >
> > > Such a technique would need to meet two requirements (or, so it seems to 
> > > me):
> > > #1: The layer1 UTXO (that defines the channel) can never change (ie, the 
> > > 32-bytes which define the p2sh/tapscript/covenant/whatever, must stay 
> > > what-they-were when the channel was opened).
> > > #2: The new part-owners (who are getting coins from the rich man), will 
> > > have new pubkeys which are NOT known, until AFTER the channel is opened 
> > > and confirmed on the blockchain.
> > >
> > > Not sure how you would get both #1 and #2 at the same time. But I am not 
> > > up to date on the latest LN research.
> >
> > Yes, using channel factories.
>
> I think you may be wrong about this.
> Channel factories do not meet requirement #2, as they cannot grow to onboard 
> new users (ie, new pubkeys).
> The factory-open requires that people pay to (for example), a 5-of-5 
> multisig. So all 5 fixed pubkeys must be known, before the factory-open is 
> confirmed, not after.

I am not wrong about this.
You can cut-through the closure of one channel factory with the opening of 
another channel factory with the same 5 fixed pubkeys *plus* an additional 100 
new fixed pubkeys.
With `SIGHASH_ANYPREVOUT` (which we need to Decker-Russell-Osuntokun-based 
channel factories) you do not even need to make new signatures for the existing 
channels, you just reuse the existing channel signatures and whether or not the 
*single*, one-input-one-output, close+reopen transaction is confirmed or not, 
the existing channels remain usable (the signatures can be used on both 
pre-reopen and post-reopen).

That is why I said changing the membership set requires onchain action.
But the onchain action is *only* a 1-input-1-output transaction, and with 
Taproot the signature needed is just 64 bytes witness (1 weight unit per byte), 
I had several paragraphs describing that, did you not read them?

Note as well that with sidechains, onboarding also requires action on the 
mainchain, in the form of a sideblock merge-mined on the mainchain.

>
> > We assume that onboarding new members is much rarer than existing members 
> > actually paying each other
>
> Imagine that Bitcoin could only onboard 5 new users per millennium, but once 
> onboarded they had payment nirvana (could transact hundreds of trillions of 
> times per second, privately, smart contracts, whatever).
> Sadly, the payment nirvana would not matter. The low onboarding rate would 
> kill the project.

Fortunately even without channel factories the onboarding rate of LN is much 
much higher than that.
I mean, like, LN *is* live and *is* working, today, and (at least where I have 
looked, but I could be provincial) has a lot more onboarding activity than 
half-hearted sidechains like Liquid or Rootstock.

> The difference between the two rates [onboarding and payment], is not 
> relevant. EACH rate must meet the design goal.
> It is akin to saying: " Our car shifts from park to drive in one-millionth of 
> a second, but it can only shift into reverse once per year; but that is OK 
> because 'we assume that going in reverse is much rarer than driving forward' 
> ".

Your numbers absolutely suck and have no basis in reality, WTF.
Even without batched channel openings and a typical tranaction of 2 inputs, 1 
LN channel, and a change output, you can onboard ~1250 channels per mainchain 
block (admittedly, without any other activity).
Let us assume every user needs 5 channels on average and that is still 250 
users per 10 minutes.
I expect channel factories to increase that by about 10x to 100x more, and then 
you are going to hit the issue of getting people to *use* Bitcoin rather than 
many users wanting to get in but being unable to due to block size limits.

>
> > Continuous operation of the sidechain then implies a constant stream of 
> > 32-byte commitments, whereas continuous operation of a channel factory, in 
> > the absence of membership set changes, has 0 bytes per block being 
> > published.
>
> That's true, but I think you have neglected to actually take out your 
> calculator and run the numbers.
>
> Hypothetically, 10 largeblock-sidechains would be 320 bytes per block 
> (00.032%, essentially nothing).
> Those 10, could onboard 33% of the planet in a single month [footnote], even 
> if each sc-onboard required an average of 800 sc-bytes.
>
> Certainly not a perfect idea, as the SC onboarding rate is the same as the 
> payment rate. But once they are onboarded, those users can immediately join 
> the LN *from* their sidechain. (All of the SC LNs would be interoperable.)
>
> Such a strategy would take enormous pressure *off* of layer1 (relative to the 
> "LN only" strategy). The layer1 blocksize could even **shrink** from 4 MB 
> (wu) to 400 kb, or lower. That would cancel out the 320 bytes of overhead, 
> many hundreds of times over.
>
> Paul
>
> [footnote] Envelope math, 10 sidechains, 

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Paul Sztorc via bitcoin-dev]

On 2/26/2022 9:00 PM, ZmnSCPxj wrote:


...

Such a technique would need to meet two requirements (or, so it seems to me):
#1: The layer1 UTXO (that defines the channel) can never change (ie, the 
32-bytes which define the p2sh/tapscript/covenant/whatever, must stay 
what-they-were when the channel was opened).
#2: The new part-owners (who are getting coins from the rich man), will have 
new pubkeys which are NOT known, until AFTER the channel is opened and 
confirmed on the blockchain.

Not sure how you would get both #1 and #2 at the same time. But I am not up to 
date on the latest LN research.

Yes, using channel factories.


I think you may be wrong about this.
Channel factories do not meet requirement #2, as they cannot grow to onboard 
new users (ie, new pubkeys).
The factory-open requires that people pay to (for example), a 5-of-5 multisig. 
So all 5 fixed pubkeys must be known, before the factory-open is confirmed, not 
after.



We assume that onboarding new members is much rarer than existing members 
actually paying each other


Imagine that Bitcoin could only onboard 5 new users per millennium, but once 
onboarded they had payment nirvana (could transact hundreds of trillions of 
times per second, privately, smart contracts, whatever).
Sadly, the payment nirvana would not matter. The low onboarding rate would kill 
the project.

The difference between the two rates [onboarding and payment], is not relevant. 
EACH rate must meet the design goal.
It is akin to saying: " Our car shifts from park to drive in one-millionth of a 
second, but it can only shift into reverse once per year; but that is OK because 'we 
assume that going in reverse is much rarer than driving forward' ".



Continuous operation of the sidechain then implies a constant stream of 32-byte 
commitments, whereas continuous operation of a channel factory, in the absence 
of membership set changes, has 0 bytes per block being published.


That's true, but I think you have neglected to actually take out your 
calculator and run the numbers.

Hypothetically, 10 largeblock-sidechains would be 320 bytes per block (00.032%, 
essentially nothing).
Those 10, could onboard 33% of the planet in a single month [footnote], even if 
each sc-onboard required an average of 800 sc-bytes.

Certainly not a perfect idea, as the SC onboarding rate is the same as the 
payment rate. But once they are onboarded, those users can immediately join the 
LN *from* their sidechain. (All of the SC LNs would be interoperable.)

Such a strategy would take enormous pressure *off* of layer1 (relative to the "LN 
only" strategy). The layer1 blocksize could even **shrink** from 4 MB (wu) to 400 
kb, or lower. That would cancel out the 320 bytes of overhead, many hundreds of times 
over.

Paul

[footnote] Envelope math, 10 sidechains, each 50 MB forever-fixed blocksize 
(which is a mere 12.5x our current 4M wu limit): 10 * 6*24*30 * 
((50*1000*1000)/800) / 8.2 billion = .32926
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Paul Sztorc via bitcoin-dev]

On 2/27/2022 11:59 AM, Billy Tetrud via bitcoin-dev wrote:


@Paul
> I think largeblocksidechainsshould be reconsidered:
> * They are not a blocksize increase.
This is short sighted. They would absolutely be a blocksize increase 
for those following a large block sidechain. While sure, it wouldn't 
affect bitcoin users who don't follow that sidechain, its misleading 
to call it "not a blocksize increase" for everyone.


Your larger explanation is entirely correct.

Many of the important anti-largeblock arguments are not relevant to the 
largeblock sidechain strategy, but some of them still are.

My concern is that people will jump to conclusions, and use the old 2015 arguments 
against "a blocksize increase" against this idea.

Hence my small bullet point.



> * They allow users to be different. Some can pay more (for more 
decentralization), some less (for less decentralization).
> gambling the entire future of BTC, on the premise that strong 
decentralization will always be needed at all points in time.
Decentralization isn't just something where more is more valuable and less is 
less valuable. Decentralization is either enough to stop a class of attack or 
its not. Its pretty binary. If the decentralization is not enough, it would be 
a pretty huge catastrophe for those involved. Its pretty clear that making the 
blocksize eg 10 times larger is a poor design choice. So advocating for such a 
thing on a sidechain is just as bad as advocating for it on an altcoin.
Even if people only put a couple satoshis in such a sidechain at a time, and 
don't feel the loss very much, the *world* would feel the loss. Eg if everyone 
had $1 in such a system, and someone stole it all, it would be a theft of 
billions of dollars. The fact that no individual would feel much pain would 
make it not much less harmful to society.


I believe that you have missed my point. Let me try to explain it in more 
detail.

First, imagine a magic spell is cast, which 100% prevents the "class of attack" 
which you mention. In that situation, all of the work that BTC does to remain 
decentralized, is a pure burden with absolutely no benefit whatsoever. Rational users 
will then become indifferent to centralization. Since decentralization has tradeoffs, 
users will tend to be drawn towards 'crypto' projects that have very low decentralization.

Next, imagine that the spell is lifted, and the attacks start. Users will be, 
of course, drawn back towards BTC, and they will appreciate it for its 
decentralization.

So what's the problem? Well, I believe that money has very strong network effects. Therefore, I believe that 
"user inertia" will be much stronger than usual. At a certain critical mass it may be 
insurmountable. So, at certain points along the spectrum, users will "clump up" and get 
"stuck".

Thus, we may "clump" on a chain that is not the most decentralized one. And an adversary 
can use this to their advantage. They can "grow" the centralized chain at first, to help 
it, and help ensure that they do not have to deal with the most decentralized chain.

This entire issue is avoided completely, if all the chains --decentralized and 
centralized-- and in the same monetary unit. Then, the monetary network effects 
never interfere, and the decentralized chain is always guaranteed to exist.


As for the phrase " Its pretty clear that making the blocksize eg 10 times larger is 
a poor design choice" I think this entire way of reasoning about the blocksize, is 
one that only applies to a non-sidechain world.

In contrast, in a world where many chains can be created, it does not matter what Some 
Guy thinks is "pretty clear". The only thing that matters is that people can 
try things out, are rewarded for successes, and are punished for mistakes.

So: if someone makes a largeblock sidechain, and the design is bad, the chain 
fails, and their reputation suffers.

In my way-of-reasoning, someone is actually in the wrong, if they proactively 
censor an experiment of any type. If a creator is willing to stand behind 
something, then it should be tried.

In fact, it is often best for everyone (especially the end user), if a creator keeps 
their ideas secret (from the "peer review" community). That way they can at 
least get credit/glory. The soon-to-be-successful experiments of tomorrow, should be 
incomprehensible to the experts of today. That's what makes them innovations.


Finally, to me it makes no difference if users have their funds stolen from a 
centralized Solana contract (because there is only one full node which the 
operator resets), or from a bip300 centralized bit-Solana sidechain (for the 
same reason). I don't see why the tears shed would be any different.


> We can learn from past mistakes -- when a new largeblock sidechain is needed, 
we can make a new one from scratch, using everything we know.
If there's some design principles that *allow* for safely increasing the blocksize 
substantially like that, then I'd 

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Billy Tetrud via bitcoin-dev]

@Paul
> I think largeblock sidechains should be reconsidered:
> * They are not a blocksize increase.

This is short sighted. They would absolutely be a blocksize increase for
those following a large block sidechain. While sure, it wouldn't affect
bitcoin users who don't follow that sidechain, its misleading to call it
"not a blocksize increase" for everyone.

> * They allow users to be different. Some can pay more (for more 
> decentralization), some less (for less decentralization).

> gambling the entire future of BTC, on the premise that strong 
> decentralization will always be needed at all points in time.

Decentralization isn't just something where more is more valuable and
less is less valuable. Decentralization is either enough to stop a
class of attack or its not. Its pretty binary. If the decentralization
is not enough, it would be a pretty huge catastrophe for those
involved. Its pretty clear that making the blocksize eg 10 times
larger is a poor design choice. So advocating for such a thing on a
sidechain is just as bad as advocating for it on an altcoin.

Even if people only put a couple satoshis in such a sidechain at a
time, and don't feel the loss very much, the *world* would feel the
loss. Eg if everyone had $1 in such a system, and someone stole it
all, it would be a theft of billions of dollars. The fact that no
individual would feel much pain would make it not much less harmful to
society.

> We can learn from past mistakes -- when a new largeblock sidechain is needed, 
> we can make a new one from scratch, using everything we know.

If there's some design principles that *allow* for safely increasing the
blocksize substantially like that, then I'd advocate for it in bitcoin. But
the goal of sidechains should not be "shoot from the hip and after everyone
on that sidechain gets burned we'll have learned valuable lessons". That's
not how engineering works. That's akin to wreckless human experimentation.



On Sun, Feb 27, 2022 at 1:25 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning again Paul,
>
> > With sidechains, changing the ownership set requires that the sidechain
> produce a block.
> > That block requires a 32-byte commitment in the coinbase.
> > What is more, if any transfers occur on the sidechain, they cannot be
> real without a sidechain block, that has to be committed on the mainchain.
>
> The above holds if the mainchain miners also act as sidechain validators.
> If they are somehow separate (i.e. blind merge mining), then the
> `OP_BRIBE` transaction needed is also another transaction.
> Assuming the sidechain validator is using Taproot as well, it needs the
> 32+1 txin, a 64-byte signature, a 32-byte copy of the sidechain commitment
> that the miner is being bribed to put in the coinbase, and a txout for any
> change the sidechain validator has.
>
> This is somewhat worse than the case for channel factories, even if you
> assume that every block, at least one channel factory has to do an
> onboarding event.
>
> > Thus, while changing the membership set of a channel factory is more
> expensive (it requires a pointer to the previous txout, a 64-byte Taproot
> signature, and a new Taproot address), continuous operation does not
> publish any data at all.
> > While in sidehchains, continuous operation and ordinary payments
> requires ideally one commitment of 32 bytes per mainchain block.
> > Continuous operation of the sidechain then implies a constant stream of
> 32-byte commitments, whereas continuous operation of a channel factory, in
> the absence of membership set changes, has 0 bytes per block being
> published.
> >
> > We assume that onboarding new members is much rarer than existing
> members actually paying each other in an actual economy (after the first
> burst of onboarding, new members will only arise in proportion to the birth
> rate, but typical economic transactions occur much more often), so
> optimizing for the continuous operation seems a better tradeoff.
>
> Perhaps more illustratively, with channel factories, different layers have
> different actions they can do, and the only one that needs to be broadcast
> widely are actions on the onchain layer:
>
> * Onchain: onboarding / deboarding
> * Channel Factory: channel topology change
> * Channel: payments
>
> This is in contrast with merge-mined Sidechains, where *all* activity
> requires a commitment on the mainchain:
>
> * Onchain: onboarding / deboarding, payments
>
> While it is true that all onboarding, deboarding, and payments are
> summarized in a single commitment, notice how in LN-with-channel-factories,
> all onboarding / deboarding is *also* summarized, but payments *have no
> onchain impact*, at all.
>
> Without channel factories, LN is only:
>
> * Onchain: onboarding / deboarding, channel topology change
> * Channel: payments
>
> So even without channel factories there is already a win, although again,
> due to the large numbers of channels we need, a 

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[ZmnSCPxj via bitcoin-dev]

Good morning again Paul,

> With sidechains, changing the ownership set requires that the sidechain 
> produce a block.
> That block requires a 32-byte commitment in the coinbase.
> What is more, if any transfers occur on the sidechain, they cannot be real 
> without a sidechain block, that has to be committed on the mainchain.

The above holds if the mainchain miners also act as sidechain validators.
If they are somehow separate (i.e. blind merge mining), then the `OP_BRIBE` 
transaction needed is also another transaction.
Assuming the sidechain validator is using Taproot as well, it needs the 32+1 
txin, a 64-byte signature, a 32-byte copy of the sidechain commitment that the 
miner is being bribed to put in the coinbase, and a txout for any change the 
sidechain validator has.

This is somewhat worse than the case for channel factories, even if you assume 
that every block, at least one channel factory has to do an onboarding event.

> Thus, while changing the membership set of a channel factory is more 
> expensive (it requires a pointer to the previous txout, a 64-byte Taproot 
> signature, and a new Taproot address), continuous operation does not publish 
> any data at all.
> While in sidehchains, continuous operation and ordinary payments requires 
> ideally one commitment of 32 bytes per mainchain block.
> Continuous operation of the sidechain then implies a constant stream of 
> 32-byte commitments, whereas continuous operation of a channel factory, in 
> the absence of membership set changes, has 0 bytes per block being published.
>
> We assume that onboarding new members is much rarer than existing members 
> actually paying each other in an actual economy (after the first burst of 
> onboarding, new members will only arise in proportion to the birth rate, but 
> typical economic transactions occur much more often), so optimizing for the 
> continuous operation seems a better tradeoff.

Perhaps more illustratively, with channel factories, different layers have 
different actions they can do, and the only one that needs to be broadcast 
widely are actions on the onchain layer:

* Onchain: onboarding / deboarding
* Channel Factory: channel topology change
* Channel: payments

This is in contrast with merge-mined Sidechains, where *all* activity requires 
a commitment on the mainchain:

* Onchain: onboarding / deboarding, payments

While it is true that all onboarding, deboarding, and payments are summarized 
in a single commitment, notice how in LN-with-channel-factories, all onboarding 
/ deboarding is *also* summarized, but payments *have no onchain impact*, at 
all.

Without channel factories, LN is only:

* Onchain: onboarding / deboarding, channel topology change
* Channel: payments

So even without channel factories there is already a win, although again, due 
to the large numbers of channels we need, a channel factory in practice will be 
needed to get significantly better scaling.


Finally, in practice with Drivechains, starting a new sidechain requires 
implicit permission from the miners.
With LN, new channels and channel factories do not require any permission, as 
they are indistinguishable from ordinary transactions.
(the gossip system does leak that a particular UTXO is a particular published 
channel, but gossip triggers after deep confirmation, at which point it would 
be too late for miners to censor the channel opening.
The miners can censor channel closure for published channels, admittedly, but 
at least you can *start* a new channel without being censored, which you cannot 
do with Drivechain sidechains.)


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

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[ZmnSCPxj via bitcoin-dev]

Good morning Paul,

> ***
>
> You have emphasized the following relation: "you have to show your 
> transaction to everyone" = "thing doesn't scale".
>
> However, in LN, there is one transaction which you must, in fact, "show to 
> everyone": your channel-opener.
>
> Amusingly, in the largeblock sidechain, there is not. You can onboard using 
> only the blockspace of the SC.
> (One "rich guy" can first shift 100k coins Main-to-Side, and he can 
> henceforth onboard many users over there. Those users can then onboard new 
> users, forever.)
>
> So it would seem to me, that you are on the ropes, even by your own 
> criterion. [Footnote 1]
>
> ***
>
> Perhaps, someone will invent a way, to LN-onboard WITHOUT needing new layer1 
> bytes.
>
> If so, a "rich man" could open a LN channel, and gradually transfer it to new 
> people.
>
> Such a technique would need to meet two requirements (or, so it seems to me):
> #1: The layer1 UTXO (that defines the channel) can never change (ie, the 
> 32-bytes which define the p2sh/tapscript/covenant/whatever, must stay 
> what-they-were when the channel was opened).
> #2: The new part-owners (who are getting coins from the rich man), will have 
> new pubkeys which are NOT known, until AFTER the channel is opened and 
> confirmed on the blockchain.
>
> Not sure how you would get both #1 and #2 at the same time. But I am not up 
> to date on the latest LN research.

Yes, using channel factories.

A channel factory is a N-of-N where N >= 3, and which uses the same offchain 
technology to host multiple 2-of-2 channels.
We observe that, just as an offchain structure like a payment channel can host 
HTLCs, any offchain structure can host a lot of *other* contracts, because the 
offchain structure can always threaten to drop onchain to enforce any 
onchain-enforceable contract.
But an offchain structure is just another onchain contract!
Thus, an offchain structure can host many other offchain structures, and thus 
an N-of-N channel factory can host multiple 2-of-2 channel factories.

(I know we discussed sidechains-within-sidechains before, or at least I 
mentioned that to you in direct correspondence, this is basically that idea 
brought to its logical conclusion.)

Thus, while you still have to give *one* transaction to all Bitcoin users, that 
single transaction can back several channels, up to (N * (N - 1)) / 2.

It is not quite matching your description --- the pubkeys of the peer 
participants need to be fixed beforehand.
However, all it means is some additional pre-planning during setup with no 
scope for dynamic membership.

At least, you cannot dynamically change membership without onchain action.
You *can* change membership sets by publishing a one-input-one-output 
transaction onchain, but with Taproot, the new membership set is representable 
in a single 32-byte Taproot address onchain (admittedly, the transaction input 
is a txin and thus has overhead 32 bytes plus 1 byte for txout index, and you 
need 64 bytes signature for Taproot as well).
The advantage is that, in the meantime, if membership set is not changed, 
payments can occur *without* any data published on the blockchain (literally 0 
data).

With sidechains, changing the ownership set requires that the sidechain produce 
a block.
That block requires a 32-byte commitment in the coinbase.
What is more, if *any* transfers occur on the sidechain, they cannot be real 
without a sidechain block, that has to be committed on the mainchain.

Thus, while changing the membership set of a channel factory is more expensive 
(it requires a pointer to the previous txout, a 64-byte Taproot signature, and 
a new Taproot address), continuous operation does not publish any data at all.
While in sidehchains, continuous operation and ordinary payments requires 
ideally one commitment of 32 bytes per mainchain block.
Continuous operation of the sidechain then implies a constant stream of 32-byte 
commitments, whereas continuous operation of a channel factory, in the absence 
of membership set changes, has 0 bytes per block being published.

We assume that onboarding new members is much rarer than existing members 
actually paying each other in an actual economy (after the first burst of 
onboarding, new members will only arise in proportion to the birth rate, but 
typical economic transactions occur much more often), so optimizing for the 
continuous operation seems a better tradeoff.


Channel factories have the nice properties:

* N-of-N means that nobody can steal from you.
  * Even with a 51% miner, nobody can steal from you as long as none of the N 
participants is the 51% miner, see the other thread.
* Graceful degradation: even if if 1 of the N is offline, payments are done 
over the hosted 2-of-2s, and the balance of probability is that most of the 
2-of-2s have both participants online and payments can continue to occur.

--

The reason why channel factories do not exist *yet* is that the main offchain 
construction we 

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Paul Sztorc via bitcoin-dev]

On 2/26/2022 1:43 AM, ZmnSCPxj via bitcoin-dev wrote:


...
Drivechains are not a scaling solution [FOOTNOTE 1] ...
I personally am interested only in scaling solutions, adding more 
non-scaling-useable functionality is not of interest to me and I do not really 
care
...
But if there is consensus that those arguments are bogus, then go ahead --- add 
Drivechains and/or recursive covenants.
...

[FOOTNOTE 1] Sidechains are not a scaling solution ... Blockchains are 
inefficient ... and you have to show your transaction to everyone.
...
  Now you might conter-argue that you can have multiple smaller sidechains and 
just use HTLCs to trade across them ... I would then counter-counter-argue that 
bringing this to the most extreme conclusion, you would have tons of sidechains 
with only 2 participants each ...


Do you really hang your entire --"sidechains are not a scaling solution"-- 
argument on this frail logic?

The scaling strategy (in LN and DC) is the same: try NOT to "show your transaction 
to everyone". The details are of course different.

I think largeblock sidechains should be reconsidered:
 * They are not a blocksize increase.
 * They endorse the principle of scaling in layers.
 * They allow users to be different. Some can pay more (for more 
decentralization), some less (for less decentralization).
(We are currently gambling the entire future of BTC, on the premise that 
strong decentralization will always be needed at all points in time.)
(This leaves us vulnerable to a strategy where our adversaries temporarily 
favor/promote centralized chains, so as to "domesticate" / control these in the 
future.)
 * We can learn from past mistakes -- when a new largeblock sidechain is 
needed, we can make a new one from scratch, using everything we know.
 * Different teams can compete, releasing different chains independently; thus curtailing 
"toxicity".
 * All of the fees, paid on all blockchains, arrive as revenue to the same 
group of miners, thus improving total hashrate/difficulty.
 * Sidechains will organize geographically, which may help security (ie, USA could 
spitefully run full nodes of the "China" largeblock sidechain).
 * Relative to LN, users enjoy: unlimited "inbound liquidity", can receive 
money while offline, no risk that the channel will close, etc.

Certainly, sidechains are NOT for everyone. (Just as [I imagine] the LN is not 
for everyone.)

However, in 2015, many hardfork-largeblockers said: "we do not run a full node, full 
nodes are not important; we use SPV; read the whitepaper" etc.
They used SPV completely; and wanted large blocks. Presumably they would be happy 
users of a largeblock sidechain. So it would be >0 users.

Sadly, this idea is neglected, (I think) because of its unfortunate resemblance 
to naive-largeblock-ism. This is irrational.

***

You have emphasized the following relation: "you have to show your transaction to 
everyone" = "thing doesn't scale".

However, in LN, there is one transaction which you must, in fact, "show to 
everyone": your channel-opener.

Amusingly, in the largeblock sidechain, there is not. You can onboard using 
only the blockspace of the SC.
(One "rich guy" can first shift 100k coins Main-to-Side, and he can henceforth 
onboard many users over there. Those users can then onboard new users, forever.)

So it would seem to me, that you are on the ropes, even by your own criterion. 
[Footnote 1]

***

Perhaps, someone will invent a way, to LN-onboard WITHOUT needing new layer1 
bytes.

If so, a "rich man" could open a LN channel, and gradually transfer it to new 
people.

Such a technique would need to meet two requirements (or, so it seems to me):
#1: The layer1 UTXO (that defines the channel) can never change (ie, the 
32-bytes which define the p2sh/tapscript/covenant/whatever, must stay 
what-they-were when the channel was opened).
#2: The new part-owners (who are getting coins from the rich man), will have 
new pubkeys which are NOT known, until AFTER the channel is opened and 
confirmed on the blockchain.

Not sure how you would get both #1 and #2 at the same time. But I am not up to 
date on the latest LN research.

Paul


[Footnote 1]
I am certainly not a LN expert, so perhaps this analysis is misconceived. But consider 
these "best case scenario" assumptions for LN:
 * Each new channel-open consumes just 32 vbytes (since they are all done via one or more 
"rich men" who batches all these into one block, 24/7/365)
 * Each new channel-open, onboards 5 users at once who are a permanent trust 
group / channel factory / what-have-you
  (these five newcomers must coordinate with each other and the "rich man", 
presumably via calendly link or whatever, for their one shot at getting on the 
blockchain).
 * That one single channel is able to meet 100% of the user's payment needs
  (it never has any problems, with liquidity /balancing /routing /uptime 
/hotwallet-crashing /counterparty-fees /etc)
  (and also, people do NOT 

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Billy Tetrud via bitcoin-dev]

> If Drivechains are bad for whatever reason, we should not add recursive
covenants.

Bad "for who" was the crux of my question to you. Even if drivechains are
always bad for their users, I don't think that's a good enough reason to
block things that could allow people to build user-space drivechains, as
long as it doesn't negatively affect normal Bitcoin users.

> Drivechains are not a scaling solution

I generally agree, more of a laboratory where many things (including
scaling solutions) can be tested.

> Principle of Least Power.
A concern is that, since it turns out recursive covenants are sufficient to
implement Drivechains, recursive covenants may also enable *other*
techniques, currently unknown, which may have negative effects on Bitcoin,
or which would be considered undesirable by a significant section of the
userbase.

I think the principle of least power is a good one, but it cannot be dogma.
I think your point about unknown consequences is reasonable and a study on
that kind of thing would be quite valuable. The community has discussed it
multiple times in the past, and so at least some thought has gone into it,
with nothing very strong in opposition that I know of. Has anyone made a
good summary/study of the kinds of things recursive covenants allows?

On Sat, Feb 26, 2022, 02:35 Prayank via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning ZmnSCPxj,
>
> > Of course, I know of no such technique, but given that a technique
> (Drivechains) which before would have required its own consensus change,
> turns out to be implementable inside recursive covenants, then I wonder if
> there are other things that would have required their own consensus change
> that are now *also* implementable purely in recursive covenants.
>
>
> Agree. I would be interested to know what is NOT possible once we have
> recursive covenants.
>
> > if there is *now* consensus that Drivechains are not bad, go ahead, add
> recursive covenants (but please can we add `SIGHASH_NOINPUT` and `OP_CTV`
> first?)
>
>
> Agree and I think everything can be done in separate soft forks.
>
>
>
>
> --
> Prayank
>
> A3B1 E430 2298 178F
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Prayank via bitcoin-dev]

Good morning ZmnSCPxj,

> Of course, I know of no such technique, but given that a technique 
> (Drivechains) which before would have required its own consensus change, 
> turns out to be implementable inside recursive covenants, then I wonder if 
> there are other things that would have required their own consensus change 
> that are now *also* implementable purely in recursive covenants.


Agree. I would be interested to know what is NOT possible once we have 
recursive covenants.

> if there is *now* consensus that Drivechains are not bad, go ahead, add 
> recursive covenants (but please can we add `SIGHASH_NOINPUT` and `OP_CTV` 
> first?)


Agree and I think everything can be done in separate soft forks.



-- 
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] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Billy Tetrud via bitcoin-dev]

@ZmnSCPxj
> we have already rejected Drivechains

I also think this is kind of dubious. I don't remember consensus being to
"reject" drivechains, as much as consensus was that it wasn't a priority
and there wasn't a lot of interest in doing on it from many people (I'm
sure Paul could comment further on that).

> sidechains on Drivechains become a block size increase.

While this would be true for those who opt into a particular drivechain, I
think its important to note that it would *not* be identical to a
main-chain block size increase in a very important way: normal bitcoin
miners and nodes nodes that don't care about drivechains would not see a
blocksize increase.

But even in the hypothetical scenario where *all* mainchain miners expand
their business to sidechains, it still does not negatively affect normal
bitcoin nodes that don't care about drivechains. The important things
 about a "normal"
blocksize increase are:

A. It increases the machine resources necessary for IBD, transaction relay,
and validation
B. It probably increases the growth rate of the UTXO set, increasing memory
necessary to store that.
C. It increases the cost of storing the blockchain on non-pruned nodes
D. It increases the average propagation time of new blocks, which increases
miner centralization pressure.

The existence of drivechains with every miner opted into (some of) them
would only negatively impact item D. Normal bitcoin nodes wouldn't need to
use any extra resources if they don't care about drivechains. And miners
would only have additional centralization pressure proportional to what
drivechains they're opted into. The reason for that is that if a miner is
opted into drivechain X, and propagation of transaction data for
drivechain X is significantly slower than the normal bitcoin network, a
miner may not have the latest drivechain X block to merge mine on top of.
However that miner can still mine bitcoin with no additional latency, and
so that centralization pressure is minimal unless a significant fraction of
the miner's revenue comes from drivechains with slow data propagation.
Beyond that, by my calculations, miner centralization is quite far from
being significantly affected by blocksize increases. So unless drivechains
become the dominant use case of the bitcoin blockchain, this really isn't
something that I expect to cause any substantial miner centralization or
other blocksize related problems.

ZmnSCPaj, are you arguing that drivechains are bad for bitcoin or are you
arguing that it would be unwise to opt into a drivechain? Those are very
different arguments. If drivechains compromised things for normal bitcoin
nodes that ignore drivechains, then I agree that would be serious reason to
reject drivechains outright and reject things that allow it to happen.
However, if all you're saying is that people can shoot themselves in the
foot with drivechains, then avoiding drivechains should not be a
significant design consideration for bitcoin but rather for those who might
consider spending their time working on drivechains.

On Thu, Feb 24, 2022 at 6:03 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning aj,
>
> > > 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.
>
> ?
>
> Where:
>
> * E = Drivechains
> * X = BIP-300
> * Z = some general computation facility
> * G = some feature.
>
> But my understanding is that most of the NACKs on the BIP-300 were of the
> form:
>
> * X implements E.
> * E is bad.
> * Therefore, we should not merge in X.
>
> If the above statement "E is bad" holds, then:
>
> * Z implements G and E.
> * Therefore, we should not merge in Z.
>
> Where Z = something that implements recursive covenants.
>
> I think we really need someone who NACKed BIP-300 to speak up.
> 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,
> therefore we can merge in a feature that enables Recursive Covenants ->
> Turing-Completeness -> Drivechains.
> * Even if you NACKed before, you *are* allowed to change your mind and
> move to this position.
>   * R[0], R[1] ... are valid arguments are Drivechains are bad, therefore
> we should **NOT** merge in a feature that 

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Anthony Towns via bitcoin-dev]

On Thu, Feb 24, 2022 at 12:03:32PM +, 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 

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[ZmnSCPxj via bitcoin-dev]

Good morning aj,

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

?

Where:

* E = Drivechains
* X = BIP-300
* Z = some general computation facility
* G = some feature.

But my understanding is that most of the NACKs on the BIP-300 were of the form:

* X implements E.
* E is bad.
* Therefore, we should not merge in X.

If the above statement "E is bad" holds, then:

* Z implements G and E.
* Therefore, we should not merge in Z.

Where Z = something that implements recursive covenants.

I think we really need someone who NACKed BIP-300 to speak up.
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, 
therefore we can merge in a feature that enables Recursive Covenants -> 
Turing-Completeness -> Drivechains.
* Even if you NACKed before, you *are* allowed to change your mind and move 
to this position.
  * R[0], R[1] ... are valid arguments are Drivechains are bad, therefore we 
should **NOT** merge in a feature that implements Recursive Covenants -> 
Turing-Completeness -> Drivechains.

You cannot have it both ways.
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.

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

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


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

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Anthony Towns via bitcoin-dev]

On Wed, Feb 23, 2022 at 11:28:36AM +, 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

___
bitcoin-dev mailing 

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[ZmnSCPxj via bitcoin-dev]

Good morning Paul, welcome back, and the list,


For the most part I am reluctant to add Turing-completeness due to the 
Principle of Least Power.

We saw this play out on the web browser technology.
A full Turing-complete language was included fairly early in a popular HTML 
implementation, which everyone else then copied.
In the beginning, it had very loose boundaries, and protections against things 
like cross-site scripting did not exist.
Eventually, W3C cracked down and modern JavaScript is now a lot more sandboxed 
than at the beginning --- restricting its power.
In addition, for things like "change the color of this bit when the mouse 
hovers it", which used to be implemented in JavaScript, were moved to CSS, a 
non-Turing-complete language.

The Principle of Least Power is that we should strive to use the language with 
*only what we need*, and naught else.

So I think for the most part that Turing-completeness is dangerous.
There may be things, other than Drivechain, that you might object to enabling 
in Bitcoin, and if those things can be implemented in a Turing-complete 
language, then they are likely implementable in recursive covenants.

That the web *started* with a powerful language that was later restricted is 
fine for the web.
After all, the main use of the web is showing videos of attractive female 
humans, and cute cats.
(WARNING: WHEN I TAKE OVER THE WORLD, I WILL TILE IT WITH CUTE CAT PICTURES.)
(Note: I am not an AI that seeks to take over the world.)
But Bitcoin protects money, which I think is more important, as it can be 
traded not only for videos of attractive female humans, and cute cats, but 
other, lesser things as well.
So I believe some reticence towards recursive covenants, and other things it 
may enable, is warranted,

Principle of Least Power exists, though admittedly, this principle was 
developed for the web.
The web is a server-client protocol, but Bitcoin is peer-to-peer, so it seems 
certainly possible that Principle of Least Power does not apply to Bitcoin.
As I understand it, however, the Principle of Least Power exists *precisely* 
because increased power often lets third parties do more than what was 
expected, including things that might damage the interests of the people who 
allowed the increased power to exist, or things that might damage the interests 
of *everyone*.

One can point out as well, that despite the problems that JavaScript 
introduced, it also introduced GMail and the now-rich Web ecosystem.

Perhaps one might liken recursive covenants to the box that was opened by 
Pandora.
Once opened, what is released cannot be put back.
Yet perhaps at the bottom of this box, is Hope?



Also: Go not to the elves for counsel, for they will say both no and yes.

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

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Paul Sztorc via bitcoin-dev]

On 2/23/2022 6:28 AM, ZmnSCPxj via bitcoin-dev wrote:


... Drivechains is implementable on a Turing-complete
language.
And we have already rejected Drivechains, 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.


Is this indeed the reason? Because it is not a good one.

First, (as always) we must ignore BIP 301*. (Since it was invented to cancel 
point 1. Which it does -- by giving an incentive for side-validators and 
main-miners to UN-merge their businesses.)

With that out of the way, let's swap "blocksize increase" for "mining via natural 
gas flaring" :

1. Oil drillers and mainchain miners have a strong incentive** to merge their 
businesses.
2. Mainchain miners end up drilling for oil.
3. Ergo, sidechains on Drivechains become a requirement, that full nodes mine 
for oil.

The above logic is flawed, because full nodes can ignore the mining process. 
Nodes outrank miners.

Merged mining is, in principle, no different from any other source of mining 
profitability. I believe there is an irrational prejudice against merged 
mining, because MM takes the form of software. It would be like an NFL referee 
who refuses to allow their child to play an NFL videogame, on the grounds that 
the reffing in the game is different from how the parent would ref. But that 
makes no difference to anything. The only relevant issue is if the child has 
fun playing the videogame.

(And of course, merged mining long predates drivechain, and miners are MMing 
now, and have been for years. It was Satoshi who co-invented merged mining, so 
the modern prejudice against it is all the more mysterious.)


Also:

1.  The sidechain-to-mainchain peg degrades the security of sidechain
 users from consensus "everyone must agree to the rules" to democracy
 "if enough enfranchised voters say so, they can beat you up and steal
 your money".

In this write-up, I will...


This is also a mischaracterization.

Drivechain will not work if 51% hashrate is attacking the network. But that is 
the case for everything, including the Lightning Network***.

So there is no sense in which the security is "degraded". To establish that, one would need arguments about what will probably happen and why. Which is exactly what my original Nov 2015 article contains: truthcoin.info/blog/drivechain/#drivechains-security , as does my Peer Review section :https://www.drivechain.info/peer-review/peer-review-new/  


(And, today Largeblocker-types do not have any "everyone must agree to the rules" consensus, at 
all. Anyone who wants to use a sidechain-feature today, must obtain it via Altcoin or via real-world trust. 
So the current security is "nothing" and so it is hard to see how that could be 
"degraded".)

--

I am not sure it is a good use of my time to talk to this list about 
Drivechain. My Nov 2015 article anticipated all of the relevant 
misunderstandings. Almost nothing has changed since then.

As far as I am concerned, Drivechain was simply ahead of its time. Eventually, 
one or more of the following --the problem of Altcoins, the human desire for 
freedom and creativity, the meta-consensus/upgrade/ossification problem, the 
problem of persistently low security budget, and/or the expressiveness of 
Bitcoin smart contracts-- will force Bitcoiners to relearn drivechain-lore and 
eventually adopt something drivechain-like. At which point I will write to 
historians to demand credit. That is my plan so far, at least.

--

As to the actual content of your post, it seems pro-Drivechain.

After all, you are saying that Recursive Covenants --> Turing Completeness --> 
Drivechain. So, which would you rather have? The hacky, bizzaro, covenant-Drivechain, 
or my pure optimized transparent Bip300-Drivechain? Seems that this is exactly what I 
predicted: people eventually reinventing Drivechain.

On this topic, in 2015-2016 I wrote a few papers and gave a few recorded talks, in which I 
compared the uncontrollable destructive chaos of Turing Completeness, to a "categorical" 
Turing Completeness where contracts are sorted by category (ie, all of the BitName contracts in the 
Namecoin-sidechain, all of the oracle contracts in the oracle sidechain, etc). The categorical 
strategy allows, paradoxically (and perhaps counterintuitively), for more expressive contracts, 
since you can prevent smart contracts from attacking each other. (They must have a category, so if 
they aren't Name-contracts they cannot live in the Namecoin-sidechain -- they ultimately must live 
in an "Evil Sidechain", which the miners have motive and opportunity to simply disable.) 
If people are now talking about how Turing Completeness can lead to smart contracts attacking each 
other, then I suppose I was years ahead-of-my-time with that, as well. Incidentally, 

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[ZmnSCPxj via bitcoin-dev]

Subject: Turing-Completeness, And Its Enablement Of Drivechains

Introduction


Recently, David Harding challenged those opposed to recursive covenants
for *actual*, *concrete* reasons why recursive covenants are a Bad Thing
(TM).

Generally, it is accepted that recursive covenants, together with the
ability to update loop variables, is sufficiently powerful to be
considered Turing-complete.
So, the question is: why is Turing-completness bad, if it requires
*multiple* transactions in order to implement Turing-completeness?
Surely the practical matter that fees must be paid for each transaction
serves as a backstop against Turing-completeness?
i.e. Fees end up being the "maximum number of steps", which prevents a
language from becoming truly Turing-complete.

I point out here that Drivechains is implementable on a Turing-complete
language.
And we have already rejected Drivechains, 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.

Also:

1.  The sidechain-to-mainchain peg degrades the security of sidechain
users from consensus "everyone must agree to the rules" to democracy
"if enough enfranchised voters say so, they can beat you up and steal
your money".

In this write-up, I will demonstrate how recursive covenants, with
loop variable update, is sufficient to implement a form Drivechains.
Logically, if the construct is general enough to form Drivechains, and
we rejected Drivechains, we should also reject the general construct.

Digression: `OP_TLUV` And `OP_CAT` Implement Recursive Covenants


Let me now do some delaying tactics and demonstrate how `OP_TLUV` and
`OP_CAT` allow building recursive covenants by quining.

`OP_TLUV` has a mode where the current Tapleaf is replaced, and the
new address is synthesized.
Then, an output of the transaction is validated to check that it has
the newly-synthesized address.

Let me sketch how a simple recursive covenant can be built.
First, we split the covenant into three parts:

1.  A hash.
2.  A piece of script which validates that the first witness item
hashes to the above given hash in part #1, and then pushes that
item into the alt stack.
3.  A piece of script which takes the item from the alt stack,
hashes it, then concatenates a `OP_PUSH` of the hash to that
item, then does a replace-mode `OP_TLUV`.

Parts 1 and 2 must directly follow each other, but other SCRIPT
logic can be put in between parts 2 and 3.
Part 3 can even occur multiple times, in various `OP_IF` branches.

In order to actually recurse, the top item in the witness stack must
be the covenant script, *minus* the hash.
This is supposed to be the quining argument.

The convenant script part #2 then checks that the quining argument
matches the hash that is hardcoded into the SCRIPT.
This hash is the hash of the *rest* of the SCRIPT.
If the quining argument matches, then it *is* the SCRIPT minus its
hash, and we know that we can use that to recreate the original SCRIPT.
It then pushes them out of the way into the alt stack.

Part #3 then recovers the original SCRIPT from the alt stack, and
resynthesizes the original SCRIPT.
The `OP_TLUV` is then able to resynthesize the original address.

Updating Loop Variables
---

But repeating the same SCRIPT over and over is boring.

What is much more interesting is to be able to *change* the SCRIPT
on each iteration, such that certain values on the SCRIPT can be
changed.

Suppose our SCRIPT has a loop variable `i` that we want to change
each time we execute our SCRIPT.

We can simply put this loop variable after part 1 and before part 2.
Then part 2 is modified to first push this loop variable onto the
alt stack.

The SCRIPT that gets checked is always starts from part 2.
Thus, the SCRIPT, minus the loop variable, is always constant.
The SCRIPT can then access the loop variable from the alt stack.
Part 2 can be extended so that the loop variable is on top of the
quined SCRIPT on the alt stack.
This lets the SCRIPT easily access the loop variable.
The SCRIPT can also update the loop variable by replacing the top
of the alt stack with a different item.

Then part 3 first pops the alt stack top (the loop variable),
concatenates it with an appropriate push, then performs the
hash-then-concatenate dance.
This results in a SCRIPT that is the same as the original SCRIPT,
but with the loop variable possibly changed.

The SCRIPT can use multiple loop variables; it is simply a question
of how hard it would be to access from the alt stack.

Drivechains Over Recursive Covenants


Drivechains can be split into four parts:

1.  A way to commit to the sidechain blocks.
2.  A way to move funds from 

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[ZmnSCPxj via bitcoin-dev]

Good morning Dave,

> On Mon, Feb 07, 2022 at 08:34:30PM -0800, Jeremy Rubin via bitcoin-dev wrote:
>
> > Whether [recursive covenants] is an issue or not precluding this sort
> > of design or not, I defer to others.
>
> For reference, I believe the last time the merits of allowing recursive
> covenants was discussed at length on this list[1], not a single person
> replied to say that they were opposed to the idea.
>
> I would like to suggest that anyone opposed to recursive covenants speak
> for themselves (if any intelligent such people exist). Citing the risk
> of recursive covenants without presenting a credible argument for the
> source of that risk feels to me like (at best) stop energy[2] and (at
> worst) FUD.

Let me try to give that a shot.

(Just to be clear, I am not an artificial intelligence, thus, I am not an 
"intelligent such people".)

The objection here is that recursion can admit partial (i.e. Turing-complete) 
computation.
Turing-completeness implies that the halting problem cannot be solved for 
arbitrary programs in the language.

Now, a counter-argument to that is that rather than using arbitrary programs, 
we should just construct programs from provably-terminating components.
Thus, even though the language may admit arbitrary programs that cannot 
provably terminate, "wise" people will just focus on using that subset of the 
language, and programming styles within the language, which have proofs of 
termination.
Or in other words: people can just avoid accepting coin that is encumbered with 
a SCRIPT that is not trivially shown to be non-recursive.

The counter-counter-argument is that it leaves such validation to the user, and 
we should really create automation (i.e. lower-level non-sentient programs) to 
perform that validation on behalf of the user.
***OR*** we could just design our language so that such things are outright 
rejected by the language as a semantic error, of the same type as `for (int x = 
0; x = y; x++);` is a semantic error that most modern C compilers will reject 
if given `-Wall -Werror`.


Yes, we want users to have freedom to shoot themselves in the feet, but we also 
want, when it is our turn to be the users, to keep walking with two feet as 
long as we can.

And yes, you could instead build a *separate* tool that checks if your SCRIPT 
can be proven to be non-recursive, and let the recursive construct remain in 
the interpreter and just require users who don't want their feet shot to use 
the separate tool.
That is certainly a valid alternate approach.
It is certainly valid to argue as well, that if a possibly-recursive construct 
is used, and you cannot find a proof-of-non-recursion, you should avoid coins 
encumbered with that SCRIPT (which is just a heuristic that approximate a tool 
for proof-of-non-recursion).

On the other hand, if we have the ability to identify SCRIPTs that have some 
proof-of-non-recursion, why is such a tool not built into the interpreter 
itself (in the form of operations that are provably non-recursive), why have a 
separate tool that people might be too lazy to actually use?


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

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Anthony Towns via bitcoin-dev]

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

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

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Lucky Star via bitcoin-dev]

Hello,

I'm opposed to recursive covenants because they allow the government to 
_gradually_ restrict all bitcoins.

Without covenants, other miners can fork to a free blockchain, if the 
government tells miners each transaction to be added in the block. Thus the 
government cannot impose desires on the Bitcoin community. With covenants, the 
government gradually forces all companies to use the permissible covenants. 
There is no free blockchain, and the government controls more bitcoins each day.

Bitcoin experts Greg Maxwell and Peter Todd explained this reason and many 
others on the forum.[1] More experts also agreed, and it's common knowledge. I 
strongly recommend to support the OP_CHECKTEMPLATEVERIFY. It is well reviewed, 
and it protects the Bitcoin community from the bad effects of covenants. With 
OP_CHECKTEMPLATEVERIFY, we achieve the best of both worlds.

With best regards,
Lucky Star

[1] Maxwell, Greg. "CoinCovenants using SCIP signatures, an amusingly bad 
idea." https://bitcointalk.org/index.php?topic=278122.0;all

> On Mon, Feb 07, 2022 at 08:34:30PM -0800, Jeremy Rubin via bitcoin-dev wrote:
> > Whether [recursive covenants] is an issue or not precluding this sort
> > of design or not, I defer to others.
>
>
> For reference, I believe the last time the merits of allowing recursive
> covenants was discussed at length on this list[1], not a single person
> replied to say that they were opposed to the idea.
>
>
> I would like to suggest that anyone opposed to recursive covenants speak
> for themselves (if any intelligent such people exist). Citing the risk
> of recursive covenants without presenting a credible argument for the
> source of that risk feels to me like (at best) stop energy[2] and (at
> worst) FUD.
>
>
> -Dave
>
>
> [1] 
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019203.html
> [2] 
> http://radio-weblogs.com/0107584/stories/2002/05/05/stopEnergyByDaveWiner.html
> (thanks to AJ who told me about stop energy one time when I was
> producing it)
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Billy Tetrud via bitcoin-dev]

> in the case of a multisig/non-consensus based system, exit from that
restriction is still possible

But why do we care if someone reduces the value of coins they own by
permanently encumbering them in some way? Burning coins permanently
encumbers them so much they can't be spent at all. If the worry is
depleting the supply of sats, don't worry, the amount of value lost by
those encumbered is gained but the rest of the coins. Just like burning,
encumbering your coins in a way that devalues them is a donation to the
rest of us.

Could you clarify what harm there is to those who choose not to accept such
encumbered coins? Or are you just saying that those who do accept such
encumbered coins may be harmed by doing so?

On Sat, Feb 12, 2022, 06:11 darosior via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Such a construct would present dangerous implications to the fungibility
> of individual UTXOs by introducing a totally different risk model in being
> paid with such a coin compared to any other coin not encumbered by such a
> condition
>
>
> How is that different from being paid in an altcoin?
> It seems to me that being able to say "sorry, your money isn't good here"
> is at the heart of Bitcoin's security (similarly to enforcing the network
> rules with your node). If someone can coerce you into using another
> currency, you've already lost.
>
> Now there is left the influence on the system of an user being coerced
> into using gov coin (on another chain) or an encumbered bit coin. Sure the
> latter would decrease the supply available, but that's already possible to
> do today.
>
> --- Original Message ---
> Le vendredi 11 février 2022 à 7:12 PM, digital vagabond via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> a écrit :
>
> This is Shinobi (can verify out of band at @brian_trollz on Twitter, I
> only signed up to the list with this email to read initially, but feel like
> I should reply to this as I think I am one of the only people in this space
> who has voiced concerns with recursive covenants).
>
> My concerns don't really center specifically around recursion itself
> necessarily, but unbounded recursion in combination with too much
> generality/flexibility in what types of conditions future UTXOs can be
> encumbered with based on the restriction of such covenants. Forgive the
> hand waiving arguments without getting into specific opcodes, but I would
> summarize my concerns with a hypothetical construct that I believe would be
> incredibly damaging to fungibility. 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. Such a construct would present
> dangerous implications to the fungibility of individual UTXOs by
> introducing a totally different risk model in being paid with such a coin
> compared to any other coin not encumbered by such a condition, and also
> potentially introduce a shift in the scope of what a 51% attack could
> accomplish in terms of permanent consequences attempting to coerce coins
> into such covenants, as opposed to right now only being able to accomplish
> censorship or temporary network disruption.
>
> 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 place they initially purchased from, as is demonstrated by the
> implementation of the Asset Management Platform by Blockstream for use on
> Liquid with regulated equity tokens, 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. If such a construct was
> possible to build with a recursive covenant enforced by consensus, coins
> encumbered by such a covenant would literally be incapable of escaping
> those restrictions without hardforking the protocol, leaving any such UTXOs
> permanently non-fungible with ones not encumbered by such conditions.
>
> I'm not that deeply familiar with all the working pieces involved in the
> recent TXHASH + CSFS proposal, and whether such a type of overly (IMO)
> generalized recursion would be possible to construct, but one of the
> reasons CTV does not bother me in terms of such concerns is the inability
> to infinitely recurse in such a generalized way given the requirements to
> exactly specify the destination of 

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[darosior via bitcoin-dev]

> Such a construct would present dangerous implications to the fungibility of 
> individual UTXOs by introducing a totally different risk model in being paid 
> with such a coin compared to any other coin not encumbered by such a condition

How is that different from being paid in an altcoin?
It seems to me that being able to say "sorry, your money isn't good here" is at 
the heart of Bitcoin's security (similarly to enforcing the network rules with 
your node). If someone can coerce you into using another currency, you've 
already lost.

Now there is left the influence on the system of an user being coerced into 
using gov coin (on another chain) or an encumbered bit coin. Sure the latter 
would decrease the supply available, but that's already possible to do today.

--- Original Message ---
Le vendredi 11 février 2022 à 7:12 PM, digital vagabond via bitcoin-dev 
 a écrit :

> This is Shinobi (can verify out of band at @brian_trollz on Twitter, I only 
> signed up to the list with this email to read initially, but feel like I 
> should reply to this as I think I am one of the only people in this space who 
> has voiced concerns with recursive covenants).
>
> My concerns don't really center specifically around recursion itself 
> necessarily, but unbounded recursion in combination with too much 
> generality/flexibility in what types of conditions future UTXOs can be 
> encumbered with based on the restriction of such covenants. Forgive the hand 
> waiving arguments without getting into specific opcodes, but I would 
> summarize my concerns with a hypothetical construct that I believe would be 
> incredibly damaging to fungibility. 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. Such a construct would present 
> dangerous implications to the fungibility of individual UTXOs by introducing 
> a totally different risk model in being paid with such a coin compared to any 
> other coin not encumbered by such a condition, and also potentially introduce 
> a shift in the scope of what a 51% attack could accomplish in terms of 
> permanent consequences attempting to coerce coins into such covenants, as 
> opposed to right now only being able to accomplish censorship or temporary 
> network disruption.
>
> 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 place they initially purchased from, as is demonstrated by the 
> implementation of the Asset Management Platform by Blockstream for use on 
> Liquid with regulated equity tokens, 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. If such a construct was 
> possible to build with a recursive covenant enforced by consensus, coins 
> encumbered by such a covenant would literally be incapable of escaping those 
> restrictions without hardforking the protocol, leaving any such UTXOs 
> permanently non-fungible with ones not encumbered by such conditions.
>
> I'm not that deeply familiar with all the working pieces involved in the 
> recent TXHASH + CSFS proposal, and whether such a type of overly (IMO) 
> generalized recursion would be possible to construct, but one of the reasons 
> CTV does not bother me in terms of such concerns is the inability to 
> infinitely recurse in such a generalized way given the requirements to 
> exactly specify the destination of future spends in constructing a chain of 
> CTV encumbrances. I'd very much appreciate any feedback on my concerns, and 
> if this side tracks the discussion I apologize, but I felt given the issue 
> has been mentioned a few times in this thread it was appropriate for me to 
> voice the concerns here so they could be addressed directly.
>
> On Fri, Feb 11, 2022 at 11:42 AM James O'Beirne via bitcoin-dev 
>  wrote:
>
>> I don't oppose recursive covenants per se, but in prior posts I have 
>> expressed uncertainty about proposals that enable more "featureful" 
>> covenants by adding more kinds of computation into bitcoin script.
>>
>> Not that anyone here is necessarily saying otherwise, but I am very 
>> interested in limiting operations in bitcoin script to "verification" (vs. 
>> "computation") to the extent practical, and instead 

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[James O'Beirne via bitcoin-dev]

I don't oppose recursive covenants per se, but in prior posts I have
expressed uncertainty about proposals that enable more "featureful"
covenants by adding more kinds of computation into bitcoin script.

Not that anyone here is necessarily saying otherwise, but I am very
interested in limiting operations in bitcoin script to "verification" (vs.
"computation") to the extent practical, and instead encouraging general
computation be done off-chain. This of course isn't a new observation and I
think the last few years have been very successful to that effect, e.g. the
popularity of the "scriptless scripts" idea and Taproot's emphasis on
embedding computational artifacts in key tweaks.

My (maybe unfounded?) worry about opcodes like OP_CAT and OP_TX is that
more logic will live in script than is necessary, and so the burden to
verify the chain may grow and the extra "degrees of freedom" in script may
make it harder to reason about. But I guess at this point there aren't
alternative means to construct new kinds of sighashes that are necessary
for some interesting covenants.

One thing I like about CTV is that it buys a lot of functionality without
increasing the "surface area" of script's design. In general I think there
is a lot to be said for this "jets"-style approach[0] of codifying the
script operations that you'd actually want to do into single opcodes. This
adds functionality while introducing minimal surface area to script, giving
script implementers more flexibility for, say, optimization. But of course
this comes at the cost of precluding experimentation, and probably
requiring more soft-forking. Though whether the place for script
experimentation using more general-purpose opcodes on the main chain is
another interesting debate...

Sorry for going a little off-topic there.

[0]: https://medium.com/blockstream/simplicity-jets-release-803db10fd589


On Thu, Feb 10, 2022 at 7:55 PM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Mon, Feb 07, 2022 at 08:34:30PM -0800, Jeremy Rubin via bitcoin-dev
> wrote:
> > Whether [recursive covenants] is an issue or not precluding this sort
> > of design or not, I defer to others.
>
> For reference, I believe the last time the merits of allowing recursive
> covenants was discussed at length on this list[1], not a single person
> replied to say that they were opposed to the idea.
>
> I would like to suggest that anyone opposed to recursive covenants speak
> for themselves (if any intelligent such people exist).  Citing the risk
> of recursive covenants without presenting a credible argument for the
> source of that risk feels to me like (at best) stop energy[2] and (at
> worst) FUD.
>
> -Dave
>
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019203.html
> [2]
> http://radio-weblogs.com/0107584/stories/2002/05/05/stopEnergyByDaveWiner.html
> (thanks to AJ who told me about stop energy one time when I was
> producing it)
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Jeremy Rubin via bitcoin-dev]

I don't have a specific response to share at this moment, but I may make
one later.

But for the sake of elevating the discourse, I'd encourage people
responding this to read through
https://rubin.io/bitcoin/2021/12/04/advent-7/ as I think it has some
helpful terminology and categorizations.

I bring this up because I think that recursion is often given as a
shorthand for "powerful" because the types of operations that support
recursion typically also introduce open ended covenants, unless they are
designed specially not to. As a trivial example a covenant that makes a
coin spendable from itself to itself entirely with no authorization is
recursive but fully enumerated in a sense and not particularly interesting
or useful.

Therefore when responding you might be careful to distinguish if it is just
recursion which you take issue with or open ended or some combination of
properties which severally might be acceptable.

TL;DR there are different properties people might care about that get
lumped in with recursion, it's good to be explicit if it is a recursion
issue or something else.

Cheers,

Jeremy


On Thu, Feb 10, 2022, 4:55 PM David A. Harding  wrote:

> On Mon, Feb 07, 2022 at 08:34:30PM -0800, Jeremy Rubin via bitcoin-dev
> wrote:
> > Whether [recursive covenants] is an issue or not precluding this sort
> > of design or not, I defer to others.
>
> For reference, I believe the last time the merits of allowing recursive
> covenants was discussed at length on this list[1], not a single person
> replied to say that they were opposed to the idea.
>
> I would like to suggest that anyone opposed to recursive covenants speak
> for themselves (if any intelligent such people exist).  Citing the risk
> of recursive covenants without presenting a credible argument for the
> source of that risk feels to me like (at best) stop energy[2] and (at
> worst) FUD.
>
> -Dave
>
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019203.html
> [2]
> http://radio-weblogs.com/0107584/stories/2002/05/05/stopEnergyByDaveWiner.html
> (thanks to AJ who told me about stop energy one time when I was
> producing it)
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[David A. Harding via bitcoin-dev]

On Mon, Feb 07, 2022 at 08:34:30PM -0800, Jeremy Rubin via bitcoin-dev wrote:
> Whether [recursive covenants] is an issue or not precluding this sort
> of design or not, I defer to others.

For reference, I believe the last time the merits of allowing recursive
covenants was discussed at length on this list[1], not a single person
replied to say that they were opposed to the idea.

I would like to suggest that anyone opposed to recursive covenants speak
for themselves (if any intelligent such people exist).  Citing the risk
of recursive covenants without presenting a credible argument for the
source of that risk feels to me like (at best) stop energy[2] and (at
worst) FUD.

-Dave

[1] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019203.html
[2] 
http://radio-weblogs.com/0107584/stories/2002/05/05/stopEnergyByDaveWiner.html
(thanks to AJ who told me about stop energy one time when I was
producing it)



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