Ross Nicoll [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-04-26 to 2015-08-10
💬 Posted a total of 31 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub10plv6jx6pktpp5ezldnus6kj8ffg045g2kdjl78w23njrlveqy5s3pfaef

Profile Code

nprofile1qqs8slkdfrdqm9ss6v30ke7gdtfr555866y9txe0lrh9geeplkvsz2g805za4

Author Public Key

npub10plv6jx6pktpp5ezldnus6kj8ffg045g2kdjl78w23njrlveqy5s3pfaef

Show more details

Last Notes

2023-06-07 17:34:32

- reply

📅 Original date posted:2015-08-10
📝 Original message:Trimmed some of the thread to clarity
On 10/08/2015 19:40, Luke Dashjr wrote:
>>>> I propose adding a new optional "genesis" field as a 16 byte sequence
>>>> containing the SHA-256 hash of the genesis block of the network the
>>>> request belongs to, uniquely identifying chains without any requirement
>>>> for a central registry.
>>> Genesis blocks are not necessarily unique. For example, Litecoin and
>>> Feathercoin share the same one.
>> Had missed that, and there's no easy alternatives. BIP 44 chain IDs
>> don't identify different testnets, and do not cover regtest at all.
> Regtest isn't really a network at all, just a testing mode of Bitcoin Core...
True, but as Jorge points out, it's generally better not to have special
cases.
>> Most recent block hash could be used and also provides fork
>> detection, but in doing so advertises if a merchant is on the wrong
>> fork. Will think about it.
> Is that a bad thing?
It was something I was thinking about with the BIP 66 fork, that it
could be used as a safety measure, but could also be used to find
merchants & exchanges who are accepting coins on the wrong branch of a
fork (and therefore are susceptible to double-spend attacks). For fork
detection it's probably safer for the client to provide a recent block
hash with the payment response.
I think genesis hash collisions are probably acceptable; or, the
duplicate coins are so far rarely long-lived and it's therefore not a
major concern at least. The server should reject any attempt to pay on
the wrong chain, in hindsight, as it will try to relay on the network it
expects and the transaction will be rejected.
>>> I'd appreciate initial feedback on the idea, and if there's no major
>>> objections I'll raise this as a BIP.
>> I don't see how this is related to improving Bitcoin...
>>
>> Well, mostly I'm trying not to avoid the situation where any accidental
>> mixing of files is dangerous (funds can easily be sent on the wrong
>> blockchain), nor with multiple standards (which is where we are at the
>> moment). It improves things in avoiding future problems, rather than in
>> the immediate term.
> Sorry, I meant to stress that BIPs are for *Bitcoin* improvements
> specifically. Things which only improve altcoins, while a perfectly fine thing
> to standardise, are outside the scope of what belongs in a BIP.
>
> Perhaps, however, this could be made to kill 2 birds with one stone, by
> ensuring it addresses the need for payments made of bitcoins on a sidechain?
> For this, a merchant who wants a sidechain payment would presumably be able to
> provide a script from the main chain already, but an extension allowing
> payment directly on the sidechain (at the customer's choice) avoids the need
> to round-trip it...
That could definitely be done, for example by making the genesis field
"repeated", so it specifies all potential networks. The response would
need to indicate which hash it used, but that could be chain tip (with
height in a further field), and provide fork detection.
Ross

2023-06-07 17:34:29

- reply

📅 Original date posted:2015-08-09
📝 Original message:I'm cautious of using human-meaningful identifiers, especially any that
might require a central repository, due to name collisions. Examples
that could be complicated include BitcoinDark, Litedoge, and other names
that base on existing coins. I think the ability to differentiate
between test networks is also useful.
Could certainly just use the genesis hash as network ID, that would
work. Bit long, but suspect 64 bytes isn't the end of the world! I'll
see if any more responses come in then raise a BIP for using genesis
hash as an alternative to short names.
Ross
On 09/08/2015 15:29, Mike Hearn wrote:
>
> I'd appreciate initial feedback on the idea, and if there's no
> major objections I'll raise this as a BIP.
>
>
> The reason BIP 70 doesn't do this is the assumption that alt coins are
> ... well .... alt. They can vary in arbitrary ways from Bitcoin, and
> so things in BIP70 that work for Bitcoin may or may not work for other
> coins.
>
> If your alt coin is close enough to BIP 70 that you can reuse it "as
> is" then IMO we should just define a new network string for your alt.
> network = "dogecoin-main" or whatever.
>
> You could also use the genesis hash as the network name. That works
> too. But it's less clear and would involve lookups to figure out what
> the request is for, if you find such a request in the wild. I don't
> care much either way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150809/5e746ec0/attachment.html>

2023-06-07 17:34:29

- reply

📅 Original date posted:2015-08-09
📝 Original message:BIP 70 currently lists two networks, main and test (inferred as
testnet3) for payment protocol requests. This means that different
testnets cannot be supported trivially, and the protocol cannot be used
for alternative coins (or, lacks context to indicate which coin the
request applies to, which is particularly dangerous in cases where coins
share address prefixes).
I propose adding a new optional "genesis" field as a 16 byte sequence
containing the SHA-256 hash of the genesis block of the network the
request belongs to, uniquely identifying chains without any requirement
for a central registry. For backwards compatibility, the "network" field
would contain "main" for Bitcoin main net, "test" for Bitcoin testnet3,
and "other" for other networks apart from those two.
I'd appreciate initial feedback on the idea, and if there's no major
objections I'll raise this as a BIP.
Ross

- reply

- reply

- reply

- 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 15:42:48

- reply

📅 Original date posted:2015-07-22
📝 Original message:So, if consensus shouldn't really be between the developers (which is
fine), should we empower users to control consensus? I've been working
on a fork framework anyway, which can support reasonably arbitrary
consensus changes (currently against block height, but moving towards
block time). Theoretically it could be modified to load consensus
parameters (which block size would have to be added to) from disk at
startup, rather than having them hard-coded.
Is that considered desirable? Will raise as a PR if so. If not, where do
we draw a line between developer and user consensus?
Ross
On 22/07/2015 17:52, Pieter Wuille via bitcoin-dev wrote:
>
> Hello all,
>
> I'd like to talk a bit about my view on the relation between the
> Bitcoin Core project, and the consensus rules of Bitcoin.
>
> I believe it is the responsibility of the maintainers/developers of
> Bitcoin Core to create software which helps guarantee the security and
> operation of the Bitcoin network.
>
> In addition to normal software maintenance, bug fixes and performance
> improvements, this includes DoS protection mechanism deemed necessary
> to keep the network operational. Sometimes, such (per-node
> configurable) policies have had economic impact, for example the dust
> rule.
>
> This also includes participating in discussions about consensus
> changes, but not the responsibility to decide on them - only to
> implement them when agreed upon. It would be irresponsible and
> dangerous to the network and thus the users of the software to risk
> forks, or to take a leading role in pushing dramatic changes. Bitcoin
> Core developers obviously have the ability to make any changes to the
> codebase or its releases, but it is still up to the community to
> choose to run that code.
>
> 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.
>
> 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.
>
> ===
>
> 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.
>
> --
> 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/20150722/1b3907fd/attachment.html>

2023-06-07 15:42:40

- 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 15:42:33

- 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 15:42:30

- 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 15:42:29

- 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 15:42:29

- 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 15:40:32

- 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 15:39:55

- reply

📅 Original date posted:2015-06-23
📝 Original message:Also, before that's turned into "8MB blocks are infeasible", my presumption is that blocks are not expected to jump suddenly to 8MB, and that most will have time to ramp up storage and bandwidth.
The point about not outright replacing existing test data is the more critical one, anyway, although in retrospect we could simply add spam transactions on top of existing transactions.
Ross
On 23 Jun 2015 08:35, Ross Nicoll <jrn at jrn.me.uk> wrote:

2023-06-07 15:39:54

- reply

📅 Original date posted:2015-06-22
📝 Original message:Potentially daft question, why not use a minimum height? Yes, it's
imprecise, but over an extended period of time they're good enough IMHO.
I'd have to do more careful calculations to confirm, but block 388,000
should be about right as a minimum.
Ross
On 22/06/2015 22:04, Stephen Morse wrote:
>
> In the nVersion bits proposal that I co-authored we solved that
> issue by
> comparing the timestamp against the median time, which is
> guaranteed by
> the protocol rules to monotonically advance.
>
>
> I'm also a fan of using the median time to ensure that there is a
> clear point where the protocol change starts. Something like "blocks
> only allow the larger block size if the associate pindex has
> pindex->GetMedianTimePast() after midnight 11 Jan 2016 and where a
> supermajority showing support for the fork has previously been reached".
>
>
> _______________________________________________
> 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/20150622/b29ea6b5/attachment.html>

2023-06-07 15:39:42

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

- 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 15:38:36

- 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 15:38:34

- 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 15:34:23

- reply

📅 Original date posted:2015-05-09
📝 Original message:I think potential fee subsidies for cleaning up UTXO (and/or penalties
for creating more UTXO than you burn) are worth thinking about. As
Gavin's post ( gavinandresen.ninja/utxo-uhoh ) indicates, UTXO cost is
far higher than block storage, so charging differently for the in/out
mismatches should make good economic sense.
Ross
On 09/05/2015 20:16, Jim Phillips wrote:
> On Sat, May 9, 2015 at 2:06 PM, Pieter Wuille <pieter.wuille at gmail.com
> <mailto:pieter.wuille at gmail.com>> wrote:
>
> It's a very complex trade-off, which is hard to optimize for all
> use cases. Using more UTXOs requires larger transactions, and thus
> more fees in general.
>
> Unless the miner determines that the reduction in UTXO storage
> requirements is worth the lower fee. There's no protocol level
> enforcement of a fee as far as I understand it. It's enforced by the
> miners and their willingness to include a transaction in a block.
>
> In addition, it results in more linkage between coins/addresses
> used, so lower privacy.
>
> Not if you only select all the UTXOs from a single address. A wallet
> that is geared more towards privacy minded individuals may want to
> reduce the amount of address linkage, but a wallet geared towards the
> general masses probably won't have to worry so much about that.
>
> The only way you can guarantee an economical reason to keep the
> UTXO set small is by actually having a consensus rule that
> punishes increasing its size.
>
> There's an economical reason right now to keeping the UTXO set small.
> The smaller it is, the easier it is for the individual to run a full
> node. The easier it is to run a full node, the faster Bitcoin will
> spread to the masses. The faster it spreads to the masses, the more
> valuable it becomes.
>
>
>
> ------------------------------------------------------------------------------
> 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/20150509/bbd40c7a/attachment.html>

2023-06-07 15:33:22

- reply

📅 Original date posted:2015-05-07
📝 Original message:I'm presuming that schedule is just an example, as you'd end up with
insanely large block sizes in a few years.
Absolutely, yes, an increase schedule is an option if people agree on
it, and I think the better option, as the current limit too low, but
jumping straight to a value big enough for "indefinitely" is a huge jump.
Gave some thought to scaling block size based on transaction fees, but
suspect it would end up with miners sending huge fees to themselves with
transactions that aren't relayed (so they only are actioned if they make
it into a block that miner mines) to make the network allow bigger blocks.
Ross
On 07/05/2015 19:38, Chris Wardell wrote:
> Instead of raising the block size to another static number like 20MB,
> can we raise it dynamically?
>
> Make the max block size something like:
> pow(2, nHeight/100000) * 1MB; //double every ~2 years
>
>
>
> ------------------------------------------------------------------------------
> 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/bcea0e35/attachment.html>

2023-06-07 15:33:16

- 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 15:30:18

- 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 15:28:38

- 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 15:28:37

- 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 15:28:22

- reply

📅 Original date posted:2015-01-04
📝 Original message:On 04/01/15 17:35, Gregory Maxwell wrote:
> On Sun, Jan 4, 2015 at 5:22 PM, Ross Nicoll <jrn at jrn.me.uk> wrote:
>> Grabbing a simple test case:
>> https://chain.so/tx/BTCTEST/f903a31f2474df737d324c60abf2407e1cf7e052844da4ccffbfab81cf6ac1f8
>> - that won't lock until 0028 UTC on the 5th.
>>
>> I've tried closing the wallet, moving the wallet.dat file out of the
>> way, and then attempting the spend transaction (which can be locked
>> immediately), and it either rejects it on acceptance to mempool, or it
>> is never included in a block.
>
> Can you send me the actual raw transaction (that site doesn't appear
> have a way to get it, only some cooked json output; which doesn't
> include the sequence number).
>
> As I said, it's a severe bug if unlocked transactions are being
> relayed or mempooled far in advance.
Attached. Sequence number for the input is set to 1, please do tell me
if I've misunderstood how it's used.
>> They can only replace a non-final transaction with a final transaction,
>
> Ah I missed that the replacement had to be final. Thats indeed a much
> more sane thing to do than I was thinking (sorry for some reason I saw
> the +1 and thought it was just checking the sequence number was
> higher.)
>
>> I don't think that's a major issue?
>
> If they can relay the first one to begin with its an an issue, the
> replacement just makes it twice an issue. :)
>
I'll set up a few nodes tomorrow and double check it's in fact relaying
in the latest version. If it's simply an issue of incorrect relaying,
that's significantly simpler at least, and the problem can be tackled
through that instead.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: f903a31f2474df737d324c60abf2407e1cf7e052844da4ccffbfab81cf6ac1f8.hex
Type: text/x-hex
Size: 606 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150104/4c954510/attachment.bin>

2023-06-07 15:28:21

- reply

📅 Original date posted:2015-01-04
📝 Original message:On 04/01/15 17:44, Gregory Maxwell wrote:
> On Sun, Jan 4, 2015 at 5:35 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
>> Can you send me the actual raw transaction (that site doesn't appear
>> have a way to get it, only some cooked json output; which doesn't
>> include the sequence number).
>
> Nevermind, I guess. I think I figured out your problem: The behaviour
> on testnet is busted because the non-mempooling is enforced by
> IsStandardTx which is bypassed in testnet. We should enforce that
> elsewhere.
>
> This isn't the case on the real network.
>
Ah, thanks for that.
I'll try Peter's patch for testnet tomorrow, sounds like it should fix
this for my use case.

2023-06-07 15:28:20

- reply

📅 Original date posted:2015-01-04
📝 Original message:On 04/01/15 17:04, Gregory Maxwell wrote:
> On Sun, Jan 4, 2015 at 2:43 PM, Ross Nicoll <jrn at jrn.me.uk> wrote:
>> Dear all,
>>
>> I've been looking at atomic cross-chain trading (
>> https://en.bitcoin.it/wiki/Atomic_cross-chain_trading ) between the
>> Bitcoin and Dogecoin blockchains, and have a mostly functional
>> prototype. However as it stands if the refund transaction is relayed
>> before the actual spend transaction, it "blocks" the legitimate spend
>> transaction from being accepted into the memory pool.
>
> Unless there is a serious bug that I am not aware of this is not the
> case. The unlocked transaction is not relayable and will not be
> mempooled (well, until right before it locks).
Grabbing a simple test case:
https://chain.so/tx/BTCTEST/f903a31f2474df737d324c60abf2407e1cf7e052844da4ccffbfab81cf6ac1f8
- that won't lock until 0028 UTC on the 5th.
I've tried closing the wallet, moving the wallet.dat file out of the
way, and then attempting the spend transaction (which can be locked
immediately), and it either rejects it on acceptance to mempool, or it
is never included in a block.
Compare with
https://chain.so/tx/BTCTEST/0b96eb0c9bf8a6ca08bb9d75e44970889db77779c6d3122296c0169959f979cc
where the refund was not sent first, and the transaction has succeeded.
>> I've drafted a patch for this
>> https://github.com/rnicoll/bitcoin/commit/e668d36607f008990ccaac7275e463a6efdd9b5a
>> but have not yet raised a PR, as historically this has lead to a lot of
>> discussion in Github which is better suited to this mailing list.
>>
>> I'm therefore looking for feedback while I continue testing that patch,
>> and any comments would be welcomed.
>
> This appears to have absolutely no protection against denial of
> service, it seems to me that a single user can rapidly update their
> transaction and exhaust the relay bandwidth of the entire network.
>
They can only replace a non-final transaction with a final transaction,
so the replacement can happen at most once (any later replacement would
be attempting to replace a final transaction, and therefore fails). So,
while they can expend twice the bandwidth compared to a non-replacement,
I don't think that's a major issue?

2023-06-07 15:28:20

- reply

📅 Original date posted:2015-01-04
📝 Original message:Dear all,
I've been looking at atomic cross-chain trading (
https://en.bitcoin.it/wiki/Atomic_cross-chain_trading ) between the
Bitcoin and Dogecoin blockchains, and have a mostly functional
prototype. However as it stands if the refund transaction is relayed
before the actual spend transaction, it "blocks" the legitimate spend
transaction from being accepted into the memory pool.
I'd like to enable TX replacement in the case where all conflicting
transactions are not final, and the replacement is final. While yes,
this still leaves scope for "unpaid for" bandwidth, hopefully being able
to do a single replacement isn't a major issue.
For those wanting background on this,
https://github.com/bitcoin/bitcoin/pull/2516 may be useful reading.
I've drafted a patch for this
https://github.com/rnicoll/bitcoin/commit/e668d36607f008990ccaac7275e463a6efdd9b5a
but have not yet raised a PR, as historically this has lead to a lot of
discussion in Github which is better suited to this mailing list.
I'm therefore looking for feedback while I continue testing that patch,
and any comments would be welcomed.
Ross

2023-06-07 15:26:49

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

2023-06-07 15:20:23

- reply

📅 Original date posted:2014-04-26
📝 Original message:Dear all,
Still going through the payment protocol specifications... the MIME
types in BIP0071 aren't IANA registered, and honestly look unlikely to
be accepted if they were submitted as-is.
Latest RFC on media type registration is RFC 6838, which very strictly
restricts what can go in the default "application/" namespace.
Essentially they'd want it to be an ISO standard or similar. There are
vendor namespaces, which look much more feasible (this is how Powerpoint
2007 ended up as
"application/vnd.openxmlformats-officedocument.presentationml.presentation"),
but would be quite a dramatic change to BIP0071.
What's the general feeling on this? Personally I'm in favour of
following the registration process, so register a Bitcoin vendor
namespace with IANA, then allocate MIME types such as:
application/vnd.bitcoin.payment.request
application/vnd.bitcoin.payment.payment
application/vnd.bitcoin.payment.ack
Thoughts?
Ross

2023-06-07 15:20:16

- reply

📅 Original date posted:2014-04-26
📝 Original message:I'd be very cautious of security implications of embedding files into
the payment request. Even file formats one would presume safe, such as
images, have had security issues (i.e.
https://technet.microsoft.com/library/security/ms11-006 )
Longer term I was wondering about embedding the PaymentRequest into web
pages directly via the <object> tag, which could eliminate need for
BIP0072 and potentially improve user interface integration that way.
Obviously this would require browser plugins, however.
Ross
On 26/04/14 18:36, Mike Hearn wrote:
>> PaymentRequests are limited to 50,000 bytes. I can't think of a reason why
>> Payment messages would need to be any bigger than that. Submit a pull
>> request to the existing BIP.
>>
> In future it might be nice to have images and things in the payment
> requests, to make UIs look prettier. But with the current version 50kb
> should be plenty indeed.
>

2023-06-07 15:20:15

- reply

📅 Original date posted:2014-04-26
📝 Original message:Dear Gavin, Andreas,
I'd see standardisation (or at least suggested standards) for error
handling as positive for consistency of user experience. I do see what
you mean about over-specification, however.
Thanks for the feedback, I've taken the main points and created two pull
requests:
BIP-0070: https://github.com/bitcoin/bips/pull/54/
BIP-0072: https://github.com/bitcoin/bips/pull/55/
Please tell me if these need any further work.
Ross
On 26/04/14 14:23, Gavin Andresen wrote:
>> The main area of concern is handling unexpected problems while sending
>> the Payment message, or receiving the corresponding PaymentACK message.
>> For example, in case of a transport layer failure or non-200 HTTP status
>> code while sending the Payment message, what should the wallet software
>> do next? Is it safe to re-send the Payment message? I'd propose that for
>> any transport failure or 500 status code, the client retries after a
>> delay (suggested at 30-60 seconds). For 400 status codes, the request
>> should not be repeated, and as such the user should be alerted and a
>> copy of the Payment message saved to be resent later.
>>
> Why does error handling have to be standardized?
>
> I generally think that wallet software should be free to do whatever gives
> the user the best experience, so I'm in favor of restricting BIPs to things
> that must be standardized so that different implementations inter-operate.
>
>
>> For 300 (redirect and similar) status codes, is it considered safe to
>> follow redirects? I think we have to, but good to make it clear in the
>> specification.
>>
> Referencing whatever RFCs defines how to fetch URLs would be the best way
> to do this. Submit a pull request.
>
>
>> On the merchant's side; I think it would be useful for there to be
>> guidance for handling of errors processing Payment messages. I'd suggest
>> that Payment messages should have a fixed maximum size to avoid merchant
>> systems theoretically having to accept files of any size; 10MB would
>> seem far larger than in any way practical, and therefore a good maximum
>> size?
>
> PaymentRequests are limited to 50,000 bytes. I can't think of a reason why
> Payment messages would need to be any bigger than that. Submit a pull
> request to the existing BIP.
>
>
>> A defined maximum time to wait (to avoid DDoS via connection
>> holding) might be useful too, although I'd need to do measurements to
>> find what values are tolerable.
>>
> Implementation detail that doesn't belong in the spec, in my humble opinion.
>
>
>> I would like to have the protocol state that merchant systems should
>> handle repeatedly receiving the same Payment message, and return an
>> equivalent (if not identical) PaymentACK to each. This is important in
>> case of a network failure while the client is sending the Payment
>> message, as outlined above.
>>
> I think this should be left to implementations to work out.
>
>
>> Lastly, I'm wondering about potential timing issues with transactions;
>> if a merchant system wants to see confirmation of a transaction before
>> sending a PaymentACK...
>
> .... not a good idea. The user should get feedback right away. Poking a
> "pay now" button and then waiting more than a second or three to get "your
> payment has been received and is being processed" is terrible UI.
>
>