After getting neutral to negative feedback on the choice, I have switched
to OP_TRUE on the BIP and implementation.
Cheers,
Greg
On Sat, Feb 4, 2023 at 11:03 AM Peter Todd wrote:
> On Fri, Feb 03, 2023 at 09:07:29PM -0500, Greg Sanders wrote:
> > I'm not particularly persuaded, but also not
On Fri, Feb 03, 2023 at 09:07:29PM -0500, Greg Sanders wrote:
> I'm not particularly persuaded, but also not wedded to either idea.
>
> Fixed up tests for the OP_TRUE case here:
> https://github.com/instagibbs/bitcoin/tree/ephemeral-anchors-true
Thanks.
Looking through that, I think a lot of
I'm not particularly persuaded, but also not wedded to either idea.
Fixed up tests for the OP_TRUE case here:
https://github.com/instagibbs/bitcoin/tree/ephemeral-anchors-true
On Fri, Feb 3, 2023 at 5:10 PM Peter Todd wrote:
> On Thu, Feb 02, 2023 at 03:47:28PM -0500, Greg Sanders wrote:
> > >
On Thu, Feb 02, 2023 at 03:47:28PM -0500, Greg Sanders wrote:
> > OP_TRUE is the obvious way to do this, and it results with a 1 on the
> stack,
> which plays better with other standardness rules.
>
> What other standardness rules? MINAMALIF? How does that interact with the
> proposal?
It makes
> OP_TRUE is the obvious way to do this, and it results with a 1 on the
stack,
which plays better with other standardness rules.
What other standardness rules? MINAMALIF? How does that interact with the
proposal?
On Thu, Feb 2, 2023 at 3:22 PM Peter Todd wrote:
> On Thu, Feb 02, 2023 at
On Thu, Feb 02, 2023 at 01:36:24PM -0500, Greg Sanders wrote:
> Quickly checked, it fails a number of standardness tests in unit/functional
> tests in Bitcoin Core, at least.
>
> OP_2 was actually Luke Jr's idea circa 2017 for about the same reasons, I
> just independently arrived at the same
Quickly checked, it fails a number of standardness tests in unit/functional
tests in Bitcoin Core, at least.
OP_2 was actually Luke Jr's idea circa 2017 for about the same reasons, I
just independently arrived at the same conclusion.
On Thu, Feb 2, 2023 at 10:06 AM Peter Todd wrote:
> On Thu,
On Thu, Feb 02, 2023 at 09:59:09AM -0500, Greg Sanders wrote:
> Hi Peter,
>
> For the most principled of reasons:
>
> Because I have to change test vectors everywhere!
Specifically, you mean you'd have to change tests that test something is
non-standard?
--
https://petertodd.org
Hi Peter,
For the most principled of reasons:
Because I have to change test vectors everywhere!
Greg
On Thu, Feb 2, 2023 at 9:52 AM Peter Todd wrote:
> On Fri, Jan 27, 2023 at 09:05:20AM -0500, Greg Sanders via bitcoin-dev
> wrote:
> > Hello again dev,
> >
> > Due to the interest in the
On Fri, Jan 27, 2023 at 09:05:20AM -0500, Greg Sanders via bitcoin-dev wrote:
> Hello again dev,
>
> Due to the interest in the proposal and the prodding of certain folks, I've
> written up a short draft BIP of the Ephemeral Anchors idea here:
>
Hello again dev,
Due to the interest in the proposal and the prodding of certain folks, I've
written up a short draft BIP of the Ephemeral Anchors idea here:
https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki
The pull request at
Small update.
A bit ago I went ahead and implemented ephemeral anchors on top of the V3
proposal to see what the complexity looks like:
https://github.com/bitcoin/bitcoin/pull/26403
Roughly 130 loc excluding tests, using OP_2 instead of OP_TRUE to not camp
the value that is used elsewhere.
Hi, Greg.
I find this proposal super interesting, and IIUC something that seems
fairly "safe" to allow (assuming V3).
For LN having the commitment transaction pay a non-zero fee is a cause for
a lot of complexity in the channel state machine. Something like this would
remove a lot of edge cases
So it doesn't look like I'm ignoring a good question:
No solid noninteractive ideas, unless we get some very flexible sighash
softfork. Interactively, I think you can get collaborative fee bumps under
the current consensus regime and ephemeral anchors. The child will just be
built with inputs
I'm also very happy to see this proposal, since it gets us closer to having
a mechanism that allows the contribution to feerate in an "unauthenticated"
way, which seems to be a very helpful feature for vaults and other
contracting protocols.
One possible advantage of the sponsors interface -- and
> (see https://rubin.io/public/pdfs/multi-txn-contracts.pdf "Intermediate
UTXO")
I think I remember you trying to explain this to me a long time ago. Thanks
for the callback!
> One question I have is if V3 is designed for lightning, and this is
designed for lightning, is there any sense in
Excellent proposal and I agree it does capture much of the spirit of
sponsors w.r.t. how they might be used for V3 protocols.
The only drawbacks I see is they don't work for lower tx version contracts,
so there's still something to be desired there, and that the requirement to
sweep the output
> does that effectively mark output B as unspendable once the child gets
confirmed?
Not at all. It's a normal spend like before, since the parent has been
confirmed. It's completely unrestricted, not being bound to any
V3/ephemeral anchor restrictions on size, version, etc.
On Tue, Oct 18, 2022
Hi Greg,
Thank you very much for sharing your proposal!
I think there's one thing about the second part of your proposal that I'm
missing. Specifically, assuming the scenario of a v3 transaction with three
outputs, A, B, and the ephemeral anchor OP_TRUE. If a child transaction spends
A and
19 matches
Mail list logo
