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] A Comparison Of LN and Drivechain Security In The Presence Of 51% Attackers

[Paul Sztorc via bitcoin-dev]

Not bad, but not particularly good either.

Definitely correct:
  1  (plus extra credit, it was originally 1008+2016),
  3a "whales"
  3b (atomic swaps is the "official" answer, but otc trading is also 
acceptable, or just "trade" in general)

  6
  9  part one

Close, but not quite right:
  2  (part one "~4" is correct, but you didn't answer part two)
  3a "attacker- miners" is not the way I see it at all
  3c true, but I was talking about withdrawal security, not hashrate, 
[this is related to the 3a "attacker miners" mis-answer]
  4  ? you seem to have not very seriously answered this. The 
parameters are spelled out in the original Nov 2015 post


Some kind of miscommunication may have happened:
  8 -- I was more thinking, what happens if the UASF fails (in 
thwarting miners) vs succeeds. (I take it for granted that non-DC users 
will prefer to do nothing, and prefer to be unaffected.)


Seems wrong to me:
  0  seems like a pretty big misunderstanding happened here, or else 
you mistakenly typo'd the wrong word
  5  (you started with m=1 examples, which is not what was requested; 
and finished with something not a sidechain attribute)

  7  [related to the miss on #5] ; it is not a re-ask of question #0
  9  part two is wrong
 10  you did not answer

Paul


On 2/26/2022 2:39 AM, ZmnSCPxj wrote:

Good morning Paul,



I don't think I can stop people from being ignorant about Drivechain. But I can 
at least allow the Drivechain-knowledgable to identify each other.

So here below, I present a little "quiz". If you can answer all of these 
questions, then you basically understand Drivechain:

0. We could change DC to make miner-theft impossible, by making it a layer1 
consensus rule that miners never steal. Why is this cure worse than the disease?

Now miners are forced to look at all sideblocks, not optionally do so if it is 
profitable for them.


1. If 100% hashrate wanted to steal coins from a DC sidechain *as quickly as 
possible*, how long would this take (in blocks)?

13,150 (I think this is how you changed it after feedback from this list, I 
think I remember it was ~3000 before or thereabouts.)


2. Per sidechain per year (ie, per 52560 blocks), how many DC withdrawals can 
take place (maximum)? How many can be attempted?
  (Ie, how does the 'train track metaphor' work, from ~1h5m in the "Overview and 
Misconceptions" video)?

I hate watching videos, I can read faster than anyone can talk (except maybe 
Laolu, he speaks faster than I can process, never mind read).

~4 times (assuming 52560 block per year, which may vary due to new miners, 
hashrate drops, etc)


3. Only two types of people should ever be using the DC withdrawal system at 
all.
   3a. Which two?

a.  Miners destroying the sidechain because the sidechain is no longer viable.
b.  Aggregators of sidechain-to-minechain transfers and large whales.


   3b. How is everyone else, expected to move their coins from chain to chain?

Cross-system atomic swaps.
(I use "System" here since the same mechanism works for Lightning channels, and 
channels are not blockchains.)


   3c. (Obviously, this improves UX.) But why does it also improve security?

Drivechain-based pegged transfers are aggregates of many smaller transfers and thus every 
transfer out from the sidechain contributes its "fee" to the security of the 
peg.


--
4. What do the parameters b and m stand for (in the DC security model)?

m is how much people want to kill a sidechain, 0 = everybody would be sad if it 
died and would rather burn all their BTC forever than continue living, 1 = do not 
care, > 1 people want to actively kill the sidechain.

b is how much profit a mainchain miner expects from supporting a sidechain (do 
not remember the unit though).
Something like u = a + b where a is the mainchain, b is the sidechain, u is the 
total profit.
Or fees?  Something like that.


5. How can m possibly be above 1? Give an example of a sidechain-attribute 
which may cause this situation to arise.

The sidechain is a total scam.
A bug may be found in the sidechain that completely negates any security it 
might have, thus removing any desire to protect the sidechain and potentially 
make users want to destroy it completely rather than let it continue.
People end up hating sidechains completely.


6. For which range of m, is DC designed to deter sc-theft?

m <= 1


7. If DC could be changed to magically deter theft across all ranges of m, why 
would that be bad for sidechain users in general?

Because the sidechain would already be part of mainchain consensus.


--
8. If imminent victims of a DC-based theft, used a mainchain UASF to prohibit 
the future theft-withdrawal, then how would this affect non-DC users?

If the non-DC users do not care, then they are unaffected.
If the non-DC users want to actively kill the sidechain, they will 
counterattack with an opposite UASF and we have a chainsplit and sadness and 
mutual destruction and death and a new subreddit.


9. In what 

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] A Comparison Of LN and Drivechain Security In The Presence Of 51% Attackers

[Billy Tetrud via bitcoin-dev]

> m is how much people want to kill a sidechain, 0 = everybody would be sad
if it died and would rather burn all their BTC forever than continue living

Math is brutal

On Sat, Feb 26, 2022, 01:39 ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> Good morning Paul,
>
>
> > I don't think I can stop people from being ignorant about Drivechain.
> But I can at least allow the Drivechain-knowledgable to identify each other.
> >
> > So here below, I present a little "quiz". If you can answer all of these
> questions, then you basically understand Drivechain:
> >
> > 0. We could change DC to make miner-theft impossible, by making it a
> layer1 consensus rule that miners never steal. Why is this cure worse than
> the disease?
>
> Now miners are forced to look at all sideblocks, not optionally do so if
> it is profitable for them.
>
> > 1. If 100% hashrate wanted to steal coins from a DC sidechain *as
> quickly as possible*, how long would this take (in blocks)?
>
> 13,150 (I think this is how you changed it after feedback from this list,
> I think I remember it was ~3000 before or thereabouts.)
>
> > 2. Per sidechain per year (ie, per 52560 blocks), how many DC
> withdrawals can take place (maximum)? How many can be attempted?
> >  (Ie, how does the 'train track metaphor' work, from ~1h5m in the
> "Overview and Misconceptions" video)?
>
> I hate watching videos, I can read faster than anyone can talk (except
> maybe Laolu, he speaks faster than I can process, never mind read).
>
> ~4 times (assuming 52560 block per year, which may vary due to new miners,
> hashrate drops, etc)
>
> > 3. Only two types of people should ever be using the DC withdrawal
> system at all.
> >   3a. Which two?
>
> a.  Miners destroying the sidechain because the sidechain is no longer
> viable.
> b.  Aggregators of sidechain-to-minechain transfers and large whales.
>
> >   3b. How is everyone else, expected to move their coins from chain to
> chain?
>
> Cross-system atomic swaps.
> (I use "System" here since the same mechanism works for Lightning
> channels, and channels are not blockchains.)
>
> >   3c. (Obviously, this improves UX.) But why does it also improve
> security?
>
> Drivechain-based pegged transfers are aggregates of many smaller transfers
> and thus every transfer out from the sidechain contributes its "fee" to the
> security of the peg.
>
> > --
> > 4. What do the parameters b and m stand for (in the DC security model)?
>
> m is how much people want to kill a sidechain, 0 = everybody would be sad
> if it died and would rather burn all their BTC forever than continue
> living, 1 = do not care, > 1 people want to actively kill the sidechain.
>
> b is how much profit a mainchain miner expects from supporting a sidechain
> (do not remember the unit though).
> Something like u = a + b where a is the mainchain, b is the sidechain, u
> is the total profit.
> Or fees?  Something like that.
>
> > 5. How can m possibly be above 1? Give an example of a
> sidechain-attribute which may cause this situation to arise.
>
> The sidechain is a total scam.
> A bug may be found in the sidechain that completely negates any security
> it might have, thus removing any desire to protect the sidechain and
> potentially make users want to destroy it completely rather than let it
> continue.
> People end up hating sidechains completely.
>
> > 6. For which range of m, is DC designed to deter sc-theft?
>
> m <= 1
>
> > 7. If DC could be changed to magically deter theft across all ranges of
> m, why would that be bad for sidechain users in general?
>
> Because the sidechain would already be part of mainchain consensus.
>
> > --
> > 8. If imminent victims of a DC-based theft, used a mainchain UASF to
> prohibit the future theft-withdrawal, then how would this affect non-DC
> users?
>
> If the non-DC users do not care, then they are unaffected.
> If the non-DC users want to actively kill the sidechain, they will
> counterattack with an opposite UASF and we have a chainsplit and sadness
> and mutual destruction and death and a new subreddit.
>
> > 9. In what ways might the BTC network one day become uncompetitive? And
> how is this different from caring about a sidechain's m and b?
>
> If it does not enable scaling technology fast enough to actually be able
> to enable hyperbitcoinization.
>
> Sidechains are not a scaling solution, so caring about m and b is
> different because your focus is not on scaling.
>
> > --
> > 10. If DC were successful, Altcoin-investors would be harmed. Two
> Maximalist-groups would also be slightly harmed -- who are these?
>
> Dunno!
>
>
> Regards,
> ZmnSCPxj
> ___
> 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

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] Documenting the lifetime of a transaction during mempool congestion from the perspective of a rational user

[Billy Tetrud via bitcoin-dev]

The crux of the type of situation you're talking about is where a source
that might revert their payment by rbf double spending sends you money. You
mentioned this situation is "not unlikely". What kind of prevalence does
this happen with today?

Also my question is, if you've been paid by someone like this, what right
do you really have to this money? Is the other side buying something from
you? No one should be considering something actually bought unless it's got
sufficient confirmations. Anyone following that rule isn't losing anything
by simply waiting for the transaction to confirm. If the transaction is
double spent, who cares?

This seems like a situation where adding software and ui complexity is not
worth it to reach the maximization you're talking about. It feels more like
opportunistic stealing than actual commerce. Maybe it would be a social
good to prevent attempted scammers from scamming people, but the only
people who would be affected are 0 conf people. And that problem can be
solved much more easily and generally (eg by clear messaging around
transaction finalization) than by complicating coin selection.

On Thu, Jan 13, 2022, 15:07 Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Devs,
>
> This email is primarily about existing wallet behaviors and user
> preferences, and not about CTV. However, towards the end I will describe
> the relevance of CTV, but the email is worth reading even if you have no
> interest in CTV as the problems described exist today.
>
> One point of confusion I've seen while discussing CTV based congestion
> control is that it requires a bunch of new wallet software.
>
> Most of the software requirements that would make CTV work well are things
> that either already exist in Bitcoin Core, or are 'bugs' (where bug is
> defined as deviation from rational utility maximizing behavior) that should
> be fixed *whether or not CTV exists.*
>
> In this post, I am going to walk through what I expect rational behavior
> to be for a not unlikely circumstance.
>
> First, let's define what rational behavior for a wallet is. A rational
> wallet should have a few goals:
>
> 1) Maximize 'fully trusted' balance (fully confirmed + unconfirmed change
> outputs from our own txns)
> 2) Process payments requested by the owner within the "urgency budget"
> requested by the user.
> 3) Maximize "privacy" (this is a vague goal, so we'll largely ignore it
> here.).
>
> Rational wallet behavior may not be possible without metadata. For
> example, a rational wallet might prompt the user for things like "how much
> do you trust the sender of this payment to not RBF this transaction?", or
> "how much do you trust this sender to not double spend you?". For example,
> a self-transfer from cold wallet to hot wallet could have a trust score of
> 1, whereas a payment from an anonymous source would have a trust score of
> 0. Exchanges where you have a legal agreement to not RBF might sit
> somewhere in between. Other pieces of exogenous information that could
> inform wallet behavior include "has hashrate decreased recently, making
> longer reorgs likely".
>
> In the model above, a user does not request transactions, they request
> payments. The rational wallet serves as an agent to assist the user in
> completing these payments. For example, if I have a wallet with a single
> unconfirmed output, and I spend from it to pay Alice, if the unconfirmed
> gets replaced, my wallet should track that it was replaced and prompt me to
> re-sign a new transaction. Rational wallets that maximize balance should be
> careful to ensure that replaced payments are exclusive, guaranteed either
> through sufficient confirmations or 'impossibility proofs' by reusing an
> input (preventing double-send behavior).
>
> -
>
> Now that we've sketched out a basic framework for what a rational wallet
> should be doing, we can describe what the process of receiving a payment is.
>
> Suppose I have a wallet with a bevy of fully confirmed coins such that for
> my future payments I am sufficiently funded.
>
> Then, I receive a payment from a highly trusted source (e.g., self
> transfer) that is unconfirmed.
>
> I then seek to make an outgoing payment. I should have no preference
> towards or against spending the unconfirmed transfer, I should simply
> account for it's cost in coin selection of CPFP-ing the parent transaction.
> If fees are presently historically low, I may have a preference to spend it
> so as to not have a higher fee later (consolidation).
>
> Later, I receive payment from an untrusted source (e.g., an anonymous
> donation to me). I have no reason to trust this won't be double spent.
> Perhaps I can even observe that this output has been RBF'd many times
> previously. I do not count on this money arriving. The feerate on the
> transaction suggests it won't be confirmed immediately.
>
> In order to maximize balance, I should prioritize spending from this
> output