Hi Salvatore,
Thanks for the additional insights.
> At this time, my goal is to facilitate maximum experimentation; it's safe
to open Pandora's box in a sandbox, as that's the only way to know if it's
empty.
> Concerns will of course need to be answered when a soft-fork proposal is
made, and rest
Hi Symphonic,
I'm not aware of any theory of the "mining firm" (in the coasian sense)
that would give the lineaments of the cost / income structure of a lambda
mining operation, and from which to predict how a change in the withhold
mined coins impact the long-term sustainability of their business
Hi Antoine,
It is important to consider that miners are not always incentivized by what
brings them the most profit in the moment, but also their long-term prospects.
If they begin participating in transaction censorship, they open the
possibility of reducing the value of the coins they mine an
Hi Symphonic,
>From a game-theory viewpoint where we define among other players utility
functions, set of moves, rules of the games and pattern of information, I
don't think oracles can be mathematically reduced to miners.
Miners are competing to generate a proof-of-work on a set of transactions.
Hi Antoine,
Thanks for your comments and insights.
On Mon, 14 Aug 2023 at 05:01, Antoine Riard wrote:
> I think cross-input inspection (not cross-input signature
> aggregation which is different) is opening a pandora box in terms of
> "malicious" off-chain contracts than one could design. E.g m
> I think cross-input inspection (not cross-input signature aggregation which
> is different) is opening a pandora box in terms of "malicious" off-chain
> contracts than one could design. E.g miners bribing contracts to censor the
> confirmation of time-sensitive lightning channel transactions,
Hi Salvatore,
> This also allows inspection of other inputs, that was not possible with
the original opcodes.
I think cross-input inspection (not cross-input signature aggregation which
is different) is opening a pandora box in terms of "malicious" off-chain
contracts than one could design. E.g m
Hi Johan,
Thanks a lot for the comments, and the independent implementation!
> - For the opcode parameter ordering, it feels unnatural for the two
> tweaks (data, taptree) to be separated by the internal key. A more
> natural ordering of parameters IMO would be (of course this is all
> subjective
Hi, Salvatore.
Thanks for the update! I like the fact that taptree verification now
can be done on both input and outputs, and having them be symmetrical
also makes the learning curve a bit easier.
I have implemented the updated opcodes in btcd (very rough
implementation)]1] as well as updated th
Hi Dave,
I apologize for the confusion and the inconsistent use of plurals.
The reason I called it a "complete proposal" is that the opcode is
now functionally complete, unlike the previous attempt where the
approach for the output amount introspection was not yet specified.
The semantics are inf
On July 30, 2023 11:37:49 AM HST, Salvatore Ingala via bitcoin-dev
>I have put together a first complete proposal for the core opcodes of
>MATT [1][2].
>The changes make the opcode functionally complete, and the
>implementation is revised and improved.
> [...]
>[1] - https://merkle.fun/
>[2] -
>
Hi all,
I have put together a first complete proposal for the core opcodes of
MATT [1][2].
The changes make the opcode functionally complete, and the
implementation is revised and improved.
The code is implemented in the following fork of the
bitcoin-inquisition repo:
https://github.com/Merkleiz
12 matches
Mail list logo
