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,
A couple of features we are considering for the mercury statechain
wallet/service and would be good to get comments/feedback on.
1.
In the current setup (https://github.com/commerceblock/mercury), deposits
are free and permissionless (i.e. no authentication required to generate a
shared key
This is my first time submitting anything to this mailer list, so I am here
with humility and I would appreciate any feedback about any aspect of my
BIP draft submission below. If you want to reach out to me directly you can
email me at as...@seent.com.
Abstract
Rather than having a maximum
> "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 aj,
> On Sun, Feb 27, 2022 at 04:34:31PM +, ZmnSCPxj via bitcoin-dev wrote:
>
> > In reaction to this, AJ Towns mailed me privately about some of his
> > thoughts on this insane `OP_EVICT` proposal.
> > He observed that we could generalize the `OP_EVICT` opcode by
> >
On Fri, Mar 04, 2022 at 11:21:41PM +, Jeremy Rubin via bitcoin-dev wrote:
> I've seen some discussion of what the Annex can be used for in Bitcoin.
https://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-12-19.00.log.html
includes some discussion on that topic
Good morning Jeremy,
Umm `OP_ANNEX` seems boring
> It seems like one good option is if we just go on and banish the OP_ANNEX.
> Maybe that solves some of this? I sort of think so. It definitely seems like
> we're not supposed to access it via script, given the quote from above:
>
>
I've seen some discussion of what the Annex can be used for in Bitcoin. For
example, some people have discussed using the annex as a data field for
something like CHECKSIGFROMSTACK type stuff (additional authenticated data)
or for something like delegation (the delegation is to the annex). I think
Good morning Chris,
Quick question.
How does this improve over just handing over `nLockTime`d transactions?
Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
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
11 matches
Mail list logo
