Nathan Wilcox [ARCHIVE] / is on Nostr

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

Last Notes

2023-06-07 18:06:35

- reply

📅 Original date posted:2017-09-28
📝 Original message:On Fri, Sep 29, 2017 at 11:10 AM, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Fri, Sep 29, 2017 at 01:53:55AM +0000, 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 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/20170929/a7352e52/attachment.html>

2023-06-07 18:06:34

- reply

📅 Original date posted:2017-09-28
📝 Original message: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 at 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 at 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 of a regular feerate
>> paying transaction that would have been included in the block anyway.
>> And what would be the point of that?
>>
>>
>> As an original contribution, I would like to note that something
>> strongly resembling this proposal could be soft-forked in very easily.
>> The shortest explanation is:
>>
>> For scriptPubKey outputs of the form "<max-42-byte-push>", where
>> the pushed data evaluates as true, a consensus rule is added that
>> the coinbase must pay any fee in excess of the minimum fee rate
>> for the block to the push value, which is a scriptPubKey.
>>
>> Beyond fixing the perceived problems of bitcoin's fee auction model
>> leading to costly strategic behavior (whether that is a problem is a
>> topic open to debate!), this would have the additional benefits of:
>>
>> 1. Allowing pre-signed transactions, of payment channel close-out
>> for example, to provide sufficient fee for confirmation without
>> knowledge of future rates or overpaying or trusting a wallet to
>> be online to provide CPFP fee updates.
>>
>> 2. Allowing explicit fees in multi-party transaction creation
>> protocols where final transaction sizes are not known prior to
>> signing by one or more of the parties, while again not
>> overpaying or trusting on CPFP, etc.
>>
>> 3. Allowing applications with expensive network access to pay
>> reasonable fees for quick confirmation, without overpaying or
>> querying a trusted fee estimator. Blockstream Satellite helps
>> here, but rebateable fees provides an alternative option when
>> full block feeds are not available for whatever reason.
>>
>> Using a fee rebate would carry a marginal cost of 70-100 vbytes per
>> instance. This makes it a rather expensive feature, and therefore in
>> my own estimation not something that is likely to be used by most
>> transactions today. However the cost is less than CPFP, and so I
>> expect that it would be a heavily used feature in things like payment
>> channel refund and uncooperative close-out transactions.
>>
>>
>> Here is a more worked out proposal, suitable for critiquing:
>>
>> 1. A transaction is allowed to specify an _Implicit Fee_, as usual, as
>> well as one or more explicit _Rebateable Fees_. A rebateable fee
>> is an ouput with a scriptPubKey that consists of a single, minimal,
>> nonzero push of up to 42 bytes. Note that this is an always-true
>> script that requires no signature to spend.
>>
>> 2. The _Fee Rate_ of a transaction is a fractional number equal to the
>> combined implicit and rebateable fee divided by the size/weight of
>> the transaction.
>>
>> (A nontrivial complication of this, which I will punt on for the
>> moment, is how to group transactions for fee rate calculation such
>> that CPFP doesn't bring down the minimum fee rate of the block,
>> but to do so with rules that are both simple, because this is
>> consensus code; and fair, so as to prevent unintended use of a
>> rebate fee by children or siblings.)
>>
>> 3. The smallest fee rate of any non-coinbase transaction (or
>> transaction group) is the _Marginal Fee Rate_ for the block and is
>> included in the witness for the block.
>>
>> 4. The verifier checks that each transaction or transaction grouping
>> provides a fee greater than or equal to the threshold fee rate, and
>> at least one is exactly equal to the marginal rate (which proves
>> the marginal rate is the minimum for the block).
>>
>> This establishes the marginal fee rate, which alternatively expressed
>> is epsilon less than the fee rate that would have been required to get
>> into the block, assuming there was sufficient space.
>>
>> 5. A per-block _Dust Threshold_ is calculated using the marginal fee
>> rate and reasonable assumptions about transaction size.
>>
>> 6. For each transaction (or transaction group), the _Required Fee_ is
>> calculated to be the marginal fee rate times the size/weight of the
>> transaction. Implicit fee is applied towards this required fee and
>> added to the _Miner's Fee Tally_. Any excess implicit fee
>> remaining is added to the _Implicit Fee Tally_.
>>
>> 7. For each transaction (group), the rebateable fees contribute
>> proportionally towards towards meeting the remaining marginal fee
>> requirement, if the implicit fee failed to do so. Of what's left,
>> one of two things can happen based on how much is remaining:
>>
>> A. If greater than or equal to the dust threshold is remaining in
>> a specific rebateable fee, a requirement is added that an
>> output be provided in the coinbase paying the remaining fee to
>> a scriptPubKey equal to the push value (see #1 above).
>>
>> (With due consideration for what happens if a script is reused
>> in multiple explicit fees, of course.)
>>
>> B. Otherwise, add remaining dust to the implicit fee tally.
>>
>> 8. For the very last transaction in the block, the miner builds a
>> transaction claiming ALL of these explicit fees, and with a single
>> zero-valued null/data output, thereby forwarding the fees on to the
>> coinbase, as far as old clients are concerned. This is only
>> concerns consensus in that this final transaction does not change
>> any of the previously mentioned tallies.
>>
>> (Aside: the zero-valued output is merely required because all
>> transactions must have at least one output. It does however make a
>> great location to put commitments for extensions to the block
>> header, as being on the right-most path of the Merkle tree can
>> mean shorter proofs.)
>>
>> 9. The miner is allowed to claim subsidy + the miner's fee tally + the
>> explicit fee tally for themselves in the coinbase. The coinbase is
>> also required to contain all rebated fees above the dust threshold.
>>
>> In summary, all transactions have the same actual fee rate equal to
>> the minimum fee rate that went into the creation of the block, which
>> is basically the marginal fee rate for transaction inclusion.
>>
>> A variant of this proposal is that instead of giving the implicit fee
>> tally to the miner (the excess non-rebateable fees beyond the required
>> minimum), it is carried forward from block to block in the final
>> transaction and the miner is allowed to claim some average of past
>> fees, thereby smoothing out fees or providing some other incentive.
>>
>>
> _______________________________________________
> 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/20170929/c4b50f5d/attachment-0001.html>

2023-06-07 18:05:54

- reply

📅 Original date posted:2017-09-21
📝 Original message:[inline responses]
On Thu, Sep 14, 2017 at 2:27 PM, Anthony Towns via bitcoin-dev <
bitcoin-dev at 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 security at 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 to disclose to confidentially versus which should just receive hints
to apply new patches is tricky and political.
Having a global timeout is a reasonable stop-gap. I consider the cost of
never disclosing, publicly, a known vulnerbility to be very high, even if
the fix is ubiquitously deployed, because it's a loss of security
knowledge, a precious public good.
>
> Instinctively, I'd say documenting this policy (or whatever it actually
> is) would be good, and having all vulnerabilities get publically released
> eventually would also be good; that's certainly the more "open source"
> approach. But arguing the other side:
>
> - documenting security policy gives attackers a better handle on where
> to find weak points; this may be more harm than there is benefit to
> improving legitimate users' understanding of and confidence in the
> development process
>
>
Publishing a policy *might* increase organizational vulnerability, but so
might *not publishing* a policy. It seems fairly neutral to me on
vulnerability impact, whereas the benefit is good for users and developers.
> - the main benefit of public vulnerability disclosure is a better
> working relationship with security researchers and perhaps better
> understanding of what sort of bugs happen in practice in general;
> but if most of your security research is effectively in house [6],
> maybe those benefits aren't as great as the harm done by revealing
> even old vulnerabilities to attackers
>
>
Publishing after a reasonable timeout has many benefits. Many security
researchers learn from vulnerability disclosures across many disciplines
and industries. Future protocol designers of things potentially unrelated
to blockchain altogether may also learn important lessons.
If the first of those arguments holds, well, hopefully this message has
> egregious errors that no one will correct, or it will quickly get lost
> in this list's archives...
>
> Cheers,
> aj
>
>
regards,
Nathan Wilcox
Zcash
> [0] http://bitcoincore.org/en/contact
> referenced from .github/ISSUE_TEMPLATE.md in git
>
> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-September/014986.html
>
> [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-September/014990.html
>
> [3] https://www.reddit.com/r/btc/comments/6zf1qo/peter_todd_
> nicely_pulled_away_attention_from_jjs/dmxcw70/
>
> [4] https://www.reddit.com/r/btc/comments/6z827o/chris_jeffrey_
> jj_discloses_bitcoin_attack_vector/dmxdg83/
>
> [5] https://www.reddit.com/r/btc/comments/6zb3lp/maxwell_
> admits_core_sat_on_vulnerability/dmv4y7g/
>
> [6] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-September/014991.html
>
> [7] Per http://luke.dashjr.org/programs/bitcoin/files/charts/branches.html
> it seems like 1.7% of the network is running known-vulnerable versions
> 0.8 and 0.9; but only 0.37% are running 0.10 or 0.11, so that might
> argue
> revealing any vulnerabilities fixed since 0.12.0 would be fine...
> (bitnodes.21.co doesn't seem to break down anything earlier than 0.12)
>
> _______________________________________________
> 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/20170922/db798f3b/attachment-0001.html>

2023-06-07 15:41:56

- reply

📅 Original date posted:2015-07-11
📝 Original message:On Sat, Jul 11, 2015 at 2:24 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
> All miners should validate transactions precisely because of the latest
attack you've described.
The problem is one of individual incentives leading to a systemic problem.
"All X should do..." solutions which are oblivious to individual incentives
don't scale, eg: "If all factories avoid emitting pollution they don't pay
for..." does not work if individual factories save their own costs by
dumping into the environment. No one wants environmental catastrophe, and
no one wants a blockchain where miners don't validate transactions, but
there may be a systemic problem of incentives.
The bitcoin.org claim that "about half" of miner capacity does SPV Mining,
is consistent with the incentives problem as I described it. However, I
don't claim the state of mining is certainly due to these incentives and
not other incentives we haven't discussed. Also, there may be other
incentives that outweigh this issue.
On Sat, Jul 11, 2015 at 3:39 AM, Tier Nolan <tier.nolan at gmail.com> wrote:
>
>
> On Sat, Jul 11, 2015 at 10:24 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
>
>> I think it would be more rational for them to keep mining on top of the
>> old block until they've fully validated the new block (which shouldn't take
>> so long anyway), even if this slightly increases the orphan rate.
>
>
> Increased orphan rate means that the network is (slightly) less secure.
>
> If miners have a 5% orphan rate, then an attacker can launch a 51% attack
> with 49% of the network.
>
> It isn't a massive difference, but it is there.
>
> As long as miners switch back to non-SPV mining after a timeout,
> SPV-mining is safe for everyone.
>
>
If there's any cost to non-SPV mining, and the chance that an incoming
block contains only valid transactions is very high, isn't there still an
incentive to make this timeout longer and longer?
The average cost to the miner from building on an invalid block is small,
> as long as invalid blocks only happen rarely.
>
>
Yes. If it's rare enough, then skipping transaction validation saves more
cost than the expected cost of mining atop an invalid block. ... but if
everyone follows that logic, the chance is no longer rare.
> Miners still have an incentive to do full validation, so that they can
> include transactions and get transaction fees.
>
>
This is a good point. If the benefit to skipping verification outweighs
expected transaction costs, then a non-validating miner might also choose
to mine empty blocks with only their coinbase. (I recall hearing this
occurred somewhat regularly around 2013, but I haven't paid attention since
then. How common are empty blocks these days?)
This is a benefit of the world where transaction fees approach or surpass
block reward.
SPV-mining is to prevent hashing hardware from having to waste power when
> it isn't needed.
>
>
It may be less of a problem if (when?) electricity costs dominate hardware
> capital costs.
>
Oh. This is a different explanation than Peter Todd's I linked to above,
which claimed it was network latency in receiving transactions.
Could you explain this a bit more? What is not needed, the hashing
hardware or the power? How does SPV Mining affect that?
I'll bet there are many individual rationales for SPV-Mining, but
ultimately they come down to dropping a cost based on a bet about other
miners' behavior.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--
Nathan Wilcox
Least Authoritarian
email: nathan at leastauthority.com
twitter: @least_nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150711/d25d7fea/attachment.html>

2023-06-07 15:41:56

- reply

📅 Original date posted:2015-07-11
📝 Original message:Thesis: The disincentive miners have for verifying transactions is
problematic and weakens the network's robustness against forks.
According to the 2015-07-04 bitcoin.org alert [1]_ so-called "SPV Mining"
has become popular across a large portion of miners, and this enabled the
consensus-violating forks to persist. Peter Todd provides an explanation
of the incentive for SPV Mining over in another thread [2]_.
.. [1] https://bitcoin.org/en/alert/2015-07-04-spv-mining#cause
.. [2]
https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg00404.html
If there is a cost to verifying transactions in a received block, then
there is an incentive to *not verify transactions*. However, this is
balanced by the a risk of mining atop an invalid block.
If we imagine all miners verify all transactions, except Charlie the
Cheapskate, then it's in Charlie's interest to forego transaction
verification. If all miners make a similar wager, then in the extreme,
no miners verify any transactions, and the expected cost of skipping
transaction verification becomes very high.
Unfortunately, it's difficult to measure how many miners are not
validating transactions, since there's no evidence of this until they
mine atop on invalid block. Because of this, I worry that over time,
more and more miners cut this particular corner, to save on costs.
If true, then the network continues to grow more brittle towards the kind
of forking-persistence behavior we saw from the July 4th (and 5th) forks.
This gets weird. For example, a malicious miner which suspects a large
fraction of miners are neglecting transaction verification may choose to
forego a block reward by throwing an erroneous transaction into their
winning block, then, as all the "SPV Miners" run off along a worthless
chain, they can reap a higher reward rate due to controlling a larger
network capacity fraction on the valid chain.
Can we fix this?
--
Nathan Wilcox
Least Authoritarian
email: nathan at leastauthority.com
twitter: @least_nathan
Standard Disclaimer: I'm behind on dev archives, irc logs, bitcointalk,
the wiki... if this has been discussed before I appreciate mentions of
that fact.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150711/1d90f07c/attachment-0001.html>

2023-06-07 15:39:38

- reply

📅 Original date posted:2015-06-22
📝 Original message:attack at dawn.
On Mon, Jun 22, 2015 at 10:46 AM, Richard Winder <richard at windstone.co.za>
wrote:
> awaiting transmission transmission
>
> On Mon, Jun 22, 2015 at 5:23 PM, Nathan Wilcox <nathan at leastauthority.com>
> wrote:
>
>> hello world.
>>
>> --
>> Nathan Wilcox
>> Least Authoritarian
>>
>> email: nathan at leastauthority.com
>> twitter: @least_nathan
>> PGP: 11169993 / AAAC 5675 E3F7 514C 67ED E9C9 3BFE 5263 1116 9993
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
--
Nathan Wilcox
Least Authoritarian
email: nathan at leastauthority.com
twitter: @least_nathan
PGP: 11169993 / AAAC 5675 E3F7 514C 67ED E9C9 3BFE 5263 1116 9993
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150622/07928fe3/attachment.html>

2023-06-07 15:39:38

- reply

📅 Original date posted:2015-06-22
📝 Original message:hello world.
--
Nathan Wilcox
Least Authoritarian
email: nathan at leastauthority.com
twitter: @least_nathan
PGP: 11169993 / AAAC 5675 E3F7 514C 67ED E9C9 3BFE 5263 1116 9993
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150622/a928cecb/attachment.html>

2023-06-07 15:37:21

- reply

📅 Original date posted:2015-06-11
📝 Original message:On Thu, Jun 11, 2015 at 7:10 AM, Peter Todd <pete at petertodd.org> wrote:
> On Wed, Jun 10, 2015 at 02:18:30PM -0700, Aaron Voisine wrote:
> > The other complication is that this will tend to be a lagging indicator
> > based on network congestion from the last time you connected. If we
> assume
> > that transactions are being dropped in an unpredictable way when blocks
> are
> > full, knowing the network congestion *right now* is critical, and even
> then
> > you just have to hope that someone who wants that space more than you do
> > doesn't show up after you disconnect.
>
> Hence the need for ways to increase fees on transactions after initial
> broadcast like replace-by-fee and child-pays-for-parent.
>
>
I haven't looked closely at replace-by-fee yet, but I assume this is a
non-consensus change to mempool mechanics. To me, this seems like the
"actuator" side of fee mechanics: it provides a transaction sender a way to
influence the system. By contrast, learning about fees is the "sensor"
side of fee mechanics.
Consider how a replace-by-fee wallet makes fee decisions. When does it
replace by fee? It needs feedback in one of two forms:
a. Direct feedback from a trnasaction relay service, or:
b. Information in the blockchain, which is verified by all verifying nodes
and refined by all miners.
The first kind of information is quite acceptable and practical for many
use cases, but leave the wallet vulnerable to fabrications by that service.
This vulnerability is precisely what SPV security intends to mitigate,
right?
With only information type a, a (non-SPV) wallet can "shop around" to find
competing services, and this should work pretty well, provided the wallet
can discover those competing services. If, OTOH, the wallet has access to
information type b, it now has "perfect competition" across all such
services, even when it can't discover the low-priced services directly.
This actual-fees-in-the-actual-block-chain information of type b seem like
a powerful source of pricing information, and if SPV security is already
valuable for other reasons, then it seems natural to leverage that value.
Re: "dropped in an unpredictable way" - transactions would be dropped
> lowest fee/KB first, a completely predictable way.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000124bae79afdcee9267b4e6f8137758b8b4135455cd8e3bfd
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Nathan Wilcox
Least Authoritarian
email: nathan at leastauthority.com
twitter: @least_nathan
PGP: 11169993 / AAAC 5675 E3F7 514C 67ED E9C9 3BFE 5263 1116 9993
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150611/6aed7d44/attachment.html>

2023-06-07 15:37:18

- reply

📅 Original date posted:2015-06-13
📝 Original message:On Thu, Jun 11, 2015 at 12:55 PM, Aaron Voisine <voisine at gmail.com> wrote:
> > A Header-PoW-verifying client could still be given all transactions in
> a recent block, from which it can see the in-band fees directly.
>
> You don't know the fees paid by any given transaction unless you also have
> all it's inputs. Transaction inputs do not include an amount. You could
> however get the average fee-per-kb paid by all transactions in a block by
> looking at the coinbase transaction, subtracting the block reward, and
> dividing by the size of block minus the header.
>
>
Excellent point and alternative proposal. You're right: to get the specifi
fees, you'd need all transactions in a block, and all TxOuts with
membership proofs. Your alternative seems like a much leaner trade-off for
similar data.
>
> Aaron Voisine
> co-founder and CEO
> breadwallet.com
>
> On Thu, Jun 11, 2015 at 11:30 AM, Nathan Wilcox <nathan at leastauthority.com
> > wrote:
>
>> On Wed, Jun 10, 2015 at 2:03 PM, Peter Todd <pete at petertodd.org> wrote:
>>
>>> On Wed, Jun 10, 2015 at 02:00:27PM -0600, Nathan Wilcox wrote:
>>> > On Wed, Jun 10, 2015 at 1:19 PM, Aaron Voisine <voisine at gmail.com>
>>> wrote:
>>> >
>>> > > It could be done by agreeing on a data format and encoding it in an
>>> > > op_return output in the coinbase transaction. If it catches on it
>>> could
>>> > > later be enforced with a soft fork.
>>> > >
>>> > >
>>> > Sounds plausible, except SPV protocols would need to include this
>>> coinbase
>>> > txn if it's going to help SPV clients. (Until a softfork is activated,
>>> SPV
>>> > clients should not rely on this encoding, since until that time the
>>> results
>>> > can be fabricated by individual miners.)
>>>
>>> Fee stats can always be fabricated by individual miners because fees can
>>> be paid out-of-band.
>>>
>>>
>> This is a point I hadn't considered carefully before. I don't understand
>> the marketplace here or why miners would want to move fees outside of
>> explicit inband fees. Implicit in this proposal is that the statistics only
>> cover in-band data, because that's the scope of consensus rules, and thus
>> the proposal is only as useful as the information of in-band fees is useful.
>>
>> I've also noticed a detracting technical argument given a particular
>> tradeoff:
>>
>> A Header-PoW-verifying client could still be given all transactions in a
>> recent block, from which it can see the in-band fees directly. The
>> trade-off is the size of those transactions versus the need to alter any
>> consensus rules or do soft forks.
>>
>> Notice how this trade-off's costs change with maximum block size.
>>
>>
>>
>>
>>> --
>>> 'peter'[:-1]@petertodd.org
>>> 00000000000000001245bd2f5c99379ee76836227ded9c08324894faabc0d27f
>>>
>>
>>
>>
>> --
>> Nathan Wilcox
>> Least Authoritarian
>>
>> email: nathan at leastauthority.com
>> twitter: @least_nathan
>> PGP: 11169993 / AAAC 5675 E3F7 514C 67ED E9C9 3BFE 5263 1116 9993
>>
>
>
--
Nathan Wilcox
Least Authoritarian
email: nathan at leastauthority.com
twitter: @least_nathan
PGP: 11169993 / AAAC 5675 E3F7 514C 67ED E9C9 3BFE 5263 1116 9993
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150613/d2787118/attachment.html>

2023-06-07 15:37:17

- reply

📅 Original date posted:2015-06-11
📝 Original message:On Wed, Jun 10, 2015 at 2:03 PM, Peter Todd <pete at petertodd.org> wrote:
> On Wed, Jun 10, 2015 at 02:00:27PM -0600, Nathan Wilcox wrote:
> > On Wed, Jun 10, 2015 at 1:19 PM, Aaron Voisine <voisine at gmail.com>
> wrote:
> >
> > > It could be done by agreeing on a data format and encoding it in an
> > > op_return output in the coinbase transaction. If it catches on it could
> > > later be enforced with a soft fork.
> > >
> > >
> > Sounds plausible, except SPV protocols would need to include this
> coinbase
> > txn if it's going to help SPV clients. (Until a softfork is activated,
> SPV
> > clients should not rely on this encoding, since until that time the
> results
> > can be fabricated by individual miners.)
>
> Fee stats can always be fabricated by individual miners because fees can
> be paid out-of-band.
>
>
This is a point I hadn't considered carefully before. I don't understand
the marketplace here or why miners would want to move fees outside of
explicit inband fees. Implicit in this proposal is that the statistics only
cover in-band data, because that's the scope of consensus rules, and thus
the proposal is only as useful as the information of in-band fees is useful.
I've also noticed a detracting technical argument given a particular
tradeoff:
A Header-PoW-verifying client could still be given all transactions in a
recent block, from which it can see the in-band fees directly. The
trade-off is the size of those transactions versus the need to alter any
consensus rules or do soft forks.
Notice how this trade-off's costs change with maximum block size.
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000001245bd2f5c99379ee76836227ded9c08324894faabc0d27f
>
--
Nathan Wilcox
Least Authoritarian
email: nathan at leastauthority.com
twitter: @least_nathan
PGP: 11169993 / AAAC 5675 E3F7 514C 67ED E9C9 3BFE 5263 1116 9993
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150611/ae77eddb/attachment.html>

2023-06-07 15:37:17

- reply

📅 Original date posted:2015-06-10
📝 Original message:On Wed, Jun 10, 2015 at 1:19 PM, Aaron Voisine <voisine at gmail.com> wrote:
> It could be done by agreeing on a data format and encoding it in an
> op_return output in the coinbase transaction. If it catches on it could
> later be enforced with a soft fork.
>
>
Sounds plausible, except SPV protocols would need to include this coinbase
txn if it's going to help SPV clients. (Until a softfork is activated, SPV
clients should not rely on this encoding, since until that time the results
can be fabricated by individual miners.)
> For real up-to-the-minute fee calculations you're also going to want to
> look at the current mempool, how many transactions are waiting, what fees
> they're paying, etc, but of course that information is susceptible to sybil
> attack.
>
Hm, when you mention Sybil attack, I don't quite follow.
When a client relies on any report of a mempool [*], this is already
outside the realm of locally-verifiable SPV information, so they are
already susceptible to the service making false claims. If that's
acceptable (and in many cases it may be) then this whole mechanism is moot,
because the client can ask the service for fee statistics for past blocks.
> In practice what we're doing for now is using services like blockcypher
> who's business is improving reliability of zero-conf to tell us what
> fee-per-kb is needed, and then putting a hard coded range around it to
> protect against the service being compromised.
>
This is interesting for me, because I had previously believed fees were
fairly static presently, and also because I like hearing about real life
wallet implementations.
So if this "SPV Fee Stats" feature were added, a wallet might rely on an
API for timely stats (aka "block height < 1") then verify that the API
isn't lying after doing SPV verification of fee stats for confirmed blocks.
This is also the kind of thing being done for exchange rate data which is
> probably the bigger security risk until bitcoin becomes the standard unit
> of account for the planet.
>
>
That makes sense, although there's no SPV equivalent for exchange data.
Aaron Voisine
> co-founder and CEO
> breadwallet.com
>
> On Wed, Jun 10, 2015 at 10:37 AM, Nathan Wilcox <nathan at leastauthority.com
> > wrote:
>
>> [I'm currently wading through bitcoin-development. I'm still about a
>> month behind, so I apologize in advance for any noisy redundancy in this
>> post.]
>>
>> While reading about blocksize, I've just finished Mike Hearn's blog post
>> describing expected systemic behavior as actual blocks approach the current
>> limit (with or without non-protocol-changing implementation improvements):
>>
>> https://medium.com/@octskyward/crash-landing-f5cc19908e32
>>
>>
>> One detail Mike uses to argue against the "fee's will save us" line of
>> reasoning is that wallets have no good way to learn fee information.
>>
>> So, here's a proposal to fix that: put fee and (and perhaps block size,
>> UTXO, etc...) statistics into the locally-verifiable data available to SPV
>> clients (ie: block headers).
>>
>>
>> It's easy to imagine a hard fork that places details like per-block total
>> fees, transaction count, fee variance, UTXO delta, etc... in a each block
>> header. This would allow SPV clients to rely on this data with the same
>> PoW-backed assurances as all other header data.
>>
>> This mechanism seems valuable regardless of the outcome of blocksize
>> debate. So long as fees are interesting or important, SPV clients should
>> know about them. (Same for other stats such as UTXO count.)
>>
>> Upgrading the protocol without a hard-fork may be possible and is left as
>> an exercise for the reader. ;-)
>>
>> --
>> Nathan Wilcox
>> Least Authoritarian
>>
>> email: nathan at leastauthority.com
>> twitter: @least_nathan
>> PGP: 11169993 / AAAC 5675 E3F7 514C 67ED E9C9 3BFE 5263 1116 9993
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
--
Nathan Wilcox
Least Authoritarian
email: nathan at leastauthority.com
twitter: @least_nathan
PGP: 11169993 / AAAC 5675 E3F7 514C 67ED E9C9 3BFE 5263 1116 9993
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150610/084827a1/attachment.html>

2023-06-07 15:37:16

- reply

📅 Original date posted:2015-06-10
📝 Original message:[I'm currently wading through bitcoin-development. I'm still about a month
behind, so I apologize in advance for any noisy redundancy in this post.]
While reading about blocksize, I've just finished Mike Hearn's blog post
describing expected systemic behavior as actual blocks approach the current
limit (with or without non-protocol-changing implementation improvements):
https://medium.com/@octskyward/crash-landing-f5cc19908e32
One detail Mike uses to argue against the "fee's will save us" line of
reasoning is that wallets have no good way to learn fee information.
So, here's a proposal to fix that: put fee and (and perhaps block size,
UTXO, etc...) statistics into the locally-verifiable data available to SPV
clients (ie: block headers).
It's easy to imagine a hard fork that places details like per-block total
fees, transaction count, fee variance, UTXO delta, etc... in a each block
header. This would allow SPV clients to rely on this data with the same
PoW-backed assurances as all other header data.
This mechanism seems valuable regardless of the outcome of blocksize
debate. So long as fees are interesting or important, SPV clients should
know about them. (Same for other stats such as UTXO count.)
Upgrading the protocol without a hard-fork may be possible and is left as
an exercise for the reader. ;-)
--
Nathan Wilcox
Least Authoritarian
email: nathan at leastauthority.com
twitter: @least_nathan
PGP: 11169993 / AAAC 5675 E3F7 514C 67ED E9C9 3BFE 5263 1116 9993
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150610/73fcaa85/attachment.html>