I should clarify: the current proposal already achieves the first part
needed for coin pools: removing some data from the merkle tree (I was
indeed referring to the embedded data, not the taptree).
The thing that is missing is removal of a public key from the taproot
internal key, but as
Hi Johan,
Exciting to finally see some merkleization, which was only confined
within the meme, up to this point!
> A simpler way IMO, would be to make OP_CICV and OP_COCV symmetrical:
> Have OP_CICV take an optional taproot and do the same check as is
> done for the output: Q ==
Hi, Salvatore.
As a further exploration of this idea, I implemented a
proof-of-concept of OP_CICV and OP_COCV in btcd[1] that together with
OP_CAT enables a set of interesting use cases.
One such use case is, as mentioned earlier, CoinPools[2]. The opcodes
let you easily check the "dynamically
On Thu, 4 May 2023 at 10:34, Johan Torås Halseth wrote:
>
> It sounds like we can generalize the description of the construct to:
> Access to (the hash of) embedded data of inputs and outputs, and the
> enforcement of output keys and (static) taptrees. In other words, as
> long as you can
Thank you for the example.
It sounds like we can generalize the description of the construct to:
Access to (the hash of) embedded data of inputs and outputs, and the
enforcement of output keys and (static) taptrees. In other words, as
long as you can dynamically compute the output embedded data
Hi all,
I apologize for a couple of oversights in my last e-mail.
The first is that m_B can't be committed as-is in the contract's
embedded data, with the current semantics of OP_COCV, which
only allows 32-byte values. A solution could be to store its
hash SHA256(m_B), instead.
(I didn't test
Hi Johan,
Thanks for your message.
I think games where all the possible futures can be enumerated are
not ideal to showcase MATT, as one could just fully represent them
with just CTV or COCV, and not use the "data embedding" at all.
Perhaps rock-paper-scissors could be a better academic
Hi, Salvatore.
I find this proposal very interesting. Especially since you seemingly
can achieve such powerful capabilities by such simple opcodes.
I'm still trying to grok how this would look like on-chain (forget
about the off-chain part for now), if we were to play out such a
computation.
Re Verkle trees, that's a very interesting construction that would be super
useful as a tool for something like Utreexo. A potentially substantial
downside is that it seems the cryptography used to get those nice
properties of Verkle trees isn't quantum safe
Hello Rijndael,
On Wed, 30 Nov 2022 at 23:09, Rijndael wrote:
> Hello Salvatore,
>
> I found my answer re-reading your original post:
> > During the arbitration phase (say at the i-th leaf node of M_T), any
> party can win the challenge by providing correct values for tr_i = (st_i,
> op_i,
Hello Salvatore,
I found my answer re-reading your original post:
> During the arbitration phase (say at the i-th leaf node of M_T), any party
> can win the challenge by providing correct values for tr_i = (st_i, op_i,
> st_{i + 1}). Crucially, only one party is able to provide correct values,
Hello Salvatore,
Really interesting idea. The walk-through of the challenge protocol helped.
In the final state:
[S14. state: h_{A;6}, h_{B;6}]
- Alice can take all the money if she can open h_{A;6} to a correct "n => n +
n" computation step
- Bob can take all the money if he can open h_{B;6}
Hi Antoine,
It appears that my explanation of the relationship between the covenant and
the bisection protocol is still unclear; I'll do my best to clarify.
The bisection's Merkle tree never ends up on-chain, in any form. Therefore,
a bigger computation does not end up in a bigger witness size,
Hi Salvatore,
Thanks for bringing forward this MATT proposal!
Here my (rough) understanding of the protocol, the participants decompose
the entire computation into a number N of steps, each assigned a tapleaf,
each computation is a triplet (state_start, operation, state_end), the
tapleaves are
Hi ZmnSCPxj, Bram, Peter, David,
Thanks for all your comments; replies below.
On Tue, 8 Nov 2022 at 13:01, ZmnSCPxj wrote:
> Modulo bugs, operator error, misconfigurations, and other irrationalities
> of humans.
>
I agree that making footguns impossible is a much more difficult problem to
On 2022-11-07 23:17, Salvatore Ingala via bitcoin-dev wrote:
Hi list,
Hi Salvatore!,
I have been working on some notes to describe an approach that uses
covenants in order to enable general smart contracts in bitcoin. You
can find them here:
https://merkle.fun
I haven't yet been able
On Tue, Nov 08, 2022 at 03:34:32PM -0800, Bram Cohen via bitcoin-dev wrote:
> Another probably unhelpful bit of feedback I have is that Bitcoin should
> probably be taking verkle trees seriously because those can have
> substantially lower size/cost/weight than merkle trees. That doesn't just
>
On Tue, Nov 8, 2022 at 2:13 AM Salvatore Ingala via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> I have been working on some notes to describe an approach that uses
> covenants in order to enable general smart contracts in bitcoin. You can
> find them here:
>
>
Good morning Salvatore,
Interesting idea.
The idea to embed the current state is similar to something I have been musing
about recently.
> ### Game theory (or why the chain will not see any of this)
>
> With the right economic incentives, protocol designers can guarantee that
> playing a
Hi list,
I have been working on some notes to describe an approach that uses
covenants in order to enable general smart contracts in bitcoin. You can
find them here:
https://merkle.fun
The approach has a number of desirable features:
- small impact to layer 1;
- not application-specific,
20 matches
Mail list logo
