Hi Hiroki,
(inserting the bitcoin-dev mailing list as this question is mainly
concerning on-chain interaction)
Thanks for taking the time to really dig into things!
> When trying to verify the provenance of a given UTXO, it is necessary to
> verify the state transitions of all transaction
Hi Greg,
Thanks for proposing forward the "ephemeral anchors" policy change.
> In Gloria's proposal for ln-penalty, this is worked
> around by reducing the number of anchors per commitment transaction to 1,
> and each version of the commitment transaction has a unique party's key on
> it. The
Hello Andrew and Bryan,
> No, as I understand the proposal, the "public key" held by the wallet is
> simply
> a signing key used to authenticate addresses, and never leaves the wallet.
That's right (or at least, that's the intent). Think of importing someone's GPG
key and then using it to
not sure if this is helpful, but when i'm code reviewing a change to
an existing, functioning and very complex system, i rarely go back to
"first principles" to analyze that change independently, and instead
try to decide if it's better or worse than what we have now
I agree that it's
> (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
not sure if this is helpful, but when i'm code reviewing a change to an
existing, functioning and very complex system, i rarely go back to "first
principles" to analyze that change independently, and instead try to decide
if it's better or worse than what we have now
you can introduce a new
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
I think the issue with
I still think it is misguided to think that the "honest" (i.e. rule
> following) majority is to just be accepted as an axiom and if it is
> violated, well, then sorry. The rules need to be incentive compatible for
> the system to be functional. The honest majority is only
> 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
On Tue, Oct 18, 2022 at 9:07 AM Jeremy Rubin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> However, what *is* important about what Satoshi wrote is that it is sort
> of the "social contract" of what Bitcoin is that we can all sort of
> minimally agree to. This makes it
Hello Everyone,
Following up on the "V3 Transaction" discussion here
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html
, I would like to elaborate a bit further on some potential follow-on work
that would make pinning severely constrained in many setups].
V3
Hello John,
On 17.10.22 02:23, John Carvalho via bitcoin-dev wrote:
Simply, 0conf acceptance can be monitored and enforced by the merchant and
exposure to doublespends can be both mitigated and limited in size per block.
It is less expensive to be double-spent occasionally than to have a
Hi Rijndael,
I think your thoughts are pretty much compatible with this proposal, as
what I'm describing (the recipient signing their keys) is also essentially
a form of authentication.
It's a good observation that in general this makes the communication of
addresses more secure. I do wish to
On Mon, Oct 17, 2022 at 07:07:07PM -0500, Bryan Bishop via bitcoin-dev wrote:
>
> Isn't this the same problem but now for copy-pasting pubkeys instead of an
> address?
>
No, as I understand the proposal, the "public key" held by the wallet is simply
a signing key used to authenticate addresses,
On Mon, Oct 17, 2022 at 05:41:48PM -0400, Antoine Riard via bitcoin-dev wrote:
> > 1) Continue supporting and encouraging accepting unconfirmed "on-chain"
> > payments indefinitely
> > 2) Draw a line in the sand now, but give people who are currently
> > accepting unconfirmed txs time to
16 matches
Mail list logo
