Jeff Garzik [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2011-06-12 to 2015-12-21
💬 Posted a total of 545 messages
📚 Participated in the following categories: Bitcoin-development, ANN, PATCH, ANNOUNCE, PATCH, try2, RFC, BIP proposal, BIP draft, softfork proposal, bitcoin-dev, Was: Re: Let's deploy BIP65 CHECKLOCKTIMEVERIFY!, patch
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58

Profile Code

nprofile1qqstyhssufw5wrvmy92jrdgd5r070gsfhmrlah448psv8cvqllwgcyg93psdf

Author Public Key

npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58

Show more details

Last Notes

2023-06-07 17:47:16

- reply

📅 Original date posted:2015-12-21
📝 Original message:On Sun, Dec 20, 2015 at 12:21 PM, joe2015--- via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Remember this is proposed as an alternative to hardforks, which is also a
> "nuclear option". Hardforks carry significant risks such as permanently
> splitting Bitcoin into two chains if global consensus is never reached. A
> (generalized) softfork avoids this problem.
Current hard fork implementations include / will include miner lock-in,
just like any soft fork. They will not activate if global consensus is not
reached.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151220/264fff1d/attachment.html>

2023-06-07 17:46:50

- reply

📅 Original date posted:2015-12-18
📝 Original message:My preference is height activation + one step per block (i.e. also
height). Height seems KISS.
AFAICT most of the attacks would occur around the already-heavily-watched
flag day activation event, in a height based environment, a useful
attribute.
However I would like to hear from others about possible attacks with the
various approaches, before diverging from the default community approach of
switch-based-on-time.
On Fri, Dec 18, 2015 at 3:10 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
> Well, if it's not going to be height, I think median time of the previous
> block is better than the time of the current one, and would also solve Chun
> Wang's concerns.
> But as said I prefer to use heights that correspond to diff recalculation
> (because that's the window that bip9 will use for the later 95%
> confirmation anyway).
> On Dec 18, 2015 9:02 PM, "Jeff Garzik" <jgarzik at gmail.com> wrote:
>
>> From a code standpoint, based off height is easy.
>>
>> My first internal version triggered on block 406,800 (~May 5), and each
>> block increased by 20 bytes thereafter.
>>
>> It was changed to time, because time was the standard used in years past
>> for other changes; MTP flag day is more stable than block height.
>>
>> It is preferred to have a single flag trigger (height or time), rather
>> than the more complex trigger-on-time, increment-on-height, but any
>> combination of those will work.
>>
>> Easy to change code back to height-based...
>>
>>
>>
>> On Fri, Dec 18, 2015 at 2:52 PM, Jorge Timón <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> I agree that nHeight is the simplest option and is my preference.
>>> Another option is to use the median time from the previous block (thus
>>> you know whether or not the next block should start the miner confirmation
>>> or not). In fact, if we're going to use bip9 for 95% miner upgrade
>>> confirmation, it would be nice to always pick a difficulty retarget block
>>> (ie block.nHeight % DifficultyAdjustmentInterval == 0).
>>> Actually I would always have an initial height in bip9, for softforks
>>> too.
>>> I would also use the sign bit as the "hardfork bit" that gets activated
>>> for the next diff interval after 95% is reached and a hardfork becomes
>>> active (that way even SPV nodes will notice when a softfork or hardfork
>>> happens and also be able to tell which one is it).
>>> I should update bip99 with all this. And if the 2 mb bump is
>>> uncontroversial, maybe I can add that to the timewarp fix and th recovery
>>> of the other 2 bits in block.nVersion (given that bip102 doesn't seem to
>>> follow bip99's recommendations and doesn't want to give 6 full months as
>>> the pre activation grace period).
>>> On Dec 18, 2015 8:17 PM, "Chun Wang via bitcoin-dev" <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> In many BIPs we have seen, include the latest BIP202, it is the block
>>>> time that determine the max block size. From from pool's point of
>>>> view, it cannot issue a job with a fixed ntime due to the existence of
>>>> ntime roll. It is hard to issue a job with the max block size unknown.
>>>> For developers, it is also easier to implement if max block size is a
>>>> function of block height instead of time. Block height is also much
>>>> more simple and elegant than time.
>>>> _______________________________________________
>>>> 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/20151218/42f35752/attachment-0001.html>

2023-06-07 17:46:49

- reply

📅 Original date posted:2015-12-18
📝 Original message:>From a code standpoint, based off height is easy.
My first internal version triggered on block 406,800 (~May 5), and each
block increased by 20 bytes thereafter.
It was changed to time, because time was the standard used in years past
for other changes; MTP flag day is more stable than block height.
It is preferred to have a single flag trigger (height or time), rather than
the more complex trigger-on-time, increment-on-height, but any combination
of those will work.
Easy to change code back to height-based...
On Fri, Dec 18, 2015 at 2:52 PM, Jorge Timón <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I agree that nHeight is the simplest option and is my preference.
> Another option is to use the median time from the previous block (thus you
> know whether or not the next block should start the miner confirmation or
> not). In fact, if we're going to use bip9 for 95% miner upgrade
> confirmation, it would be nice to always pick a difficulty retarget block
> (ie block.nHeight % DifficultyAdjustmentInterval == 0).
> Actually I would always have an initial height in bip9, for softforks too.
> I would also use the sign bit as the "hardfork bit" that gets activated
> for the next diff interval after 95% is reached and a hardfork becomes
> active (that way even SPV nodes will notice when a softfork or hardfork
> happens and also be able to tell which one is it).
> I should update bip99 with all this. And if the 2 mb bump is
> uncontroversial, maybe I can add that to the timewarp fix and th recovery
> of the other 2 bits in block.nVersion (given that bip102 doesn't seem to
> follow bip99's recommendations and doesn't want to give 6 full months as
> the pre activation grace period).
> On Dec 18, 2015 8:17 PM, "Chun Wang via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> In many BIPs we have seen, include the latest BIP202, it is the block
>> time that determine the max block size. From from pool's point of
>> view, it cannot issue a job with a fixed ntime due to the existence of
>> ntime roll. It is hard to issue a job with the max block size unknown.
>> For developers, it is also easier to implement if max block size is a
>> function of block height instead of time. Block height is also much
>> more simple and elegant than time.
>> _______________________________________________
>> 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/20151218/770de789/attachment.html>

2023-06-07 17:46:43

- reply

📅 Original date posted:2015-12-17
📝 Original message:On Thu, Dec 17, 2015 at 1:46 PM, jl2012 <jl2012 at xbt.hk> wrote:
> This is not correct.
>
> As only about 1/3 of nodes support BIP65 now, would you consider CLTV tx
> are less secure than others? I don't think so. Since one invalid CLTV tx
> will make the whole block invalid. Having more nodes to fully validate
> non-CLTV txs won't make them any safer. The same logic also applies to SW
> softfork.
>
Yes - the logic applies to all soft forks. Each soft fork degrades the
security of non-upgraded nodes.
The core design of bitcoin is that trustless nodes validate the work of
miners, not trust them.
Soft forks move in the opposite direction. Each new soft-forked feature
leans very heavily on miner trust rather than P2P network validation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151217/b7b9e80f/attachment.html>

2023-06-07 17:46:40

- reply

📅 Original date posted:2015-12-16
📝 Original message:Maybe a new analogy helps.
SW presents a blended price and blended basket of two goods. You can
interact with the Service through the blended price, but that does not
erase the fact that the basket contains two separate from similar resources.
A different set of economic actors uses one resource, and/or both. There
are explicit incentives to shift actors from solely using one resource to
using both.
The fact that separate sets of economic actors and incentives exist is
sufficient to prove it is indeed a basket of goods, not a single good.
On Wed, Dec 16, 2015 at 4:36 PM, Pieter Wuille <pieter.wuille at gmail.com>
wrote:
> Thus, the miners' best strategy is to accept the witness transactions,
> as it allows 1000000/110=9090 transactions rather than
> 1000000/200=5000.
>
Under your blended algorithm, this seems reasonable as a first pass.
> In fact, the optimal fee maximizing strategy is always to maximize fee
> per virtual size.
>
This is a microscopic, not macroscopic analysis. Externalities and long
term incentives can severely perturb or invalidate that line of thinking.
Typical counter-example: Many miners are perfectly happy with very low
fees to encourage long term growth of their bitcoin income through network
effect growth -- rendering fee micro-optimizations largely in the realm of
DoS prevention rather than miner incentive.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151216/0f083114/attachment.html>

2023-06-07 17:46:40

- reply

📅 Original date posted:2015-12-16
📝 Original message:On Wed, Dec 16, 2015 at 5:09 PM, Jeff Garzik <jgarzik at gmail.com> wrote:
> SW presents a blended price and blended basket of two goods. You can
> interact with the Service through the blended price, but that does not
> erase the fact that the basket contains two separate from similar resources.
>
separate-but-similar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151216/30baa066/attachment.html>

2023-06-07 17:46:40

- reply

📅 Original date posted:2015-12-17
📝 Original message:On Wed, Dec 16, 2015 at 5:09 PM, Jeff Garzik <jgarzik at gmail.com> wrote:
> SW presents a blended price and blended basket of two goods. You can
> interact with the Service through the blended price, but that does not
> erase the fact that the basket contains two separate from similar resources.
>
> A different set of economic actors uses one resource, and/or both. There
> are explicit incentives to shift actors from solely using one resource to
> using both.
>
Illustration: If SW is deployed via soft fork, the count of nodes that
validate witness data is significantly lower than the count of nodes that
validate non-witness data. Soft forks are not trustless operation, they
depend on miner trust, slowly eroding the trustless validation of older
nodes over time.
Higher security in one data area versus another produces another economic
value distinction between the two goods in the basket, and creates a "pay
more for higher security in core block, pay less for lower security in
witness" dynamic.
This economic distinction is not present if SW is deployed via hard fork.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151217/f0a3b264/attachment.html>

2023-06-07 17:46:39

- reply

📅 Original date posted:2015-12-16
📝 Original message:On Wed, Dec 16, 2015 at 3:59 PM, Pieter Wuille <pieter.wuille at gmail.com>
wrote:
> On Wed, Dec 16, 2015 at 9:38 PM, Jeff Garzik via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > 4.3. Observations on new block economic model
> >
> > SW complicates block economics by creating two separate, supply limited
> > resources.
>
> Not correct. I propose defining the virtual_block_size as base_size +
> witness_size * 0.25, and limiting virtual_block_size to 1M. This
> creates a single variable to optimize for. If accepted, miners are
> incentived to maximize fee per virtual_block_size instead of per size.
>
It is correct. There are two separate sets of economic actors and levels
of contention for each set of space.
That is true regardless of the proposed miner selection algorithm.
> > 5.4. Problem: More complex economic policy, new game theory, new
> bidding
> > structure risks.
> >
> > Splitting blocks into two pieces, each with separate and distinct
> behaviors
> > and resource values, creates two fee markets.
>
> I believe you have misunderstood the proposal in that case.
>
See above. There are two separate and distinct resource velocities and
demand levels in reality. That creates two markets regardless of miner
selection algorithm in the block maker.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151216/17766776/attachment.html>

2023-06-07 17:46:32

- reply

📅 Original date posted:2015-12-17
📝 Original message:On Wed, Dec 16, 2015 at 9:44 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
> At least SW *is* a scaling solution (albeit most of the important benefits
> are long term). The issue of fee events has nothing to do with scaling - it
> has to do with economics...specifically whether we should be subsidizing
> transactions, who should pay the bill for it, etc. My own personal opinion
> is that increasing validation costs works against adoption, not for
> it...even if it artificially keeps fees low - and we'll have to deal with a
> fee event sooner or later anyhow. You may disagree with my opinion, but
> please, let's stop confounding the economic issues with actual scaling.
>
At least on my part, the title of the 1st email was "It's economics & ..."
and focused on (a) economics and (b) transition issues. There was no
confounding. There was a list of real problems and risks taken when 1M is
not lifted in the short term.
Thus "SW is orthogonal" in these emails, because these problems remain
regardless of SW or no, as the 1st email outlined.
The 2nd email addresses the specific assertion of "no 1M hard fork needed,
because SW."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151216/f3dd723a/attachment.html>

2023-06-07 17:46:31

- reply

📅 Original date posted:2015-12-17
📝 Original message:On Wed, Dec 16, 2015 at 3:50 PM, Matt Corallo <lf-lists at mattcorallo.com>
wrote:
> A large part of your argument is that SW will take longer to deploy than a
> hard fork, but I completely disagree. Though I do not agree with some
> people claiming we can deploy SW significantly faster than a hard fork,
> once the code is ready (probably a six month affair) we can get it deployed
> very quickly. It's true the ecosystem may take some time to upgrade, but I
> see that as a feature, not a bug - we can build up some fee pressure with
> an immediate release valve available for people to use if they want to pay
> fewer fees.
>
That's taking a big risk. "Build up some fee pressure" is essentially
risking a Fee Event if uptake is slower than planned, or traffic is greater
than expected.
>
> On the other hand, a hard fork, while simpler for the ecosystem to upgrade
> to, is a 1-2 year affair (after the code is shipped, so at least 1.5-2.5
> from today if we all put off heads down and work). One thing that has
> concerned me greatly through this whole debate is how quickly people seem
> to think we can roll out a hard fork. Go look at the distribution of node
> versions on the network today and work backwards to get nearly every node
> upgraded... Even with a year between fork-version-release and
> fork-activation, we'd still kill a bunch of nodes and instead of reducing
> their security model, lead them to be outright robbed.
>
A hard fork will never achieve 100% There are many credible folks and
estimates who feel a May hard fork is reasonable and doable.
Further, hard forks restore the full trustless nature of the post-hard-fork
nodes. Soft forks continually erode that. That's why SW should come via
hard fork. The end result is more secure - 100% validation of witness
transactions.
If regular hard fork plans are proposed in public, many months in advance,
there is plenty of time for the community to react. Hard forks create a
more predictable market and environment for Users, and a more secure
network.
Further, even if you believe SW makes hard fork unnecessary, it is the
responsible thing to code and communicate to users the plan for a Fee Event
just in case SW uptake and extension block use does not match theoretical
projections of SW proponents.
Finally, SW does not eliminate and is orthogonal to Short Term Problem #1
(orig. email - drift into ECE)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151216/f044cec8/attachment-0001.html>

2023-06-07 17:46:29

- reply

📅 Original date posted:2015-12-16
📝 Original message:1. Summary
Segregated Witness (SegWitness, SW) is being presented in the context of
Scaling Bitcoin. It has useful attributes, notably addressing a major
malleability vector, but is not a short term scaling solution.
2. Definitions
Import Fee Event, ECE, TFM, FFM from previous email.
Older clients - Any software not upgraded to SW
Newer clients - Upgraded, SW aware software
Block size - refers to the core block economic resource limited by
MAX_BLOCK_SIZE. Witness data (or extension block data) is excluded.
Requires a hard fork to change.
Core block - Current bitcoin block, with upper bound MAX_BLOCK_SIZE. Not
changed by SW.
Extended transaction - Newer, upgraded version of transaction data format.
Extended block - Newer, upgraded version of block data format.
EBS - Extended block size. Block size seen by newer clients.
3. Context of analysis
One proposal presents SW *in lieu of* a hard fork block size increase.
This email focuses directly on that.
Useful features outside block size context, such as anti-malleability or
fraud proof features, are not covered in depth.
4.1. Observations on data structure formats and views
SW creates two *views* of each transaction and block. SW has blocks and
extended blocks. Similarly, there exists transactions and extended
transactions.
This view is rendered to clients depending on compatibility level. Newer
clients see extended blocks and extended transactions. Older clients see
blocks (limit 1M), and do not see extended blocks. Older clients see
upgraded transactions as unsigned, anyone-can-pay transactions.
Each extended transaction exists in two states, one unsigned and one
signed, each of which passes validation as a valid bitcoin transaction.
4.2. Observations on behavior of older transaction creation
Transactions created by older clients will not use the extended transaction
format. All data is stored the standard 1M block as today.
4.3. Observations on new block economic model
SW complicates block economics by creating two separate, supply limited
resources.
The core block economic resource is heavily contended. Older clients use
core blocks exclusively. Newer clients use core blocks more
conservatively, storing as much data as possible in extended blocks.
The extended block economic resource is less heavily contended, though that
of course grows over time as clients upgrade.
Because core blocks are more heavily contended, it is presumed that older
clients will pay a higher fee than newer clients (subject to elasticity
etc.).
5.1. Problem: Pace of roll-out will be slow - Whole Ecosystem must be
considered.
The current apparent proposal is to roll out Segregated Witness as a soft
fork, and keep block size at 1M.
The roll-out pace cannot simply be judged by soft fork speed - which is
months at best. Analysis must the layers above: Updating bitcoin-core
(JS) and bitcoinj (Java), and then the timelines to roll out those updates
to apps, and then the timeline to update those apps to create extended
transactions.
Overall, wallet software and programmer libraries must be upgraded to make
use of this new format, adding many more months (12+ in some stacks) to the
roll out timeline. In the meantime, clients continue to contend entirely
for core block space.
5.2. Problem: Hard fork to bigger block size Just Works(tm) with most
software, unlike SW.
A simple hard fork such as BIP 102 is automatically compatible with the
vast range of today's ecosystem software.
SW requires merchants to upgrade almost immediately, requires wallet and
other peripheral software upgrades to make use of. Other updates are
opt-in and occur more slowly. BIP 70 processors need some updates.
The number of LOC that must change for BIP 102 is very small, and the
problem domain well known, versus SW.
5.3. Problem: Due to pace, Fee Event not forestalled.
Even presuming SW is merged into Bitcoin Core tomorrow, this does not
address the risk of a Fee Event and associated Economic Change in the
coming months.
5.4. Problem: More complex economic policy, new game theory, new bidding
structure risks.
Splitting blocks into two pieces, each with separate and distinct behaviors
and resource values, creates *two fee markets.*
Having two pricing strata within each block has certainly feasible - that
is the current mining policy of (1) fee/KB followed by (2) priority/age.
Valuable or not - e.g. incentivizing older clients to upgrade - the fact
remains that SW creates a more-complex bidding structure by creating a
second economic resource.
*This is clearly a change to a new economic policy* with standard risks
associated with that. Will that induce an Economic Change Event (see def
last email)? *Unlikely*, due to slow rollout pace.
5.5. Problem: Current SW mining algorithm needs improvement
Current SW block template maker does a reasonable job, but makes some naive
assumptions about the fee market across an entire extended block. This is
a mismatch with the economic reality (just described).
5.6. Problem: New, under-analyzed attack surfaces
Less significant and fundamental but still worth noting.
This is not a fundamental SW problem, but simply standard complexity risk
factors: splitting the signatures away from transactions, and creating a
new apparently-unsigned version of the transaction opens the possibility of
some network attacks which cause some clients to degrade down from extended
block to core block mode temporarily.
There is a chance of a failure mode that fools older clients into thinking
fraudulent data is valid (judgement: unlikely vis hashpower but not
impossible)
6. Conclusions and recommendations
It seems unlikely that SW provides scaling in the short term, and SW
introduces new economics complexities.
A "short term bump" hard fork block size increase addresses economic and
ecosystem risks that SW does not.
Bump + SW should proceed in parallel, independent tracks, as orthogonal
issues.
7. Appendix - Other SW comments
Hard forks provide much stronger validation, and ensure the network
operates at a fully trustless level.
SW hard fork is preferred, versus soft fork. Soft forking SW places a huge
amount of trust on miners to validate transaction signatures, versus the
rest of the network, as the network slowly upgrades to newer clients.
An SW hard fork could also add several zero-filled placeholders in a merkle
tree for future use.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151216/1c334c8f/attachment-0001.html>

2023-06-07 17:46:25

- reply

📅 Original date posted:2015-12-16
📝 Original message:On Wed, Dec 16, 2015 at 1:36 PM, jl2012 <jl2012 at xbt.hk> wrote:
> 4. In the miners round table on the second day, one of the devs mentioned
> that he didn't want to be seen as the decision maker of Bitcoin. On the
> other hand, Chinese miners repeatedly mentioned that they want several
> concrete proposals from devs which they could choose. I see no
> contradiction between these 2 viewpoints.
>
This was a very interesting dynamic, and seems fair (menu).
> 6. I believe we should avoid a radical "Economic Change Event" at least in
> the next halving cycle, as Bitcoin was designed to bootstrap the adoption
> by high mining reward in the beginning. For this reason, I support an early
> and conservative increase, such as BIP102 or 2-4-8. 2MB is accepted by most
> people and it's better than nothing for BIP101 proponents. By "early" I
> mean to be effective by May, at least 2 months before the halving.
>
That was precisely my logic for picking May 5 as the hard fork date. Some
buffer before halving, enough for caution and iteration in the meantime.
>
> (c) My most optimistic guess is SW will be ready in 6 months, which will
> be very close to halving and potential tx volume burst. And it may not be
> done in 2016, as it does not only involve consensus code, but also change
> in the p2p protocol and wallet design
>
Not just wallet design -- you have to game through the standard steps of:
update dev lib (bitcoin-core.js/bitcoinj) + release cycle, update app +
release cycle, for most actors in the ecosystem, on top of the Bitcoin Core
roll out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151216/9123a94f/attachment.html>

2023-06-07 17:46:24

- reply

📅 Original date posted:2015-12-18
📝 Original message:On Fri, Dec 18, 2015 at 2:56 AM, Pieter Wuille <pieter.wuille at gmail.com>
wrote:
> On Fri, Dec 18, 2015 at 6:11 AM, Jeff Garzik <jgarzik at gmail.com> wrote:
> >> You present this as if the Bitcoin Core development team is in charge
> >> of deciding the network consensus rules, and is responsible for making
> >> changes to it in order to satisfy economic demand. If that is the
> >> case, Bitcoin has failed, in my opinion.
> >
> > Diverging from the satoshi block size change plan[1] and current
> economics
> > would seem to require a high level of months-ahead communication to
> users.
>
> I don't see any plan, but will you say the same thing when the subsidy
>
Yes, I forgot the link:
[1] https://bitcointalk.org/index.php?topic=1347.msg15366#msg15366
> dwindles, and mining income seems to become uncertain? It will equally
> be an economic change, which equally well will have been predictable,
> and it will equally well be treatable with a hardfork to increase the
> subsidy.
>
That is a red herring. Nobody I know has proposed this, and I am opposed
to changing that fundamental.
It is well known that the 1M limit was never intended to stay, unlike 21M
coin limit etc.
1M was set high in the beginning because it is a DoS engineering limit, not
an [accidental] economic policy tool.
> But I am not against a block size increase hard fork. My talk on
> segregated witness even included proposed pursuing a hard fork at a
> slightly later stage.
>
Great!
> But what you're arguing for is that - despite being completely
> expected - blocks grew fuller, and people didn't adapt to block size
> pressure and a fee market, so the Core committee now needs to kick the
> can down the road, because we can't accept the risk of economic
> change. That sounds very much like a bailout to me.
>
I am arguing for continuing what we know works. We are 100% certain
blocks-not-full-on-avg works, where a "buffer" of space exists between avg
block size and hard limit.
Any other avenue is by definition speculation and risk. You _think_ you
know what a healthy fee market _should_ be. Massive damage occurs to
bitcoin if you are wrong - and I listed several
vis expectation, there is clear consensus and expectation that block size
would increase, from 2010 onward. It was always a question of _when_ not
if.
Sticking with 1M presents clear risk of (a) economic fracture and (b)
community fracture. It quite clearly risks massive change to an unknown
system at an unknown, unpredictable date in the future.
BIP 102 presents an expected upgrade at a predictable date in the future.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151218/3a05c528/attachment.html>

2023-06-07 17:46:22

- reply

📅 Original date posted:2015-12-16
📝 Original message:On Wed, Dec 16, 2015 at 4:24 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
> Assuming we adopt bip102, eventually you will be able to say exactly the
> same about 2 MB. When does this "let's not change the economics" finishes
> (if ever)?
>
The question is answered in the original email.
In the short term, the risk of a Fee Event and lack of solid post-Fee-Event
economic plan implies "short term bump" reduces those risks.
It is also true - as noted in [1], a bump does create the danger of long
term moral hazard.
This is why a bump should be accompanied with at least a weak public
commitment to flexcap or a similar long term proposal, as the original
email recommended. Communicate clearly the conditions for future change,
then iterate as needs and feedback indicate.
[1] http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151216/eecf9243/attachment.html>

2023-06-07 17:46:22

- reply

📅 Original date posted:2015-12-18
📝 Original message:On Wed, Dec 16, 2015 at 1:34 PM, Pieter Wuille <pieter.wuille at gmail.com>
wrote:
> On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > 2) If block size stays at 1M, the Bitcoin Core developer team should
> sign a
> > collective note stating their desire to transition to a new economic
> policy,
> > that of "healthy fee market" and strongly urge users to examine their fee
> > policies, wallet software, transaction volumes and other possible User
> > impacting outcomes.
>
> You present this as if the Bitcoin Core development team is in charge
> of deciding the network consensus rules, and is responsible for making
> changes to it in order to satisfy economic demand. If that is the
> case, Bitcoin has failed, in my opinion.
>
Diverging from the satoshi block size change plan[1] and current economics
would seem to require a high level of months-ahead communication to users.
> all. Yes, old full nodes after a soft fork are not able to fully
> validate the rules new miners enforce anymore, but they do still
> verify the rules that their operators opted to enforce. Furthermore,
> they can't be prevented. For that reason, I've proposed, and am
> working hard, on an approach that includes Segregated Witness as a
> first step. It shows the ecosystem that something is being done, it
> kicks the can down the road, it solves/issues half a dozen other
> issues at the same time, and it does not require the degree of
> certainty needed for a hardfork.
>
Segregated Witness does not kick the can, it solves none of the problems
#1, #3 - #8 explicitly defined and listed in email #1.
1) A plan of "SW + no hard fork" is gambling with ECE risk, gambling there
will be no Fee Event, because the core block size is still heavily
contended -- 100% contended at time out SW rollout.
2) We are only 100% certain that bitcoin works in the
blocks-not-full-on-avg state, where there is a healthy buffer between the
hard limit and the average block size.
There is remains major ECE risk due to the core block size freeze, possibly
pushing the system into a new, untried economic state and causing major
market and actor disruption. Users of the Service can still drift randomly
and unpredictably into a Fee Event.
SW mitigates this
- only after several months
- only assuming robust adoption rates by up-layer ecosystem software, and
- only assuming transaction volume growth is flat or sub-linear
Those conditions *must* go as planned to fulfill "SW kicked the can" -- a
lot of if's.
As stated, SW is orthogonal to the drift-into-uncharted-waters problem
outlined in email #1, which a short term bump does address.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151218/df9746ce/attachment.html>

2023-06-07 17:46:20

- reply

📅 Original date posted:2015-12-16
📝 Original message:On Wed, Dec 16, 2015 at 1:34 PM, Pieter Wuille <pieter.wuille at gmail.com>
wrote:
> On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > 2) If block size stays at 1M, the Bitcoin Core developer team should
> sign a
> > collective note stating their desire to transition to a new economic
> policy,
> > that of "healthy fee market" and strongly urge users to examine their fee
> > policies, wallet software, transaction volumes and other possible User
> > impacting outcomes.
>
> You present this as if the Bitcoin Core development team is in charge
> of deciding the network consensus rules, and is responsible for making
> changes to it in order to satisfy economic demand. If that is the
> case, Bitcoin has failed, in my opinion.
>
This circles back to Problem #1: Avoidance of a choice is a still a
choice - failing to ACK a MAX_BLOCK_SIZE increase still creates very real
Economic Change Event risk.
And #3: If the likely predicted course is that Bitcoin Core will not
accept a protocol change changing MAX_BLOCK_SIZE via hard fork in the short
term, the core dev team should communicate that position clearly to users
and media.
Hitting a Fee Event is market changing, potentially reshuffling economic
actors to a notable degree. Maintaining a short term economic policy of
fixed 1M supply in the face of rising transaction volume carries risks that
should be analyzed and communicated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151216/117c35a7/attachment.html>

2023-06-07 17:46:19

- reply

📅 Original date posted:2015-12-16
📝 Original message:All,
Following the guiding WP principle of Assume Good Faith, I've been trying
to boil down the essence of the message following Scaling Bitcoin. There
are key bitcoin issues that remain outstanding and pressing, that are*
orthogonal to LN & SW*.
I create multiple proposals and try multiple angles because of a few,
notable systemic economic and analysis issues - multiple tries at solving
the same problems. Why do I do what I do -- Why not try to reboot... just
list those problems?
Definitions:
FE - "Fee Event", the condition where main chain MSG_BLOCK is 95+% to hard
limit for 7 or more days in row, "blocks generally full" This can also be
induced by a miner squeeze (collective soft limit reduction).
Service - a view of bitcoin as a decentralized, faceless, multi-celled,
amorphous automaton cloud, that provides services in exchange for payment
Users - total [current | future] set of economic actors that pay money to
the Service, and receive value (figuratively or literally) in return
Block Size - This is short hand for MAX_BLOCK_SIZE, the hard limit that
requires, today, a hard fork to increase (excl. extension blocks etc.)
Guiding Principle:
Keep the Service alive, secure, decentralized, and censorship resistant for
as many Users as possible.
Observations on block size (shorthand for MAX_BLOCK_SIZE as noted above):
This is economically modeled as a supply limited resource over time. On
average, 1M capacity is available every 10 minutes, with variance.
Observations on Users, block size and modern bidding process:
A supermajority of hashpower currently evaluates for block inclusion based,
first-pass, on tx-fee/KB. Good.
The Service is therefore responsive to the free market and some classes of
DoS. Good.
Recent mempool changes float relay fee, making the Service more responsive
to fast moving markets and DoS's. Good progress.
Service provided to Users can be modeled at the bandwidth resource level as
bidding for position in a virtual priority queue, where up-to-1M bursts are
cleared every 10 min (on avg etc.). Not a perfectly fixed supply,
definitionally, but constrained within a fixed range.
Observations on the state of today's fee market:
On average, blocks are not full. Economically, this means that fees trend
towards zero, due to theoretically unlimited supply at <1M levels.
Of course, fees are not zero. The network relay anti-flood limits serve as
an average lower limit for most transactions (excl direct-to-miner).
Wallet software also introduces fee variance in interesting ways. All this
fee activity is range-bound on the low end.
Let the current set of Users + transaction fee market behavior be TFM
(today's fee market).
Let the post-Fee-Event set of Users + transaction fee market behavior be
FFM (future fee market).
*Key observation: A Bitcoin Fee Event (see def. at top) is an Economic
Change Event.*
An Economic Change Event is a period of market chaos, where large changes
to prices and sets of economic actors occurs over a short time period.
A Fee Event is a notable Economic Change Event, where a realistic
projection forsees higher fee/KB on average, pricing some economic actors
(bitcoin projects and businesses) out of the system.
*It is a major change to how current Users experience and pay for the
Service*, state change from TFM to FFM.
The game theory bidding behavior is different for a mostly-empty resource
versus a usually-full resource. Prices are different. Profitable business
models are different. Users (the set of economic actors on the network)
are different.
Observation: Contentious hard fork is an Economic Change Event.
Similarly, a fork that partitions economic actors for an extended period or
permanently is also an Economic Change Event, shuffling prices and economic
actors as the Service dynamically readjusts on both sides of the partition,
and Users-A and Users-B populations change their behavior.
Short-Term Problem #1: No-action on block size increase leads to an
Economic Change Event.
Failure to increase block size is not obviously-conservative, it is a
conscious choice, electing for one economic state and set of actors and
prices over another. Choosing FFM over TFM.
*It is rational to reason that maintaining TFM is more conservative* than
enduring an Economic Change Event from TFM to FFM.
*It is rational to reason that maintaining similar prices and economic
actors is less disruptive.*
Failure to increase block size will lead to a Fee Event sooner rather than
later.
Failure to plan ahead for a Fee Event will lead to greater market chaos and
User pain.
Short-Term Problem #2: Some Developers wish to accelerate the Fee Event,
and a veto can accomplish that.
In the current developer dynamics, 1-2 key developers can and very likely
would veto any block size increase.
Thus a veto (e.g. no-action) can lead to a Fee Event, which leads to
pricing actors out of the system.
A block size veto wields outsize economic power, because it can accelerate
ECE.
*This is an extreme moral hazard: A few Bitcoin Core committers can veto
increase and thereby reshape bitcoin economics, price some businesses out
of the system. It is less of a moral hazard to keep the current economics
[by raising block size] and not exercise such power.*
Short-Term Problem #3: User communication and preparation
The current trajectory of no-block-size-increase can lead to short time
market chaos, actor chaos, businesses no longer viable.
In a $6.6B economy, it is criminal to let the Service undergo an ECE
without warning users loudly, months in advance: "Dear users, ECE has
accelerated potential due to developers preferring a transition from TFM to
FFM."
As stated, *it is a conscious choice to change bitcoin economics and User
experience* if block size is not advanced with a healthy buffer above
actual average traffic levels.
*Raising block size today, at TFM, produces a smaller fee market delta.*
Further, wallet software User experience is very, very poor in a
hyper-competitive fee market. (This can and will be improved; that's just
the state of things today)
Short-Term Problem #4: User/Dev disconnect: Large mass of users wishes
to push Fee Event into future
Almost all bitcoin businesses, exchanges and miners have stated they want a
block size increase. See the many media articles, BIP 101 letter, and wiki
e.g.
https://en.bitcoin.it/wiki/Block_size_limit_controversy#Entities_positions
The current apparent-veto on block size increase runs contra to the desires
of many Users. (note language: "many", not claiming "all")
*It is a valid and rational economic choice to subsidize the system with
lower fees in the beginning*. Many miners, for example, openly state they
prefer long term system growth over maximizing tiny amounts of current day
income.
Vetoing a block size increase has the effect of eliminating that economic
choice as an option.
It is difficult to measure Users; projecting beyond "businesses and miners"
is near impossible.
Without exaggeration, I have never seen this much disconnect between user
wishes and dev outcomes in 20+ years of open source.
Short-Term Problem #5: Higher Service prices can negatively impact system
security
Bitcoin depends on a virtuous cycle of users boosting and maintaining
bitcoin's network effect, incentivizing miners, increasing security.
Higher prices that reduce bitcoin's user count and network effect can have
the opposite impact.
(Obviously this is a dynamic system, users and miners react to higher
prices... including actions that then reduce the price)
Short-Term Problem #6: Post-Fee-Event market reboot problem + general lack
of planning
Game it out: Blocks are now full (FFM). Block size kept at 1M.
How full is too full - who and what dictates when 1M should be increased?
The same question remains, yet now economic governance issues are
compounded: In FFM, the fees are very tightly bound to the upper bound of
the block size. In TFM, fees are much less sensitive to the upper bound of
block size.
Changing block size, when blocks are full, has a more dramatic effect on
the market - suddenly new supply is magically brought online, and a minor
Economic Change Event occurs.
More generally, the post-Fee-Event next step has not been agreed upon. Is
it flexcap? This key "step #2" is just barely at whiteboard stage.
Short-Term Problem #7: Fee Event timing is unpredictable.
As block size free space gets tighter - that is the trend - and block size
remains at 1M, Users are ever more likely to hit an Economic Change Event.
It could happen in the next 2-6 months.
Today, Users and wallets are not prepared.
It is also understandably a very touchy subject to say "your business or
use case might get priced out of bitcoin"
But it is even worse to let worse let Users run into a Fee Event without
informing the market that the block size will remain at 1M.
Markets function best with maximum knowledge - when they are informed well
in advance of market shifting news and events, giving economic actors time
to prepare.
Short-Term Problem #8: Very little testing, data, effort put into
blocks-mostly-full economics
*We only know for certain that blocks-mostly-not-full works.* We do not
know that changing to blocks-mostly-full works.
Changing to a new economic system includes boatloads of risk.
Very little data has been forthcoming from any party on what FFM might look
like, following a Fee Event.
Observation: In the long run, it is assumed we need a "healthy fee market"
Yes, absolutely. In the long run, bitcoin was intended to be supported by
transaction fees and not the minting of new supply, and the design of the
system is to slowly wean Users off new supply and onto transaction fees for
supporting the Service.
While agreeing with the goal, it must be acknowledge that this is a vague
and untested goal with many open economic questions -- more of a hope,
really.
It is more conservative to preserve current economics than to change to a
new system with new economics and no notion of what-comes-next (flexcap?)
in terms of system security, healthy sustainable market levels, and impact
of changes during and following an ECE.
Core recommendations:
1) "Short term bump" Block size increase to maintain buffer. I've no
special BIP preference.
This avoids moral hazard and avoids a major Economic Change Event, as well
many other risks.
2) If block size stays at 1M, the Bitcoin Core developer team should sign a
collective note stating their desire to transition to a new economic
policy, that of "healthy fee market" and strongly urge users to examine
their fee policies, wallet software, transaction volumes and other possible
User impacting outcomes.
3) Even if can is kicked down the road, Fee Event will come eventually.
Direct research, testing and simulations into the economics and user impact
side of the equation. Research and experiment with pay-for-burst (pay to
future miner), flexcap and other solutions ASAP.
The worst possible outcome is letting the ecosystem randomly drift into the
first Fee Event without openly stating the new economic policy choices and
consequences.
The simple fact is *inaction* on this supply-limited resource, block size,
will change bitcoin to a new economic shape and with different economic
actors, selecting some and not others.
It is better to kick the can and gather crucial field data, because
next-step (FFM) is very much not fleshed out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151216/024095fb/attachment-0001.html>

2023-06-07 17:46:18

- reply

📅 Original date posted:2015-12-21
📝 Original message:On Sun, Dec 20, 2015 at 11:35 AM, Peter Todd <pete at petertodd.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
>
>
> On 20 December 2015 08:30:45 GMT-08:00, Chris Pacia <ctpacia at gmail.com>
> wrote:
> >On Dec 20, 2015 6:34 AM, "Jeff Garzik via bitcoin-dev" <
> >bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> >> 2) This reverses the useful minimization attribute of HD wallets -
> >"just
> >backup the seed"
> >
> >It would be nice if the bip37 filter matching algorithm was extended to
> >serve up the proof.
> >
> >And if server-based wallets did the same it would preserve the "just
> >backup
> >the seed" functionality.
>
> Exactly! The information will be out there - "just backup the seed"
> requires someone to have the exact same data needed to generate the
> TXO-unspent proof that my proposal requires to spend an old txout.
>
> tl;dr: jgarzik is incorrect; theres no difference at all from the status
> quo.
>
The data stored in the legacy case makes it possible to sign and send a
transaction without any connection to a network. The data stored in the
upgraded case, absent grandfathering, requires significant network sync at
a minimum.
The user experience and security parameters are different.
Thus, issue/recommendation #1.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151220/e8707e97/attachment.html>

2023-06-07 17:46:16

- reply

📅 Original date posted:2015-12-20
📝 Original message:On Sun, Dec 20, 2015 at 6:24 AM, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> What I proprosed is that a consensus-critical maximum UTXO age be part
> of the protocol; UTXO's younger than that age are expected to be cached.
> For UTXO's older than that age, they can be dropped from the cache,
> however to spend them you are required to provide the proof, and that
> proof counts as blockchain space to account for the fact that they do
> need to be broadcast on the network.
Yes, this is almost what -has- to happen in the long term.
Ideally we should start having wallets generate those proofs now, and then
introduce the max-age as a second step as a planned hard fork a couple
years down the line.
However,
1) There is also the open question of "grandfathered" UTXOs - for those
wallets generated in 2009, buried in a landfill and then dug out 10 years
ago
2) This reverses the useful minimization attribute of HD wallets - "just
backup the seed"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151220/849d17b4/attachment.html>

2023-06-07 17:46:03

- reply

📅 Original date posted:2015-12-10
📝 Original message:There is no need for a BIP draft. "Turing complete" is just a fancy,
executive-impressing term for "it can run any computer program", or put
even more simply, "it can loop"
Furthermore, the specification of such a language is trivial. It is the
economics of validation that is the complex piece. Proving whether or not
a program will halt as expected - The Halting Problem - is near impossible
for most complex programs. As a result, your proof is... running the
program. That produces enormous validation consequences and costs for
generic-execution scripts when applied to a decentralized network of
validation P2P nodes.
If you need that capability, it is just as easy to use a normal C/C++/etc.
computer language, with your preferred algorithm libraries and development
tools.
See https://github.com/jgarzik/moxiebox for a working example of provable
execution.
On Thu, Dec 10, 2015 at 9:35 AM, Luke Durback via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello Bitcoin-Dev,
>
> I hope this isn't out of line, but I joined the mailing list to try to
> start a discussion on adding opcodes to make Script Turing Pseudo-Complete
> as Wright suggested is possible.
>
> ---
>
> In line with Wright's suggestion, I propose adding a return stack
> alongside the, already existing, control stack.
>
> The principle opcodes (excluding conditional versions of call and
> return_from) needed are
>
> OP_DEFINITION_START FunctionName: The code that follows is the definition
> of a new function to be named TransactionSenderAddress.FunctionName. If
> this function name is already taken, the transaction is marked invalid.
> Within the transaction, the function can be called simply as FunctionName.
>
> OP_DEFINITION_END: This ends a function definition
>
> OP_FUNCTION_NAME FunctionName: Gives the current transaction the name
> FunctionName (this is necessary to build recursive functions)
>
> ---
>
> OP_CALL Namespace.FunctionName Value TransactionFee: This marks the
> transaction as valid. It also pushes the current execution location onto
> the return stack, debits the calling transaction by the TransactionFee and
> Value, and creates a new transaction specified by Namespace.FunctionName
> with both stacks continued from before (this may be dangerous, but I see no
> way around it) with the specified value.
>
> OP_RETURN_FROM_CALL_AND_CONTINUE: This pops the top value off the return
> stack and continues from the specified location with both stacks in tact.
>
> ---
>
> It would also be useful if a transaction can create another transaction
> arbitrarily, so to prepare for that, I additionally propose
>
> OP_NAMESPACE: Pushes the current namespace onto the control stack
>
> This, combined with the ability to make new transactions arbitrarily would
> allow a function to pay its creator.
>
>
>
> I understand that this isn't all that is needed, but I think it's a
> start. I hope this proposal has met you all well,
>
> Luke Durback
>
> _______________________________________________
> 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/20151210/1c482e7c/attachment.html>

2023-06-07 17:44:50

- reply

📅 Original date posted:2015-11-13
📝 Original message:On Fri, Nov 13, 2015 at 4:48 PM, xor via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> This clearly says that funds can be frozen.
> Can the BIP65-thing be used to freeze funds or can it not be?
>
This language definitely trips up or worries several folks - it's been
mentioned a few times before.
The user _chooses_ to freeze _their own_ funds. It is not an unwilling act
of force, which many assume when they see the phrase "freeze funds."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151113/2a23202a/attachment.html>

2023-06-07 17:44:23

- reply

📅 Original date posted:2015-11-10
📝 Original message:Comments:
1) cblock seems a reasonable way to extend the protocol. Further wrapping
should probably be done at the stream level.
2) zlib has crappy security track record.
3) A fallback path to non-compressed is required, should compression fail
or crash.
4) Most blocks and transactions have runs of zeroes and/or highly common
bit-patterns, which contributes to useful compression even at smaller
sizes. Peter Ts's most recent numbers bear this out. zlib has a
dictionary (32K?) which works well with repeated patterns such as those you
see with concatenated runs of transactions.
5) LZO should provide much better compression, at a cost of CPU performance
and using a less-reviewed, less-field-tested library.
On Tue, Nov 10, 2015 at 11:30 AM, Tier Nolan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> On Tue, Nov 10, 2015 at 4:11 PM, Peter Tschipper <
> peter.tschipper at gmail.com> wrote:
>
>> There are better ways of sending new blocks, that's certainly true but
>> for sending historical blocks and seding transactions I don't think so.
>> This PR is really designed to save bandwidth and not intended to be a huge
>> performance improvement in terms of time spent sending.
>>
>
> If the main point is for historical data, then sticking to just blocks is
> the best plan.
>
> Since small blocks don't compress well, you could define a "cblocks"
> message that handles multiple blocks (just concatenate the block messages
> as payload before compression).
>
> The sending peer could combine blocks so that each cblock is compressing
> at least 10kB of block data (or whatever is optimal). It is probably worth
> specifying a maximum size for network buffer reasons (either 1MB or 1 block
> maximum).
>
> Similarly, transactions could be combined together and compressed "ctxs".
> The inv messages could be modified so that you can request groups of 10-20
> transactions. That would depend on how much of an improvement compressed
> transactions would represent.
>
> More generally, you could define a message which is a compressed message
> holder. That is probably to complex to be worth the effort though.
>
>
>
>>
>> On Tue, Nov 10, 2015 at 5:40 AM, Johnathan Corgan via bitcoin-dev <
>> <bitcoin-dev at lists.linuxfoundation.org>
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> On Mon, Nov 9, 2015 at 5:58 PM, gladoscc via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>
>>>> I think 25% bandwidth savings is certainly considerable, especially for
>>>> people running full nodes in countries like Australia where internet
>>>> bandwidth is lower and there are data caps.
>>>>
>>>
>>> This reinforces the idea that such trade-off decisions should be be
>>> local and negotiated between peers, not a required feature of the network
>>> P2P.
>>>
>>>
>>> --
>>> Johnathan Corgan
>>> Corgan Labs - SDR Training and Development Services
>>> http://corganlabs.com
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing listbitcoin-dev at lists.linuxfoundation.orghttps://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/20151110/d0474410/attachment.html>

2023-06-07 17:43:53

- reply

📅 Original date posted:2015-10-28
📝 Original message:On Wed, Oct 28, 2015 at 4:28 PM, Sean Lynch <seanl at literati.org> wrote:
> On Fri, Oct 23, 2015 at 1:23 AM Lucas Betschart via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Facebook has a LevelDB fork which is maintained.
>> It's called RocksDB and the API seems to be nearly the same as for
>> LevelDB, thus maybe easy to replace: http://rocksdb.org/
>> https://github.com/facebook/rocksdb
>>
>> Although I don't know if we might have some negative effects for our
>> use-case since RocksDB was optimized for big databases running on multiple
>> cores.
>>
>
> While RocksDB is pretty decent, note that it's optimized for flash. Not
> sure how well it will work on spinning disks.
>
That's OK for our purposes. We have a huge database which already
incentivized having zero seek time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151028/4d05bbae/attachment.html>

2023-06-07 17:43:51

- reply

📅 Original date posted:2015-10-22
📝 Original message:Here is the beginnings of an implementation to replace leveldb with sqlite:
https://github.com/jgarzik/bitcoin/tree/2015_sqlite
It builds, but still needs work before passing tests.
It was noted that leveldb is unmaintained, and this is part of researching
alternatives that are maintained and reliable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151022/751780a6/attachment.html>

2023-06-07 17:43:34

- reply

📅 Original date posted:2015-10-14
📝 Original message:Introduction
-------------------
This mailing list, bitcoin-dev, aim to facilitate constructive discussion
of issues related to technical development of the bitcoin protocol and the
Bitcoin Core reference implementation. We can achieve this, in part, by
behaving well towards each other, so that the broadest diversity of
participants - both amateur and professional, new and experienced - feel
that the lists are welcoming and useful.
This proposed policy helps maintain that environment by capturing the
conduct we aspire to when we participate in discussions on bitcoin-dev.
We Strive To:
-------------
*Be friendly and patient*
1. Many of us are volunteers, and so a sense of fun is part of why we do
what we do. Be positive and engaging, rather than snarky.
2. If someone asks for help it is because they need it. Politely suggest
specific documentation or more appropriate venues where appropriate. Avoid
aggressive or vague responses.
*Be civil and considerate*
1. Disagreement is no excuse for poor conduct or personal attacks. A
community where people feel uncomfortable is not a productive one.
2. If you would not feel comfortable saying something to a co-worker or
acquaintance, it is probably not appropriate on this list either.
*Assume good faith*
1. Remember that protocol & engineering questions are often very complex
and difficult to assess. If you disagree, please do so politely, by
disputing logical errors and factual premises rather than by attacking
individuals.
2. If something seems outrageous, check that you did not misinterpret it.
Ask for clarification, rather than assuming the worst.
3. For more, read https://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith
*Respect time and attention*
1. List members are often busy people. As a result, we value concision and
clarity. Emails that are brief and to the point take more time to write,
but are repaid many times over when other members of the list make the same
effort.
2. Conversations should remain focused and on-topic. If you must change the
topic, start a new thread by changing the topic line of your emails. Also,
avoid flooding the list with long threads by reading the entire thread
first, instead of responding quickly to many emails in a short period of
time.
3. New members are welcome, but should be careful to respect the time and
energy of long-time list members by doing research in FAQs and with search
engines before asking questions.
4. Off-topic threads will be directed to other venues.
*Disclose potential conflicts*
1. List discussions often involve interested parties. We expect
participants to be aware when they are conflicted due to employment or
other projects they are involved in, and disclose those interests to other
project members.
2. When in doubt, over-disclose. Perceived conflicts of interest are
important to address, so that the lists’ decisions are credible even when
unpopular, difficult or favorable to the interests of one group over
another.
Interpretation
--------------
This policy is not exhaustive or complete. It is not a rulebook; it serves
to distill our common understanding of a collaborative, shared environment
and goals. We expect it to be followed in spirit as much as in the letter.
Enforcement
-----------
Most members of the bitcoin-dev community already comply with this policy,
not because of the existence of the policy, but because they have long
experience participating in open source communities where the conduct
described above is normal and expected. However, failure to observe the
code may be grounds for reprimand, probation, or removal from the lists.
If you have concerns about someone’s conduct:
* *Direct contact*: it is always appropriate to email a list member,
mention that you think their behavior was out of line, and (if necessary)
point them to this document.
* *On-list*: discussing conduct on-list, either as part of another message
or as a standalone thread, is always acceptable. Note, though, that
approaching the person directly can be better, as it tends to make them
less defensive, and it respects the time of other list members, so you
probably want to try direct contact first.
* *Moderators*: You can reach the list moderators through the addresses
they use for on-list communication.
Moderators
----------
The selection of moderators is intended to be a mix from various projects
and roles, and expressly intended to avoid cases where the set of
(moderators) equals the set of (bitcoin core committers) or similar.
TBD
Jeff Garzik
[btcdrak? Johnathan? Others were listed in the IRC meeting, but the
bitcoinstats site is down right here]
Further Context
---------------
Other resources, while not formally part of this code of conduct, can
provide useful context and guidance for good behavior.
1. Chapter 6 of Producing OSS, by OSI board member Karl Fogel, describes
common best practices for mailing list participation,
particularly [“You Are What You Write”](
http://producingoss.com/en/communications.html#you-are-what-you-write) and
[“Avoiding Common
Pitfalls"](http://producingoss.com/en/common-pitfalls.html).
2. [RFC 1855](https://www.ietf.org/rfc/rfc1855.txt), particularly section
2.1.1 (“User Guidelines for mail”), also provides useful
guidelines for sending good emails.
3. [The Ubuntu Code of Conduct](
http://www.ubuntu.com/project/about-ubuntu/conduct) provides useful
guidance for group leaders.
This policy was inspired by [the GNOME Code of Conduct](
https://live.gnome.org/CodeOfConduct/), [the Mozilla Community Participation
Guidelines](https://www.mozilla.org/about/policies/participation.html),
[the Ubuntu Code of Conduct](
http://www.ubuntu.com/project/about-ubuntu/conduct), and other codes listed
at [the OpenHatch list of project codes of conduct](
https://openhatch.org/wiki/Project_codes_of_conduct).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151014/585c3ab5/attachment.html>

2023-06-07 17:42:10

- reply

📅 Original date posted:2015-10-01
📝 Original message:To reduce the list noise level, drama level and promote inclusion, my own
personal preference (list admin hat: off, community member hat: on) is for
temporal bans based on temporal circumstances. Default to
pro-forgiveness. Also, focus on disruption of the list as a metric, rather
than focusing on a specific personality.
I do think we're at a bit of a point where we're going around in circles.
Given the current reddit hubbub, a bit of a cooling off period is IMO
advisable before taking any further action.
On Thu, Oct 1, 2015 at 12:08 AM, Tao Effect via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Dear list,
>
> Mike has made a variety of false and damaging statements about Bitcoin, of
> which this is but one:
>
> On Sep 30, 2015, at 2:01 PM, Mike Hearn via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I coined the term SPV so I know exactly what it means, and bitcoinj
> implements it, as does BreadWallet (the other big SPV implementation).
>
>
> On his website Vinumeris.com he writes:
>
> Vinumeris was founded in 2014 by Mike Hearn, one of the developers of the
> Bitcoin digital currency system.
>
>
> On plan99.net there are several embedded videos that refer to him a “core
> developer” of Bitcoin. And now it seems he is claiming to be Satoshi.
>
> It seems to me that Mike’s emails, false statements (like the one above
> about coining SPV), arguments, and his attempts to steal control of Bitcoin
> via the contentious Bitcoin XT fork, represent actions that have been
> harming and dividing this community for several years now.
>
> In many communities/tribes, there exists a line that, once crossed,
> results in the expulsion of a member from the community.
>
> So, two questions:
>
> 1. Does the Bitcoin-devs mailing list have such a line?
> 2. If so, does the community feel that Mike Hearn has crossed it? (I
> personally feel he has. Multiple times.)
>
> Thanks for your thoughts,
> Greg Slepak
>
> --
> Please do not email me anything that you are not comfortable also sharing with
> the NSA.
>
>
> _______________________________________________
> 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/20151001/837d4131/attachment.html>

2023-06-07 17:41:58

- reply

📅 Original date posted:2015-10-05
📝 Original message:- It is true that hard forks produce a much cleaner outcome, in terms of
well defined behavior across the entire network.
- Replacing an opcode should not result in undefined behavior. The
non-upgraded behavior is defined and deterministic.
- IsStandard remains an assistant. Miners may mine non-standard
transactions.
- "Hard forks require everyone to upgrade and soft forks don't" Doesn't
require tons of explanation: Non upgraded clients continue working on the
network even after the rules are upgraded.
All those corrections aside, I do think there has been too much hysteria
surrounding hard forks. Hard forks, when done right, produce a much
cleaner system for users.
On Mon, Oct 5, 2015 at 6:59 AM, Mike Hearn via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Putting aside stupid arguments about who is older or who starting using
> the term SPV wallet first, let me try and make a better suggestion than
> what's in the BIP. How about the following:
>
> A new flag is introduced to Core, --scriptchecks=[all,standardonly,none].
> The default is all. When set to "standardonly", non-standard scripts are
> not checked but others are. This is similar to the behaviour during a soft
> fork. In "none" you have something a bit like SPV mode, but still
> calculating the UTXO set. This flag is simple and can be implemented in a
> few lines of code. Then an unused opcode is used for CLTV, so making it a
> hard fork.
>
> This has the following advantages:
>
> - Nodes that want the pseudo-SPV behaviour of a soft fork can opt in
> to it if they want it. This prioritises availability (in a sense) over
> correctness.
>
> - But otherwise, nodes will prioritise correctness by default, which
> is how it should be. This isn't PHP where nonsensical code the interpreter
> doesn't understand just does ...... something. This is financial software
> where money is at risk. I feel very strongly about this: undefined
> behaviour is fine *if you opted into getting it. *Otherwise it should
> be avoided whenever possible.
>
> - SPV wallets do the right thing by default.
>
> - IsStandard doesn't silently become a part of the consensus rules.
>
> - All other software gets simpler. It's not just SPV wallets. Block
> explorers, for example, can just add a single line to their opcode map.
> With a soft fork they have to implement the entire soft fork logic just to
> figure out when an opcode transitioned from OP_NOP to CLTV and make sure
> they render old scripts differently to new scripts. And they face tricky
> questions - do they render an opcode as a NOP if the miner who built it was
> un-upgraded, or do they calculate the flag day and change all of them after
> that? It's just an explosion of complexity.
>
> Many people by now have accepted that hard forks are simpler, conceptually
> cleaner, and prioritise correctness of results over availability of
> results. I think these arguments are strong.
>
> So let me try addressing the counter-arguments one more time:
>
> - Hard forks require everyone to upgrade and soft forks don't. I still
> feel this one has never actually been explained. There is no difference to
> the level of support required to trigger the change. With the suggestion
> above, if someone can't or won't upgrade their full node but can no longer
> verify the change, they can simply restart with -scriptchecks=standardonly
> and get the soft fork behaviour. Or they can upgrade and get their old
> security level back.
>
> - Hard forks are somehow bad or immoral or can lead to "schisms". This
> is just saying, if we hold a vote, the people who lose the vote might try
> starting a civil war and refuse to accept the change. That's not a reason
> to not hold votes.
>
> But at any rate, they can do that with soft forks too: just decide
> that any output that contains OP_CLTV doesn't make it into the UTXO set.
> Eventually coins that trace back to such an output will become unusable in
> the section of the economy that decided to pick a fight.
>
>
>
> _______________________________________________
> 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/6fe4130c/attachment.html>

2023-06-07 17:41:50

- reply

📅 Original date posted:2015-09-29
📝 Original message:This was discussed in IRC, but (did I miss it?) never made it to the list
outside of being buried in a longer summary.
There is a common complain that bitcoin-dev is too noisy. The response
plan is to narrow the focus of the list to near term technical changes to
the bitcoin protocol and its implementations (bitcoin core, btcd, ...)
Debates over bitcoin philosophy, broader context, etc. will start seeing
grumpy list admins squawk about "off-topic!"
It is a fair criticism, though, that "take it elsewhere!" needs to have
some place as a suggested destination. The proposal is to create a second
list, bitcoin-tech-discuss or perhaps just 'bitcoin', with a more general
rubric. This split has served IRC well and generally manages to keep the
noise down to a productive level. We want this list to achieve that same
goal; if bitcoin-dev is not productive then it's not useful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150929/d62cd28f/attachment.html>

2023-06-07 17:41:40

- reply

📅 Original date posted:2015-09-30
📝 Original message:On Wed, Sep 30, 2015 at 3:56 PM, Mike Hearn <hearn at vinumeris.com> wrote:
> Field experience shows it successfully delivers new features to end users
>> without a global software upgrade.
>>
>
> The global upgrade is required for all full nodes in both types. If a full
> node doesn't upgrade then it no longer does what it was designed to do; if
> the user is OK with that, they should just run an SPV wallet or use
> blockchain.info or some other mechanism that consumes way fewer resources.
>
> But if you want the software you installed to achieve its stated goal, you
> *must* upgrade. There is no way around that.
>
It is correct that security is slightly reduced for full nodes that have
not upgraded. It is not correct that the choice is binary, full node or
SPV.
Any user running a not-upgraded full node still retains protection against
many attacks outside the subset related to the feature being introduced.
The field observable end result is that we do receive new features, secured
by hashpower and user full nodes, via soft fork, without a global flag day
upgrade.
Yes, a flag day hard fork upgrade is cleaner and results in higher security
due to the entire network validating the new rules. However, the
difficulty of executing hard forks would mean fewer total features to
users, if that route were chosen instead.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150930/79a7b5d7/attachment.html>

2023-06-07 17:41:39

- reply

📅 Original date posted:2015-09-30
📝 Original message:On Wed, Sep 30, 2015 at 1:11 PM, Mike Hearn via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Several people have asked several times now: given the very real and
> widely acknowledged downsides that come with a soft fork, *what* is the
> specific benefit to end users of doing them?
>
Field experience shows it successfully delivers new features to end users
without a global software upgrade.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150930/c7ce1b05/attachment.html>

2023-06-07 17:41:24

- reply

📅 Original date posted:2015-09-29
📝 Original message:On Tue, Sep 29, 2015 at 8:07 PM, Milly Bitcoin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> What happened years ago is not really relevant as Bitcoin has changed and
>> the stakeholders have expanded. What is relevant is the actual
>> description. Whatever you want to discuss it should be clearly described
>> when people sign up.
>>
>
This email's quote excised the "short time ago" bit, which is the other 1/2
of the context.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150929/78c833e5/attachment.html>

2023-06-07 17:41:23

- reply

📅 Original date posted:2015-09-29
📝 Original message:On Tue, Sep 29, 2015 at 7:16 PM, Milly Bitcoin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On 9/29/2015 7:02 PM, Jonathan Toomim (Toomim Bros) wrote:
>
>> Making statements about a developer's personal character is also
>> off-topic for this list.
>>
>
> If that were true then probably 20-30% of the posting here would be
> off-topic. lol.
Yes - that is the reason why a discussion list is being created, as an
outlet for off-topic discussions. The consensus of the developers that
created this bitcoin-dev list a short time ago is of being turned off due
to the off-topic noise, impacting productivity.
Since 2011 and bitcoin-development, the list was always intended to focus
on the highly technical bits of the core software, and avoid wandering into
never-ending philosophical discussions. Example:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2011-June/thread.html
>
>
> Russ
>
>
> _______________________________________________
> 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/20150929/fcf5c011/attachment.html>

2023-06-07 17:41:22

- reply

📅 Original date posted:2015-09-29
📝 Original message:This is off-topic for this list.
On Sun, Sep 27, 2015 at 1:53 PM, Neil Haran via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi,
>
> I have an idea for a gamified bitcoin mining app that I'd like to partner
> with someone on that is very good with cryptography and knows the bitcoin
> code base well. I have received interest in this from some, but I'm looking
> for the ideal candidate to work with. If this is of interest, please email
> me at nharan81 at gmail.com.
>
> Thanks,
> Neil
>
> _______________________________________________
> 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/20150929/e2679f89/attachment.html>

2023-06-07 17:41:16

- reply

📅 Original date posted:2015-09-29
📝 Original message:ACK
On Thu, Sep 24, 2015 at 7:25 AM, Wladimir J. van der Laan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello all,
>
> The next major release of Bitcoin Core, 0.12.0 is planned for the end of
> the year. Let's propose a more detailed schedule:
>
> 2015-11-01
> -----------
> - Open Transifex translations for 0.12
> - Soft translation string freeze (no large or unnecessary changes)
> - Finalize and close translation for 0.10
>
> 2015-12-01
> -----------
> - Feature freeze
> - Translation string freeze
>
> In December at least I will probably not get much done code-wise (Scaling
> Bitcoin Hongkong, 32C3, end of year festivities, etc), and I'm sure I'm not
> the only one, so let's leave that for last pre-RC bugfixes and polishing.
>
> 2016-01-06
> -----------
> - Split off `0.12` branch from `master`
> - Start RC cycle, tag and release `0.12.0rc1`
> - Start merging for 0.13 on master branch
>
> 2016-02-01
> -----------
> - Release 0.12.0 final (aim)
>
> 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/20150929/8eba3a72/attachment-0001.html>

2023-06-07 17:40:26

- reply

📅 Original date posted:2015-09-16
📝 Original message:During Scaling Bitcoin, Bitcoin Core committers and notable contributors
got together and chatted about where a "greatest common denominator" type
consensus might be. The following is a without-attribution (Chatham House)
summary. This is my own personal summary of the chat; any errors are my
own; this is _not_ a consensus statement or anything formal.
- Background (pre-conference, was on public IRC): "net-utxo", calculating
transaction size within block by applying a delta to transaction size based
on the amount of data added, or removed, from the UTXO set. Fee is then
evaluated after the delta is applied. This aligns user incentives with
UTXO resource usage/cost. Original idea by gmaxwell (and others??).
- Many interested or at least willing to accept a "short term bump", a hard
fork to modify block size limit regime to be cost-based via "net-utxo"
rather than a simple static hard limit. 2-4-8 and 17%/year were debated
and seemed "in range" with what might work as a short term bump - net after
applying the new cost metric.
- Hard fork method: Leaning towards "if (timestamp > X)" flag day hard
fork Y months in the future. Set high bit in version, resulting in a
negative number, to more cleanly fork away. "miner advisement" - miners,
as they've done recently, signal non-binding (Bitcoin Core does not examine
the value) engineering readiness for a hard fork via coinbase moniker.
Some fork cancellation method is useful, if unsuccessful after Z time
elapses.
- As discussed publicly elsewhere, other forks may be signaled via setting
a bit in version, and then triggering a fork'ing change once a threshold is
reached.
Chat participants are invited to reply to this message with their own
corrections and comments and summary in their view.
For the wider community, take this as one of many "inputs" described at
Scaling Bitcoin. Over the next few months developers and the community
should evaluate everything discussed and work towards some concrete
proposal(s) that are implemented, tested and simulated in December in Hong
Kong.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150916/b53805a1/attachment.html>

2023-06-07 17:40:22

- reply

📅 Original date posted:2015-09-29
📝 Original message:There seemed to be some agreement on IRC - after a bit of haranguing by
myself :) -- that large refactors should (a) occur over a small window of
time and (b) have a written plan beforehand.
On Tue, Sep 22, 2015 at 7:49 PM, Dave Scotese <dscotese at litmocracy.com>
wrote:
> If I'm reading this situation correctly, Jeff is basically pointing out
> that developers need more links (hooks, rungs, handholds, data points,
> whatever you want to call them) so that they can see all the things his
> email insinuated are missing (a plan, order, sense, etc.). He didn't say
> these things were missing, but that it kind of feels like it from the
> 10,000 foot view.
>
> If you use Google to search the list, as in <<site:
> lists.linuxfoundation.org libconsensus plan>> you DO NOT get the page
> Jorge gave. He wrote that page, so he had a good idea what to search for
> to find it again. I just want to recommend that when you describe the work
> you're doing on bitcoin, imagine several different ways people might try to
> find this description in the future and make them work. In other words,
> Jorge could have put "A plan for abstracting out libconsensus" in the email
> where he wrote "Here are some things that need to happen first..."
>
> Likewise, if Jeff had searched for <<site:lists.linuxfoundation.org
> libconsensus plan>> (maybe he did, but he didn't list any results), he may
> have found enough clues to see Jorge's overall plan. The "site:" keyword
> on Google fascinated me when I discovered it, so I let it inspire this
> email :-)
>
> Maybe someone can explain this if I have it wrong: A few people are able
> to pull code into Bitcoin/bitcoin. Isn't is possible that those few people
> can agree to merge in a lot of refactor-hell PRs for those making the
> requests, but postpone them to that one-week-per-month that someone
> suggested? The idea of letting that "hell" come in (predictable) waves is
> excellent and I was hoping to see some agreement. But I don't know who
> those few are, so even if they all wrote "Yeah, we'll do that," I wouldn't
> recognize that I got what I wanted.
>
> notplato
>
> On Tue, Sep 22, 2015 at 11:12 AM, Jorge Timón <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Tue, Sep 15, 2015 at 6:10 AM, Jeff Garzik via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > [collating a private mail and a github issue comment, moving it to a
>> > better forum]
>> >
>> > On libconsensus
>> > ---------------
>> > In general there exists the reasonable goal to move consensus state
>> > and code to a specific, separate lib.
>> >
>> > To someone not closely reviewing the seemingly endless stream of
>> > libconsensus refactoring PRs, the 10,000 foot view is that there is a
>> > rather random stream of refactors that proceed in fits and starts
>> > without apparent plan or end other than a one sentence "isolate
>> > consensus state and code" summary.
>> >
>> > I am hoping that
>> > * There is some plan
>> > * We will not see a five year stream of random consensus code movement
>> > patches causing lots of downstream developer headaches.
>> >
>> > I read every code change in every pull request that comes into
>> > github/bitcoin/bitcoin with three exceptions:
>> > * consensus code movement changes - too big, too chaotic, too
>> > frequent, too unfocused, laziness guarantees others will inevitably
>> > ACK it without me.
>> > * some non-code changes (docs)
>> > * ignore 80% of the Qt changes
>> >
>> > As with any sort of refactoring, they are easy to prove correct, easy
>> > to reason, and therefore quick and easy to ACK and merge.
>> >
>> > Refactors however have a very real negative impact.
>> > bitcoin/bitcoin.git is not only the source tree in the universe.
>> > Software engineers at home, at startups, and at major companies are
>> > maintaining branches of their own.
>> >
>> > It is very very easy to fall into a trap where a project is merging
>> > lots of cosmetic changes and not seeing the downstream ripple effects.
>> > Several people complained to me at the conference about all the code
>> > movement changes breaking their own work, causing them to stay on
>> > older versions of bitcoin due to the effort required to rebase to each
>> > new release version - and I share those complaints.
>> >
>> > Complex code changes with longer development cycles than simple code
>> > movement patches keep breaking. It is very frustrating, and causes
>> > folks to get trapped between a rock and a hard place:
>> > - Trying to push non-trivial changes upstream is difficult, for normal
>> > and reasonable reasons (big important changes need review etc.).
>> > - Maintaining non-trivial changes out of tree is also painful, for the
>> > aforementioned reasons.
>> >
>> > Reasonable work languishes in constant-rebase hell, and incentivizes
>> > against keeping up with the latest tree.
>> >
>> >
>> > Aside from the refactor, libconsensus appears to be engineering in the
>> > dark. Where is any sort of plan? I have low standards - a photo of a
>> > whiteboard or youtube clip will do.
>>
>> Just because you don't understand the changes proposed it doesn't mean
>> that they are random.
>> I may have done a poor job in communicating "my plan for libconsensus"
>> but I have tried many times and in many ways.
>> #bitcoin-dev logs show that I have not worked "in the dark" at all, on
>> the contrary, I've been very tenacious when asking for review and
>> opinions, to the point that several people (at least @laanwj and
>> @theuni have complained about their github inboxes being full of
>> "spam").
>> This is a relatively recent thread where I describe my plan:
>>
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009568.html
>> Not my first attempt on this list.
>>
>> It is very frustrating that everybody seems to agree that separating
>> libconsensus is a priority to maximize the number of people that can
>> safely contribute to the project, but at the same time, nobody thinks
>> that reviewing the necessary refactors to do so is a priority.
>> I tried creating big PRs for people to see "the big picture" #5946 but
>> those were too many commits and nobody wanted to read it. Gavin asked
>> for an API.
>> So I tried a smaller step: exposing just VerifyHeader in libconsensus
>> and leave VerifyTx and VerifyBlock for later #5995
>> Again, this was "too big" and "a moving target". In the meantime I
>> always had smaller one-little-step PRs that were part of a longer
>> branch:
>>
>> ** [8/8] MERGED Consensus
>> - [X] Consensus: Decouple pow from chainparams #5812 [consensuspow]
>> - [X] MOVEONLY: Move constants and globals to consensus.h #5696
>> [consensus_policy0]
>> - [X] Chainparams: Refactor: Decouple IsSuperMajority from Params()
>> #5968 [params_consensus]
>> - [X] Remove redundant getter CChainParams::SubsidyHalvingInterval()
>> #5996 [params_subsidy]
>> - [X] Separate CValidationState from main #5669 [consensus]
>> - [X] Consensus: Decouple ContextualCheckBlockHeader from checkpoints
>> #5975 [consensus_checkpoints]
>> - [X] Separate Consensus::CheckTxInputs and GetSpendHeight in
>> CheckInputs #6061 [consensus_inputs]
>> - [X] Bugfix: Don't check the genesis block header before accepting it
>> #6299 [5975-quick-fix]
>> ** [5/5] DELETED
>> *** DELETED Refactor: Create CCoinsViewEfficient interface for
>> CCoinsViewCache #5747 [coins]
>> *** DELETED Chainparams: Explicit Consensus::Params arg in consensus
>> functions #6024 [params_consensus2]
>> *** DELETED MOVEONLY: Move most of consensus functions (pre-block)
>> #6051 [consensus_moveonly] (depends on consensus-blocksize-0.12.99)
>> *** DELETED Consensus: Refactor: Separate CheckFinalTx from
>> main::IsFinalTx #6063 [consensus_finaltx]
>> *** DELETED Consensus: Refactor: Turn CBlockIndex::GetMedianTimePast
>> into independent function #6009 [consensus_mediantime]
>> *** DELETED Consensus: Adapt declarations of most obviously consensus
>> functions #6591 [consensus-params-0.12.99]
>> *** DELETED Consensus: Move blocksize and related parameters to
>> consensusparams ...without removing consensus/consensus.h [#6526
>> alternative] #6625 [consensus-blocksize-0.12.99]
>>
>> After a while I stop rebasing the longer branches and just maintained
>> a few small consensus-related PRs at a time.
>>
>> Now I consolidated 3 of them in
>>
>> *** REVIEW Optimizations: Consensus: In AcceptToMemoryPool,
>> ConnectBlock, and CreateNewBlock #6445 [consensus-txinputs-0.12.99]
>>
>> with the hope that it would be merged relatively fast.
>> After that it will be much simpler to start talking about potential C
>> APIs for VerifyHeader, VerifyTx and VerifyBlock; as well as separating
>> the library to a subtree.
>>
>> I'm more than happy to answer any questions anyone may have about any
>> of the PRs or commits, until everybody interested is convinced that
>> there's nothing random in the proposed changes.
>> I'm also more than happy to get advice on how to better communicate my
>> plans and structure my PRs.
>> _______________________________________________
>> 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 <http://www.litmocracy.com> and Meme Racing
> <http://www.memeracing.net> (in alpha).
> I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>
> which now accepts Bitcoin.
> I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
> "He ought to find it more profitable to play by the rules" - Satoshi
> Nakamoto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150929/5ac4034a/attachment-0001.html>

2023-06-07 17:40:16

- reply

📅 Original date posted:2015-09-15
📝 Original message:Drak,
I would say that the refactoring does actually fulfill some conditions you
mention:
- move-only is almost always clearly separated out
- the refactoring is not controversial _in minimis_ - meaning, the
individual pull request is not controversial.
The problem comes with the impact of an unfocused stream of refactors to
key code.
For example, there is much less long term developer impact if refactoring
were _accelerated_, scheduled to be performed in a one-week sprint. There
is a lot of breakage, yes, but after that week the average level of
downstream patch breakage is significantly lower. A "rip the band-aid off
quickly rather than slowly" approach.
On Tue, Sep 15, 2015 at 5:55 AM, Btc Drak <btcdrak at gmail.com> wrote:
> I also share a lot of Jeff's concerns about refactoring and have voiced
> them several times on IRC and in private to Jorge, Wladamir and Greg. I
> meant to do a write up but never got around to it. Jeff has quite
> eloquently stated the various problems. I would like to share my thoughts
> on the matter because we really do need to come up with a plan on how this
> issue is dealt with.
>
> Obviously, Bitcoin Core is quite tightly coupled at the moment and
> definitely needs extensive modularisation. Such work will inevitably
> require lots of bulk code moves and then finer refactoring. However, it
> requires proper planning because there are lots of effects and consequences
> for other people contributing to Core and also downstream projects relying
> on Core:
>
> 1. Refactoring often causes other pull requests to diverge and require
> rebasing. Continual refactoring can put PRs in "rebase hell" and puts a big
> stress on contributors (many of whom are part time).
>
> 2. Version to version, Bitcoin Core changes significantly in structure.
> 0.9 to 0.10 is unrecognisable. 0.10 to 0.11 is even more so. This makes
> makes it hard to follow release to release and the net result is less
> people upgrade (especially think of miners trying to keep their patch sets
> working while trying not to disrupt or risk their mining operations).
>
> 3. Continual refactoring increases risk: we're human, and mistakes will
> slip through peer review. This is especially concerning with consensus
> critical code and this makes it difficult to merge such refactoring often,
> which of course exacerbates the problem.
>
> The net negative consequence is it is harder to contribute to Core, harder
> for the Core maintainers to merge and harder for downstream/dependent
> projects/implementations to keep up.
>
> Suggested Way Forward
> ---------------------------------
>
> With the understanding that refactored code by definition must not change
> behaviour. There are three major kinds of refactoring:
>
> 1. code moves (e.g. separating concerns into different files);
> 2. code style;
> 3. structural optimisation and consolidation (reducing LOC, separating
> concerns, encapsulation etc).
>
> Code moves(1) and CS(2) are easy to peer review and merge quickly. The
> third kind(3) requires deeper analysis to ensure that while the code
> changed, the behaviour (including any bugs) did not.
>
> We must resist all temptation to fix bugs or tack on minor fixes and
> tweaks during refactoring: pull requests should only be refactoring only,
> with no net change to behaviour. Keeping discipline makes it much easier to
> verify and peer review and this faster to merge.
>
> With respect to Code moves and CS, I believe we should have a "refactoring
> fortnight" where we so the bulk of code move-only refactoring plus CS where
> necessary. This is by fat the most disruptive kind of change because it
> widely affects other PRs mergeability. We should aim to get most of this
> done in one go, so that it's not happening in dribs and drabs over months
> and many releases. Once done, it gives everyone a good idea to the overall
> new structure and where one can expect to find things in the future. The
> idea here is to help orientation and not have to continuously hunt for
> where things have moved to.
>
> To be clear, I am strongly suggesting code move-only refactoring PRs not
> be mixed with anything else. Same for CS changes. This makes the PRs
> extremely easy to vet and thus quick to merge.
>
> Towards this end, maybe there should be an IRC meeting to agree the
> initial moves, then someone who has the stomach for it can get on and do it
> - during that time, we do not merge anything else. We need to bite the
> bullet and break the back out of code moves.
>
> With regards to CS, I think we do need to get CS right, because a
> continual dribble of CS changes also makes diffs between releases less easy
> to follow. Much of CS checking can be automated by the continuous
> integration so authors can get it right easily. It can be just like a
> Travis check.
>
> With respect to the 3rd kind of refactoring, we need to set some standards
> and goals and aim for some kind of consistency. Refactoring needs to fulfil
> certain goals and criterion otherwise contributors will always find a
> reason to fiddle over and over forever. Obvious targets here can be things
> like proper encapsulation and separation of concerns.
>
> Overall, refactoring should be merged quickly, but only on a schedule so
> it doesn't cause major disruption to others.
>
> Obviously the third kind of refactoring more complex and time consuming
> and will need to occur over time, but it should happen in defined steps. As
> Jeff said, one week a month, or maybe one month a release. In any case,
> refactoring changes should be quickly accepted or rejected by the project
> maintainer and not left hanging.
>
> Finally, refactoring should *always* be uncontroversial because
> essentially functionality is not changing. If functionality changes (e.g.
> you try to sneak in a big fix or feature tweak "because it's small") the PR
> should be rejected outright. Additionally, if we break down refactoring
> into the three kinds stated above, peer review will be much more
> straightforward.
>
>
>
> On Tue, Sep 15, 2015 at 5:10 AM, Jeff Garzik via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> [collating a private mail and a github issue comment, moving it to a
>> better forum]
>>
>> On libconsensus
>> ---------------
>> In general there exists the reasonable goal to move consensus state
>> and code to a specific, separate lib.
>>
>> To someone not closely reviewing the seemingly endless stream of
>> libconsensus refactoring PRs, the 10,000 foot view is that there is a
>> rather random stream of refactors that proceed in fits and starts
>> without apparent plan or end other than a one sentence "isolate
>> consensus state and code" summary.
>>
>> I am hoping that
>> * There is some plan
>> * We will not see a five year stream of random consensus code movement
>> patches causing lots of downstream developer headaches.
>>
>> I read every code change in every pull request that comes into
>> github/bitcoin/bitcoin with three exceptions:
>> * consensus code movement changes - too big, too chaotic, too
>> frequent, too unfocused, laziness guarantees others will inevitably
>> ACK it without me.
>> * some non-code changes (docs)
>> * ignore 80% of the Qt changes
>>
>> As with any sort of refactoring, they are easy to prove correct, easy
>> to reason, and therefore quick and easy to ACK and merge.
>>
>> Refactors however have a very real negative impact.
>> bitcoin/bitcoin.git is not only the source tree in the universe.
>> Software engineers at home, at startups, and at major companies are
>> maintaining branches of their own.
>>
>> It is very very easy to fall into a trap where a project is merging
>> lots of cosmetic changes and not seeing the downstream ripple effects.
>> Several people complained to me at the conference about all the code
>> movement changes breaking their own work, causing them to stay on
>> older versions of bitcoin due to the effort required to rebase to each
>> new release version - and I share those complaints.
>>
>> Complex code changes with longer development cycles than simple code
>> movement patches keep breaking. It is very frustrating, and causes
>> folks to get trapped between a rock and a hard place:
>> - Trying to push non-trivial changes upstream is difficult, for normal
>> and reasonable reasons (big important changes need review etc.).
>> - Maintaining non-trivial changes out of tree is also painful, for the
>> aforementioned reasons.
>>
>> Reasonable work languishes in constant-rebase hell, and incentivizes
>> against keeping up with the latest tree.
>>
>>
>> Aside from the refactor, libconsensus appears to be engineering in the
>> dark. Where is any sort of plan? I have low standards - a photo of a
>> whiteboard or youtube clip will do.
>>
>> The general goal is good. But we must not stray into unfocused
>> engineering for a non-existent future library user.
>>
>> The higher priority must be given to having a source code base that
>> maximizes the collective developers' ability to maintain The Router --
>> the core bitcoin full node P2P engine.
>>
>> I recommend time-based bursts of code movement changes. See below;
>> for example, just submit & merge code movement changes on the first
>> week of every 2nd month. Code movement changes are easy to create
>> from scratch once a concrete goal is known. The coding part is
>> trivial and takes no time.
>>
>> As we saw in the Linux kernel - battle lessons hard learned - code
>> movement and refactors have often unseen negative impact on downstream
>> developers working on more complicated changes that have more positive
>> impact to our developers and users.
>>
>>
>> On Bitcoin development release cycles & process
>> ------------------------------------------------------------------
>>
>> As I've outlined in the past, the Linux kernel maintenance phases
>> address some of these problems. The merge window into git master
>> opens for 1 week, a very chaotic week full of merging (and rebasing),
>> and then the merge window closes. Several weeks follow as the "dust
>> settles" -- testing, bug fixing, moving in parallel OOB with
>> not-yet-ready development. Release candidates follow, then the
>> release, then the cycle repeats.
>>
>> IMO a merge window approach fixes some of the issues with refactoring,
>> as well as introduces some useful -developer discipline- into the
>> development process. Bitcoin Core still needs rapid iteration --
>> another failing of the current project -- and so something of a more
>> rapid pace is needed:
>> - 1st week of each month, merge changes. Lots of rebasing during this
>> week.
>> - remaining days of the month, test, bug fix
>> - release at end of month
>>
>> If changes are not ready for merging, then so be it, they wait until
>> next month's release. Some releases have major features, some
>> releases are completely boring and offer little of note. That is the
>> nature of time-based development iteration. It's like dollar cost
>> averaging, a bit.
>>
>>
>> And frankly, I would like to close all github pull requests that are
>> not ready to merge That Week. I'm as guilty of this as any, but that
>> stuff just languishes. Excluding a certain category of obvious-crap,
>> pull requests tend to default to a state of either (a) rapid merging,
>> (b) months-long issues/projects, (c) limbo.
>>
>> Under a more time-based approach, a better pull request process would be
>> to
>> * Only open pull requests if it's a bug fix, or the merge window is
>> open and the change is ready to be merged in the developer's opinion.
>> * Developers CC bitcoin-dev list to discuss Bitcoin Core-bound projects
>> * Developers maintain and publish projects via their own git trees
>> * Pull requests should be closed if unmerged after 7 days, unless it
>> is an important bug fix etc.
>>
>> The problem with projects like libconsensus is that they can get
>> unfocused and open ended. Code movement changes in particular are
>> cheap to generate. It is low developer cost for the developer to
>> iterate all the way to the end state, see what that looks like, and
>> see if people like it. That end state is not something you would
>> merge all in one go. I would likely stash that tree, and then start
>> again, seek the most optimal and least disruptive set of refactors,
>> and generate and merge those into bitcoin/bitcoin.git in a time-based,
>> paced manner. Announce the pace ahead of time - "cosmetic stuff that
>> breaks your patches will be merged 1st week of every second month"
>>
>> To underscore, the higher priority must be given to having a source
>> code base and disciplined development process that maximizes the
>> collective developers' ability to maintain The Router that maintains
>> most of our network.
>>
>> Modularity, refactoring, cleaning up grotty code generates a deep
>> seated happiness in many engineers. Field experience however shows
>> refactoring is a never ending process which sometimes gets in the way
>> of More Important Work.
>> _______________________________________________
>> 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/20150915/3f2f6d55/attachment-0001.html>

2023-06-07 17:40:15

- reply

📅 Original date posted:2015-09-15
📝 Original message:[collating a private mail and a github issue comment, moving it to a
better forum]
On libconsensus
---------------
In general there exists the reasonable goal to move consensus state
and code to a specific, separate lib.
To someone not closely reviewing the seemingly endless stream of
libconsensus refactoring PRs, the 10,000 foot view is that there is a
rather random stream of refactors that proceed in fits and starts
without apparent plan or end other than a one sentence "isolate
consensus state and code" summary.
I am hoping that
* There is some plan
* We will not see a five year stream of random consensus code movement
patches causing lots of downstream developer headaches.
I read every code change in every pull request that comes into
github/bitcoin/bitcoin with three exceptions:
* consensus code movement changes - too big, too chaotic, too
frequent, too unfocused, laziness guarantees others will inevitably
ACK it without me.
* some non-code changes (docs)
* ignore 80% of the Qt changes
As with any sort of refactoring, they are easy to prove correct, easy
to reason, and therefore quick and easy to ACK and merge.
Refactors however have a very real negative impact.
bitcoin/bitcoin.git is not only the source tree in the universe.
Software engineers at home, at startups, and at major companies are
maintaining branches of their own.
It is very very easy to fall into a trap where a project is merging
lots of cosmetic changes and not seeing the downstream ripple effects.
Several people complained to me at the conference about all the code
movement changes breaking their own work, causing them to stay on
older versions of bitcoin due to the effort required to rebase to each
new release version - and I share those complaints.
Complex code changes with longer development cycles than simple code
movement patches keep breaking. It is very frustrating, and causes
folks to get trapped between a rock and a hard place:
- Trying to push non-trivial changes upstream is difficult, for normal
and reasonable reasons (big important changes need review etc.).
- Maintaining non-trivial changes out of tree is also painful, for the
aforementioned reasons.
Reasonable work languishes in constant-rebase hell, and incentivizes
against keeping up with the latest tree.
Aside from the refactor, libconsensus appears to be engineering in the
dark. Where is any sort of plan? I have low standards - a photo of a
whiteboard or youtube clip will do.
The general goal is good. But we must not stray into unfocused
engineering for a non-existent future library user.
The higher priority must be given to having a source code base that
maximizes the collective developers' ability to maintain The Router --
the core bitcoin full node P2P engine.
I recommend time-based bursts of code movement changes. See below;
for example, just submit & merge code movement changes on the first
week of every 2nd month. Code movement changes are easy to create
from scratch once a concrete goal is known. The coding part is
trivial and takes no time.
As we saw in the Linux kernel - battle lessons hard learned - code
movement and refactors have often unseen negative impact on downstream
developers working on more complicated changes that have more positive
impact to our developers and users.
On Bitcoin development release cycles & process
------------------------------------------------------------------
As I've outlined in the past, the Linux kernel maintenance phases
address some of these problems. The merge window into git master
opens for 1 week, a very chaotic week full of merging (and rebasing),
and then the merge window closes. Several weeks follow as the "dust
settles" -- testing, bug fixing, moving in parallel OOB with
not-yet-ready development. Release candidates follow, then the
release, then the cycle repeats.
IMO a merge window approach fixes some of the issues with refactoring,
as well as introduces some useful -developer discipline- into the
development process. Bitcoin Core still needs rapid iteration --
another failing of the current project -- and so something of a more
rapid pace is needed:
- 1st week of each month, merge changes. Lots of rebasing during this week.
- remaining days of the month, test, bug fix
- release at end of month
If changes are not ready for merging, then so be it, they wait until
next month's release. Some releases have major features, some
releases are completely boring and offer little of note. That is the
nature of time-based development iteration. It's like dollar cost
averaging, a bit.
And frankly, I would like to close all github pull requests that are
not ready to merge That Week. I'm as guilty of this as any, but that
stuff just languishes. Excluding a certain category of obvious-crap,
pull requests tend to default to a state of either (a) rapid merging,
(b) months-long issues/projects, (c) limbo.
Under a more time-based approach, a better pull request process would be to
* Only open pull requests if it's a bug fix, or the merge window is
open and the change is ready to be merged in the developer's opinion.
* Developers CC bitcoin-dev list to discuss Bitcoin Core-bound projects
* Developers maintain and publish projects via their own git trees
* Pull requests should be closed if unmerged after 7 days, unless it
is an important bug fix etc.
The problem with projects like libconsensus is that they can get
unfocused and open ended. Code movement changes in particular are
cheap to generate. It is low developer cost for the developer to
iterate all the way to the end state, see what that looks like, and
see if people like it. That end state is not something you would
merge all in one go. I would likely stash that tree, and then start
again, seek the most optimal and least disruptive set of refactors,
and generate and merge those into bitcoin/bitcoin.git in a time-based,
paced manner. Announce the pace ahead of time - "cosmetic stuff that
breaks your patches will be merged 1st week of every second month"
To underscore, the higher priority must be given to having a source
code base and disciplined development process that maximizes the
collective developers' ability to maintain The Router that maintains
most of our network.
Modularity, refactoring, cleaning up grotty code generates a deep
seated happiness in many engineers. Field experience however shows
refactoring is a never ending process which sometimes gets in the way
of More Important Work.

2023-06-07 17:39:26

- reply

📅 Original date posted:2015-09-03
📝 Original message:Expanding on pay-with-diff and volatility (closing comment),
Users and miners will have significant difficulty creating and/or
predicting a stable block size (and fee environment) with pay-with-diff
across the months. The ability of businesses to plan is low. Chaos and
unpredictability are bad in general for markets and systems. Thus the
binary conclusion of "not get used" or "volatility"
On Thu, Sep 3, 2015 at 10:31 AM, Jeff Garzik <jgarzik at gmail.com> wrote:
> It's written as 'a' and/or 'b'. If you don't have idle hashpower, then
> paying with difficulty requires some amount of collusion ('a')
>
> Any miner paying with a higher difficulty either needs idle hashpower, or
> self-increase their own difficulty at the possible *opportunity cost* of
> losing an entire block's income to another miner who doesn't care about
> changing the block size. The potential loss does not economically
> compensate for size increase gains in most cases, when you consider the
> variability of blocks (they come in bursts and pauses) and the fee income
> that would be associated.
>
> Miners have more to lose paying with diff than they gain -- unless the
> entire network colludes out-of-band with ~90% certainty, by collectively
> agreeing to increase the block period by collectively agreeing with
> pay-with-diff until the globally desired block size is reached. At that
> level of collusion, we can create far more simple schemes to increase block
> size.
>
> Pay-with-diff will either not get used, or lead to radical short term
> block size (and thus fee) volatility. It is complex & difficult for all
> players to reason, and a Rational game theory choice can be to avoid
> paying-for-diff even when the network desperately needs an upgrade.
>
>
>
>
>
>
> On Thu, Sep 3, 2015 at 2:57 AM, Gregory Maxwell <gmaxwell at gmail.com>
> wrote:
>
>> On Thu, Sep 3, 2015 at 4:05 AM, Jeff Garzik via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > (b) requiring miners to have idle
>> > hashpower on hand to change block size are both unrealistic and
>> potentially
>>
>> I really cannot figure out how you could characterize pay with
>> difficty has in any way involving idle hashpower.
>>
>> Can you walk me through this?
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150903/1b1284e9/attachment.html>

2023-06-07 17:39:26

- reply

📅 Original date posted:2015-09-03
📝 Original message:It's written as 'a' and/or 'b'. If you don't have idle hashpower, then
paying with difficulty requires some amount of collusion ('a')
Any miner paying with a higher difficulty either needs idle hashpower, or
self-increase their own difficulty at the possible *opportunity cost* of
losing an entire block's income to another miner who doesn't care about
changing the block size. The potential loss does not economically
compensate for size increase gains in most cases, when you consider the
variability of blocks (they come in bursts and pauses) and the fee income
that would be associated.
Miners have more to lose paying with diff than they gain -- unless the
entire network colludes out-of-band with ~90% certainty, by collectively
agreeing to increase the block period by collectively agreeing with
pay-with-diff until the globally desired block size is reached. At that
level of collusion, we can create far more simple schemes to increase block
size.
Pay-with-diff will either not get used, or lead to radical short term block
size (and thus fee) volatility. It is complex & difficult for all players
to reason, and a Rational game theory choice can be to avoid
paying-for-diff even when the network desperately needs an upgrade.
On Thu, Sep 3, 2015 at 2:57 AM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Thu, Sep 3, 2015 at 4:05 AM, Jeff Garzik via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > (b) requiring miners to have idle
> > hashpower on hand to change block size are both unrealistic and
> potentially
>
> I really cannot figure out how you could characterize pay with
> difficty has in any way involving idle hashpower.
>
> Can you walk me through this?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150903/78c0bac7/attachment.html>

2023-06-07 17:39:25

- reply

📅 Original date posted:2015-09-03
📝 Original message:Thanks for the link. I readily admit only having given pay-to-future-miner
a little bit of thought. Not convinced it sets a minimal tx fee in all
cases.
On Thu, Sep 3, 2015 at 12:55 AM, <jl2012 at xbt.hk> wrote:
> Jeff Garzik via bitcoin-dev 於 2015-09-03 00:05 寫到:
>
>> Schemes proposing to pay with difficulty / hashpower to change block
>> size should be avoided. The miners incentive has always been fairly
>> straightforward - it is rational to deploy new hashpower as soon as
>> you can get it online. Introducing the concepts of (a) requiring
>> out-of-band collusion to change block size and/or (b) requiring miners
>> to have idle hashpower on hand to change block size are both
>> unrealistic and potentially corrosive. That potentially makes the
>> block size - and therefore fee market - too close, too sensitive to
>> the wild vagaries of the mining chip market.
>>
>> Pay-to-future-miner has neutral, forward looking incentives worth
>> researching.
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> Ref:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010723.html
>
> I explained here why pay with difficulty is bad for everyone: miners and
> users, and described the use of OP_CLTV for pay-to-future-miner
>
> However, a general problem of pay-to-increase-block-size scheme is it
> indirectly sets a minimal tx fee, which could be difficult and arbitrary,
> and is against competition
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150903/28c494e3/attachment.html>

2023-06-07 17:39:24

- reply

📅 Original date posted:2015-09-03
📝 Original message:Schemes proposing to pay with difficulty / hashpower to change block size
should be avoided. The miners incentive has always been fairly
straightforward - it is rational to deploy new hashpower as soon as you can
get it online. Introducing the concepts of (a) requiring out-of-band
collusion to change block size and/or (b) requiring miners to have idle
hashpower on hand to change block size are both unrealistic and potentially
corrosive. That potentially makes the block size - and therefore fee
market - too close, too sensitive to the wild vagaries of the mining chip
market.
Pay-to-future-miner has neutral, forward looking incentives worth
researching.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150903/c3b89058/attachment.html>

2023-06-07 17:39:22

- reply

📅 Original date posted:2015-09-03
📝 Original message:Thanks - several good suggestions, including some in common. Will comment
& revise today.
Currently in "collecting" mode, to avoid duplicative comments in multiple
locales.
On Thu, Sep 3, 2015 at 3:57 AM, <jl2012 at xbt.hk> wrote:
> Some comments:
>
>
> - The 75% rule is meaningless here. Since this is a pure relaxation of
> rules, there is no such thing as "invalid version 4 blocks"
>
>
> -
>
> The implication threshold is unclear. Is it 95% or 80%?
>
> - Softfork requires a very high threshold (95%) to "attack" the
> original fork. This makes sure that unupgraded client will only see the new
> fork.
> - In the case of hardfork, however, the new fork is unable to
> attack the original fork, and unupgraded client will never see the new
> fork. The initiation of a hardfork should be based on its acceptance by the
> economic majority, not miner support. 95% is an overkill and may probably
> never accomplished. I strongly prefer a 80% threshold rather than 95%.
>
>
> - As I've pointed out, using 20-percentile rather than median creates
> an incentive to 51% attack the uncooperative minority.
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010690.html
>
> Having said that, I don't have a strong feeling about the use of
> 20-percentile as threshold to increase the block size. That means the block
> size is increased only when most miners agree, which sounds ok to me.
>
> However, using 20-percentile as threshold to DECREASE the block size could
> be very dangerous. Consider that the block size has been stable at 8MB for
> a few years. Everyone are happy with that. An attacker would just need to
> acquire 21% of mining power to break the status quo and send us all the way
> to 1MB. The only way to stop such attempt is to 51% attack the attacker.
> That'd be really ugly.
>
> For technical and ethical reasons, I believe the thresholds for increase
> and decrease must be symmetrical: increase the block size when the
> x-percentile is bigger than the current size, decrease the block size when
> the (100-x)-percentile is smaller than the current size. The overall effect
> is: the block size remains unchanged unless 80% of miners agree to.
>
> - Please consider the use of "hardfork bit" to signify the hardfork:
>
>
> https://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bip_draft_hardfork_bit_jl2012_at_xbthk_jul_23_2015/
>
> https://github.com/jl2012/bips/blob/master/hardforkbit.mediawiki
>
> - Or, alternatively, please combine the hardfork with a softfork. I'm
> rewriting the specification as follow (changes underlined):
>
>
> 1. Replace static 1M block size hard limit with a floating limit
> ("hardLimit").
> 2.
>
> hardLimit floats within the range 1-32M, inclusive.
>
> 3.
>
> Initial value of hardLimit is 1M, preserving current system.
>
> 4. Changing hardLimit is accomplished by encoding a proposed value
> within a block's coinbase scriptSig.
> 1. Votes refer to a byte value, encoded within the pattern
> "/BV\d+/" Example: /BV8000000/ votes for 8,000,000 byte hardLimit. If
> there is more than one match with with pattern, the first match is counted.
> 2. Absent/invalid votes and votes below minimum cap (1M) are
> counted as 1M votes. Votes above the maximum cap (32M) are counted as 32M
> votes.
> 3. A new hardLimit is calculated at each difficult adjustment
> period (2016 blocks), and applies to the next 2016 blocks.
> 4. Calculate hardLimit by examining the coinbase scriptSig votes of
> the previous 12,000 blocks, and taking the 20th percentile and 80th
> percentile.
> 5. New hardLimit is the median of the followings:
> 1. min(current hardLimit * 1.2, 20-percentile)
> 2. max(current hardLimit / 1.2, 80-percentile)
> 3. current hardLimit
> 5. version 4 block: the coinbase of a version 4 block must match
> this pattern: "/BV\d+/"
> 6. 70% rule: If 8,400 of the last 12,000 blocks are version 4 or
> greater, reject invalid version 4 blocks. (testnet4: 501 of last 1000)
> 7. 80% rule ("Point of no return"): If 9,600 of the last 12,000 blocks
> are version 4 or greater, reject all version <= 3 blocks. (testnet4: 750 of
> last 1000)
> 8. Block version number is calculated after masking out high 16 bits
> (final bit count TBD by versionBits outcome).
>
> Jeff Garzik via bitcoin-dev 於 2015-09-02 23:33 寫到:
> > BIP 100 initial public draft:
> > https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki [1]
> >
> > Emphasis on "initial" This is a starting point for the usual open
> > source feedback/iteration cycle, not an endpoint that Must Be This
> > Way.
> >
> >
> >
> > Links:
> > ------
> > [1] https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki
> >
> > _______________________________________________
> > 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/20150903/2be39ef3/attachment.html>

2023-06-07 17:39:20

- reply

📅 Original date posted:2015-09-03
📝 Original message:Take a look at the latest update:
- swiped Tier Nolan verbiage, which I agree was usefully more clear
- added 'M' suffix and removed 'V' from coinbase scriptSig
On Thu, Sep 3, 2015 at 12:32 PM, jl2012 via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 1. I think there is no need to have resolution at byte level, while
> resolution at MB level is not enough. kB would be a better choice.
>
> 2. In my specification a v4 block without a vote is invalid, so there is
> no need to consider absent or invalid votes
>
> 3. We should allow miners to explicitly vote for the status quo, so they
> don't need to change the coinbase vote every time the size is changed. They
> may indicate it by /BV/ in the coinbase, and we should look for the first
> "/BVd*/" instead of "/BVd+/"
>
> 4. Alternatively, miners may vote in different styles: /BV1234567/,
> /BV1500K/, /BV3M/. The first one means 1.234567MB, the second one is 1.5MB,
> the last one is 3MB. The pattern is "/BV(\d+[KM]?)?/"
>
> Tier Nolan via bitcoin-dev 於 2015-09-03 07:59 寫到:
>
>> On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> *
>>>
>>> hardLimit floats within the range 1-32M, inclusive.
>>>
>>
>> Does the 32MB limit actually still exist anywhere in the code? In
>> effect, it is re-instating a legacy limitation.
>>
>> The message size limit is to minimize the storage required per peer.
>> If a 32MB block size is required, then each network input buffer must
>> be at least 32MB. This makes it harder for a node to support a large
>> number of peers.
>>
>> There is no reason why a single message is used for each block. Using
>> the merkleblock message (or a different dedicated message), it would
>> be possible to send messages which only contain part of a block and
>> have a limited maximum size.
>>
>> This would allow receiving parts of a block from multiple sources.
>>
>> This is a separate issue but should be considered if moving past 32MB
>> block sizes (or maybe as a later protocol change).
>>
>> * Changing hardLimit is accomplished by encoding a proposed value
>>> within a block's coinbase scriptSig.
>>>
>>> * Votes refer to a byte value, encoded within the pattern "/BVd+/"
>>> Example: /BV8000000/ votes for 8,000,000 byte hardLimit. If there is
>>> more than one match with with pattern, the first match is counted.
>>>
>>
>> Is there a need for byte resolution? Using MB resolution would use up
>> much fewer bytes in the coinbase.
>>
>> Even with the +/- 20% rule, miners could vote for the nearest MB.
>> Once the block size exceeds 5MB, then there is enough resolution
>> anyway.
>>
>> * Absent/invalid votes and votes below minimum cap (1M) are
>>>
>>> counted as 1M votes. Votes above the maximum cap (32M) are counted
>>> as 32M votes.
>>>
>>
>> I think abstains should count for the status quo. Votes which are out
>> of range should be clamped.
>>
>> Having said that, if core supports the change, then most miners will
>> probably vote one way or another.
>>
>> New hardLimit is the median of the followings:
>>> min(current hardLimit * 1.2, 20-percentile)
>>> max(current hardLimit / 1.2, 80-percentile)
>>> current hardLimit
>>>
>>
>> I think this is unclear, though mathematically exact.
>>
>> Sort the votes for the last 12,000 blocks from lowest to highest.
>>
>> Blocks which don't have a vote are considered a vote for the status
>> quo.
>>
>> Votes are limited to +/- 20% of the current value. Votes that are out
>> of range are considered to vote for the nearest in range value.
>>
>> The raise value is defined as the vote for the 2400th highest block
>> (20th percentile).
>>
>> The lower value is defined as the vote for the 9600th highest block
>> (80th percentile).
>>
>> If the raise value is higher than the status quo, then the new limit
>> is set to the raise value.
>>
>> If the lower value is lower than the status quo, then the new limit is
>> set to the lower value.
>>
>> Otherwise, the size limit is unchanged.
>>
>> _______________________________________________
>> 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/20150903/6babfaa4/attachment.html>

2023-06-07 17:39:18

- reply

📅 Original date posted:2015-09-03
📝 Original message:A discussion of rolling out BIP 100 will not be avoided :)
It is a hard fork; it would be silly to elide discussion of these key
issues.
I don't get the community's recent interest in avoiding certain topics.
On Thu, Sep 3, 2015 at 7:20 AM, Btc Drak <btcdrak at gmail.com> wrote:
> We should avoid discussing actual hard fork/softfork deployment
> methodologies when discussing blocksize proposals because deployment
> is a separate issue. As a recent case in point, look at how BIP65
> (CHECKLOCKTIMEVERIFY) specifically avoided the issue of how to deploy.
> That lead to a focused discussion of the functionality and relatively
> quick inclusion.
>
> Deployment really is a separate issue than the mechanics of how BIP100
> will function after activation.
>
> On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Some comments:
> >
> > The 75% rule is meaningless here. Since this is a pure relaxation of
> rules,
> > there is no such thing as "invalid version 4 blocks"
> >
> > The implication threshold is unclear. Is it 95% or 80%?
> >
> > Softfork requires a very high threshold (95%) to "attack" the original
> fork.
> > This makes sure that unupgraded client will only see the new fork.
> > In the case of hardfork, however, the new fork is unable to attack the
> > original fork, and unupgraded client will never see the new fork. The
> > initiation of a hardfork should be based on its acceptance by the
> economic
> > majority, not miner support. 95% is an overkill and may probably never
> > accomplished. I strongly prefer a 80% threshold rather than 95%.
> >
> > As I've pointed out, using 20-percentile rather than median creates an
> > incentive to 51% attack the uncooperative minority.
> >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010690.html
> >
> > Having said that, I don't have a strong feeling about the use of
> > 20-percentile as threshold to increase the block size. That means the
> block
> > size is increased only when most miners agree, which sounds ok to me.
> >
> > However, using 20-percentile as threshold to DECREASE the block size
> could
> > be very dangerous. Consider that the block size has been stable at 8MB
> for a
> > few years. Everyone are happy with that. An attacker would just need to
> > acquire 21% of mining power to break the status quo and send us all the
> way
> > to 1MB. The only way to stop such attempt is to 51% attack the attacker.
> > That'd be really ugly.
> >
> > For technical and ethical reasons, I believe the thresholds for increase
> and
> > decrease must be symmetrical: increase the block size when the
> x-percentile
> > is bigger than the current size, decrease the block size when the
> > (100-x)-percentile is smaller than the current size. The overall effect
> is:
> > the block size remains unchanged unless 80% of miners agree to.
> >
> > Please consider the use of "hardfork bit" to signify the hardfork:
> >
> >
> https://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bip_draft_hardfork_bit_jl2012_at_xbthk_jul_23_2015/
> >
> > https://github.com/jl2012/bips/blob/master/hardforkbit.mediawiki
> >
> > Or, alternatively, please combine the hardfork with a softfork. I'm
> > rewriting the specification as follow (changes underlined):
> >
> > Replace static 1M block size hard limit with a floating limit
> ("hardLimit").
> >
> > hardLimit floats within the range 1-32M, inclusive.
> >
> > Initial value of hardLimit is 1M, preserving current system.
> >
> > Changing hardLimit is accomplished by encoding a proposed value within a
> > block's coinbase scriptSig.
> >
> > Votes refer to a byte value, encoded within the pattern "/BV\d+/"
> Example:
> > /BV8000000/ votes for 8,000,000 byte hardLimit. If there is more than one
> > match with with pattern, the first match is counted.
> > Absent/invalid votes and votes below minimum cap (1M) are counted as 1M
> > votes. Votes above the maximum cap (32M) are counted as 32M votes.
> > A new hardLimit is calculated at each difficult adjustment period (2016
> > blocks), and applies to the next 2016 blocks.
> > Calculate hardLimit by examining the coinbase scriptSig votes of the
> > previous 12,000 blocks, and taking the 20th percentile and 80th
> percentile.
> > New hardLimit is the median of the followings:
> >
> > min(current hardLimit * 1.2, 20-percentile)
> > max(current hardLimit / 1.2, 80-percentile)
> > current hardLimit
> >
> > version 4 block: the coinbase of a version 4 block must match this
> pattern:
> > "/BV\d+/"
> > 70% rule: If 8,400 of the last 12,000 blocks are version 4 or greater,
> > reject invalid version 4 blocks. (testnet4: 501 of last 1000)
> > 80% rule ("Point of no return"): If 9,600 of the last 12,000 blocks are
> > version 4 or greater, reject all version <= 3 blocks. (testnet4: 750 of
> last
> > 1000)
> > Block version number is calculated after masking out high 16 bits (final
> bit
> > count TBD by versionBits outcome).
> >
> > Jeff Garzik via bitcoin-dev 於 2015-09-02 23:33 寫到:
> >> BIP 100 initial public draft:
> >> https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki [1]
> >>
> >> Emphasis on "initial" This is a starting point for the usual open
> >> source feedback/iteration cycle, not an endpoint that Must Be This
> >> Way.
> >>
> >>
> >>
> >> Links:
> >> ------
> >> [1] https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki
> >>
> >> _______________________________________________
> >> 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/20150903/43c07e6d/attachment-0001.html>

2023-06-07 17:39:16

- reply

📅 Original date posted:2015-09-03
📝 Original message:BIP 100 initial public draft:
https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki
Emphasis on "initial" This is a starting point for the usual open source
feedback/iteration cycle, not an endpoint that Must Be This Way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150902/0c11c03f/attachment.html>

2023-06-07 17:39:15

- reply

📅 Original date posted:2015-09-03
📝 Original message:Luke,
- Definitely agree with most of your suggestions on the practical side;
several clarification could be made.
- The power to decrease the hard limit appears riskier long term in my
analysis. This is mitigated somewhat by the ease at which miners may
locally or collectively lower the block size at any time, without a vote.
On Wed, Sep 2, 2015 at 8:17 PM, Luke Dashjr <luke at dashjr.org> wrote:
> On Wednesday, September 02, 2015 11:58:54 PM Jeff Garzik via bitcoin-dev
> wrote:
> > The repo: https://github.com/jgarzik/bip100
>
> What is the purpose of the newly added 1 MB floor? It seems clear from the
> current information available that 1 MB is presently too high for the
> limit,
> and it is entirely one-sided to only allow increases when decreases are
> much
> more likely to be needed in the short term.
>
> Must the new size limit votes use 11 bytes of coinbase? Why not just use a
> numeric value pushed after height? Since this is a hardfork, I suggest
> increasing the coinbase length to allow for 100 bytes *in addition* to the
> pushed height and size-vote.
>
> I suggest combining 2 & 4 into a single rule lifting the 1 MB limit to 32
> MB
> (or whatever value is deemed appropriate) to make it clear that the limit
> remains a part of the consensus protocol and p2p protocol limits are not to
> have an effect on consensus rules.
>
> Furthermore, I suggest modifying the voting to require 50% to set the limit
> floor. This has the effect of merely coordinating what miners can already
> effectively do today by rejecting blocks larger than some collusion-
> determined limit.
>
> Thoughts?
>
> Luke
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150902/a238869a/attachment.html>

2023-06-07 17:39:15

- reply

📅 Original date posted:2015-09-03
📝 Original message:Oh, and answering your question about the 1M: It is a safety rail. It can
perform no worse on the low end than the current system. Eliminates
unlikely scenarios that squeeze users.
On Wed, Sep 2, 2015 at 8:17 PM, Luke Dashjr <luke at dashjr.org> wrote:
> On Wednesday, September 02, 2015 11:58:54 PM Jeff Garzik via bitcoin-dev
> wrote:
> > The repo: https://github.com/jgarzik/bip100
>
> What is the purpose of the newly added 1 MB floor? It seems clear from the
> current information available that 1 MB is presently too high for the
> limit,
> and it is entirely one-sided to only allow increases when decreases are
> much
> more likely to be needed in the short term.
>
> Must the new size limit votes use 11 bytes of coinbase? Why not just use a
> numeric value pushed after height? Since this is a hardfork, I suggest
> increasing the coinbase length to allow for 100 bytes *in addition* to the
> pushed height and size-vote.
>
> I suggest combining 2 & 4 into a single rule lifting the 1 MB limit to 32
> MB
> (or whatever value is deemed appropriate) to make it clear that the limit
> remains a part of the consensus protocol and p2p protocol limits are not to
> have an effect on consensus rules.
>
> Furthermore, I suggest modifying the voting to require 50% to set the limit
> floor. This has the effect of merely coordinating what miners can already
> effectively do today by rejecting blocks larger than some collusion-
> determined limit.
>
> Thoughts?
>
> Luke
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150903/133d57d9/attachment-0001.html>

2023-06-07 17:39:14

- reply

📅 Original date posted:2015-09-02
📝 Original message:Opened a repo containing the full text of BIP 100 discussion document, in
markdown format.
The BIP 100 formal spec will be checked in here as well, before submitting
to upstream bips.git repo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150902/3380d204/attachment.html>

2023-06-07 17:39:14

- reply

📅 Original date posted:2015-09-02
📝 Original message:Oops, link paste fail.
The repo: https://github.com/jgarzik/bip100
On Wed, Sep 2, 2015 at 7:51 PM, Jeff Garzik <jgarzik at gmail.com> wrote:
> Opened a repo containing the full text of BIP 100 discussion document, in
> markdown format.
>
> The BIP 100 formal spec will be checked in here as well, before submitting
> to upstream bips.git repo.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150902/2b394143/attachment.html>

2023-06-07 17:38:01

- reply

📅 Original date posted:2015-08-27
📝 Original message:20th percentile, though there is some argument to take the 'mode' of
several tranches
On Thu, Aug 27, 2015 at 11:07 AM, Andrew C <achow101 at gmail.com> wrote:
> I have been reading the pdf and one thing I can't figure out is what you
> mean by "most common floor". Is that the smallest block size that has a
> vote or the block size with the most votes or something else?
>
> On Mon, Aug 24, 2015 at 10:40 AM Jeff Garzik <jgarzik at gmail.com> wrote:
>
>> Great questions.
>>
>> - Currently working on technical BIP draft and implementation, hopefully
>> for ScalingBitcoin.org. Only the PDF is publicly available as of today.
>> - Yes, the initial deployment is in the same manner as size votes.
>>
>>
>> On Fri, Aug 21, 2015 at 7:38 PM, Andrew C via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Hi all,
>>>
>>> Is there any client or code that currently implements BIP 100? And how
>>> will it be deployed? WIll the initial fork be deployed in the same manner
>>> that the max block size changes are deployed described in the bip?
>>>
>>> Thanks
>>>
>>> _______________________________________________
>>> 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/20150827/1681a5ee/attachment.html>

2023-06-07 17:38:00

- reply

📅 Original date posted:2015-08-24
📝 Original message:Great questions.
- Currently working on technical BIP draft and implementation, hopefully
for ScalingBitcoin.org. Only the PDF is publicly available as of today.
- Yes, the initial deployment is in the same manner as size votes.
On Fri, Aug 21, 2015 at 7:38 PM, Andrew C via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi all,
>
> Is there any client or code that currently implements BIP 100? And how
> will it be deployed? WIll the initial fork be deployed in the same manner
> that the max block size changes are deployed described in the bip?
>
> Thanks
>
> _______________________________________________
> 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/20150824/5b02e8ec/attachment.html>

2023-06-07 17:37:37

- reply

📅 Original date posted:2015-08-21
📝 Original message:I don't see any link to data backing up "Bloom filter usage has declined
significantly"
Is there actual data showing this feature's use is declining or
non-existent?
On Fri, Aug 21, 2015 at 1:55 AM, Peter Todd <pete at petertodd.org> wrote:
> On Fri, Aug 21, 2015 at 01:48:23AM -0400, Jeff Garzik via bitcoin-dev
> wrote:
> > If this is widely deployed + enabled, what is the impact to current
> wallets
> > in use?
>
> See my comment on the recently-opened issue, reproduced below. In short,
> not all that much, especially if we adopt my suggestion of having the
> Core implementation accept and respond to bloom filter requests from
> non-upgraded clients regardless of whether or not NODE_BLOOM was set
> until some fixed upgrade deadline in the future.
>
>
> Note that since the last time NODE_BLOOM was proposed, the landcape for
> (lite-)SPV clients has changed significantly in a few key ways:
>
> 1) @mikehearn's [Cartographer](https://github.com/mikehearn/httpseed)
> seed protocol has been created and deployed in production to allow
> (lite-)SPV clients to find nodes supporting arbitrary service bits,
> notable NODE_GETUTXOs.
>
> 2) Bloom filter usage has declined significantly, as lite-SPV clients
> are moving towards using centralized, trusted, servers run by the
> wallet
> authors. For instance
> [Mycelium](https://github.com/mycelium-com/wallet),
> [GreenBits](https://github.com/greenaddress/GreenBits),
> [AirBitz](
> https://www.reddit.com/r/Bitcoin/comments/3etohn/whats_wrong_with_breadwallet/ctirou5
> ),
> and [Electrum](https://electrum.org/#home) all fall in this category.
>
> 3) Bloom filters [have been found](http://eprint.iacr.org/2014/763) to
> have severe privacy issues, offering essentially no privacy at all.
> Under many threat models a small number of trusted servers pose less
> privacy security risk than connecting to random, sybil-attackable,
> peers
> using unencrypted connections and giving those peers very accurate
> wallet contents information.
>
> 4) Finally, Bloom filters still have [unsolved DoS attack
> issues](
> https://www.reddit.com/r/Bitcoin/comments/3hjak7/the_hard_work_of_core_devs_not_xt_makes_bitcoin/cu9xntf?context=3
> ),
> that will get significantly worse under upcoming blocksize increase
> proposals.
>
> Re: service bit identifier, I'd just pick 1<<3
>
> -https://github.com/bitcoin/bitcoin/issues/6578#issuecomment-133226943
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150821/a7e8d410/attachment.html>

2023-06-07 17:37:36

- reply

📅 Original date posted:2015-08-21
📝 Original message:If this is widely deployed + enabled, what is the impact to current wallets
in use?
On Fri, Aug 21, 2015 at 12:46 AM, Matt Corallo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Peter: Since I stole most of this text from your old BIP, should I leave
> you as an author?
>
> BIP: ?
> Title: NODE_BLOOM service bit
> Author: Matt Corallo <bip at bluematt.me>, Peter Todd <pete at petertodd.org>
> Type: Standards Track (draft)
> Created: 20-08-2015
>
> Abstract
> ========
>
> This BIP extends BIP 37, Connection Bloom filtering, by defining a
> service bit to allow peers to advertise that they support bloom filters
> explicitly. It also bumps the protocol version to allow peers to
> identify old nodes which allow bloom filtering of the connection despite
> lacking the new service bit.
>
>
> Motivation
> ==========
>
> BIP 37 did not specify a service bit for the bloom filter service, thus
> implicitly assuming that all nodes that serve peers data support it.
> However, the connection filtering algorithm proposed in BIP 37, and
> implemented in several clients today, has been shown to provide little
> to no privacy, as well as being a large DoS risk on some nodes. Thus,
> allowing node operators to disable connection bloom filtering is a
> much-needed feature.
>
>
> Specification
> =============
>
> The following protocol bit is added:
>
> NODE_BLOOM = (1 << 2)
>
> Nodes which support bloom filters should set that protocol bit.
> Otherwise it should remain unset. In addition the protocol version is
> increased from 70002 to 70011 in the reference implementation. It is
> often the case that nodes which have a protocol version smaller than
> 70011, but larger than 70000 support bloom filtered connections without
> the NODE_BLOOM bit set, however clients which require bloom filtered
> connections should avoid making this assumption.
>
> NODE_BLOOM is distinct from NODE_NETWORK, and it is legal to advertise
> NODE_BLOOM but not NODE_NETWORK (eg for nodes running in pruned mode
> which, nonetheless, provide filtered access to the data which they do
> have).
>
> If a node does not support bloom filters but receives a "filterload",
> "filteradd", or "filterclear" message from a peer the node should
> disconnect that peer immediately. For backwards compatibility, in
> initial implementations, nodes may choose to only disconnect nodes which
> have the new protocol version set and attempt to send a filter command.
>
> While outside the scope of this BIP it is suggested that DNS seeds and
> other peer discovery mechanisms support the ability to specify the
> services required; current implementations simply check only that
> NODE_NETWORK is set.
>
>
> Design rational
> ===============
>
> A service bit was chosen as applying a bloom filter is a service.
>
> The increase in protocol version is for backwards compatibility. In
> initial implementations, old nodes which are not yet aware of NODE_BLOOM
> and use a protocol version < 70011 may still send filter* messages to a
> node without NODE_BLOOM. This feature may be removed after there are
> sufficient NODE_BLOOM nodes available and SPV clients have upgraded,
> allowing node operators to fully close the bloom-related DoS vectors.
>
>
> Reference Implementation
> ========================
>
> https://github.com/bitcoin/bitcoin/pull/6579
>
>
> Copyright
> =========
>
> This document is placed in the public domain.
> _______________________________________________
> 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/20150821/fa23e4e1/attachment.html>

2023-06-07 17:37:30

- reply

📅 Original date posted:2015-08-24
📝 Original message:There is a duplicated column.
BIP 100 voting is /BV\d+/
On Fri, Aug 21, 2015 at 9:24 AM, Christian Decker via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I hacked together a simple tracking page for the 'block votes', it
> currently includes the 8MB vote and XT, as well as the /BV\d+/ vote for
> generic size:
> http://bitcoinstats.com/network/votes/
>
> On Fri, Aug 21, 2015 at 7:25 AM odinn via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hello Nicolas,
>>
>> On 08/20/2015 08:49 PM, Nicolas Dorier via bitcoin-dev wrote:
>> >> A visualization I would like to see would include:
>> >
>> >> pie graph(s) of what % are voting for (BIP 100, BIP 101, 8MB, BIP
>> >> sipa
>> > etc) based on what's published in blocks.
>> >
>> > If such a vote existed, I would gladly show the pie on BIPxDevs.
>> > However there is no standard way for miners to vote informally BIP
>> > they support.
>>
>> What about formal votes? Is there a way to visually have them appear
>> in a pie chart as the votes become apparent in blocks?
>>
>> I appreciate good visualizations and am trying to get a (visual)
>> comparison of the votes on these competing proposals.
>>
>> >
>> >
>> >
>> > _______________________________________________ bitcoin-dev mailing
>> > list bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>>
>> - --
>> http://abis.io ~
>> "a protocol concept to enable decentralization
>> and expansion of a giving economy, and a new social good"
>> https://keybase.io/odinn
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1
>>
>> iQEcBAEBAgAGBQJV1rZSAAoJEGxwq/inSG8CuNgIAIOIpHavzz6EJ5AOGBg2T859
>> MV7rsPfk1HBV4K1Yf4HfrlD/1SY0L57SANpRodi1NME3pl27QQCDnuwNLAqOLKtA
>> P/sHXnk9LuSG8Czk0PHOslZ+f1fDbmNm9gtR3QWXGOx0jP2b+WQ8RhkPhqQ++S/i
>> oXmjyrk+8TTu1hxMbuCcG5bqeS0lBm0SyrSbRTPWH+4U1jGYbxQNKkHnuZGByX4B
>> HBWuKvIylQzHCfy0ToUW+Z29Y+78wQNQUOA10eq7qpZCZvfRZUov1KBVXLx8GAKy
>> Y5WGSJYIAt+Rwn9eMxhpD91ZR1vwtqtRZn7M+NtrStPBJt+n4ET9VmPpsMAc/Zc=
>> =AHv3
>> -----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/20150824/6ea02715/attachment-0001.html>

2023-06-07 17:37:04

- reply

📅 Original date posted:2015-08-19
📝 Original message:bitcoin-dev for protocol discussion and bitcoin-core for Bitcoin Core
discussion?
As Jorge notes, a general discussion list has existed for a long time with
little use.
On Wed, Aug 19, 2015 at 5:58 AM, Btc Drak via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Aug 19, 2015 at 9:59 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
>
>> Apparently that existed already:
>> http://sourceforge.net/p/bitcoin/mailman/
>> But technical people run away from noise while non-technical people
>> chase them wherever their voices sounds more loud.
>>
>
> Regarding disruptors, if there are clear rules about what is acceptable on
> -dev, one can simply moderate out offenders. It's absolutely necessary we
> have a forum where we can share and discuss purely academic and technical
> matters. No-one can accuse censorship because all moderation would say
> would be to "take it to the other list". It's essential for all people who
> are developing and maintaining Bitcoin protocol software, or services that
> rely on it. The mailing list used to be very low volume.
>
> While we are at it, we should also think about a bitcoin-announce read
> only list which consumers of Bitcoin Core can subscribe for announcements
> about new versions of Bitcoin Core, and any critical warnings. Miners and
> service providers would particularly benefit from this. The list is
> moderated so only say Bitcoin Core commit engineers are allowed to post.
>
>
>> One thing that I would like though, is separating Bitcoin
>> Core-specific development from general bips and consensus discussions.
>>
>
> The potential downside is too much separation becomes confusing although I
> would not oppose such a change. My own suggestion would be try just a -dev
> and -discuss list and see how that goes first. It used to work well.
> Whatever the case I am very confident we need a general discussion mailing
> list.
>
>
>
> _______________________________________________
> 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/20150819/bc1f9aa4/attachment.html>

2023-06-07 17:37:01

- reply

📅 Original date posted:2015-08-19
📝 Original message:A lot of this detail and worry is eliminated by simply asking BIP 102
maintainers to change to a different bit that works best for everyone.
Existing nVersion garbage will get buried in sufficient time window to
prevent anything from triggering.
Just settle on a specific standard, reserve bits for feature upgrade forks,
and move on. There is already a rough standard proposed in sipa's gist.
On Wed, Aug 19, 2015 at 9:22 AM, Tier Nolan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Aug 19, 2015 at 7:10 AM, Mark Friedenbach via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> We can use nVersion & 0x8 to signal support, while keeping the consensus
>> rule as nVersion >= 4, right? That way we don't waste a bit after this all
>> clears up.
>>
> What happens if XT gets 40% and this BIP gets 55%? That gives 95% that
> accept the upgrade. Version 3 and lower blocks need to be rejected after
> that.
>
> By advertising 0x7 for the last 3 bits, XT is effectively claiming to
> support the check locktime verify BIPs but they don't have the code.
>
> This sequence could be used, without a specific version-bits proposal.
>
> Until height = N + 5000, if 950 of the last 1000 blocks have the 0x8 bit
> set, then reject blocks with version numbers less than 8.
>
> At height N, if the above rule is active, then the BIP is permanent.
>
> It applies to any block with bit 0x8 set, once the 75% threshold is met.
>
> From height N + 5000 to N + 10000, reject blocks which have bit 0x8 set.
>
> N could be set 1 year from now, or so.
>
>
> This gives a period of time after lock that bit 8 is kept and then a
> period where is is guaranteed to be zero.
>
> This gives software that is only watching the bit time to be upgraded and
> similarly time where the bit is set to zero before it can be reused.
>
> _______________________________________________
> 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/20150819/d86e0c0c/attachment-0001.html>

2023-06-07 17:36:16

- reply

📅 Original date posted:2015-08-19
📝 Original message:As jl2012 indicated, this is an insufficient analysis.
You cannot assume that because X time passed since the last block, the
miner's internal block maker has updated the template, and from there, is
shipped out to the hashers in the field. Further, even if you update the
block template at time Y, a hasher might return with a solution for the
block at time X, and the miner will of course publish solution X.
There are several steps of latency involved, even ignoring things such as
the miner relay network or getting US pool stratum links to a sub-pool in
China.
On Mon, Aug 17, 2015 at 4:42 AM, Luv Khemani via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi all,
>
> I previously mentioned in a post that i believe that technically nodes
> are capable of handling blocks an order of magnitude larger than the
> current blocksize limit, the only missing thing was an incentive to run
> them. I have been monitoring the blockchain for the past couple of weeks
> and am seeing that even miners who have all the incentives are for whatever
> reason struggling to download and validate much smaller blocks.
>
> The data actually paints a very grim picture of the current
> bandwidth/validating capacity of the global mining network.
>
> See the following empty blocks mined despite a non-trivial elapsed time
> from the previous block just from the past couple of days alone (Data from
> insight.bitpay.com):
>
> EmptyBlock /Time since previous block/ Size of previous block(bytes)/Mined
> by
> ====================================================
> 370165 29s 720784 Antpool
> 370160 31s 50129 BTCChinaPool
> 370076 49s 469988 F2Pool
> 370059 34s 110994 Antpool
> 370057 73s 131603 Antpool
>
> We have preceding blocks as small as 50KB with 30s passing and the miner
> continues to mine empty blocks via SPV mining.
> The most glaring case is Block 370057 where despite 73s elapsing and the
> preceding block being a mere 131KB, the miner is unable to
> download/validate fast enough to include transactions in his block. Unless
> ofcourse the miner is mining empty blocks on purpose, which does not make
> sense as all of these pools do mine blocks with transactions when the
> elapsed time is greater.
>
> This is a cause for great concern, because if miners are SPV mining for a
> whole minute for <750KB blocks, at 8MB blocks, the network will just fall
> apart as a significant portion of the hashing power SPV mines throughout.
> All a single malicious miner has to do is mine an invalid block on purpose,
> let these pools SPV mine on top of them while it mines a valid block free
> of their competition. Yes, these pools deserve to lose money in that event,
> but the impact of reorgs and many block orphans for anyone not running a
> full node could be disastrous, especially more so in the XT world where
> Mike wants everyone to be running SPV nodes. I simply don't see the XT fork
> having any chance of surviving if SPV nodes are unreliable.
>
> And if these pools go out of business, it will lead to even more mining
> centralization which is already too centralized today.
>
> Can anyone representing these pools comment on why this is happening? Are
> these pools on Matt's relay network?
>
>
>
>
>
> _______________________________________________
> 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/20150819/0e62622a/attachment.html>

2023-06-07 17:36:02

- reply

📅 Original date posted:2015-08-16
📝 Original message:"minimum" an interesting topic.
- Traffic levels may not produce a minimum size block
- Miners can always collude to produce a lowered maximum block size, a sort
of minimum maximum
On Sun, Aug 16, 2015 at 12:41 PM, Levin Keller via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hey everyone,
>
> as with the current "max block size" debate I was wondering: Is anyone
> here in favor of a minimum block size (say 2 MB or so)? If so I would be
> interested in an exchange (maybe off-list) of ideas. I am in favor of a
> lower limit and am giving it quite a bit of thought at the moment.
>
> Cheers
>
> Levin
>
> _______________________________________________
> 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/20150816/f99fd546/attachment.html>

2023-06-07 17:35:40

- reply

📅 Original date posted:2015-08-17
📝 Original message:In times of controversy or flamewar on the Linux kernel mailing list,
occasionally fake "Linus Torvalds" or other spoofed posts would appear. It
is the nature of email. Just ignore it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150817/f57f433b/attachment.html>

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

📅 Original date posted:2015-08-12
📝 Original message:Many miners are already voting on BIP 100 -- see the blocks published.
The BIP itself should be submitted w/ implementation in the next 2 weeks.
On Wed, Aug 12, 2015 at 12:44 PM, odinn via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Assuming some form of BIP 100 is a path which people may want to take,
> how and at what point do miners vote on this?
> Note:
> https://bitcoin.stackexchange.com/questions/37943/bip-100-what-votes-are
> - -possible
> describes this somewhat, but is unclear as to timeline of when miners
> would do the things described.
>
> Followup question thrown in for good measure:
> When is BIP 100 anticipated to be published (moved to 'accepted' and
> published) at
> https://github.com/bitcoin/BIPS ?
>
> - --
> http://abis.io ~
> "a protocol concept to enable decentralization
> and expansion of a giving economy, and a new social good"
> https://keybase.io/odinn
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJVy3gLAAoJEGxwq/inSG8C9kgH/2YHDIbf118I4k3uLYn0UzUQ
> 7iF+gV76pgtjsXmcUpRw1piZcUwWFQ1MszTn92PvmW9sjajuTPRBOOmHv1srsC4e
> H9jrQ3AoBDZCeY6FnVZIkCUYvcexi+2DsUG3z+e82AssBVljuzh3SPTZimA7oe20
> 9RxcNxSMmvcRFxkaFfuAjr2BaxiwaWNV7mlG1KCdCV8JV8LoHZRiMe+MPN7I9QKo
> yssEYP49TzaXBaAsRFXVl8N+pr5CRtXz+bv5Uh3WOAzhXMqpeliKnzTLdsgyz2SR
> EfICr7GezOieBvNRCp3e+bVD4mkG20Da7y0jfrxahRNB7ZBWIiFuxu4inyoCH00=
> =644w
> -----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/20150812/54379da8/attachment.html>

2023-06-07 15:46:37

- reply

📅 Original date posted:2015-08-11
📝 Original message:+1 Glad to see this work.
The Bitcoin Core wallet is a bit neglected these days - maintained but not
advancing.
On Tue, Aug 11, 2015 at 5:02 AM, Jonas Schnelli via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi
> (excuse my english; it’s not my native language)
>
> As you might noticed, bitcoin-cores wallet didn’t got that much focus
> during the last month (even years?).
> Wallet development has mostly moved towards SPV (bitcoinj), thin
> clients (Electrum), centralized web middleware (Copay, Greenaddress,
> etc.).
>
> Obviously this direction was highly appreciated by users who now can
> now run a bitcoin-client (SPV / thin client) on a smartphone or on a
> computer with tiny available resources.
>
> Full validation slowly gets a privilege of people who can manage to
> run bitcoin-core on a VPS or different server like system.
> Thought, i think, running a full node wallet could be end user
> friendly with some changes in the current concept.
>
> Today a standard user can download a 1080p 10GB movie over iTunes (in
> background) and simultaneous play a CPU/GPU extensive 3D game on a
> standard computer.
> Why do people think (and it might is) running a full node is so painful?
>
> Mainly it could be because bitcoin-core has been focused on doing
> validation as quick as possible (okay for a server, not desirable for
> a wallet background service).
>
> I could see the following strategy:
> - - end user focused full node wallet would have enabled pruning by
> default (~2GB disk usage).
> - - throttled validation (flexible CPU usage, user selectable, maybe
> ~20% by default).
> - - throttled block download (bandwidth).
> - - SPV during catch up (initial sync as also when catching up multiple
> days because user/node was offline).
> - - Disable bloom filtering if there is enough bandwith, keep blocks for
> later validation.
> - - when node is in sync, switch from SPV to full validation (maybe
> maintain to lists/dbs of wtx or re-validate after full catchup and
> display potential conflicts).
> - - participate in p2p, but with limits/throttling (service limited
> amount of blocks, tx [TBD]).
>
> Why?
> - - This could increase the amount of participating full nodes while
> giving users more privacy and security.
> - - Create a counterweight against SPV/thin clients (avoid wallet
> development centralization, could be helpful once/if attacks agains
> SPV/thin clients are becoming real).
> - - Slowly complete full validation (can take ~1-2 weeks) and thereforce
> increase privacy (avoid bloomfilters) and security.
>
> What about SPV together with a full node?
> Sounds good in theory. But who can run a full node (see above)? How is
> the channel secured (against MITM, privacy) between the SPV client and
> the trusted full node? How hard is it to setup and maintain a secure
> tunnel between a smartphone SPV and a full node over the p2p (8333)
> channel? How about examine the mempool for fee calculations and
> (maybe) upcoming CPFP like approaches, etc.?
>
> How about smartphones?
> Obviously the above solution won’t probably work on a smartphone (to
> much bandwidth and CPU usage). But do you carry your whole saving in
> your physical wallet with you? Maybe a smartphone does hold keys which
> protects low value / daily spendings like a physical wallet (=SPV okay).
> My personal long term vision of that use-case is, that groups of
> people who trust each other (a family, etc.) might run one or multiple
> full node(s) on a hardened system (something similar to the bitnodes
> hardware) where the system could serve smartphones over something like
> a stratum server (electrum) or bitpays wallet-service does (index
> blockchain, additional wallet services). Every member still holds it’s
> keys but they trust the connected full node (full nodes does address
> index, balance calculation, multisig arrangements and maybe even coin
> selection).
>
> Since about one year i slowly work toward this direction. It took me a
> while to commit myself to a strategy (and i still shake from time to
> time).
> At the moment I am working on a wallet focused bitcoin-core fork with
> the ability to re-merge it to the bitcoin-core branch (keep the fork
> rebased).
> Long term goal is, to decouple the both (wallet / core) by using
> bitcoin-core as a library (static or shared) for the wallet side
> (which is possible already now)
>
> To myself: I work in the bitcoin-space full-time and completely
> independent (not employed or influenced by a bitcoin related company)
> with no business interest, though, i think the acquired know-how can
> be valuable within the next serval years. And i won’t have any regrets
> if my work turns out to be unless and ends up in trash.
>
> I have set up this mail to avoid parallelism on a works stream (if
> there is any). Of course i would really appreciate if other developers
> are willing to join the team by reviewing, concept critism or
> contributing code at https://github.com/jonasschnelli/bitcoin.
>
> Any forms of criticism and any ideas are highly appreciated.
>
>
> —
> /jonas
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJVyboPAAoJECnUvLZBb1PsgkkQAKySrksCclbfwIsf1L4Jwaxp
> nWmUhlXa3lIoxKG3eYZMPVugFX/LFKtmNqypQJ8whUjF2K5ZwIW1Boosl13cBkE9
> 2EIAMcBrpah0pwzomJ9ViLArl+7t6ksLR5qWJsgJsLnWlaW4c/1KwjGkYTZ6++VC
> 8O3M3HrdwT3fnrK35XJXTIhpFfRKRFrWcW98vMFt9xw7MUq+enhloGF6Nw4UiQbi
> nOV85YleBJEBU5cXuIOznG4EwHH77f8336+GY8d6mLCg7rKj7ZZWqqHztqEQf68Q
> mtwJhag3pxyW2jqb/fCxYD27oPqgMcLT1lyUobpzu7SrlKKmAIikf8uNU1+8rH+W
> U1C1IsWzvoPK7g7mqlmpk1/6kvlJOWNshTATfQS2A/hMB1Oec3zZTCz+P5S5g+F7
> FT4tB2sR2nwGkWNVPNSs92o0f8y55/u+fAFcbmHkkNrfEt4IuMwsqJNW9i7GzU6b
> uOznq4ZgYw5OxUJh8uXLaA1OFIdPTEcTA4nNRSA7v6cRbfWeaCSGzafOYdGQKV2Y
> 5R7VCZJZe8ALzSUr03FsZ5bilcjdJ3ZyeQNikqeYnQLP+qoH6oRhDT0B2GI2E4+4
> EvfIZCmaDxYG0FClWOQiiO0WeW2kNBWyD3tWCpM63ri//OnoN65NDKsbIpJ+oD8m
> OwxleWQP0eC/5knZSFwB
> =7CG9
> -----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/20150811/b14d6491/attachment.html>

2023-06-07 15:43:05

- reply

📅 Original date posted:2015-07-22
📝 Original message:I wouldn't go quite that far. The reality is somewhere in the middle, as
Bryan Cheng noted in this thread:
Quoting BC,
> Upgrading to a version of Bitcoin Core that is incompatible with your
ideals is in no way a forced choice, as you have stated in your email;
forks, alternative clients, or staying on an older version are all valid
choices. If the majority of the network chooses not to endorse a specific
change, then the majority of the network will continue to operate just fine
without it, and properly structured consensus rules will pull the minority
along as well.
The developers *propose* a new version, by publishing a new release. The
individual network nodes choose to accept or reject that.
So I respectfully disagree with "core devs don't control the network" and
"core devs control the network" both.
There are checks-and-balances that make the system work. Consensus is most
strongly measured by user actions after software release. If the
developers fail to reflect user consensus, the network will let us know.
On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Pieter,
>
> I think a core area of disagreement is this:
>
>> Bitcoin Core is not running the Bitcoin economy, and its developers have
>> no authority to set its rules.
>>
> In fact Bitcoin Core is running the Bitcoin economy, and its developers do
> have the authority to set its rules. This is enforced by the reality of
> ~100% market share and limited github commit access.
>
> You may not like this situation, but it is what it is. By refusing to make
> a release with different rules, people who disagree are faced with only two
> options:
>
> 1. Swallow it even if they hate it
> 2. Fork the project and fork the block chain with it (XT)
>
> There are no alternatives. People who object to (2) are inherently
> suggesting (1) is the only acceptable path, which not surprisingly, makes a
> lot of people very angry.
>
> _______________________________________________
> 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/f4c37787/attachment-0001.html>

2023-06-07 15:42:50

- reply

📅 Original date posted:2015-07-22
📝 Original message:On Wed, Jul 22, 2015 at 11:03 AM, Alex Morcos <morcos at gmail.com> wrote:
> 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?
>
There is a vast difference between what software developers have been
chattering about in the background versus what the users actually
experience in the field.
To the user, talk of a fee market is equivalent to talk about block size -
various opinions are tossed about, but it doesn't really impact them. Fees
have been low for 6 years.
We see this with the actual data - no fee pressure on average for the
entirety of bitcoin's history. We see this with the recent stress tests,
which exposed dumb wallet behavior WRT fees. Users -and software- had the
expectation
Remember, this is not a judgement on whether or not fee market/pressure
should exist. It is simply a factual observation that users/market have
not experienced this new economic policy.
That opens the question - *why now?* Why make bitcoin growth more
expensive at this time in its young life? Many smart people would prefer
that bitcoin continue to grow, rather than making the system more expensive
to use right now.
Choosing "let a fee market develop" -- *today* -- is picking economic
sides, picking winners & losers in the market.
This new policy should be debated and consensus achieved, not simply rolled
out by fiat without user notification.
Otherwise it is engaging in precisely the economic wizardry that this
thread opened with decrying.
Just like block size, there are multiple sides to the fee market debate.
However, Bitcoin Core has (unfortunately) outsized decision making power in
that simply avoiding progress on block size limit will achieve the "let a
fee market develop" economic policy change. Ironic but true - sitting
around and doing nothing dumps users into a new economic policy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/bc0495dc/attachment.html>

2023-06-07 15:42:50

- reply

📅 Original date posted:2015-07-22
📝 Original message:Addendum:
Please do not interpret - as many have - my points as advocating against
letting a fee market ever develop(!).
Fees are useful against DoS, increasing cost of attack etc. Further,
continuing the artificially-low fee policy ad infinitum is unsustainable
and constitutes a moral hazard.
Examine from the user's point of view. If you want to develop a fee
market, think it through in the context of user expectation/experience -
which translates to how software is written and users behave, the context
of market disruption, and the context of further block size increases.
Transition to a new economic policy should be planned. It should give
users and markets time to adjust.
It is grossly irresponsible to simply drop users into a new economic policy
with no warning and no preparation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/a2a73eea/attachment.html>

2023-06-07 15:42:49

- reply

📅 Original date posted:2015-07-22
📝 Original message: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/fb24245a/attachment-0001.html>

2023-06-07 15:42:32

- reply

📅 Original date posted:2015-07-22
📝 Original message:On Tue, Jul 21, 2015 at 6:58 AM, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I don't agree with you at all.
>
> This is a case where if Jeff doesn't understand that issue, he's
> proposing changes that he's not competent enough to understand, and it'd
> save us a lot of review effort if he left that discussion. Equally, Jeff
> is in a position in the dev community where he should be that competent;
> if he actually isn't it does a lot of good for the broader community to
> change that opinion.
>
> I personally *don't* think he's doing that, rather I believe he knows
> full well it's a bad patch and is proposing it because he wants to push
> discussion towards a solution. Often trolling the a audience with bad
> patches is an effective way to motivate people to respond by writing
> better ones; Jeff has told me he often does exactly that.
>
>
mmmm kay. Let's try to keep it technical, please.
2MB is a limit that has been discussed as a viable next-step, meeting with
the most consensus.
2MB gets beyond the 1MB hard fork issue, while still remaining within a
safety cap that should ensure the system does not go "off the rails" as
some has predicted.
Security, privacy and centralization are not going to disappear at 2MB.
Further, a limited step gains valuable field data for judging whether
further steps are warranted - thus informing the "better block size
solution" development process.
Finally, as stated in the initial PR, it is intended as a viable fallback
should we reach a point of criticality where the user community feels a
block size increase is warranted, yet cannot reach consensus on a fancy,
all-consuming solution be it 20MB, flexcap, BIP 100, BIP 102, etc.
I am open to suggestions for improving BIP 102. The goal is a minimum
complexity fallback that others have previously agreed was a useful
kick-the-can compromise - a static 2MB cap.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/0b2bf624/attachment.html>

2023-06-07 15:42:28

- reply

📅 Original date posted:2015-07-17
📝 Original message:Opening a mailing list thread on this BIP:
BIP PR: https://github.com/bitcoin/bips/pull/173
Code PR: https://github.com/bitcoin/bitcoin/pull/6451
The general intent of this BIP is as a minimum viable alternative plan to
my preferred proposal (BIP 100).
If agreement is not reached on a more comprehensive solution, then this
solution is at least available and a known quantity. A good backup plan.
Benefits: conservative increase. proves network can upgrade. permits
some added growth, while the community & market gathers data on how an
increased block size impacts privacy, security, centralization, transaction
throughput and other metrics. 2MB seems to be a Least Common Denominator
on an increase.
Costs: requires a hard fork. requires another hard fork down the road.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150717/f81af759/attachment.html>

2023-06-07 15:41:54

- reply

📅 Original date posted:2015-07-11
📝 Original message:It sounds like you are seeking transaction expiration from the mempool, not
CPFP.
On Sat, Jul 11, 2015 at 4:30 PM, Dan Bryant <dkbryant at gmail.com> wrote:
> I think a compromise will be somewhere in the middle. I think most people
> would be OK with TXs that don't have enough fees for P2P transfer to stay
> in deadmans land. Most people are stuck in a situation where they payed
> enough to get it into (and keep it in) the pool, but not enough to get it
> out.
>
> If we could get CPFP that only worked on TXs that met the minimum
> threshold for peer propagation, then I think we would be in much better
> position to battle this spam flood.
>
> On Sat, Jul 11, 2015 at 3:28 PM, Micha Bailey <michabailey at gmail.com>
> wrote:
>
>> Right. The issue (AIUI) is that, right now, even though transactions are
>> evaluated for inclusion as a group with CPFP, they're not yet evaluated for
>> relaying as a unit, nor can they be, because the current p2p protocol
>> doesn't have a way to send multiple transactions in a single protocol
>> message to signify that they should be evaluated together.
>>
>>
>
>
> _______________________________________________
> 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/20150711/3180630b/attachment.html>

2023-06-07 15:41:52

- reply

📅 Original date posted:2015-07-10
📝 Original message: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.
On Fri, Jul 10, 2015 at 12:28 PM, Tier Nolan <tier.nolan at gmail.com> wrote:
>
>
> On Fri, Jul 10, 2015 at 5:09 PM, Richard Moore <me at ricmoo.com> wrote:
>
>> I was also wondering, with CPFP, should the transaction fee be based on
>> total transactions size, or the sum of each transaction’s required fee? For
>> example, a third transaction C whose unconfirmed utxo from transaction B
>> has an unconfirmed utxo in transaction A (all of A’s inputs are confirmed),
>> with each A, B and C being ~300bytes, should C’s transaction fee be 0.0001
>> btc for the ~1kb it is about to commit to the blockchain, or 0.0003 btc for
>> the 3 transactions it is going to commit.
>>
>
> It should be whatever gives the highest fee. In effect, child pays for
> parent creates compound transactions.
>
> A: 250 bytes, 0 fee
> B: 300 bytes: 0.0005 fee
> C: 400 bytes: 0.0001 fee
>
> There are 3 combinations to consider
>
> A: 0 fee for 250 bytes = 0 per byte
> A&B: 0.0005 fee for 550 bytes = 0.91 uBTC per byte
> A&B&C: 0.0006 fee for 950 bytes = 0.63uBTC per byte
>
> This means that the A&B combination has the best fee per byte value. A&B
> should be added to the memory pool (if 0.91 uBTC per byte is above the
> threshold).
>
> Once A&B are added, then C can be reconsidered on its own.
>
> C: 0.0001 for 400 bytes = 0.25 BTC per byte
>
> If that is above the threshold, then C should be added.
>
> In practice, it isn't possible to check every combination. If there are N
> transactions, then checking all triple combinations costs around N cubed.
>
> A 2 pass system could get a reasonably efficient result.
>
> B is 0.0005 fee for 300 bytes = 1.67 uBTC per byte and is assumed to be a
> high value transaction.
>
> The algorithm would be
>
> Pass 1:
> Process all transactions in order of BTC per byte, until block is full
> If the transaction's parents are either already in the pool or a
> previous block, add the transaction.
>
> Pass 1:
> Process all non-included transactions in order of BTC per byte, until
> block is full
> If the transaction's parents are either already in the pool or a
> previous block, add the transaction.
>
> Otherwise, consider the transaction plus all non-included ancestors as
> a single transaction
> If this combined transaction has a higher BTC per byte than the
> lowest transaction(s),
> add the combined transaction
> drop the other transaction(s)
>
>
>
> _______________________________________________
> 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/24c24be6/attachment.html>

2023-06-07 15:41:51

- reply

📅 Original date posted:2015-07-10
📝 Original message:CPFP is interesting, but it does not fully cover the case it is trying to
address: If TX_a goes out without sufficient fee, sending out a new TX_b
will not help TX_a suddenly reach nodes/miners that ignored TX_a.
On Fri, Jul 10, 2015 at 12:09 PM, Richard Moore <me at ricmoo.com> wrote:
> Hey guys,
>
> With all the recent congestion and discussion regarding FSS-RBF, I was
> wondering if there good reasons not to have CPFP as a default policy? Or is
> it?
>
> I was also wondering, with CPFP, should the transaction fee be based on
> total transactions size, or the sum of each transaction’s required fee? For
> example, a third transaction C whose unconfirmed utxo from transaction B
> has an unconfirmed utxo in transaction A (all of A’s inputs are confirmed),
> with each A, B and C being ~300bytes, should C’s transaction fee be 0.0001
> btc for the ~1kb it is about to commit to the blockchain, or 0.0003 btc for
> the 3 transactions it is going to commit.
>
> I tried to test it out a few days ago, sending 0.0008 btc without any fee,
> then that utxo into another transaction w/ 0.0001 btc. It still hasn’t
> confirmed, which could be any of: a) CPFP doesn’t have enough hash power,
> b) the amounts are too small, c) the coins are too new, d) the fee should
> have actually been 0.0002 btc, e) the congestion is just too great; or some
> combination.
>
> Just curious as whatnot…
>
> Thanks,
> RicMoo
>
> .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
>
> Richard Moore ~ Founder
> Genetic Mistakes Software inc.
> phone: (778) 882-6125
> email: ricmoo at geneticmistakes.com
> www: http://GeneticMistakes.com
>
>
> _______________________________________________
> 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/5fb1e521/attachment.html>

2023-06-07 15:41:31

- reply

📅 Original date posted:2015-07-03
📝 Original message:On Fri, Jul 3, 2015 at 1:33 AM, Jeremy Rubin <
jeremy.l.rubin.travel at gmail.com> wrote:
> Moxie looks fantastic! The reason I thought RISC-V was a good selection is
> the very active development community which is pushing the performance of
> the ISA implementations forward. Can you speak to the health of Moxie
> development? Ultimately, ensuring support for many open architectures would
> be preferable. Are there other reasonable open-source processors that you
> are aware of?
>
> I would be willing to work on a design a Bitcoin specific open-hardware
> processor, up to the FPGA bound, if this would be useful for this goal.
>
Moxie was designed to be small and efficient from the compiler standpoint.
As a side effect, it is easy to audit from a security perspective. It
started life as a simulator + gcc compiler backend, and then later became
an FPGA implementation.
Moxie would benefit from focused effort in building out the hardware side
to be efficient on FPGA, developing and testing multi-core support and
related efforts. This area is less mature and could use attention. Start
at https://github.com/atgreen/moxiedev/tree/master/moxie/cores/moxie
In terms of other projects, there are many open source processor cores at
http://opencores.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150703/c7a71728/attachment-0001.html>

2023-06-07 15:41:29

- reply

📅 Original date posted:2015-07-03
📝 Original message:If the freedom to pick architecture exists, Moxie is a nice, compact, easy
to audit alternative:
http://moxielogic.org/blog/pages/architecture.html
https://github.com/jgarzik/moxiebox
Scaling can occur at the core level, rather than hyper-pipelining, keeping
the architecture itself nice and clean and simple.
On Thu, Jul 2, 2015 at 11:13 PM, Jeremy Rubin <
jeremy.l.rubin.travel at gmail.com> wrote:
> Might I suggest that the min-spec, if developed, target the RISC-V Rocket
> architecture (running on FPGA, I suppose) as a reference point for
> performance? This may be much lower performance than desirable, however, it
> means that we don't lock people into using large-vendor chipsets which have
> unknown, or known to be bad, security properties such as Intel AMT.
>
> In general, targeting open hardware seems to me to be more critical than
> performance metrics for the long term health of Bitcoin, however,
> performance is still important.
>
> Does anyone know how the RISC-V FPGA performance stacks up to, say, a
> Raspberry Pi?
>
> On Thu, Jul 2, 2015 at 10:52 PM, Owen Gunden <ogunden at phauna.org> wrote:
>
>> I'm also a user who runs a full node, and I also like this idea. I think
>> Gavin has done some back-of-the-envelope calculations around this stuff,
>> but nothing so clearly defined as what you propose.
>>
>> On 07/02/2015 08:33 AM, Mistr Bigs wrote:
>>
>>> I'm an end user running a full node on an aging laptop.
>>> I think this is a great suggestion! I'd love to know what system
>>> requirements are needed for running Bitcoin Core.
>>>
>>> On Thu, Jul 2, 2015 at 6:04 AM, Jean-Paul Kogelman
>>> <jeanpaulkogelman at me.com <mailto:jeanpaulkogelman at me.com>> wrote:
>>>
>>> I’m a game developer. I write time critical code for a living and
>>> have to deal with memory, CPU, GPU and I/O budgets on a daily basis.
>>> These budgets are based on what we call a minimum specification (of
>>> hardware); min spec for short. In most cases the min spec is based
>>> on entry model machines that are available during launch, and will
>>> give the user an enjoyable experience when playing our games.
>>> Obviously, we can turn on a number of bells and whistles for people
>>> with faster machines, but that’s not the point of this mail.
>>>
>>> The point is, can we define a min spec for Bitcoin Core? The number
>>> one reason for this is: if you know how your changes affect your
>>> available budgets, then the risk of breaking something due to
>>> capacity problems is reduced to practically zero.
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20150702/b79de4df/attachment.html>

2023-06-07 15:41:04

- reply

📅 Original date posted:2015-06-27
📝 Original message:Older nodes have been phased out in the past. For example, protocol
versions older than 209 were phased out.
Follow the yellow brick git trail starting at
18c0fa97d0408a3ee8e4cb39c08156f7667f99ac
On Sat, Jun 27, 2015 at 3:53 PM, Natanael <natanael.l at gmail.com> wrote:
> Old versions of software that can't be sandboxed from the world by design
> must eventually die. The reason is simple - otherwise it will be abused,
> exploited and end up actively countering its own intended purpose. Either
> through security holes or other means of abusing the outdated code's
> behavior.
>
> Full nodes in Bitcoin validate all new transactions against their own
> embedded policies and rules. Eventually the global concensus will agree on
> a change of rules, as the current ruleset isn't perfect - this will toss
> incompatible old full nodes off the greatest-PoW blockchain. This is
> inevitable - not all instances of the software will get updated. Scanning
> the Internet for Internet accessible hardware will reveal tons of outdated
> software versions.
>
> There is however currently no simple way to tell a node that it is
> outdated. Even if you just incremented block versions, it will only lead to
> some kind of alert (IIRC) for some versions. I'm suggesting behaviors that
> would simplify transition to new versions over time with minimal
> disruption.
>
> * Expiration dates. Nodes so old that they are behind by numerous soft
> forks and likely are to be deprecated by a hard fork should switch to SPV
> mode automatically while also alerting the node owner. This behavior
> extends the lifetime while not by itself breaking anything with minimal
> disruption. It also allows node owners which look at the status of their
> nodes but don't think of updating (maybe it is automatically deployed old
> software images) to realize an update is sin necessary. SPV mode also needs
> to have an expiration date before complete node shutdown. Expiration dates
> also minimize risk for political disagreement regarding how and when to
> take any manual action to trigger necessary alerts. 3 years to SPV is a
> reasonable default IMHO, with node shutdown after 5 years. Any other
> suggestions?
>
> * Explicit declaration of block policy / rules in blocks, including miner
> votes for changes, and explicit declaration of incompatibility with old
> versions. Having votes visible in the blocks for implementing changes
> incompatible with the policy and rules your node runs allows it to alert
> the node owner of impending necessity to update. Switching to SPV mode
> again provides for minimal disruption. Please take note that even old SPV
> nodes may eventually be deprecated through data structure changes, this too
> should be declared and then cause alerts and halt / shutdown of those
> nodes.
>
> This also protects against another issue - an old abandoned node will not
> automatically trust a fresh longer chain (likely malicious) using its own
> policy if it remembers an earlier fork voting for change, instead it
> prompts for the node owner to either update (or stick to SPV on the
> new-policy chain) or to accept this fresh fork. Nodes on a chain with its
> own policy seeing a fork with a vote for change should look at the PoW
> first. If it is close, alert the user (he might have brought the node
> online just after the vote finished, to first see the fork that is on his
> old policy), so he can investigate. If the PoW is far behind it may be
> ignored, or simply logged.
>
> Seeing a block also explicitly declare being incompatible with the policy
> a node follows including for SPV nodes, rather than just using version
> numbers, simplifies things too. It ensures the nodes know they can't
> validate the blocks with their old code, which simultaneously ensures that
> behavior changes that doesn't violate the old validation code but yet
> causes incompatibility then will not silently fork the network, instead it
> will let the node owners know their nodes are incompatible with the main
> chain. This allows them to investigate and update of necessary.
>
> ---
>
> The primary reason for me suggesting switching to SPV mode is simple - it
> buys time for everybody. Hard forks no longer become a critical deadline
> for getting the ENTIRE network upgraded - you just need to worry about the
> miners and major players in the short term. Long term you do need
> information campaigns to get SPV fallback nodes updated, but it won't need
> to be rushed. The information campaigns no longer need to be FULLY
> completed BEFORE deployment.
>
> Feedback?
>
> - Sent from my tablet
>
> _______________________________________________
> 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/20150627/7af5b0ef/attachment.html>

2023-06-07 15:41:02

- reply

📅 Original date posted:2015-06-27
📝 Original message:Generally agreed w/ all this.
To preserve digital signatures now and in the future, and make mbox
archives actually useful, a minimum modification policy is needed.
On Sat, Jun 27, 2015 at 3:21 PM, grarpamp <grarpamp at gmail.com> wrote:
> On Sun, Jun 21, 2015 at 9:14 PM, Frank Flores <frankf44 at gmail.com> wrote:
> > If you're going to go through the trouble of signing your public emails
> ...
>
> ... then you should also demand that the official archives of your
> favorite lists preserve them and their verifiability in the supposedly
> canonical reference "mbox" format that they distribute.
>
> On Wed, Jun 24, 2015 at 7:47 AM, Wladimir J. van der Laan
> <laanwj at gmail.com> wrote:
> > Subject: [bitcoin-dev] New GPG signing key for Bitcoin Core binary
> releases
>
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009045.html
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June.txt.gz
>
> As you can clearly see, both the HTML archives and the "mbox"
> archives have corrupted this message, it will not verify. Do not
> try to say this case is trivial, the problem itself is not trivial,
> it's gratuitous, and it applies to all matching messages... text,
> code, binary inline... that's dangerous.
>
> Do not try to say this corruption prevents spam, it does not.
> Spammers simply subscribe to the list and harvest everything
> efficiently in realtime... no webcrawling overhead, no stale
> addresses. Obfuscation is futile.
>
> This misfeature needs to be disabled.
>
>
>
> On Fri, Jun 19, 2015 at 12:57 AM, Warren Togami Jr. <wtogami at gmail.com>
> wrote:
> > archives will be exported
> > and imported into the new list server
>
> On Tue, Jun 23, 2015 at 2:45 PM, Andy Schroder <info at andyschroder.com>
> wrote:
> > I'm not sure if anyone has submitted a request for gmane
>
> On Sun, Jun 21, 2015 at 5:35 PM, s7r <s7r at sky-ip.org> wrote:
> > Do we have all the archives imported? I run several full nodes and
> > mirrors for open source projects, if you think it's useful, I can
> > provide a mirror for the mail list archives.
>
> Yes... these other mirrors, archives, analysis, journalism, and
> interfaces are useful. However, as it is now, there are no useful
> authoritative sources for them to seed from... they're all corrupt.
> And any subscribed realtime sources, though nice, are subject to
> downtime, administrative and other unrecoverable gaps. Your mirror
> project is a fine idea, you should demand that the pristine historical
> sources be made publicly available. Not just for you, but for everyone.
>
>
>
> On Wed, Jun 17, 2015, grarpamp wrote:
> > ...
>
> As before, the current "mbox" archives are broken and not useful...
>
> a) They corrupt message data, messages are unverifiable, another example...
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009132.html
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June.txt.gz
> b) They are missing the minimum set of original headers necessary
> for fully replyable, threadable, sortable, searchable, context
> preserving and direct use by users MUA's in their local environment:
> (Date, From, To, Cc, Subject, Message-ID, In-Reply-To, References)
> c) They do not include attachments (patches, signatures, images, crypto,
> data) that are absolutely necessary to the context and archives
> of all lists. Instead they stupidly throw them away to "web links"
> which results not only in uselessness of the so called "mbox"
> version, but in many thousands of needless fetches by archive
> users and indexers. And hours of wasted work attempting to
> postprocess them into usable form.
> Valuable content lost from the "mbox" files this June alone:
> 418 attachment.html
> 106 attachment.sig
> 6 attachment.jpe
> 4 attachment.png
> 2 attachment.bin
> d) There appear to be at least 15 instances of unescaped '^From '
> in the "mbox". Regeneration with current mailman may fix. One such
> case is here:
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-January/004245.html
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-January.txt.gz
>
>
>
> Please fix all the above mentioned issues by providing the full raw
> archives in regularly updated [gzip/7z] mbox format. The internet
> thanks you :)
>
> Example, compare the "Downloadable version"s here:
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> https://cpunks.org/pipermail/cypherpunks/
> https://cpunks.org/pipermail/cypherpunks/2015-February/006820.html
>
>
>
> On Tue, Jun 23, 2015 at 2:45 PM, Andy Schroder <info at andyschroder.com>
> wrote:
> > Regarding message footers and the subject prefix
>
> Yes, they're also corruptive and space wasting clutter, for and by
> the clueless :( Both of them should be turned off.
> _______________________________________________
> 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/20150627/bfb6410d/attachment-0001.html>

2023-06-07 15:40:30

- reply

📅 Original date posted:2015-06-26
📝 Original message:Failure to plan now for a hard fork increase 6(?) months in the future
produces that lumpy, unpredictable market behavior.
The market has baked in the years-long behavior of low fees. From the
market PoV, inaction does lead to precisely that, a sudden change over the
span of a few months.
At a higher level, people look at bitcoin and see people delaying, waiting,
dawdling until the barn is actually on fire before taking action to put out
the fire.
They see a system that is not responsive to higher level externalities of
people & businesses making plans for the future. Based on current proposal
of change-through-inaction, businesses will simply shelve plans to use
bitcoin and not bother putting those new users on the network.
If you wait until the need to increase block size is acute, it is already
too late. (1) Businesses have permanently shelved plans to use bitcoin and
(2) change at that point produces _larger_ disruption to the fee market.
Hard forks require planning many months in advance. Gavin's timing is
sound, even though the Gavin/Hearn Bitcoin-XT antics were sub-optimal.
On Fri, Jun 26, 2015 at 11:12 AM, 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
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150626/4980bc88/attachment-0001.html>

2023-06-07 15:40:29

- reply

📅 Original date posted:2015-06-26
📝 Original message: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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150626/4d6992ee/attachment.html>

2023-06-07 15:40:27

- reply

📅 Original date posted:2015-06-26
📝 Original message:On Fri, Jun 26, 2015 at 8:24 AM, Pieter Wuille <pieter.wuille at gmail.com>
wrote:
> On Fri, Jun 26, 2015 at 5:22 PM, Milly Bitcoin <milly at bitcoins.info>
> wrote:
>
>> >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...
>>
>> Yes. I think people/businesses want some kind of assurance that there is
>> a path to get things done when needed rather than immediate changes. Since
>> there is currently no clear path/schedule to get any changes accomplished
>> they gets anxious.
>>
>
> I think you just proved my point by saying "when needed".
>
Proposing inaction is not the way you convince people that bitcoin can
scale.
People and businesses cannot perform any capacity planning and future
projections under the proposal of "economic change through inaction."
There will be no growth, by your argument, until there is fee pressure.
And what happens then?
a) Block size limit increases, disrupting and rebooting the fee market.
or
b) You argue that fees have taken care of the capacity.
Waiting until blocks are full before taking action produces even more
disruption and market-unpredictable behavior than today.
I understand you want a fee market to develop, and increasing the block
size limit retards/prevents that. The fact remains that that is a _major_
change to economic policy that creates a _more_ unpredictable system.
Who knows when Pieter will agree that a fee market is healthy? And at that
time, once blocks are full, changing the block size limit then will produce
even more disruption, going from
little pressure -> lots of pressure -> little pressure
Inaction produces fee pressure produces volatility. And makes it more
difficult for system users to perform capacity planning.
I see a lot of microscopic fee analysis - economically insignificant for at
least 12 months to come - and very little holistic analysis from people
arguing that inaction is the best course.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150626/469d8757/attachment-0001.html>

2023-06-07 15:40:14

- reply

📅 Original date posted:2015-06-25
📝 Original message:On Thu, Jun 25, 2015 at 6:41 AM, Eric Lombrozo <elombrozo at gmail.com> wrote:
> Wladimir is doing an amazing job under difficult circumstances. Give the
> guy a break, please
A+ agreed. He is not an elected decider - he is the Bitcoin Core release
manager, and has been doing a damn fine job.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150625/035d6855/attachment.html>

2023-06-07 15:40:05

- reply

📅 Original date posted:2015-06-25
📝 Original message:Ladies & gents, please do not feed the troll. This has been explained to
Milly multiple times in the past, on previous mailing list & github with no
impact.
On Wed, Jun 24, 2015 at 7:34 PM, Milly Bitcoin <milly at bitcoins.info> wrote:
> I'm sorry but that is the kind of defensive, cultish response everyone
> gets when they ask that question. If you had a well constructed documented
> process then you would be able to point to it ... but you can't. While
> there are a few bits and pieces scattered about in different places there
> is no coherent plan or process.
>
> It is easy to make statements like "consensus must be unanimous" but the
> issue is that you never have true 100% consensus yet you have to move
> forward in some fashion and everyone has to run software with the same
> consensus rules. The issue is how you move forward is the question that
> nobody wants to answer because (a) it is a hard question to answer and (b)
> developers see it as a threat to their authority/position. If people just
> keep shutting down the discussion with a bunch of cultish stock answers
> then you are never going to move forward with developing some kind of
> process.
>
> From what I can see much of the discussion is personality-driven and not
> based on Computer Science or and defined process. The issue is that a
> personality has changed so the process is perceived to be different and
> some people want to hard fork. Previously, the cultish answer is that
> Bitcoin development is decentralized because people can fork the code. Now
> that some developers want to fork the code suddenly it is a big problem.
> Is forking the code part of the consensus process or is it the work of the
> devil? The fact that there is so much diverse opinion on this shows a
> defined process has never been fully vetted or understood.
>
> I have worked on these processes for many years for projects orders of
> magnitudes larger than Bitcoin. I can absolutely assure you the current
> mishmash does not scale and huge amounts of time are wasted. That should
> be readily apparent from the recent discussions and the recent concern it
> has caused from people outside the developer's inner circle.
>
> Lack of defined process = high risk and wasted effort.
>
> Russ
>
>
>
>
>
> On 6/24/2015 9:50 PM, Mark Friedenbach 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>
> 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/42b42299/attachment-0001.html>

2023-06-07 15:40:03

- reply

📅 Original date posted:2015-06-24
📝 Original message:BIPs are accepted into BIP repo with a low "reasonable" threshold.
Code is accepted into the Bitcoin Core repo when it is likely that the
community will accept a change.
There is no voting in the way you think. Devs commit changes the users will
accept and use. Users "fire" developers by choosing different devs or
different software.
Standard open source method.
On Jun 24, 2015 4:41 PM, "Raystonn" <raystonn at hotmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150624/5eae6595/attachment-0001.html>

2023-06-07 15:39:49

- reply

📅 Original date posted:2015-06-24
📝 Original message:Miners can collude today to lower the block size limit.
In fact, this largely happens already out of laziness - miners often follow
the "soft" default limit set by Bitcoin Core, to the point where you can
chart when miners upgrade to new software:
http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bitcoin-block
On Tue, Jun 23, 2015 at 8:05 PM, William Madden <will.madden at novauri.com>
wrote:
> Here are refutations of the approach in BIP-100 here:
> http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
>
> To recap BIP-100:
>
> 1) Hard form to remove static 1MB block size limit
> 2) Add new floating block size limit set to 1MB
> 3) Historical 32MB message limit remains
> 4) Hard form on testnet 9/1/2015
> 5) Hard form on main 1/11/2016
> 6) 1MB limit changed via one-way lock in upgrade with a 12,000 block
> threshold by 90% of blocks
> 7) Limit increase or decrease may not exceed 2x in any one step
> 8) Miners vote by encoding 'BV'+BlockSizeRequestValue into coinbase
> scriptSig, e.g. "/BV8000000/" to vote for 8M.
> 9) Votes are evaluated by dropping bottom 20% and top 20%, and then the
> most common floor (minimum) is chosen.
>
> 8MB limits doubling just under every 2 years makes a static value grow
> in a predictable manner.
>
> BIP-100 makes a static value grow (or more importantly potentially
> shrink) in an unpredictable manner based on voting mechanics that are
> untested in this capacity in the bitcoin network. Introducing a highly
> variable and untested dynamic into an already complex system is
> unnecessarily risky.
>
> For example, the largely arbitrary voting rules listed in 9 above can be
> gamed. If I control pools or have affiliates involved in pools that
> mine slightly more than 20% of blocks, I could wait until block sizes
> are 10MB, and then suddenly vote "/BV5000000/" for 20% of blocks and
> "/BV5000001/" for the remaining 10%. If others don't consistently vote
> for the same "/BV#/" value, vote too consistently and have their value
> thrown out as the top 20%, I could win the resize to half capacity
> "/BV5000001/" because it was the lowest repeated value not in the bottom
> 20%.
>
> I could use this to force an exodus to my sidechain/alt coin, or to
> choke out the bitcoin network. A first improvement would be to only let
> BIP-100 raise the cap and not lower it, but if I can think of a
> vulnerability off the top of my head, there will be others on the other
> side of the equation that have not been thought of. Why bother
> introducing a rube goldberg machine like voting when a simple 8mb cap
> with predictable growth gets the job done, potentially permanently?
>
>
> On 6/23/2015 9:43 PM, odinn wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > 1) Hard fork not (necessarily) needed
> > 2) See Garzik's BIP 100, better (this is not meant to say "superior to
> > your stuff," but rather simply to say, "Better you should work with
> > Garzik to implement BIP-100, that would be good")
> > 3) See points 1 and 2 above
> > 4) If still reading... changes should be (as you seem to have been
> > trying to lean towards)... lean towards gradual change; hence, changes
> > that would flow from this BIP would be better off oriented in a
> > process that dies not require the "way you have done it."
> >
> > You did address that, to be fair - in your TODO, this link:
> > http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
> >
> > contained the following link:
> >
> > http://gavinandresen.ninja/bigger-blocks-another-way
> >
> > However, in reading that, I didn't see any meaningful statements that
> > would refute the approach in Garzik's BIP-100.
> >
> > Maybe a better way to say this is,
> >
> > Work with Jeff Garzik (which I am sure you are already having such
> > discussions in private) as well as the list discussions,
> > Move forward on BIP-100 with Garzik and other developers (not such a
> > bad plan really) and don't get caught up in XT. (If you feel you can
> > develop XT further, that is your thing but it would perhaps make you
> > lose focus, work together with other developers.)
> >
> > Relax into the process. Things will be ok.
> >
> > Respectfully,
> >
> > - -O
> >
> > On 06/22/2015 11:18 AM, Gavin Andresen wrote:
> >> I promised to write a BIP after I'd implemented
> >> increase-the-maximum-block-size code, so here it is. It also lives
> >> at:
> >> https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki
> >>
> >> I don't expect any proposal to please everybody; there are
> >> unavoidable tradeoffs to increasing the maximum block size. I
> >> prioritize implementation simplicity -- it is hard to write
> >> consensus-critical code, so simpler is better.
> >>
> >>
> >>
> >>
> >> BIP: ?? Title: Increase Maximum Block Size Author: Gavin Andresen
> >> <gavinandresen at gmail.com <mailto:gavinandresen at gmail.com>> Status:
> >> Draft Type: Standards Track Created: 2015-06-22
> >>
> >> ==Abstract==
> >>
> >> This BIP proposes replacing the fixed one megabyte maximum block
> >> size with a maximum size that grows over time at a predictable
> >> rate.
> >>
> >> ==Motivation==
> >>
> >> Transaction volume on the Bitcoin network has been growing, and
> >> will soon reach the one-megabyte-every-ten-minutes limit imposed by
> >> the one megabyte maximum block size. Increasing the maximum size
> >> reduces the impact of that limit on Bitcoin adoption and growth.
> >>
> >> ==Specification==
> >>
> >> After deployment on the network (see the Deployment section for
> >> details), the maximum allowed size of a block on the main network
> >> shall be calculated based on the timestamp in the block header.
> >>
> >> The maximum size shall be 8,000,000 bytes at a timestamp of
> >> 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double
> >> every 63,072,000 seconds (two years, ignoring leap years), until
> >> 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of
> >> blocks in between doublings will increase linearly based on the
> >> block's timestamp. The maximum size of blocks after 2036-01-06
> >> 00:00:00 UTC shall be 8,192,000,000 bytes.
> >>
> >> Expressed in pseudo-code, using integer math:
> >>
> >> function max_block_size(block_timestamp):
> >>
> >> time_start = 1452470400 time_double = 60*60*24*365*2 size_start =
> >> 8000000 if block_timestamp >= time_start+time_double*10 return
> >> size_start * 2^10
> >>
> >> // Piecewise-linear-between-doublings growth: time_delta =
> >> block_timestamp - t_start doublings = time_delta / time_double
> >> remainder = time_delta % time_double interpolate = (size_start *
> >> 2^doublings * remainder) / time_double max_size = size_start *
> >> 2^doublings + interpolate
> >>
> >> return max_size
> >>
> >> ==Deployment==
> >>
> >> Deployment shall be controlled by hash-power supermajority vote
> >> (similar to the technique used in BIP34), but the earliest possible
> >> activation time is 2016-01-11 00:00:00 UTC.
> >>
> >> Activation is achieved when 750 of 1,000 consecutive blocks in the
> >> best chain have a version number with bits 3 and 14 set (0x20000004
> >> in hex). The activation time will be the timestamp of the 750'th
> >> block plus a two week (1,209,600 second) grace period to give any
> >> remaining miners or services time to upgrade to support larger
> >> blocks. If a supermajority is achieved more than two weeks before
> >> 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11
> >> 00:00:00 UTC.
> >>
> >> Block version numbers are used only for activation; once activation
> >> is achieved, the maximum block size shall be as described in the
> >> specification section, regardless of the version number of the
> >> block.
> >>
> >>
> >> ==Rationale==
> >>
> >> The initial size of 8,000,000 bytes was chosen after testing the
> >> current reference implementation code with larger block sizes and
> >> receiving feedback from miners stuck behind bandwidth-constrained
> >> networks (in particular, Chinese miners behind the Great Firewall
> >> of China).
> >>
> >> The doubling interval was chosen based on long-term growth trends
> >> for CPU power, storage, and Internet bandwidth. The 20-year limit
> >> was chosen because exponential growth cannot continue forever.
> >>
> >> Calculations are based on timestamps and not blockchain height
> >> because a timestamp is part of every block's header. This allows
> >> implementations to know a block's maximum size after they have
> >> downloaded it's header, but before downloading any transactions.
> >>
> >> The deployment plan is taken from Jeff Garzik's proposed BIP100
> >> block size increase, and is designed to give miners, merchants,
> >> and full-node-running-end-users sufficient time to upgrade to
> >> software that supports bigger blocks. A 75% supermajority was
> >> chosen so that one large mining pool does not have effective veto
> >> power over a blocksize increase. The version number scheme is
> >> designed to be compatible with Pieter's Wuille's proposed "Version
> >> bits" BIP.
> >>
> >> TODO: summarize objections/arguments from
> >> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks.
> >>
> >> TODO: describe other proposals and their advantages/disadvantages
> >> over this proposal.
> >>
> >>
> >> ==Compatibility==
> >>
> >> This is a hard-forking change to the Bitcoin protocol; anybody
> >> running code that fully validates blocks must upgrade before the
> >> activation time or they will risk rejecting a chain containing
> >> larger-than-one-megabyte blocks.
> >>
> >> Simplified Payment Verification software is not affected, unless
> >> it makes assumptions about the maximum depth of a transaction's
> >> merkle branch based on the minimum size of a transaction and the
> >> maximum block size.
> >>
> >> ==Implementation==
> >>
> >> https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork
> >>
> >>
> >>
> >> _______________________________________________ bitcoin-dev mailing
> >> list bitcoin-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >
> > - --
> > http://abis.io ~
> > "a protocol concept to enable decentralization
> > and expansion of a giving economy, and a new social good"
> > https://keybase.io/odinn
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1
> >
> > iQEcBAEBAgAGBQJVigtJAAoJEGxwq/inSG8CqZwIAIG3ZQzekfccPxBOMqtim175
> > Crov6hrO9FaIzbLljECpUi60RKuDM/fs09ZJsKKIaJPkB5dlJjs4huc206veAIO+
> > K2h3DmAcA6W/Thk0C2cV3ewv+OiELDOhpeoddBBLPadAfaBGr4l9ltqWLdBtMCmw
> > OtmiWstEuXTao9ApgoFOmybdmCjbfrfhejOOHs/pMiSn5xVE60RK4x2HFTFsHfAN
> > fZAeLCuwuN2qWMrVrr+cbpCXjEuE1xZG3WEj7ppYoGR+AgF/Y5/U1j7S4PVpk85s
> > CgMkpcWvLnBMmSCrllnRZy1Gfrwk36Pg0rXD/l/NNd0/KTpmPSvkX/bCyzFwbzo=
> > =ft62
> > -----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/20150623/a3e483fb/attachment-0001.html>

2023-06-07 15:39:16

- reply

📅 Original date posted:2015-06-19
📝 Original message:This is very disappointing. "scorched earth" replace-by-fee implemented
first at a pool, without updating wallets and merchants, is very
anti-social and increases the ability to perform Finney attacks and
double-spends.
The community is progressing more towards a safer replace-by-fee model, as
indicated by the following code change:
https://github.com/bitcoin/bitcoin/pull/6176
On Fri, Jun 19, 2015 at 3:39 AM, Peter Todd <pete at petertodd.org> wrote:
> Yesterday F2Pool, currently the largest pool with 21% of the hashing
> power, enabled full replace-by-fee (RBF) support after discussions with
> me. This means that transactions that F2Pool has will be replaced if a
> conflicting transaction pays a higher fee. There are no requirements for
> the replacement transaction to pay addresses that were paid by the
> previous transaction.
>
>
> I'm a user. What does this mean for me?
> ---------------------------------------
>
> In the short term, very little. Wallet software aimed at average users
> has no ability to reliably detect conditions where an unconfirmed
> transaction may be double-spent by the sender. For example, Schildbach's
> Bitcoin Wallet for Android doesn't even detect double-spends of
> unconfirmed transactions when connected to a RBF or Bitcoin XT nodes
> that propagate them. The least sophisticated double-spend attack
> possibly - simply broadcasting two conflicting transactions at the same
> time - has about 50% probability of success against these wallets.
>
> Additionally, SPV wallets based on bitcoinj can't even detect invalid
> transactions reliably, instead trusting the full node(s) it is connected
> too over the unauthenticated, unencrypted, P2P protocol to do validation
> for them. For instance due to a unfixed bug¹ Bitcoin XT nodes will relay
> double-spends that spend the output of the conflicting transaction. I've
> personally tested this with Schildbach's Bitcoin Wallet for Android,
> which shows such invalid transactions as standard, unconfirmed,
> transactions.
>
> Users should continue to assume that unconfirmed transactions could be
> trivially reversed by the sender until the first confirmation. In
> general, only the sender can reverse a transaction, so if you do trust
> the sender feel free to assume an unconfirmed transaction will
> eventually confirm. However, if you do not trust the sender and/or have
> no other recourse if they double-spend you, wait until at least the
> first confirmation before assuming the transaction will go through.
>
> In the long term, miner support of full RBF has a number of advantages
> to users, allowing you to more efficiently make transactions, paying
> lower fees. However you'll need a wallet supporting these features; none
> exist yet.
>
>
> I'm a business. What does this mean for me?
> -------------------------------------------
>
> If you use your own node to verify transactions, you probably are in a
> similar situation as average users, so again, this means very little to
> you.
>
> If you use a payment processor/transaction API such as BitPay, Coinbase,
> BlockCypher, etc. you may or may not be accepting unconfirmed
> transactions, and they may or may not be "guaranteed" by your payment
> processor even if double-spent. If like most merchants you're using the
> API such that confirmations are required prior to accepting orders (e.g.
> taking a meaningful loss such as shipping a product if the tx is
> reversed) nothing changes for you. If not I recommend you contact your
> payment processor.
>
>
> I'm a miner. Why should I support replace-by-fee?
> -------------------------------------------------
>
> Whether full or first-seen-safe⁵ RBF support (along with
> child-pays-for-parent) is an important step towards a fully functioning
> transaction fee market that doesn't lead to users' transactions getting
> mysteriously "stuck", particularly during network flooding
> events/attacks. A better functioning fee market will help reduce
> pressure to increase the blocksize, particularly from the users creating
> the most valuable transactions.
>
> Full RBF also helps make use of the limited blockchain space more
> efficiently, with up to 90%+ transaction size savings possible in some
> transaction patterns. (e.g. long payment chains⁶) More users in less
> blockchain space will lead to higher overall fees per block.
>
> Finally as we'll discuss below full RBF prevents a number of serious
> threats to the existing level playing field that miners operate in.
>
>
> Why can't we make accepting unconfirmed txs from untrusted people safe?
> -----------------------------------------------------------------------
>
> For a decentralized wallet, the situation is pretty bleak. These wallets
> only have a handful of connections to the network, with no way of
> knowing if those connections give an accurate view of what transactions
> miners actually know about.
>
> The only serious attempt to fix this problem for decentralized wallets
> that has been actually deployed is Andresen/Harding's double-spend
> relaying, implemented in Bitcoin XT. It relays up to one double-spend
> transaction per double-spent txout, with the intended effect to warn
> recipients. In practice however this functionality makes it easier to
> double-spend rather than harder, by giving an efficient and easy way to
> get double-spends to miners after the fact. Notably my RBF
> implementation even connects to Bitcoin XT nodes, reserving a % of all
> incoming and outgoing connection slots for them.
>
> Additionally Bitcoin XT's double-spend relaying is subject to attacks
> include bandwidth exhaustion, sybil attacks, and Gervais's non-sybil
> interactive attacks⁷ among many others.
>
>
> What about centralised wallets?
> -------------------------------
>
> Here the solutions being deployed, planned, and proposed are harmful,
> and even represent serious threats to Bitcoin's decentralization.
>
>
> Confidence factors
> ------------------
>
> Many services such as BlockCypher² have attempted to predict the
> probability that unconfirmed transactions will be mined, often
> guaranteeing merchants payment³ even in the event of a double-spend. The
> key component of these predictions is to sybil attack the P2P network as
> a whole, connecting to as many nodes as possible to measure transaction
> propagation. Additionally these services connect to pools directly via
> the getblocktemplate protocol, repeatedly downloading via GBT the lists
> of transactions in the to-be-mined blocks to determine what transactions
> miners are attempting to mine.
>
> None of these measures scale, wasting significant network and miner
> resources; in one instance a sybil attack by Chainalysis even completely
> blocked the users of the SPV wallet Breadwallet⁴ from accessing the
> network. These measures also don't work very well, giving double-spend
> attackers incentives to sybil attack miners themselves.
>
>
> Transaction processing contracts with miners
> --------------------------------------------
>
> The next step after measuring propagation fails is to contract with
> miners directly, signing contracts with as much of the hashing power as
> possible to get the transactions they want mined and double-spends
> rejected. The miners/pools would then provide an authenticated API
> endpoint for exclusive use of this service that would allow the service
> to add and remove specific transactions to the mempool on demand.
>
> There's a number of serious problems with this:
>
> 1) Mining contracts can be used to double-spend
>
> ...even when they're being used "honestly".
>
> Suppose Alice is a merchant using CoinPayCypher, who has contracts with
> 75% of the hashing power. Bob, another merchant, meanwhile uses a
> decentralized Bitcoin Core backend for payments to his website.
>
> Mallory wants to double-spend Bob's to buy his expensive products. He
> can do this by creating a transaction, tx1, that pays Alice, followed by
> a second transaction, tx2, that pays Bob. In any circumstance when
> Mallory can convince Bob to accept tx2, but prevent Bob from seeing tx1,
> the chance of Malory's double-spend succeeding becomes ~75% because
> CoinPayCypher's contracts with mining ensure the transaction paying
> Alice will get mined.
>
> Of course, dishonest use and/or compromise makes double-spending
> trivial: Malory can use the API credentials to ask miners to reject
> Bob's payment at any time.
>
>
> 2) They still don't work, without 51% attacking other miners
>
> Even if CoinPayCypher has 75% of the hashing power on contract, that's
> still a potentially 75% chance of being double-spent. The 25% of miners
> who haven't signed contracts have no _decentralized_ way of ensuring
> they don't create blocks with double-spends, let alone at low cost. If
> those miners won't or can't sign contracts with CoinPayCypher the only
> next step available is to reject their blocks entirely.
>
>
> 3) Legal contracts give the advantage to non-anonymous miners in
> Western jurisdictions
>
> Suppose CoinPayCypher is a US company, and you're a miner with 1%
> hashing power located in northern China. The barriers to you succesfully
> negotiating a contract with CoinPayCypher are significant. You don't
> speak the same langauge, you're in a completely different jurisdiction
> so enforcing the legal contract is difficult, and being just 1%,
> CoinPayCypher sees you as insignificant.
>
> Who's going to get the profitable hashing power contracts first, if at
> all? Your English speaking competitors in the west. This is inherently a
> pressure towards centralization of mining.
>
>
> Why isn't this being announced on the bitcoin-security list first?
> ------------------------------------------------------------------
>
> I've had repeated discussions with services vulnerable to double-spends;
> they have been made well aware of the risk they're taking. If they've
> followed my own and others' advice they'll at minimum have constant
> monitoring of the rate of double-spends both on their own services and
> on the P2P network in general.
>
> If you choose to take a risk you should accept the consequences.
>
>
> How do I actually use full RBF?
> -------------------------------
>
> First get the full-RBF patch to v0.10.2:
>
> https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.2
>
> The above implementation of RBF includes additional code to find and
> preferentially connect to other RBF nodes, as well as Bitcoin XT nodes.
> Secondly, try out my replace-by-fee-tools at:
>
> https://github.com/petertodd/replace-by-fee-tools
>
> You can watch double-spends on the network here:
>
> http://respends.thinlink.com/
>
>
> References
> ----------
>
> 1) "Replace-by-fee v0.10.2 - Serious DoS attack fixed! - Also novel
> variants of existing attacks w/ Bitcoin XT and Android Bitcoin Wallet",
> Peter Todd, May 23rd 2015, Bitcoin-development mailing list,
>
> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07795.html
>
> 2) "From Zero to Hero: Bitcoin Transactions in 8 Seconds",
> June 2nd, 2014, Erik Voorhees,
>
> https://medium.com/blockcypher-blog/from-zero-to-hero-bitcoin-transactions-in-8-seconds-7c9edcb3b734
>
> 3) Coinbase Merchant API, Accessed Jun 19th 2015,
> https://developers.coinbase.com/docs/merchants/callbacks#confirmations
>
> 4) "Chainalysis CEO Denies 'Sybil Attack' on Bitcoin's Network",
> March 14th 2015, Grace Caffyn, Coindesk,
>
> http://www.coindesk.com/chainalysis-ceo-denies-launching-sybil-attack-on-bitcoin-network/
>
> 5) "First-Seen-Safe Replace-by-Fee",
> May 25th 2015, Peter Todd, Bitcoin-development mailing list,
>
> http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07829.html
>
> 6) "Cost savings by using replace-by-fee, 30-90%",
> May 25th 2015, Peter Todd, Bitcoin-development mailing list,
>
> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07813.html
>
> 7) "Tampering with the Delivery of Blocks and Transactions in Bitcoin",
> Arthur Gervais and Hubert Ritzdorf and Ghassan O. Karame and Srdjan
> Capkun,
> Cryptology ePrint Archive: Report 2015/578, Jun 10th 2015,
> http://eprint.iacr.org/2015/578
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000070a2bb3b92c20d5c2c971e6e1a7abe55cdbbe6a2dd9a5ad
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/f1279cf6/attachment.html>

2023-06-07 15:39:14

- reply

📅 Original date posted:2015-06-19
📝 Original message:On Fri, Jun 19, 2015 at 10:48 AM, <justusranvier at riseup.net> wrote:
> On 2015-06-19 17:40, Jeff Garzik wrote:
>
>> Making multiple incompatible versions of a spend is a -requirement- of
>> various refund contract protocols.
>>
>
> Is there not a dedicated field in a transaction (nSequence) for express
> purpose of indicating when a protocol like this is in use?
>
No. You cannot know which is the 'right' or wrong transaction. One tx has
obvious nSequence adjustments, the other - the refund transaction - may not.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/260466f9/attachment.html>

2023-06-07 15:39:13

- reply

📅 Original date posted:2015-06-21
📝 Original message:On Sun, Jun 21, 2015 at 12:42 AM, Eric Lombrozo <elombrozo at gmail.com> wrote:
> Thanks for asking *the* question, Jeff. We often get caught up in these
> philosophical debates…but at the end of the day we need something concrete.
>
> Even more important than the specific software you’re using is the
> security policy.
>
> If you must accept zero confirmation transactions, there are a few
> concrete things you can do to reduce your exposure:
>
> 1) limit the transaction amounts for zero confirmation transactions - do
> not accept them for very high priced goods…especially if they require
> physical shipping.
> 2) limit the total amount of unconfirmed revenue you’ll tolerate at any
> given moment - if the amount is exceeded, require confirmations.
> 3) give merchants of subscription services (i.e. servers, hosting, etc…)
> the ability to shut the user out if a double-spend is detected.
>
Already done -- BitPay merchants choose their level of transaction
security. Level of confirmations is directly exposed to merchants, so that
they choose the level of risk for themselves.
Physically shipped orders and subscriptions are actually the easy cases and
are already handled. These can accept 0-conf for an initial order phase,
then have the luxury of time to wait for confirmations before shipping /
canceling a subscription.
Electronic goods instantly delivered are the toughest use case. Even
there, merchants choose their level of risk.
> 4) collect legal information on purchasers (or have the merchants collect
> this information) so you have someone to go after if they try to screw you
>
The system requests this information on orders yes. Merchants also collect
this info as their needs dictate.
> 5) create a risk profile for users…and flag suspicious behavior (i.e.
> someone trying to purchase a bunch of stuff that totally doesn’t fit into
> their purchasing habits).
> 6) get insurance (although right now reasonably-priced insurance is
> probably pretty hard to obtain since statistics are generally of little
> use…we’re entering uncharted territory).
> 7) set up a warning system and a “panic” button so that if you start to
> see an attack you can immediately disable all zero confirmation
> transactions system-wide.
> 8) independently verify all inbound transactions and connect to multiple
> network nodes…check them against one another.
>
Definitely looking at or have implemented this sort of stuff. I cannot get
into detail in public...
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150621/8d925c35/attachment.html>

2023-06-07 15:39:13

- reply

📅 Original date posted:2015-06-19
📝 Original message:On Fri, Jun 19, 2015 at 9:44 AM, <justusranvier at riseup.net> wrote:
> If we have ECDSA proof that an entity intentionally made and publicly
> announced incompatible promises regarding the disposition of particular
> Bitcoins under their control, then why shouldn't that be assumed to be a
> fraud attempt unless shown otherwise?
>
Making multiple incompatible versions of a spend is a -requirement- of
various refund contract protocols.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/a49350a3/attachment.html>

2023-06-07 15:39:11

- reply

📅 Original date posted:2015-06-21
📝 Original message:On Sat, Jun 20, 2015 at 5:54 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
> but we NEED to be applying some kind of pressure on the merchant end to
> upgrade their stuff to be more resilient
>
Can you be specific? What precise technical steps would you have BitPay
and Coinbase do? We upgrade our stuff to... what exactly?
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150620/97d71b05/attachment.html>

2023-06-07 15:39:06

- reply

📅 Original date posted:2015-06-19
📝 Original message:On Fri, Jun 19, 2015 at 6:44 AM, Peter Todd <pete at petertodd.org> wrote:
> Having said that... honestly, zeroconf is pretty broken already. Only
> with pretty heroic measures like connecting to a significant fraction of
> the Bitcoin network at once, as well as connecting to getblocktemplate
> supporting miners to figure out what transactions are being mined, are
> services having any hope of avoiding getting ripped off. For the average
> user their wallets do a terrible job of showing whether or not an
>
This is no excuse for further degrading the overall network security.
There are many issues to address in the bitcoin ecosystem. It negatively
impacts users to roll out "scorched earth" replace-by-fee given today's
ecosystem.
Yes, zero conf security is poor. An outright attack on zero conf degrades
user security even more.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/5bb9893d/attachment.html>

2023-06-07 15:39:05

- reply

📅 Original date posted:2015-06-19
📝 Original message:Yes, FSS RBF is far better.
On Fri, Jun 19, 2015 at 6:52 AM, Chun Wang <1240902 at gmail.com> wrote:
> Before F2Pool's launch, I performed probably the only successful
> bitcoin double spend in the March 2013 fork without any mining power.
> [ https://bitcointalk.org/index.php?topic=152348.0 ] I know how bad
> the full RBF is. We are going to switch to FSS RBF in a few hours.
> Sorry.
>
> On Fri, Jun 19, 2015 at 9:44 PM, Peter Todd <pete at petertodd.org> wrote:
> > On Fri, Jun 19, 2015 at 09:33:05AM -0400, Stephen Morse wrote:
> >> It is disappointing that F2Pool would enable full RBF when the safe
> >> alternative, first-seen-safe RBF, is also available, especially since
> the
> >> fees they would gain by supporting full RBF over FSS RBF would likely be
> >> negligible. Did they consider using FSS RBF instead?
> >
> > Specifically the following is what I told them:
> >
> >> We are
> >> interested in the replace-by-fee patch, but I am not following the
> >> development closely, more background info is needed, like what the
> >> difference between standard and zeroconf versions? Thanks.
> >
> > Great!
> >
> > Basically both let you replace one transaction with another that pays a
> > higher fee. First-seen-safe replace-by-fee adds the additional criteria
> > that all outputs of the old transaction still need to be paid by the new
> > transaction, with >= as many Bitcoins. Basically, it makes sure that if
> > someone was paid by tx1, then tx2 will still pay them.
> >
> > I've written about how wallets can use RBF and FSS-RBF to more
> > efficiently use the blockchain on the bitcoin-development mailing list:
> >
> >
> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07813.html
> >
> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07829.html
> >
> > Basically, for the purpose of increasing fees, RBF is something like %50
> > cheaper than CPFP, and FSS-RBF is something like %25 cheaper.
> >
> > In addition, for ease of implementation, my new FSS-RBF has a number of
> > other restrictions. For instance, you can't replace multiple
> > transactions with one, you can't replace a transaction whose outputs
> > have already been spent, you can't replace a transaction with one that
> > spends additional unconfirmed inputs, etc. These restrictions aren't
> > "set in stone", but they do make the code simpler and less likely to
> > have bugs.
> >
> > In comparison my previous standard RBF patch can replace multiple
> > transactions with one, can replace long chains of transactions, etc.
> > It's willing to do more computation before deciding if a transaction
> > should be replaced, with more complex logic; it probably has a higher
> > chance of having a bug or DoS attack.
> >
> > You've probably seen the huge controversy around zeroconf with regard to
> > standard replace-by-fee. While FSS RBF doesn't make zeroconf any safer,
> > it also doesn't make it any more dangerous, so politically with regard
> > to zeroconf it makes no difference. You *can* still use it doublespend
> > by taking advantage of how different transactions are accepted
> > differently, but that's true of *every* change we've ever made to
> > Bitcoin Core - by upgrading to v0.10 from v0.9 you've also "broken"
> > zeroconf in the same way.
> >
> >
> > Having said that... honestly, zeroconf is pretty broken already. Only
> > with pretty heroic measures like connecting to a significant fraction of
> > the Bitcoin network at once, as well as connecting to getblocktemplate
> > supporting miners to figure out what transactions are being mined, are
> > services having any hope of avoiding getting ripped off. For the average
> > user their wallets do a terrible job of showing whether or not an
> > unconfirmed transaction will go through. For example, Schildbach's
> > Bitcoin wallet for Android has no code at all to detect double-spends
> > until they get mined, and I've been able to trick it into showing
> > completely invalid transactions. In fact, currently Bitcoin XT will
> > relay invalid transactions that are doublepsends, and Schildbach's
> > wallet displays them as valid, unconfirmed, payments. It's really no
> > surprise to me that nearly no-one in the Bitcoin ecosystem accepts
> > unconfirmed transactions without some kind of protection that doesn't
> > rely on first-seen-safe mempool behavior. For instance, many ATM's these
> > days know who their customers are due to AML requirements, so while you
> > can deposit Bitcoins and get your funds instantly, the protection for
> > the ATM operator is that they can go to the police if you rip them off;
> > I've spoken to ATM operators who didn't do this who've lost hundreds or
> > even thousands of dollars before giving up on zeroconf.
> >
> > My big worry with zeroconf is a service like Coinbase or Shapeshift
> > coming to rely on it, and then attempting to secure it by gaining
> > control of a majority of hashing power. For instance, if Coinbase had
> > contracts with 80% of the Bitcoin hashing power to guarantee their
> > transactions would get mined, but 20% of the hashing power didn't sign
> > up, then the only way to guarantee their transactions could be for the
> > 80% to not build on blocks containing doublespends by the 20%. There's
> > no way in a decentralized network to come to consensus about what
> > transactions are or are not valid without mining itself, so you could
> > end up in a situation where unless you're part of one of the big pools
> > you can't reliably mine at all because your blocks may get rejected for
> > containing doublespends.
> >
> > One of my goal with standard replace-by-fee is to prevent this scenario
> > by forcing merchants and others to implement ways of accepting zeroconf
> > transactions safely that work in a decentralized environment regardless
> > of what miners do; we have a stronger and safer Bitcoin ecosystem if
> > we're relying on math rather than trust to secure our zeroconf
> > transactions. We're also being more honest to users, who right now often
> > have the very wrong impression that unconfirmed transactions are safe to
> > accept - this does get people ripped off all too often!
> >
> >
> > Anyway, sorry for the rant! FWIW I updated my FSS-RBF patch and am
> > waiting to get some feedback:
> >
> > https://github.com/bitcoin/bitcoin/pull/6176
> >
> > Suhas Daftuar did find a pretty serious bug in it, now fixed. I'm
> > working on porting it to v0.10.2, and once that's done I'm going to put
> > up a bounty for anyone who can find a DoS attack in the patch. If no-one
> > claims the bounty after a week or two I think I'll start feeling
> > confident about using it in production.
> >
> >
> > --
> > 'peter'[:-1]@petertodd.org
> > 000000000000000003188926be14e5fbe2f8f9c63c9fb8e2ba4b14ab04f1c9ab
> >
> >
> ------------------------------------------------------------------------------
> >
> > _______________________________________________
> > 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
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/2897fe9a/attachment.html>

2023-06-07 15:38:58

- reply

📅 Original date posted:2015-06-19
📝 Original message:Double spend detection is by definition best-effort.
The purpose of bitcoin is to provide security (confirmations) to otherwise
insecure, possibly double spent transactions.
On Fri, Jun 19, 2015 at 2:05 PM, Frank Flores <frankf44 at gmail.com> wrote:
> Has anyone from Mycelium weighed in on this? Is their doublespend attack
> detection broken with this kind of irresponsible behavior?
>
> On Fri, Jun 19, 2015 at 3:39 PM, Matt Whitlock <bip at mattwhitlock.name>
> wrote:
>
>> On Friday, 19 June 2015, at 9:18 am, Adrian Macneil wrote:
>> > If full-RBF sees any significant adoption by miners, then it will
>> actively
>> > harm bitcoin adoption by reducing or removing the ability for online or
>> POS
>> > merchants to accept bitcoin payments at all.
>>
>> Retail POS merchants probably should not be accepting vanilla Bitcoin
>> payments, as Bitcoin alone does not (and cannot) guarantee the
>> irreversibility of a transaction until it has been buried several blocks
>> deep in the chain. Retail merchants should be requiring a co-signature from
>> a mutually trusted co-signer that vows never to sign a double-spend. The
>> reason we don't yet see such technology permeating the ecosystem is
>> because, to date, zero-conf transactions have been irreversible "enough,"
>> but this has only been a happy accident; it was never promised, and it
>> should not be relied upon.
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> --
> *MONEY IS OVER!*
> IF YOU WANT IT
> <http://www.zeitgeistmovie.com/>
> =====================================================
> The causes of my servitude can be traced to the tyranny of money.
> -Serj Tankian
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/a36b7617/attachment.html>