From: Antoine Riard <antoine.riard@gmail•com>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] On a new community process to specify covenants
Date: Mon, 25 Jul 2022 23:20:31 -0400 [thread overview]
Message-ID: <CALZpt+GPNQU6MdFgWZwJwGpLw1X36dhT0sqoY4deS7SYNWiwWA@mail.gmail.com> (raw)
In-Reply-To: <0tp0SQgSX6kVG84bQ6fk7umnv3IaC2Nx6leiGYxhayz2HCQymAuBJxaODFijqLPP0nJ1b41wE4wlC-0_H8eN2GadtVEqGBGWGlzuMtfjhDo=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 5754 bytes --]
Hi Zeeman,
So on the first concern of using an "economic simulation" or
sidechains/other cryptocurrencies to gather feedback about interest of
Script extensions, I wonder about the value transitivity of such a process
to measure consensus. Namely, if you have asset X picked up in system A, it
doesn't tell you the same asset X is preferred in system B, unless I think
you have the same agent. However, in cryptocurrencies, at least in Bitcoin,
we assume pseudonymous participants. So it can be really hard to say it's
the same agent to qualify its utility. Of course, you could have some
linking between system A and system B, like signatures if the same signing
scheme is used. However if it's possible why not use direct assets in
system B to express a preference ? Maybe in the future if we have a
privacy-preserving coins ownership proof system we could use that as one
consensus indicator [0] ?
At least in terms of community decision-making, the more we have
trust-minimized data signals, _assuming_ we have the information
capabilities to process them, the better we're.
That said, about the covenant working group/process I'm proposing I would
like to stay on the use-cases collection, deep trade-offs analysis and
adequate covenant designs grounds.
Activation really should be its own dedicated process, well-splitted in
terms of communication channels, documentation archive and timeframes.
About a generic contracting platform approach, I think for sure it would be
a huge gain in flexibility for multi-party contract protocols design though
there is at least three caveats in my opinion 1) we might open a Pandora
Box enabling one to design trustless bribing contracts towards miners to
attack existent deployed Bitcoin use-cases like Lightning (not a
theoretical concern at all when we look on the wild west of Defi in other
cryptocurrencies) 2) the multi-party contract protocol problem space is
relatively early, we might evolve the primitive abstraction with which
we're dealing and the language itself should evolve 3) we might still have
to do a lot of economic engineering if the microcode operations or syntax
units of the language are bounding well to validation nodes ressources.
So IMHO, a lot of unknowns about a generic contracting platform (even if
it's tempting from an application developer viewpoint I know)
[0]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002884.html
[1] For example an input-output bundle abstraction might be better for
fee-bumping reasons:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html
Le dim. 24 juil. 2022 à 19:40, ZmnSCPxj <ZmnSCPxj@protonmail•com> a écrit :
> Good morning alia, Antoine, and list,
>
> > Hi Antoine,
> > Claiming Taproot history, as best practice or a standard methodology in
> bitcoin development, is just too much. Bitcoin development methodology is
> an open problem, given the contemporary escalation/emergence of challenges,
> history is not entitled to be hard coded as standard.
> >
> > Schnorr/MAST development history, is a good subject for case study, but
> it is not guaranteed that the outcome to be always the same as your take.
> >
> > I'd suggest instead of inventing a multi-decades-lifecycle based
> methodology (which is weird by itself, let alone installing it as a
> standard for bitcoin projects), being open-mind enough for examining more
> agile approaches and their inevitable effect on the course of discussions,
>
> A thing I have been mulling is how to prototype such mechanisms more
> easily.
>
> A "reasonably standard" approach was pioneered in Elements Alpha, where an
> entire federated sidechain is created and then used as a testbed for new
> mechanisms, such as SegWit and `OP_CHECKSIGFROMSTACK`.
> However, obviously the cost is fairly large, as you need an entire
> federated sidechain.
>
> It does have the nice advantage that you can use "real" coins, with real
> value (subject to the federation being trustworthy, admittedly) in order to
> convincingly show a case for real-world use.
>
> As I pointed out in [Smart Contracts Unchained](
> https://zmnscpxj.github.io/bitcoin/unchained.html), an alternative to
> using a blockchain would be to use federated individual coin outpoints.
>
> A thing I have been pondering is to create a generic contracting platform
> with a richer language, which itself is just used to implement a set of
> `OP_` SCRIPT opcodes.
> This is similar to my [Microcode proposal](
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020158.html)
> earlier this year.
> Thus, it would be possible to prototype new `OP_` codes, or change the
> behavior of existing `OP_` codes (e.g. `SIGHASH_NOINPUT` would be a change
> in behavior of existing `OP_CHECKSIG` and `OP_CHECKMULTISIG`), by having a
> translation from `OP_` codes to the richer language.
> Then you could prototype a new SCRIPT `OP_` code by providing your own
> translation of the new `OP_` code and a SCRIPT that uses that `OP_` code,
> and using Smart Contract Unchained to use a real funds outpoint.
>
> Again, we can compare the Bitcoin consensus layer to a form of hardware:
> yes, we *could* patch it and change it, but that requires a ***LOT*** of
> work and the new software has to be redeployed by everyone, so it is,
> practically speaking, hardware.
> Microcode helps this by adding a softer layer without compromising the
> existing hard layer.
>
> So... what I have been thinking of is creating some kind of smart
> contracts unchained platform that allows prototyping new `OP_` codes using
> a microcode mechanism.
>
> Regards,
> ZmnSCPxj
>
[-- Attachment #2: Type: text/html, Size: 6511 bytes --]
next prev parent reply other threads:[~2022-07-26 3:20 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-20 20:42 Antoine Riard
2022-07-23 5:09 ` Ryan Grant
2022-07-23 14:57 ` Antoine Riard
2022-07-23 14:25 ` Michael Folkson
2022-07-23 16:41 ` Antoine Riard
2022-07-24 13:01 ` aliashraf.btc At protonmail
2022-07-24 23:40 ` ZmnSCPxj
2022-07-26 3:20 ` Antoine Riard [this message]
2022-07-26 3:18 ` Antoine Riard
2022-07-24 18:22 ` Bram Cohen
2022-07-24 20:26 ` aliashraf.btc At protonmail
2022-07-26 3:21 ` Antoine Riard
2022-07-26 16:02 ` Bram Cohen
2022-08-03 15:37 ` Billy Tetrud
2022-08-09 20:15 ` Antoine Riard
2022-08-27 21:01 ` Billy Tetrud
2022-08-30 15:46 ` Antoine Riard
2022-09-10 0:10 ` Antoine Riard
2022-10-07 15:33 ` Antoine Riard
2022-09-12 0:05 Buck O Perley
2022-09-13 16:02 ` Ryan Grant
2022-09-15 8:05 ` Devrandom
2022-09-16 19:08 ` Antoine Riard
2022-09-16 18:59 ` Antoine Riard
2022-09-17 7:52 ` Devrandom
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALZpt+GPNQU6MdFgWZwJwGpLw1X36dhT0sqoY4deS7SYNWiwWA@mail.gmail.com \
--to=antoine.riard@gmail$(echo .)com \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox