<unnamed>

Public Key

npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58

Profile Code

nprofile1qqstyhssufw5wrvmy92jrdgd5r070gsfhmrlah448psv8cvqllwgcygpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dstlnrpl

Publishing to

relay.damus.io

nos.lol

Last Notes

2023-06-07 19:46:50 CEST

- 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 19:46:49 CEST

- 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 19:46:32 CEST

- 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 19:46:31 CEST

- 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 19:46:29 CEST

- 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 19:46:20 CEST

- 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 19:46:19 CEST

- 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 19:43:53 CEST

- 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 19:43:51 CEST

- 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 19:41:58 CEST

- 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 19:41:40 CEST

- 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 19:40:26 CEST

- 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 19:40:16 CEST

- 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 19:40:15 CEST

- 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 19:39:25 CEST

- 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 19:39:24 CEST

- 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 19:39:22 CEST

- 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 19:39:20 CEST

- 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 19:39:18 CEST

- 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 19:39:16 CEST

- 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 19:37:37 CEST

- 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 19:35:40 CEST

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

2023-06-07 17:49:02 CEST

- 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:47:24 CEST

- reply

2023-06-07 17:43:05 CEST

- 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 17:42:50 CEST

- 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 17:42:50 CEST

- 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 17:42:49 CEST

- 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 17:42:32 CEST

- 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 17:42:28 CEST

- 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 17:41:52 CEST

- 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 17:41:51 CEST

- 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 17:40:30 CEST

- 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 17:40:29 CEST

- 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 17:40:27 CEST

- 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 17:40:14 CEST

- 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 17:40:05 CEST

- 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 17:40:03 CEST

- 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 17:39:49 CEST

- 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 17:39:14 CEST

- 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 17:39:13 CEST

- 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 17:39:13 CEST

- 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 17:39:05 CEST

- 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/[email protected]/msg07813.html
> >
> http://www.mail-archive.com/[email protected]/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 17:38:58 CEST

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

2023-06-07 17:38:31 CEST

- reply

📅 Original date posted:2015-06-18
📝 Original message:On Thu, Jun 18, 2015 at 8:29 AM, Pieter Wuille <pieter.wuille at gmail.com>
wrote:
> On Thu, Jun 18, 2015 at 1:14 PM, Wladimir J. van der Laan <
> laanwj at gmail.com> wrote:
>
>> Like in any open source project there is lots of decision making ability
>> for code changes. I'd say look at the changelog for e.g. 0.11
>> https://github.com/bitcoin/bitcoin/blob/0.11/doc/release-notes.md#0110-change-log,
>> or follow pull requests for a while, to see how many decisions about
>> changes are made from day to day. No, I'm not sitting on my hands, and so
>> is none of the other contributors that you'd like to get rid of.
>>
>
> The analogy goes further even. Even though I disagree with some of the
> changes you're making, I respect Mike's (and anyone's) right to make a fork
> of Bitcoin Core. That's how open source works: if people disagree with
> changes made or not made, they can maintain their own version. However:
>
>
>> Consensus changes are *much* more difficult, on the other hand. Even
>> relatively straightforward softforks come with a long discussion process
>> (see BIP62, BIP66). A hardfork is hard to do at the best of times (everyone
>> needs to upgrade their software!), and simply not possible if almost the
>> entire technical community disagrees with you.
>>
>
> Consensus changes - in particular hardforks - are not about making a
> change to the software. You are effectively asking users of the system to
> migrate to a new system. Perhaps one which is a philosophical successor to
> the old one, but a different system, with new rules that are incompatible
> with the old one.
>
Indeed. I think Mike is glossing over this major facet.
Consensus changes - worded another way - change Bitcoin's Constitution -
The Rules that everyone in the system is -forced- to follow, or be ignored
by the system.
Changing bitcoin's rules IS IN NO WAY like Wikipedia or other open source
software.
--
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/20150618/4eec5ab0/attachment.html>

2023-06-07 17:38:31 CEST

- reply

📅 Original date posted:2015-06-18
📝 Original message:On Thu, Jun 18, 2015 at 9:07 AM, <justusranvier at riseup.net> wrote:
> On 2015-06-18 14:53, Jeff Garzik wrote:
>
>> Consensus changes - worded another way - change Bitcoin's Constitution -
>> The Rules that everyone in the system is -forced- to follow, or be ignored
>> by the system.
>>
>
> Bitcoin does not and can not function as a set of rules imposed by some
> people onto other people.
This is an engineering list. The quote precisely describes how the bitcoin
consensus system functions.
Users' choice is largely binary: Follow the rules, or bitcoin software
ignores you.
--
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/20150618/1e4ba4be/attachment.html>

2023-06-07 17:38:30 CEST

- reply

📅 Original date posted:2015-06-18
📝 Original message:On Thu, Jun 18, 2015 at 10:53 AM, Milly Bitcoin <milly at bitcoins.info> wrote:
> >So I'm *not* the decider for anything that concerns the behavior of
> the global consensus, and I cannot be, as I have explained in the
> previous post.
>
> The person who decides if a pull request is accepted is a decider and
> significantly affects the behavior of the global consensus. The only
> option for someone who doesn't agree is to hard fork. There is no way
> around that and you should just accept that fact and move on.
>
Impacts, yes, decider, no. Multiple ACKs are required from developers who
will not act if the community will disagree with the change.
The users ultimately choose by deciding which software to download, and
that dictates the range of choices available.
--
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/20150618/71ad12e5/attachment.html>

2023-06-07 17:37:37 CEST

- reply

📅 Original date posted:2015-06-14
📝 Original message:Miner voting, while imperfect, is the least-worst of various solutions
which inject market input into the system. It is is known quantity, field
tested, and must be sustained, in public, over a time span of months. As
this thread shows, stakeholder and direct user voting is nigh impossible to
get right.
Choosing block size is fundamentally a central bank directive shaping the
fee market. Whatever actor or algorithm or natural equilibrium picks the
block size, that choice will dictate the level of competition for fees, the
level of scarcity of an economically scarce resource. Picking the block
size advantages some businesses over others, some business models over
others. Software (and software devs) should not be the ones picking that
limit.
Checks-and-balances are also important. BIP 100 notably includes two steps
at which user input is visibly and actively injected: 1) hard fork to
enable, and 2) a second hard fork if the system is to scale beyond 32MB.
The network users (not miners) twice approve the system. Further, one must
remember all the basic miner incentives that do align with users, notably
that of maintaining the value of bitcoin tokens as their primary income
stream.
On Sun, Jun 14, 2015 at 12:16 AM, Stephen <stephencalebmorse at gmail.com>
wrote:
> While this idea is theoretically interesting because it involves many
> stakeholders, rather than just miners, I think in practice this would not
> work very well. Users don't want to worry about this kind of technicality,
> they just want to be able to make a transaction and have it be processed.
>
> In addition, while this gives stakeholders some weight with the fees they
> supply, these fees are marginal compared to the block size subsidy. If this
> proposal were actually implemented, I think miners would vote for whatever
> they think is best, and users would not contradict them with their votes to
> ensure a fast confirmation time. Users are incentivized to be in agreement
> with miners because the miners provide them with the confirmations they
> need, but fees do not provide a great incentive for miners to be in
> agreement with users, and likely won't for some time.
>
> Best,
> Stephen
>
>
>
>
> > On Jun 12, 2015, at 2:11 PM, Peter Todd <pete at petertodd.org> wrote:
> >
> > Jeff Garzik recently proposed that the upper blocksize limit be removed
> > entirely, with a "soft" limit being enforced via miner vote, recorded by
> > hashing power.
> >
> > This mechanism within the protocol for users to have any influence over
> > the miner vote. We can add that back by providing a way for transactions
> > themselves to set a flag determining whether or not they can be included
> > in a block casting a specific vote.
> >
> > We can simplify Garzik's vote to say that one of the nVersion bits
> > either votes for the blocksize to be increased, or decreased, by some
> > fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a
> > nVersion bit in transactions themselves, also voting for an increase or
> > decrease. Transactions may only be included in blocks with an
> > indentical vote, thus providing miners with a monetary incentive via
> > fees to vote according to user wishes.
> >
> > Of course, to cast a "don't care" vote we can either define an
> > additional bit, or sign the transaction with both versions. Equally we
> > can even have different versions with different fees, broadcast via a
> > mechanism such as replace-by-fee.
> >
> >
> > See also John Dillon's proposal for proof-of-stake blocksize voting:
> >
> >
> https://www.mail-archive.com/[email protected]/msg02323.html
> >
> > --
> > 'peter'[:-1]@petertodd.org
> > 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
> >
> ------------------------------------------------------------------------------
> > _______________________________________________
> > 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/20150614/a0c711a4/attachment.html>

2023-06-07 17:37:33 CEST

- reply

📅 Original date posted:2015-06-14
📝 Original message:Exactly -- both block size proponents and block size change conservatives
seem to be glossing over this aspect - much to my dismay.
Choosing the size limit is choosing the size of a scarce resource. By fiat.
It is wrong to think that a "technical consensus" can choose what is best
here.
The block size limit defines the scope of a resource for which all fee
market actors bid. That, in turn, defines who is in the fee market and how
they behave, what market choices are made.
It doesn't matter how or why the limit was originally enacted, what Satoshi
meant to do. What matters, economically, is what is. What the software
and our $3B economy & market knows and sees today. (I think some block
size change proponents miss this!)
The solution lies in transitioning this size limit to the free market. In
the end, the users must choose their desired level of growth,
decentralization, etc. We cannot rely on some dev's idea of the proper
level of fee, proper level of growth, proper level of decentralization.
And IMO, a "floating limit with training wheels" is better and stronger for
bitcoin's health from a governance, user choice and free market perspective
than simply "hard fork to 2MB, come back again in 6 months."
On Sun, Jun 14, 2015 at 6:34 AM, Benjamin <benjamin.l.cordes at gmail.com>
wrote:
> "The size limit is an economic policy lever that needs to be
> transitioned -away- from software and software developers, to the free
> market."
>
> Exactly right. Bitcoin does not have a free market for fee though, and
> literally all the discussion so far has neglected some fundamental
> aspect of this, as you described. It's not at all a "technical" or
> "engineering" decision. It's the question of how to potentially
> re-design a fundamental part of Bitcoin, and the proposals so far
> don't address this. What is the price of the scarce resource of the
> blockchain and the mechanism to decide on price, once the subsidy runs
> out?
>
> On Sun, Jun 14, 2015 at 12:06 PM, Mats Henricson <mats at henricson.se>
> wrote:
> > Jeff,
> >
> > with all due respect, but I've seen you saying this a few times
> > now, that this decision is oh so difficult and important.
> >
> > But this is not helpful. We all know that. Even I.
> >
> > Make a suggestion, or stay out of the debate!
> >
> > Mats
> >
> > On 06/14/2015 07:36 AM, Jeff Garzik wrote:
> >> The choice is very real and on-point. What should the block size limit
> >> be? Why?
> >>
> >> There is a large consensus that it needs increasing. To what? By what
> >> factor?
> >>
> >> The size limit literally defines the fee market, the whole damn thing.
> If
> >> software high priests choose a size limit of 300k, space is scarce, fees
> >> are bid high. If software high priests choose a size limit of 32mb,
> space
> >> is plentiful, fees are near zero. Market actors take their signals
> >> accordingly. Some business models boom, some business models fail, as a
> >> direct result of changing this unintentionally-added speedbump.
> Different
> >> users value adoption, decentralization etc. differently.
> >>
> >> The size limit is an economic policy lever that needs to be transitioned
> >> -away- from software and software developers, to the free market.
> >>
> >> A simple, e.g. hard fork to 2MB or 4MB does not fix higher level
> governance
> >> problems associated with actors lobbying developers, even if a
> cloistered
> >> and vetted Technical Advisory Board as has been proposed.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Sun, Jun 14, 2015 at 1:20 AM, Eric Lombrozo <elombrozo at gmail.com>
> wrote:
> >>
> >>> I definitely think we need some voting system for metaconsensus…but if
> >>> we’re going to seriously consider this we should look at the problem
> much
> >>> more generally. Using false choices doesn’t really help, though ;)
> >>>
> >>> - Eric Lombrozo
> >>>
> >>>
> >>> On Jun 13, 2015, at 10:13 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> >>>
> >>> On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo <elombrozo at gmail.com>
> >>> wrote:
> >>>
> >>>> 2) BIP100 has direct economic consequences…and particularly for
> miners.
> >>>> It lends itself to much greater corruptibility.
> >>>>
> >>>>
> >>> What is the alternative? Have a Chief Scientist or Technical Advisory
> >>> Board choose what is a proper fee, what is a proper level of
> >>> decentralization, a proper growth factor?
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >>
> >>
> >>
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>
> >
> >
> ------------------------------------------------------------------------------
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
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/20150614/48bfb14a/attachment.html>

2023-06-07 17:37:32 CEST

- reply

📅 Original date posted:2015-06-14
📝 Original message:On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo <elombrozo at gmail.com> wrote:
> 2) BIP100 has direct economic consequences…and particularly for miners. It
> lends itself to much greater corruptibility.
>
>
What is the alternative? Have a Chief Scientist or Technical Advisory
Board choose what is a proper fee, what is a proper level of
decentralization, a proper growth factor?
--
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/20150614/82643684/attachment.html>

2023-06-07 17:37:32 CEST

- reply

📅 Original date posted:2015-06-14
📝 Original message:The choice is very real and on-point. What should the block size limit
be? Why?
There is a large consensus that it needs increasing. To what? By what
factor?
The size limit literally defines the fee market, the whole damn thing. If
software high priests choose a size limit of 300k, space is scarce, fees
are bid high. If software high priests choose a size limit of 32mb, space
is plentiful, fees are near zero. Market actors take their signals
accordingly. Some business models boom, some business models fail, as a
direct result of changing this unintentionally-added speedbump. Different
users value adoption, decentralization etc. differently.
The size limit is an economic policy lever that needs to be transitioned
-away- from software and software developers, to the free market.
A simple, e.g. hard fork to 2MB or 4MB does not fix higher level governance
problems associated with actors lobbying developers, even if a cloistered
and vetted Technical Advisory Board as has been proposed.
On Sun, Jun 14, 2015 at 1:20 AM, Eric Lombrozo <elombrozo at gmail.com> wrote:
> I definitely think we need some voting system for metaconsensus…but if
> we’re going to seriously consider this we should look at the problem much
> more generally. Using false choices doesn’t really help, though ;)
>
> - Eric Lombrozo
>
>
> On Jun 13, 2015, at 10:13 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
>
> On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo <elombrozo at gmail.com>
> wrote:
>
>> 2) BIP100 has direct economic consequences…and particularly for miners.
>> It lends itself to much greater corruptibility.
>>
>>
> What is the alternative? Have a Chief Scientist or Technical Advisory
> Board choose what is a proper fee, what is a proper level of
> decentralization, a proper growth factor?
>
>
>
--
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/20150614/b1a4825d/attachment.html>

2023-06-07 17:37:31 CEST

- reply

📅 Original date posted:2015-06-14
📝 Original message:On Sun, Jun 14, 2015 at 12:55 AM, Chun Wang <1240902 at gmail.com> wrote:
> To tell you the truth. It is only because most miners are not located
> in the West. If Slush, Eligius and BTC Guild still on top 3, the core
> developers, including brain-dead Mike Hearn, would be very happy to do
> BIP100 just like they did BIP34 and BIP66. Shame on you!
>
BIP 100 requires a hard fork to engage. Users proactively opt-in.
--
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/20150614/718f5a1c/attachment.html>

2023-06-07 17:33:19 CEST

- reply

📅 Original date posted:2015-05-08
📝 Original message:On Fri, May 8, 2015 at 10:59 AM, Alan Reiner <etotheipi at gmail.com> wrote:
>
> This isn't about "everyone's coffee". This is about an absolute minimum
> amount of participation by people who wish to use the network. If our
> goal is really for bitcoin to really be a global, open transaction network
> that makes money fluid, then 7tps is already a failure. If even 5% of the
> world (350M people) was using the network for 1 tx per month (perhaps to
> open payment channels, or shift money between side chains), we'll be above
> 100 tps. And that doesn't include all the non-individuals (organizations)
> that want to use it.
>
> The goals of "a global transaction network" and "everyone must be able to
> run a full node with their $200 dell laptop" are not compatible. We need
> to accept that a global transaction system cannot be fully/constantly
> audited by everyone and their mother. The important feature of the network
> is that it is open and anyone *can* get the history and verify it. But not
> everyone is required to. Trying to promote a system where the history can
> be forever handled by a low-end PC is already falling out of reach, even
> with our miniscule 7 tps. Clinging to that goal needlessly limits the
> capability for the network to scale to be a useful global payments system
>
>
To repeat, the very first point in my email reply was: "Agree that 7 tps is
too low" Never was it said that bit
Therefore a reply arguing against the low end is nonsense, and the relevant
question remains on the table.
How high do you want to go - and can Layer 1 bitcoin really scale to get
there?
It is highly disappointing to see people endorse "moar bitcoin volume!"
with zero thinking behind that besides "adoption!" Need to actually
project what bitcoin looks like at the desired levels, what network
resources are required to get to those levels -- including traffic to serve
those SPV clients via P2P -- and then work backwards from that to see who
can support it, and then work backwards to discern a maximum tps.
--
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/20150508/c0203dbe/attachment.html>

2023-06-07 17:33:18 CEST

- reply

📅 Original date posted:2015-05-07
📝 Original message:On Thu, May 7, 2015 at 9:40 PM, Tom Harding <tomh at thinlink.com> wrote:
> On 5/7/2015 12:54 PM, Jeff Garzik wrote:
> > 2) Where do you want to go? Should bitcoin scale up to handle all the
> > world's coffees?
>
> Alan was very clear. Right now, he wants to go exactly where Gavin's
> concrete proposal suggests.
>
G proposed 20MB blocks, AFAIK - 140 tps
A proposed 100MB blocks - 700 tps
For ref,
Paypal is around 115 tps
VISA is around 2000 tps (perhaps 4000 tps peak)
I ask again: where do we want to go? This is the existential question
behind block size.
Are we trying to build a system that can handle Paypal volumes? VISA
volumes?
It's not a snarky or sarcastic question: Are we building a system to
handle all the world's coffees? Is bitcoin's main chain and network -
Layer 1 - going to receive direct connections from 500m mobile phones,
broadcasting transactions?
We must answer these questions to inform the change being discussed today,
in order to decide what makes the most sense as a new limit. Any
responsible project of this magnitude must have a better story than "zomg
1MB, therefore I picked 20MB out of a hat" Must be able to answer /why/
the new limit was picked.
As G notes, changing the block size is simply kicking the can down the
road: http://gavinandresen.ninja/it-must-be-done-but-is-not-a-panacea
Necessarily one must ask, today, what happens when we get to the end of
that newly paved road.
--
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/20150507/f1a12b68/attachment.html>

2023-06-07 17:33:17 CEST

- reply

📅 Original date posted:2015-05-07
📝 Original message:On Thu, May 7, 2015 at 3:31 PM, Alan Reiner <etotheipi at gmail.com> wrote:
> (1) Blocks are essentially nearing "full" now. And by "full" he means
> that the reliability of the network (from the average user perspective) is
> about to be impacted in a very negative way
>
Er, to be economically precise, "full" just means fees are no longer zero.
Bitcoin behaves as it always has. It is no longer basically free to dump
spam into the blockchain, as it is today.
In the short term, blocks are bursty, with some on 1 minute intervals, some
with 60 minute intervals. This does not change with larger blocks.
> (2) Leveraging fee pressure at 1MB to solve the problem is actually really
> a bad idea. It's really bad while Bitcoin is still growing, and relying on
> fee pressure at 1 MB severely impacts attractiveness and adoption potential
> of Bitcoin (due to high fees and unreliability). But more importantly, it
> ignores the fact that for a 7 tps is pathetic for a global transaction
> system. It is a couple orders of magnitude too low for any meaningful
> commercial activity to occur. If we continue with a cap of 7 tps forever,
> Bitcoin *will* fail. Or at best, it will fail to be useful for the vast
> majority of the world (which probably leads to failure). We shouldn't be
> talking about fee pressure until we hit 700 tps, which is probably still
> too low.
>
[...]
1) Agree that 7 tps is too low
2) Where do you want to go? Should bitcoin scale up to handle all the
world's coffees?
This is hugely unrealistic. 700 tps is 100MB blocks, 14.4 GB/day -- just
for a single feed. If you include relaying to multiple nodes, plus serving
500 million SPV clients en grosse, who has the capacity to run such a
node? By the time we get to fee pressure, in your scenario, our network
node count is tiny and highly centralized.
3) In RE "fee pressure" -- Do you see the moral hazard to a software-run
system? It is an intentional, human decision to flood the market with
supply, thereby altering the economics, forcing fees to remain low in the
hopes of achieving adoption. I'm pro-bitcoin and obviously want to see
bitcoin adoption - but I don't want to sacrifice every decentralized
principle and become a central banker in order to get there.
--
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/20150507/52c8aa10/attachment.html>

2023-06-07 17:33:12 CEST

- reply

📅 Original date posted:2015-05-07
📝 Original message:On Thu, May 7, 2015 at 11:12 AM, Mike Hearn <mike at plan99.net> wrote:
>
> That's why I conclude the opposite - if there is no fork, then people's
> confidence in Bitcoin will be seriously damaged.
>
Yes, that is a possibility.
> If it's impossible to do something as trivial as removing a temporary hack
> Satoshi put in place, then what about bigger challenges?
>
This is absolutely not a trivial change.
It is a trivial *code* change. It is not a trivial change to the economics
of a $3.2B system.
--
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/20150507/9ef5c02d/attachment.html>

2023-06-07 17:33:12 CEST

- reply

📅 Original date posted:2015-05-07
📝 Original message:Yes - but you must recognize that is precisely 50% of the picture.
Others have made different assumptions - taking the [1MB-constrained]
market *as it exists today*, rather than in some projected future.
Raising the block size limit then becomes a *human decision* to favor some
users over others, a *human decision* to prevent an active and competitive
free fee market developing at 1MB, a *human decision* to keep transaction
fees low to incentivize bitcoin adoption, a *human decision* to value
adoption over decentralization.
These statements are not value judgements - not saying you are wrong -
these are observations of some rather huge, relevant blind spots in this
debate.
On Thu, May 7, 2015 at 11:29 AM, Mike Hearn <mike at plan99.net> wrote:
> It is a trivial *code* change. It is not a trivial change to the
>> economics of a $3.2B system.
>>
>
> Hmm - again I'd argue the opposite.
>
> Up until now Bitcoin has been unconstrained by the hard block size limit.
>
> If we raise it, Bitcoin will continue to be unconstrained by it. That's
> the default "continue as we are" position.
>
> If it's not raised, then ....... well, then we're in new territory
> entirely. Businesses built on the assumption that Bitcoin could become
> popular will suddenly have their basic assumptions invalidated. Users will
> leave. The technical code change would be zero, but the economic change
> would be significant.
>
--
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/20150507/a084642c/attachment.html>

2023-06-07 17:28:42 CEST

- reply

📅 Original date posted:2015-01-28
📝 Original message:It is not "fear", it is field experience.
JSON has proven to be a bug generator for the reasons already stated.
JSON does not include type marshalling and input validation.
Protobufs/msgpack/etc. engineered those to occur automatically, because
that is an area shown by field experience to be a constant source of bugs
and inconsistent parsing/validation behavior.
On Wed, Jan 28, 2015 at 11:52 AM, Nicolas DORIER <nicolas.dorier at gmail.com>
wrote:
> For the number of field there is in the spec, I don't consider having a
> JSON to schama really worthwhile.
> If you fear it is error prone, then we should provide some testing data
> for the BIP70. (Which I already did for protobuf, but was rejected, because
> deemed no useful thanks to the code generator... But such code generator
> gave me inconsistencies with gavin's implementation for example)
>
> Why do you think type support is very useful in our case ? we have 3
> types, and dealing only with bytes, int, and string.
> It cost me more time to find a suitable cross plateform lib for protobuf
> (in c#, that works in ios and winrt) than I would by just coding the json
> wrapper classes by hand. (JSON libs are more wildspread and supported than
> protobuf)
>
> 2015-01-28 17:04 GMT+01:00 Jeff Garzik <jgarzik at bitpay.com>:
>
>> Not to mention the tiresome and error-prone task of writing your own
>> JSON-to-schema marshalling code -- or something equivalent to the protobufs
>> compiler and libs for JSON.
>>
>> protobufs -- and its modern competitors such as msgpack -- natively
>> provide type support in a way that must be hacked into JSON or XML.
>>
>> The protobuf/msgpack design is engineered to avoid bugs routinely found
>> in JSON parsing code; due to the amount of code & effort involved in JSON
>> input sanity checking, bugs and inconsistencies inevitable arise. We have
>> seen this in bitcoind with JSON-RPC.
>>
>>
>>
>> On Wed, Jan 28, 2015 at 10:42 AM, Mike Hearn <mike at plan99.net> wrote:
>>
>>> On the other hand, if you charge the developer (and not the plateform)
>>>> to check certificate validity, it means that you have to develop a
>>>> different codebase for all plateform you are targeting, because each
>>>> plateform store trusted root certificate in a different manner with
>>>> different APIs, and also have different types representing a X509
>>>> Certificate.
>>>>
>>>
>>> That's what cross-platform abstraction libraries are for. Both Java and
>>> Qt provide a key store library that can load from either the OS root store
>>> or a custom one. If your chosen app platform doesn't, OK, then you'll have
>>> to make or find one yourself. Perhaps contribute it upstream or make it a
>>> library. But that's not a limitation of BIP70.
>>>
>>> Just as a reminder, there is no obligation to use the OS root store. You
>>> can (and quite possibly should) take a snapshot of the Mozilla/Apple/MSFT
>>> etc stores and load it in your app. We do this in bitcoinj by default to
>>> avoid cases where BIP70 requests work on some platforms and not others,
>>> although the developer can easily override this and use the OS root store
>>> instead.
>>>
>>> Of all possible solutions, using a third party service to convert things
>>> to JSON is one of the least obvious and highest effort. I don't know anyone
>>> else who arrived at such a conclusion and respectfully disagree that this
>>> is a problem with the design choices in BIP70. It sounds like a bizarre
>>> hack around lack of features in whatever runtime you're using.
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Dive into the World of Parallel Programming. The Go Parallel Website,
>>> sponsored by Intel and developed in partnership with Slashdot Media, is
>>> your
>>> hub for all things parallel software development, from weekly thought
>>> leadership blogs to news, videos, case studies, tutorials and more. Take
>>> a
>>> look and join the conversation now. http://goparallel.sourceforge.net/
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>>
>> --
>> Jeff Garzik
>> Bitcoin core developer and open source evangelist
>> BitPay, Inc. https://bitpay.com/
>>
>
>
--
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/20150128/37d1a41c/attachment.html>

2023-06-07 17:28:39 CEST

- reply

📅 Original date posted:2015-01-19
📝 Original message:None of those listed were in the context of performance. Parsing of binary
or text is quite fast these days, and is not really a consideration versus
other needs such as a predictable encoding for a single data
representation. XML and JSON both can represent the same post-evaluation
user data a million different ways, which is awful for anything you are
signing and hashing. Text formats also transit binary data very poorly,
leading to unnecessary wrapping and unwrappiing (a programmatic, visibility
& bug; again performance not a primary concern).
This is evident because both XML and JSON have standards efforts under way
to correct some of these problems and make them more deterministic.
However, such standards are not field deployed and widely supported by
parsers and generators alike.
On Mon, Jan 19, 2015 at 2:16 PM, Richard Brady <rnbrady at gmail.com> wrote:
> Fair points, although for me the line is blurred between which of those
> are security considerations vs performance considerations.
>
> Richard
>
> On 19 January 2015 at 19:09, Jeff Garzik <jgarzik at bitpay.com> wrote:
>
>> Text formats such as XML or JSON are far less deterministic, are more
>> loosely specified, have wide variance in parsing, are not very hash-able,
>> the list goes on.
>>
>>
>> On Mon, Jan 19, 2015 at 2:07 PM, Richard Brady <rnbrady at gmail.com> wrote:
>>
>>> Hi Gavin, Mike and co
>>>
>>> Is there a strong driver behind the choice of Google Protocol Buffers
>>> for payment request encoding in BIP-0070?
>>>
>>> Performance doesn't feel that relevant when you think that:
>>> 1. Payment requests are not broadcast, this is a request / response
>>> flow, much more akin to a web request.
>>> 2. One would be cramming this data into a binary format just so you can
>>> then attach it to a no-so-binary format such as HTTP.
>>>
>>> Some great things about protocols/encodings such as HTTP/JSON/XML are:
>>> 1. They are human readable on-the-wire. No Wireshark plugin required,
>>> tcpdump or ngrep will do.
>>> 2. There are tons of great open source libraries and API for parsing /
>>> manipulating / generating.
>>> 3. It's really easy to hand-craft a test message for debugging.
>>> 4. The standards are much easier to read and write. They don't need to
>>> contain code like BIP-0070 currently does and they can contain examples,
>>> which BIP70 does not.
>>> 5. They are thoroughly specified by independent standards bodies such as
>>> the IETF. Gotta love a bit of MUST / SHOULD / MAY in a standard.
>>> 6. They're a family ;-)
>>>
>>> Keen to hear your thoughts on this and very keen to watch the payment
>>> protocol grow regardless of encoding choice! My background is SIP / VoIP
>>> and I think that could be a fascinating use case for this protocol which
>>> I'm hoping to do some work on.
>>>
>>> Best,
>>> Richard
>>>
>>>
--
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/20150119/eb614bf2/attachment.html>

2023-06-07 17:28:39 CEST

- reply

📅 Original date posted:2015-01-19
📝 Original message:ASN.1 is not nearly as flexible when it comes to well-supported libraries,
generators, and the ecosystem that surrounds the actual encoding. You
don't see ASN.1 compilers + language support packages for [all popular
programming languages], as you do with protobufs.
Google engineers were well aware it existed I'm sure. There are wider
considerations beyond the low-level specified format.
Protobufs have their problems and aren't perfect, but ASN.1 ecosystem is
far less developed in the programming ecosystem, far less approachable for
programmers. BIP70 wouldn't have been as easily and widely adopted if
ASN.1 had been chosen.
On Mon, Jan 19, 2015 at 2:19 PM, Matt Whitlock <bip at mattwhitlock.name>
wrote:
> Even if a compact binary encoding is a high priority, there are more
> "standard" choices than Google Protocol Buffers. For example, ASN.1 is a
> very rigorously defined standard that has been around for decades, and
> ASN.1 even has an XML encoding (XER) that is directly convertible to/from
> the binary encoding (BER/DER), given the schema. In practice, I'm mostly
> agnostic about what encoding is actually used in BIP70, and I wouldn't
> fault BIP70 for choosing Google Protocol Buffers, but the very existence of
> Protobuf perplexes me, as it apparently re-solves a problem that was solved
> 40 years ago by ASN.1. It's as though the engineers at Google weren't aware
> that ASN.1 existed.
>
>
> On Monday, 19 January 2015, at 7:07 pm, Richard Brady wrote:
> > Hi Gavin, Mike and co
> >
> > Is there a strong driver behind the choice of Google Protocol Buffers for
> > payment request encoding in BIP-0070?
> >
> > Performance doesn't feel that relevant when you think that:
> > 1. Payment requests are not broadcast, this is a request / response flow,
> > much more akin to a web request.
> > 2. One would be cramming this data into a binary format just so you can
> > then attach it to a no-so-binary format such as HTTP.
> >
> > Some great things about protocols/encodings such as HTTP/JSON/XML are:
> > 1. They are human readable on-the-wire. No Wireshark plugin required,
> > tcpdump or ngrep will do.
> > 2. There are tons of great open source libraries and API for parsing /
> > manipulating / generating.
> > 3. It's really easy to hand-craft a test message for debugging.
> > 4. The standards are much easier to read and write. They don't need to
> > contain code like BIP-0070 currently does and they can contain examples,
> > which BIP70 does not.
> > 5. They are thoroughly specified by independent standards bodies such as
> > the IETF. Gotta love a bit of MUST / SHOULD / MAY in a standard.
> > 6. They're a family ;-)
> >
> > Keen to hear your thoughts on this and very keen to watch the payment
> > protocol grow regardless of encoding choice! My background is SIP / VoIP
> > and I think that could be a fascinating use case for this protocol which
> > I'm hoping to do some work on.
> >
> > Best,
> > Richard
>
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> 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/20150119/439ccfd3/attachment.html>

2023-06-07 17:28:38 CEST

- reply

📅 Original date posted:2015-01-19
📝 Original message:Correct. I should have said "more likely to be deterministic" Bitcoin
Core does not *rely* on determinism in BIP70; I was referring to recent
upstream efforts to make protobufs usable in a deterministic fashion by
default.
On Mon, Jan 19, 2015 at 3:03 PM, Alan Reiner <etotheipi at gmail.com> wrote:
> I'm a bit confused. It's been a long time since I looked at protobuf
> (and will have to dig into it soon), but I seem to recall it doesn't have
> any of the determinism properties you guys just said. It is intended to
> allow you to skip details of the on-the-wire representations and just send
> a bunch of named fields between systems. I thought there was no guarantee
> that two identical protobuf structures will get serialized identically...?
>
>
>
>
>
> On 01/19/2015 02:57 PM, Richard Brady wrote:
>
> Thanks guys, great answers.
>
> The design choice certainly makes a lot more sense now regardless of
> whether one agrees with it or not.
>
> Regards,
> Richard
>
>
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.http://p.sf.net/sfu/gigenet
>
>
>
> _______________________________________________
> Bitcoin-development mailing listBitcoin-development at lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> 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/20150119/5f969ba7/attachment.html>

2023-06-07 17:28:36 CEST

- reply

📅 Original date posted:2015-01-19
📝 Original message:Text formats such as XML or JSON are far less deterministic, are more
loosely specified, have wide variance in parsing, are not very hash-able,
the list goes on.
On Mon, Jan 19, 2015 at 2:07 PM, Richard Brady <rnbrady at gmail.com> wrote:
> Hi Gavin, Mike and co
>
> Is there a strong driver behind the choice of Google Protocol Buffers for
> payment request encoding in BIP-0070?
>
> Performance doesn't feel that relevant when you think that:
> 1. Payment requests are not broadcast, this is a request / response flow,
> much more akin to a web request.
> 2. One would be cramming this data into a binary format just so you can
> then attach it to a no-so-binary format such as HTTP.
>
> Some great things about protocols/encodings such as HTTP/JSON/XML are:
> 1. They are human readable on-the-wire. No Wireshark plugin required,
> tcpdump or ngrep will do.
> 2. There are tons of great open source libraries and API for parsing /
> manipulating / generating.
> 3. It's really easy to hand-craft a test message for debugging.
> 4. The standards are much easier to read and write. They don't need to
> contain code like BIP-0070 currently does and they can contain examples,
> which BIP70 does not.
> 5. They are thoroughly specified by independent standards bodies such as
> the IETF. Gotta love a bit of MUST / SHOULD / MAY in a standard.
> 6. They're a family ;-)
>
> Keen to hear your thoughts on this and very keen to watch the payment
> protocol grow regardless of encoding choice! My background is SIP / VoIP
> and I think that could be a fascinating use case for this protocol which
> I'm hoping to do some work on.
>
> Best,
> Richard
>
>
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> 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/20150119/2046cd15/attachment.html>

2023-06-07 17:28:24 CEST

- reply

📅 Original date posted:2015-01-09
📝 Original message:Mike, Can you be more specific? You reference "original design" without
saying how it was different/better.
On Fri, Jan 9, 2015 at 8:20 AM, Mike Hearn <mike at plan99.net> wrote:
> A limitation on most existing micropayment channel ideas is that payments
>> can only flow in one direction.
>>
>
> It's worth noting that the original protocol as designed by Satoshi did
> not have this limitation. It has evolved this way because of ad-hoc DoS
> fixes over time (btw I'm not saying they were the wrong thing to do, as non
> "ad hoc" solutions are significantly more work). But it seems like
> eventually a different approach to handling DoS attacks based on resource
> prioritisation and scheduling will become needed / implemented, and at that
> point the original design could be safely brought back to life.
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
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/20150109/d9790647/attachment.html>

2023-06-07 17:28:04 CEST

- reply

📅 Original date posted:2014-12-15
📝 Original message:On Mon, Dec 15, 2014 at 1:42 PM, Cory Fields <lists at coryfields.com> wrote:
> That's exactly what happened during the modularization process, with
> the exception that the code movement and refactors happened in
> parallel rather than in series. But they _were_ done in separate
> logical chunks for the sake of easier review.
>
"That's exactly what was done except it wasn't"
Yes, in micro, at the pull request level, this happened
* Code movement
* Refactor
At a macro level, that cycle was repeated many times, leading to the
opposite end result: a lot of tiny movement/refactor/movement/refactor
producing the review and patch annoyances described.
It produces a blizzard of new files and new data structures, breaking a
bunch of out-of-tree patches, complicating review quite a bit. If the vast
majority of code movement is up front, followed by algebraic
simplifications, followed by data structure work, further patches are easy
to review/apply with less impact on unrelated code.
The flow of patches into the tree over time should be examined. Simply
tagging patches as movement-only does not address the described problem at
all.
--
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/20141215/e2cb4696/attachment.html>

2023-06-07 17:28:03 CEST

- reply

📅 Original date posted:2014-12-15
📝 Original message:On Mon, Dec 15, 2014 at 9:57 AM, Btc Drak <btcdrak at gmail.com> wrote:
> We all want to see more modular code, but the first steps should just be
> to relocate blocks of code so everything is more logically organised in
> smaller files (especially for consensus critical code). Refactoring should
> come in a second wave preferably after a stable release.
>
This is my opinion as well. In the Linux kernel, we often were faced with
a situation where you have a One Big File driver with > 1MB of source
code. The first step was -always- raw code movement, a brain-dead breaking
up of code into logical source code files.
Refactoring of data structures comes after that.
While not always money-critical, these drivers Had To Keep Working. We had
several situations where we had active users, but zero hardware access for
debugging, and zero access to the vendor knowledge (hardware documentation,
engineers). Failure was not an option. ;p
Performing the dumb Break Up Files step first means that future, more
invasive data structures are easier to review, logically segregated, and
not obscured by further code movement changes down the line. In code such
as Bitcoin Core, it is important to think about the _patch stream_ and how
to optimize for reviewer bandwidth.
The current stream of refactoring is really a turn-off in terms of
reviewing, sapping reviewer bandwidth by IMO being reviewer-unfriendly. It
is a seemingly never-ending series of tiny
refactor-and-then-stuff-in-a-class-and-make-it-pretty-and-do-all-the-work.
Some change is in order, gentlemen.
--
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/20141215/fa588b20/attachment.html>

2023-06-07 17:27:32 CEST

- reply

📅 Original date posted:2014-11-26
📝 Original message:I don't recall being contacted directly, but the attack has been
discussed. It relies on a number of conditions. For example, if you are
over Tor, they try to kick the machine off Tor, _assuming_ that it will
fall back to non-Tor. That's only true for dual stack nodes, which are not
really 100% anonymous anyway -- you're operating from your public IP anyway.
On Wed, Nov 26, 2014 at 2:47 AM, Jean-Paul Kogelman <jeanpaulkogelman at me.com
> wrote:
> This paper was just posted on reddit that describes how an attacker can
> de-anonymize clients on the bitcoin network. It mentions that the core devs
> were contacted prior to publication. I was just wondering, how many of
> these issues have already been addressed?
>
>
> Paper (University of Luxembourg):
> http://orbilu.uni.lu/handle/10993/18679
>
>
> Kind regards,
>
> Jean-Paul
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> 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/20141126/23470dfe/attachment.html>

2023-06-07 17:26:45 CEST

- reply

📅 Original date posted:2014-10-25
📝 Original message:It is an overly-simplistic miner model to assume altruism is
necessary. The hashpower market is maturing in the direction of
financial instruments, where the owner of the hashpower is not
necessarily the one receiving income. These are becoming tradeable
instruments, and derivatives and hedging are built on top of that.
Risk is hedged at each layer. Market players also forge agreements
with miners, and receive -negative- value if hashpower is simply shut
down.
Simplistic models cannot predict what hashpower does in the face of
business-to-business medium- and long-term contracts.
On Sat, Oct 25, 2014 at 2:22 PM, Alex Mizrahi <alex.mizrahi at gmail.com> wrote:
>
>>
>> "Flag day" herd behavior like this is unlikely for well informed and
>> well prepared market participants.
>
>
> It is simply rational to turn your mining device off until difficulty
> adjusts.
> Keeping mining for 2+ weeks when it costs you money is an altruistic
> behavior, we shouldn't rely on this.
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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/

2023-06-07 17:26:45 CEST

- reply

📅 Original date posted:2014-10-25
📝 Original message:On Sat, Oct 25, 2014 at 2:06 PM, Alex Mizrahi <alex.mizrahi at gmail.com> wrote:
> Hashrate might drop by more than 50% immediately after the halving (and
> before difficulty is updated), thus a combination of the halving and slow
> difficulty update pose a real threat.
"Flag day" herd behavior like this is unlikely for well informed and
well prepared market participants.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 17:26:09 CEST

- reply

📅 Original date posted:2014-10-03
📝 Original message:RE " It's not like other software where people can choose to skip an
upgrade and things still work just like before."
If you're a minority, sure you can. Still a few nutters out there on
a 0.3.x codebase, including one or two inattentive,
now-inconsequential miners.
There is some headroom built in for just that... less disruptive
upgrades that don't require 100%.
On Fri, Oct 3, 2014 at 4:58 PM, Mike Hearn <mike at plan99.net> wrote:
> Alright. It seems there's no real disagreement about how the opcode behaves.
> Perhaps a time limit would be appropriate to stop people creating outputs
> locked for 100 years .... is bitcoin even likely to exist in 100 years? The
> entire history of computing is not even that old, seems hard to imagine that
> it'd be good for anything beyond wasting space in the database. But this is
> a minor point.
>
> So I guess it's time to start the deployment discussion.
>
> Bitcoin is a consensus system. It works best when everyone is following
> exactly the same rules at the same time. A soft fork works against this
> principle by allowing nodes to think they're following the majority ruleset,
> even if they aren't, effectively downgrading them to something a bit like
> SPV security without them realising.
>
> A hard fork has multiple desirable properties. Most importantly, it means a
> node can detect it's no longer in the consensus because it'll find its own
> chain height has diverged significantly from its peers. Core already has
> code that knows how to detect this condition and log errors about it as well
> as running the alertnotify script i.e. emailing the admin. Ideally it would
> also stop serving work so miners shut down or fail over, but this is easily
> added to the CheckForkWarningConditions() function.
>
> In other words, this gives the cleanest failure we can give, such that any
> procedures a node operator has put in place to alert them of divergence will
> be triggered. Any code which is waiting for confirmations will wait forever
> at this point, thus minimising the risk of loss.
>
> Additionally, forcing old peers to fall behind means SPV clients will pick
> the right chain, and not end up downloading transactions or blocks that are
> about to be doomed at the next re-org. They can easily choose to ignore
> transactions relayed by peers that are too far behind and thus not end up
> accepting transactions that are no longer valid according to the majority (a
> scenario which can cause monetary loss).
>
> I don't think hard forks should be scary. Mechanisms are in place to warn
> people and they can be scheduled with plenty of time in advance. The main
> stated justification for a soft fork is backwards compatibility, but in a
> system like Bitcoin you really don't want to be running behind the consensus
> and it's hard to imagine any node operator deliberately choosing to stay on
> the wrong side of the fork. It's not like other software where people can
> choose to skip an upgrade and things still work just like before.
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> 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/

2023-06-07 17:25:40 CEST

- reply

📅 Original date posted:2014-09-12
📝 Original message:Indeed -- Every byte added to the QR code makes it more difficult to
be used in restaurants, pubs and other low-light conditions. BitPay
tested some of these scenarios.
Scannability is absolutely impacted.
On Fri, Sep 12, 2014 at 9:49 AM, Mike Hearn <mike at plan99.net> wrote:
> A few thoughts on this:
>
> (1) Base64 of SHA256 seems overkill. 256 bits of hash is a lot. The risk
> here is that a MITM intercepts the payment request, which will be typically
> requested just seconds after the QR code is vended. 80 bits of entropy would
> still be a lot and take a long time to brute force, whilst keeping QR codes
> more compact, which impacts scannability.
>
> (2) This should not be necessary in the common HTTPS context. The QR code
> itself is going to be fetched from some service, over HTTPS. I see no
> reasonable attacker that can MITM the request for the BIP70 message but not
> the request to get the QR code. Adding a hash makes QR codes more bloated
> and harder to scan, all on the assumption that HTTPS is broken in some odd
> way that we haven't actually ever seen in practice.
>
> (3) This can be useful in the Bluetooth context, but then again, we could
> also do things a different way by signing with the key in the first part of
> the URI, thus avoiding the need for a hash.
>
> I know I've been around the loop on this one with Andreas many times. But
> this BIP doesn't fix any actually existing problem in the previous spec. It
> exists because Andreas thinks SSL is useless. If SSL is useless we all have
> much bigger problems.
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> 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/

2023-06-07 17:25:27 CEST

- reply

📅 Original date posted:2014-08-19
📝 Original message:It would be nice if the issues and git repo for Bitcoin Core were not
on such a centralized service as github, nice and convenient as it is.
To that end, I note that Linux does its own git repo, and now requires
2FA: http://www.linux.com/news/featured-blogs/203-konstantin-ryabitsev/784544-linux-kernel-git-repositories-add-2-factor-authentication
As a first step, one possibility is putting the primary repo on
bitcoin.org somewhere, and simply mirroring that to github for each
push.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 17:24:09 CEST

- reply

📅 Original date posted:2014-07-18
📝 Original message:Related: We must handle some legitimate miner-privately-mined cases,
such as miner payout TXs (outside coinbase) or side chain conditional
TXs[1].
[1] https://bitcointalk.org/index.php?topic=676703.msg7682680#msg7682680
On Fri, Jul 18, 2014 at 3:51 PM, Kaz Wesley <keziahw at gmail.com> wrote:
> I've updated the gist, and added an additional proposal that I think
> meshes well:
> https://gist.github.com/kazcw/43c97d3924326beca87d#ultra-fast-block-validation
>
> sparseblocks + UFBV would tighten the new-block process to this (when
> txes have been received in advance):
> - receive block (~2kB for 1000 tx)
> - check whether block contains txes known to belong to conflict-sets,
> and if so whether more than one tx from a single conflict-set has been
> included (a few operations on very small sets)
> - relay block (~2kB)
>
> The benefits of these changes only occur when the transactions have
> been seen in advance, but incentivizing ahead-of-block transaction
> propogation is a plus, as Jeff mentioned; working on a block without
> first ensuring peers have its transactions would be very expensive
> from a miner's point of view.
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> 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/

2023-06-07 17:24:08 CEST

- reply

📅 Original date posted:2014-07-18
📝 Original message:On a flood-fill network, you don't want to create a storm of "I
already have this" replies.
On Fri, Jul 18, 2014 at 1:39 PM, Kaz Wesley <keziahw at gmail.com> wrote:
> Peers exchanging mempool priority policies is great; that accomplishes
> the flexibility in what txes to remember that I was going for with the
> forget-filters, but much more neatly, with less overhead and some side
> benefits.
>
> Here's what I'm picturing now:
> - exchange priority policies in peer introductions
> - assign unique sequential IDs in the order the transactions were
> inved (per peer)
> - receiving a getdata for a tx updates last-known-peer-received inv to
> all invs up to the one referenced
> - include ID-last-received, last-known-peer-received in sparse block
> - reference txes in sparse block by index in receiver's
> prioritiziation with peer's sent invs up to ID-last-received and
> sender's prior invs up to last-known-peer-received
>
> Possible new messages:
> - sparseblock
> - invack message a node can send at times when it's received a bunch
> of invs it already has, so it hasn't acked with a getdata in a while
> - gettx: getdata, but using new sequential ID to save 28 bytes per tx
>
> It seems important for ordering policies to be able to be specified in
> as much detail as possible. Parameters that should be available:
> - total inputs
> - total outputs
> - bytes
> - coin days destroyed
> - net UTXO size change
> - sigops
> - is data carrier
> - is output raw multisig
> - age in mempool
> - what else?
> This parameter set should be extensible to allow for unforeseen future factors.
>
> Ordering policies should allow arbitrary algebraic combinations of
> their parameters, as well as thresholds. Boolean combinations of
> sub-policies would also be desirable. This could be implemented with a
> tx-script-like stack-based language, in which each supported tx
> property is pushed onto the stack by a particular opcode, and
> +-*//min/max/boolean operators combine them to yield the sort key.
>
> Difficult parameters:
> * Coin-days-destroyed: changes, peers need agreement on when (if?)
> it's recalculated. Probably can just not recalculate, but peers still
> need agreement on "time seen" to get CDD.
> * Age in mempool: seems intractable in terms of time, but could be
> done easily in terms of "how many txes old is this sequential ID"
>
> One potential pitfall: this allows for an environment of completely
> heterogeneous mempool policies. I think that's a good thing, but we
> need to avoid a situation where only least-common-denominator
> transactions make it farther than a hop or two, and we don't want
> nodes to have a strong preference for connecting to like-minded peers
> since clustering reduces overall connectivity. It may be worthwhile to
> add a parallel mechanism for relay policies, to differentiate between
> what a node would keep in its mempool vs. what it wouldn't even relay
> and doesn't want to see at all. Relay policies could be specified just
> like prioritization policies, but with the final stack value evaluated
> in a boolean context.
>
> An interesting additional use of policy-scripts would be a
> standardized way for miners to include a policy script in a coinbase,
> allowing miners a mechanism to advertise things like their relative
> price of sigops vs bytes. Nodes may then choose to take this
> information into account in order to optimize their mempool policies
> for likelihood of consistency with future blocks. Since policy scripts
> provide only relative information on prices of different transaction
> properties rather than an absolute fee, this should not allow miners
> to "vote fees up", although care would need to be taken they wouldn't
> be able to drive up prices by claiming common transaction types are at
> the high end of the fee scale.
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> 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/

2023-06-07 17:24:07 CEST

- reply

📅 Original date posted:2014-07-18
📝 Original message:On Fri, Jul 18, 2014 at 10:53 AM, Gavin Andresen
<gavinandresen at gmail.com> wrote:
> But if there was some agreed-upon canonical ordering, then it should
> theoretically be possible to take shortcuts in the "what order".
>
> You'd start with setof(transactions I think everybody knows about)
> Select some subset, based on miner's policy
> Sort that subset with the canonical ordering algorithm
> Very efficiently broadcast, taking all sorts of shortcuts assuming most of
> your peers already know the set you started with and expect the same
> canonical ordering (see gmaxwell's thoughts on block encoding).
Related implementation detail: Having pursued this train of thought,
I noted that you don't want to include too-young transactions that you
received in the past few seconds, because those are likely still
propagating around the network.
> Second half-baked thought:
> I wonder if broadcasting your transaction selection policy ("11KB of free
> transactions, sorted by priority, then 111K of fee-paying transactions,
> sorted by fee") might make it possible to save even more bandwidth by
> letting your peers create a very good approximation of your block with just
> that information....
Absolutely. One path I would like to see pursued is multiple
p2pool-esque chains. Each with their own policy, perhaps with their
own administrative team. ie. you could have a fully decentralized
p2pool-like chain, or multiple such chains, each with a stated
policy/reward pattern. Or, GHash/BTCGuild/Eligius could run a
semi-centrally managed chain ultimately guaranteed not only by
protocol but by administrators' digital signatures.
In each case, advertising technical attributes about your pool [chain]
policy would give nodes the better ability to predict what is in an
upcoming block.
And the flip side of that, such predictions are never perfect. Need
to make sure the fallback case, while undoubtedly more costly than the
Fast Path, is not overly painful.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 17:23:45 CEST

- reply

📅 Original date posted:2014-07-15
📝 Original message:On Tue, Jul 15, 2014 at 4:19 AM, Wladimir <laanwj at gmail.com> wrote:
> In my opinion encouraging the use of the payment protocol and
> deprecating the use of addresses is the best way forward, and not just
> for this reason.
There are major gaps that the payment protocol doesn't cover.
There are several deployed use cases where you are provided/request an
address, an API provides one, and one or more incoming payments arrive
as the user sends them over minutes/hours/days/weeks.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 17:23:44 CEST

- reply

📅 Original date posted:2014-07-15
📝 Original message:Proxying another's idea, from CoinSummit.
The request: It would be useful to limit the lifetime of a bitcoin
address. Intentionally prevent (somehow) bitcoins being sent to a
pubkey/pkh after the key expires.
You could append "don't ["permit"|confirm] after X [time|block]" to
the address I suppose. The metadata would not be digitally signed,
but it would be hash-sealed. As "address" is a client-side notion,
wallet clients would be the ones enforcing such a rule.
Bitcoin protocol of course knows about keys, and key expiration is a
well known and useful concept in public key cryptography. The best
insertion point in the protocol for key expiration is an open
question, if it's even a good idea at that level at all. Some flag
"no more TxOuts exactly like this [after X block?]"?
I readily admit I don't have good answers, but it does seem valuable IMO to
* Prevent users from accidentally sending to an "expired" TxOut/pkh.
This happens in the field.
* Discourage address reuse
* Enable sites that generate lots of keys to rotate ancient keys off
their core systems. (HD wallets mitigate this)
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 17:22:17 CEST

- reply

📅 Original date posted:2014-06-04
📝 Original message:Yes, check macros like that can be useful.
I like the kernel's policy, which parallels our direction:
1) Enable and use lightweight assertions for most users.
2) No assertions with side effects
If you want to compile them out, that's fine, but they should always
be present in production software.
On Wed, Jun 4, 2014 at 6:20 AM, Mike Hearn <mike at plan99.net> wrote:
>> As a matter of procedure we do not use assertions with side effects— the
>> codebase did at one point, but have cleaned them up. In an abundance of
>> caution we also made it refuse to compile without assertions enabled: A
>> decision who's wisdom was clearly demonstrated when not long after, some
>> additional side-effect having assert was contributed. In the real world
>> errors happen here and there, and making robust software involves defense in
>> depth.
>
>
> I think this class of errors could be removed entirely by just saying it's
> OK for assertions to have side effects and requiring them to be enabled, as
> is currently done.
>
> The glog library:
>
> http://google-glog.googlecode.com/svn/trunk/doc/glog.html
>
> provides CHECK macros that print stack traces when they fail. Using them
> would also be good.
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> 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/

2023-06-07 17:21:55 CEST

- reply

📅 Original date posted:2014-05-22
📝 Original message:Related: Current multi-sig wallet technology being rolled out now,
with 2FA and other fancy doodads, is now arguably more secure than my
PGP keyring. My PGP keyring is, to draw an analogy, a non-multisig
wallet (set of keys), with all the associated theft/data
destruction/backup risks.
The more improvements I see in bitcoin wallets, the more antiquated my
PGP keyring appears. Zero concept of multisig. The PGP keyring
compromise process is rarely exercised. 2FA is lacking. At least
offline signing works well. Mostly.
On Wed, May 21, 2014 at 5:02 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Wed, May 21, 2014 at 1:30 PM, Mark Friedenbach <mark at monetize.io> wrote:
>> Honest question: what would signed commits do to help us here anyway?
>> What's the problem being solved?
>>
>> Unfortunately git places signatures in the history itself, so it's not
>> like we could use easily use signatures to indicate acceptance after
>> code review, like we could if we were using monotone for example. Git
>> just wasn't designed for a commit-signing workflow.
>
> Just makes it easier to sort out things like your git account (or the
> git site) being compromised and used to submit commits.
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> 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/

2023-06-07 17:21:49 CEST

- reply

📅 Original date posted:2014-05-20
📝 Original message:Yes, i spec'd out the UDP traversal of the P2P protocol. It seems
reasonable especially for "inv" messages.
On Tue, May 20, 2014 at 2:46 PM, Andy Alness <andy at coinbase.com> wrote:
> Has there ever been serious discussion on extending the protocol to
> support UDP transport? That would allow for NAT traversal and for many
> more people to run effective nodes. I'm also curious if it could be
> made improve block propagation time.
>
> On Tue, May 20, 2014 at 7:52 AM, Gmail <will.yager at gmail.com> wrote:
>> Unlikely. I doubt any significant portion of miners in china will continue to mine on a china-specific chain, since it will certainly be outmined by non-Chinese miners, and will be orphaned eventually.
>>
>> More likely is that mining interests in china will make special arrangements to circumvent the GFwOC.
>>
>> Users who can't access the worldwide blockchain will notice horrendously slow confirmation times and other side effects.
>>
>>> On May 20, 2014, at 10:37, Eugen Leitl <eugen at leitl.org>
>>>
>>> Could a blockchain fork due to network split happen?
>>>
>>
>> ------------------------------------------------------------------------------
>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>> Instantly run your Selenium tests across 300+ browser/OS combos.
>> Get unparalleled scalability from the best Selenium testing platform available
>> Simple to use. Nothing to install. Get started now for free."
>> http://p.sf.net/sfu/SauceLabs
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> --
> Andy Alness
> Software Engineer
> Coinbase
> San Francisco, CA
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> 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/

2023-06-07 17:21:43 CEST

- reply

📅 Original date posted:2014-05-19
📝 Original message:On Sun, May 18, 2014 at 1:43 PM, Raúl Martínez <rme at i-rme.es> wrote:
> - Allow users to view the bandwith used by Bitcoin Core:
+1 for the sake of transparency
HOWEVER, the impact on this feature RE user population is
unpredictable. Users may see bigger than expected numbers, and switch
off their node.
> - Educate users about the correct setup of a bitcoin node:
+1
> - bitcoind and Bitcoin Core should create a bitcoin.conf file on the first
Meh. I like example configs, perhaps tuned by the distro. If the
distro (_not_ Bitcoin Core upstream) chooses to install a bitcoin.conf
in the proper location, that's up to them.
> - bitcoind and Bitcoin Core should be in Linux repos:
Agreed with conditions:
1) The distro MUST let bitcoin devs dictate which dependent libs are
shipped with / built statically into the bitcoin binaries/libs.
2) The distro MUST permit fresh updates even to older stable distros.
2) The maintainer(s) MUST be active, and follow bitcoin development,
release status, etc. on a near-daily basis, be able to respond quickly
if security issues arise, etc.
Matt C seems to do a good job of this in Ubuntu PPA, I'm told.
> - Create a "grafical interface" for bitcoind on Linux servers:
> When I say "grafical interface" I mean like "top" command, an interface made
> out of characters in ASCII.
The best path for this is figure out what statistics you want to see,
and have bitcoind export those raw numbers to any willing consumer.
Then write your bitcoind-top on top of that.
> - Split Bitcoin Wallet from Bitcoin Node:
+1
In progress. Disable-wallet support, at compile time or runtime, was
the first step.
> - Inform users if 8333 port is closed:
+1
> - Keep connections if bitcoind is restarted:
> I noticed that if I restart bitcoind (to apply new config) my reset to 0 and
> take some hours to rise up to ~40. I believe that my peers should notice
> that I am down for less than ~15 minutes and try to connect again faster.
No, you don't want this (and it's not possible in many cases anyway).
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 17:21:26 CEST

- reply

📅 Original date posted:2014-05-19
📝 Original message:On Mon, May 19, 2014 at 4:36 PM, Robert McKay <robert at mckay.com> wrote:
> It should be possible to configure bind as a DNS forwarder.. this can
> be done in a zone context.. then you can forward the different zones to
> different dnsseed daemons running on different non-public IPs or two
> different ports on the same IP (or on one single non-public IP since
> there's really no reason to expose the dnsseed directly daemon at all).
Quite the opposite. dnsseed data rotates through a lot of addresses
if available. Using the bind/zone-xfer system would result in fewer
total addresses going through to the clients, thanks to the addition
of caching levels that the bind/zone-xfer system brings.
That said, if the choice is between no-service and bind, bind it is ;p
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 17:21:20 CEST

- reply

📅 Original date posted:2014-05-15
📝 Original message:On Thu, May 15, 2014 at 7:50 AM, Andreas Schildbach
<andreas at schildbach.de> wrote:
> I'm bringing this issue up again. The current Bitcoin DNS seed
> infrastructure is unstable. I assume this is because of we're using a
> custom DNS implementation which is not 100% compatible. There have been
> bugs in the past, like a case sensitive match for the domain name.
While I agree that the problem seeds should be fixed, it also sounds
like a problem with bitcoinj / other layers, if a malfunctioning seed
is a problem for your app.
Seeds are fundamentally a backup for peer exchange. You are going to
run into problems if you rely 100% on seeds, always.
Further, there are multiple seeds so that we are not impacted if a
couple seeds malfunction or die. All bitcoin apps must take this into
account.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 17:20:46 CEST

- reply

📅 Original date posted:2014-05-02
📝 Original message:<vendor hat: on>
Related: http://blog.bitpay.com/2014/05/02/bitpay-bitcoin-and-where-to-put-that-decimal-point.html
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 17:20:20 CEST

- reply

📅 Original date posted:2014-04-27
📝 Original message:On Sat, Apr 26, 2014 at 6:08 AM, Thomas Voegtlin <thomasv1 at gmx.de> wrote:
> Perhaps the only thing that needs to be standardized is the order of
> public keys in the redeem script: I think they should be sorted, so that
> the p2sh address does not depend on the order of pubkeys.
Yes. That solution is already implemented in a few wallets.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 17:17:43 CEST

- reply

📅 Original date posted:2014-04-08
📝 Original message:Being Mr. Torrent, I've held open the "80% serious" suggestion to
simply refuse to serve blocks older than X (3 months?).
That forces download by other means (presumably torrent).
I do not feel it is productive for any nodes on the network to waste
time/bandwidth/etc. serving static, ancient data. There remain, of
course, issues of older nodes and "getting the word out" that prevents
this switch from being flipped on tomorrow.
On Mon, Apr 7, 2014 at 2:49 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Mon, Apr 7, 2014 at 11:35 AM, Tamas Blummer <tamas at bitsofproof.com> wrote:
>> BTW, did we already agree on the service bits for an archive node?
>
> I'm still very concerned that a binary archive bit will cause extreme
> load hot-spotting and the kind of binary "Use lots of resources YES or
> NO" I think we're currently suffering some from, but at that point
> enshrined in the protocol.
>
> It would be much better to extend the addr messages so that nodes can
> indicate a range or two of blocks that they're serving, so that all
> nodes can contribute fractionally according to their means. E.g. if
> you want to offer up 8 GB of distributed storage and contribute to the
> availability of the blockchain, without having to swollow the whole
> 20, 30, 40 ... gigabyte pill.
>
> Already we need that kind of distributed storage for the most recent
> blocks to prevent extreme bandwidth load on archives, so extending it
> to arbitrary ranges is only more complicated because there is
> currently no room to signal it.
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> 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/

2023-06-07 17:17:22 CEST

- reply

📅 Original date posted:2014-04-08
📝 Original message:On Tue, Apr 8, 2014 at 4:13 AM, Mike Hearn <mike at plan99.net> wrote:
> I'd be careful with swift generalisations. It depends a lot on the value of
> your product. I didn't have any hangups about installing a plugin to use my
-You- are irrelevant, as am I. We don't mind such things.
But based on personal observations as well as Mozilla and other
browser data, the user populace in general does not install plugins.
Flash is the LONE exception to that ironclad general rule.
PS. Google Earth is not a plugin :)
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 17:17:20 CEST

- reply

📅 Original date posted:2014-04-04
📝 Original message:On Fri, Apr 4, 2014 at 9:43 AM, Mike Hearn <mike at plan99.net> wrote:
> These are the kinds of problems that crop up when you mix together two
> different things: the act of paying, and the act of identifying yourself.
This is precisely why SINs use a different version byte from bitcoin
addresses. There should never be any confusion between money/payments
and identity.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 17:16:54 CEST

- reply

📅 Original date posted:2014-04-04
📝 Original message:On Fri, Apr 4, 2014 at 3:01 AM, Wladimir <laanwj at gmail.com> wrote:
> Personally I'd prefer to standardize on ISO 8601 (YYYY-MM-DD) dates as well.
+1 for all-numeric, easily computer parse-able without a lookup table,
and naturally sorts correctly in a lexicographic sort.
English (or any language) should never be in a date format, on a computer.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 17:16:38 CEST

- reply

📅 Original date posted:2014-03-29
📝 Original message:On Sat, Mar 29, 2014 at 10:10 AM, Matt Whitlock <bip at mattwhitlock.name> wrote:
> Multisig does not allow for the topology I described. Say the board has seven directors, meaning the majority threshold is four. This means the organization needs the consent of six individuals in order to sign a transaction: the president, the CFO, and any four of the board members. A 6-of-9 multisig would not accomplish the same policy, as then any six board members could successfully sign a transaction without the consent of the president or CFO. Of course the multi-signature scheme could be expanded to allow for hierarchical threshold topologies, or Shamir's Secret Sharing can be used to distribute keys at the second level (and further, if desired).
Disagree with "does not allow" Review bitcoin's script language.
Bitcoin script can handle the use case you describe. Add conditionals
to the bitcoin script, OP_IF etc. You can do 'multisig AND multisig'
type boolean logic entirely in script, and be far more flexible than a
single CHECKMULTISIG affords.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 17:16:36 CEST

- reply

📅 Original date posted:2014-03-29
📝 Original message:The comparison with multisig fails to mention that multi-signature
transactions explicitly define security at the transaction level.
This permits fine-grained specificity of what a key holder may
approve.
Shamir is much more coarse-grained. You reconstitute a private key,
which may then be used to control anything that key controls. Thus,
in addition to Shamir itself, you need policies such as "no key
reuse."
My first impression of Shamir many moons ago was "cool!" but that's
since been tempered by thinking through the use cases. Shamir has a
higher D.I.Y. factor, with a correspondingly larger surface of
things-that-could-go-wrong, IMO.
(None of this implies making an informational BIP lacks value; I'm all
for an informational BIP)
On Sat, Mar 29, 2014 at 7:54 AM, Chris Beams <chris at beams.io> wrote:
> Enlightening; thanks, Matt. And apologies to the list for my earlier inadvertent double-post.
>
> On Mar 29, 2014, at 12:16 PM, Matt Whitlock <bip at mattwhitlock.name> wrote:
>
>> On Saturday, 29 March 2014, at 10:08 am, Chris Beams wrote:
>>> Matt, could you expand on use cases for which you see Shamir's Secret Sharing Scheme as the best tool for the job? In particular, when do you see that it would be superior to simply going with multisig in the first place? Perhaps you see these as complimentary approaches, toward defense-in-depth? In any case, the Motivation and Rationale sections of the BIP in its current form are silent on these questions.
>>
>> I have added two new sections to address your questions.
>>
>> https://github.com/whitslack/btctool/blob/bip/bip-xxxx.mediawiki
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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/

2023-06-07 17:16:17 CEST

- reply

📅 Original date posted:2014-03-27
📝 Original message:On Thu, Mar 27, 2014 at 3:09 AM, Tamas Blummer <tamas at bitsofproof.com> wrote:
> A notable suggestion was to instead of building a directory of magic numbers
> (like 0 for Bitcoin, 1 for Litecoin etc) use a hash of the word "Bitcoin",
> "Litecoin", "Dogecoin", so collosion is unlikely and
> cetral directory is not needed.
+1 good idea
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 17:16:05 CEST

- reply

📅 Original date posted:2014-03-25
📝 Original message:On Tue, Mar 25, 2014 at 9:49 AM, Peter Todd <pete at petertodd.org> wrote:
> For someone with 'Chief Scientist' as their job title, I'm surprised you
> think so little of hard evidence and so much of idol worshipping.
Peter, take this unprofessional, personal crap off-list.
Mike's anecdote of hostility is not an isolated one. Just today, a
bitcore developer commented on "Peter Todd's ..apocalyptic vision
and... negative view on bitcoin" which turned off some other
developers from participating more interactively.
As I commented on IRC, open source projects are no strangers to people
who simultaneously (a) make useful contributions and (b) turn
potential contributors away with an abrasive or hostile attitude
toward others. It's an unsolved problem in OSS, that I saw for 15+
years in the Linux kernel community.
For this list, as Mike suggested on IRC, introducing an openly stated
moderation policy may be the one route.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 17:15:36 CEST

- reply

📅 Original date posted:2014-03-13
📝 Original message:On Thu, Mar 13, 2014 at 1:18 PM, Mark Friedenbach <mark at monetize.io> wrote:
> Using milli- and micro- notation for currency units is also not very
> well supported. Last time this thread was active, I believe there was a
> suggestion to use 1 XBT == 1 uBTC. This would bring us completely within
> the realm of supported behavior in accounting applications.
Yes. That was in Tamas's recursive link, and also brought up on
github by jcorgan. +1
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 17:15:36 CEST

- reply

📅 Original date posted:2014-03-13
📝 Original message:On Thu, Mar 13, 2014 at 12:14 PM, Alan Reiner <etotheipi at gmail.com> wrote:
> Of course, as Mike said, this ship may have already sailed, but if
> there's any way to revisit this, I'm there. We're just about to do
> another Armory release and could support this very easily.
mBTC now just means the issue -will- be revisited in the future. Just
a question of when, not if.
People and software in various nations handle big numbers for small
values (e.g. Yen) just fine.
People and software do -not- handle extra decimal places well, field
experience shows.
<vendor hat: on> To roll out QuickBooks support --without converting
any numbers, a key financial attribute-- mBTC is simply insufficient
today, not in the future.
I also argue that it is a security risk, as follows: To support
accounting packages limited to 2 decimal places, decimal point
conversion must be performed. This produces a situation where your
accounting system shows numbers that do not visually match the numbers
in the bitcoin software. That, in turn, making auditing more
difficult, particularly for outsiders.
Shipping with mBTC defaults was decidedly unwise, considering that --
like BTC -- it fails to solve existing, known problems that uBTC can
solve, and considering the inevitable mBTC->uBTC switch.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 17:15:33 CEST

- reply

📅 Original date posted:2014-03-13
📝 Original message:On Thu, Mar 13, 2014 at 9:53 AM, Mike Hearn <mike at plan99.net> wrote:
> BitPay should use mBTC as well. Unless you can point to any major wallets,
> exchanges or price watching sites that use uBTC by default?
>
> I think it is highly optimistic to assume we'll need another 1000x shift any
> time soon. By now Bitcoin isn't obscure anymore. Lots of people have heard
Such hand-wavy, data-free logic is precisely why community
coordination is preferred to random apps making random decisions in
this manner.
mBTC is problematic because you do not need 1000x shift in value to
produce annoyances for major accounting packages that are hard-limited
to two decimal places. Further, spreadsheets hide information if
formatting is configured naively -- that is, if formatting is
configured for bitcoin the way it is configured for other currencies.
Fundamentally, more than two decimal places tends to violate the
Principle Of Least Astonishment with many humans, and as a result,
popular software systems have been written with that assumption.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 17:15:32 CEST

- reply

📅 Original date posted:2014-03-13
📝 Original message:<vendor hat: on>
Based on this seeming consensus, BitPay was headed towards uBTC
internally, and hoped to coordinate messaging and rollout with others
in the community. Ah well, proceed apace, and Bitcoin Wallet will
catch up, I suppose.
Multiple unit changes negatively impact users, but we are already there :/
On Thu, Mar 13, 2014 at 9:34 AM, Wladimir <laanwj at gmail.com> wrote:
>
> On Thu, Mar 13, 2014 at 1:56 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
>>
>> Resurrecting this topic. Bitcoin Wallet moved to mBTC several weeks
>> ago, which was disappointing -- it sounded like the consensus was
>> uBTC, and moving to uBTC later --which will happen-- may result in
>> additional user confusion, thanks to yet another decimal place
>> transition.
>
>
> I've kind of given up getting any consensus about this, or even getting
> people to care.
>
> Everyone agrees that a decimal shift would be good, but it's the same boring
> shed painting discussion every time on how many decimals. In the end nothing
> happens.
>
> I can't really blame Andreas for finally taking action and making the change
> to mBTC. People in the community are familiar with mBTC because some
> exchanges and price sites used mBTC (at least for a while when >$1000), also
> mBTC seems to be catching on on reddit etc.
>
> Moving to muBTC (which in itself would be better because it is the final
> unit change ever needed without hardfork) would require more coordinated
> education effort.
>
> Wladimir
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 17:15:10 CEST

- reply

📅 Original date posted:2014-03-12
📝 Original message:On Wed, Mar 12, 2014 at 5:48 AM, Mike Hearn <mike at plan99.net> wrote:
> CoinVault is also using a partially signed transaction format whereby
> 0-length placeholders are used for missing signatures in the transaction
> scripts.
>
> I don't know how you are implementing this/what framework you're using, but
> I suggest using placeholders that are the length of an actual expected
> signature, at least when forming the transaction. This is what bitcoinj will
> do because otherwise you could end up miscalculating the fee, which is based
> on the final size. See TransactionSignature.dummy() in the API.
The zero-length placeholder is not a new invention.
This is what bitcoind produces and expects by default, for a partially
signed transaction.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 17:15:06 CEST

- reply

📅 Original date posted:2014-03-11
📝 Original message:On Tue, Mar 11, 2014 at 10:23 AM, Gavin Andresen
<gavinandresen at gmail.com> wrote:
> If the remote party is one of the parties involved in a multisig, and speaks
> the "Lets set up a multisig wallet together / Lets spend from a multisig"
> protocols, then it should be perfectly reasonable to assume that they're
> HD-capable.
Disagree. It is an unnecessary restriction. People are already
writing and starting to deploy multisig wallets in the field, that do
not match this assumption.
In general, HD is really cool, but even the barest amount of
infrastructure is lacking. Popular libraries and the reference client
all lack support. Building a protocol that assumes HD is optimistic
at this stage.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 17:15:06 CEST

- reply

📅 Original date posted:2014-03-11
📝 Original message:(#include <rant.h>)
Right now, HD is hot air. Let us end the pie-in-the-sky assumptions
about how HD will save the day, with zero code to back it up. Bitcoin
Wallet purportedly fails to rotate addresses, a privacy ugly, because
of this Waiting For Godot situation. An attempt to add a simple,
stateless RPC stalled because we are all Waiting For Godot, also:
https://github.com/bitcoin/bitcoin/pull/3520
Until the major user wallets and bitcoind have -basic- HD support, it
is premature to build anything on top of HD. We really have no clue
at this juncture how difficult will be the HD rollout.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 17:15:05 CEST

- reply

📅 Original date posted:2014-03-11
📝 Original message:Sure, but I don't see wallets being able to _assume_ _remote_ parties
have an HD wallet for a long, long time. Interoperability common
sense implies the environment will be heterogenous, perhaps forever,
invalidating assume-each-party-uses-HD logic.
On Tue, Mar 11, 2014 at 9:51 AM, Gavin Andresen <gavinandresen at gmail.com> wrote:
> On Tue, Mar 11, 2014 at 8:38 AM, Jeff Garzik <jgarzik at bitpay.com> wrote:
>>
>> On Tue, Mar 11, 2014 at 7:43 AM, Drak <drak at zikula.org> wrote:
>> > I very much like the idea of assuming each party uses HD wallets, that
>> > certainly simplifies things greatly.
>>
>> It also assumes a reality different from our current one.
>
>
> Multisig wallets are a different reality from our current one, so when we
> move to that new reality we should do it correctly from the beginning.
>
> --
> --
> Gavin Andrese
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/