<unnamed>

Public Key

npub12g7q65me6tf93kfd4d0k8ffdvz52d56vumg3l8rqc0mykfrj02hs8xyand

Profile Code

nprofile1qqs9y0qd2dua95jcmyk6khmr55kkp29x6dxwd5gln3sv8ajty3e84tcpzpmhxue69uhkummnw3ezuamfdejsk80acl

Publishing to

nostr.wine

Last Notes

2023-06-07 18:06:35 UTC

- 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:05:54 UTC

- 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:39:38 UTC

- 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 UTC

- 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>