email at yancy.lol [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2021-03-12 to 2022-11-10
💬 Posted a total of 17 messages
📚 Participated in the following categories: bitcoin-dev, Bitcoin Advent Calendar
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 23:16:30

- reply

📅 Original date posted:2022-11-09
📝 Original message:> technically, all we need is for *miners* to consistently mine "full
> rbf"
There's another important point I think:
technically, all we need is for *miners* to consistently mine the
highest fee-rate transaction (or the one with the most incentive).
Miners could probably be incentivized to mine transactions that double
spend a previous transaction that isn't rbf, also.
Cheers,
-Yancy
On 2022-11-03 14:32, Erik Aronesty via bitcoin-dev wrote:
> actually, peter makes an important point here
>
> technically, all we need is for *miners* to consistently mine "full
> rbf"
>
> as long as they do, businesses that accept 0conf will have to adjust
> their risk accordingly, and the problem of misaligned incentives is
> resolved
>
> i don't think it matters what non-mining users do nearly as much
>
> On Wed, Nov 2, 2022 at 3:05 PM alicexbt via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi Peter,
>
> tl;dr: I'm broadcasting full-RBF replacements paying extremely high
> fees to reward miners that turn on full-RBF. I'm starting small, just
> ~$100/block in times of congestion. Miner and pool profit margins are
> pretty small, on the order of $1k/block in many cases, so I know it
> doesn't take that much more money to make a difference.
> I appreciate this effort and perhaps this was all that was needed in
> addition to Bitcoin Core's inclusion of full rbf support. Making it
> default right away or enabling preferential peering with service
> flag in a bitcoin core release was unnecessary.
>
> If you'd like to donate to this effort, send BTC to
> bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m
> Sorry, I don't trust you based on some of the things you support on
> Twitter. Hopefully, others will donate and help this bounty.
>
> /dev/fd0
>
> Sent with Proton Mail secure email.
>
> ------- Original Message -------
> On Wednesday, November 2nd, 2022 at 2:56 PM, Peter Todd via
> bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I'm now running a full-RBf bounty program for miners.
>
> tl;dr: I'm broadcasting full-RBF replacements paying extremely high
> fees to reward miners that turn on full-RBF. I'm starting small, just
> ~$100/block in times of congestion. Miner and pool profit margins are
> pretty small, on the order of $1k/block in many cases, so I know it
> doesn't take that much more money to make a difference.
>
> Why should you do this? Full-RBF/zeroconf has been discussed to death.
> But tl;dr: You'll earn more money, and help transition Bitcoin to a
> more secure mempool policy based on economic incentives rather than
> trust.
>
> If you're a miner and want to participate, the easiest way to so is to
> use the mempoolfullrbf=1 option in the upcoming Bitcoin Core v24
> release (eg the 24.0rc3 tag), or use the mempoolreplacement=fee option
> in Bitcoin Knots.
> You can also just modify the code yourself by removing the opt-in RBF
> check. For example against the v23.0 tag:
>
> $ git diff
> diff --git a/src/validation.cpp b/src/validation.cpp
> index 214112e2b..44c364623 100644
> --- a/src/validation.cpp
> +++ b/src/validation.cpp
> @@ -736,7 +736,7 @@ bool MemPoolAccept::PreChecks(ATMPArgs& args,
> Workspace& ws) // check all unconfirmed ancestors; otherwise an opt-in
> ancestor
> // might be replaced, causing removal of this descendant.
> if (!SignalsOptInRBF(*ptxConflicting)) {
> - return state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY,
> "txn-mempool-conflict"); + // return
> state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY,
> "txn-mempool-conflict"); }
>
> ws.m_conflicts.insert(ptxConflicting->GetHash());
>
> Once you've enabled full-RBF, you need a full-RBF peer. I'm running a
> few of them:
>
> cup.nop.lol
> mug.nop.lol
> jar.nop.lol
> jug.nop.lol
>
> These nodes run a preferential peering patch
> (https://github.com/bitcoin/bitcoin/pull/25600) to ensure that full-RBF
> nodes are interconnected to each other and replacements can easily
> propagate. Also feel free to contact me if you'd like to peer with a
> private node.
>
> If you'd like to donate to this effort, send BTC to
> bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m
>
> ...and yes, I'm well aware that miners could collect this bounty in
> other ways, eg by raising minimum fees. Doing that also breaks
> zeroconf, so I'm not too concerned.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org [1 [1]]
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Links:
------
[1] http://petertodd.org
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Links:
------
[1] http://petertodd.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221109/62cc0003/attachment-0001.html>

2023-06-07 23:16:20

- reply

📅 Original date posted:2022-11-09
📝 Original message:> Bob has staked liquidity in a payment channel with Alice who later
> double spends the same inputs (at a very low feerate) resulting in a
> stalemate where neither can spend the UTXOs.
I just realized I made a mistake. RBF will always mine the higher fee
transaction, so in this case, full-rbf would prevent a transaction from
being pinned.
On 2022-11-08 15:54, yancy via bitcoin-dev wrote:
> Peter,
>
> It sounds like there are two attack vectors; neither of which require
> full-rbf (correct me if I'm wrong).
>
> 1) Bob has staked liquidity in a payment channel with Alice who later
> double spends the same inputs (at a very low feerate) resulting in a
> stalemate where neither can spend the UTXOs. The TX that creates the
> payment channel with Bob will never be mined since the mining pool
> sees the double spend?
>
> 2) Alice spams the network with a double spend wide enough that the
> double spend makes it into a block before the remainder of the network
> sees the first spend.
>
> In that case of 1), what if Bob required a opt-in rbf? Wouldn't that
> solve the issue? Bob could just create a replacement transaction with
> enough fee to get back his UTXO?
>
> For 2) it seems to me that neither full-rbf or opt-in rbf resolves
> this, although it's a probabilistic attack and requires spamming many
> nodes.
>
> Cheers,
> -Yancy
>
> On 2022-11-07 15:32, Peter Todd wrote:
>
>> On November 3, 2022 5:06:52 PM AST, yancy via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> AJ/Antoine et al
>>
>> What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to
>> solve that problem if they have only opt-in RBF available?
>> Assuming Alice is a well funded advisory, with enough resources to
>> spam the network so that enough nodes see her malicious transaction
>> first, how does full-rbf solve this vs. opt-in rbf?
>
> First of all, to make things clear, remember that the attacks were
> talking about are aimed at _preventing_ a transaction from getting
> mined. Alice wants to cheaply broadcast something with low fees that
> won't get mined soon (if ever), that prevents a protocol from making
> forward progress.
>
> With full-rbf, who saw what transaction first doesn't matter: the
> higher fee paying transaction will always(*) replace the lower fee
> one. With opt-in RBF, spamming the network can beat out the
> alternative.
>
> *) So what's the catch? Well, due to limitations in today's mempool
> implementation, sometimes we can't fully evaluate which tx pays the
> higher fee. For example, if Alice spams the network with very _large_
> numbers transactions spending that input, the current mempool code
> doesn't even try to figure out if a replacement is better.
>
> But those limitations are likely to be fixable. And even right now,
> without fixing them, Alice still has to use a lot more money to pull
> off these attacks with full-rbf. So full-rbf definitely improves the
> situation even if it doesn't solve the problem completely.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221109/fa0bd0e1/attachment-0001.html>

2023-06-07 23:16:20

- reply

📅 Original date posted:2022-11-04
📝 Original message:Peter,
> There's nothing special about a "full-rbf transaction" other than the
> fact
> that it's replacing a previously broadcast transaction that didn't
> signal
> replacement.
Thanks, this is a piece I haven't seen. It sounds like "full-rbf"
policy is fundamentally different from BIP125, where in BIP125 a
transaction must signal that it can be replaced. If I'm reading what
you said correctly, then "full-rbf" policy will allow the replacement of
any transaction, whether it's signaled or not..
> Since all the machinery to do replacemnt already exists, adding a
> full-rbf
> config flag is particularly trivial. It requires just a single line in
> the
> mempool code.
Agree the flag is trivial. The interplay between mempool policies may
not be trivial.
Cheers,
-Yancy
On 2022-10-31 18:51, Peter Todd wrote:
> On Mon, Oct 31, 2022 at 06:21:08PM +0100, yancy via bitcoin-dev wrote:
>
>> Protocol Devs,
>>
>> After reading through this email thread and BIP125, I'm curious if
>> non-rbf
>> nodes will relay full-rbf transactions and vice versa. That is to
>> say, if
>> only one non-rbf node exists on the network, however, every other node
>> implements full-rbf, will the transaction still be propagated? IE can
>> we
>> always guarantee a path through the network for either transaction
>> type no
>> matter what the combination of network policies are?
>
> 1) There are nodes that signal full-rbf, and preferentially peer to
> each other,
> thus ensuring good transaction propagation. The most recent patch to
> implement
> this is: https://github.com/bitcoin/bitcoin/pull/25600
>
> There's enough peers running full-rbf that the last time I started up a
> new
> node on a fresh IP address, it happened to have a peer relaying
> full-rbf
> replacements to it. And of course, if people want full-rbf to work more
> reliably, it's very easy to just run some nodes with a large number of
> outgoing
> peers. Changing the hard-coded 8 outgoing peers to, say, 800, isn't
> very hard.
>
> 2) There's nothing special about a "full-rbf transaction" other than
> the fact
> that it's replacing a previously broadcast transaction that didn't
> signal
> replacement. There is not consensus over the mempool, so in certain
> cases
> non-full-rbf nodes will in fact broadcast replacements when they didn't
> happen
> to receive the "first" transaction first.
>
> The latter makes testing full-rbf a bit problematic, as if you don't
> take
> special measures to ensure good propagation a small % of the time the
> "replacement" transaction will in fact be the one that gets gets mined.
>
> Does fullrbf offer any benefits other than breaking zeroconf
> business practices? If so, what are they?
> I think AJ mentioned this earlier, but adding more configuration
> options
> always increases code complexity, and with that, there is likely more
> unforeseen bugs. However, there is a section of network participants
> that
> rely on both types of transaction policy, so from my limited
> view-point, it
> seems worth accommodating if possible.
Since all the machinery to do replacemnt already exists, adding a
full-rbf
config flag is particularly trivial. It requires just a single line in
the
mempool code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221104/e8a258ae/attachment.html>

2023-06-07 23:16:19

- reply

📅 Original date posted:2022-11-08
📝 Original message:Peter,
It sounds like there are two attack vectors; neither of which require
full-rbf (correct me if I'm wrong).
1) Bob has staked liquidity in a payment channel with Alice who later
double spends the same inputs (at a very low feerate) resulting in a
stalemate where neither can spend the UTXOs. The TX that creates the
payment channel with Bob will never be mined since the mining pool sees
the double spend?
2) Alice spams the network with a double spend wide enough that the
double spend makes it into a block before the remainder of the network
sees the first spend.
In that case of 1), what if Bob required a opt-in rbf? Wouldn't that
solve the issue? Bob could just create a replacement transaction with
enough fee to get back his UTXO?
For 2) it seems to me that neither full-rbf or opt-in rbf resolves this,
although it's a probabilistic attack and requires spamming many nodes.
Cheers,
-Yancy
On 2022-11-07 15:32, Peter Todd wrote:
> On November 3, 2022 5:06:52 PM AST, yancy via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> AJ/Antoine et al
>
> What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to
> solve that problem if they have only opt-in RBF available?
> Assuming Alice is a well funded advisory, with enough resources to spam
> the network so that enough nodes see her malicious transaction first,
> how does full-rbf solve this vs. opt-in rbf?
First of all, to make things clear, remember that the attacks were
talking about are aimed at _preventing_ a transaction from getting
mined. Alice wants to cheaply broadcast something with low fees that
won't get mined soon (if ever), that prevents a protocol from making
forward progress.
With full-rbf, who saw what transaction first doesn't matter: the
higher fee paying transaction will always(*) replace the lower fee
one. With opt-in RBF, spamming the network can beat out the
alternative.
*) So what's the catch? Well, due to limitations in today's mempool
implementation, sometimes we can't fully evaluate which tx pays the
higher fee. For example, if Alice spams the network with very _large_
numbers transactions spending that input, the current mempool code
doesn't even try to figure out if a replacement is better.
But those limitations are likely to be fixable. And even right now,
without fixing them, Alice still has to use a lot more money to pull
off these attacks with full-rbf. So full-rbf definitely improves the
situation even if it doesn't solve the problem completely.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221108/b618d371/attachment.html>

2023-06-07 23:16:05

- reply

📅 Original date posted:2022-10-31
📝 Original message:Protocol Devs,
After reading through this email thread and BIP125, I'm curious if
non-rbf nodes will relay full-rbf transactions and vice versa. That is
to say, if only one non-rbf node exists on the network, however, every
other node implements full-rbf, will the transaction still be
propagated? IE can we always guarantee a path through the network for
either transaction type no matter what the combination of network
policies are?
> Does fullrbf offer any benefits other than breaking zeroconf
> business practices? If so, what are they?
I think AJ mentioned this earlier, but adding more configuration options
always increases code complexity, and with that, there is likely more
unforeseen bugs. However, there is a section of network participants
that rely on both types of transaction policy, so from my limited
view-point, it seems worth accommodating if possible.
Cheers,
-Yancy
On 2022-10-31 17:25, Greg Sanders via bitcoin-dev wrote:
> Thanks for your full thoughts Suhas,
>
> The idea of V3 is that we're currently leaving fees on the table by
> allowing use-cases to be pinned, not that we like Lightning and we
> think miners should stop being profit maximizing somehow to enable
> safer/better layer 2 systems.
>
> If someone wants to bump fees for V3 transactions(or replace them!),
> there's a much simpler "API" to do so than in legacy policy land. The
> fact that it disallows more idiotic ways to add more total fees means
> wallets "shouldn't do that". If it ends up that V3 is disallowing too
> many "natural" ways to fee bump, that's a strike against the V3 idea
> and should be discussed. For 0-conf services we have potential thieves
> who are willing to *out-bid themselves* to have funds come back to
> themselves. It's not a "legitimate" use-case, but a rational one.
>
> I have mostly come around to not pushing for fullrbf due to the issues
> you mentioned, except taking away the option. Removing a
> quite-likely-incentive-compatible option from the software just
> encourages miners to adopt an additional patch if they ever deem it
> necessary to increase their revenue, even if that revenue is from
> hurting 0-conf businesses.
>
> Maybe putting/leaving in a default-false flag for disabling these
> "carve outs" is the least bad option. V3 usage patterns shouldn't
> crumble if a large majority of miners opt out, but 0-conf use cases
> crumble after a small percentage of adoption.
>
> To recap my thoughts:
>
> 1) I have put away my fullrbf hats, I will not advocate anyone running
> it as I think it doesn't really do anything useful for users who
> aren't trying to double-spend merchants.
>
> 2) Forcing miners to honor fees left on the table with respect to
> 0-conf, or forcing them to run a custom patchset to go around it, is a
> step backwards.
>
> Greg
>
> On Mon, Oct 31, 2022 at 11:03 AM Suhas Daftuar via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> AJ,
>>
>> Thanks for the thoughtful post. I think your observations about how
>> we view mempool policy in the Bitcoin Core project, and how that
>> seems to be changing in the discussions around `-mempoolfullrbf`,
>> are on-point and provide a helpful baseline for considering future
>> policy changes.
>>
>> For a long time I viewed fullrbf as an eventuality and I considered
>> myself to be philosophically supportive of the idea. However, after
>> giving this issue some thought in the past few weeks, I am reversing
>> my thinking on this. Concretely, I will argue that we should
>> continue to maintain a relay policy where replacements are rejected
>> for transactions that don't opt-in to RBF (as described in BIP 125),
>> and moreover, that we should remove the `-mempoolfullrbf` flag from
>> Bitcoin Core's latest release candidate and not plan to release
>> software with that flag, unless (or until) circumstances change on
>> the network, which I'll discuss below.
>>
>> This is, of course, a nuanced topic, and among the considerations is
>> a philosophy of how to think about the relay policy and
>> configuration options that we make available in Bitcoin Core (a
>> consideration that is perhaps unique to that project, but I think
>> relevant for this mailing list).
>>
>> I'll start with some technical issues regarding the benefits of
>> enabling fullrbf on the network. In the current BIP 125 regime,
>> every time a transaction is created, a choice is made whether to
>> subject the transaction to BIP 125's RBF rules or not (based on
>> the sequence values of the inputs). So given that users can already
>> opt-in to RBF, the benefit of a "fullrbf" network policy would
>> be if, somehow, RBF users were still denied the benefits of RBF due
>> to the existence of other transactions that don't opt-in.
>>
>> Along those lines, Antoine Riard brought up[1] a DoS vector that is
>> available to someone who wants to interfere with multi-party funded
>> transactions, and suggested that fullrbf would eliminate the
>> problem. After exploring that question again in this thread (thanks
>> to Greg Sanders for clarifying this to me), I understand that the
>> issue is around ensuring that a multiparty (coinjoin-type) protocol
>> is able to make eventual progress, by having a candidate multiparty
>> transaction either eventually confirm or become conflicted with
>> something that has been confirmed, in which case the double-spend
>> information could be used to start a new coinjoin round with fewer
>> participants. The concern Antoine and Greg have brought up is that
>> non-rbf transactions can persist in the mempool ~indefinitely (at a
>> low feerate and not subject to replacement) and interfere with
>> progress being made in a coinjoin protocol.
>>
>> However, it seems to me that similar problems exist for such a
>> protocol even in a fullrbf world, as we understand that term today.
>> I mentioned the ability for rbf "pinning" to interfere with
>> relay of the multiparty transaction (even if the conflicting
>> transaction signals for RBF - a set of large but low feerate
>> conflicting transactions can persist in the mempool and make it
>> difficult for the coinjoin transaction from confirming, at least
>> without attaching a very large fee); and as Greg mentioned in a
>> followup, the BIP 125 rule to only permit 100 transactions to be
>> removed from the mempool at a time during a replacement can also be
>> used to pin a coinjoin protocol in the same way as a non-rbf
>> transaction today. It seems to me that what these multiparty
>> protocols actually need is some sort of "maximal rbf" network
>> policy: a way to guarantee that a transaction which should be
>> desirable for a miner to mine would always get to a miner and
>> considered for inclusion in a block, no matter what the state of
>> node's mempools on the network.
>>
>> While that sounds like a reasonable thing to want on its face (and
>> worth working on), it's not how opt-in RBF works today, nor is it
>> how transaction relay has ever conceptually worked. We have not,
>> thus far, been able to come up with a total ordering on transaction
>> desirability. Moreover, due to all the DoS issues that exist with
>> transaction relay, there are plenty of seemingly legitimate ways to
>> construct transactions that would not relay well on the network.
>> Relay has only ever been a best-efforts concept, where we carve out
>> a small subset of the entire transaction universe for which we try
>> to optimize propagation. The idea behind this approach is that if
>> every use case we can come up with has some way to achieve its goals
>> using transactions that should (eventually) be able to relay, then
>> users wouldn't have much demand for transactions that would
>> deviate from the supported policies, and we therefore shouldn't
>> need to worry too much about incentive compatibility concerns when
>> it comes to transaction types that wouldn't relay at all, even if
>> they are high feerate. (And when those situations arise where the
>> standard transactions do not accommodate some needed use case,
>> developers typically work to define a policy that is compatible with
>> our anti-DoS goals to support such use cases, such as with the
>> recent proposal for version=3 transactions [2].)
>>
>> BIP 125's RBF rules themselves were an effort to carve out just a
>> subset of situations where a transaction should evict conflicting
>> ones -- it was not a design that anyone thought would ensure that
>> all replacements which "should" be mined would always propagate.
>> And I don't believe that we know how to design policy rules that
>> would achieve the goals of this kind of multiparty protocol in a DoS
>> resistant way, today. Along those lines, I would point out that
>> even the BIP 125 design itself is not entirely incentive compatible,
>> in that it is possible to construct a replacement transaction that
>> would evict transactions which would be preferable to be included in
>> a block! [3] (This has been known for years, but fixing this has
>> proven difficult, and the only way to fix it that I'm aware of
>> would be to make BIP 125 RBF even more restrictive than it is today.
>> I do think this is something that needs to be worked on.)
>>
>> Given the limitations of RBF as we have it today, it appears to be
>> incorrect that a fullrbf network policy would solve the problems
>> Antoine raised. And so absent any other examples, it does not seem
>> to me that fullrbf solves any problems for RBF users, who are
>> already free to choose to subject their transactions to BIP 125's
>> RBF policy. From this perspective, "enabling fullrbf" is really
>> just taking away user choice to opt a transaction into a
>> non-replacement policy regime.
>>
>> I think we should ask, then, whether it is reasonable on its face
>> that users might want to opt-in to a non-replacement policy? Or in
>> other words, is it reasonable for a user to mark a transaction as
>> non-replaceable and have that indication be enforced by the network?
>> Note that these are two different questions: you could imagine a
>> world where fullrbf is a dominant policy, but users still use the
>> BIP 125 signaling method to indicate, in an unenforced way, their
>> intention to not replace a transaction. This might give useful
>> information to the network or the recipient for how to interact with
>> such a transaction.
>>
>> And I think that it's entirely possible that users would continue to
>> use the BIP 125 signaling to indicate that they do not intend to
>> replace a transaction. For better or worse, this might be because
>> zeroconf services continue to differentiate their behavior based on
>> such a signal (possibly in conjunction with other factors), or it
>> could be because there are other behaviors that could be utilized
>> more effectively if the transaction originator has made such a
>> signal, such as the recipient chaining an unconfirmed transaction as
>> a way to bump the fee (CPFP) [4].
>>
>> If it were to be the case that users continued to use BIP 125-style
>> signaling to indicate that they do not plan to replace a
>> transaction, would that be harmful to the network? This is not
>> something we can stop in our policy rules (short of censoring such
>> transactions, an obviously bad idea). I think network actors can
>> always do things that we might think are harmful for the network,
>> but that doesn't mean that there are no legitimate use cases for
>> the tools that such actors might be using. Just because someone
>> might use some policy to adopt a zeroconf model, doesn't mean that
>> others aren't using the same policy to achieve benign ends (such
>> as better CPFP behavior).
>>
>> Moreover, while users might attempt to exploit services that offer
>> zeroconf or other differentiated behavior to non-replacement
>> signaling transactions, they also might not -- I think predicting
>> user behavior in this way (and specifically predicting the
>> complexities of what a business might do and whether users might try
>> to subvert it) is beyond the scope of what we can do as protocol
>> developers. Instead, I think we can try to answer a different
>> question: if a group of users were to want the ability to opt-in to
>> a non-replacement policy regime, is that a technically sound option
>> for us to have on the network and enforce in software?
>> Specifically, does that interfere with having a sensible anti-DoS
>> mempool acceptance algorithm, or interfere with other protocols on
>> the network, or necessarily run counter to the interests of miners
>> or node operators?
>>
>> And I think the answer to that question, in looking at the
>> difference between opt-in RBF and fullrbf, is no: offering the
>> ability to opt-in to a non-replacement regime for transactions
>> doesn't introduce any fundamental issues with software or network
>> policy or other protocols. In a world where we only had fullrbf, I
>> could imagine at some point down the road proposing a
>> non-replacement signal myself, because the complexities around
>> transaction chains (and pinning) are more complex for the RBF case
>> than for the non-RBF case (and BIP 125 is not always incentive
>> compatible to begin with!). Conceptually, this is no different to
>> me than the version=3 transaction policy proposal that has been
>> advancing, if we think of it as a special set of restrictions on
>> transactions designed to accommodate a particular use case.
>>
>> Philosophically, I think we should be looking to add non-interfering
>> use cases to what the network supports.
>>
>> To those who argue for making fullrbf a default policy on the
>> network (or even just offering a flag for users to enable fullrbf),
>> I pose this hypothetical: suppose we deploy the v3 transaction
>> policy proposal (which I hope will happen in the near future). That
>> policy would restrict the ways that outputs of a v3 transaction can
>> be spent while the transaction is unconfirmed, including by limiting
>> the number and size of descendants that such a transaction can have,
>> and limiting the types of unconfirmed ancestors that can be
>> included. Suppose in a few years someone proposes that we add a
>> "-disable_v3_transaction_enforcement" flag to our software, to let
>> users decide to turn off those policy restrictions and treat v3
>> transactions the same as v2, for all the same reasons that could be
>> argued today with fullrbf: miners might earn more revenue if we
>> allowed multiple descendant v3 transactions; it's illogical for the
>> recipient of a v3 transaction to believe what is a fundamentally
>> unenforceable promise of a sender to not issue more high value
>> children that descend from an unconfirmed transaction; it's
>> inappropriate for Bitcoin Core to dictate policy on the network and
>> we should honor user choice to turn off that flag if that's what
>> users want; if users are relying on v3's policy restrictions for
>> security then that is an unstable model and we should assume it will
>> get broken[5].
>>
>> It's obvious to me that adding a flag to disable v3 policy would
>> be subversive to making the lightning use case for v3 transactions
>> work. And so my response to such a hypothetical proposal would be
>> to argue that no, we should not enable users to disable this policy,
>> because as long as that policy is just optional and working for
>> those who want it, it shouldn't harm anyone that we offer a
>> tighter set of rules for a particular use case. Adding a way to
>> bypass those rules is just trying to break someone else's use
>> case, not trying to add a new one. We should not wield "incentive
>> compatibility" as a bludgeon for breaking things that appear to be
>> working and not causing others harm.
>>
>> I think this is exactly what is happening with fullrbf.
>>
>> In comparing v3 transaction policy with opting out of transaction
>> replacement, there is of course one significant difference that I
>> have ignored thus far: I think the real difference is an opinion
>> about whether non-replacement transactions that are being used today
>> are, overall, bad for Bitcoin, and whether lightning's use of v3
>> transactions in the future would be bad for Bitcoin. If you think
>> that zeroconf is unequivocally bad, and that no one will be able to
>> plausibly construct a case that lightning is bad, then that
>> qualitative judgment might sway you to not worrying about the
>> philosophical issues I've raised above, because these situations can
>> be distinguished.
>>
>> However I am not personally willing to say that I think, overall,
>> non-rbf-signaling transactions in use on the network today are bad
>> for Bitcoin (or that fullrbf is definitely good - BIP 125's rbf
>> rules are something we've been trying to improve upon for years,
>> with little success). Nor am I convinced that someone couldn't
>> put together a cogent argument for lightning being bad for Bitcoin,
>> because of its reliance on relay policies that are difficult to
>> design and impossible to guarantee as part of its security model.
>> So I choose instead to merely make a judgment that seems more
>> factually verifiable, which is that non-replacement is a policy
>> widely in use on the network today, and we largely don't have reason
>> to think (as far as I know!) that the network is seeing a lot of
>> transactions that would violate that policy.
>>
>> If it did turn out that users were commonly signaling
>> non-replacement, but then signing and trying to relay doublespends,
>> then I think that would be a very good reason for Bitcoin Core to
>> adopt fullrbf to reflect the reality of what is happening. In the
>> meantime, I think it makes more sense to say that because we have
>> BIP 125, there seems to be no need for users to signal one way and
>> behave another, and therefore there is no need to offer software
>> that might break a policy that is working well for some users.
>> Other software projects might choose differently, and it is after
>> all a permissionless network, so if this is in fact an unstable
>> equilibrium that will not last, then presumably someday it will be
>> apparent it is not working and we'll abandon it. But I think the
>> philosophy of transaction relay policy in Bitcoin Core should be to
>> support disparate use cases in order to try to make everything work
>> better, rather than break things prematurely because we guess others
>> will break them eventually anyway.
>>
>> For those that have read this long email and still favor a fullrbf
>> network policy (or even just the ability for users to be able to
>> turn on fullrbf for themselves), I'd ask for thoughts on the
>> following questions, which have guided my thinking on this:
>>
>> Does fullrbf offer any benefits other than breaking zeroconf
>> business practices? If so, what are they?
>>
>> Is it reasonable to enforce BIP 125's rbf rules on all transactions,
>> if those rules themselves are not always incentive compatible?
>>
>> If someone were to propose a command line option that breaks v3
>> transaction relay in the future, is there a logical basis for
>> opposing that which is consistent with moving towards fullrbf now?
>>
>> Cheers,
>> Suhas
>>
>> [1]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
>
>> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html
>
>> [3] This is because under the BIP 125 rules, the feerate of the
>> replacement transaction is not compared to the individual feerates
>> of all transactions being evicted - we just compare feerates with
>> the transactions that are directly in conflict (and not their
>> descendants). So it's possible for a transaction that would evict
>> 2 or more transactions to have a higher feerate than the direct
>> conflicts, and higher total fee than the set being evicted, but have
>> a lower feerate (eg if it is larger) than that of some subset of the
>> set of transactions being evicted.
>>
>> [4] Chaining unconfirmed transactions when the sender might RBF the
>> parent is far riskier than if the sender indicates they don't plan
>> to do so (chaining onto an RBF transaction creates pinning issues
>> for the sender, and risks having the child wiped out if the parent
>> is replaced), so I think this is a concrete reason why signaling
>> that a transaction won't be replaced could be useful.
>>
>> [5] This is a subtle point. I don't think v3 transactions create
>> an unreasonable security assumption for the use case it is being
>> designed for. However, I don't think anyone could rule out the
>> possibility that someone could adopt a usage pattern for v3
>> transactions that subverts the intent of this policy. For example,
>> if users started using v3 transactions for all their payments, then
>> the limitations on the number of descendants could directly
>> interfere with CPFP by a recipient, and someone could argue that we
>> should break the policy in order to allow for this hypothetical
>> behavior. I think this is a similar form of argument as saying that
>> zeroconf practices + BIP 125 create an incentive to double-spend
>> non-rbf signaling transactions.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221031/fc8ddf49/attachment-0001.html>

2023-06-07 23:15:18

- reply

📅 Original date posted:2022-10-20
📝 Original message:I had one other idea on the topic. Namely, in the last section
"calculation", Satoshi talks more about what he/she/they consider to be
bad actors. The idea that someone is not doing "tip mining" does not
mean they are dishonest.
> We consider the scenario of an attacker trying to generate an alternate
> chain faster than the honest
> chain. Even if this is accomplished, it does not throw the system open
> to arbitrary changes, such
> as creating value out of thin air or taking money that never belonged
> to the attacker. Nodes are
> not going to accept an invalid transaction as payment, and honest nodes
> will never accept a block
> containing them. An attacker can only try to change one of his own
> transactions to take back
> money he recently spent.
It seems to me that there's a distinction in the game theoretics between
"not tip mining" and actively being a bad actor (changing a past
transaction signed by yourself).
I rewrote the "AttackerSuccessProbability" C function in Rust for fun:
https://github.com/yancyribbens/attacker-success-probability-rust
Cheers,
-Yancy
On 2022-10-18 18:27, Jeremy Rubin via bitcoin-dev wrote:
> 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 considered an assumption because even if following the rules
>> were clearly the 100% dominant strategy, this doesn't prove that the
>> majority is honest, since mathematics cannot say what is happening
>> in the real world at any given time. Still, we must have a reason
>> to think that the majority would be honest, and that reasoning
>> should come from an argument that the rule set is incentive
>> compatible.
>
> epistemically is that even within the game that you prove the dominant
> strategy, you can't be certain that you've captured (except maybe
> through clever use of exogenous parameters, which reduces to the same
> thing as % honest) the actual incentives of all players. For example,
> you would need to capture the existence of large hegemonic governments
> defending their legacy currencies by attacking bitcoin.
>
> I think we may be talking past each other if it is a concern /
> valuable exercise to decrease the assumptions that Bitcoin rests on to
> make it more secure than it is as defined in the whitepaper. That's an
> exercise of tremendous value. I think my point is that those things
> are aspirational (aspirations that perhaps we should absolutely
> achieve?) but to the extent that we need to fix things like the fee
> market, selfish mining, mind the gap, etc, those are modifying Bitcoin
> to be secure (or more fair is perhaps another way to look at it) in
> the presence of deviations from a hypothesized "incentive compatible
> Bitcoin", which is a different thing that "whitepaper bitcoin". I
> think that I largely fall in the camp -- as evidenced by some past
> conversations I won't rehash -- that all of Bitcoin should be
> incentive compatible and we should fix it if not. But from those
> conversations I also learned that there are large swaths of the
> community who don't share that value, or only share it up to a point,
> and do feel comfortable resting on honest majority assumptions at one
> layer of the stack or another. And I think that prior / axiom is a
> pretty central one to debug or comprehend when dealing with, as is
> happening now, a fight over something that seems obviously not
> incentive compatible.
>
> --
> @JeremyRubin [1 [1]]
>
> On Tue, Oct 18, 2022 at 10:30 AM Russell O'Connor
> <roconnor at blockstream.com> wrote:
>
> On Tue, Oct 18, 2022 at 9:07 AM Jeremy Rubin via bitcoin-dev
> <bitcoin-dev at 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 clear, when we try
> to describe Bitcoin with differing assumptions than in the
> whitepaper, what the changes are and why we think the system might
> support those claims. But if we can't prove the new description
> sound, such as showing tip mining to be rational in a fully
> adversarial model, it doesn't mean Bitcoin doesn't work as
> promised, since all that was promised originally is functioning
> under an honest majority. Caveat Emptor!
> 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 considered an assumption because even if following the rules
> were clearly the 100% dominant strategy, this doesn't prove that the
> majority is honest, since mathematics cannot say what is happening
> in the real world at any given time. Still, we must have a reason
> to think that the majority would be honest, and that reasoning
> should come from an argument that the rule set is incentive
> compatible.
>
> The stability of mining, i.e. the incentives to mine on the most
> work chain, is actually a huge concern, especially in a future low
> subsidy environment. There is actually much fretting about this
> issue, and rightly so. We don't actually know that Bitcoin can
> function in a low subsidy environment because we have never tested
> it. Bitcoin could still end up a failure if that doesn't work out.
> My current understanding/guess is that with a "thick mempool" (that
> is lots of transactions without large gaps in fee rates between
> them) and/or miners rationally leaving behind transactions to
> encourage mining on their block (after all it is in a miner's own
> interest not to have their block orphaned), that mining will be
> stable. But I don't know this for sure, and we cannot know with
> certainty that we are going to have a "thick mempool" when it is
> needed.
>
> It is most certainly the case that one can construct situations
> where not mining on the tip is going to be the prefered strategy.
> But even if that happens on occasion, it's not like the protocol
> immediately collapses, because mining off the tip is
> indistinguishable from being a high latency miner who simply didn't
> receive the most work block in time. So it is more of a question of
> how rare does it need to be, and what can we do to reduce the
> chances of such situations arising (e.g. updating our mining policy
> to leave some transactions out based on current (and anticipated)
> mempool conditions, or (for a sufficiently capitalized miner) leave
> an explicit, ANYONECANSPEND transaction output as a tip for the next
> miner to build upon mined blocks.)
Links:
------
[1] https://twitter.com/JeremyRubin
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Links:
------
[1] https://twitter.com/JeremyRubin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221020/d96658cc/attachment-0001.html>

2023-06-07 23:15:13

- reply

📅 Original date posted:2022-10-17
📝 Original message:Hi Jeremy,
Thanks for the reply. I do find the semantics of mempool and block org
interesting (although there's a lot on the topic I don't know).
> E.g., suppose:
>
> Block N: Fees = 10, reward = 1
>
> Mempool: Fees = 2
>
> Mining block N+1 with the mempool leads to reward 2+1 = 3, reorging
> leads to reward of up to 10 + 1 + c, (c < 2, where c is the extra
> transactions that fit).
If I'm reading this correctly, Block N was already mined, but the miner
who mined block N+1 repacks the transactions from block N because they
have more to gain. Wouldn't such a situation be resolved in the same
way as two miners who find a block at a similar time? E.g the network
will choose depending on when block N+2 is created.
> Assume instead your reward is 8, leaving 3+c on the table.
Mining block N+1 with the mempool leads to reward 2+8 = 10, reorging
leads to 10 + 8 + c? Wouldn't that leave 8+c?
> If you assume all other miners are tip miners, and there are two
> conflicting tips, they should pick the one with the more profit for
> them, which is the new one you made as a non-tip miner since you
> "shared" some fee.
I'm curious how the "fee sharing" would be organized. To see if I
understand, You're asking what would happen if one of the two miners
incentives (bribes in this case) the next miner (block N+1) to choose
one of the competing tip miners?
> You aren't particularly more likely to remine block N or N+1, before
> someone builds on it, as opposed to deeper reorgs (which require
> larger incentive).
Agree.
> However, as many have pointed out, perhaps not following the simple
> "honest tip mining" strategy is bad for bitcoin, so maybe we should
> expect it not to happen often?
The idea that people won't do something because it's "bad for Bitcoin"
doesn't fit an adversarial model. Even in the above examples (which I
think wouldn't expect to happen often), I would argue the network still
conforms to a Nash Equilibrium without requiring trust. Although It's
mostly speculation without some empirical data.
Cheers,
-Yancy
On 2022-10-17 21:10, Jeremy Rubin wrote:
> Building on the most work chain is perhaps not rational in many normal
> circumstances that can come up today under the stated reference
> strategy:
>
> 1) Take highest paying transactions that fit
> 2) Mine on tips
>
> E.g., suppose:
>
> Block N: Fees = 10, reward = 1
>
> Mempool: Fees = 2
>
> Mining block N+1 with the mempool leads to reward 2+1 = 3, reorging
> leads to reward of up to 10 + 1 + c, (c < 2, where c is the extra
> transactions that fit). Assume instead your reward is 8, leaving 3+c
> on the table.
>
> If you assume all other miners are tip miners, and there are two
> conflicting tips, they should pick the one with the more profit for
> them, which is the new one you made as a non-tip miner since you
> "shared" some fee.
>
> You aren't particularly more likely to remine block N or N+1, before
> someone builds on it, as opposed to deeper reorgs (which require
> larger incentive).
>
> However, as many have pointed out, perhaps not following the simple
> "honest tip mining" strategy is bad for bitcoin, so maybe we should
> expect it not to happen often? Or other strategies to emerge around
> selecting transactions so that the next M blocks have a similar fee
> profile, as opposed to picking greedily for the next block.
>
> --
> @JeremyRubin [1 [1]]
>
> On Sun, Oct 16, 2022 at 3:03 PM <email at yancy.lol> wrote:
>
> The proof-of-work also solves the problem of determining
> representation in majority decision
> making. If the majority were based on one-IP-address-one-vote, it
> could be subverted by anyone
> able to allocate many IPs. Proof-of-work is essentially
> one-CPU-one-vote. The majority
> decision is represented by the longest chain, which has the
> greatest
> proof-of-work effort invested
> in it. If a majority of CPU power is controlled by honest nodes,
> the
> honest chain will grow the
> fastest and outpace any competing chains. To modify a past block,
> an
> attacker would have to
> redo the proof-of-work of the block and all blocks after it and
> then
> catch up with and surpass the
> work of the honest nodes. We will show later that the probability
> of a
> slower attacker catching up
> diminishes exponentially as subsequent blocks are added.
> It's interesting that Nash Equilibrium isn't mentioned here. Since
> each miner has the option to either contribute to the longest chain
> or not, even if the miners know what strategy the other miners will
> use, they still wouldn't change their decision to contribute to the
> majority.
>
> For example, if I run a shop that takes rain checks, but I sell an
> item to a higher bidder who didn't have a hold on the item, that
> is
> not honest, but it may be selfish profit maximizing.
> It would be honest if the store policy said ahead of time they are
> allowed to sell rain checks for more in such an occurrence.
> Although this is a good example of the difference between honest and
> rational. I think this means it's not a Nash Equilibrium if we
> needed to rely on the store owner to be honest.
>
> Satoshi said an honest majority is required for the chain to be
> extended. Honest is not really defined though. Honesty, in my
> definition, is that you follow a pre specified rule, rational or
> not.
> My take is that "rational" is probably a better word than honest.
> In terms of a Nash Equilibrium, each participant is simply trying to
> maximize their outcome and honesty doesn't matter (only that
> participants are rational).
>
> It seems a lot of the RBF controversy is that Protocol developers
> have
> aspired to make the honest behavior also be the rational behavior.
> This is maybe a good idea because, in theory, if the honest
> behavior
> is rational then we can make a weaker assumption of selfishness
> maximizing a parameter.
> I'm curious, can RBF can be described by a Nash Equilibrium? If
> yes, then it also shouldn't matter if participants are honest?
>
> Overall, it might be nice to more tightly document what bitcoins
> assumptions are in practice and what those assumptions do in terms
> of
> properties of Bitcoin, as well as pathways to weakening the
> assumptions without compromising the behaviors users expect the
> network to have. An "extended white paper" if you will.
> White paper 1.1 :D
>
> A last reflection is that Bitcoin is specified with an honest
> majority
> assumption, but also has a rational dishonest minority assumption
> over
> both endogenous (rewards) and exogenous (electricity) costs.
> Satoshi
> did not suggest, at least as I read it, that Bitcoin works with an
> rational majority assumption. (If anyone thinks these three are
> similar properties you can make some trivial counterexamples)
> My take is the opposite unless I'm missing something. Participants
> are always incentivized to choose the rational solution (Not to
> waste electricity on a minority chain).
>
> Cheers,
> -Yancy
>
> On 2022-10-16 19:35, Jeremy Rubin via bitcoin-dev wrote:
>
> The Bitcoin white paper says:
>
> The proof-of-work also solves the problem of determining
> representation in majority decision
> making. If the majority were based on one-IP-address-one-vote, it
> could be subverted by anyone
> able to allocate many IPs. Proof-of-work is essentially
> one-CPU-one-vote. The majority
> decision is represented by the longest chain, which has the
> greatest
> proof-of-work effort invested
> in it. If a majority of CPU power is controlled by honest nodes,
> the
> honest chain will grow the
> fastest and outpace any competing chains. To modify a past block,
> an
> attacker would have to
> redo the proof-of-work of the block and all blocks after it and
> then
> catch up with and surpass the
> work of the honest nodes. We will show later that the probability
> of a
> slower attacker catching up
> diminishes exponentially as subsequent blocks are added.
>
> This, Satoshi (who doesn't really matter anyways I guess?) claimed
> that for Bitcoin to function properly you need a majority honest
> nodes.
>
> There are multiple behaviors one can describe as honest, and
> economically rational or optimizing is not necessarily rational.
>
> For example, if I run a shop that takes rain checks, but I sell an
> item to a higher bidder who didn't have a hold on the item, that
> is
> not honest, but it may be selfish profit maximizing.
>
> Satoshi said an honest majority is required for the chain to be
> extended. Honest is not really defined though. Honesty, in my
> definition, is that you follow a pre specified rule, rational or
> not.
>
> It seems a lot of the RBF controversy is that Protocol developers
> have
> aspired to make the honest behavior also be the rational behavior.
> This is maybe a good idea because, in theory, if the honest
> behavior
> is rational then we can make a weaker assumption of selfishness
> maximizing a parameter.
>
> However, Satoshi did not particularly bound what aspects of
> honesty
> are important for the network, because there isn't a spec defining
> exactly what is honest or not. And also as soon as people are
> honest,
> you can rely on that assumption for good effect.
>
> And sometimes, defining an honest behavior can be creating a
> higher
> utility system because most people are "law abiding citizens" who
> might not be short term rational. For example, one might expect
> that
> miners would be interested in making sure lightning closes are
> "accurate" because increasing the utility of lightning is good for
> Bitcoin, even if it is irrational.
>
> It seems that the NoRBF crowd want to rely on an honest majority
> assumption where the honest behavior is not doing replacement if
> not
> requested. This is really not much different than trying to close
> lightning channels "the right way".
>
> However, where it may be different, is that even in the presence
> of
> honest majority, the safety of 0conf isn't assured given the
> potential
> of race conditions in the mempool. Therefore it's not clear to me
> that
> 0conf working well is something you can drive from the Honest
> Majority
> Assumption (where honest includes first seen).
>
> Overall, it might be nice to more tightly document what bitcoins
> assumptions are in practice and what those assumptions do in terms
> of
> properties of Bitcoin, as well as pathways to weakening the
> assumptions without compromising the behaviors users expect the
> network to have. An "extended white paper" if you will.
>
> It's somewhat clear to me that we shouldn't weaken assumptions
> that
> only seem local to one subsystem of Bitcoin if they end up
> destabilizing another system. In particular, things that decrease
> "transaction utility" for end users decrease the demand for
> transactions which hurts the fee market's longer term viability,
> even
> if we feel good about making an honest policy assumption into a
> self
> interested policy assumption.
>
> A last reflection is that Bitcoin is specified with an honest
> majority
> assumption, but also has a rational dishonest minority assumption
> over
> both endogenous (rewards) and exogenous (electricity) costs.
> Satoshi
> did not suggest, at least as I read it, that Bitcoin works with an
> rational majority assumption. (If anyone thinks these three are
> similar properties you can make some trivial counterexamples)
>
> Cheers,
>
> Jeremy
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Links:
------
[1] https://twitter.com/JeremyRubin
Links:
------
[1] https://twitter.com/JeremyRubin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221018/227ec446/attachment-0001.html>

2023-06-07 23:01:39

- reply

📅 Original date posted:2021-12-26
📝 Original message:Prayank,
I believe the p2pderivatives DLC application is still under active
development here (single oracle):
https://github.com/p2pderivatives/rust-dlc
I was once involved in the project in a galaxy far far away but haven't
kept up with the project. Also, I'm a few days behind in the Bitcoin
Advent Calendar :)
Cheers,
-Yancy
On 2021-12-24 17:42, Prayank via bitcoin-dev wrote:
> Hi Jeremy,
>
>> Wheres the info come from? Well, multiple places. We could get it
> from a third party (maybe using an attestation chain of some sort?),
> or there are certain ways it could be self-referential (like for
> powswap [1]).
>
>> Now let’s define a threshold oracle – we wouldn’t want to
> trust just one lousy oracle, so let’s trust M out of N of them!
>
> Similar approach is used in discreet log contracts for multi oracles.
> There is even a project for P2P derivatives but it was not used for
> any real trades on mainnet or further developed. What difference would
> OP_CTV make in this project if its implemented in Bitcoin?
>
> https://github.com/p2pderivatives/p2pderivatives-client
>
> https://github.com/p2pderivatives/p2pderivatives-server
>
> https://github.com/p2pderivatives/p2pderivatives-oracle
>
>> Does this NEED CTV?
>
> No, not in particular. Most of this stuff could be done with online
> signer server federation between you and counterparty. CTV makes some
> stuff nicer though, and opens up new possibilities for opening these
> contracts unilaterally.
>
> Nicer? How would unilateral derivatives work because my understanding
> was that you always need a peer to take the other side of the trade. I
> wish we could discuss this topic in a trading community with some
> Bitcoiners that even had some programming knowledge.
>
> Derivatives are interesting and less explored or used in Bitcoin
> projects. They could be useful in solving lot of problems.
>
> --
>
> Prayank
>
> A3B1 E430 2298 178F
>
>
> Links:
> ------
> [1] https://powswap.com
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev