> CTV DLCs are non-interactive asynchronously third-party unilaterally
creatable.
This is super interesting. I think that would make it easier to do
multi-party DLCs. With a "normal" DLC, you need to have N parties
exchanging and signing CETs and you end up with a combinatorial explosion
of
Apologies for the double post*, but I just had a follow up idea
that's pretty interesting to me.
You can make the close portion of a DLC be an "optimistic" execution with a
choice of justice scheme. This enables closing a DLC somewhat securely
without exposing the oracles on-chain at all.
Lloyd,
This is an excellent write up, the idea and benefits are clear.
Is it correct that in the case of a 3/5th threshold it is a total 10x * 30x
= 300x improvement? Quite impressive.
I have a few notes of possible added benefits / features of DLCs with CTV:
1) CTV also enables a "trustless
Thibaut,
CSFS might have independent benefits, but in this case CTV is not being
used in the Oracle part of the DLC, it's being used in the user generated
mapping of Oracle result to Transaction Outcome.
So it'd only be complimentary if you came up with something CSFS based for
the Oracles.
I probably need to reset it -- I ran into some issues with the IBD latch
bug IIRC and had difficulty producing new blocks.
I sent funds as a manual faucet to at least one person... not aware of
anyone else finding use for the signet. In part this is due to the fact
that in order to run a signet,
> what is the incentive for the honest party to punish?
Justice. Also, there's no incentive for the honest party to not punish -
presumably their software would automatically punish, and why go through
any effort to stop it? A 1 cent bribe certainly wouldn't be enough. Maybe a
$10 bribe might get
> Technical debt isn't a measure of weight of transactions.
Sorry, my original sentence was a little unclear. I meant to say that the
notion that CTV is just a subpar waypoint en route to a more general
covenant system may not be accurate if it is a more efficient way (in terms
of
On Fri, Jan 28, 2022 at 01:14:07PM +, Michael Folkson via bitcoin-dev wrote:
> There is not even a custom signet with CTV (as far as I know)
https://twitter.com/jeremyrubin/status/1339699281192656897
signetchallenge=512102946e8ba8eca597194e7ed90377d9bbebc5d17a9609ab3e35e706612ee882759351ae
On Thu, Jan 27, 2022 at 7:19 PM James O'Beirne
wrote:
> > I don't think implementing a CTV opcode that we expect to largely be
> obsoleted by a TXHASH at a later date is yielding good value from a soft
> fork process.
>
> This presumes the eventual adoption of TXHASH (or something like it).
>
On Thu, Jan 27, 2022 at 8:34 PM Anthony Towns wrote:
> > An Alternative Proposal::
> > ...
>
> > For similar reasons, TXHASH is not amenable to extending the set of
> txflags
> > at a later date.
>
> > I believe the difficulties with upgrading TXHASH can be mitigated by
> > designing a robust
> Even if we were to adopt something like TXHASH, how long is it going to take
> to develop, test, and release? My guess is "a while" - in the meantime, users
> of Bitcoin are without a vault strategy that doesn't require either
> presigning transactions with ephemeral keys (operationally
> I don't think implementing a CTV opcode that we expect to largely be
obsoleted by a TXHASH at a later date is yielding good value from a soft
fork process.
This presumes the eventual adoption of TXHASH (or something like it).
You're presenting a novel idea that, as far as I know, hasn't had
12 matches
Mail list logo
