Alex Morcos [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-02-13 to 2022-01-13
💬 Posted a total of 47 messages
📚 Participated in the following categories: Bitcoin-development, softfork proposal, bitcoin-dev, BIP Proposal, Update
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub10z4xjfgftd3fm9dfu7dw6mkemgyhxgumcmhd7yd0ggjq7rsaw4wqa3xfzw

Profile Code

nprofile1qqs832nfy5y4kc5ajk570xhddmva5ztnywdudmklzxh5yfq0pcwh2hq9dhhq6

Author Public Key

npub10z4xjfgftd3fm9dfu7dw6mkemgyhxgumcmhd7yd0ggjq7rsaw4wqa3xfzw

Show more details

Last Notes

2023-06-07 23:02:11

- reply

📅 Original date posted:2022-01-13
📝 Original message:To belatedly answer Rene's question:
Yes, we hope so. To start, the Fund will focus on the defense of the
pending litigation and new litigation that may arise. However, we intend to
build up the capacity to provide competent third-party advice to developers
on strategies to reduce their liability.
On Tue, Jan 11, 2022 at 7:47 PM René Pickhardt <r.pickhardt at googlemail.com>
wrote:
>
>
> jack via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> schrieb am
> Mi., 12. Jan. 2022, 01:35:
>
>> To Bitcoin Developers:
>>
>> Open-source developers, who are often independent, are especially
>> susceptible to legal pressure.
>
>
> Will the fund eventually also help to educate developers about the risks
> they are facing and which measures can be taken to reduce such risks so
> that legal pressure might not even arise in the first place?
>
> The main purpose of this Fund is to defend developers from lawsuits
>> regarding their activities in the Bitcoin ecosystem, including finding and
>> retaining defense counsel, developing litigation strategy, and paying legal
>> bills. This is a free and voluntary option for developers to take advantage
>> of if they so wish.
>
>
> Thank you!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220113/2ed1b619/attachment-0001.html>

2023-06-07 18:12:02

- reply

📅 Original date posted:2018-05-10
📝 Original message:Fee rates in Bitcoin Core are measured in satoshis/kB. There are a couple
places where a minimum of 1000 satoshis/kB is assumed.
Setting "incrementalrelayfee" to a smaller than default value and either
leaving "minrelaytxfee" unset or also setting it smaller will be sufficient
to allow your node to accept and relay transactions with smaller fee
rates. Of course without the rest of the network making these changes
and/or the miners being willing to mine those transactions, it won't be of
much benefit.
Fee estimation doesn't distinguish fee rates less than 1000 sats/kB. This
would be more substantial to change.
On Thu, May 10, 2018 at 4:10 AM, st-bind--- via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Currently, the minimum fee of 1 satoshi per byte corresponds to about 0.09
> USD per kB, which is no longer insignificant. Maybe the time has come now
> to introduce more decimal places and make the minimum fee 1 of the new
> smallest unit. This way, everyday payments would again be possible with
> virtually no fee without flooding the mempool with free spam transactions.
> _______________________________________________
> 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/20180510/3dc06c7a/attachment.html>

2023-06-07 18:06:37

- reply

📅 Original date posted:2017-09-29
📝 Original message:I had the same concern, or a miner could fill the remainder of the block
with their own high fee paying transactions if blocks were required to be
full.
On Fri, Sep 29, 2017 at 7:55 AM Daniele Pinna via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Maybe I'm getting this wrong but wouldn't this scheme imply that a miner
> is incentivized to limit the amount of transactions in a block to capture
> the maximum fee of the ones included?
>
> As an example, mined blocks currently carry ~0.8 btc in fees right now. If
> I were to submit a transaction paying 1 btc in maximal money fees, then the
> miner would be incentivized to include my transaction alone to avoid that
> lower fee paying transactions reduce the amount of fees he can earn from my
> transaction alone. This would mean that I could literally clog the network
> by paying 1btc every ten minutes.
>
> Am I missing something?
>
> Daniele
> _______________________________________________
> 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/7873796c/attachment.html>

2023-06-07 18:05:51

- reply

📅 Original date posted:2017-09-11
📝 Original message:I don't think I know the right answer here, but I will point out two things
that make this a little more complicated.
1 - There are lots of altcoin developers and while I'm sure the majority
would greatly appreciate the disclosure and would behave responsibly with
the information, I don't know where you draw the line on who you tell and
who you don't.
2- Unlike other software, I'm not sure good security for bitcoin is defined
by constant upgrading. Obviously upgrading has an important benefit, but
one of the security considerations for Bitcoin is knowing that your
definition of the money hasn't changed. Much harder to know that if you
change software.
On Sun, Sep 10, 2017 at 10:15 PM, Anthony Towns via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sun, Sep 10, 2017 at 07:02:36PM -0400, Matt Corallo via bitcoin-dev
> wrote:
> > I believe there continues to be concern over a number of altcoins which
> > are running old, unpatched forks of Bitcoin Core, making it rather
> > difficult to disclose issues without putting people at risk (see, eg,
> > some of the dos issues which are preventing release of the alert key).
> > I'd encourage the list to have a discussion about what reasonable
> > approaches could be taken there.
>
> That seems like it just says bitcoin core has two classes of users:
> people who use it directly following mainnet or testnet, and people who
> make derived works based on it to run altcoins.
>
> Having a "responsible disclosure" timeline something like:
>
> * day -N: vulnerability reported privately
> * day -N+1: details shared amongst private trusted bitcoin core group
> * day 0: patch/workaround/mitigation determined, CVE reserved
> * day 1: basic information shared with small group of trusted users
> (eg, altcoin maintainers, exchanges, maybe wallet devs)
> * day ~7: patches can be included in git repo
> (without references to vulnerability)
> * day 90: release candidate with fix available
> * day 120: official release including fix
> * day 134: CVE published with details and acknowledgements
>
> could make sense. 90 days / 3 months is hopefully a fair strict upper
> bound for how long it should take to get a fix into a rc; but that's still
> a lot longer than many responsible disclosure timeframes, like CERT's at
> 45 days, but also shorter than some bitcoin core minor update cycles...
> Obviously, those timelines could be varied down if something is more
> urgent (or just easy).
>
> As it is, not publishing vulnerability info just seems like it gives
> everyone a false sense of security, and encourages ignoring good security
> practices, either not upgrading bitcoind nodes, or not ensuring altcoin
> implementations keep up to date...
>
> I suppose both "trusted bitcoin core group" and "small group of trusted
> users" isn't 100% cypherpunk, but it sure seems better than not both not
> disclosing vulnerability details, and not disclosing vulnerabilities
> at all... (And maybe it could be made more cypherpunk by, say, having
> the disclosures to trusted groups have the description/patches get
> automatically fuzzed to perhaps allow identification of leakers?)
>
> Cheers,
> aj
>
> > On 09/10/17 18:03, Simon Liu via bitcoin-dev wrote:
> > > Hi,
> > >
> > > Given today's presentation by Chris Jeffrey at the Breaking Bitcoin
> > > conference, and the subsequent discussion around responsible disclosure
> > > and industry practice, perhaps now would be a good time to discuss
> > > "Bitcoin and CVEs" which has gone unanswered for 6 months.
> > >
> > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-March/013751.html
> > >
> > > To quote:
> > >
> > > "Are there are any vulnerabilities in Bitcoin which have been fixed but
> > > not yet publicly disclosed? Is the following list of Bitcoin CVEs
> > > up-to-date?
> > >
> > > https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures
> > >
> > > There have been no new CVEs posted for almost three years, except for
> > > CVE-2015-3641, but there appears to be no information publicly
> available
> > > for that issue:
> > >
> > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3641
> > >
> > > It would be of great benefit to end users if the community of clients
> > > and altcoins derived from Bitcoin Core could be patched for any known
> > > vulnerabilities.
> > >
> > > Does anyone keep track of security related bugs and patches, where the
> > > defect severity is similar to those found on the CVE list above? If
> > > yes, can that list be shared with other developers?"
> > >
> > > Best Regards,
> > > Simon
> > > _______________________________________________
> > > 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
> _______________________________________________
> 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/20170911/e2ab7b78/attachment-0001.html>

2023-06-07 18:04:30

- reply

📅 Original date posted:2017-07-17
📝 Original message:"it was ACKed by everyone else that I heard from" - I don't think you
should read into that much.
I felt like this whole conversation was putting the cart before the horse.
You might very well have some good ideas in your roadmap update, to tell
you the truth, I didn't even read it.
But I don't think we should be taking relatively new/untested ideas such as
Drivechain and sticking them on a roadmap. There is a tendency in this
community to hear about the latest and greatest idea and immediately fixate
on it as our salvation. I'm very happy that you are doing this work and
that others are researching a wide variety of ideas. But please, lets be
conservative and flexible with how we evolve Bitcoin. We don't even know
if or when we'll get segwit yet.
On Mon, Jul 17, 2017 at 1:13 PM, Paul Sztorc via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello,
>
> Last week I posted about updating the Core Scalability Roadmap.
>
> I'm not sure what the future of it is, given that it was concept NACK'ed
> by Greg Maxwell the author of the original roadmap, who said that he
> regretted writing the first one.
>
> Nonetheless, it was ACKed by everyone else that I heard from, except for
> Tom Zander (who objected that it should be a specific project document,
> not a "Bitcoin" document -- I sortof agree and decided to label it a
> "Core" document -- whether or not anything happens with that label is up
> to the community).
>
> I therefore decided to:
> 1. Put the draft on GitHub [1]
> 2. Update it based on all of the week 1 feedback [2]
> 3. Add some spaces at the bottom for comments / expressions of interest [2]
>
> However, without interest from the maintainers of bitcoincore.org
> (specifically these [3, 4] pages and similar) the document will probably
> be unable to gain traction.
>
> Cheers,
> Paul
>
> [1] https://github.com/psztorc/btc-core-capacity-2/blob/master/draft.txt
> [2]
> https://github.com/psztorc/btc-core-capacity-2/commit/
> 2b4f0ecc9015ee398ce0486ca5c3613e3b929c00
> [3] https://bitcoincore.org/en/2015/12/21/capacity-increase/
> [4] https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/
>
>
> On 7/10/2017 12:50 PM, Paul Sztorc wrote:
> > Summary
> > =========
> >
> > In my opinion, Greg Maxwell's scaling roadmap [1] succeeded in a few
> > crucial ways. One success was that it synchronized the entire Bitcoin
> > community, helping to bring finality to the (endless) conversations of
> > that time, and get everyone back to work. However, I feel that the Dec
> > 7, 2015 roadmap is simply too old to serve this function any longer. We
> > should revise it: remove what has been accomplished, introduce new
> > innovations and approaches, and update deadlines and projections.
> >
> >
> > Why We Should Update the Roadmap
> > =================================
> >
> > In a P2P system like Bitcoin, we lack authoritative info-sources (for
> > example, a "textbook" or academic journal), and as a result
> > conversations tend to have a problematic lack of progress. They do not
> > "accumulate", as everyone must start over. Ironically, the scaling
> > conversation _itself_ has a fatal O(n^2) scaling problem.
> >
> > The roadmap helped solve these problems by being constant in size, and
> > subjecting itself to publication, endorsement, criticism, and so forth.
> > Despite the (unavoidable) nuance and complexity of each individual
> > opinion, it was at least globally known that X participants endorsed Y
> > set of claims.
> >
> > Unfortunately, the Dec 2015 roadmap is now 19 months old -- it is quite
> > obsolete and replacing it is long overdue. For example, it highlights
> > older items (CSV, compact blocks, versionbits) as being _future_
> > improvements, and makes no mention of new high-likelihood improvements
> > (Schnorr) or mis-emphasizes them (LN). It even contains mistakes (SegWit
> > fraud proofs). To read the old roadmap properly, one must already be a
> > technical expert. For me, this defeats the entire point of having one in
> > the first place.
> >
> > A new roadmap would be worth your attention, even if you didn't sign it,
> > because a refusal to sign would still be informative (and, therefore,
> > helpful)!
> >
> > So, with that in mind, let me present a first draft. Obviously, I am
> > strongly open to edits and feedback, because I have no way of knowing
> > everyone's opinions. I admit that I am partially campaigning for my
> > Drivechain project, and also for this "scalability"/"capacity"
> > distinction...that's because I believe in both and think they are
> > helpful. But please feel free to suggest edits.
> >
> > I emphasized concrete numbers, and concrete dates.
> >
> > And I did NOT necessarily write it from my own point of view, I tried
> > earnestly to capture a (useful) community view. So, let me know how I
> did.
> >
> > ==== Beginning of New ("July 2017") Roadmap Draft ====
> >
> > This document updates the previous roadmap [1] of Dec 2015. The older
> > statement endorsed a belief that "the community is ready to deliver on
> > its shared vision that addresses the needs of the system while upholding
> > its values".
> >
> > That belief has not changed, but the shared vision has certainly grown
> > sharper over the last 18 months. Below is a list of technologies which
> > either increase Bitcoin's maximum tps rate ("capacity"), or which make
> > it easier to process a higher volume of transactions ("scalability").
> >
> > First, over the past 18 months, the technical community has completed a
> > number of items [2] on the Dec 2015 roadmap. VersonBits (BIP 9) enables
> > Bitcoin to handle multiple soft fork upgrades at once. Compact Blocks
> > (BIP 152) allows for much faster block propagation, as does the FIBRE
> > Network [3]. Check Sequence Verify (BIP 112) allows trading partners to
> > mutually update an active transaction without writing it to the
> > blockchain (this helps to enable the Lightning Network).
> >
> > Second, Segregated Witness (BIP 141), which reorganizes data in blocks
> > to handle signatures separately, has been completed and awaits
> > activation (multiple BIPS). It is estimated to increase capacity by a
> > factor of 2.2. It also improves scalability in many ways. First, SW
> > includes a fee-policy which encourages users to minimize their impact on
> > the UTXO set. Second, SW achieves linear scaling of sighash operations,
> > which prevents the network from crashing when large transactions are
> > broadcast. Third, SW provides an efficiency gain for everyone who is not
> > verifying signatures, as these no longer need to be downloaded or
> > stored. SegWit is an enabling technology for the Lightning Network,
> > script versioning (specifically Schnorr signatures), and has a number of
> > benefits which
> > are unrelated to capacity [4].
> >
> > Third, the Lightning Network, which allows users to transact without
> > broadcasting to the network, is complete [5, 6] and awaits the
> > activation of SegWit. For those users who are able to make a single
> > on-chain transaction, it is estimated to increase both capacity and
> > scalability by a factor of ~1000 (although these capacity increases will
> > vary with usage patterns). LN also greatly improves transaction speed
> > and transaction privacy.
> >
> > Fourth, Transaction Compression [7], observes that Bitcoin transaction
> > serialization is not optimized for storage or network communication. If
> > transactions were optimally compressed (as is possible today), this
> > would improve scalability, but not capacity, by roughly 20%, and in some
> > cases over 30%.
> >
> > Fifth, Schnorr Signature Aggregation, which shrinks transactions by
> > allowing many transactions to have a single shared signature, has been
> > implemented [8] in draft form in libsecp256k1, and will likely be ready
> > by Q4 of 2016. One analysis [9] suggests that signature aggregation
> > would result in storage and bandwidth savings of at least 25%, which
> > would therefore increase scalability and capacity by a factor of 1.33.
> > The relative savings are even greater for multisignature transactions.
> >
> > Sixth, drivechain [10], which allows bitcoins to be temporarily
> > offloaded to 'alternative' blockchain networks ("sidechains"), is
> > currently under peer review and may be usable by end of 2017. Although
> > it has no impact on scalability, it does allow users to opt-in to
> > greater capacity, by moving their BTC to a new network (although, they
> > will achieve less decentralization as a result). Individual drivechains
> > may have different security tradeoffs (for example, a greater reliance
> > on UTXO commitments, or MimbleWimble's shrinking block history) which
> > may give them individually greater scalability than mainchain Bitcoin.
> >
> > Finally, the capacity improvements outlined above may not be sufficient.
> > If so, it may be necessary to use a hard fork to increase the blocksize
> > (and blockweight, sigops, etc) by a moderate amount. Such an increase
> > should take advantage of the existing research on hard forks, which is
> > substantial [11]. Specifically, there is some consensus that Spoonnet
> > [12] is the most attractive option for such a hardfork. There is
> > currently no consensus on a hard fork date, but there is a rough
> > consensus that one would require at least 6 months to coordinate
> > effectively, which would place it in the year 2018 at earliest.
> >
> > The above are only a small sample of current scaling technologies. And
> > even an exhaustive list of scaling technologies, would itself only be a
> > small sample of total Bitcoin innovation (which is proceeding at
> > breakneck speed).
> >
> > Signed,
> > <Names Here>
> >
> > [1]
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2015-December/011865.html
> > [2] https://bitcoincore.org/en/2017/03/13/performance-optimizations-1/
> > [3] http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/
> > [4] https://bitcoincore.org/en/2016/01/26/segwit-benefits/
> > [5]
> > http://lightning.community/release/software/lnd/
> lightning/2017/05/03/litening/
> > [6] https://github.com/ACINQ/eclair
> > [7] https://people.xiph.org/~greg/compacted_txn.txt
> > [8]
> > https://github.com/ElementsProject/secp256k1-zkp/blob/
> d78f12b04ec3d9f5744cd4c51f20951106b9c41a/src/secp256k1.c#L592-L594
> > [9] https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/
> > [10] http://www.drivechain.info/
> > [11] https://bitcoinhardforkresearch.github.io/
> > [12]
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-February/013542.html
> >
> > ==== End of Roadmap Draft ====
> >
> > In short, please let me know:
> >
> > 1. If you agree that it would be helpful if the roadmap were updated.
> > 2. To what extent, if any, you like this draft.
> > 3. Edits you would make (specifically, I wonder about Drivechain
> > thoughts and Hard Fork thoughts, particularly how to phrase the Hard
> > Fork date).
> >
> > Google Doc (if you're into that kind of thing):
> > https://docs.google.com/document/d/1gxcUnmYl7yM0oKR9NY9zCPbBbPNoc
> mCq-jjBOQSVH-A/edit?usp=sharing
> >
> > Cheers,
> > Paul
> >
>
>
> _______________________________________________
> 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/20170717/dc2b31ff/attachment-0001.html>

2023-06-07 17:57:49

- reply

📅 Original date posted:2017-03-26
📝 Original message:No I actually agree with a lot of what you said.
I feel there has been a lack of precision and consistency in talking about
these things in the past. This is not intentional, but its just what
happens when a lot of different people are all giving their own arguments.
I tried to be a bit more clear by talking about how soft forks have
historically been done. But certainly the technical definition of a soft
fork is a slippery slope. I completely disagree with the idea that miners
have any right to enforce a soft fork. Even more strongly, I don't think
they have the ability. Censoring a certain class of transactions (such as
those invalid under a soft fork) is something they can unilaterally do, but
it is not the same thing as a soft fork. It is necessarily transient. It
requires nodes to enforce the rules to make it a permanent soft fork.
I do think there are differences between soft forks and hard forks and
consensus requirements and safety for rolling them out. But as mentioned
in my email, I think soft forks should still have a very high bar for
consensus. It's an open question as to whether Core misjudged this for
segwit, although if so, I think it was a close call. The intention is not
to let 95% of miners make the rules (although again, note that it is 95%, a
very high bar, vastly different than 75% of miners). It seems to me that
the vast majority of the community is in favor of segwit. I'm not sure
about your comment that it is obvious to an observer than a sizable portion
of the community is opposed. It is certainly some, and perhaps more than
expected. But this is exactly why the new version bits soft fork roll out
mechanism allows proposals to expire. We did do an extensive job assessing
support for segwit before roll out, and although we knew of a few loud
voices against we judged them to be a very small minority. No business we
contacted was opposed. If it turns out we got it wrong then the proposal
will expire harmlessly. I for one am certainly opposed to forcing segwit
or any other fork of any kind on a significant minority that is opposed.
Despite saying that, I think you will hear some other responses about how
soft forks are opt-in and if you don't like the new features don't use
them. There is some logic behind this idea. But these are all subtleties
which are hard to make strong right and wrong statements about. See some
of the past discussion on this list.
On Sun, Mar 26, 2017 at 4:13 AM, Chris Pacia <ctpacia at gmail.com> wrote:
>
>
> On Mar 25, 2017 10:38 PM, "Alex Morcos via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> As a Bitcoin user I find it abhorrent the way you are proposing to
> intentionally cripple the chain and rules I want to use instead of just
> peacefully splitting.
>
>
> I just want to point out what appears to be doublespeak going on here.
>
> First, I think it would seem obvious to an observer that a sizable portion
> of the community (certainly greater than 5%) view segwit as preventing
> "rules I want to use instead of just peacefully splitting" but no
> consideration was given to these people when designing segwit as a
> softfork. I believe it was Luke who went as far as saying consensus does
> not matter when it comes softforks.
>
> Furthermore, when segwit was first introduced it kicked off a round of
> softfork/hardfork debate which I participated in. The primary concern that
> I and other raised was precisely what is going on now.. that miners could
> unilaterally impose an unpopular change to the protocol rules.
>
> At the time I told, rather forcefully, by multiple people that miners have
> an "absolute right" to softfork in whatever rules they want. Which, of
> course, is absurd on it's face.
>
> But I don't see how people can make such claims on the one hand, and then
> complain when this process is used against them.
>
> It amounts to nothing more than "When it's rules I like we get to impose
> them on non-consenting users. When it's rules I don't like it's an attack
> on the network".
>
> It was completely obvious this entire time that softforks were a very
> slippery slope, now we are indeed sliding down that slope.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170326/1bd8ed19/attachment.html>

2023-06-07 17:57:48

- reply

📅 Original date posted:2017-03-25
📝 Original message:Surely you are aware that what you are proposing is vastly different from
the way soft forks have historically worked.
First of all, the bar for miners being on the new chain is extremely high,
95%.
Second of all, soft forks make rule restrictions on classes of transactions
that are already non-standard so that any non-upgraded miners are unlikely
to be including txs in their blocks which would violate the new rules and
should not have their blocks orphaned even after the fork.
Finally, soft forks are designed to only be used when there is a very wide
community consensus and the intention is not to overrule anyone's choice to
remain on the old rules but to ensure the security of nodes that may have
neglected to upgrade. Obviously it is impossible to draw a bright line
between users who intentionally are not upgrading due to opposition and
users that are just being lazy. But in the case of a proposed BU hard fork
it is abundantly clear that there is a very significant fraction, in fact
likely a majority of users who intentionally want to remain on the old
rules.
As a Bitcoin user I find it abhorrent the way you are proposing to
intentionally cripple the chain and rules I want to use instead of just
peacefully splitting.
On Sat, Mar 25, 2017 at 3:28 PM, Peter R via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> One of the purported benefits of a soft-forking change (a tightening of
> the consensus rule set) is the reduced risk of a blockchain split compared
> to a loosening of the consensus rule set. The way this works is that
> miners who fail to upgrade to the new tighter ruleset will have their
> non-compliant blocks orphaned by the hash power majority. This is a strong
> incentive to upgrade and has historically worked well. If a minority
> subset of the network didn’t want to abide by the new restricted rule set,
> a reasonable solution would be for them to change the proof-of-work and
> start a spin-off from the existing Bitcoin ledger (
> https://bitcointalk.org/index.php?topic=563972.0).
>
> In the case of the coming network upgrade to larger blocks, a primary
> concern of both business such as Coinbase and Bitpay, and most miners, is
> the possibility of a blockchain split and the associated confusion, replay
> risk, etc. By applying techniques that are known to be successful for
> soft-forking changes, we can likewise benefit in a way that makes a split
> less likely as we move towards larger blocks. Two proposed techniques to
> reduce the chances of a split are:
>
> 1. That miners begin to orphan the blocks of non-upgraded miners once a
> super-majority of the network hash power has upgraded. This would serve as
> an expensive-to-ignore reminder to upgrade.
>
> 2. That, in the case where a minority branch emerges (unlikely IMO),
> majority miners would continually re-org that minority branch with empty
> blocks to prevent transactions from confirming, thereby eliminating replay
> risk.
>
> Just like after a soft forking change, a minority that does not want to
> abide by the current ruleset enforced by the majority could change the
> proof-of-work and start a spin-off from the existing Bitcoin ledger, as
> suggested by Emin.
>
> Best regards,
> Peter R
>
>
> > On Mar 25, 2017, at 9:12 AM, CANNON via bitcoin-dev <bitcoin-dev at lists.
> linuxfoundation.org> wrote:
> >
> > On 03/24/2017 07:00 PM, Aymeric Vitte wrote:
> >> I don't know what "Time is running short I fear" stands for and when 50%
> >> is supposed to be reached
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> >
> > On 03/24/2017 07:00 PM, Aymeric Vitte wrote: > I don't know what
> > "Time is running short I fear" stands for and when 50% > is supposed
> > to be reached
> >
> > According to current hashrate distribution tracking site coin.dance,
> > very likely within less than four weeks according to current hashrate
> > takeover rate.
> >
> > While a fork is very likely, that I dont really fear because worst
> > case scenario is that bitcoin still survives and the invalid chain
> > becomes an alt. My fear is the centralized mining power being used
> > to attack the valid chain with intentions on killing it. [1]
> >
> > Shouldn't this 50% attack they are threatening be a concern? If it
> > is a concern, what options are on the table. If it is not a concern
> > please enlightent me as to why.
> >
> >
> > [1] Source:
> > https://www.reddit.com/r/Bitcoin/comments/6172s3/peter_
> rizun_tells_miners_to_force_a_hard_fork_by/
> >
> > Text:
> >
> > The attack quoted from his article:
> > https://medium.com/@peter_r/on-the-emerging-consensus-
> regarding-bitcoins-block-size-limit-insights-from-my-visit-
> with-2348878a16d8
> >
> > [Level 2] Anti-split protection Miners will orphan the
> > blocks of non-compliant miners prior to the first larger block
> > to serve as a reminder to upgrade. Simply due to the possibility
> > of having blocks orphaned, all miners would be motivated to
> > begin signalling for larger blocks once support definitively
> > passes 51%. If some miners hold out (e.g., they may not be
> > paying attention regarding the upgrade), then they will begin
> > to pay attention after losing approximately $15,000 of revenue
> > due to an orphaned block.
> >
> > [Level 3] Anti-split protection In the scenario where Levels
> > 1 and 2 protection fails to entice all non-compliant miners to
> > upgrade, a small-block minority chain may emerge. To address the
> > risk of coins being spent on this chain (replay risk), majority
> > miners will deploy hash power as needed to ensure the minority
> > chain includes only empty blocks after the forking point. This
> > can easily be accomplished if the majority miners maintain a
> > secret chain of empty blocks built off their last empty
> > block publishing only as much of this chain as necessary
> > to orphan any non-empty blocks produced on the minority chain.
> >
> >
> >
> >
> > - --
> > Cannon
> > PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
> > Email: cannon at cannon-ciota.info
> >
> > NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD
> > BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
> > If this matters to you, use PGP.
> > -----BEGIN PGP SIGNATURE-----
> >
> > iQIcBAEBCgAGBQJY1pbaAAoJEAYDai9lH2mwOO0QANOWqGzPNlifWguc+Y5UQxQM
> > eAiztAayQBoAyLcFE7/qdtSNlUxbIAHG17fM+aNkehjYH2oN5ODJ+j7E2Yt6EoUH
> > h5t8MLhNRG/YGF1hJK8Io940EmdcjuNmohiZvrjIqEOYggmLU3hR6J4gsuGsQQhu
> > gY3sMS/TtT+gZNH8w53ePGrsVhuQR7yEMMr91/vM4+Q5abpwqLeYLnslaZDcd3XK
> > VB9vyyK08r34J1GQt/H4UvTvGs28MFKBkvueA/Sfyvnrih7+WSQLuSvhiFr+cW1B
> > TmSVYrB2DzyHN27jDCI2ty3ryNE4PMYcaeLfI2TTbsD/MuVU5lK0kM/1JajP4eRj
> > j+P03OipuQiy/dNU63w0Uka2PbdKhDC13hVtK/ttBbNppbjnGeB9PYSJCzOpInGw
> > NwAyz0rVS/llGsdctcII7Z6AUMGuJXzsosY8vjUroU+KFRDqIbDfC53sH7DaPh7u
> > YawwId5S5RnZsAGCUJ+qNcg0s728J1eDjofN291IS5sOKMzpI7KhaOhFxjnk1MpN
> > ZAlQeTlvG+sAdn61QMQK1NbFt0km+jcqyVh0+L01yB0K4VDi1YFJaSBOaYUELBXa
> > 8a6WhZf5nrl5UIpH7rRcPzzqchcdYczy5VRZp2UsU+HYeqLXlcN0a03yPpVQik9S
> > /T93MuZgmvSCry5MlccA
> > =R71g
> > -----END PGP SIGNATURE-----
> >
> > _______________________________________________
> > 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/20170325/16187c21/attachment.html>

2023-06-07 17:54:27

- reply

📅 Original date posted:2016-11-17
📝 Original message:I think this conversation has gone off the rails and is no longer really
appropriate for the list.
But just to be clear to any readers. Bitcoin Core absolutely does rely on
the impossibility of a hash collision for maintaining consensus. This
happens in multiple places in the code but in particular we don't check
BIP30 any more since the only way it could get violated is by a hash
collision.
On Thu, Nov 17, 2016 at 6:22 AM, Eric Voskuil via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On 11/17/2016 02:22 AM, Tier Nolan via bitcoin-dev wrote:
> > On Thu, Nov 17, 2016 at 12:43 AM, Eric Voskuil <eric at voskuil.org
> > <mailto:eric at voskuil.org>> wrote:
> >
> > > This means that all future transactions will have different
> txids...
> > rules do guarantee it.
> >
> > No, it means that the chance is small, there is a difference.
> >
> > I think we are mostly in agreement then? It is just terminology.
>
> Sure, if you accept that mostly is not fully - just as unlikely is not
> impossible.
>
> > In terms of discussing the BIP, barring a hash collision, it does make
> > duplicate txids impossible.
>
> That's like saying, as long as we exclude car accidents from
> consideration, car accidents are impossible.
>
> > Given that a hash collision is so unlikely, the qualifier should be
> > added to those making claims that require hash collisions rather than
> > those who assume that they aren't possible.
> >
> > You could have said "However nothing precludes different txs from having
> > the same hash, but it requires a hash collision".
>
> I generally try to avoid speaking in tautologies :)
>
> > Thinking about it, a re-org to before the enforcement height could allow
> > it. The checkpoints protect against that though.
> >
> > As such this is not something that a node
> > can just dismiss.
> >
> > The security of many parts of the system is based on hash collisions not
> > being possible.
>
> This is not the case.
>
> Block hash duplicates within the same chain are invalid as a matter of
> consensus, which is the opposite of assuming impossibility.
>
> Tx hash collisions are explicitly allowed in the case that preceding tx
> with the same hash is unspent. This is also not a reliance on the
> impossibility of hash collision. Core certainly implements this
> distinction:
>
> https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2419-L2426
>
> Address hashes and script hashes can collide without harming the
> security of Bitcoin (although address owner(s) may experience harm).
> Rare in this case is sufficient because of this distinction.
>
> Compact blocks contemplates hash collisions:
>
> https://github.com/bitcoin/bips/blob/master/bip-0152.
> mediawiki#Random_collision_probabilty
>
> Checkpoints aren't part of Bitcoin security, so even the remote
> possibility of two different potential blocks, with the same hash, at
> the same height in the same chain, does not indicate a problem.
>
> There is no case where the security of Bitcoin assumes that hashes never
> collide. Consensus rules have specific handling for both block hash
> collisions and tx hash collisions.
>
> e
>
>
> _______________________________________________
> 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/20161117/dc2d9d3c/attachment-0001.html>

2023-06-07 17:54:21

- reply

📅 Original date posted:2016-11-16
📝 Original message:huh?
can you give an example of how a duplicate transaction hash (in the same
chain) can happen given BIP34?
On Wed, Nov 16, 2016 at 7:00 PM, Eric Voskuil via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On 11/16/2016 03:58 PM, Jorge Timón via bitcoin-dev wrote:
> > On Wed, Nov 16, 2016 at 3:18 PM, Thomas Kerin via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> BIP30 actually was given similar treatment after a reasonable amount of
> time
> >> had passed.
> >> https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2392
> >
> > This is not really the same. BIP30 is not validated after BIP34 is
> > active because blocks complying with BIP34 will always necessarily
> > comply with BIP30 (ie coinbases cannot be duplicated after they
> > include the block height).
>
> This is a misinterpretation of BIP30. Duplicate transaction hashes can
> and will happen and are perfectly valid in Bitcoin. BIP34 does not
> prevent this.
>
> e
>
>
> _______________________________________________
> 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/20161116/31f43652/attachment.html>

2023-06-07 17:54:19

- reply

📅 Original date posted:2016-11-16
📝 Original message:I think we are misunderstanding the effect of this change.
It's still "OK" for a 50k re-org to happen.
We're just saying that if it does, we will now have potentially introduced
a hard fork between new client and old clients if the reorg contains
earlier signaling for the most recent ISM soft fork and then blocks which
do not conform to that soft fork before the block height encoded activation.
I think the argument is this doesn't substantially add to the confusion or
usability of the system as its likely that old software won't even handle
50k block reorgs cleanly anyway and there will clearly have to be human
coordination at the time of the event. In the unlikely event that the new
chain does cause such a hard fork, that coordination can result in everyone
upgrading to software that supports the new rules anyway.
So no, I don't think we should add a checkpoint. I think we should all
just agree to a hard fork that only has a very very slim chance of any
practical effect.
In response to Thomas' email. I think ideally we would treat these soft
forks the way we did BIP30 which is to say that we're just introducing a
further soft fork that applies to all blocks except for the historical
exceptions. So then its a almost no-op soft fork with no risk of hard
fork. This however isn't practical with at least BIP 34 without storing
the hashes of all 200K blocks that don't meet the requirement.
On Wed, Nov 16, 2016 at 9:18 AM, Tier Nolan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Nov 16, 2016 at 1:58 PM, Eric Voskuil via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Are checkpoints good now? Are hard forks okay now?
>>
>
> I think that at least one checkpoint should be included. The assumption
> is that no 50k re-orgs will happen, and that assumption should be directly
> checked.
>
> Checkpointing only needs to happen during the headers-first part of the
> download.
>
> If the block at the BIP-65 height is checkpointed, then the comparisons
> for the other ones are automatically correct. They are unnecessary, since
> the checkpoint protects all earlier block, but many people would like to be
> able to verify the legacy chain.
>
> This makes the change a soft-fork rather than a hard fork. Chains that
> don't go through the checkpoint are rejected but no new chains are allowed.
>
> _______________________________________________
> 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/20161116/5e407283/attachment-0001.html>

2023-06-07 17:49:54

- reply

📅 Original date posted:2016-03-18
📝 Original message:Following on my earlier message
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-March/012485.html>,
I am happy to announce a new soft fork to be deployed using BIP 9
<https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki> - Version
bits.
Please review BIP 9
<https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki> as it has
been updated for information on how Version bits soft forks activate.
This deployment is being referred to as CSV (CheckSequenceVerify) and will
activate the following 3 BIPS as consensus rules:
BIP 68 <https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki> -
Relative lock-time using consensus-enforced sequence numbers
BIP 112 <https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki> -
CHECKSEQUENCEVERIFY
BIP 113 <https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki> -
Median time-past as endpoint for lock-time calculations
These BIP's have been updated with the deployment information:
bit: 0
startTime: 1462060800 "May 1st, 2016" (mainnet)
1456790400 "March 1st, 2016" (testnet)
endTime: 1493596800 "May 1st, 2017" (mainnet and testnet)
Bitcoin Core will release 0.11.3 and 0.12.1 software which implements these
soft forks in the near future.
Thanks,
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160318/1286d40a/attachment.html>

2023-06-07 17:49:25

- reply

📅 Original date posted:2016-03-01
📝 Original message:Bitcoin Core is ready to move towards deployment of a soft fork which will
implement BIP's 68, 112, and 113.
BIP 68 - Relative lock-time using consensus-enforced sequence numbers -
https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki
BIP 112 - CHECKSEQUENCEVERIFY -
https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki
BIP 113 - Median time-past as endpoint for lock-time calculations -
https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki
BIP 113 logic was introduced in the 0.11.2 release as a standardness rule
and BIP 68 and BIP 112 logic has been merged into master*.
What remains to be done is finish testing, merge the logic to activate the
soft forks and backport the code to supported releases.
The exact rollout mechanism is still being finalized but will be
coordinated with the community.
This email is meant to serve as a readiness announcement and confirm that
there are no outstanding concerns.
Thanks,
Alex
* - BIP 68 and BIP 112 logic is only enforced when the tx version is >= 2
which will only become standard with the release of the soft fork code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160301/f118cd50/attachment.html>

2023-06-07 17:49:12

- reply

📅 Original date posted:2016-02-17
📝 Original message:On Tue, Feb 16, 2016 at 6:46 PM, Luke Dashjr <luke at dashjr.org> wrote:
> On Tuesday, February 16, 2016 8:20:26 PM Alex Morcos via bitcoin-dev wrote:
> > # The feefilter message is defined as a message containing an int64_t
> where
> > pchCommand == "feefilter"
>
> What happened to extensibility? And why waste 64 bits for what is almost
> certainly a small number?
>
I thought that extensibility was already sufficient with the command string
system. If we come up with a better version of the feefilter later we can
just give it a different command name. This seemed to encapsulate a fairly
complete idea for now. As for the 8 bytes, it didn't seem necessary to me
to over optimize with a custom encoding for what amounts to well under 20%
of ping traffic. (pings are sent every 2 mins per peer, feefilters on
average every 10 mins, but when the quantized value to be sent would be the
same it is skipped)
> > # The fee filter is additive with a bloom filter for transactions so if
> an
> > SPV client were to load a bloom filter and send a feefilter message,
> > transactions would only be relayed if they passed both filters.
>
> This seems to make feefilter entirely useless for wallets?
>
>
I don't follow this comment? Transactions aren't synced with the wallet
unless they are accepted into the mempool. Sending feefilter messages
should not reduce the number of transactions that are accepted to the
mempool.
> Luke
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160216/08d950a6/attachment.html>

2023-06-07 17:49:11

- reply

📅 Original date posted:2016-02-16
📝 Original message:Hi,
I'm proposing the addition of a new optional p2p message to help reduce
unnecessary network traffic. The draft BIP is available here and pasted
below:
https://gist.github.com/morcos/9aab223c443c9258c979
The goal of this message is to take advantage of the fact that when a node
has reached its mempool limit, there is a minimum fee below which no
transactions are accepted to the mempool. Informing peers of this minimum
would save them inv'ing your node for those transaction id's and save your
node requesting them if they are not in your recentRejects filter.
This message is optional and may be ignored as a protocol rule. There is
also an option to turn off sending the messages in the implementation.
Thanks to Suhas Daftuar, Greg Maxwell, and others for helping develop the
idea.
-Alex
Draft BIP text:
<pre>
BIP: <unassigned>
Title: feefilter message
Author: Alex Morcos <morcos at chaincode.com>
Status: Draft
Type: Standards Track
Created: 2016-02-13
</pre>
==Abstract==
Add a new message, "feefilter", which serves to instruct peers not to send
"inv"'s to the node for transactions with fees below the specified fee rate.
==Motivation==
The concept of a limited mempool was introduced in Bitcoin Core 0.12 to
provide protection against attacks or spam transactions of low fees that
are not being mined. A reject filter was also introduced to help prevent
repeated requests for the same transaction that might have been recently
rejected for insufficient fee. These methods help keep resource utilization
on a node from getting out of control.
However, there are limitations to the effectiveness of these approaches.
The reject filter is reset after every block which means transactions that
are inv'ed over a longer time period will be rerequested and there is no
method to prevent requesting the transaction the first time. Furthermore,
inv data is sent at least once either to or from each peer for every
transaction accepted to the mempool and there is no mechanism by which to
know that an inv sent to a given peer would not result in a getdata request
because it represents a transaction with too little fee.
After receiving a feefilter message, a node can know before sending an inv
that a given transaction's fee rate is below the minimum currently required
by a given peer, and therefore the node can skip relaying an inv for that
transaction to that peer.
==Specification==
# The feefilter message is defined as a message containing an int64_t where
pchCommand == "feefilter"
# Upon receipt of a "feefilter" message, the node will be permitted, but
not required, to filter transaction invs for transactions that fall below
the feerate provided in the feefilter message interpreted as satoshis per
kilobyte.
# The fee filter is additive with a bloom filter for transactions so if an
SPV client were to load a bloom filter and send a feefilter message,
transactions would only be relayed if they passed both filters.
# Inv's generated from a mempool message are also subject to a fee filter
if it exists.
# Feature discovery is enabled by checking protocol version >= 70013
==Considerations==
The propagation efficiency of transactions across the network should not be
adversely affected by this change. In general, transactions which are not
accepted to your mempool are not relayed and the funcionality implemented
with this message is meant only to filter those transactions. There could
be a small number of edge cases where a node's mempool min fee is actually
less than the filter value a peer is aware of and transactions with fee
rates between these values will now be newly inhibited.
Feefilter messages are not sent to whitelisted peers if the
"-whitelistforcerelay" option is set. In that case, transactions are
intended to be relayed even if they are not accepted to the mempool.
There are privacy concerns with deanonymizing a node by the fact that it is
broadcasting identifying information about its mempool min fee. To help
ameliorate this concern, the implementaion quantizes the filter value
broadcast with a small amount of randomness, in addition, the messages are
broadcast to different peers at individually randomly distributed times.
If a node is using prioritisetransaction to accept transactions whose
actual fee rates might fall below the node's mempool min fee, it may want
to consider setting "-nofeefilter" to make sure it is exposed to all
possible txid's.
==Backward compatibility==
Older clients remain fully compatible and interoperable after this change.
The sending of feefilter messages can be disabled by unsetting the
"-feefilter" option.
==Implementation==
https://github.com/bitcoin/bitcoin/pull/7542
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160216/88e18afc/attachment-0001.html>

2023-06-07 17:48:43

- reply

📅 Original date posted:2016-02-07
📝 Original message:I apologize if this discussion should be moved to -discuss, I'll let the
moderators decide, I've copied both.
And Gavin, I apologize for picking on you here, because certainly this
carelessness in how people represent "facts" applies to both sides, but
much of this discussion really infuriates me.
I believe it is completely irresponsible for you to state:
"There will be approximately zero percentage of hash power left on the
weaker branch of the fork, based on past soft-fork adoption by miners"
Sure, the rest of the technical community is capable of evaluating that for
themselves, but your statements are considered authoritative by much larger
audience. In truth, no one has any idea what would happen if the proposed
Classic hard fork activated with 75% right now. There is some chance you
are right, but there is a very legitimate possibility that a concerted
effort would arise to maintain a minority fork or perhaps if miners don't
see nearly a complete switch over, many of them might themselves reverse
the fork if they think it would be easier to achieve consensus that way.
We as a community have never been in such a situation before and it
behooves us to speak honestly and directly about the uncertainty of the
situation.
And the back and forth discussion over your BIP has been in large part a
charade. People asking why you aren't picking 95% know very well why you
aren't, but lets have an honest discussion of what the risks and in your
mind potential benefits of 75% are. Important debate about parameters of
your BIP get lost because we're sniping at each other about known
disagreements. For instance, I strongly believe 28 days is far too short.
I think its extremely unlikely that those who are opposed to a contentious
hard fork will do the development work to prepare for it as that may only
make it more likely to happen. Thus if you did achieve activation with
75%, its almost impossible to imagine that if Bitcoin Core decided to come
along (as opposed to pursuing a minority fork) that they'd have the time to
develop and test the patch and roll it out to wide adoption. If the goal
of your attempt is that any minority that disagreed will "choose" to follow
the majority branch, then you'd be much more likely to achieve that by
giving them time to decide that's what they wanted and roll out the
software to do so.
On Sun, Feb 7, 2016 at 9:16 AM, Gavin Andresen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-dev
>> wrote:
>> > On Saturday, February 06, 2016 06:09:21 PM Jorge Timón via bitcoin-dev
>> wrote:
>> > > None of the reasons you list say anything about the fact that "being
>> > > lost" (kicked out of the network) is a problem for those node's users.
>> >
>> > That's because its not.
>> >
>> > If you have a node that is "old" your node will stop getting new blocks.
>> > The node will essentially just say "x-hours behind" with "x" getting
>> larger
>> > every hour. Funds don't get confirmed. etc.
>>
>> Until someone decides to attack you. Then you'll get 6, 10, maybe more
>> blocks
>> confirming a large 10000 BTC payment. If you're just a normal end user (or
>> perhaps an automated system), you'll figure that payment is good and
>> irreversibly hand over the title to the house.
>>
>
> There will be approximately zero percentage of hash power left on the
> weaker branch of the fork, based on past soft-fork adoption by miners (they
> upgrade VERY quickly from 75% to over 95%).
>
> So it will take a week to get 6 confirmations.
>
> If you are a full node, you are warned that your software is obsolete and
> you must upgrade.
>
> If you are a lightweight node, it SHOULD tell you something is wrong, but
> even if it doesn't, given that people running lightweight nodes run them so
> they don't have to be connected to the network 24/7, it is very likely
> during that week you disconnect and reconnect to the network several times.
> And every time you do that you increase your chances that you will connect
> to full nodes on the majority branch of the chain, where you will be told
> about the double-spend.
>
> All of that is assuming that there is no OTHER mitigation done. DNS seeds
> should avoid reporting nodes that look like they are in the middle of
> initial block download (that are at a block height significantly behind the
> rest of the network), for example.
>
> --
> --
> Gavin Andresen
>
>
> _______________________________________________
> 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/20160207/b8871116/attachment-0001.html>

2023-06-07 17:45:49

- reply

📅 Original date posted:2015-12-21
📝 Original message:I'm also strongly in favor of moving forward with this plan.
A couple of points:
1) There has been too much confusion in looking at segwit as an alternative
way to increase the block size and I think that is incorrect. It should
not be drawn into the block size debate as it brings many needed
improvements and tools we'd want even if no one were worried about block
size now.
2) The full capacity increase plan Greg lays out makes it clear that we can
accomplish a tremendous amount without a contentious hard fork at this
point.
3) Let's stop arguing endlessly and actually do work that will benefit
everyone.
On Sun, Dec 20, 2015 at 11:33 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Tue, Dec 8, 2015 at 6:07 AM, Wladimir J. van der Laan wrote:
> > On Mon, Dec 07, 2015 at 10:02:17PM +0000, Gregory Maxwell via
> bitcoin-dev wrote:
> >> TL;DR: I propose we work immediately towards the segwit 4MB block
> >> soft-fork which increases capacity and scalability, and recent speedups
> >> and incoming relay improvements make segwit a reasonable risk. BIP9
> >> and segwit will also make further improvements easier and faster to
> >> deploy. We’ll continue to set the stage for non-bandwidth-increase-based
> >> scaling, while building additional tools that would make bandwidth
> >> increases safer long term. Further work will prepare Bitcoin for further
> >> increases, which will become possible when justified, while also
> providing
> >> the groundwork to make them justifiable.
> >
> > Sounds good to me.
>
> Better late than never, let me comment on why I believe pursuing this plan
> is important.
>
> For months, the block size debate, and the apparent need for agreement on
> a hardfork has distracted from needed engineering work, fed the external
> impression that nothing is being done, and generally created a toxic
> environment to work in. It has affected my own productivity and health, and
> I do not think I am alone.
>
> I believe that soft-fork segwit can help us out of this deadlock and get
> us going again. It does not require the pervasive assumption that the
> entire world will simultaneously switch to new consensus rules like a
> hardfork does, while at the same time:
> * Give a short-term capacity bump
> * Show the world that scalability is being worked on
> * Actually improve scalability (as opposed to just scale) by reducing
> bandwidth/storage and indirectly improving the effectiveness of systems
> like Lightning.
> * Solve several unrelated problems at the same time (fraud proofs, script
> extensibility, malleability, ...).
>
> So I'd like to ask the community that we work towards this plan, as it
> allows to make progress without being forced to make a possibly divisive
> choice for one hardfork or another yet.
>
> --
> Pieter
>
> _______________________________________________
> 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/20151220/727153dd/attachment.html>

2023-06-07 17:44:34

- reply

📅 Original date posted:2015-11-12
📝 Original message:I just wanted to let everyone know that after much considered review, new
lower policy limits on the number and size of related unconfirmed
transactions that will be accepted in to the mempool and relayed have been
merged into the master branch of Bitcoin Core for 0.12 release.
The actual limits were merged in PR 6771
<https://github.com/bitcoin/bitcoin/pull/6771> and discussion of these
limits can be found in this previous email
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010221.html>
to the dev list and discussion of the new lower limits here
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011401.html>
.
The new limits are:
25 unconfirmed ancestors
25 unconfirmed descendants
101kb total size with unconfirmed ancestors
101kb total size with unconfirmed descendants.
These limits are just policy and do not affect consensus.
They can be modified by command line arguments.
Thanks,
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151112/90b6a2ad/attachment.html>

2023-06-07 17:44:33

- reply

📅 Original date posted:2015-11-12
📝 Original message:To be clear Luke, its not THAT complicated to maintain the mining policy,
but preserving the ability of people to place priority based transactions
in a limited mempool world is quite complicated. See recently closed
#6992.
I think the biggest issue with #6357 is being sure the logic doesn't break
in future changes. There are a lot of things that need to be updated in
the right order when blocks are connected or disconnected.
And whats the point of having even that added extra complication if its not
easy to place free transactions and starting priority is a decent
approximation for mining anyway (txs can just be rebroadcast in the worst
case).
On Thu, Nov 12, 2015 at 4:10 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Thursday, November 12, 2015 8:43:17 PM Jorge Timón wrote:
> > On Thu, Nov 12, 2015 at 9:12 PM, Luke Dashjr via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > > On Thursday, November 12, 2015 7:47:50 PM Matt Corallo via bitcoin-dev
> > > wrote:
> > >> * Mining code will use starting priority for ease of implementation
> > >
> > > This should be optional, at least for 0.12.
> >
> > The ease of implementation is not gained if it's maintained optionally.
>
> It has come to my attention maintaining the current priority algorithm is
> not
> even expensive, so I think I'm inclined to NACK using starting priority
> altogether. Since I am the mining maintainer for Core, I believe it's
> reasonable for me to decide on maintenance tradeoffs...
>
> Therefore, my goal in this matter will be to review #6357 in depth to be
> merged, and follow up with #6898 based on the current default policies.
>
> > >> * Default block priority size will be 0
> > >
> > > We should not be influencing miner policy by changing defaults.
> >
> > I agree changing policy defaults is meaningless, but in this case it
> > is supposed to signal deprecation of the policy option.
>
> This is a bad idea anyway, since priority is the best metric we have right
> now
> for ensuring legitimate transactions get mined despite spam attacks.
>
> Luke
> _______________________________________________
> 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/20151112/e994acb0/attachment.html>

2023-06-07 17:42:55

- reply

📅 Original date posted:2015-10-05
📝 Original message:Yes, total number of dependent transactions regardless of chain depth.
A descendant package means all the transactions that can not be included in
a block before the transaction in question.
An ancestor package means all the transactions that are required to be
included in a block before the transaction in question can be.
On Mon, Oct 5, 2015 at 2:51 PM, Danny Thorpe <danny.thorpe at gmail.com> wrote:
> What does "package" mean here?
>
> When you say 25 txs, does that mean maximum linked chain depth, or total
> number of dependent transactions regardless of chain depth?
>
> Thanks,
> -Danny
>
>
>
> On Mon, Oct 5, 2015 at 11:45 AM, Alex Morcos via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I'd like to propose updates to the new policy limits on unconfirmed
>> transaction chains.
>>
>> The existing limits in master and scheduled for release in 0.12 are:
>> Ancestor packages = 100 txs and 900kb total size
>> Descendant packages = 1000 txs and 2500kb total size
>>
>> Before 0.12 is released I would like to propose a significant reduction
>> in these limits. In the course of analyzing algorithms for mempool
>> limiting, it became clear that large packages of unconfirmed transactions
>> were the primary vector for mempool clogging or relay fee boosting attacks.
>> Feedback from the initial proposed limits was that they were too generous
>> anyway.
>>
>> The proposed new limits are:
>> Ancestor packages = 25 txs and 100kb total size
>> Descendant packages = 25 txs and 100kb total size
>>
>> Based on historical transaction data, the most restrictive of these
>> limits is the 25 transaction count on descendant packages. Over the period
>> of April and May of this year (before stress tests), 5.8% of transactions
>> would have violated this limit alone. Applying all the limits together
>> would have affected 6.1% of transactions.
>>
>> Please keep in mind these are policy limits that affect transactions
>> which depend on other unconfirmed transactions only. They are not a change
>> to consensus rules and do not affect how many chained txs a valid block may
>> contain. Furthermore, any transaction that was unable to be relayed due to
>> these limits need only wait for some of its unconfirmed ancestors to be
>> included in a block and then it could be successfully broadcast. This is
>> unlikely to affect the total time from creation to inclusion in a block.
>> Finally, these limits are command line arguments that can easily be changed
>> on an individual node basis in Bitcoin Core.
>>
>> Please give your feedback if you know of legitimate use cases that would
>> be hindered by these limits.
>>
>> Thanks,
>> Alex
>>
>> On Mon, Sep 21, 2015 at 11:02 AM, Alex Morcos <morcos at gmail.com> wrote:
>>
>>> Thanks for everyone's review. These policy changes have been merged in
>>> to master in 6654 <https://github.com/bitcoin/bitcoin/pull/6654>, which
>>> just implements these limits and no mempool limiting yet. The default
>>> ancestor package size limit is 900kb not 1MB.
>>>
>>> Yes I think these limits are generous, but they were designed to be as
>>> generous as was computationally feasible so they were unobjectionable
>>> (since the existing policy was no limits). This does not preclude future
>>> changes to policy that would reduce these limits.
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Aug 21, 2015 at 3:52 PM, Danny Thorpe <danny.thorpe at gmail.com>
>>> wrote:
>>>
>>>> The limits Alex proposed are generous (bordering on obscene!), but
>>>> dropping that down to allowing only two levels of chained unconfirmed
>>>> transactions is too tight.
>>>>
>>>> Use case: Brokered asset transfers may require sets of transactions
>>>> with a dependency tree depth of 3 to be published together. ( N seller txs,
>>>> 1 broker bridge tx, M buyer txs )
>>>>
>>>> If the originally proposed depth limit of 100 does not provide a
>>>> sufficient cap on memory consumption or loop/recursion depth, a depth limit
>>>> of 10 would provide plenty of headroom for this 3 level use case and
>>>> similar patterns.
>>>>
>>>> -Danny
>>>>
>>>> On Fri, Aug 21, 2015 at 12:22 PM, Matt Corallo via bitcoin-dev <
>>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>>> I dont see any problem with such limits. Though, hell, if you limited
>>>>> entire tx dependency trees (ie transactions and all required
>>>>> unconfirmed
>>>>> transactions for them) to something like 10 txn, maximum two levels
>>>>> deep, I also wouldnt have a problem.
>>>>>
>>>>> Matt
>>>>>
>>>>> On 08/14/15 19:33, Alex Morcos via bitcoin-dev wrote:
>>>>> > Hi everyone,
>>>>> >
>>>>> >
>>>>> > I'd like to propose a new set of requirements as a policy on when to
>>>>> > accept new transactions into the mempool and relay them. This policy
>>>>> > would affect transactions which have as inputs other transactions
>>>>> which
>>>>> > are not yet confirmed in the blockchain.
>>>>> >
>>>>> > The motivation for this policy is 6470
>>>>> > <https://github.com/bitcoin/bitcoin/pull/6470> which aims to limit
>>>>> the
>>>>> > size of a mempool. As discussed in that pull
>>>>> > <https://github.com/bitcoin/bitcoin/pull/6470#issuecomment-125324736
>>>>> >,
>>>>> > once the mempool is full a new transaction must be able to pay not
>>>>> only
>>>>> > for the transaction it would evict, but any dependent transactions
>>>>> that
>>>>> > would be removed from the mempool as well. In order to make sure
>>>>> this
>>>>> > is always feasible, I'm proposing 4 new policy limits.
>>>>> >
>>>>> > All limits are command line configurable.
>>>>> >
>>>>> > The first two limits are required to make sure no chain of
>>>>> transactions
>>>>> > will be too large for the eviction code to handle:
>>>>> >
>>>>> > Max number of descendant txs : No transaction shall be accepted if it
>>>>> > would cause another transaction in the mempool to have too many
>>>>> > descendant transactions (all of which would have to be evicted if the
>>>>> > ancestor transaction was evicted). Default: 1000
>>>>> >
>>>>> > Max descendant size : No transaction shall be accepted if it would
>>>>> cause
>>>>> > another transaction in the mempool to have the total size of all its
>>>>> > descendant transactions be too great. Default : maxmempool / 200
>>>>> = 2.5MB
>>>>> >
>>>>> > The third limit is required to make sure calculating the state
>>>>> required
>>>>> > for sorting and limiting the mempool and enforcing the first 2
>>>>> limits is
>>>>> > computationally feasible:
>>>>> >
>>>>> > Max number of ancestor txs: No transaction shall be accepted if it
>>>>> has
>>>>> > too many ancestor transactions which are not yet confirmed (ie, in
>>>>> the
>>>>> > mempool). Default: 100
>>>>> >
>>>>> > The fourth limit is required to maintain the pre existing policy goal
>>>>> > that all transactions in the mempool should be mineable in the next
>>>>> block.
>>>>> >
>>>>> > Max ancestor size: No transaction shall be accepted if the total
>>>>> size of
>>>>> > all its unconfirmed ancestor transactions is too large. Default: 1MB
>>>>> >
>>>>> > (All limits include the transaction itself.)
>>>>> >
>>>>> > For reference, these limits would have affected less than 2% of
>>>>> > transactions entering the mempool in April or May of this year.
>>>>> During
>>>>> > the period of 7/6 through 7/14, while the network was under stress
>>>>> test,
>>>>> > as many as 25% of the transactions would have been affected.
>>>>> >
>>>>> > The code to implement the descendant package tracking and new policy
>>>>> > limits can be found in 6557
>>>>> > <https://github.com/bitcoin/bitcoin/pull/6557> which is built off
>>>>> of 6470.
>>>>> >
>>>>> > Thanks,
>>>>> > Alex
>>>>> >
>>>>> >
>>>>> >
>>>>> > _______________________________________________
>>>>> > 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
>>>>>
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> 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/20151005/6dd5377c/attachment-0001.html>

2023-06-07 17:42:54

- reply

📅 Original date posted:2015-10-05
📝 Original message:I'd like to propose updates to the new policy limits on unconfirmed
transaction chains.
The existing limits in master and scheduled for release in 0.12 are:
Ancestor packages = 100 txs and 900kb total size
Descendant packages = 1000 txs and 2500kb total size
Before 0.12 is released I would like to propose a significant reduction in
these limits. In the course of analyzing algorithms for mempool limiting,
it became clear that large packages of unconfirmed transactions were the
primary vector for mempool clogging or relay fee boosting attacks. Feedback
from the initial proposed limits was that they were too generous anyway.
The proposed new limits are:
Ancestor packages = 25 txs and 100kb total size
Descendant packages = 25 txs and 100kb total size
Based on historical transaction data, the most restrictive of these limits
is the 25 transaction count on descendant packages. Over the period of
April and May of this year (before stress tests), 5.8% of transactions
would have violated this limit alone. Applying all the limits together
would have affected 6.1% of transactions.
Please keep in mind these are policy limits that affect transactions which
depend on other unconfirmed transactions only. They are not a change to
consensus rules and do not affect how many chained txs a valid block may
contain. Furthermore, any transaction that was unable to be relayed due to
these limits need only wait for some of its unconfirmed ancestors to be
included in a block and then it could be successfully broadcast. This is
unlikely to affect the total time from creation to inclusion in a block.
Finally, these limits are command line arguments that can easily be changed
on an individual node basis in Bitcoin Core.
Please give your feedback if you know of legitimate use cases that would be
hindered by these limits.
Thanks,
Alex
On Mon, Sep 21, 2015 at 11:02 AM, Alex Morcos <morcos at gmail.com> wrote:
> Thanks for everyone's review. These policy changes have been merged in to
> master in 6654 <https://github.com/bitcoin/bitcoin/pull/6654>, which just
> implements these limits and no mempool limiting yet. The default ancestor
> package size limit is 900kb not 1MB.
>
> Yes I think these limits are generous, but they were designed to be as
> generous as was computationally feasible so they were unobjectionable
> (since the existing policy was no limits). This does not preclude future
> changes to policy that would reduce these limits.
>
>
>
>
>
> On Fri, Aug 21, 2015 at 3:52 PM, Danny Thorpe <danny.thorpe at gmail.com>
> wrote:
>
>> The limits Alex proposed are generous (bordering on obscene!), but
>> dropping that down to allowing only two levels of chained unconfirmed
>> transactions is too tight.
>>
>> Use case: Brokered asset transfers may require sets of transactions with
>> a dependency tree depth of 3 to be published together. ( N seller txs, 1
>> broker bridge tx, M buyer txs )
>>
>> If the originally proposed depth limit of 100 does not provide a
>> sufficient cap on memory consumption or loop/recursion depth, a depth limit
>> of 10 would provide plenty of headroom for this 3 level use case and
>> similar patterns.
>>
>> -Danny
>>
>> On Fri, Aug 21, 2015 at 12:22 PM, Matt Corallo via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> I dont see any problem with such limits. Though, hell, if you limited
>>> entire tx dependency trees (ie transactions and all required unconfirmed
>>> transactions for them) to something like 10 txn, maximum two levels
>>> deep, I also wouldnt have a problem.
>>>
>>> Matt
>>>
>>> On 08/14/15 19:33, Alex Morcos via bitcoin-dev wrote:
>>> > Hi everyone,
>>> >
>>> >
>>> > I'd like to propose a new set of requirements as a policy on when to
>>> > accept new transactions into the mempool and relay them. This policy
>>> > would affect transactions which have as inputs other transactions which
>>> > are not yet confirmed in the blockchain.
>>> >
>>> > The motivation for this policy is 6470
>>> > <https://github.com/bitcoin/bitcoin/pull/6470> which aims to limit the
>>> > size of a mempool. As discussed in that pull
>>> > <https://github.com/bitcoin/bitcoin/pull/6470#issuecomment-125324736>,
>>> > once the mempool is full a new transaction must be able to pay not only
>>> > for the transaction it would evict, but any dependent transactions that
>>> > would be removed from the mempool as well. In order to make sure this
>>> > is always feasible, I'm proposing 4 new policy limits.
>>> >
>>> > All limits are command line configurable.
>>> >
>>> > The first two limits are required to make sure no chain of transactions
>>> > will be too large for the eviction code to handle:
>>> >
>>> > Max number of descendant txs : No transaction shall be accepted if it
>>> > would cause another transaction in the mempool to have too many
>>> > descendant transactions (all of which would have to be evicted if the
>>> > ancestor transaction was evicted). Default: 1000
>>> >
>>> > Max descendant size : No transaction shall be accepted if it would
>>> cause
>>> > another transaction in the mempool to have the total size of all its
>>> > descendant transactions be too great. Default : maxmempool / 200 =
>>> 2.5MB
>>> >
>>> > The third limit is required to make sure calculating the state required
>>> > for sorting and limiting the mempool and enforcing the first 2 limits
>>> is
>>> > computationally feasible:
>>> >
>>> > Max number of ancestor txs: No transaction shall be accepted if it has
>>> > too many ancestor transactions which are not yet confirmed (ie, in the
>>> > mempool). Default: 100
>>> >
>>> > The fourth limit is required to maintain the pre existing policy goal
>>> > that all transactions in the mempool should be mineable in the next
>>> block.
>>> >
>>> > Max ancestor size: No transaction shall be accepted if the total size
>>> of
>>> > all its unconfirmed ancestor transactions is too large. Default: 1MB
>>> >
>>> > (All limits include the transaction itself.)
>>> >
>>> > For reference, these limits would have affected less than 2% of
>>> > transactions entering the mempool in April or May of this year. During
>>> > the period of 7/6 through 7/14, while the network was under stress
>>> test,
>>> > as many as 25% of the transactions would have been affected.
>>> >
>>> > The code to implement the descendant package tracking and new policy
>>> > limits can be found in 6557
>>> > <https://github.com/bitcoin/bitcoin/pull/6557> which is built off of
>>> 6470.
>>> >
>>> > Thanks,
>>> > Alex
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > 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/20151005/6e2a78a3/attachment.html>

2023-06-07 17:42:30

- reply

📅 Original date posted:2015-10-15
📝 Original message:Adam,
The remaining 14 bits can be used to soft fork in finer granularity in the
future.
Alex
On Thu, Oct 15, 2015 at 12:37 PM, Adam Back <adam at cypherspace.org> wrote:
> Does that pre-judge that block interval would never change from
> 10mins? Eg say with IBLT or fountain codes etc and security arguments
> for the current limitations of them are found, such that orphan rates
> can remain low in a decentralised way with 1min blocks, then the
> locktime granularity would be coarse relative to the block interval
> (with 512s locktime granularity.
>
> Adam
>
> On 15 October 2015 at 18:27, Btc Drak via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Alex,
> >
> > I am sorry for not communicating more clearly. Mark and I discussed your
> > concerns from the last meeting and he made the change. The BIP text still
> > needs to be updated, but the discussed change was added to the PR, albeit
> > squashed making it more non-obvious. BIP68 now explicitly uses 16 bits
> with
> > a bitmask. Please see the use of SEQUENCE_LOCKTIME_MASK and
> > SEQUENCE_LOCKTIME_GRANULARITY in the PR
> > https://github.com/bitcoin/bitcoin/pull/6312.
> >
> > /* If CTxIn::nSequence encodes a relative lock-time, this mask is
> > * applied to extract that lock-time from the sequence field. */
> > static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff;
> >
> > /* In order to use the same number of bits to encode roughly the
> > * same wall-clock duration, and because blocks are naturally
> > * limited to occur every 600s on average, the minimum granularity
> > * for time-based relative lock-time is fixed at 512 seconds.
> > * Converting from CTxIn::nSequence to seconds is performed by
> > * multiplying by 512 = 2^9, or equivalently shifting up by
> > * 9 bits. */
> > static const int SEQUENCE_LOCKTIME_GRANULARITY = 9;
> >
> > I am also much happier with this last tightening up of the specification
> > because it removes ambiguity. 512s granularity makes sense within the
> > context of the 10 minute block target.
> >
> > Thank you for spending so much time carefully considering this BIP and
> > reference implementation and please let me know if there there are any
> > remaining nits so we can get those addressed.
> >
> >
> >
> >
> >
> > On Thu, Oct 15, 2015 at 2:47 PM, Alex Morcos via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>
> >> Mark,
> >>
> >> You seemed interested in changing BIP 68 to use 16 bits for sequence
> >> number in both the block and time versions, making time based sequence
> >> numbers have a resolution of 512 seconds.
> >>
> >> I'm in favor of this approach because it leaves aside 14 bits for
> further
> >> soft forks within the semantics of BIP 68.
> >>
> >> It would be nice to know if you're planning this change, and perhaps
> >> people can hold off on review until things are finalized.
> >>
> >> I'd cast my "vote" against BIP 68 without this change, but am also open
> to
> >> being convinced otherwise.
> >>
> >> What are other peoples opinions on this?
> >>
> >> On Thu, Oct 8, 2015 at 9:38 PM, Rusty Russell via bitcoin-dev
> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>>
> >>> Peter Todd <pete at petertodd.org> writes:
> >>> > On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote:
> >>> >> Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> >>> >> writes:
> >>> >> > However I don't think we've done a good job showing why we need to
> >>> >> > implement this feature via nSequence.
> >>> >>
> >>> >> It could be implemented in other ways, but nSequence is the neatest
> >>> >> and
> >>> >> most straightforward I've seen.
> >>> >>
> >>> >> - I'm not aware of any other (even vague) proposal for its use?
> >>> >> Enlighten?
> >>> >
> >>> > There's three that immediately come to mind:
> >>> >
> >>> > Gregory Maxwell has proposed it as a way of discouraging miners from
> >>> > reorging chains, by including some of the low-order bits of a
> previous
> >>> > block header in nSequence.
> >>> >
> >>> > A few people have proposed implementing proof-of-stake blocksize
> voting
> >>> > with nSequence.
> >>>
> >>> Excellent, thanks! It's good to have such ideas as a compass. PoS
> >>> voting seems like it won't be a problem in 5 bits.
> >>>
> >>> The "prevbits" idea would want more bits; naively 64 would be good, but
> >>> I think there are some tricks we can use to make 32 work OK. We would
> >>> have to then split between nLocktime (if available) and multiple
> >>> nSequence fields, and it would weaken it for some txs.
> >>>
> >>> There is one easy solution: change the BIP wording from:
> >>>
> >>> -For transactions with an nVersion of 2 or greater,
> >>> +For transactions with an nVersion of 2,
> >>>
> >>> And on every tx bump, we decide whether to keep this scheme (mempool
> >>> would enforce it always).
> >>>
> >>> Cheers,
> >>> Rusty.
> >>> _______________________________________________
> >>> 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
> >>
> >
> >
> > _______________________________________________
> > 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/20151015/fabd688e/attachment-0001.html>

2023-06-07 17:42:29

- reply

📅 Original date posted:2015-10-15
📝 Original message:Mark,
You seemed interested in changing BIP 68 to use 16 bits for sequence number
in both the block and time versions, making time based sequence numbers
have a resolution of 512 seconds.
I'm in favor of this approach because it leaves aside 14 bits for further
soft forks within the semantics of BIP 68.
It would be nice to know if you're planning this change, and perhaps people
can hold off on review until things are finalized.
I'd cast my "vote" against BIP 68 without this change, but am also open to
being convinced otherwise.
What are other peoples opinions on this?
On Thu, Oct 8, 2015 at 9:38 PM, Rusty Russell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Peter Todd <pete at petertodd.org> writes:
> > On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote:
> >> Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> >> writes:
> >> > However I don't think we've done a good job showing why we need to
> >> > implement this feature via nSequence.
> >>
> >> It could be implemented in other ways, but nSequence is the neatest and
> >> most straightforward I've seen.
> >>
> >> - I'm not aware of any other (even vague) proposal for its use?
> Enlighten?
> >
> > There's three that immediately come to mind:
> >
> > Gregory Maxwell has proposed it as a way of discouraging miners from
> > reorging chains, by including some of the low-order bits of a previous
> > block header in nSequence.
> >
> > A few people have proposed implementing proof-of-stake blocksize voting
> > with nSequence.
>
> Excellent, thanks! It's good to have such ideas as a compass. PoS
> voting seems like it won't be a problem in 5 bits.
>
> The "prevbits" idea would want more bits; naively 64 would be good, but
> I think there are some tricks we can use to make 32 work OK. We would
> have to then split between nLocktime (if available) and multiple
> nSequence fields, and it would weaken it for some txs.
>
> There is one easy solution: change the BIP wording from:
>
> -For transactions with an nVersion of 2 or greater,
> +For transactions with an nVersion of 2,
>
> And on every tx bump, we decide whether to keep this scheme (mempool
> would enforce it always).
>
> Cheers,
> Rusty.
> _______________________________________________
> 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/20151015/11660e06/attachment.html>

2023-06-07 17:42:26

- reply

📅 Original date posted:2015-10-05
📝 Original message:Peter,
Your concern about whether this is the best way to use the nSequence field;
would that be addressed by providing more high order bits to signal
different uses of the field? At a certain point we're really not limiting
the future at all and there is something to be said for not letting the
perfect be the enemy of the good. I think it would be nice to make forward
progress on BIPS 68,112, and 113 and move towards getting them finalized
and implemented. (Although I do suspect they aren't quite ready to go out
with CLTV)
What is the reasoning for having single second resolution on the time based
sequence number locks? Might it not make some sense to reduce that
resolution and leave more low order bits as well?
Alex
On Sun, Oct 4, 2015 at 8:04 AM, s7r via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi aj,
>
> On 10/4/2015 11:35 AM, Anthony Towns via bitcoin-dev wrote:
> > On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via
> > bitcoin-dev wrote:
> >> So we need to make the case for two main things: 1) We have
> >> applications that need a relative (instead of absolute CLTV) 2)
> >> Additionally to RCLTV, we need to implement this via nSequence
> >
> >> However I don't think we've done a good job showing why we need
> >> to implement this feature via nSequence. BIP68 describes the new
> >> nSequence semantics, and gives the rational for them as being a
> >> "Consensus-enforced tx replacement" mechanism, with a
> >> bidirectional payment channel as an example of this in action.
> >> However, the bidirectional payment channel concept itself can be
> >> easily implemented with CLTV alone.
> >
> > Do you mean "with RCLTV alone" here?
> >
> > RCLTV/OP_CSV is used in lightning commitment transactions to
> > enforce a delay between publishing the commitment transaction, and
> > spending the output -- that delay is needed so that the
> > counterparty has time to prove the commitment was revoked and claim
> > the outputs as a penalty.
> >
>
> I partially understand - can you please provide a simple Alice and Bob
> example here with the exact scenario? Thanks. Why is there a need to
> 'delay between publishing the commitment transaction and spending the
> output'? If the absolute CLTV script reached its maturity it means
> something went wrong (e.g. counterparty cheated or got hit by a bus)
> so what is with the delay time needed for proving that the commitment
> was revoked? I assume an absolute CLTV script reaching its maturity
> (nLockTime) is the proof itself that the commitment was revoked - but
> maybe I'm missing something obvious, sorry if this is the case.
>
> > Using absolute CLTV instead would mean that once the effective
> > delay a commitment transaction has decreases over time -- initially
> > it will be longer than desirable, causing unwanted delays in
> > claiming funds when no cheating is going on; but over time it will
> > become too short, which means there is not enough time to prove
> > cheating (and the channel has to be closed prematurely). You can
> > trade those things off and pick something that works, but it's
> > always going to be bad.
> >
> I agree, I see the logic here. Absolute CLTV is not necessary inferior
> to RCLTV - there are use cases and use cases. For example, you can
> avoid unnecessary waiting until the nLockTime expires if you use
> absolute CLTV in combination with P2SH (2/2). Again, it always depends
> on the use case - it might be a good solution, it might not be such a
> good solution, but even absolute CLTV alone clearly fixes a lot of
> things and takes smart contracts to the next level.
>
> >> There is a small drawback in that the initial transaction could
> >> be delayed, reducing the overall time the channel exists, but the
> >> protocol already assumes that transactions can be reliably
> >> confirmed within a day - significantly less than the proposed 30
> >> days duration of the channel.
> >
> > Compared to using a CLTV with 30 days duration, With RCLTV a
> > channel could be available for years (ie 20x longer), but in the
> > case of problems funds could be reclaimed within hours or days (ie
> > 30x faster).
> >
> Indeed. I for one _need_ CLTV / RCLTV in my day to day use cases, it
> would be neat to have both, but if I can only have (for the time
> being) absolute CLTV so be it - it's still a lot better.
>
> > But that's all about RCLTV vs CLTV, not about RCLTV vs
> > nSequence/OP_CSV. ie, it needs BIP 112 (OP_CSV) but not necessarily
> > BIP 68 (nSequence relative locktime), if they could be
> > disentangled.
> >
> > You could do all that with "<n> OP_CHECK_HEIGHT_DELTA_VERIFY" that
> > ignores nSequence, and directly compares the height of the current
> > block versus the input tx's block (or the diff of their
> > timestamps?) though, I think?
> >
> > I think the disadvantage is that (a) you have to look into the
> > input transaction's block height when processing the script; and
> > (b) you don't have an easy lookup to check whether the transaction
> > can be included in the next block.
> >
> > You could maybe avoid (b) by using locktime though. Have "<n>
> > OP_CHECK_RELATIVE_LOCKTIME_VERIFY" compare the transactions
> > locktime against the input's block height or time; if the locktime
> > is 0 or too low, the transaction is invalid. (So if nLockTime is in
> > blockheight, you can only spend inputs with blockheight based
> > OP_CRLTV tests; and if it's in blocktime, you can only spend inputs
> > with blocktime based OP_CRLTV. "n" does need to encode whether it's
> > time/block height though).
> >
> > That way, when you see a txn:
> >
> > - run the script. if you see <n> RCLTV, then + if the tx's locktime
> > isn't set, it's invalid; drop it + if the input txn is unconfirmed,
> > it's invalid; try again later + workout "locktime - n" if that's >=
> > the input tx's block height/time, it's good; keep it in mempool,
> > forward it, etc
> >
> > - if you're mining, include the tx when locktime hits, just like
> > you would any other valid tx with a locktime
> >
> > I think the use cases for BIP68 (nSequence) are of the form:
> >
> > 1) published input; here's a signed tx that spends it to you,
> > usable after a delay. might as well just use absolute locktime
> > here, though.
> >
> > 2) here's an unpublished input, you can build your own transaction
> > to spend it, just not immediately after it's published. BIP112 is
> > required, and OP_RCLTV as defined above works fine, just include
> > it in the published input's script.
> >
> > 3) here's an unpublished input, and a signed transaction spending
> > it, that you can use to spend it after a delay. BIP68 is enough;
> > but OP_RCLTV in the second transaction works here. however without
> > normalised tx ids, the input could be malleated before
> > publication, so maybe this use case isn't actually important
> > anyway.
> >
> > So I think OP_CRLTV alone works fine for them too...
> >
> > (Does that make sense, or am I missing something obvious?)
> >
> > Cheers, aj
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (MingW32)
>
> iQEcBAEBCAAGBQJWERXAAAoJEIN/pSyBJlsRypMH/2Q+jVRf4hWtPr9cs/06pXM9
> mKHd2OPDEJO8HjSe+cIMCxOz76EZxXglUEkK4YV/huP0Tp0bcMp6EJxsZVD9L78k
> dugyh2747ddL6aqRmt0ducTEfIC/Q4BxPA2HRQZkvyyIUQv2Tyo780bC0y8BwUpb
> j/BQjFZwk4QgqkTlf5lbCgn85alOKHki2El04iALHc27pUiDWKQPPeNOy6po6mmD
> /csvh4XOTQwCVy384ljuFBp0+QN7Z/zx4E8i6GqV2BmfNcveTG6Fc5KrHr2Ud4Th
> RD8k6n9mLaPs6ufhVkgUiUqPzQsJ+ns+mm7OEUdd645Kxqxg3Tu1u32DgdpRcHk=
> =U0N6
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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/20151005/ee853e6f/attachment-0001.html>

2023-06-07 17:41:01

- reply

📅 Original date posted:2015-09-21
📝 Original message:Thanks for everyone's review. These policy changes have been merged in to
master in 6654 <https://github.com/bitcoin/bitcoin/pull/6654>, which just
implements these limits and no mempool limiting yet. The default ancestor
package size limit is 900kb not 1MB.
Yes I think these limits are generous, but they were designed to be as
generous as was computationally feasible so they were unobjectionable
(since the existing policy was no limits). This does not preclude future
changes to policy that would reduce these limits.
On Fri, Aug 21, 2015 at 3:52 PM, Danny Thorpe <danny.thorpe at gmail.com>
wrote:
> The limits Alex proposed are generous (bordering on obscene!), but
> dropping that down to allowing only two levels of chained unconfirmed
> transactions is too tight.
>
> Use case: Brokered asset transfers may require sets of transactions with a
> dependency tree depth of 3 to be published together. ( N seller txs, 1
> broker bridge tx, M buyer txs )
>
> If the originally proposed depth limit of 100 does not provide a
> sufficient cap on memory consumption or loop/recursion depth, a depth limit
> of 10 would provide plenty of headroom for this 3 level use case and
> similar patterns.
>
> -Danny
>
> On Fri, Aug 21, 2015 at 12:22 PM, Matt Corallo via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I dont see any problem with such limits. Though, hell, if you limited
>> entire tx dependency trees (ie transactions and all required unconfirmed
>> transactions for them) to something like 10 txn, maximum two levels
>> deep, I also wouldnt have a problem.
>>
>> Matt
>>
>> On 08/14/15 19:33, Alex Morcos via bitcoin-dev wrote:
>> > Hi everyone,
>> >
>> >
>> > I'd like to propose a new set of requirements as a policy on when to
>> > accept new transactions into the mempool and relay them. This policy
>> > would affect transactions which have as inputs other transactions which
>> > are not yet confirmed in the blockchain.
>> >
>> > The motivation for this policy is 6470
>> > <https://github.com/bitcoin/bitcoin/pull/6470> which aims to limit the
>> > size of a mempool. As discussed in that pull
>> > <https://github.com/bitcoin/bitcoin/pull/6470#issuecomment-125324736>,
>> > once the mempool is full a new transaction must be able to pay not only
>> > for the transaction it would evict, but any dependent transactions that
>> > would be removed from the mempool as well. In order to make sure this
>> > is always feasible, I'm proposing 4 new policy limits.
>> >
>> > All limits are command line configurable.
>> >
>> > The first two limits are required to make sure no chain of transactions
>> > will be too large for the eviction code to handle:
>> >
>> > Max number of descendant txs : No transaction shall be accepted if it
>> > would cause another transaction in the mempool to have too many
>> > descendant transactions (all of which would have to be evicted if the
>> > ancestor transaction was evicted). Default: 1000
>> >
>> > Max descendant size : No transaction shall be accepted if it would cause
>> > another transaction in the mempool to have the total size of all its
>> > descendant transactions be too great. Default : maxmempool / 200 =
>> 2.5MB
>> >
>> > The third limit is required to make sure calculating the state required
>> > for sorting and limiting the mempool and enforcing the first 2 limits is
>> > computationally feasible:
>> >
>> > Max number of ancestor txs: No transaction shall be accepted if it has
>> > too many ancestor transactions which are not yet confirmed (ie, in the
>> > mempool). Default: 100
>> >
>> > The fourth limit is required to maintain the pre existing policy goal
>> > that all transactions in the mempool should be mineable in the next
>> block.
>> >
>> > Max ancestor size: No transaction shall be accepted if the total size of
>> > all its unconfirmed ancestor transactions is too large. Default: 1MB
>> >
>> > (All limits include the transaction itself.)
>> >
>> > For reference, these limits would have affected less than 2% of
>> > transactions entering the mempool in April or May of this year. During
>> > the period of 7/6 through 7/14, while the network was under stress test,
>> > as many as 25% of the transactions would have been affected.
>> >
>> > The code to implement the descendant package tracking and new policy
>> > limits can be found in 6557
>> > <https://github.com/bitcoin/bitcoin/pull/6557> which is built off of
>> 6470.
>> >
>> > Thanks,
>> > Alex
>> >
>> >
>> >
>> > _______________________________________________
>> > 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/20150921/9c5e53e6/attachment.html>

2023-06-07 17:40:55

- reply

📅 Original date posted:2015-09-18
📝 Original message:I guess I always assumed that UTXO set commitments were an alternative
security model (between SPV and full-node), not that they would cause the
existing security model to be deprecated.
On Fri, Sep 18, 2015 at 3:43 PM, Patrick Strateman via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Full nodes using UTXO set commitments is a change to the bitcoin
> security model.
>
> Currently an attacker with >50% of the network hashrate can rewrite
> history.
>
> If full nodes rely on UTXO set commitments such an attacker could create
> an infinite number of bitcoins (as in many times more than the current
> 21 million bitcoin limit).
>
> Before we consider mechanisms for UTXO set commitments, we should
> seriously discuss whether the security model reduction is reasonable.
>
> On 09/18/2015 12:05 PM, Rune Kjær Svendsen via bitcoin-dev wrote:
> > Currently, when a new node wants to join the network, it needs to
> retrieve the entire blockchain history, starting from January 2009 and up
> until now, in order to derive a UTXO set that it can verify new
> blocks/transactions against. With a blockchain size of 40GB and a UTXO size
> of around 1GB, the extra bandwidth required is significant, and will keep
> increasing indefinitely. If a newly mined block were to include the UTXO
> set hash of the chain up until the previous block — the hash of the UTXO
> set on top of which this block builds — then new nodes, who want to know
> whether a transaction is valid, would be able to acquire the UTXO set in a
> trustless manner, by only verifying proof-of-work headers, and knowing that
> a block with an invalid UTXO set hash would be rejected.
> >
> > I’m not talking about calculating a complicated tree structure from the
> UTXO set, which would put further burden on already burdened Bitcoin Core
> nodes. We simply include the hash of the current UTXO set in a newly
> created block, such that the transactions in the new block build *on top*
> of the UTXO set whose hash is specified. This actually alleviates Bitcoin
> Core nodes, as it will now become possible for nodes without the entire
> blockchain to answer SPV queries (by retrieving the UTXO set trustlessly
> and using this to answer queries). It also saves bandwidth for Bitcore Core
> nodes, who only need to send roughly 1GB of data, in order to synchronise a
> node, rather than 40GB+. I will continue to run a full Bitcoin Core node,
> saving the entire blockchain history, but it shouldn’t be a requirement to
> hold the entire transaction history in order to start verifying new
> transactions.
> >
> > As far as I can see, this also forces miners to actually maintain an
> UTXO set, rather than just build on top of the chain with the most
> proof-of-work. Producing a UTXO set and verifying a block against a chain
> is the same thing, so by including the hash of the UTXO set we force miners
> to verify the block that they want to build on top of.
> >
> > Am I missing something obvious, because as far as I can see, this solves
> the problem of quadratic time complexity for initial sync:
> http://www.youtube.com/watch?v=TgjrS-BPWDQ&t=2h02m12s
> >
> > The only added step to verifying a block is to hash the UTXO set. So it
> does require additional computation, but most modern CPUs have a SHA256
> throughput of around 500 MB/s, which means it takes only two seconds to
> hash the UTXO set. And this can be improved further (GPUs can do 2-3 GB/s).
> A small sacrifice for the added ease of initial syncing, in my opinion.
> >
> > /Rune
> > _______________________________________________
> > 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/20150918/b0e1a5b4/attachment-0001.html>

2023-06-07 17:40:49

- reply

📅 Original date posted:2015-09-17
📝 Original message:+1
sounds good to me!
On Thu, Sep 17, 2015 at 9:07 PM, Wladimir J. van der Laan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello,
>
> At Monday's code sprint we had a good idea to schedule a regular developer
> meeting in #bitcoin-dev.
>
> Attendance is of course voluntary, but it may be good to have a time that
> many people are expected to be present and current issues can be discussed.
>
> Any preference for days/times?
>
> What about e.g. every week 15:00-16:00 UTC on Thursday?
>
> Wladimir
> _______________________________________________
> 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/20150917/074771ec/attachment.html>

2023-06-07 17:37:12

- reply

📅 Original date posted:2015-08-19
📝 Original message:This is a message that I wrote and had hoped that all the core devs would
sign on to, but I failed to finish organizing it. So I'll just say it from
myself.
There has been a valuable discussion over the last several months regarding
a hard fork with respect to block size. However the sheer volume of email
and proportion of discussion that is more philosophical than technical has
rendered this list almost unusable for its primary purpose of technical
discussion related to Bitcoin development. Many of us share the blame for
letting the discourse run off topic to such a degree, and we hope that an
appeal for individual self restraint will allow this list to return to a
higher signal-to-noise ratio.
-Please consider the degree to which any email you send is related to
technical development before sending it.
-Please consider how many emails you are sending to this list regarding the
same topic.
This list is not appropriate for an endless back and forth debate on the
philosophical underpinnings of Bitcoin. Although such a debate may be
worthwhile it should be taken to another forum for discussion. Every email
you send is received by hundreds of developers who value their time as much
as you value yours. If your intended audience isn't really the majority of
them, perhaps private communication would be more appropriate.
Thanks,
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150819/68f13345/attachment-0001.html>

2023-06-07 17:35:10

- reply

📅 Original date posted:2015-08-14
📝 Original message:Hi everyone,
I'd like to propose a new set of requirements as a policy on when to accept
new transactions into the mempool and relay them. This policy would affect
transactions which have as inputs other transactions which are not yet
confirmed in the blockchain.
The motivation for this policy is 6470
<https://github.com/bitcoin/bitcoin/pull/6470> which aims to limit the size
of a mempool. As discussed in that pull
<https://github.com/bitcoin/bitcoin/pull/6470#issuecomment-125324736>, once
the mempool is full a new transaction must be able to pay not only for the
transaction it would evict, but any dependent transactions that would be
removed from the mempool as well. In order to make sure this is always
feasible, I'm proposing 4 new policy limits.
All limits are command line configurable.
The first two limits are required to make sure no chain of transactions
will be too large for the eviction code to handle:
Max number of descendant txs : No transaction shall be accepted if it would
cause another transaction in the mempool to have too many descendant
transactions (all of which would have to be evicted if the ancestor
transaction was evicted). Default: 1000
Max descendant size : No transaction shall be accepted if it would cause
another transaction in the mempool to have the total size of all its
descendant transactions be too great. Default : maxmempool / 200 = 2.5MB
The third limit is required to make sure calculating the state required for
sorting and limiting the mempool and enforcing the first 2 limits is
computationally feasible:
Max number of ancestor txs: No transaction shall be accepted if it has too
many ancestor transactions which are not yet confirmed (ie, in the
mempool). Default: 100
The fourth limit is required to maintain the pre existing policy goal that
all transactions in the mempool should be mineable in the next block.
Max ancestor size: No transaction shall be accepted if the total size of
all its unconfirmed ancestor transactions is too large. Default: 1MB
(All limits include the transaction itself.)
For reference, these limits would have affected less than 2% of
transactions entering the mempool in April or May of this year. During the
period of 7/6 through 7/14, while the network was under stress test, as
many as 25% of the transactions would have been affected.
The code to implement the descendant package tracking and new policy limits
can be found in 6557 <https://github.com/bitcoin/bitcoin/pull/6557> which
is built off of 6470.
Thanks,
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150814/3ee1bf86/attachment.html>

2023-06-07 17:33:56

- reply

📅 Original date posted:2015-08-10
📝 Original message:Gavin,
They are not analogous.
Increasing performance and making other changes that will help allow
scaling can be done while at small scale or large scale.
Dealing with full blocks and the resultant feedback effects is something
that can only be done when blocks are full. It's just too complicated a
problem to solve without seeing the effects first hand, and unlike the
block size/scaling concerns, its binary, you're either in the situation
where demands outgrows supply or you aren't.
Fee estimation is one example, I tried very hard to make fee estimation
work well when blocks started filling up but it was impossible to truly
test and in the small sample of full blocks we've gotten since the code
went live, many improvements made themselves obvious. Expanding mempools
is another issue that doesn't exist at all if supply > demand. Turns out
to also be a difficult problem to solve.
Nevertheless, I mostly agree that these arguments shouldn't be the reason
not to expand block size, I think they are more just an example of how
immature all of this technology is, and we should be concentrating on
improving it before we're trying to scale it to world acceptance levels.
The saddest thing about this whole debate is how fundamental improvements
to the science of cryptocurrencies (things like segregated witness and
confidential transactions) are just getting lost in the circus debate
around trying to cram a few more users into the existing system sooner
rather than later.
On Mon, Aug 10, 2015 at 10:12 AM, Gavin Andresen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Fri, Aug 7, 2015 at 1:33 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
>
>>
>> On Aug 7, 2015 5:55 PM, "Gavin Andresen" <gavinandresen at gmail.com> wrote:
>> >
>> > I think there are multiple reasons to raise the maximum block size, and
>> yes, fear of Bad Things Happening as we run up against the 1MB limit is one
>> of the reasons.
>>
>> What are the other reasons?
>>
>> > I take the opinion of smart engineers who actually do resource planning
>> and have seen what happens when networks run out of capacity very seriously.
>>
>> When "the network runs out of capacity" (when we hit the limit) do we
>> expect anything to happen apart from minimum market fees rising (above
>> zero)?
>> Obviously any consequences of fees rising are included in this concern.
>>
> It is frustrating to answer questions that we answered months ago,
> especially when I linked to these in response to your recent "increase
> advocates say that not increasing the max block size will KILL BITCOIN"
> false claim:
> http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent
> https://medium.com/@octskyward/crash-landing-f5cc19908e32
>
> Executive summary: when networks get over-saturated, they become
> unreliable. Unreliable is bad.
>
> Unreliable and expensive is extra bad, and that's where we're headed
> without an increase to the max block size.
>
> RE: the recent thread about "better deal with that type of thing now
> rather than later" : exactly the same argument can be made about changes
> needed to support a larger block size-- "better to do that now than to do
> that later." I don't think either of those arguments are very convincing.
>
>
> --
> --
> Gavin Andresen
>
>
> _______________________________________________
> 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/20150810/e46ab2bb/attachment.html>

2023-06-07 17:33:38

- reply

📅 Original date posted:2015-08-08
📝 Original message:I agree
There are a lot of difficult technical problems introduced by insufficient block space that are best addressed now. As well as problems that scale will exacerbate like bootstrapping that we should develop solutions for first.
Sent from my iPad
> On Aug 8, 2015, at 6:45 PM, Dave Scotese via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I see value in lowering the block size or leaving it where it is. We expect to run out of space, and I think it's a good idea to prepare for that, rather than avoid it. When we run out of space and the block size is low, we will see problems. If we raise the block size, we will NOT see these problems until bitcoin is bigger and more important and the pressure is higher.
>
> Someone mentioned that when the backlog grows faster than it shrinks, that is a real problem. I don't think it is. It is a problem for those who don't wait for even one confirmation, but backlogs in the past have already started training users to wait for at least one confirmation, or go off-chain. I am comfortable leaving those zero-conf people in a little bit of trouble. Everyone else can double-spend (perhaps that's not as easy as it should be in bitcoin core) and use a higher fee, thus competing for block space. Yes, $5 transactions suck, but $0.15 is not so bad and about twice the average right now.
>
> Meanwhile, the higher fees everyone starts feeling like paying, along with the visibility of the problems caused by full-blocks, will provide excellent justification and motivation for increasing the limit. My favorite thing to do is to have a solution ready for a problem I expect to see, see the problem (so I can measure things about it) and then implement the solution.
>
> In my experience, the single biggest reason not to run a full node has to do with starting from scratch: "I used to run a full node, but last time I had to download the full blockchain, it took ___ days, so I just use (some wallet) now." I think that has been improved with headers-first, but many people don't know it.
>
> I have some ideas how a "full node" could postpone being "full" but still be nearly completely operational so that the delay between startup and having a full blockchain is nearly painless. It involves bonded representation of important not-so-large pieces of data (blocks that have my transactions, the complete UTXO as of some height, etc.). If I know that I have some btc, I could offer it (say, 100 or 1000 transaction fees' worth) to anyone who will guarantee good data to me, and then when I have the whole blockchain, I will know if they were honest. If done right, the whole network could know whether or not they were honest and enforce the bond if they weren't. Credit the Lightening paper for parts of this idea.
>
> Dave
>
>> On Fri, Aug 7, 2015 at 4:06 PM, Adam Back via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> Please try to focus on constructive technical comments.
>>
>> On 7 August 2015 at 23:12, Thomas Zander via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > What will the backlash be when people here that are pushing for "off-chain-
>> > transactions" fail to produce a properly working alternative, which
>> > essentially means we have to say NO to more users.
>>
>> But > 99% of Bitcoin transactions are already off-chain. There are
>> multiple competing companies offering consumer & retail service with
>> off-chain settlement.
>>
>> I wasnt clear but it seemed in your previous mail that you seemed to
>> say you dont mind trusting other people with your money, and so
>> presumably you are OK using these services, and so have no problem?
>>
>> > At this time and this size of bitcoin community, my personal experience (and
>> > I've been part of many communities) saying NO to new customers
>>
>> Who said no to anything? The systems of off-chain transfer already
>> exist and are by comparison to Bitcoins protocol simple and rapid to
>> adapt and scale.
>>
>> Indications are that we can even do off-chain at scale with Bitcoin
>> similar trust-minimisation with lightning, and duplex payment
>> channels; and people are working on that right now.
>>
>> I think it would be interesting and useful for someone, with an
>> interest in low trust, high scale transactions, to work on and propose
>> an interoperability standard and API for such off-chain services to be
>> accessed by wallets, and perhaps periodic on-chain inter-service
>> netting.
>>
>> Adam
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> --
> I like to provide some work at no charge to prove my value. Do you need a techie?
> I own Litmocracy and Meme Racing (in alpha).
> I'm the webmaster for The Voluntaryist which now accepts Bitcoin.
> I also code for The Dollar Vigilante.
> "He ought to find it more profitable to play by the rules" - Satoshi Nakamoto
> _______________________________________________
> 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/20150808/e5e734f6/attachment-0001.html>

2023-06-07 17:32:28

- reply

📅 Original date posted:2015-08-04
📝 Original message:On Tue, Aug 4, 2015 at 9:12 AM, Gavin Andresen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I would say that things already demonstrately got terrible. The mining
>> landscape is very centralized, with apparently a majority depending on
>> agreements to trust each other's announced blocks without validation.
>>
> And that is a problem... why?
>
> As far as I can tell, nobody besides miners running old and/or buggy
> software lost money due to outsourced mining validation (please correct me
> if I'm wrong-- I'm looking forward to Greg's post-mortem). The operators of
> bitcoin.org seem to have freaked out and pushed the panic button (with
> dire warnings of not trusting transactions until 20 confirmations), but
> theymos was well known for using an old, patched version of Core for
> blockexplorer.com so maybe that's not surprising.
>
>
I'm also looking forward to Greg's post-mortem, because I had a completely
different takeaway from the BIP66 mini-forks. My view is that despite the
extremely cautious and conservative planning for the completely
uncontentious fork, the damage could and would have been very significant
if it had not been for several core devs manually monitoring, intervening
and problem solving for other network participants. I don't believe thats
the way the system should work. Participants in the Bitcoin community have
come to rely on the devs for just making sure everything works for them.
That's not sustainable. The system needs to be made fundamentally more
secure if its going to succeed, not depend on the good will of any
particular parties, otherwise it certainly will no longer be permissionless.
The BIP66 fork was urgently required to fix an undisclosed consensus bug,
unanimously agreed on and without technical objection, and it was still
fraught with problems. That's the most clear cut example of when we should
have a fork. A change to a consensus limit that a significant proportion
of the community disagrees with for economic or technical reasons or both
should be raising a sea of red flags.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150804/b2ddba5d/attachment.html>

- reply

- reply

- reply

- reply

- reply

- reply

📅 Original date posted:2015-07-22
📝 Original message:Jeff I respectively disagree with many of your points, but let me just
point out 2.
Over the last 6 years there may not have been fee pressure, but certainly
there was the expectation that it was going to happen. Look at all the
work that has been put into fee estimation, why do that work if the
expectation was there would be no fee pressure?
I know you respect Pieter's work, so I don't want to twist your words, but
for the clarity of other people reading these posts, it sounds like you're
accusing Pieter and others of stonewalling size increases and not
participating in planning for them. Without debate, no one has done more
for this project to make eventual size increases technically feasible than
Pieter. We only have the privilege of even having this debate as a result
of his work.
On Wed, Jul 22, 2015 at 1:33 PM, Jeff Garzik via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Jul 22, 2015 at 9:52 AM, Pieter Wuille via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Some people have called the prospect of limited block space and the
>> development of a fee market a change in policy compared to the past. I
>> respectfully disagree with that. Bitcoin Core is not running the Bitcoin
>> economy, and its developers have no authority to set its rules. Change in
>> economics is always happening, and should be expected. Worse, intervening
>> in consensus changes would make the ecosystem more dependent on the group
>> taking that decision, not less.
>>
>>
> This completely ignores *reality*, what users have experienced for the
> past ~6 years.
>
> "Change in economics is always happening" does not begin to approach the
> scale of the change.
>
> For the entirety of bitcoin's history, absent long blocks and traffic
> bursts, fee pressure has been largely absent.
>
> Moving to a new economic policy where fee pressure is consistently present
> is radically different from what users, markets, and software have
> experienced and *lived.*
>
> Analysis such as [1][2] and more shows that users will hit a "painful"
> "wall" and market disruption will occur - eventually settling to a new
> equilibrium after a period of chaos - when blocks are consistently full.
>
> [1] http://hashingit.com/analysis/34-bitcoin-traffic-bulletin
> [2] http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent
>
> First, users & market are forced through this period of chaos by "let a
> fee market develop" as the whole market changes to a radically different
> economic policy, once the network has never seen before.
>
> Next, when blocks are consistently full, the past consensus was that block
> size limit will be increased eventually. What happens at that point?
>
> Answer - Users & market are forced through a second period of chaos and
> disruption as the fee market is rebooted *again* by changing the block
> size limit.
>
> The average user hears a lot of noise on both sides of the block size
> debate, and really has no idea that the new "let a fee market develop"
> Bitcoin Core policy is going to *raise fees* on them.
>
> It is clear that
> - "let the fee market develop, Right Now" has not been thought through
> - Users are not prepared for a brand new economic policy
> - Users are unaware that a brand new economic policy will be foisted upon
> them
>
>
>
>> So to point out what I consider obvious: if Bitcoin requires central
>> control over its rules by a group of developers, it is completely
>> uninteresting to me. Consensus changes should be done using consensus, and
>> the default in case of controversy is no change.
>>
>
> False.
>
> All that has to do be done to change bitcoin to a new economic policy -
> not seen in the entire 6 year history of bitcoin - is to stonewall work on
> block size.
>
> Closing size increase PRs and failing to participate in planning for a
> block size increase accomplishes your stated goal of changing bitcoin to a
> new economic policy.
>
> "no [code] change"... changes bitcoin to a brand new economic policy,
> picking economic winners & losers. Some businesses will be priced out of
> bitcoin, etc.
>
> Stonewalling size increase changes is just as much as a Ben Bernanke/FOMC
> move as increasing the hard limit by hard fork.
>
>
>
>> My personal opinion is that we - as a community - should indeed let a fee
>> market develop, and rather sooner than later, and that "kicking the can
>> down the road" is an incredibly dangerous precedent: if we are willing to
>> go through the risk of a hard fork because of a fear of change of
>> economics, then I believe that community is not ready to deal with change
>> at all. And some change is inevitable, at any block size. Again, this does
>> not mean the block size needs to be fixed forever, but its intent should be
>> growing with the evolution of technology, not a panic reaction because a
>> fear of change.
>>
>> But I am not in any position to force this view. I only hope that people
>> don't think a fear of economic change is reason to give up consensus.
>>
>
> Actually you are.
>
> When size increase progress gets frozen out of Bitcoin Core, that just
> *increases* the chances that progress must be made through a contentious
> hard fork.
>
> Further, it increases the market disruption users will experience, as
> described above.
>
> Think about the users. Please.
>
>
>
> _______________________________________________
> 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/20150722/2fd9f799/attachment-0001.html>

2023-06-07 15:41:53

- reply

📅 Original date posted:2015-07-10
📝 Original message:I think the biggest problem with merging CPFP right now is that at least in
its current implementation it is not efficient enough in certain
situations,.
On Fri, Jul 10, 2015 at 1:02 PM, Justus Ranvier <
justus at openbitcoinprivacyproject.org> wrote:
> On 07/10/2015 11:31 AM, Jeff Garzik wrote:
> > This is a good explanation but it does not address reachability. TX_a,
> the
> > first tx sent out on the network, presumably has insufficient fee to get
> > mined - which also means it did not necessarily even reach all miners.
> >
> > Simply sending out TX_b with added fee does not guarantee that nodes
> > suddenly have TX_a, which they may have ignored/dropped before.
>
> I'm not sure why that's actually a problem.
>
> CPFP is initiated by the recipient of the parent transaction, and so if
> the recipient is creating this transaction in the first place they must
> have a copy of the parent transaction which can/should broadcast at the
> same time.
>
> If the child reaches a CPFP miner, then presumably the parents made it
> as well (any path between the sender and the miner that doesn't relay
> the parent should reject the child as trying to spend non-existent
> coins), so both of the transactions can be mined at the same time.
>
> --
> Justus Ranvier
> Open Bitcoin Privacy Project
> http://www.openbitcoinprivacyproject.org/
> justus at openbitcoinprivacyproject.org
> E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
>
> _______________________________________________
> 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/20150710/4b36fab9/attachment.html>

2023-06-07 15:40:37

- reply

📅 Original date posted:2015-06-26
📝 Original message:I think thats the crux of the issue: "some uses fit, some don't".
I don't think anyone can claim to know which fall in which category for
sure. But its clear that with the existing technology, achieving
decentralization and lack of trusted third parties is expensive, therefore
I think it does the world a disservice to pretend everyone can put their
microtransactions on the block chain.
More importantly, I don't think I'm worried about economic policy or change
at all. I'm worried about decentralization. That's the piece we should be
concentrating on. Sure a bitcoin with giant blocks could probably serve a
bunch more use cases, but what value would it provide if there are 10
centralized miners and processing nodes running the network. We'll beat
out Apple Pay or Paypal or Google at their game? Who cares.
On Fri, Jun 26, 2015 at 2:12 PM, Pieter Wuille <pieter.wuille at gmail.com>
wrote:
> I am not saying that economic change is what we want. Only that it is
> inevitable, independent of whether larger blocks happen or not.
>
> I am saying that acting because of fear of economic change is a bad
> reason. The reason for increase should be because of the higher utility. We
> need it at some point, but there should be no rush.
>
> I do understand that we want to avoid a *sudden* change in economic
> policy, but I'm generally not too worried. Either fees increase and they
> get paid, and we're good. But more likely is that some uses just move
> off-chain because the block chain does not offer what they need. That's
> sad, but it is inevitable at any size: some uses fit, some don't.
>
> --
> Pieter
> On Jun 26, 2015 7:57 PM, "Jeff Garzik" <jgarzik at gmail.com> wrote:
>
>> It is not "fear" of fee pressure.
>>
>> 1) Blocks are mostly not-full on average.
>>
>> 2) Absent long blocks and stress tests, there is little fee pressure
>> above the anti-spam relay fee metric, because of #1.
>>
>> 3) As such, inducing fee pressure is a delta, a change from years-long
>> bitcoin economic policy. Each time we approach the soft limit, Bitcoin
>> Core increases the soft limit to prevent "full" blocks. Mike Hearn et. al.
>> lobbies miners to upgrade.
>>
>> (note - this is not an endorsement of these actions - it is a neutral
>> observation)
>>
>> 4) Inaction leads to consistent fee pressure as the months tick on and
>> system volume grows; thus, inaction leads to economic policy change.
>>
>> 5) Economic policy change leads to market and software disruption. The
>> market and software - notably wallets - is not prepared for this.
>>
>> 6) If you want to change economic policy, that's fine. But be honest and
>> admit you are arguing for a change, a delta from current market
>> expectations and behavior.
>>
>> 7) It is critical to first deal with what _is_, not what you wish the
>> world to be. You want a fee market to develop. There is nothing wrong
>> with that desire. It remains a delta from where we are today, and that is
>> critically relevant in a $3b+ market.
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Jun 26, 2015 at 7:09 AM, Pieter Wuille <pieter.wuille at gmail.com>
>> wrote:
>>
>>> Hello all,
>>>
>>> here I'm going to try to address a part of the block size debate which
>>> has been troubling me since the beginning: the reason why people seem to
>>> want it.
>>>
>>> People say that larger blocks are necessary. In the long term, I agree -
>>> in the sense that systems that do not evolve tend to be replaced by other
>>> systems. This evolution can come in terms of layers on top of Bitcoin's
>>> blockchain, in terms of the technology underlying various aspects of the
>>> blockchain itself, and also in the scale that this technology supports.
>>>
>>> I do, however, fundamentally disagree that a fear for a change in
>>> economics should be considered to necessitate larger blocks. If it is, and
>>> there is consensus that we should adapt to it, then there is effectively no
>>> limit going forward. This is similar to how Congress voting to increase the
>>> copyright term retroactively from time to time is really no different from
>>> having an infinite copyright term in the first place. This scares me.
>>>
>>> Here is how Gavin summarizes the future without increasing block sizes
>>> in PR 6341:
>>>
>>> > 1. Transaction confirmation times for transactions with a given fee
>>> will rise; very-low-fee transactions will fail to get confirmed at all.
>>> > 2. Average transaction fee paid will rise
>>> > 3. People or applications unwilling or unable to pay the rising fees
>>> will stop submitting transactions
>>> > 4. People and businesses will shelve plans to use Bitcoin, stunting
>>> growth and adoption
>>>
>>> Is it fair to summarize this as "Some use cases won't fit any more,
>>> people will decide to no longer use the blockchain for these purposes, and
>>> the fees will adapt."?
>>>
>>> I think that is already happening, and will happen at any scale. I
>>> believe demand for payments in general is nearly infinite, and only a small
>>> portion of it will eventually fit on a block chain (independent of whether
>>> its size is limited by consensus rules or economic or technological means).
>>> Furthermore, systems that compete with Bitcoin in this space already offer
>>> orders of magnitude more capacity than we can reasonably achieve with any
>>> blockchain technology at this point.
>>>
>>> I don't know what subset of use cases Bitcoin will cater to in the long
>>> term. They have already changed - you see way less betting transactions
>>> these days than a few years ago for example - and they will keep changing,
>>> independent of what effective block sizes we end up with. I don't think we
>>> should be afraid of this change or try to stop it.
>>>
>>> If you look at graphs of block sizes over time (for example,
>>> http://rusty.ozlabs.org/?p=498), it seems to me that there is very
>>> little "organic" growth, and a lot of sudden changes (which could
>>> correspond to changing defaults in miner software, introduction of popular
>>> sites/services, changes in the economy). I think these can be seen as the
>>> economy changing to full up the available space, and I believe these will
>>> keep happening at any size effectively available.
>>>
>>> None of this is a reason why the size can't increase. However, in my
>>> opinion, we should do it because we believe it increases utility and
>>> understand the risks; not because we're afraid of what might happen if we
>>> don't hurry up. And from that point of view, it seems silly to make a huge
>>> increase at once...
>>>
>>> --
>>> Pieter
>>>
>>>
>>> _______________________________________________
>>> 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/20150626/70106007/attachment.html>

2023-06-07 15:40:04

- reply

📅 Original date posted:2015-06-24
📝 Original message:+1 Mark!
On Wed, Jun 24, 2015 at 9:50 PM, Mark Friedenbach <mark at friedenbach.org>
wrote:
> I'm sorry but this is absolutely not the case, Milly. The reason that
> people get defensive is that we have a carefully constructed process that
> does work (thank you very much!) and is well documented. We talk about it
> quite often in fact as it is a defining characteristic of how bitcoin is
> developed which differs in some ways from how other open source software is
> developed -- although it remains the same in most other ways.
>
> Changes to the non-consensus sections of Bitcoin Core tend to get merged
> when there are a few reviews, tests, and ACKs from recognized developers,
> there are no outstanding objections, and the maintainer doing the merge
> makes a subjective judgement that the code is ready.
>
> Consensus-changes, on the other hand, get merged into Bitcoin Core only
> after the above criteria are met AND an extremely long discussion period
> that has given all the relevant stakeholders a chance to comment, and no
> significant objections remain. Consensus-code changes are unanimous. They
> must be.
>
> The sort of process that exists in standards bodies for example, with
> working groups and formal voting procedures, has no place where changes
> define the nature and validity of other people's money. Who has the right
> to reach into your pocket and define how you can or cannot spend your
> coins? The premise of bitcoin is that no one has that right, yet that is
> very much what we do when consensus code changes are made. That is why when
> we make a change to the rules governing the nature of bitcoin, we must make
> sure that everyone is made aware of the change and consents to it.
>
> Everyone. Does this work? Does this scale? So far, it does.
> Uncontroversial changes, such as BIP 66, are deployed without issue. Every
> indication is that BIP 66 will complete deployment in the very near future,
> and we intend to repeat this process for more interesting changes such as
> BIP65: CHECKLOCKTIMEVERIFY.
>
> This isn't about no one stepping forward to be the "decider." This is
> about no one having the right to decide these things on the behalf of
> others. If a contentious change is proposed and not accepted by the process
> of consensus, that is because the process is doing its job at rejecting
> controversial changes. It has nothing to do with personality, and
> everything to do with the nature of bitcoin itself.
>
>
> On Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin <milly at bitcoins.info>
> wrote:
>
>> I have seen this question asked many times. Most developers become
>> defensive and they usually give a very vague 1-sentence answer when this
>> question is asked. It seems to be it is based on personalities rather than
>> any kind of definable process. To have that discussion the personalities
>> must be separated out and answers like "such-and-such wouldn't do that"
>> don't really do much to advance the discussion. Also, the incentive for
>> new developers to come in is that they will be paid by companies who want
>> to influence the code and this should be considered (some developers take
>> this statement as an insult when it is just a statement of the incentive
>> process).
>>
>> The other problem you are having is the lead developer does not want to
>> be a "decider" when, in fact, he is a very significant decider. While the
>> users have the ultimate choice in a practical sense the chief developer is
>> the "decider." Now people don't want to get him upset so nobody wants to
>> push the issue or fully define the process. Now you are left with a
>> broken, unwritten/unspoken process. While this type of thing may work with
>> a small group of developers businesses/investors looking in from the
>> outside will see this as a risk.
>>
>> Until you get passed all the personality-based arguments you are going to
>> have a tough time defining a real process.
>>
>> Russ
>>
>>
>>
>>
>>
>>
>> On 6/24/2015 7:41 PM, Raystonn wrote:
>>
>>> I would like to start a civil discussion on an undefined, or at least
>>> unwritten, portion of the BIP process. Who should get to vote on approval
>>> to commit a BIP implementation into Bitcoin Core? Is a simple majority of
>>> these voters sufficient for approval? If not, then what is?
>>>
>>> Raystonn
>>> _______________________________________________
>>> 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
>>
>
>
> _______________________________________________
> 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/20150624/3c10f6ac/attachment.html>

2023-06-07 15:38:33

- reply

📅 Original date posted:2015-06-18
📝 Original message:Not that I know how to do this, but would you be willing to attempt some
other method of measuring just how much of a "super-majority" we have
before deploying code? Maybe that information would be helpful for
everyone. Obviously such a poll couldn't be perfect, but maybe better than
the information we have now.
A) I don't believe we should consider changing the 1 MB limit now
B) I conceptually believe in increasing block size, but would like to
follow a more conservative process and wait to see if a stronger technical
consensus on a plan to do so can develop.
C) I'd like to go along with Gavin and Mike's 8MB proposal (maybe we wait
til this is fully specified, but again not deployed)
Perhaps there can even be 4 polls:
Miners can vote in coinbases
Known corporate entities can announce their vote
Does the Bitcoin Foundation infrastructure still exist to represent some
authenticated (I think) set of individuals
A reddit poll
I don't even know if I think this is a good idea, but just trying to find a
way to move forward where more of us are on the same page.
On Thu, Jun 18, 2015 at 2:23 PM, Gavin Andresen <gavinandresen at gmail.com>
wrote:
> On Thu, Jun 18, 2015 at 1:42 PM, Alex Morcos <morcos at gmail.com> wrote:
>
>> Let me take a pass at explaining how I see this.
>>
>> 1) Code changes to Bitcoin Core that don't change consensus: Wladimir is
>> the decider but he works under a process that is well understood by
>> developers on the project in which he takes under reasonable consideration
>> other technical opinions and prefers to have clear agreement among them.
>>
>
> Yes.
>
> 2) Changes to the consensus rules: As others have said, this isn't
>> anyone's decision for anyone else.
>>
>
> Yes.
>
>
>> It's up to each individual user as to what code they run and what rules
>> they enforce. So then why is everyone so up in arms about what Mike and
>> Gavin are proposing if everyone is free to decide for themselves? I
>> believe that each individual user should adhere to the principle that there
>> should be no changes to the consensus rules unless there is near complete
>> agreement among the entire community, users, developers, businesses miners
>> etc. It is not necessary to define complete agreement exactly because every
>> individual person decides for themselves. I believe that this is what
>> gives Bitcoin, or really any money, its value and what makes it work, that
>> we all agree on exactly what it is. So I believe that it is misleading and
>> bad for Bitcoin to tell users and business that you can just choose without
>> concern for everyone else which code you'll run and we'll see which one
>> wins out. No. You should run the old consensus rules (on any codebase you
>> want) until you believe that pretty much everyone has consented to a change
>> in the rules. It is your choice, but I think a lot of people that have
>> spent time thinking about the philosophy of consensus systems believe that
>> when the users of the system have this principle in mind, it's what will
>> make the system work best.
>>
>
> I don't think I agree with "pretty much everybody", because status-quo
> bias is a very powerful thing. Any change that disrupts the way they've
> been doing things will generate significant resistance -- there will be 10
> or 20% of any population that will take a position of "too busy to think
> about this, everything seems to be working great, I don't like change, NO
> to any change."
>
> For example, I think some of the resistance for bigger blocks is coming
> from contributors who are worried they, personally, won't be able to keep
> up with a bigger blockchain. They might not be able to run full nodes from
> their home network connections (or might not be able to run a full node AND
> stream Game of Thrones), on their old raspberry pi machines.
>
> The criteria for me is "clear super-majority of the people and businesses
> who are using Bitcoin the most," and I think that criteria is met.
>
>
>
>> 3) Code changes to Core that do change consensus: I think that Wladimir,
>> all the other committers besides Gavin, and almost all of the other
>> developers on Core would defer to #2 above and wait for its outcome to be
>> clear before considering such a code change.
>>
>
> Yes, that's the way it has mostly been working. But even before stepping
> down as Lead I was starting to wonder if there are ANY successful open
> source projects that didn't have either a Benevolent Dictator or some clear
> voting process to resolve disputes that cannot be settled with "rough
> consensus."
>
>
> --
> --
> Gavin Andresen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/a6d09f1f/attachment.html>

2023-06-07 15:38:32

- reply

📅 Original date posted:2015-06-18
📝 Original message:Let me take a pass at explaining how I see this.
1) Code changes to Bitcoin Core that don't change consensus: Wladimir is
the decider but he works under a process that is well understood by
developers on the project in which he takes under reasonable consideration
other technical opinions and prefers to have clear agreement among them.
2) Changes to the consensus rules: As others have said, this isn't anyone's
decision for anyone else. It's up to each individual user as to what code
they run and what rules they enforce. So then why is everyone so up in
arms about what Mike and Gavin are proposing if everyone is free to decide
for themselves? I believe that each individual user should adhere to the
principle that there should be no changes to the consensus rules unless
there is near complete agreement among the entire community, users,
developers, businesses miners etc. It is not necessary to define complete
agreement exactly because every individual person decides for themselves.
I believe that this is what gives Bitcoin, or really any money, its value
and what makes it work, that we all agree on exactly what it is. So I
believe that it is misleading and bad for Bitcoin to tell users and
business that you can just choose without concern for everyone else which
code you'll run and we'll see which one wins out. No. You should run the
old consensus rules (on any codebase you want) until you believe that
pretty much everyone has consented to a change in the rules. It is your
choice, but I think a lot of people that have spent time thinking about the
philosophy of consensus systems believe that when the users of the system
have this principle in mind, it's what will make the system work best.
3) Code changes to Core that do change consensus: I think that Wladimir,
all the other committers besides Gavin, and almost all of the other
developers on Core would defer to #2 above and wait for its outcome to be
clear before considering such a code change.
I'm sure my description of point 2 is not the most eloquent or clear, but
maybe someone else can try to elucidate this principle if they've grasped
what I'm trying to say.
On Thu, Jun 18, 2015 at 1:04 PM, <justusranvier at riseup.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 2015-06-18 16:28, Jeff Garzik wrote:
> > This is an engineering list. The quote precisely describes how the
> > bitcoin
> > consensus system functions.
> >
> > Users' choice is largely binary: Follow the rules, or bitcoin software
> > ignores you.
>
>
> Software engineers should understand that they have a binary choice:
> produce the software that your customers want, or the world will ignore
> your software.
>
> There is *no inherent value* to Bitcoin's software rules. The only value
> that is exists is that produced by the individuals who voluntarily
> choose to run the software.
>
> Failing to account for all design requirements is bad engineering.
> Nobody cares about the design features of a bridge to nowhere.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBCgAGBQJVgvoDAAoJECpf2nDq2eYj0h4P/0YaTsS963qpb63zvB6WlIPS
> 2lhCJ9FtAd3II5Et+5c/cisfJ9YI2OnM0y8nQpyB9NEOeueN1L1sLFcayE5aHASd
> EgF7F81AhQD2iSIVwQNs2qAzrZNC2/Nx+nBzBDcrgZ6gRiPpQdsNLy2p0OuZdOgX
> yG4xl6tKADB2kNi6tVPtZqUC300uQHvggtm+pexYilT0ojEbeVHCoDV40MNDZC2h
> 1kcdTnGU2SHJJqeZN2vChJCOMfhmK4JwKgoz7JRXe/GHkUUJKriE6Kb7SVczii9e
> 9qfcosbnR3gjATMoHFYuJX/nsUx52Q1LM9eQgvE8Ml+6Mim5bj2KCJFh7YISxSq9
> FhDujfZFCRRQLPJCSkEUePxU/LS7lmoTZXYl3Zz1j9zbq4ncpRHpIFy9QX6iIqK6
> Dursnge9ELQwB+H6HoosWRzxOZyo+oiGj17OngJvZYcvzrc2wjHbpZfVqSkmZepU
> SfJZ64O7yjjXjITwhOc4XF2drzvhsjTsHH5BIwdbCn82SoCkJIwXraj7sxIundli
> LUJBPiAE0csdmsvW/2kkxLsd9JwTw9lJ9Pf8fiqH3itgrkPkO5mf10DPPnay1SNk
> Wnm1bAJ05WnKXSo0m0SzaFgZkdfFuhWR4fieSzhLpa+s/HHj18NZvJCmCBR6ic9G
> 0A+51wwSZnAdMIw7lwIb
> =r4Co
> -----END PGP SIGNATURE-----
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/bb6ae32f/attachment.html>

2023-06-07 15:38:13

- reply

📅 Original date posted:2015-06-15
📝 Original message:Aaron,
My understanding is that Gavin and Mike are proceeding with the XT fork, I
hope that understanding is wrong.
As for improving the non-consensus code to handle full blocks more
gracefully. This is something I'm very interested in, block size increase
or not. Perhaps I shouldn't hijack this thread, but maybe there are others
who also believe this would ameliorate some of the time pressure for
deciding on a block size increase.
What is it that you would like to see improved?
The fee estimation code that is included for 0.11 will give much more
accurate fee estimates, which should allow adding the correct fee to a
transaction to see it likely to be confirmed in a reasonable time. For
further improvements:
- There has recently been attention to overhauling the block creation and
mempool limiting code in such a way that actual outstanding queues to be
included in a block could also be incorporated in fee estimation. See
https://github.com/bitcoin/bitcoin/pull/6281.
- CPFP and RBF are candidates for inclusion in core soon, both of which
could be integrated into transaction processing to handle the edge cases
where a priori fee estimation fails. See
https://github.com/bitcoin/bitcoin/pull/1647 and
https://github.com/bitcoin/bitcoin/pull/6176
I know there has been much discussion of fee estimation not working for SPV
clients, but I believe several independent servers which were serving the
estimates from full nodes would go a long way towards allowing that
information to be used by SPV clients even if its not a completely
decentralized solution. See for example
http://core2.bitcoincore.org/smartfee/latest.json
On Mon, Jun 15, 2015 at 8:08 PM, Aaron Voisine <voisine at gmail.com> wrote:
> Wasn't the XT hard fork proposed as a last resort, should the bitcoin-core
> maintainers simply refuse to lift the 1Mb limit? No one wants to go that
> route. An alternate hard-fork proposal like BIP100 that gets consensus, or
> a modified version of gavin's that ups the limit to 8Mb instead of 20Mb, or
> hell even some major changes to the non-consunsus code to make it
> adequately handle the situation when blocks fill up, and allow wallet
> software to continue working with a send-and-forget use pattern, any of
> these would be enough to avoid the need for an XT only hard-fork.
>
> So far BIP100 is the only one that seems to actually be getting any sort
> of momentum toward consensus, and it was proposed... 2 days ago? When the
> XT fork was proposed as a last resort, it was when the opponents were (to
> my understanding) suggesting we just let blocks fill up, and hopefully
> things would just work out on their own.
>
>
>
> Aaron Voisine
> co-founder and CEO
> breadwallet.com
>
> On Mon, Jun 15, 2015 at 3:56 PM, Brian Hoffman <brianchoffman at gmail.com>
> wrote:
>
>> Who is actually planning to move to Bitcoin-XT if this happens?
>>
>> Just Gavin and Mike?
>>
>> [image: image1.JPG]
>>
>> On Jun 15, 2015, at 6:17 PM, Faiz Khan <faizkhan00 at gmail.com> wrote:
>>
>> I'm quite puzzled by the response myself, it doesn't seem to address some
>> of the (more serious) concerns that Adam put out, the most important
>> question that was asked being the one regarding personal ownership of the
>> proposed fork:
>>
>> "How do you plan to deal with security & incident response for the
>> duration you describe where you will have control while you are deploying
>> the unilateral hard-fork and being in sole maintainership control?"
>>
>> I do genuinely hope that whomever (now and future) wishes to fork the
>> protocol reconsider first whether they are truly ready to test/flex their
>> reputation/skills/resources in this way... Intuitively, to me it seems
>> counterproductive, and I don't fully believe it is within a single
>> developer's talents to manage the process start-to-finish (as it is
>> non-trivial to hard-fork successfully, others have rehashed this in other
>> threads)...
>>
>> That being said I think it appropriate if Adam's questions were responded
>> in-line when Mike is feeling up to it. I think that the answers are
>> important for the community to hear when such a drastic change is being
>> espoused.
>>
>> Faiz
>>
>> On Mon, Jun 15, 2015 at 4:56 PM, Bryan Bishop <kanzure at gmail.com> wrote:
>>
>>> On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn <mike at plan99.net> wrote:
>>>
>>>> Re: anyone who agrees with noted non-programmers Mike&Gavin must be
>>>> non-technical, stupid, uninformed, etc .... OK, go ahead and show them the
>>>> error of their ways. Anyone can write blogs.
>>>>
>>>
>>> I worry that if this is the level of care you take with reading and
>>> (mis)interpreting Adam's messages, that you might not be taking extreme
>>> care with evaluating consensus changes, even while tired or sleeping. I
>>> encourage you to evaluate both messages and source code more carefully,
>>> especially in the world of bitcoin. However, this goes for everyone and not
>>> just you. Specifically, when Adam mentioned your conversations with
>>> non-technical people, he did not mean "Mike has talked with people who have
>>> possibly not made pull requests to Bitcoin Core, so therefore Mike is a
>>> non-programmer". Communication is difficult and I can understand that, but
>>> we really have to be more careful when evaluating each other's messages;
>>> technical miscommunication can be catastrophic in this context. On the
>>> topic of whether you are a programmer, I suspect that ever since you built
>>> CIA.vc we have all known you're a programmer, Mike.
>>>
>>> - Bryan
>>> http://heybryan.org/
>>> 1 512 203 0507
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>> --
>>>
>>> My regards,
>>>
>>> Faiz Khan
>>>
>>> <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/66911ee3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image1.JPG
Type: image/jpeg
Size: 22107 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/66911ee3/attachment.jpe>

2023-06-07 15:33:10

- reply

📅 Original date posted:2015-05-07
📝 Original message:That strikes me as a dangerous path forward.
I don't actually think there is anything wrong with this: "everybody
eventually gets tired of arguing angels-dancing-on-the-head-of-a-pin, and
we're left with the status quo"
What gives Bitcoin value aren't its technical merits but the fact that
people believe in it. The biggest risk here isn't that 20MB blocks will
be bad or that 1MB blocks will be bad, but that by forcing a hard fork that
isn't nearly universally agreed upon, we will be damaging that belief. If
I strongly believed some hard fork would be better for Bitcoin, say
permanent inflation of 1% a year to fund mining, and I managed to convince
80% of users, miners, businesses and developers to go along with me, I
would still vote against doing it. Because that's not nearly universal
agreement, and it changes what people chose to believe in without their
consent. Forks should be hard, very hard. And both sides should recognize
that belief in the value of Bitcoin might be a fragile thing. I'd argue
that if we didn't force through a 20MB fork now, and we ran into major
network difficulties a year from now and had no other technical solutions,
that maybe we would get nearly universal agreement, and the businesses and
users that were driven away by the unusable system would be a short term
loss in value considerably smaller than the impairment we risk by forcing a
change.
On Thu, May 7, 2015 at 10:52 AM, Gavin Andresen <gavinandresen at gmail.com>
wrote:
> For reference: the blog post that (re)-started this debate, and which
> links to individual issues, is here:
> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
>
> In it, I asked people to email me objections I might have missed. I would
> still appreciate it if people do that; it is impossible to keep up with
> this mailing list, /r/bitcoin posts and comments, and #bitcoin-wizards and
> also have time to respond thoughtfully to the objections raised.
>
> I would very much like to find some concrete course of action that we can
> come to consensus on. Some compromise so we can tell entrepreneurs "THIS is
> how much transaction volume the main Bitcoin blockchain will be able to
> support over the next eleven years."
>
> I've been pretty clear on what I think is a reasonable compromise (a
> one-time increase scheduled for early next year), and I have tried to
> explain why I think it it is the right set of tradeoffs.
>
> There ARE tradeoffs here, and the hard question is what process do we use
> to decide those tradeoffs? How do we come to consensus? Is it worth my
> time to spend hours responding thoughtfully to every new objection raised
> here, or will the same thing happen that happened last year and the year
> before-- everybody eventually gets tired of arguing
> angels-dancing-on-the-head-of-a-pin, and we're left with the status quo?
>
> I AM considering contributing some version of the bigger blocksize-limit
> hard-fork patch to the Bitcoin-Xt fork (probably "target a hobbyist with a
> fast Internet connection, and assume Nelson's law to increase over time),
> and then encouraging merchants and exchanges and web wallets and
> individuals who think it strikes a reasonable balance to run it.
>
> And then, assuming it became a super-majority of nodes on the network,
> encourage miners to roll out a soft-fork to start producing bigger blocks
> and eventually trigger the hard fork.
>
> Because ultimately consensus comes down to what software people choose to
> run.
>
> --
> --
> Gavin Andresen
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/30afcdf6/attachment.html>

2023-06-07 15:29:29

- reply

📅 Original date posted:2015-02-03
📝 Original message:Could we see a PR that adds it to BIP 66? Perhaps we'd all agree quickly
that its so simple we can just add it...
In either case it doesn't seem strictly necessary to me that it was
non-standard before it becomes a soft-fork...
On Tue, Feb 3, 2015 at 7:00 AM, Wladimir <laanwj at gmail.com> wrote:
> > One way to do that is to just - right now - add a patch to 0.10 to
> > make those non-standard. This requires another validation flag, with a
> > bunch of switching logic.
> >
> > The much simpler alternative is just adding this to BIP66's DERSIG
> > right now, which is a one-line change that's obviously softforking. Is
> > anyone opposed to doing so at this stage?
>
> Not opposed, but is kind of late for 0.10, I had hoped to tag rc4 today.
>
> Wladimir
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150203/aa4477a0/attachment.html>

2023-06-07 15:26:57

- reply

📅 Original date posted:2014-10-28
📝 Original message:RE: 90% : I think it's fine to use 90% for anything other than 1
confirmation, but if you look at the real world data test I did, or the raw
data from this new code, you'll see that even the highest fee rate
transactions only get confirmed at about a 90% rate in 1 block, so that if
you use that as your cut-off you will sometimes get no answer and sometimes
get a very high fee rate and sometimes get a reasonable fee rate, it just
depends because the data is too noisy. I think thats just because there is
no good answer to that question. There is no fee you can put on your
transaction to guarantee greater than 90% chance of getting confirmed in
one block. I think 85% might be safe?
RE: tunable as command-line/bitcoin.conf: sounds good!
OK, sorry to have all this conversation on the dev list, maybe i'll turn
this into an actual PR if we want to comment on the code?
I just wanted to see if it even made sense to make a PR for this or this
isn't the way we wanted to go about it.
On Tue, Oct 28, 2014 at 10:58 AM, Gavin Andresen <gavinandresen at gmail.com>
wrote:
> On Tue, Oct 28, 2014 at 10:30 AM, Alex Morcos <morcos at gmail.com> wrote:
>>
>> Do you think it would make sense to make that 90% number an argument to
>> rpc call? For instance there could be a default (I would use 80%) but then
>> you could specify if you required a different certainty. It wouldn't
>> require any code changes and might make it easier for people to build more
>> complicated logic on top of it.
>>
>
> RE: 80% versus 90% : I think a default of 80% will get us a lot of "the
> fee estimation logic is broken, I want my transactions to confirm quick and
> a lot of them aren't confirming for 2 or 3 blocks."
>
> RE: RPC argument: I'm reluctant to give too many 'knobs' for the RPC
> interface. I think the default percentage makes sense as a
> command-line/bitcoin.conf option; I can imagine services that want to save
> on fees running with -estimatefeethreshold=0.5 (or
> -estimatefeethreshold=0.95 if as-fast-as-possible confirmations are
> needed). Setting both the number of confirmations and the estimation
> threshold on a transaction-by-transaction basis seems like overkill to me.
>
> --
> --
> Gavin Andresen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141028/2ebb0ad7/attachment.html>

2023-06-07 15:26:56

- reply

📅 Original date posted:2014-10-28
📝 Original message:Sorry, perhaps I misinterpreted that question. The estimates will be
dominated by the prevailing transaction rates initially, so the estimates
you get for something like "what is the least I can pay and still be 90%
sure I get confirmed in 20 blocks" won't be insane, but they will still be
way too conservative. I'm not sure what you meant by reasonable. You
won't get the "correct" answer of something significantly less than 40k
sat/kB for quite some time. Given that the half-life of the decay is 2.5
days, then within a couple of days. And in fact even in the steady state,
the new code will still return a much higher rate than the existing code,
say 10k sat/kB instead of 1k sat/kB, but that's just a result of the
sorting the existing code does and the fact that no one places transactions
with that small fee. To correctly give such low answers, the new code
will require that those super low feerate transactions are occurring
frequently enough, but the bar for enough datapoints in a feerate bucket is
pretty low, an average of 1 tx per block. The bar can be made lower at the
expense of a bit of noisiness in the answers, for instance for priorities I
had to make the bar significantly lower because there are so many fewer
transactions confirmed because of priorities. I'm certainly open to tuning
some of these variables.
On Tue, Oct 28, 2014 at 10:30 AM, Alex Morcos <morcos at gmail.com> wrote:
> Oh in just a couple of blocks, it'll give you a somewhat reasonable
> estimate for asking about every confirmation count other than 1, but it
> could take several hours for it to have enough data points to give you a
> good estimate for getting confirmed in one block (because the prevalent
> feerate is not always confirmed in 1 block >80% of the time) Essentially
> what it does is just combine buckets until it has enough data points, so
> after the first block it might be treating all of the txs as belonging to
> the same feerate bucket, but since the answer it returns is the "median"*
> fee rate for that bucket, its a reasonable answer right off the get go.
>
> Do you think it would make sense to make that 90% number an argument to
> rpc call? For instance there could be a default (I would use 80%) but then
> you could specify if you required a different certainty. It wouldn't
> require any code changes and might make it easier for people to build more
> complicated logic on top of it.
>
> *It can't actually track the median, but it identifies which of the
> smaller actual buckets the median would have fallen into and returns the
> average feerate for that median bucket.
>
>
>
>
>
> On Tue, Oct 28, 2014 at 9:59 AM, Gavin Andresen <gavinandresen at gmail.com>
> wrote:
>
>> I think Alex's approach is better; I don't think we can know how much
>> better until we have a functioning fee market.
>>
>> We don't have a functioning fee market now, because fees are hard-coded.
>> So we get "pay the hard-coded fee and you'll get confirmed in one or two or
>> three blocks, depending on which miners mine the next three blocks and what
>> time of day it is."
>>
>> git HEAD code says you need a fee of 10,0000 satoshis/kb to be pretty
>> sure you'll get confirmed in the next block. That looks about right with
>> Alex's real-world data (if we take "90% chance" as 'pretty sure you'll get
>> confirmed'):
>>
>> Fee rate 100000 Avg blocks to confirm 1.09 NumBlocks:% confirmed 1: 0.901
>> 2: 1.0 3: 1.0
>>
>> My only concern with Alex's code is that it takes much longer to get
>> 'primed' -- Alex, if I started with no data about fees, how long would it
>> take to be able to get enough data for a reasonable estimate of "what is
>> the least I can pay and still be 90% sure I get confirmed in 20 blocks" ?
>> Hours? Days? Weeks?
>>
>> --
>> --
>> Gavin Andresen
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141028/06848964/attachment.html>

2023-06-07 15:26:56

- reply

📅 Original date posted:2014-10-28
📝 Original message:Oh in just a couple of blocks, it'll give you a somewhat reasonable
estimate for asking about every confirmation count other than 1, but it
could take several hours for it to have enough data points to give you a
good estimate for getting confirmed in one block (because the prevalent
feerate is not always confirmed in 1 block >80% of the time) Essentially
what it does is just combine buckets until it has enough data points, so
after the first block it might be treating all of the txs as belonging to
the same feerate bucket, but since the answer it returns is the "median"*
fee rate for that bucket, its a reasonable answer right off the get go.
Do you think it would make sense to make that 90% number an argument to rpc
call? For instance there could be a default (I would use 80%) but then you
could specify if you required a different certainty. It wouldn't require
any code changes and might make it easier for people to build more
complicated logic on top of it.
*It can't actually track the median, but it identifies which of the smaller
actual buckets the median would have fallen into and returns the average
feerate for that median bucket.
On Tue, Oct 28, 2014 at 9:59 AM, Gavin Andresen <gavinandresen at gmail.com>
wrote:
> I think Alex's approach is better; I don't think we can know how much
> better until we have a functioning fee market.
>
> We don't have a functioning fee market now, because fees are hard-coded.
> So we get "pay the hard-coded fee and you'll get confirmed in one or two or
> three blocks, depending on which miners mine the next three blocks and what
> time of day it is."
>
> git HEAD code says you need a fee of 10,0000 satoshis/kb to be pretty sure
> you'll get confirmed in the next block. That looks about right with Alex's
> real-world data (if we take "90% chance" as 'pretty sure you'll get
> confirmed'):
>
> Fee rate 100000 Avg blocks to confirm 1.09 NumBlocks:% confirmed 1: 0.901
> 2: 1.0 3: 1.0
>
> My only concern with Alex's code is that it takes much longer to get
> 'primed' -- Alex, if I started with no data about fees, how long would it
> take to be able to get enough data for a reasonable estimate of "what is
> the least I can pay and still be 90% sure I get confirmed in 20 blocks" ?
> Hours? Days? Weeks?
>
> --
> --
> Gavin Andresen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141028/3e672923/attachment.html>

2023-06-07 15:26:55

- reply

📅 Original date posted:2014-10-28
📝 Original message:Yeah, so to explain points 1 and 2 a bit more
1) It's about what question you are trying to answer. The existing code
tries to answer the question of what is the median fee of a transaction
that gets confirmed in Y blocks. It turns out that is not a very good
proxy for the question we really want to know which is what is the fee that
is necessary such that we are likely to be confirmed within Y blocks.
What happens is that there are so many transactions of the 40k satoshis/kB
feerate that they turn out to be the dominant data points of transactions
that are confirmed after 2 blocks, 3 blocks, etc. and not only 1 block.
So for example. A hypothetical sample of 20 txs might find 2 of your 1k
sat/kB txs and 18 of the 40k sat/kB txs. Perhaps 15 of the 40k txs are
confirmed in 1 block and the other 3 in 2 blocks, and 1 of the 1k txs in 1
block and the other in 2 blocks. So if you analyze the data by
confirmation time, you find that 15/16 1-conf txs are 40k and 3/4 2-conf
txs are 40k, so the median feerate is 40k for both 1 and 2 confirmations.
Instead, the correct thing to do is analyze the data by feerate. Doing
that, we find that 15/18 (83%) of 40k txs are confirmed in 1 block and 1/2
(50%) 1k txs are. But 100% of both are confirmed within two blocks. This
leads you to say, you need 40k feerate if you want to get confirmed in 1
block but 1k is sufficient if you want to be confirmed in 2 blocks.
Put another way, Let's imagine you wanted to know how tall you have to be
no longer fit in the coach seats on an airplane. If you looked at the
median height of all people in coach and all people in first class, you
would see that they were about the same, and you would get a confusing
answer. Instead you have to bin by height, and look at the percentage of
people of each height that fly first-class vs coach, and I'd guess that by
the time you got up to say 6'8" you were finding greater than 50% of the
people flying first class.
2) The code also presupposes that higher fee rate transactions must be
confirmed quicker. And so in addition to binning all transactions by
confirmation time, the code then sorts all of the transactions and re-bins
them such that the highest fee transactions are all in the 1-confirmation
bin and the lowest fee transactions are all in the 25-confirmation bin. If
we'd been trying to predict whether the first 2 bytes of transaction hash
influenced our confirmation time, we would have started by having a random
distribution of hashes in each confirmation bin, but then after doing the
sorting, we'd of course have found that the "median hash" of the
1-confirmation transactions was higher, because we sorted it to make that
the case.
In the airplane example this would have been equivalent to taking the
median height of the 20 tallest people on the plane (assuming first class
is 20 seats) and saying that was the height for first class and the median
height of the remaining people for coach. This will appear to give a
slightly better answer than the first approach, but is still wrong.
There are still a lot of additional improvements that can be made to fee
estimation. One problem my proposed code has is there really just aren't
enough data points of low feerate transactions to give meaningful answers
about how likely those are to be confirmed, so its answers are still a bit
conservative. This will improve though as the actual distribution of
transactions spreads out. The other major needed improvement is to not
just state some description of what has happened in the past, but to
actually make a prediction about what is going to happen in the future.
For instance looking at the feerates of unconfirmed transactions currently
in the mempool could tell you that if you want to be confirmed immediately
you'll need to be high enough in that priority queue.
On Tue, Oct 28, 2014 at 5:55 AM, Mike Hearn <mike at plan99.net> wrote:
> Could you explain a little further why you think the current approach is
> statistically incorrect? There's no doubt that the existing estimates the
> system produces are garbage, but that's because it assumes players in the
> fee market are rational and they are not.
>
> Fwiw bitcoinj 0.12.1 applies the January fee drop and will attach fee of
> only 1000 satoshis per kB by default. I also have a program that measures
> confirmation time for a given fee level (with fresh coins so there's no
> priority) and it aligns with your findings, most txns confirm within a
> couple of blocks.
>
> Ultimately there isn't any easy method to stop people throwing money away.
> Bitcoinj will probably continue to use hard coded fee values for now to try
> and contribute to market sanity in the hope it makes smartfees smarter.
> On 27 Oct 2014 19:34, "Alex Morcos" <morcos at gmail.com> wrote:
>
>> I've been playing around with the code for estimating fees and found a
>> few issues with the existing code. I think this will address several
>> observations that the estimates returned by the existing code appear to be
>> too high. For instance see @cozz in Issue 4866
>> <https://github.com/bitcoin/bitcoin/issues/4866>.
>>
>> Here's what I found:
>>
>> 1) We're trying to answer the question of what fee X you need in order
>> to be confirmed within Y blocks. The existing code tries to do that by
>> calculating the median fee for each possible Y instead of gathering
>> statistics for each possible X. That approach is statistically incorrect.
>> In fact since certain X's appear so frequently, they tend to dominate the
>> statistics at all possible Y's (a fee rate of about 40k satoshis)
>>
>> 2) The existing code then sorts all of the data points in all of the
>> buckets together by fee rate and then reassigns buckets before calculating
>> the medians for each confirmation bucket. The sorting forces a
>> relationship where there might not be one. Imagine some other variable,
>> such as first 2 bytes of the transaction hash. If we sorted these and then
>> used them to give estimates, we'd see a clear but false relationship where
>> transactions with low starting bytes in their hashes took longer to confirm.
>>
>> 3) Transactions which don't have all their inputs available (because they
>> depend on other transactions in the mempool) aren't excluded from the
>> calculations. This skews the results.
>>
>> I rewrote the code to follow a different approach. I divided all
>> possible fee rates up into fee rate buckets (I spaced these
>> logarithmically). For each transaction that was confirmed, I updated the
>> appropriate fee rate bucket with how many blocks it took to confirm that
>> transaction.
>>
>> The hardest part of doing this fee estimation is to decide what the
>> question really is that we're trying to answer. I took the approach that
>> if you are asking what fee rate I need to be confirmed within Y blocks,
>> then what you would like to know is the lowest fee rate such that a
>> relatively high percentage of transactions of that fee rate are confirmed
>> within Y blocks. Since even the highest fee transactions are confirmed
>> within the first block only 90-93% of the time, I decided to use 80% as my
>> cutoff. So now to answer "estimatefee Y", I scan through all of the fee
>> buckets from the most expensive down until I find the last bucket with >80%
>> of the transactions confirmed within Y blocks.
>>
>> Unfortunately we still have the problem of not having enough data points
>> for non-typical fee rates, and so it requires gathering a lot of data to
>> give reasonable answers. To keep all of these data points in a circular
>> buffer and then sort them for every analysis (or after every new block) is
>> expensive. So instead I adopted the approach of keeping an exponentially
>> decaying moving average for each bucket. I used a decay of .998 which
>> represents a half life of 374 blocks or about 2.5 days. Also if a
>> bucket doesn't have very many transactions, I combine it with the next
>> bucket.
>>
>> Here is a link <https://github.com/morcos/bitcoin/pull/3> to the code.
>> I can create an actual pull request if there is consensus that it makes
>> sense to do so.
>>
>> I've attached a graph comparing the estimates produced for 1-3
>> confirmations by the new code and the old code. I did apply the patch to
>> fix issue 3 above to the old code first. The new code is in green and the
>> fixed code is in purple. The Y axis is a log scale of feerate in satoshis
>> per KB and the X axis is chain height. The new code produces the same
>> estimates for 2 and 3 confirmations (the answers are effectively quantized
>> by bucket).
>>
>> I've also completely reworked smartfees.py. It turns out to require many
>> many more transactions are put through in order to have statistically
>> significant results, so the test is quite slow to run (about 3 mins on my
>> machine).
>>
>> I've also been running a real world test, sending transactions of various
>> fee rates and seeing how long they took to get confirmed. After almost 200
>> tx's at each fee rate, here are the results so far:
>>
>> Fee rate 1100 Avg blocks to confirm 2.30 NumBlocks:% confirmed 1: 0.528
>> 2: 0.751 3: 0.870
>> Fee rate 2500 Avg blocks to confirm 2.22 NumBlocks:% confirmed 1: 0.528
>> 2: 0.766 3: 0.880
>> Fee rate 5000 Avg blocks to confirm 1.93 NumBlocks:% confirmed 1: 0.528
>> 2: 0.782 3: 0.891
>> Fee rate 10000 Avg blocks to confirm 1.67 NumBlocks:% confirmed 1: 0.569
>> 2: 0.844 3: 0.943
>> Fee rate 20000 Avg blocks to confirm 1.33 NumBlocks:% confirmed 1: 0.715
>> 2: 0.963 3: 0.989
>> Fee rate 30000 Avg blocks to confirm 1.27 NumBlocks:% confirmed 1: 0.751
>> 2: 0.974 3: 1.0
>> Fee rate 40000 Avg blocks to confirm 1.25 NumBlocks:% confirmed 1: 0.792
>> 2: 0.953 3: 0.994
>> Fee rate 60000 Avg blocks to confirm 1.12 NumBlocks:% confirmed 1: 0.875
>> 2: 1.0 3: 1.0
>> Fee rate 100000 Avg blocks to confirm 1.09 NumBlocks:% confirmed 1: 0.901
>> 2: 1.0 3: 1.0
>> Fee rate 300000 Avg blocks to confirm 1.12 NumBlocks:% confirmed 1: 0.886
>> 2: 0.989 3: 1.0
>>
>>
>> Alex
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141028/bb4e512b/attachment.html>

2023-06-07 15:26:54

- reply

📅 Original date posted:2014-10-27
📝 Original message:I've been playing around with the code for estimating fees and found a few
issues with the existing code. I think this will address several
observations that the estimates returned by the existing code appear to be
too high. For instance see @cozz in Issue 4866
<https://github.com/bitcoin/bitcoin/issues/4866>.
Here's what I found:
1) We're trying to answer the question of what fee X you need in order to
be confirmed within Y blocks. The existing code tries to do that by
calculating the median fee for each possible Y instead of gathering
statistics for each possible X. That approach is statistically incorrect.
In fact since certain X's appear so frequently, they tend to dominate the
statistics at all possible Y's (a fee rate of about 40k satoshis)
2) The existing code then sorts all of the data points in all of the
buckets together by fee rate and then reassigns buckets before calculating
the medians for each confirmation bucket. The sorting forces a
relationship where there might not be one. Imagine some other variable,
such as first 2 bytes of the transaction hash. If we sorted these and then
used them to give estimates, we'd see a clear but false relationship where
transactions with low starting bytes in their hashes took longer to confirm.
3) Transactions which don't have all their inputs available (because they
depend on other transactions in the mempool) aren't excluded from the
calculations. This skews the results.
I rewrote the code to follow a different approach. I divided all possible
fee rates up into fee rate buckets (I spaced these logarithmically). For
each transaction that was confirmed, I updated the appropriate fee rate
bucket with how many blocks it took to confirm that transaction.
The hardest part of doing this fee estimation is to decide what the
question really is that we're trying to answer. I took the approach that
if you are asking what fee rate I need to be confirmed within Y blocks,
then what you would like to know is the lowest fee rate such that a
relatively high percentage of transactions of that fee rate are confirmed
within Y blocks. Since even the highest fee transactions are confirmed
within the first block only 90-93% of the time, I decided to use 80% as my
cutoff. So now to answer "estimatefee Y", I scan through all of the fee
buckets from the most expensive down until I find the last bucket with >80%
of the transactions confirmed within Y blocks.
Unfortunately we still have the problem of not having enough data points
for non-typical fee rates, and so it requires gathering a lot of data to
give reasonable answers. To keep all of these data points in a circular
buffer and then sort them for every analysis (or after every new block) is
expensive. So instead I adopted the approach of keeping an exponentially
decaying moving average for each bucket. I used a decay of .998 which
represents a half life of 374 blocks or about 2.5 days. Also if a bucket
doesn't have very many transactions, I combine it with the next bucket.
Here is a link <https://github.com/morcos/bitcoin/pull/3> to the code. I
can create an actual pull request if there is consensus that it makes sense
to do so.
I've attached a graph comparing the estimates produced for 1-3
confirmations by the new code and the old code. I did apply the patch to
fix issue 3 above to the old code first. The new code is in green and the
fixed code is in purple. The Y axis is a log scale of feerate in satoshis
per KB and the X axis is chain height. The new code produces the same
estimates for 2 and 3 confirmations (the answers are effectively quantized
by bucket).
I've also completely reworked smartfees.py. It turns out to require many
many more transactions are put through in order to have statistically
significant results, so the test is quite slow to run (about 3 mins on my
machine).
I've also been running a real world test, sending transactions of various
fee rates and seeing how long they took to get confirmed. After almost 200
tx's at each fee rate, here are the results so far:
Fee rate 1100 Avg blocks to confirm 2.30 NumBlocks:% confirmed 1: 0.528
2: 0.751 3: 0.870
Fee rate 2500 Avg blocks to confirm 2.22 NumBlocks:% confirmed 1: 0.528
2: 0.766 3: 0.880
Fee rate 5000 Avg blocks to confirm 1.93 NumBlocks:% confirmed 1: 0.528
2: 0.782 3: 0.891
Fee rate 10000 Avg blocks to confirm 1.67 NumBlocks:% confirmed 1: 0.569
2: 0.844 3: 0.943
Fee rate 20000 Avg blocks to confirm 1.33 NumBlocks:% confirmed 1: 0.715
2: 0.963 3: 0.989
Fee rate 30000 Avg blocks to confirm 1.27 NumBlocks:% confirmed 1: 0.751
2: 0.974 3: 1.0
Fee rate 40000 Avg blocks to confirm 1.25 NumBlocks:% confirmed 1: 0.792
2: 0.953 3: 0.994
Fee rate 60000 Avg blocks to confirm 1.12 NumBlocks:% confirmed 1: 0.875
2: 1.0 3: 1.0
Fee rate 100000 Avg blocks to confirm 1.09 NumBlocks:% confirmed 1: 0.901
2: 1.0 3: 1.0
Fee rate 300000 Avg blocks to confirm 1.12 NumBlocks:% confirmed 1: 0.886
2: 0.989 3: 1.0
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141027/70128962/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Fee Estimation Comparison.jpg
Type: image/jpeg
Size: 90822 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141027/70128962/attachment.jpg>

2023-06-07 15:15:28

- reply

📅 Original date posted:2014-03-14
📝 Original message:I think Mark makes some good arguments.
I realize this would only add to the confusion, but...
What if we did relabel 100 satoshis to be some new kind of unit ("bit" or
whatever else), with a proper 3 letter code, and then from a user
standpoint, where people are using mBTC, they could switch to using Kbits
(ok thats obviously bad, but you get the idea) at the same nominal price.
But accounting backends and so forth would operate in the "bit" base unit
with 2 decimals of precision.
On Fri, Mar 14, 2014 at 12:01 PM, Mark Friedenbach <mark at monetize.io> wrote:
> A cup of coffee in Tokyo costs about 55 yen. You see similar magnitude
> numbers in both Chinas, Thailand, and other economically important East
> Asian countries. Expect to pay hundreds of rupees in India, or thousands
> of rupees in Indonesia.
>
> This concept that money should have low, single digits for everyday
> prices is not just Western-centric, it's English-centric. An expresso in
> Rome would have cost you a few (tens of?) thousand lira in recent
> memory. It was pegging of the Euro to the U.S. dollar that brought
> European states in line with the English-speaking world (who themselves
> trace lineage to the pound sterling).
>
> No, there is no culturally-neutral common standards for currency and
> pricing. But there are ill-advised, ill-informed "standards" in
> accounting software that we nevertheless must live with. These software
> packages do not handle more than two decimal places gracefully. That
> gives technical justifications for moving to either uBTC or accounting
> in Satoshis directly. An argument for uBTC is that it retains alignment
> with the existing kBTC/BTC/mBTC/uBTC conventions.
>
> However another limitation of these accounting software practices is
> that they do not always handle SI notation very well, particularly
> sub-unit prefixes. By relabeling uBTC to be a new three-digit symbol
> (XBT, XBC, IBT, NBC, or whatever--I really don't care), we are now fully
> compliant with any software accounting package out there.
>
> We are still very, very early in the adoption period. These are changes
> that could be made now simply by a few big players and/or the bitcoin
> foundation changing their practice and their users following suit.
>
> On 03/14/2014 07:49 AM, Andreas Schildbach wrote:
> > How much do you pay for an Espresso in your local currency?
> >
> > At least for the Euro and the Dollar, mBTC 3.56 is very close to what
> > people would expect. Certainly more familiar than µBTC 3558 or BTC
> > 0.003578.
> >
> > Anyway, I was just sharing real-world experience: nobody is confused.
> >
> >
> > On 03/14/2014 03:14 PM, Tamas Blummer wrote:
> >> You give them a hard to interpret thing like mBTC and then wonder
> >> why they rather look at local currency. Because the choices you
> >> gave them are bad.
> >>
> >> I think Bitcoin would have a better chance to be percieved as a
> >> currency of its own if it had prices and fractions like currencies
> >> do.
> >>
> >> 3.558 mBTC or 0.003578 BTC will never be as accepted as 3558 bits
> >> would be.
> >>
> >>
> >> Tamas Blummer Bits of Proof
> >>
> >> On 14.03.2014, at 15:05, Andreas Schildbach <andreas at schildbach.de>
> >> wrote:
> >>
> >>> btw. None of Bitcoin Wallet's users complained about confusion
> >>> because of the mBTC switch. In contrast, I get many mails and
> >>> questions if exchange rates happen to differ by >10%.
> >>>
> >>> I suspect nobody looks at the Bitcoin price. It's the amount in
> >>> local currency that matters to the users.
> >>>
> >>>
> >>> On 03/13/2014 02:40 PM, Andreas Schildbach wrote:
> >>>> Indeed. And users were crying for mBTC. Nobody was asking for
> >>>> µBTC.
> >>>>
> >>>> I must admit I was not aware if this thread. I just watched
> >>>> other wallets and at some point decided its time to switch to
> >>>> mBTC.
> >>>>
> >>>>
> >>>> On 03/13/2014 02:31 PM, Mike Hearn wrote:
> >>>>> The standard has become mBTC and that's what was adopted.
> >>>>> It's too late to try and sway this on a mailing list thread
> >>>>> now.
> >>>>>
> >>>>>
> >>>>> On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe
> >>>>> <g.rowe at froot.co.uk <mailto:g.rowe at froot.co.uk>> wrote:
> >>>>>
> >>>>> The MultiBit HD view is that this is a locale-sensitive
> >>>>> presentation issue. As a result we offer a simple
> >>>>> configuration panel giving pretty much every possible
> >>>>> combination: icon, m+icon, μ+icon, BTC, mBTC, μBTC, XBT,
> >>>>> mXBT, μXBT, sat along with settings for leading/trailing
> >>>>> symbol, commas, spaces and points. This allows anyone to
> >>>>> customise to meet their own needs beyond the offered default.
> >>>>>
> >>>>>
> >>>>> We apply the NIST guidelines for representation of SI unit
> >>>>> symbols (i.e no conversion to native language, no RTL giving
> >>>>> icon+m etc).
> >>>>>
> >>>>> Right now MultiBit HD is configured to use m+icon taken from
> >>>>> the Font Awesome icon set. However reading earlier posts it
> >>>>> seems that μ+icon is more sensible.
> >>>>>
> >>>>> Let us know what you'd like.
> >>>>>
> >>>>> Links: m+icon screenshot: http://imgur.com/a/WCDoG Font
> >>>>> Awesome icon:
> >>>>> http://fortawesome.github.io/Font-Awesome/icon/btc/ NIST SI
> >>>>> guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html
> >>>>>
> >>>>>
> >>>>> On 13 March 2014 12:56, Jeff Garzik <jgarzik at bitpay.com
> >>>>> <mailto:jgarzik at bitpay.com>> wrote:
> >>>>>
> >>>>> Resurrecting this topic. Bitcoin Wallet moved to mBTC
> >>>>> several weeks ago, which was disappointing -- it sounded like
> >>>>> the consensus was uBTC, and moving to uBTC later --which will
> >>>>> happen-- may result in additional user confusion, thanks to
> >>>>> yet another decimal place transition.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Sun, Nov 17, 2013 at 9:28 PM, Wendell <w at grabhive.com
> >>>>> <mailto:w at grabhive.com>> wrote:
> >>>>>> We're with uBTC too. Been waiting for the signal to do
> >>>>>> this,
> >>>>> let's do it right after the fee system is improved.
> >>>>>>
> >>>>>> -wendell
> >>>>>>
> >>>>>> grabhive.com <http://grabhive.com> |
> >>>>>> twitter.com/hivewallet
> >>>>> <http://twitter.com/hivewallet> | gpg: 6C0C9411
> >>>>>>
> >>>>>> On Nov 15, 2013, at 6:03 AM, Jeff Garzik wrote:
> >>>>>>
> >>>>>>> Go straight to uBTC. Humans and existing computer
> >>>>>>> systems
> >>>>> handle numbers to
> >>>>>>> the left of the decimals just fine (HK Dollars, Yen).
> >>>>>>> The
> >>>>> opposite is
> >>>>>>> untrue (QuickBooks really does not like 3+ decimal
> >>>>>>> places).
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> -- Jeff Garzik Bitcoin core developer and open source
> >>>>> evangelist BitPay, Inc. https://bitpay.com/
> >>>>>
> >>>>>
> ------------------------------------------------------------------------------
> >>>>>
> >>>>>
> > Learn Graph Databases - Download FREE O'Reilly Book
> >>>>> "Graph Databases" is the definitive new guide to graph
> >>>>> databases and their applications. Written by three acclaimed
> >>>>> leaders in the field, this first edition is now available.
> >>>>> Download your free book today!
> >>>>> http://p.sf.net/sfu/13534_NeoTech
> >>>>> _______________________________________________
> >>>>> Bitcoin-development mailing list
> >>>>> Bitcoin-development at lists.sourceforge.net
> >>>>> <mailto:Bitcoin-development at lists.sourceforge.net>
> >>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >
> ------------------------------------------------------------------------------
> >>>>> Learn Graph Databases - Download FREE O'Reilly Book "Graph
> >>>>> Databases" is the definitive new guide to graph databases
> >>>>> and their applications. Written by three acclaimed leaders in
> >>>>> the field, this first edition is now available. Download your
> >>>>> free book today! http://p.sf.net/sfu/13534_NeoTech
> >>>>> _______________________________________________
> >>>>> Bitcoin-development mailing list
> >>>>> Bitcoin-development at lists.sourceforge.net
> >>>>> <mailto:Bitcoin-development at lists.sourceforge.net>
> >>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >
> ------------------------------------------------------------------------------
> >>>>> Learn Graph Databases - Download FREE O'Reilly Book "Graph
> >>>>> Databases" is the definitive new guide to graph databases and
> >>>>> their applications. Written by three acclaimed leaders in the
> >>>>> field, this first edition is now available. Download your
> >>>>> free book today! http://p.sf.net/sfu/13534_NeoTech
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Bitcoin-development mailing list
> >>>>> Bitcoin-development at lists.sourceforge.net
> >>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>
> >
> ------------------------------------------------------------------------------
> >>>> Learn Graph Databases - Download FREE O'Reilly Book "Graph
> >>>> Databases" is the definitive new guide to graph databases and
> >>>> their applications. Written by three acclaimed leaders in the
> >>>> field, this first edition is now available. Download your free
> >>>> book today! http://p.sf.net/sfu/13534_NeoTech
> >>>> _______________________________________________
> >>>> Bitcoin-development mailing list
> >>>> Bitcoin-development at lists.sourceforge.net
> >>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>>>
> >
> ------------------------------------------------------------------------------
> >>> Learn Graph Databases - Download FREE O'Reilly Book "Graph
> >>> Databases" is the definitive new guide to graph databases and
> >>> their applications. Written by three acclaimed leaders in the
> >>> field, this first edition is now available. Download your free
> >>> book today! http://p.sf.net/sfu/13534_NeoTech
> >>> _______________________________________________
> >>> Bitcoin-development mailing list
> >>> Bitcoin-development at lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >>
> >>
> > Learn Graph Databases - Download FREE O'Reilly Book
> >> "Graph Databases" is the definitive new guide to graph databases
> >> and their applications. Written by three acclaimed leaders in the
> >> field, this first edition is now available. Download your free book
> >> today! http://p.sf.net/sfu/13534_NeoTech
> >>
> >>
> >>
> >> _______________________________________________ Bitcoin-development
> >> mailing list Bitcoin-development at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Learn Graph Databases - Download FREE O'Reilly Book
> > "Graph Databases" is the definitive new guide to graph databases and
> their
> > applications. Written by three acclaimed leaders in the field,
> > this first edition is now available. Download your free book today!
> > http://p.sf.net/sfu/13534_NeoTech
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140314/b6d600bc/attachment.html>

2023-06-07 15:13:23

- reply

📅 Original date posted:2014-02-12
📝 Original message:I apologize if this has been discussed many times before.
As a long term solution to malleable transactions, wouldn't it be possible
to modify the signatures to be of the entire transaction. Why do you have
to zero out the inputs? I can see that this would be a hard fork, and
maybe it would be somewhat tricky to extract signatures first (since you
can sign everything except the signatures), but it would seem to me that
this is an important enough change to consider making.
On Wed, Feb 12, 2014 at 5:52 PM, Luke-Jr <luke at dashjr.org> wrote:
> On Wednesday, February 12, 2014 8:27:52 PM Mark Friedenbach wrote:
> > On 02/12/2014 08:44 AM, Alan Reiner wrote:
> > > Changing the protocol to use these static IDs is a pretty fundamental
> > > change that would never happen in Bitcoin. But they can still be
> > > useful at the application level to mitigate these issues.
> >
> > Not to mention that it would be potentially very insecure to have
> > consensus depend on data (scriptSigs) which are not hashed in the Merkle
> > structure of a block.
> >
> > Not that anyone on this list has suggested such a change, but I've seen
> > it raised multiple times on the forum....
>
> This would be a problem if it was used in the merkle tree, but I'm pretty
> sure
> using it for input selection would be pretty safe. One could even avoid the
> index by simply using the hashScript as the sole input value; then even
> CoinJoins would be safe without breaking chains of transactions (although
> this
> would break address reuse entirely - but I don't see that as a problem in a
> theoretical world). One of those things that an altcoin could improve upon
> Bitcoin with... ;)
>
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience. Start now.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140212/1bd41008/attachment.html>