Re: [bitcoin-dev] CTV dramatically improves DLCs
I've created a prototype of this protocol in Sapio for your perusal: https://github.com/sapio-lang/sapio/blob/master/sapio-contrib/src/contracts/derivatives/dlc.rs Feel free to tweak the test and use it as a benchmark, i tested 1 oracle with 100,000 different payouts and saw it take around 13s on a release build. I'll be playing around with this a bit (I doubt Sapio Studio can handle a gui for 100,000 nodes), but I figured it was worth a share. Cheers, Jeremy ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Speedy Trial
Boker tov bitcoin devs, A mechanism of soft-forking against activation exists. What more do you > want? > Agreed -- that should be enough. > Are we supposed to write the code on behalf of this hypothetical group of > users who may or may not exist for them just so that they can have a node > that remains stalled on Speedy Trial lockin? > That simply isn't reasonable, but if you think it is, I invite you to > create such a fork. > Disagree. It is a reasonable ask. I've done it in about 40 lines of python: https://github.com/jeremyrubin/forkd Merry Christmas Jorge, please vet the code carefully before running. Peace, Jeremy ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Speedy Trial
On Fri, Mar 11, 2022 at 02:04:29PM +, Jorge Timón via bitcoin-dev wrote: > > Thirdly, if some users insist on a chain where taproot is > > "not activated", they can always softk-fork in their own rule that > > disallows the version bits that complete the Speedy Trial activation > > sequence, or alternatively soft-fork in a rule to make spending from (or > > to) taproot addresses illegal. > Since it's about activation in general and not about taproot specifically, > your third point is the one that applies. > Users could have coordinated to have "activation x" never activated in > their chains if they simply make a rule that activating a given proposal > (with bip8) is forbidden in their chain. > But coordination requires time. People opposed to having taproot transactions in their chain had over three years to do that coordination before an activation method was merged [0], and then an additional seven months after the activation method was merged before taproot enforcement began [1]. [0] 2018-01-23 was the original proposal, 2021-04-15 was when speedy trial activation parameters for mainnet and testnet were merged. [1] 2021-11-14 For comparison, the UASF activation attempt for segwit took between 4 to 6 months to coordinate, assuming you start counting from either the "user activated soft fork" concept being raised on bitcoin-dev or the final params for BIP 148 being merged into the bips repo, and stop counting when segwit locked in. > Please, try to imagine an example for an activation that you wouldn't like > yourself. Imagine it gets proposed and you, as a user, want to resist it. Sure. There's more steps than just "fork off onto a minority chain" though. 1) The first and most important step is to explain why you want to resist it, either to convince the proposers that there really is a problem and they should stand down, or so someone can come up with a way of fixing the proposal so you don't need to resist it. Ideally, that's all that's needed to resolve the objections. (That's what didn't happen with opposition to segwit) 2) If that somehow doesn't work, and people are pushing ahead with a consensus change despite significant reasonable opposition; the next thing to do would be to establish if either side is a paper tiger and setup a futures market. That has the extra benefit of giving miners some information about which (combination of) rules will be most profitable to mine for. Once that's setup and price discovery happens, one side or the other will probably throw in the towel -- there's not much point have a money that other people aren't interested in using. (And that more or less is what happened with 2X) If a futures market like that is going to be setup, I think it's best if it happens before signalling for the soft fork starts -- the information miners will get from it is useful for figuring out how much resources to invest in signalling, eg. I think it might even be feasible to set something up even before activation parameters are finalised; you need something more than just one-on-one twitter bets to get meaningful price discovery, but I think you could probably build something based on a reasonably unbiassed oracle declaring an outcome, without precisely defined parameters fixed in a BIP. So if acting like reasonable people and talking it through doesn't work, this seems like the next step to me. 3) But maybe you try both those and they fail and people start trying to activate the soft fork (or perhaps you just weren't paying attention until it was too late, and missed the opportunity). I think the speedy trial approach here is ideal for a last ditch "everyone stays on the same chain while avoiding this horrible change" attempt. The reason being that it allows everyone to agree to not adopt the new rules with only very little cost: all you need is for 10% of hashpower to not signal over a three month period. That's cheaper than bip9 (5% over 12 months requires 2x the cumulative hashpower), and much cheaper than bip8 which requires users to update their software 4) At this point, if you were able to prevent activation, hopefully that's enough of a power move that people will take your concerns seriously, and you get a second chance at step (1). If that still results in an impasse, I'd expect there to be a second, non-speedy activation of the soft fork, that either cannot be blocked at all, or cannot be blocked without having control of at least 60% of hashpower. 5) If you weren't able to prevent activation (whether or not you prevented speedy trial from working), then you should have a lot of information: - you weren't able to convince people there was a problem - you either weren't in the economic majority and people don't think your concept of bitcoin is more valuable (
Re: [bitcoin-dev] Improving RBF Policy
Hi Gloria, It seems you're responding to what I wrote on github. Happy to respond, but perhaps we should keep it there so the conversation is kept linearly together? I'm curious what you think of my thoughts on what you brought up most recently in this thread about rate limiting / staggered window dos protection stuff. Cheers, BT On Mon, Mar 14, 2022 at 5:29 AM Gloria Zhao wrote: > Hi Billy, > > > We should expect miners will be using a more complex, more optimal way > of determining what blocks they're working on [...] we should instead run > with the assumption that miners keep all potentially relevant transactions > in their mempools, including potentially many conflicting transctions, in > order to create the most profitable blocks. And therefore we shouldn't put > the constraint on normal non-mining full nodes to do that same more-complex > mempool behavior or add any complexity for the purpose of denying > transaction replacements. > > > I think a lot of the complexity in these ideas is because of the attempt > to match relay rules with miner > inclusion rules. > > I think the assumption that miners are using a completely different > implementation of mempool and block template building is false. IIUC, most > miners use Bitcoin Core and perhaps configure their node differently (e.g. > larger mempool and different minfeerates), but also use `getblocktemplate` > which means the same ancestor package-based mining algorithm. > > Of course, I'm not a miner, so if anybody is a miner or has seen miners' > setups, please correct me if I'm wrong. > > In either case, we would want our mining algorithm to result in block > templates that are as close as possible to perfectly incentive compatibile. > > Fundamentally, I believe default mempool policy (which perhaps naturally > creates a network-wide transaction relay policy) should be as close to the > mining code as possible. Imagine node A only keeps 1 block's worth of > transactions, and node B keeps a (default) 300MB mempool. The contents of > node A's mempool should be as close as possible to a block template > generated from node B's mempool. Otherwise, node A's mempool is not very > useful - their fee estimation is flawed and compact block relay won't do > them much good if they need to re-request a lot of block transactions. > Next, imagine that node B is a miner. It would be very suboptimal if the > mining code was ancestor package-based (i.e. supports CPFP), but the > mempool policy only cared about individual feerate, and evicted low-fee > parents despite their high-fee children. It's easy to see why this would be > suboptimal. > Attempting to match mempool policy with the mining algorithm is also > arguably the point of package relay. Our mining code uses ancestor packages > which is good, but we only submit transactions one at a time to the > mempool, so a transaction's high-fee children can't be considered until > they are all already in the mempool. Package relay allows us to start > thinking about ancestor packages immediately when evaluating transactions > for submission to the mempool. > > The attempt to match policy with miner inclusion rules is deliberate and > necessary. > > > I want to echo James O'Beirne's opinion on this that this may be the > wrong path to go down (a path of more complexity without much gain). He > said: "Special consideration for "what should be in the next block" and/or > the caching of block templates seems like an imposing dependency, dragging > in a bunch of state and infrastructure to a question that should be solely > limited to mempool feerate aggregates and the feerate of the particular txn > package a wallet is concerned with." > > It seems that I under-explained the purpose of building/caching block > templates in my original post, since both you and James have the same > misunderstanding. Since RBF's introduction, we have improved to an ancestor > package-based mining algorithm. This supports CPFP (incentive compatible) > and it is now common to see more complex "families" of transactions as > users fee-bump transactions (market is working, yay). On the other hand, we > no longer have an accurate way of determining a transaction's "mining > score," i.e., the feerate of this transaction's ancestor package when it is > included in a block template using our current mining algorithm. > > This limitation is a big blocker in proposing new fee/feerate RBF rules. > For example, if we say "the transaction needs a better feerate," this is > obviously flawed, since the original transactions may have very > high-feerate children, and the replacement transaction may have low feerate > parents. So what we really want is "the transaction needs to be more > incentive compatible to mine based on our mining algorithm," but we have no > way of getting that information right now. > > In my original post, I [described 4 heuristics to get transaction's > "mining score"][1] using the current data cached in the mempool (e.g.
