Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets
On Fri, Sep 29, 2017 at 11:10 AM, Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Fri, Sep 29, 2017 at 01:53:55AM +, Matt Corallo via bitcoin-dev > wrote: > > I'm somewhat curious what the authors envisioned the real-world > implications of this model to be. While blindly asking users to enter what > they're willing to pay always works in theory, I'd imagine in such a world > the fee selection UX would be similar to what it is today - users are > provided a list of options with feerates and expected confirmation times > from which to select. Indeed, in a world where users pay a lower fee if > they paid more than necessary fee estimation could be more willing to > overshoot and the UX around RBF and CPFP could be simplified greatly, but > I'm not actually convinced that it would result in higher overall mining > revenue. > > Note too that the fee users are willing to pay often changes over time. > > My OpenTimestamps service is a perfect example: getting a timestamp > confirmed > within 10 minutes of the previous one has little value to me, but if the > previous completed timestamp was 24 hours ago I'm willing to pay > significantly > more money because the time delay is getting significant enough to affect > the > trustworthyness of the entire service. So the fee selection mechanism is > nothing more than a RBF-using loop that bumps the fee every time a block > gets > mined w/o confirming my latest transaction. > > This kind of time sensitivity is probably true of a majority of Bitcoin > use-cases, with the caveat that often the slope will be negative > eventually: > after a point in time completing the transaction has no value. > > Wouldn't this RBF loop behave pretty much the same in the Monopolistic Price Mechanism? (I haven't grokked RSOP yet.) In fact, so long as RBF works, isn't it possible to raise Pay-Your-Bid fees and Monopolistic Price fees over time to express the time curve preference? > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets
Happy to see Mark Friedenbach's strawman implementation. Two clarifying verifications: This implementation would allow old-style implicit fees which would have the same behavior (Pay-Your-Bid). Correct? In terms of space costs, rebateable fee txns (or CPFP chains, I'm less clear on that complication) add one UTXO 'internally' and new consensus rules require one UTXO in the coinbase for the rebate, correct? As for the paper itself: it doesn't account for high-latency/low-fee usage, correct? What if I want a transaction to complete anytime in the next N days for as cheap as given some probability of success? This has two parts: a. Is there a clear/clean game-theoretic-compatible UX for users? b. would the implementation be simple enough? If either a is 'no' or b is 'complicated', then the trade-off might not be much better than the status quo. Maybe for a high enough latency, the answer to a is 'yes' and b. is 'simple' by this strawman: try a tiny fee, if that doesn't work, try a new higher fee and repeat. Is that good enough? regards. Nathan On Fri, Sep 29, 2017 at 10:53 AM, Matt Corallo via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I'm somewhat curious what the authors envisioned the real-world > implications of this model to be. While blindly asking users to enter what > they're willing to pay always works in theory, I'd imagine in such a world > the fee selection UX would be similar to what it is today - users are > provided a list of options with feerates and expected confirmation times > from which to select. Indeed, in a world where users pay a lower fee if > they paid more than necessary fee estimation could be more willing to > overshoot and the UX around RBF and CPFP could be simplified greatly, but > I'm not actually convinced that it would result in higher overall mining > revenue. > > The UX issues with RBF and CPFP, not to mention the UX issues involved in > optimizing for quick confirmation are, indeed, quite significant, but I > believe them to be solveable with rather striaght-forward changes. Making > the market more useable (for higher or lower overall miner revenue) may be > a sufficient goal, however, to want to consider something like this. > > > On September 28, 2017 9:06:29 PM EDT, Mark Friedenbach via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> This article by Ron Lavi, Or Sattath, and Aviv Zohar was forwarded to >> me and is of interest to this group: >> >> "Redesigning Bitcoin's fee market" >> https://arxiv.org/abs/1709.08881 >> >> I'll briefly summarize before providing some commentary of my own, >> including transformation of the proposed mechanism into a relatively >> simple soft-fork. The article points out that bitcoin's auction >> model for transaction fees / inclusion in a block is broken in the >> sense that it does not achieve maximum clearing price* and to prevent >> strategic bidding behavior. >> >> (* Maximum clearing price meaning highest fee the user is willing to >>pay for the amount of time they had to wait. In other words, miner >>income. While this is a common requirement of academic work on >>auction protocols, it's not obvious that it provides intrinsic >>benefit to bitcoin for miners to extract from users the maximum >>amount of fee the market is willing to support. However strategic >>bidding behavior (e.g. RBF and CPFP) does have real network and >>usability costs, which a more "correct" auction model would reduce >>in some use cases.) >> >> Bitcoin is a "pay your bid" auction, where the user makes strategic >> calculations to determine what bid (=fee) is likely to get accepted >> within the window of time in which they want confirmation. This bid >> can then be adjusted through some combination of RBF or CPFP. >> >> The authors suggest moving to a "pay lowest winning bid" model where >> all transactions pay only the smallest fee rate paid by any >> transaction in the block, for which the winning strategy is to bid the >> maximum amount you are willing to pay to get the transaction >> confirmed: >> >> Users can then simply set their bids truthfully to exactly the >>> amount they are willing to pay to transact, and do not need to >>> utilize fee estimate mechanisms, do not resort to bid shading and do >>> not need to adjust transaction fees (via replace-by-fee mechanisms) >>> if the mempool grows. >>> >> >> >> Unlike other proposed fixes to the fee model, this is not trivially >> broken by paying the miner out of band. If you pay out of band fee >> instead of regular fee, then your transaction cannot be included with >> other regular fee paying transactions without the miner giving up all >> regular fee income. Any transaction paying less fee in-band than the >> otherwise minimum fee rate needs to also provide ~1Mvbyte * fee rate >> difference fee to make up for that lost income. So out of band fee is >> only realistically considered when it pays on top
Re: [bitcoin-dev] Responsible disclosure of bugs
[inline responses] On Thu, Sep 14, 2017 at 2:27 PM, Anthony Towns via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Tue, Sep 12, 2017 at 09:10:18AM -0700, Simon Liu wrote: > > It would be a good starting point if the current policy could be > > clarified, so everyone is on the same page, and there is no confusion. > > Collecting various commentary from here and reddit, I think current de > facto policy is something like: > > * Vulnerabilities should be reported via secur...@bitcoincore.org [0] > > * A critical issue (that can be exploited immediately or is already >being exploited causing large harm) will be dealt with by: > * a released patch ASAP > * wide notification of the need to upgrade (or to disable affected >systems) > * minimal disclosure of the actual problem, to delay attacks >[1] [2] > > * A non-critical vulnerability (because it is difficult or expensive to >exploit) will be dealt with by: > * patch and review undertaken in the ordinary flow of development > * backport of a fix or workaround from master to the current >released version [2] > > * Devs will attempt to ensure that publication of the fix does not >reveal the nature of the vulnerability by providing the proposed fix >to experienced devs who have not been informed of the vulnerability, >telling them that it fixes a vulnerability, and asking them to identify >the vulnerability. [2] > > * Devs may recommend other bitcoin implementations adopt vulnerability >fixes prior to the fix being released and widely deployed, if they >can do so without revealing the vulnerability; eg, if the fix has >significant performance benefits that would justify its inclusion. [3] > > * Prior to a vulnerability becoming public, devs will generally recommend >to friendly altcoin devs that they should catch up with fixes. But this >is only after the fixes are widely deployed in the bitcoin network. [4] > > * Devs will generally not notify altcoin developers who have behaved >in a hostile manner (eg, using vulnerabilities to attack others, or >who violate embargoes). [5] > > * Bitcoin devs won't disclose vulnerability details until >80% of bitcoin >nodes have deployed the fixes. Vulnerability discovers are encouraged >and requested to follow the same policy. [1] [6] > > Those seem like pretty good policies to me, for what it's worth. > > I advocate a policy like this, except I propose two modifications: - Point 4 should include *zero or more* altcoin developers, such that those altcoins also deploy mitigations as early as Bitcoin. (Call this "early altcoin disclosure".) - Disclose of vulnerabilities, by social convention, always explicitly names which altcoin developers were included in my proposed Early Altcoin Disclosure and Point 6. The rationale is that the policy should allow closer coordination with altcoins. If the goal is minimizing economic damage, including altcoins earlier may be the better trade-off between inclusiveness and secrecy. At the same time, the policy doesn't establish *which* altcoins, which is a tricky choice. However it *does* require disclosure of those relationships, which provides a form of feedback on the system. Imagine if altcoin X is compromised, and later disclosure occurs that reveals that altcoin X was not contacted early, then this *might* indicate leaks, maliciousness in the Bitcoin mitigation organization, or it *might* be coincidence or dumb luck. In the other case, if the Bitcoin disclosure reveals that X was indeed contacted early, then it probably indicates incompetence of the altoin X. Finally, notice that this kind of loose early disclosure policy can be symmetric. For example, Zcash developers may choose to disclose vulnerabilities they discover which affect Bitcoin to Bitcoin developers *before* Zcash releases fixes, or before those fixes are widely adopted in Zcash. We actually have a policy of doing this, since it's obvious that if our mitigation process leaks and that's used to attack Bitcoin the potential economic damage is very large. > I haven't seen anything that indicates bitcoin devs will *ever* encourage > public disclosure of vulnerabilities (as opposed to tolerating other > people publishing them [6]). So I'm guessing current de facto policy is > more along the lines of: > > * Where possible, Bitcoin devs will never disclose vulnerabilities >publically while affected code may still be in use (including by >altcoins). > > rather than something like: > > * Bitcoin devs will disclose vulnerabilities publically after 99% of the >bitcoin network has upgraded [7], and fixes have been released for >at least 12 months. > > I advocate for something like the latter case. I'd like to see a timeout on disclosure. There's an endless tail of alt-coins that could be affected, and no guarantee all will vigilantly upgrade. Meanwhile, deciding which of them
