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
> 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,
> "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
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
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
@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
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
> 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
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
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
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
@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
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
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
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
> 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
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
@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
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
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
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
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,
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.
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,
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
>
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
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
> 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
> 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
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
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
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
32 matches
Mail list logo
