<unnamed>

Public Key

npub10plv6jx6pktpp5ezldnus6kj8ffg045g2kdjl78w23njrlveqy5s3pfaef

Profile Code

nprofile1qqs8slkdfrdqm9ss6v30ke7gdtfr555866y9txe0lrh9geeplkvsz2gpzpmhxue69uhkummnw3ezuamfdejsz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcx579f6

Publishing to

nostr.wine

relay.damus.io

Last Notes

2023-06-07 17:43:09 CEST

- reply

📅 Original date posted:2015-07-23
📝 Original message:The code so far is fairly limited in scope, essentially making it
possible to change the values in consensus/params.h based on block
height. The actual code to interpret those values does need to be
provided ahead of time, of course, so there's still developer time to
implement, it just moves consensus arguments to the users.
Loading the values from disk rather than hard-coding them is a
reasonably straight forward extension to the code, in theory. The
existing work has application-specific changes that would need stripping
out, but you can get an idea of what this would look like from
https://github.com/rnicoll/dogecoin/commit/949b1ccd88ff13c74a3c1a7b9faa7f36c1085904
Ross
On 23/07/2015 01:43, Eric Lombrozo via bitcoin-dev wrote:
>> On Jul 22, 2015, at 5:34 PM, Cory Fields <lists at coryfields.com> wrote:
>>
>> On Wed, Jul 22, 2015 at 8:13 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>>>> On Jul 22, 2015, at 5:05 PM, Cory Fields <lists at coryfields.com> wrote:
>>>>
>>>> On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>>>>> FWIW, I had worked on something similar a while back:
>>>>> https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf
>>>>>
>>>>> I like the idea in principle…but we should require a new genesis block,
>>>>> different magic bytes, and a different network port at the very least. :)
>>>>>
>>>> Not sure if serious, so I'll assume you are :)
>>> Only being partly serious - I strongly am in favor of a sufficiently modularized codebase that swapping out consensus rules is fairly straightforward and easy to test. I’m not in favor of encouraging forking an existing blockchain without having mechanisms in place to gracefully merge back without significant network disruptions. We do not have this yet.
>>>
>> Again, why? If someone wants to create a scamcoin, they can. If
>> someone wants to burn money on a scamcoin, equally, they can. I'm not
>> sure how this is any different. If someone manages to garner realistic
>> support for a hard-fork, I don't see the benefit in forcing them to
>> use forked software.. that only leaves Core in the middle because it's
>> forced to choose a side (not choosing is unfortunately a side as
>> well). It doesn't remove the reality of the split.
> In general, new consensus rules are not trivial to implement. Block size limits are exceptional in being so simple to change in the code. So what you’re proposing sounds more like a plugin model supporting dynamic linking than a configuration file.
>
>>>> Why? The idea in this case would be to allow the user to decide
>>>> between (say) "./bitcoind -1mbchain" and "./bitcoind -2mbchain" at
>>>> runtime rather than the likely alternative of "./bitcoind" vs
>>>> "./bitcoin-fork”.
>>> That’s exactly what my coinparams_new branch does. Adding a parameter for maximum block size would be straightforward.
>>>
>>>> Chain params may be identical other than the value of some future
>>>> event (miner vote for example), in which case the configs would run
>>>> identically until that point.
>>> Yes, indeed - this would be a special case.
>>>
>>>> If your concern is about nodes with different configs communicating
>>>> with eachother, I'd like to reiterate: the idea really is no different
>>>> than suggesting that someone fork the codebase and implement their own
>>>> changes, it just cuts out most of the work required.
>>> I do not encourage anyone to try to fork an existing blockchain without first securing overwhelming (near unanimous) consensus…or without having yet built a mechanism that can merge divergent chains gracefully.
>> Well of course. It would be a terrible idea. People would try it and
>> fail, and lose money. But for those crying foul at Core for being the
>> consensus/policy gatekeeper, it seems to me that user-selectable
>> params is the only logical solution.
> The real problem isn’t so much the difficulty of creating forks of the codebase - but the fact that unless a fork has overwhelming support, blockchains cannot guarantee irreversibility of transactions…which defeats their entire purpose.
>
>
> _______________________________________________
> 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/20150723/e1376731/attachment.html>

2023-06-07 17:42:40 CEST

- reply

📅 Original date posted:2015-07-20
📝 Original message:I take it there's no feasibility in suggesting the script execution code
has run time maximums? I'm aware these would be much harder to have
consensus on, but would seem like the better solution if at all possible.
Ross
On 20/07/2015 20:10, Gavin Andresen via bitcoin-dev wrote:
> Draft BIP to prevent a potential CPU exhaustion attack if a
> significantly larger maximum blocksize is adopted:
>
> Title: Limit maximum transaction size
> Author: Gavin Andresen <gavinandresen at gmail.com
> <mailto:gavinandresen at gmail.com>>
> Status: Draft
> Type: Standards Track
> Created: 2015-07-17
>
> ==Abstract==
>
> Mitigate a potential CPU exhaustion denial-of-service attack by limiting
> the maximum size of a transaction included in a block.
>
> ==Motivation==
>
> Sergio Demian Lerner reported that a maliciously constructed block could
> take several minutes to validate, due to the way signature hashes are
> computed for OP_CHECKSIG/OP_CHECKMULTISIG
> ([[https://bitcointalk.org/?topic=140078|CVE-2013-2292]]
> <https://bitcointalk.org/?topic=140078%7CCVE-2013-2292]]>).
> Each signature validation can require hashing most of the transaction's
> bytes, resulting in O(s*b) scaling (where n is the number of signature
> operations and m is the number of bytes in the transaction, excluding
> signatures). If there are no limits on n or m the result is O(n^2)
> scaling.
>
> This potential attack was mitigated by changing the default relay and
> mining policies so transactions larger than 100,000 bytes were not
> relayed across the network or included in blocks. However, a miner
> not following the default policy could choose to include a
> transaction that filled the entire one-megaybte block and took
> a long time to validate.
>
> ==Specification==
>
> After deployment, the maximum serialized size of a transaction allowed
> in a block shall be 100,000 bytes.
>
> ==Compatibility==
>
> This change should be compatible with existing transaction-creation
> software,
> because transactions larger than 100,000 bytes have been considered
> "non-standard"
> (they are not relayed or mined by default) for years.
>
> Software that assembles transactions into blocks and that validates
> blocks must be
> updated to reject oversize transactions.
>
> ==Deployment==
>
> This change will be deployed with BIP 100 or BIP 101.
>
> ==Discussion==
>
> Alternatives to this BIP:
>
> 1. A new consensus rule that limits the number of signature operations
> in a
> single transaction instead of limiting size. This might be more
> compatible with
> future opcodes that require larger-than-100,000-byte transactions,
> although
> any such future opcodes would likely require changes to the Script
> validation
> rules anyway (e.g. the 520-byte limit on data items).
>
> 2. Fix the SIG opcodes so they don't re-hash variations of the
> transaction's data.
> This is the "most correct" solution, but would require updating every
> piece of transaction-creating and transaction-validating software to
> change how
> they compute the signature hash.
>
> ==References==
>
> [[https://bitcointalk.org/?topic=140078|CVE-2013-2292]
> <https://bitcointalk.org/?topic=140078%7CCVE-2013-2292]>]: Sergio
> Demian Lerner's original report
>
>
>
>
>
> _______________________________________________
> 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/20150720/b969dd16/attachment.html>

2023-06-07 17:42:33 CEST

- reply

📅 Original date posted:2015-07-21
📝 Original message:Not so much that the implementation is difficult, as it requires context
to validate a block size, rather than being able to validate it without
requiring the preceeding blocks. Yes, time on different machines may
vary, but block time is safe to use for this, because it's a
straight-forward test of "if block time is acceptable and block time is
after <date> then maximum block size allowed is n MB otherwise m MB".
Ross
On 21/07/2015 10:26, Jorge Timón wrote:
> I still disagree. Using height instead of time may make the
> implementation more complex by requiring some additional preparations
> but using height is in fact a simpler design. Why relay on clocks that
> we know will differ in different computers and places when we have a
> universal tick with every block?
>
> Btw, BIP16 and BIP34 could be changed to height-based activation
> already. BIP16 simply should have used height instead of time from the
> beginning.
>
> On Mon, Jul 20, 2015 at 12:51 AM, Ross Nicoll via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> Further to that - please disregard what I said about using block height. Had
>> failed to realise that in using contextual information (block height) it
>> complicates block validation (i.e. it would be impossible to tell if a block
>> is too big, without having all previous blocks first). Block time is in fact
>> the better option.
>>
>> Ross
>>
>>
>> On 17/07/2015 18:57, Ross Nicoll via bitcoin-dev wrote:
>>
>> I'd back this if we can't find a permanent solution - 2MB gives us a lot
>> more wiggle room in the interim at least; one of my concerns with block size
>> is 3 transactions per second is absolutely tiny, and we need space for the
>> network to search for an equilibrium between volume and pricing without risk
>> of an adoption spike rendering it essentially unusable.
>>
>> I'd favour switching over by block height rather than time, and I'd suggest
>> that given virtually every wallet/node out there will require testing (even
>> if many do not currently enforce a limit and therefore do not need
>> changing), 6 months should be considered a minimum target. I'd open with a
>> suggestion of block 390k as a target.
>>
>> Ross
>>
>> On 17/07/2015 16:55, Jeff Garzik via bitcoin-dev wrote:
>>
>> 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.
>>
>>
>>
>>
>> _______________________________________________
>> 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
>>

2023-06-07 17:42:30 CEST

- reply

📅 Original date posted:2015-07-19
📝 Original message:Further to that - please disregard what I said about using block height.
Had failed to realise that in using contextual information (block
height) it complicates block validation (i.e. it would be impossible to
tell if a block is too big, without having all previous blocks first).
Block time is in fact the better option.
Ross
On 17/07/2015 18:57, Ross Nicoll via bitcoin-dev wrote:
> I'd back this if we can't find a permanent solution - 2MB gives us a
> lot more wiggle room in the interim at least; one of my concerns with
> block size is 3 transactions per second is absolutely tiny, and we
> need space for the network to search for an equilibrium between volume
> and pricing without risk of an adoption spike rendering it essentially
> unusable.
>
> I'd favour switching over by block height rather than time, and I'd
> suggest that given virtually every wallet/node out there will require
> testing (even if many do not currently enforce a limit and therefore
> do not need changing), 6 months should be considered a minimum target.
> I'd open with a suggestion of block 390k as a target.
>
> Ross
>
> On 17/07/2015 16:55, Jeff Garzik via bitcoin-dev wrote:
>> 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.
>>
>>
>>
>>
>> _______________________________________________
>> 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/20150719/f1ee52d6/attachment.html>

2023-06-07 17:42:29 CEST

- reply

📅 Original date posted:2015-07-17
📝 Original message:I'll leave others to comment on whether we can get consensus on that,
but your years listed are inconsistent with everything else you've
written. Should be:
block 400,000 = 2MB (2016)
block 500,000 = 4MB (2018)
block 600,000 = 8MB (2020)
On 17/07/2015 20:06, Chris Wardell via bitcoin-dev wrote:
> I would prefer a dynamic solution that did not necessitate a second
> hard fork down the road.
>
> I propose doubling the block size every 100k blocks (~2 years)
>
> block 400,000 = 2MB (2016)
> block 500,000 = 4MB (2017)
> block 600,000 = 8MB (2018)
>
> Chris
>
>
> On Fri, Jul 17, 2015 at 1:57 PM, Ross Nicoll via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> I'd back this if we can't find a permanent solution - 2MB gives us
> a lot more wiggle room in the interim at least; one of my concerns
> with block size is 3 transactions per second is absolutely tiny,
> and we need space for the network to search for an equilibrium
> between volume and pricing without risk of an adoption spike
> rendering it essentially unusable.
>
> I'd favour switching over by block height rather than time, and
> I'd suggest that given virtually every wallet/node out there will
> require testing (even if many do not currently enforce a limit and
> therefore do not need changing), 6 months should be considered a
> minimum target. I'd open with a suggestion of block 390k as a target.
>
> Ross
>
>
> On 17/07/2015 16:55, Jeff Garzik via bitcoin-dev wrote:
>> 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.
>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto: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/20150717/201c99fb/attachment-0001.html>

2023-06-07 17:42:29 CEST

- reply

📅 Original date posted:2015-07-17
📝 Original message:I'd back this if we can't find a permanent solution - 2MB gives us a lot
more wiggle room in the interim at least; one of my concerns with block
size is 3 transactions per second is absolutely tiny, and we need space
for the network to search for an equilibrium between volume and pricing
without risk of an adoption spike rendering it essentially unusable.
I'd favour switching over by block height rather than time, and I'd
suggest that given virtually every wallet/node out there will require
testing (even if many do not currently enforce a limit and therefore do
not need changing), 6 months should be considered a minimum target. I'd
open with a suggestion of block 390k as a target.
Ross
On 17/07/2015 16:55, Jeff Garzik via bitcoin-dev wrote:
> 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.
>
>
>
>
> _______________________________________________
> 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/20150717/2d34be24/attachment.html>

2023-06-07 17:40:32 CEST

- reply

📅 Original date posted:2015-06-26
📝 Original message:I'd argue that at the point where there's consistently more transactions
than the network can handle, there are two significant risks. Firstly,
that people don't care enough to pay the transaction fees required to
get their transaction prioritised over another's, and secondly that as
transactions start outright failing (which will happen with enough
transactions backlogged) the network is considered unreliable, the
currency illiquid, and there's a virtual "bank rush" to get into a more
usable currency.
I understand the desire to use current demand to model future, however I
feel there's a lack of understanding of just how inadequate the main
chain is as a global clearance network. My go-to example for this is
CHIPS (US-only, inter-bank only clearance) which already handles
slightly over 3 transactions per second on average across a year
(https://www.theclearinghouse.org/~/media/tch/pay%20co/chips/reports%20and%20guides/chips%20volume%20through%20may%202015.pdf?la=en).
If Bitcoin is to be used across a wider portion of the world's
population, and/or beyond clearance between financial institutions, it
needs larger blocks. This is not about handling the several orders of
magnitude more transactions that would be required to replace credit
cards or cash, but simply to enabling other technologies to perform that
scaling.
Also, and I'm aware most on this list do understand the situation better
than this, I find it immensely frustrating to see people suggesting that
Greece or other large groups should adopt Bitcoin, while there's clearly
inadequate support (on chain or off) to do so.
Ross
On 26/06/2015 19:34, Pieter Wuille wrote:
>
> > If you wait until the need to increase block size
>
> It is this sentence I disagree with. Why would there be a need?
> Bitcoin provides utility at any block size, and potentially more with
> larger blocks.
>
> But no matter what, I believe the economy will adapt to what is
> available. And setting a precedent that increasing the size "because
> of a need" is reasonable is to me essentially the same as saying the
> size should forever scale to whatever people want.
>
> I believe the most important effect of a limit block size - people
> deciding not to use (on chain) Bitcoin transactions, is already
> happening, and it will keep happening at any scale.
>
> Either the resulting market is one which can live with high
> variability in confirmation times, and blocks will end up being nearly
> full. Or maybe the current fill level is what is acceptable, and we
> don't see much growth beyond this, only a change in what it is used for.
>
> --
> 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/a81ace1f/attachment.html>

2023-06-07 17:39:42 CEST

- reply

📅 Original date posted:2015-06-23
📝 Original message:I don't think essentially replacing most of Testnet with a specialised
test chain is a good idea, but this might be a good time to consider a
4th test network with very large blocks from genesis onwards.
I do tend to think 2 years of 8mb blocks is excessive as a test, too,
and while certainly large projects should have or can raise funds for
test infrastructure, I would worry about the smaller stuff out there. Is
there anything specific 2 years gives us over, say, 6 months?
Ross
On 22/06/2015 20:23, Peter Todd wrote:
> On Mon, Jun 22, 2015 at 02:18:19PM -0400, 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
> It's important that we see a wide range of realistic testing of what an
> 8MB limit could look in the near future. An important part of that
> testing is load testing.
>
> As of writing the BIP above has no mention of what switchover rules will
> be used for testnet; code floating around has August 1st 2015 as that
> date. I propose we use August 1st 2013.
>
> This switch over date should be set in the _past_ to allow for the
> creation (via reorg) of a realistic full-load blockchain on testnet to
> fully test the real-world behavior of the entire infrastructure
> ecosystem, including questions like the scalability of block explorers,
> SPV wallets, feasibility of initial syncronization, scalability of the
> UTXO set, etc. While this is of course inconvenient - 2 years of 8MB
> blocks is 840GB worth of data - the Bitcoin ecosystem can-not afford to
> make a change like this blindly.
>
> I'm sure with a $3.5 billion market cap at stake we can scrape together
> the resources to voluntarily run a few hundred full-load full-nodes for
> testing a change with the potential to destroy that market cap.
>
>
>
> _______________________________________________
> 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/7a41e361/attachment.html>

2023-06-07 17:38:39 CEST

- reply

📅 Original date posted:2015-06-18
📝 Original message:There's some actually proposing inaction as an outright decision, but I
more meant that at times it has felt like we would end up with inaction
through momentum, combined with adoption rate making any hard fork more
complex if it continues to be delayed.
On 18/06/2015 22:42, Matt Whitlock wrote:
> On Thursday, 18 June 2015, at 8:31 pm, Ross Nicoll wrote:
>> I may disagree with Mike & Gavin on timescale, but I do believe there's
>> a likelihood inaction will kill Bitcoin
> An honest question: who is proposing inaction? I haven't seen anyone in this whole, agonizing debate arguing that 1MB blocks are adequate. The debate has been about *how* to increase the block-size limit and whether to take action ASAP (at the risk of fracturing Bitcoin) or to delay action for further debate (at the risk of overloading Bitcoin). Even those who are arguing for further debate are not arguing for *inaction*.

2023-06-07 17:38:36 CEST

- reply

📅 Original date posted:2015-06-18
📝 Original message:I'm struggling to illustrate how incredibly low 7 transactions per
second is, not just for a payment network, but even just for a clearance
network (i.e. to balance transactions between institutions and/or
chains). As an example, the Clearing House Interbank Payments System
(CHIPS) is a US-only, inter-bank only clearance network, which handled
about 3.5 transactions per second (average) in 2014
(https://www.theclearinghouse.org/~/media/tch/pay%20co/chips/reports%20and%20guides/chips%20volume%20through%20may%202015.pdf?la=en).
While it seems likely the US population of 300 million makes more
transactions individually than many other countries, and therefore we
can't simply multiply that by 20 to estimate what a global clearance
network might require, hopefully it's clear that if Bitcoin is to scale
globally, it needs substantially more transaction throughput even if
main chain transactions become something for banks and the super rich. I
don't know how much more, but I can't look at the 8MB reportedly backed
by a number of mining pools and say it's clearly insufficient, at least.
I should emphasise that I don't think we need to jump straight to 8MB
(or otherwise), if a scaling protocol can be decided upon that would be
ideal, but we should be planning ahead while it's still relatively easy
to make these changes.
Ross
On 18/06/2015 23:33, Mark Friedenbach wrote:
> On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik <jgarzik at bitpay.com
> <mailto:jgarzik at bitpay.com>> wrote:
>
>
> The whole point is getting out in front of the need, to prevent
> significant negative impact to users when blocks are consistently
> full.
>
> To do that, you need to (a) plan forward, in order to (b) set a
> hard fork date in the future.
>
>
> Or alternatively, fix the reasons why users would have negative
> experiences with full blocks, chiefly:
>
> * Get safe forms of replace-by-fee and child-pays-for-parent
> finished and in 0.12.
> * Develop cross-platform libraries for managing micropayment
> channels, and get wallet authors to adopt
> * Use fidelity bonds, solvency proofs, and other tricks to minimize
> the risk of already deployed off-chain solutions as an interim measure
> until:
> * Deploy soft-fork changes for truly scalable solutions like
> Lightning Network.
>
> Not raising the block size limit does not mean doing nothing to solve
> the problem.
>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/bdee73d5/attachment.html>

2023-06-07 17:38:34 CEST

- reply

📅 Original date posted:2015-06-18
📝 Original message:I've got a few thoughts on this, but they don't really attach well to a
single message, so starting a fresh message in the same thread. I'm
going to try being brief.
There's a lot of talk about not forking. Sorry, but they're going to
happen, planned and unplanned. Even if no intentional forks occur from
here on, I hope it's obvious that there will be further accidental forks
(at least unless and until someone prepares a formal proof of a Bitcoin
wallet). We need to be more comfortable with that, and plan ahead.
Education is key here, a lot of people don't understand what a fork is,
how it will affect them, how to recognise a fork or how to recover. I'll
dig out what materials I've written already and try making them more
widely available, as a start.
On whether code forks are a solution to disagreements - I'm not quite
sure what people expect will happen where a group believes there is an
existential threat to Bitcoin and they cannot get Bitcoin Core updated.
I may disagree with Mike & Gavin on timescale, but I do believe there's
a likelihood inaction will kill Bitcoin, and in that context I see the
rational choice as taking the perceived smaller risk of a fork killing
Bitcoin. BIP100 appears to be making progress, however, right now I
think the best option is pursuing it towards something that can be
agreed on by all. I would also happily go with an 8MB block size even if
just to buy us (IMHO a lot) more time.
Lastly, there seems to be a number of people who believe inaction
through apathy is fine. I respect those who form considered opinions and
tell me why they believe 1MB is fine, but I do ask that people either
put the effort in to help make decisions, or delegate to someone else.
Decentralised does not mean there's no decision making, it means we're
all decision makers, and frankly I think there's effectively negligence
in that capacity right now. I'd also point out this ongoing discussion
is a huge time sink to a number of people who could be making much more
useful contributions, and that again going in circles endlessly
discussing in the name of decentralisation isn't positive.
I have failed at being brief, apologies.
Ross

2023-06-07 17:33:16 CEST

- reply

📅 Original date posted:2015-05-07
📝 Original message:Can I just add my own support for this - as has been stated elsewhere in
this discussion, hard forks are difficult, and risky. The earlier we
have a decision, and the earlier the change goes into the code, the
easier that is.
Even if the decision was the actual block size change is fine to leave
until 2020, I'd like to see the code committed ASAP so that every new
install, and every upgrade from there on gets the new version.
My personal opinion only is that 7 transactions a second is insanely
limited even if the main chain does nothing but act as a backbone
between other chains and transaction networks. I don't think that's
overly controversial. I think 2016 is too early for a 20mb block size,
though. I'm inclined to suggest a schedule of expansion, say to 2mb in
2016, 4mb in 2018, 8mb in 2020 and 20mb in 2022 where it stops. The
intent would be to provide enough size pressure to motivate scaling
work, while not limiting Bitcoin overly.
Further, I think this highlights that we need more work on fees. Right
now fees and transactions included are fairly naive, but I'd like to see
the absolute block size limit as a hard upper bound, with miners
imposing soft limits based on a balance cost of storage, number of
outputs vs inputs (and therefore impact on the UTXOs), and risk of
orphan blocks to determine which transactions are actually worth
including in each block. If anyone has numbers on block size vs orphan
rate that would be really useful, BTW.
Ross
On 07/05/2015 19:06, Mike Hearn wrote:
>
> I think you are rubbing against your own presupposition that
> people must find and alternative right now. Quite a lot here do
> not believe there is any urgency, nor that there is an immanent
> problem that has to be solved before the sky falls in.
>
>
> I have explained why I believe there is some urgency, whereby "some
> urgency" I mean, assuming it takes months to implement, merge, test,
> release and for people to upgrade.
>
> But if it makes you happy, imagine that this discussion happens all
> over again next year and I ask the same question.
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/11ec6034/attachment.html>

2023-06-07 17:30:18 CEST

- reply

📅 Original date posted:2015-02-14
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Arriving slightly late to the discussion, apologies.
Personally I wouldn't have written that patch, but I know development of
hostile patches happens out of sight, and if it can be written, we have
to presume it will be written eventually. I'd have preferred a patch
that only replaced non-final txes, which is the use-case I have for
transaction replacement, but that's easy to add back in.
I'm certainly not terribly convinced of the security of vanilla
zero-confirmation transactions myself, for reasons including but not
limited to this case. I also think it's important to understand that
people do make irrational decisions, and trusting network security on
everyone behaving perfectly rationally is not a workable model either.
TLDR; me too
Ross
On 12/02/15 20:36, Allen Piscitello wrote:
> You keep making moral judgements. Reality is, if you live in a world with
> arsonists, you need to have a building that won't catch on fire, or has
> fire extinguishers in place. Do not depend on arsonists ignoring you
> forever as your security model. Penetration testing to know what
> weaknesses exist, what limitations exist, and what can be improved is
> essential. Keeping your head in the sand and hoping people choose to do
> the right thing only ends one way.
>
> On Thu, Feb 12, 2015 at 1:52 PM, Justus Ranvier <justusranvier at riseup.net>
> wrote:
>
> On 02/12/2015 07:47 PM, Allen Piscitello wrote:
> >>> Nothing will stop that. Bitcoin needs to deal with those issues,
> >>> not stick our heads in the sand and pretend they don't exist out of
> >>> benevolence. This isn't a pet solution, but the rules of the
> >>> protocol and what is realistically possible given the nature of
> >>> distributed consensus. Relying on altruism is a recipe for
> >>> failure.
>
> If there's a risk of fire burning down wooden buildings, pass out fire
> extinguishers and smoke detectors, not matches.
>
> The latter makes one an arsonist.
>
>>
>>
>>
------------------------------------------------------------------------------
>> 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
>>
>>
>
>
>
>
------------------------------------------------------------------------------
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJU31/yAAoJEJFC5fflM8475YIIAI7nxgxUdkKiMePMqtvPOi25
U+WCxjvIK0ZRTAV30POC7fKLT2mK0gPusSS7LtNJpPKvpC98VcSD5HWE49K80Yo9
9+QI7X7xBau1jjLo+27uOex0bJ6JwP1DSMpC12AQbMmi4FnyG+M5FMkr5/OnSxeF
cd4lT2UF7yTJPRy0+A9LwertL5Sv1yeOJJ9jtWuXgixapmHN+1Zm2VkGnur55V64
vnonlixlUMwnZNxDVoRhjTWm1P/lmCejvmvTRvcBomUlAEgRQF4TtF4YMBYXS97S
5WYrxOHLgTfTWr3FJuOnd+CVBRgZGw3u30ktaSErelyMG19lJOusBPdHTQFkV30=
=eWPj
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150214/e1b3a085/attachment.html>

2023-06-07 17:28:38 CEST

- reply

📅 Original date posted:2015-01-25
📝 Original message:That was essentially what we did in the end, we replaced the network
identifier ("main"/"test") with the genesis block hash. The result is
never going to accidentally work with Bitcoin Core (nor vice-versa), but
is readily extensible to any other altcoins that want to use the
specification without requiring any sort of central registry.
Ross
On 24/01/15 13:19, Isidor Zeuner wrote:
>> For what it's worth, there was consideration of replacing protocol
>> buffers when modifying BIP70 to function with the altcoin I work on
>> (changes were required anyway in eliminate any risk that payment
>> requests could not be accidentally applied to the wrong blockchain).
>
> Why not serialize some kind of blockchain identifier with the
> messages? Arbitrarily deviating from a given design choice just for
> the sake of doing it differently may serve the goal of creating more
> overall code diversity, but would not necessarily serve the quality of
> the blockchain network where it is done for.
>
> Best regards,
>
> Isidor

2023-06-07 17:28:37 CEST

- reply

📅 Original date posted:2015-01-19
📝 Original message:For what it's worth, there was consideration of replacing protocol
buffers when modifying BIP70 to function with the altcoin I work on
(changes were required anyway in eliminate any risk that payment
requests could not be accidentally applied to the wrong blockchain). The
eventual conclusion was that while we might have used JSON or XML if we
were starting from scratch, there's no choice that's clearly better.
While deployed infrastructure for payment protocol is still quite
limited, it seems that the cost to replace at this point is higher than not.
If there's ever a major reworking of the standard, for example to handle
recurring payments, it's probably worth thinking about then, but
protocol buffers result in a compact data format which is supported by
most major languages (and size is a concern if dealing with Bluetooth or
NFC), and has no major drawbacks I am aware of.
Ross
On 19/01/2015 20:40, Mike Hearn 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's not guaranteed no, which is why we store signed sub-messages as byte
> arrays instead of typed submessages. In practice though, most
> implementations do seem to serialise things the same way. I recall Python
> used to be an odd one out, unsure if it still is.
>
> OK, I guess we can boil this down more simply. BIP 70 uses protocol buffers
> because I designed it and implemented the original prototype (with lots of
> input from Gavin and an earlier proposal by sipa). I used protocol buffers
> because, beyond all their nice properties, I used to work at Google and so
> was very familiar with them.
>
>
>
> ------------------------------------------------------------------------------
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150119/c508d0e9/attachment.html>

2023-06-07 17:26:49 CEST

- reply

📅 Original date posted:2014-10-25
📝 Original message:I'd suggest looking at how Dogecoin's mining schedule has worked out,
for how halvings tend to actually affect the market. Part of Dogecoin's
design was that it would halve very quickly (around every 75 days, in
fact), so it's essentially illustrating worst case scenario.
Firstly, miners do not all move/shut down as a batch. Some will stay out
of loyalty/apathy/optimism, so there's a jolt to hashrate when the
rewards drop, and then a drift towards a steady-state. In most cases,
the hardware costs vastly exceed the running costs, so while they may
never see ROI due to the reward change, there's no benefit in stopping
mining either.
On the other side, mining hardware update cycles are extremely
aggressive, and newer hardware runs much faster. Further, those with
newer hardware are likely to have the best hashrate to power ratio, and
be less likely to turn off or rent out their hardware.
So, in theory there may be an uncomfortable period where the hashrate
drops, but I would expect that drop to be much less than 50%, that most
hardware that's turned off is not cost-effective to rent out, and that
newer hardware being launched would push the hashrate back up again
within a sensible timeframe.
Ross
On 25/10/2014 19:06, Alex Mizrahi wrote:
> # Death by halving
>
> ## Summary
>
> If miner's income margin are less than 50% (which is a healthy
> situation when mining hardware is readily available), we might
> experience catastrophic loss of hashpower (and, more importantly,
> catastrophic loss of security) after reward halving.
>
> ## A simple model
>
> Let's define miner's income margin as `MIM = (R-C_e)/R`, where R is
> the total revenue miner receives over a period of time, and C_e is the
> cost of electricity spent on mining over the same period of time.
> (Note that for the sake of simplicity we do not take into account
> equipment costs, amortization and other costs mining might incur.)
>
> Also we will assume that transaction fees collected by miner are
> negligible as compared to the subsidy.
>
> Theorem 1. If for a certain miner MIM is less than 0.5 before subsidy
> halving and bitcoin and electricity prices stay the same, then mining
> is no longer profitable after the halving.
>
> Indeed, suppose the revenue after the halving is R' = R/2.
> MIM = (R-C_e)/R < 0.5
> R/2 < C_e.
>
> R' = R/2 < C_e.
>
> If revenue after halving R' doesn't cover electricity cost, a rational
> miner should stop mining, as it's cheaper to acquire bitcoins from the
> market.
>
> ~~~
>
> Under these assumptions, if the majority of miners have MIM less than
> 0.5, Bitcoin is going to experience a significant loss of hashing power.
> But are these assumptions reasonable? We need a study a more complex
> model which takes into account changes in bitcoin price and difficulty
> changes over time.
> But, first, let's analyze significance of 'loss of hashpower'.
>
> ## Catastrophic loss of hashpower
>
> Bitcoin security model relies on assumption that a malicious actor
> cannot acquire more than 50% of network's current hashpower.
> E.g. there is a table in Rosenfeld's _Analysis of Hashrate-Based
> Double Spending_ paper which shows that as long as the malicious actor
> controls only a small fraction of total hashpower, attacks have
> well-define costs. But if the attacker-controlled hashrate is higher
> than 50%, attacks become virtually costless, as the attacker receives
> double-spending revenue on top of his mining revenue, and his risk is
> close to zero.
>
> Note that the simple model described in the aforementioned paper
> doesn't take into account attack's effect on the bitcoin price and the
> price of the Bitcoin mining equipment. I hope that one day we'll see
> more elaborate attack models, but in the meantime, we'll have to
> resort to hand-waving.
>
> Consider a situation where almost all available hashpower is available
> for a lease to the highest bidder on the open market. In this case
> someone who owns sufficient capital could easily pull off an attack.
>
> But why is hashpower not available on the market? Quite likely
> equipment owners are aware of the fact that such an attack would make
> Bitcoin useless, and thus worthless, which would also make their
> equipment worthless. Thus they prefer to do mining for a known mining
> pools with good track record.
> (Although hashpower marketplaces exist: https://nicehash.com/ they
> aren't particularly popular.)
>
> Now let's consider a situation where mining bitcoins is no longer
> profitable and the majority of hashpower became dormant, i.e. miners
> turned off their equipment or went to mine something else. In this
> case equipment is already nearly worthless, so people might as well
> lease it to the highest bidder, thus enabling aforementioned attacks.
>
> Alternatively, the attacker might buy obsolete mining equipment from
> people who are no longer interested in mining.
>
> ## Taking into account the Bitcoin price
>
> This is largely trivial, and thus is left as an exercise for the
> reader. Let's just note that the Bitcoin subsidy halving is an event
> which is known to market participants in advance, and thus it
> shouldn't result in significant changes of the Bitcoin price,
>
> ## Changes in difficulty
>
> Different mining devices have different efficiency. After the reward
> halving mining on some of these devices becomes unprofitable, thus
> they will drop out, which will result in a drop of mining difficulty.
>
> We can greatly simplify calculations if we sum costs and rewards
> across all miners, thus calculating average MIM before the halving:
> `MIM = 1 - C_e/R`.
>
> Let's consider an equilibrium break-even situation where unprofitable
> mining devices were turned off, thus resulting in the change in
> electricity expenditures: `C_e' = r * C_e`. and average MIM after the
> halving `MIM' = 0`. In this case:
>
> r * C_e = R/2
> C_e / R = 1/2r
> (1 - MIM) = 1/2r
> r = 1/(2*(1-MIM))
>
> Let's evaluate this formulate for different before-halving MIM:
>
> 1. If `MIM = 0.5`, then `r = 1/(2*0.5) = 1`, that is, all miners can
> remain mining.
> 2. If `MIM = 0.25`, then `r = 1/(2*0.75) = 0.66`, the least efficient
> miners consuming 33% of total electricity costs will drop out.
> 3. If `MIM = 0.1`, then `r = 1/(2*0.9) = 0.55`, total electricity
> costs drop by 45%.
>
> We can note that for the before-halving MIM>0, r is higher than 1/2,
> thus less than half of total hashpower will drop out.
>
> The worst-case situation is when before-halving MIM is close to zero
> and mining devices, as well as cost of electricity in different
> places, are nearly identical, in that case approximately a half of all
> hashpower will drop out.
>
> ## MIM estimation
>
> OK, what MIM do we expect in the long run? Is it going to be less than
> 50% anyway?
>
> We can expect that people will keep buying mining devices as long as
> it is profitable.
>
> Break-even condition: `R - C_e - P = 0`, where P is the price of a
> mining device, R is the revenue it generates over its lifetime, and
> C_e is the total cost of required electricity over its lifetime. In
> this case, `R = C_e + P`, and thus:
>
> MIM = 1 - C_e / (C_e + P)
>
> `f = C_e / P` is a ratio of the cost of electricity to the cost of
> hardware, `C_e = f * P`, and thus
>
> MIM = 1 - f * P / (f * P + P) = 1 - f / (f + 1) = 1 / (1 + f)
>
> MIM is less than 0.5 when f > 1.
>
> Computing f is somewhat challenging even for a concrete device, as
> it's useful lifetime is unknown.
>
> Let's do some guesstimation:
>
> Spondoolies Tech's SP35 Yukon unit consumes 3.5 KW and costs $4000. If
> it's useful lifetime is more than 2 years and a cost of KWh is $0.1,
> the total expenditures on electricity will be at least $6135, thus for
> this device we have `f > 6135/4000 > 1.5`.
>
> If other devices which will be sold on the market will have similar
> specs, we will have MIM lower than 0.5. (Well, no shit.)
>
> ## Conclusions
>
> Reward halving is a deficiency in Bitcoin's design, but there is some
> hope it won't be critical: in the equilibrium break-even situation
> hashpower drop is less than 50%.
> 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.
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141025/306eebd3/attachment.html>