* [bitcoin-dev] Eli Dourado on "governance"
@ 2015-08-03 15:22 Gavin Andresen
[not found] ` <1438640036.2828.0.camel@auspira.com>
` (2 more replies)
0 siblings, 3 replies; 29+ messages in thread
From: Gavin Andresen @ 2015-08-03 15:22 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 931 bytes --]
I haven't seen this excellent recent blog post by Eli Dourado referenced
here:
https://readplaintext.com/how-should-bitcoin-be-governed-680192fcd92b
I agree with his conclusions: we need better communication/organization
mechanisms among 'stakeholders' and between the various factions
(developers, miners, merchants, exchanges, end-users).
And the preliminary results of using a prediction market to try to wrestle
with the tough tradeoffs looks roughly correct to me, too:
https://blocksizedebate.com/
(my only big disagreement with those predictions is the 'Number of nodes'
-- I don't think replace-by-fee would affect that number, and I think even
with no change we will see the number of full nodes on the network drop to
a couple thousand, because the general-purpose-home-PC is headed the way of
the dodo:
http://www.businessinsider.com/pc-sales-plummet-in-q2-2015-gartner-idc-say-2015-7
).
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 1425 bytes --]
^ permalink raw reply [flat|nested] 29+ messages in thread[parent not found: <1438640036.2828.0.camel@auspira.com>]
* Re: [bitcoin-dev] Eli Dourado on "governance" [not found] ` <1438640036.2828.0.camel@auspira.com> @ 2015-08-03 22:21 ` Gavin Andresen 2015-08-04 6:40 ` [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests Peter R 0 siblings, 1 reply; 29+ messages in thread From: Gavin Andresen @ 2015-08-03 22:21 UTC (permalink / raw) To: GJB; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 574 bytes --] On Mon, Aug 3, 2015 at 6:13 PM, GJB <balle@auspira•com> wrote: > Do you mean something like a Foundation? > No, I think one of the fundamental problems with the Foundation is it tries to represent everybody's interests. The interests of exchanges are not necessarily the same as end-users or miners, for example. But it would make sense for exchanges (for example) to get together and come to consensus on whatever issues are important to them, like the recent consensus and then statement from "the Chinese miners" regarding the block size issue. -- -- Gavin Andresen [-- Attachment #2: Type: text/html, Size: 1111 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests 2015-08-03 22:21 ` Gavin Andresen @ 2015-08-04 6:40 ` Peter R 2015-08-04 18:41 ` Dave Hudson ` (2 more replies) 0 siblings, 3 replies; 29+ messages in thread From: Peter R @ 2015-08-04 6:40 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2034 bytes --] Dear Bitcoin-Dev Mailing list, I’d like to share a research paper I’ve recently completed titled “A Transaction Fee Market Exists Without a Block Size Limit.” In addition to presenting some useful charts such as the cost to produce large spam blocks, I think the paper convincingly demonstrates that, due to the orphaning cost, a block size limit is not necessary to ensure a functioning fee market. The paper does not argue that a block size limit is unnecessary in general, and in fact brings up questions related to mining cartels and the size of the UTXO set. It can be downloaded in PDF format here: https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf Or viewed with a web-browser here: https://www.scribd.com/doc/273443462/A-Transaction-Fee-Market-Exists-Without-a-Block-Size-Limit Abstract. This paper shows how a rational Bitcoin miner should select transactions from his node’s mempool, when creating a new block, in order to maximize his profit in the absence of a block size limit. To show this, the paper introduces the block space supply curve and the mempool demand curve. The former describes the cost for a miner to supply block space by accounting for orphaning risk. The latter represents the fees offered by the transactions in mempool, and is expressed versus the minimum block size required to claim a given portion of the fees. The paper explains how the supply and demand curves from classical economics are related to the derivatives of these two curves, and proves that producing the quantity of block space indicated by their intersection point maximizes the miner’s profit. The paper then shows that an unhealthy fee market—where miners are incentivized to produce arbitrarily large blocks—cannot exist since it requires communicating information at an arbitrarily fast rate. The paper concludes by considering the conditions under which a rational miner would produce big, small or empty blocks, and by estimating the cost of a spam attack. Best regards, Peter [-- Attachment #2: Type: text/html, Size: 2598 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests 2015-08-04 6:40 ` [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests Peter R @ 2015-08-04 18:41 ` Dave Hudson 2015-08-04 21:18 ` Peter Todd ` (2 more replies) 2015-08-05 8:33 ` Benjamin [not found] ` <CAAS2fgTzeFnmnr2ScZvf1pDUtF+M3HhF9xo0yhjVPObpqhgz0A@mail.gmail.com> 2 siblings, 3 replies; 29+ messages in thread From: Dave Hudson @ 2015-08-04 18:41 UTC (permalink / raw) To: Peter R; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 3198 bytes --] The paper is nicely done, but I'm concerned that there's a real problem with equation 4. The orphan rate is not just a function of time; it's also a function of the block maker's proportion of the network hash rate. Fundamentally a block maker (pool or aggregation of pools) does not orphan its own blocks. In a degenerate case a 100% pool has no orphaned blocks. Consider that a 1% miner must assume a greater risk from orphaning than, say, a pool with 25%, or worse 40% of the hash rate. I suspect this may well change some of the conclusions as larger block makers will definitely be able to create larger blocks than their smaller counterparts. Cheers, Dave > On 3 Aug 2015, at 23:40, Peter R via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > > Dear Bitcoin-Dev Mailing list, > > I’d like to share a research paper I’ve recently completed titled “A Transaction Fee Market Exists Without a Block Size Limit.” In addition to presenting some useful charts such as the cost to produce large spam blocks, I think the paper convincingly demonstrates that, due to the orphaning cost, a block size limit is not necessary to ensure a functioning fee market. > > The paper does not argue that a block size limit is unnecessary in general, and in fact brings up questions related to mining cartels and the size of the UTXO set. > > It can be downloaded in PDF format here: > > https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf <https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf> > > Or viewed with a web-browser here: > > https://www.scribd.com/doc/273443462/A-Transaction-Fee-Market-Exists-Without-a-Block-Size-Limit <https://www.scribd.com/doc/273443462/A-Transaction-Fee-Market-Exists-Without-a-Block-Size-Limit> > > Abstract. This paper shows how a rational Bitcoin miner should select transactions from his node’s mempool, when creating a new block, in order to maximize his profit in the absence of a block size limit. To show this, the paper introduces the block space supply curve and the mempool demand curve. The former describes the cost for a miner to supply block space by accounting for orphaning risk. The latter represents the fees offered by the transactions in mempool, and is expressed versus the minimum block size required to claim a given portion of the fees. The paper explains how the supply and demand curves from classical economics are related to the derivatives of these two curves, and proves that producing the quantity of block space indicated by their intersection point maximizes the miner’s profit. The paper then shows that an unhealthy fee market—where miners are incentivized to produce arbitrarily large blocks—cannot exist since it requires communicating information at an arbitrarily fast rate. The paper concludes by considering the conditions under which a rational miner would produce big, small or empty blocks, and by estimating the cost of a spam attack. > > Best regards, > Peter > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Type: text/html, Size: 4560 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests 2015-08-04 18:41 ` Dave Hudson @ 2015-08-04 21:18 ` Peter Todd 2015-08-04 21:30 ` Gavin Andresen 2015-08-05 22:15 ` Peter R 2 siblings, 0 replies; 29+ messages in thread From: Peter Todd @ 2015-08-04 21:18 UTC (permalink / raw) To: Dave Hudson, Dave Hudson via bitcoin-dev, Peter R; +Cc: Bitcoin Dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 4 August 2015 14:41:53 GMT-04:00, Dave Hudson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: >The paper is nicely done, but I'm concerned that there's a real problem >with equation 4. The orphan rate is not just a function of time; it's >also a function of the block maker's proportion of the network hash >rate. Fundamentally a block maker (pool or aggregation of pools) does >not orphan its own blocks. In a degenerate case a 100% pool has no >orphaned blocks. Consider that a 1% miner must assume a greater risk >from orphaning than, say, a pool with 25%, or worse 40% of the hash >rate. > >I suspect this may well change some of the conclusions as larger block >makers will definitely be able to create larger blocks than their >smaller counterparts. Quite correct; this paper is fatally flawed and at best rehashes what we already know happens in the "spherical cow" case, without making it clear that it refers to a completely unrealistic setup. It'd be interested to know who actually wrote it - "Peter R" is obviously a pseudonym and the paper goes into sufficient detail that it makes you wonder why the author didn't see the flaws in it. For those wishing to do actual research, esp. people such as profs mentoring students, keep in mind that in Bitcoin situations where large miners have an advantage over small miners are security exploits, with severity proportional to the difference in profitability. A good example of the type of analysis required is the well known selfish mining paper, which shows how a miner adopting a "selfish" strategy has an advantage - more profit per unit hashing power - than miners who do not adopt that strategy, and additionally, that excess profits scales with increasing hashing power. As for the OP, if this wasn't an attempt at misinformation, my apologies. But keep in mind that you're wading into a highly politically charged research field with billions hanging on the blocksize limit; understand that people aren't happy when flawed papers end up on reddit being used to promote bad ideas. You'd be wise to run future work past experts in the field prior to publishing widely if you dislike heated controversy. -----BEGIN PGP SIGNATURE----- iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVwSwJ AAoJEMCF8hzn9Lnc47AH/RknSZpnZ8r4WA4r+S0yJmlo0hKm8gsjUGhaqX7cnuSR dB1ewrsjC4uPtSc8Ej1hzf37E67DTxiz6STq9XdtFSij+ww7SPx+z8yjEpQ0Ld0K OIidQ80WRGJ1UPMUt7pFDU3pxNZI/A46Lg3EmqjY+xAe6+wDlOHjT/miO3tv0uws nNYwrelA4f/KQXkUggGUOW62Sc3fJpUxLurq4eQHflIxtk3KM1reSxwG28KG02j6 lTUEHmMsmE7qoQAl60vwfvVKvvy/RwxpildwNey6IgtCQqWqqEy+WoTsgyVAGIbn +8gR//W2hEIp+W5OSsiVNZ5S/KpcwaIBqZFcoca8838= =HJiv -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests 2015-08-04 18:41 ` Dave Hudson 2015-08-04 21:18 ` Peter Todd @ 2015-08-04 21:30 ` Gavin Andresen 2015-08-04 21:46 ` Peter Todd 2015-08-04 23:37 ` Dave Hudson 2015-08-05 22:15 ` Peter R 2 siblings, 2 replies; 29+ messages in thread From: Gavin Andresen @ 2015-08-04 21:30 UTC (permalink / raw) To: Dave Hudson; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 922 bytes --] On Tue, Aug 4, 2015 at 2:41 PM, Dave Hudson via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > Fundamentally a block maker (pool or aggregation of pools) does not orphan > its own blocks. Unless the block maker has an infinitely fast connection to it's hashpower OR it's hashpower is not parallelized at all, that's not strictly true -- it WILL orphan its own blocks because two hashing units will find solutions in the time it takes to communicate that solution to the block maker and to the rest of the hashing units. That's getting into "how many miners can dance on the head of a pin" territory, though. I don't think we know whether the communication advantages of putting lots of hashing power physically close together will outweigh the extra cooling costs of doing that (or maybe some other tradeoff I haven't thought of). That would be a fine topic for another paper.... -- -- Gavin Andresen [-- Attachment #2: Type: text/html, Size: 1412 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests 2015-08-04 21:30 ` Gavin Andresen @ 2015-08-04 21:46 ` Peter Todd 2015-08-05 0:26 ` Milly Bitcoin 2015-08-04 23:37 ` Dave Hudson 1 sibling, 1 reply; 29+ messages in thread From: Peter Todd @ 2015-08-04 21:46 UTC (permalink / raw) To: Gavin Andresen, Gavin Andresen via bitcoin-dev, Dave Hudson; +Cc: Bitcoin Dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 4 August 2015 17:30:28 GMT-04:00, Gavin Andresen via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: >On Tue, Aug 4, 2015 at 2:41 PM, Dave Hudson via bitcoin-dev < >bitcoin-dev@lists•linuxfoundation.org> wrote: > >> Fundamentally a block maker (pool or aggregation of pools) does not >orphan >> its own blocks. > > >Unless the block maker has an infinitely fast connection to it's >hashpower >OR it's hashpower is not parallelized at all, that's not strictly true >-- >it WILL orphan its own blocks because two hashing units will find >solutions >in the time it takes to communicate that solution to the block maker >and to >the rest of the hashing units. > >That's getting into "how many miners can dance on the head of a pin" >territory, though. I don't think we know whether the communication >advantages of putting lots of hashing power physically close together >will >outweigh the extra cooling costs of doing that (or maybe some other >tradeoff I haven't thought of). That would be a fine topic for another >paper.... I'd suggest you do more research into how Bitcoin and mining works as the above has a number of serious misunderstandings. Or, I could just point out the obvious rather than try to be polite: you know exactly why the above makes no sense as a reply to this thread and are deliberately lying. If the situation is the latter, your conduct is toxic to the development mailing list discussion, not to mention a waste of all our time, and you should leave. -----BEGIN PGP SIGNATURE----- iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVwTKi AAoJEMCF8hzn9Lnc47AH/0txNyw9dLdsfQOsNE14jLEcQifxOkaKLqTJV1O4gn6O L4+T6rPo9pVLTBuVWcsm2A24R/gBL+pYaWgaIyk/3fbSRpg4GfVau0xxh54vQU6m U4L7FPHsdZ2y67frv/+5ExJ2xrVuedhpTciTi2SqSE6C0fioO+YarH0Dvd8I5Wjx f9GnmxLdKytoj2kUaoriSSxsUzMNzxVzq78jEmhMR85TGy73ApeLdgBC/pdNgxZa oAQ0CXCMYgsE59HUOO05xFLazGxNh2epPADTbTTgoNQ9py38evlW254okhRmk9p9 v4i1yTzuv/Y6C0qw2RZcEiT/GTdvajkMKCidLEm3LbY= =W/Ke -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests 2015-08-04 21:46 ` Peter Todd @ 2015-08-05 0:26 ` Milly Bitcoin 2015-08-05 0:40 ` Neil Fincham 0 siblings, 1 reply; 29+ messages in thread From: Milly Bitcoin @ 2015-08-05 0:26 UTC (permalink / raw) To: bitcoin-dev >For those wishing to do actual research, esp. people such as profs mentoring students, ... >But keep in mind that you're wading into a highly politically charged research field >with billions hanging on the blocksize limit; understand that people aren't happy when >flawed papers end up on reddit being used to promote bad ideas. You'd be wise to run future >work past experts in the field prior to publishing widely if you dislike heated controversy. > Or, I could just point out the obvious rather than try to be polite: you know exactly why >the above makes no sense as a reply to this thread and are deliberately lying. >If the situation is the latter, your conduct is toxic to the development mailing list >discussion, not to mention a waste of all our time, and you should leave. Researchers should also keep in mind that some of developers are immature and have limited knowledge or experience beyond their Bitcoin expertise ("Idiot-savants"). Others want to be in "charge" of drama-laced posts on reddit and they get upset if others do the same things. In any case these rants and attacks by Todd and Garzik should be posted on their personal blogs or reddit instead of this list. Russ ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests 2015-08-05 0:26 ` Milly Bitcoin @ 2015-08-05 0:40 ` Neil Fincham 0 siblings, 0 replies; 29+ messages in thread From: Neil Fincham @ 2015-08-05 0:40 UTC (permalink / raw) To: Milly Bitcoin; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 2440 bytes --] > Researchers should also keep in mind that some of developers are immature and have limited knowledge or experience beyond their Bitcoin expertise ("Idiot-savants"). Others want to be in "charge" of drama-laced posts on reddit and they get upset if others do the same things. > In any case these rants and attacks by Todd and Garzik should be posted on their personal blogs or reddit instead of this list. I very rarely comment on list politics but isn't this the kettle calling the pot black? Back to my hole now I promise. On 5 August 2015 at 12:26, Milly Bitcoin via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > For those wishing to do actual research, esp. people such as profs >> mentoring students, ... >> > > But keep in mind that you're wading into a highly politically charged >> research field >> with billions hanging on the blocksize limit; understand that people >> aren't happy when >> flawed papers end up on reddit being used to promote bad ideas. You'd be >> wise to run future >> work past experts in the field prior to publishing widely if you dislike >> heated controversy. >> > > Or, I could just point out the obvious rather than try to be polite: you >> know exactly why >> the above makes no sense as a reply to this thread and are deliberately >> lying. >> > > If the situation is the latter, your conduct is toxic to the development >> mailing list >> discussion, not to mention a waste of all our time, and you should leave. >> > > > > > Researchers should also keep in mind that some of developers are immature > and have limited knowledge or experience beyond their Bitcoin expertise > ("Idiot-savants"). Others want to be in "charge" of drama-laced posts on > reddit and they get upset if others do the same things. > > In any case these rants and attacks by Todd and Garzik should be posted on > their personal blogs or reddit instead of this list. > > Russ > > > > > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -- [image: Facebook] <https://www.facebook.com/MineForeman> [image: Twitter] <https://twitter.com/mineforeman> [image: LinkedIn] <http://www.linkedin.com/company/mineforeman-com> Neil Fincham MineForeman Phone: +64 21 545 583 99 Sala St, Rotorua, New Zealand. 3010 Website <http://mineforeman.com/> | neil@mineforeman•com [-- Attachment #2: Type: text/html, Size: 5482 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests 2015-08-04 21:30 ` Gavin Andresen 2015-08-04 21:46 ` Peter Todd @ 2015-08-04 23:37 ` Dave Hudson 1 sibling, 0 replies; 29+ messages in thread From: Dave Hudson @ 2015-08-04 23:37 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1407 bytes --] > On 4 Aug 2015, at 14:30, Gavin Andresen <gavinandresen@gmail•com> wrote: > > On Tue, Aug 4, 2015 at 2:41 PM, Dave Hudson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote: > Fundamentally a block maker (pool or aggregation of pools) does not orphan its own blocks. > > Unless the block maker has an infinitely fast connection to it's hashpower OR it's hashpower is not parallelized at all, that's not strictly true -- it WILL orphan its own blocks because two hashing units will find solutions in the time it takes to communicate that solution to the block maker and to the rest of the hashing units. > > That's getting into "how many miners can dance on the head of a pin" territory, though. I don't think we know whether the communication advantages of putting lots of hashing power physically close together will outweigh the extra cooling costs of doing that (or maybe some other tradeoff I haven't thought of). That would be a fine topic for another paper.... Yes, but the block maker won't publish the second block it finds for the same set of transactions. It won't orphan its own block. In fact even if it does it still doesn't matter because the block maker still gets the block reward irrespective of which of the two solutions are published. It's not about which hash wins, the issue is who gets paid as a result. [-- Attachment #2: Type: text/html, Size: 2239 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests 2015-08-04 18:41 ` Dave Hudson 2015-08-04 21:18 ` Peter Todd 2015-08-04 21:30 ` Gavin Andresen @ 2015-08-05 22:15 ` Peter R 2015-08-05 22:44 ` Dave Hudson 2 siblings, 1 reply; 29+ messages in thread From: Peter R @ 2015-08-05 22:15 UTC (permalink / raw) To: Dave Hudson; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 4514 bytes --] Hi Dave, Thank you for the feedback regarding my paper. > The paper is nicely done, but I'm concerned that there's a real problem with equation 4. The orphan rate is not just a function of time; it's also a function of the block maker's proportion of the network hash rate. Fundamentally a block maker (pool or aggregation of pools) does not orphan its own blocks. With the benefit of hindsight, I think the paper would be stronger if it also analyzed how the model changes (or doesn't) if we assume zero propagation impedance for intra-miner communication, as you suggested (the "you don't orphan your own blocks" idea). Note that the paper did briefly discuss miner-dependent propagation times in the second paragraph of page 9 and in note 13. > In a degenerate case a 100% pool has no orphaned blocks. Agreed. In this case there's no information to communicate (since the miner has no peers) and so the Shannon-Hartley limit doesn't apply. My model makes no attempt to explain this case. > Consider that a 1% miner must assume a greater risk from orphaning than, say, a pool with 25%, or worse 40% of the hash rate. I'd like to explore this in more detail. Although a miner may not orphan his own block, by building on his own block he may now orphan two blocks in a row. At some point, his solution or solutions must be communicated to his peers. And if there's information about the transactions in his blocks to communicate, I think there's a cost associated with that. It's an interesting problem and I'd like to continue working on it. > I suspect this may well change some of the conclusions as larger block makers will definitely be able to create larger blocks than their smaller counterparts. It will be interesting to see. I suspect that the main result that "a healthy fee market exists" will still hold (assuming of course that a single miner with >50% of the hash power isn't acting maliciously). Whether miners with larger value of h/H have a profit advantage, I'm not sure (but that was outside the scope of the paper anyways). Best regards, Peter >> On 3 Aug 2015, at 23:40, Peter R via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: >> >> Dear Bitcoin-Dev Mailing list, >> >> I’d like to share a research paper I’ve recently completed titled “A Transaction Fee Market Exists Without a Block Size Limit.” In addition to presenting some useful charts such as the cost to produce large spam blocks, I think the paper convincingly demonstrates that, due to the orphaning cost, a block size limit is not necessary to ensure a functioning fee market. >> >> The paper does not argue that a block size limit is unnecessary in general, and in fact brings up questions related to mining cartels and the size of the UTXO set. >> >> It can be downloaded in PDF format here: >> >> https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf >> >> Or viewed with a web-browser here: >> >> https://www.scribd.com/doc/273443462/A-Transaction-Fee-Market-Exists-Without-a-Block-Size-Limit >> >> Abstract. This paper shows how a rational Bitcoin miner should select transactions from his node’s mempool, when creating a new block, in order to maximize his profit in the absence of a block size limit. To show this, the paper introduces the block space supply curve and the mempool demand curve. The former describes the cost for a miner to supply block space by accounting for orphaning risk. The latter represents the fees offered by the transactions in mempool, and is expressed versus the minimum block size required to claim a given portion of the fees. The paper explains how the supply and demand curves from classical economics are related to the derivatives of these two curves, and proves that producing the quantity of block space indicated by their intersection point maximizes the miner’s profit. The paper then shows that an unhealthy fee market—where miners are incentivized to produce arbitrarily large blocks—cannot exist since it requires communicating information at an arbitrarily fast rate. The paper concludes by considering the conditions under which a rational miner would produce big, small or empty blocks, and by estimating the cost of a spam attack. >> >> Best regards, >> Peter >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 7120 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests 2015-08-05 22:15 ` Peter R @ 2015-08-05 22:44 ` Dave Hudson 2015-08-05 23:45 ` Tom Harding 0 siblings, 1 reply; 29+ messages in thread From: Dave Hudson @ 2015-08-05 22:44 UTC (permalink / raw) To: Peter R; +Cc: Bitcoin Dev > > On 5 Aug 2015, at 15:15, Peter R <peter_r@gmx•com> wrote: > > Hi Dave, > > Thank you for the feedback regarding my paper. > >> The paper is nicely done, but I'm concerned that there's a real problem with equation 4. The orphan rate is not just a function of time; it's also a function of the block maker's proportion of the network hash rate. Fundamentally a block maker (pool or aggregation of pools) does not orphan its own blocks. > > With the benefit of hindsight, I think the paper would be stronger if it also analyzed how the model changes (or doesn't) if we assume zero propagation impedance for intra-miner communication, as you suggested (the "you don't orphan your own blocks" idea). Note that the paper did briefly discuss miner-dependent propagation times in the second paragraph of page 9 and in note 13. I think this would be really interesting. It's an area that seems to be lacking research. While I've not had time to model it I did have a quick discussion with the author of the Organ-of-Corti blog a few months ago and he seemed to think that the Poisson process model isn't quite accurate here. Intuitively this makes sense as until a block has fully propagated we're only seeing some fraction of the actual hashing network operating on the same problem, so we actually see slightly fewer very quick blocks than we might expect. I do suspect that if we were to model this more accurately we might be able to infer the "typical" propagation characteristics by measuring the deviation from the expected distribution. >> Consider that a 1% miner must assume a greater risk from orphaning than, say, a pool with 25%, or worse 40% of the hash rate. > > I'd like to explore this in more detail. Although a miner may not orphan his own block, by building on his own block he may now orphan two blocks in a row. At some point, his solution or solutions must be communicated to his peers. And if there's information about the transactions in his blocks to communicate, I think there's a cost associated with that. It's an interesting problem and I'd like to continue working on it. \ Agreed - I think this would be really interesting! >> I suspect this may well change some of the conclusions as larger block makers will definitely be able to create larger blocks than their smaller counterparts. > > It will be interesting to see. I suspect that the main result that "a healthy fee market exists" will still hold (assuming of course that a single miner with >50% of the hash power isn't acting maliciously). Whether miners with larger value of h/H have a profit advantage, I'm not sure (but that was outside the scope of the paper anyways). I really look forward to seeing the revised version. Seeing the differences will also help assess how much impact there is from simplified models. Regards, Dave ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests 2015-08-05 22:44 ` Dave Hudson @ 2015-08-05 23:45 ` Tom Harding 0 siblings, 0 replies; 29+ messages in thread From: Tom Harding @ 2015-08-05 23:45 UTC (permalink / raw) To: bitcoin-dev On 8/5/2015 3:44 PM, Dave Hudson via bitcoin-dev wrote: > I do suspect that if we were to model this more accurately we might be > able to infer the "typical" propagation characteristics by measuring > the deviation from the expected distribution. The paper models propagation using a single time value that is a function of block size. Modeling the propagation distribution (which is totally separate from the poisson model of block production) would add a lot of complexity and my guess is the outcome would be little changed. >> On 5 Aug 2015, at 15:15, Peter R <peter_r@gmx•com> wrote: >> Although a miner may not orphan his own block, by building on his own block he may now orphan two blocks in a row. At some point, his solution or solutions must be communicated to his peers. Why complicate the analysis by assuming that a miner who finds two blocks sequentially does not publish the first, or that other miners would orphan miner's first block unless both were very quick? In general you don't consider anything beyond 1 block in the future, which seems fine. >>> I suspect this may well change some of the conclusions as larger block makers will definitely be able to create larger blocks than their smaller counterparts. >> It will be interesting to see. I suspect that the main result that "a healthy fee market exists" will still hold (assuming of course that a single miner with >50% of the hash power isn't acting maliciously). Whether miners with larger value of h/H have a profit advantage, I'm not sure (but that was outside the scope of the paper anyways). Correcting for non-orphaning of one's own blocks could be as simple as adding a factor (1 - h/H) to equation 4, which it appears would leave hashpower as an independent variable in the results. But at worst, the discussion can be considered to apply directly only to low-hashpower miners right now. Overall, the paper does not predict big changes to per/kb fees or spam costs for the kinds of block sizes being discussed for the immediate future (8MB). But it does conclude that these fees will rise, not fall, with bigger blocks. Also it is welcome that this paper actually mentions the bitcoin exchange rate as a factor in relation to block size (it points out that a spam attack is much more expensive in fiat terms today than it was years ago). ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests 2015-08-04 6:40 ` [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests Peter R 2015-08-04 18:41 ` Dave Hudson @ 2015-08-05 8:33 ` Benjamin 2015-08-05 9:18 ` Hector Chu 2015-08-05 10:26 ` Peter R [not found] ` <CAAS2fgTzeFnmnr2ScZvf1pDUtF+M3HhF9xo0yhjVPObpqhgz0A@mail.gmail.com> 2 siblings, 2 replies; 29+ messages in thread From: Benjamin @ 2015-08-05 8:33 UTC (permalink / raw) To: Peter R; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 3212 bytes --] Very interesting paper. When you talk about a market, what are you referring to exactly? A market means that demand and supply are matched continuously, and Bitcoin has no such mechanism. A lot of discussion has been around fixing the "supply" of blocksize. A floating number would mean that a hardcoded number or function would be replaced by a decision process involving users (demand). I don't think a fee market exists and that demand or supply are not easily definable. Ideally supply of transaction capability would completely depend on demand, and a price would exist such that demand can react to longterm or shorterm supply constraints. In such a scenario there would be no scalability concerns, as scale would be almost perfectly elastic. On Tue, Aug 4, 2015 at 8:40 AM, Peter R via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > Dear Bitcoin-Dev Mailing list, > > I’d like to share a research paper I’ve recently completed titled “A > Transaction Fee Market Exists Without a Block Size Limit.” In addition to > presenting some useful charts such as the cost to produce large spam > blocks, I think the paper convincingly demonstrates that, due to the > orphaning cost, a block size limit is not necessary to ensure a functioning > fee market. > > The paper does not argue that a block size limit is unnecessary in > general, and in fact brings up questions related to mining cartels and the > size of the UTXO set. > > It can be downloaded in PDF format here: > > https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf > > Or viewed with a web-browser here: > > > https://www.scribd.com/doc/273443462/A-Transaction-Fee-Market-Exists-Without-a-Block-Size-Limit > > *Abstract. *This paper shows how a rational Bitcoin miner should select > transactions from his node’s mempool, when creating a new block, in order > to maximize his profit in the absence of a block size limit. To show this, > the paper introduces the block space supply curve and the mempool demand > curve. The former describes the cost for a miner to supply block space by > accounting for orphaning risk. The latter represents the fees offered by > the transactions in mempool, and is expressed versus the minimum block size > required to claim a given portion of the fees. The paper explains how the > supply and demand curves from classical economics are related to the > derivatives of these two curves, and proves that producing the quantity of > block space indicated by their intersection point maximizes the miner’s > profit. The paper then shows that an unhealthy fee market—where miners are > incentivized to produce arbitrarily large blocks—cannot exist since it > requires communicating information at an arbitrarily fast rate. The paper > concludes by considering the conditions under which a rational miner would > produce big, small or empty blocks, and by estimating the cost of a spam > attack. > > Best regards, > Peter > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 4070 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests 2015-08-05 8:33 ` Benjamin @ 2015-08-05 9:18 ` Hector Chu 2015-08-05 9:57 ` Adam Back 2015-08-05 10:26 ` Peter R 1 sibling, 1 reply; 29+ messages in thread From: Hector Chu @ 2015-08-05 9:18 UTC (permalink / raw) To: Benjamin; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1607 bytes --] On 5 August 2015 at 09:33, Benjamin via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > A market means that demand and supply are matched continuously, and > Bitcoin has no such mechanism. > Not all markets need to have highly liquid trading outlets in order to be thought of as such. Inefficient markets are where there is an imperfect matching mechanism. I don't think a fee market exists and that demand or supply are not easily > definable. > Demand and supply are reflected in the market in the following two prices: - BTC/USD - Average transaction fee levels * Average transaction volume rate. In other words, this is the block-by-block, remainder of the block reward after subtracting the subsidy and priced in BTC. Actually the first one is the only proxy reflecting the current and future promise of Bitcoin, while the second only reflects the present. Miners would be uniquely placed to know how best to vary the block size to maximize their profit resulting from these two prices. The fact that they are unable to is limiting their collective profits, reducing competition between miners and increasing the average tx fee for users. In that respect a dynamic block size voted on by miners periodically would go some way to rectify this inefficiency. This needn't have to happen on the block chain itself; we could have a continuous prediction market for the block size, and the informed participants (miners) would stand to profit from the uninformed from trading in such a market. How to get the block chain to use the block size thus determined is another technical matter. [-- Attachment #2: Type: text/html, Size: 2195 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests 2015-08-05 9:18 ` Hector Chu @ 2015-08-05 9:57 ` Adam Back 2015-08-05 10:51 ` Hector Chu 0 siblings, 1 reply; 29+ messages in thread From: Adam Back @ 2015-08-05 9:57 UTC (permalink / raw) To: Hector Chu; +Cc: Bitcoin Dev On 5 August 2015 at 11:18, Hector Chu via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > Miners would be uniquely placed to know how best to vary the block size to maximize their > profit resulting from these two prices. [...] > In that respect a dynamic block size voted on by miners periodically would > go some way to rectify this inefficiency. This kind of thing has been discussed here, even recently. It is not without problems. You may find the flexcap idea summarised in outline by Greg Maxwell and Mark Friedenbach a month or so back interesting in showing that one can achieve such effects without handing over a free vote to miners and hence avoid many (though probably not all) of the side-effects inherent in giving miners control. About side-effects, I think we can make argument that there are limits because other than in an extremis sense, miners are not necessarily in alignment with security, nor maximising user utility and value delivered. For example switching cost economics are common in networks (cell phone service pricing), maybe Bitcoin would have a really high switching cost if miners would cartelise. Also miners are in a complex game competing with each other, and this degree of control risks selfish mining issues or other cartel attacks or bandwidth/verification/latency related attacks being made worse. eg see the recent paper by Aviv Zohar. Generally speaking economically dependent full nodes are holding miners honest by design. Changing that dynamic by shifting influence can have security and control impacting side-effects, and needs to be thought about carefully. About security to try to make those comparisons a bit more formal I posted this taxonomy of types of security that proposals could be compared against, in order of security: 1. consensus rule (your block is invalid if you attack) 2. economic incentive alignment (you tend to lose money if you attack) 3. overt (attack possible but detectable, hence probably less likely to happen for reputation or market signal reasons even if possible anonymously) 4. meta incentive (assume people would not attack if they have an investment or interest in seeing Bitcoin continue to succeed) Adam ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests 2015-08-05 9:57 ` Adam Back @ 2015-08-05 10:51 ` Hector Chu 2015-08-05 11:07 ` Adam Back 0 siblings, 1 reply; 29+ messages in thread From: Hector Chu @ 2015-08-05 10:51 UTC (permalink / raw) To: Adam Back; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1356 bytes --] On 5 August 2015 at 10:57, Adam Back <adam@cypherspace•org> wrote: > You may find the flexcap idea summarised in outline by Greg Maxwell > and Mark Friedenbach a month or so back interesting in showing that > one can achieve such effects without handing over a free vote to > miners and hence avoid many (though probably not all) of the > side-effects inherent in giving miners control. > The market I am thinking of would be open to all, not just miners. But miners would probably be best placed to profit from such a market, as it is their business to know about the revenue/costs tradeoff. About side-effects, I think we can make argument that there are limits > because other than in an extremis sense, miners are not necessarily in > alignment with security, nor maximising user utility and value > delivered. > If the block size was increasing at every settlement date (the dates on which, every 3 months say, the block size would be adjusted to the level indicated by the market) and users were getting concerned about centralization, the natural tendency would be for: a) The block size prediction market would tend to go back down. b) BTC/USD would tend to go down, reducing miner profit and indicating to them that the block size is too high. c) Transaction rate would decrease as some users stop using Bitcoin, also decreasing miner profit. [-- Attachment #2: Type: text/html, Size: 1875 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests 2015-08-05 10:51 ` Hector Chu @ 2015-08-05 11:07 ` Adam Back 2015-08-05 11:35 ` Hector Chu 0 siblings, 1 reply; 29+ messages in thread From: Adam Back @ 2015-08-05 11:07 UTC (permalink / raw) To: Hector Chu; +Cc: Bitcoin Dev On 5 August 2015 at 12:51, Hector Chu <hectorchu@gmail•com> wrote: > The market I am thinking of would be open to all, not just miners. But > miners would probably be best placed to profit from such a market, as it is > their business to know about the revenue/costs tradeoff. This prediction market in block-size seems like something extremely complex to operate and keep secure in a decentralised fashion. There are several experimental projects right now trying to figure out how to do this securely, using blockchain ideas, but it is early days for those projects. We also have no particular reason to suppose other than meta-incentive, that it should result in a secure parameter set. I suspect that, while it is interesting in the abstract, it risks converting a complex security problem into an even more complex one, rather than constituting an incremental security improvement which is more the context of day to day discussions here. Adam ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests 2015-08-05 11:07 ` Adam Back @ 2015-08-05 11:35 ` Hector Chu 2015-08-05 19:04 ` Hector Chu 0 siblings, 1 reply; 29+ messages in thread From: Hector Chu @ 2015-08-05 11:35 UTC (permalink / raw) To: Adam Back; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1054 bytes --] On 5 August 2015 at 12:07, Adam Back <adam@cypherspace•org> wrote: > This prediction market in block-size seems like something extremely > complex to operate and keep secure in a decentralised fashion. Why would it need to be decentralised? Bitcoin.org could run the exchange, and the profits from the exchange could be used to fund Core development. We also have no particular reason to suppose other than > meta-incentive, that it should result in a secure parameter set. > Security is a continuous variable, trading off against others. If security gradually begins to be threatened as a result of block size gradually increasing, the concerns of users will be enough that the bears will gain control over the bulls on the block size market. I suspect that, while it is interesting in the abstract, it risks > converting a complex security problem into an even more complex one, > rather than constituting an incremental security improvement which is > more the context of day to day discussions here. Hard problems call for complex solutions. [-- Attachment #2: Type: text/html, Size: 1687 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests 2015-08-05 11:35 ` Hector Chu @ 2015-08-05 19:04 ` Hector Chu 0 siblings, 0 replies; 29+ messages in thread From: Hector Chu @ 2015-08-05 19:04 UTC (permalink / raw) To: Adam Back; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2229 bytes --] To put some flesh on the bones of this idea, imagine a hypothetical security named BLK. Demand for bigger blocks should buy up BLK and demand for smaller blocks should short BLK. The price of BLK in BTC is the ideal block size. Now imagine that there are futures contracts for the security BLK. On the settlement date of those futures the current BLK/BTC price of those futures is taken to be the new Bitcoin block size for the next 3 months. For instance, if I predict or want the block size to be higher on September than it currently is, I would buy up September BLK futures. My actions would nudge the price up, and if come September I am right I get what I want and have a floating profit on the futures market. The nice thing about a futures market is that it allows capacity planning for the months ahead. Also there is no need for an underlying BLK security for a futures market in BLKs to exist. If the market is efficient and correctly sets the block size, BTC/USD will rise and the BTC profits of the market participants will go up in USD terms as a result. On 5 August 2015 at 12:35, Hector Chu <hectorchu@gmail•com> wrote: > On 5 August 2015 at 12:07, Adam Back <adam@cypherspace•org> wrote: > >> This prediction market in block-size seems like something extremely >> complex to operate and keep secure in a decentralised fashion. > > > Why would it need to be decentralised? Bitcoin.org could run the exchange, > and the profits from the exchange could be used to fund Core development. > > We also have no particular reason to suppose other than >> meta-incentive, that it should result in a secure parameter set. >> > > Security is a continuous variable, trading off against others. If security > gradually begins to be threatened as a result of block size gradually > increasing, the concerns of users will be enough that the bears will gain > control over the bulls on the block size market. > > I suspect that, while it is interesting in the abstract, it risks >> converting a complex security problem into an even more complex one, >> rather than constituting an incremental security improvement which is >> more the context of day to day discussions here. > > > Hard problems call for complex solutions. > [-- Attachment #2: Type: text/html, Size: 3227 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests 2015-08-05 8:33 ` Benjamin 2015-08-05 9:18 ` Hector Chu @ 2015-08-05 10:26 ` Peter R 1 sibling, 0 replies; 29+ messages in thread From: Peter R @ 2015-08-05 10:26 UTC (permalink / raw) To: Benjamin; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 5035 bytes --] Thank you for the feedback, Benjamin. > When you talk about a market, what are you referring to exactly? I define what I mean by healthy, unhealthy, and non-existent markets in Section 7, and I show a figure to illustrate the supply and demand curves in each of these three cases. A healthy market is defined as one where a rational miner would be incentivized to produce a finite block. An unhealthy market is one where a miner would be incentivized to produce an arbitrarily large block. A non-existant market is one where a miner is better off publishing an empty block. I show that so long as block space in a normal economic commodity that obeys the Law of Demand, and that the Shannon-Hartley theorem applies to the communication of the block solutions between miners, that an unhealthy market is not possible. > A market means that demand and supply are matched continuously, and Bitcoin has no such mechanism. Take a look at my definitions for the mempool demand curve (Sec 4) and the block space supply curve (Sec 5). I show that the miner's profit is a maximum at the point where the derivatives of these two curves intersect. I think of this as when "demand and supply are matched." > ...I don't think a fee market exists and that demand or supply are not easily definable. Do you not find the definitions presented in the paper for these curves useful? The mempool demand curve represents the empirical demand measureable from a miner’s mempool, while the block space supply curve represents the additional cost to create a block of size Q by accounting for orphaning risk. > Ideally supply of transaction capability would completely depend on demand, and a price would exist such that demand can react to longterm or shorterm supply constraints. Supply and demand do react. For example, if the cost to produce block space decreases (e.g., due to improvements in network interconnectivity) then a miner will be able to profitably include a greater number of transactions in his block. Furthermore, not only is there a minimum fee density below which no rational miner should include any transactions as Gavin observed, but the required fee density for inclusion also naturally increases if demand for space within a block is elevated. A rational miner will not necessarily include all fee-paying transactions, as urgent higher-paying transactions bump lower-fee transactions out, thereby bidding up the minimum fee density exponentially with demand. > In such a scenario there would be no scalability concerns, as scale would be almost perfectly elastic. Agreed. Best regards, Peter > > On Tue, Aug 4, 2015 at 8:40 AM, Peter R via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > Dear Bitcoin-Dev Mailing list, > > I’d like to share a research paper I’ve recently completed titled “A Transaction Fee Market Exists Without a Block Size Limit.” In addition to presenting some useful charts such as the cost to produce large spam blocks, I think the paper convincingly demonstrates that, due to the orphaning cost, a block size limit is not necessary to ensure a functioning fee market. > > The paper does not argue that a block size limit is unnecessary in general, and in fact brings up questions related to mining cartels and the size of the UTXO set. > > It can be downloaded in PDF format here: > > https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf > > Or viewed with a web-browser here: > > https://www.scribd.com/doc/273443462/A-Transaction-Fee-Market-Exists-Without-a-Block-Size-Limit > > Abstract. This paper shows how a rational Bitcoin miner should select transactions from his node’s mempool, when creating a new block, in order to maximize his profit in the absence of a block size limit. To show this, the paper introduces the block space supply curve and the mempool demand curve. The former describes the cost for a miner to supply block space by accounting for orphaning risk. The latter represents the fees offered by the transactions in mempool, and is expressed versus the minimum block size required to claim a given portion of the fees. The paper explains how the supply and demand curves from classical economics are related to the derivatives of these two curves, and proves that producing the quantity of block space indicated by their intersection point maximizes the miner’s profit. The paper then shows that an unhealthy fee market—where miners are incentivized to produce arbitrarily large blocks—cannot exist since it requires communicating information at an arbitrarily fast rate. The paper concludes by considering the conditions under which a rational miner would produce big, small or empty blocks, and by estimating the cost of a spam attack. > > Best regards, > Peter > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 6844 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <CAAS2fgTzeFnmnr2ScZvf1pDUtF+M3HhF9xo0yhjVPObpqhgz0A@mail.gmail.com>]
[parent not found: <6ED57388-6EC3-4515-BF3F-E753301537AB@gmx.com>]
[parent not found: <CAAS2fgRoFna4i-d=hpmz-CpV35VQ=J1aEoTTT6B1oD4f15C1KA@mail.gmail.com>]
[parent not found: <C8B38FEC-0EF2-483F-9E53-43AB937455A0@gmx.com>]
[parent not found: <CAAS2fgQjXNTi9Y_YwLg2dR8baYZhvmEjw43ictt749zR2AOEWw@mail.gmail.com>]
[parent not found: <6FED5604-4A6F-4CE1-B42E-36626375D557@gmx.com>]
[parent not found: <CAAS2fgQ7hRRvRtD8igcZ2aWBmnqre6iM27peCFGxgC8ODb9jgw@mail.gmail.com>]
[parent not found: <6BA86443-7534-4AAA-92BC-EC9B1603DE5F@gmx.com>]
[parent not found: <CAAS2fgTTZKD9LQHpMmEH0OU=T8Ta7cCaavWzhM1yQ68-MAT8UQ@mail.gmail.com>]
[parent not found: <27B16AB4-0DAD-4665-BF08-7A0C0A70D8D8@gmx.com>]
[parent not found: <CAAS2fgRm_CSmWgr7CGmBUD0nX+V0fJ8N4TQN01Vchgip9-s6uQ@mail.gmail.com>]
[parent not found: <CAAS2fgT+DP+DaoCMG276uF4=Yoi-w40YyNP-RDRG7NQgOmtpGw@mail.gmail.com>]
[parent not found: <CAEgR2PGn_SER18sMuKPJJz5RT=1K=346eCm ph5FJQhhoLcV1zw@mail.gmail.com>]
[parent not found: <CAEgR2PGn_SER18sMuKPJJz5RT=1K=346eCmph5FJQhhoLcV1zw@mail.gmail.com>]
* Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests [not found] ` <CAEgR2PGn_SER18sMuKPJJz5RT=1K=346eCmph5FJQhhoLcV1zw@mail.gmail.com> @ 2015-08-30 20:08 ` Peter R 2015-08-30 21:02 ` Daniele Pinna 0 siblings, 1 reply; 29+ messages in thread From: Peter R @ 2015-08-30 20:08 UTC (permalink / raw) To: Daniele Pinna; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1405 bytes --] Hi Daniele, I don't think there is any contention over the idea that miners that control a larger percentage of the hash rate, h / H, have a profitability advantage if you hold all the other variables of the miner's profit equation constant. I think this is important: it is a centralizing factor similar to other economies of scale. However, that is outside the scope of the result that an individual miner's profit per block is always maximized at a finite block size Q* if Shannon Entropy about each transaction is communicated during the block solution announcement. This result is important because it explains how a minimum fee density exists and it shows how miners cannot create enormous spam blocks for "no cost," for example. Best regards, Peter > 2) Whether it's truly possible for a miner's marginal profit per unit of hash to decrease with increasing hashrate in some parametric regime.This however directly contradicts the assumption that an optimal hashrate exists beyond which the revenue per unit of hash v' < v if h' > h. > Q.E.D > > This theorem in turn implies the following corollary: > > COROLLARY: The marginal profit curve is a monotonically increasing of miner hashrate. > > This simple theorem, suggested implicitly by Gmaxwell disproves any and all conclusions of my work. Most importantly, centralization pressures will always be present. [-- Attachment #2: Type: text/html, Size: 5724 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests 2015-08-30 20:08 ` Peter R @ 2015-08-30 21:02 ` Daniele Pinna 0 siblings, 0 replies; 29+ messages in thread From: Daniele Pinna @ 2015-08-30 21:02 UTC (permalink / raw) To: Peter R; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 2403 bytes --] "However, that is outside the scope of the result that an individual miner's profit per block is always maximized at a finite block size Q* if Shannon Entropy about each transaction is communicated during the block solution announcement. This result is important because it explains how a minimum fee density exists and it shows how miners cannot create enormous spam blocks for "no cost," for example. " Dear Peter, This might very well not be the case. Since the expected revenue *<V>* in our formulas is but a lower bound to the true expected revenue, and the fee supply curve [image: M_s(Q)\propto 1/\langle V\rangle], if the true expected revenue doesn't decay faster than the mempool's average transaction fee (or, more simply, if it doesn't decay to zero) then the maximum miner surplus will be unbounded and unhealthy fee markets will emerge. Best, Daniele Daniele Pinna, Ph.D On Sun, Aug 30, 2015 at 10:08 PM, Peter R <peter_r@gmx•com> wrote: > Hi Daniele, > > I don't think there is any contention over the idea that miners that > control a larger percentage of the hash rate, *h */ *H*, have a > profitability advantage if you hold all the other variables of the miner's > profit equation constant. I think this is important: it is a centralizing > factor similar to other economies of scale. > > However, that is outside the scope of the result that an individual > miner's profit per block is always maximized at a finite block size Q* if > Shannon Entropy about each transaction is communicated during the block > solution announcement. This result is important because it explains how a > minimum fee density exists and it shows how miners cannot create enormous > spam blocks for "no cost," for example. > > Best regards, > Peter > > > 2) Whether it's truly possible for a miner's marginal profit per unit of > hash to decrease with increasing hashrate in some parametric regime.This > however directly contradicts the assumption that an optimal hashrate exists > beyond which the revenue per unit of hash *v' < v *if *h' > h. * > *Q.E.D * > > This theorem in turn implies the following corollary: > > *COROLLARY: **The marginal profit curve is a monotonically increasing of > miner hashrate.* > > This simple theorem, suggested implicitly by Gmaxwell disproves any and > all conclusions of my work. Most importantly, centralization pressures will > always be present. > > > [-- Attachment #2: Type: text/html, Size: 6860 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Eli Dourado on "governance" 2015-08-03 15:22 [bitcoin-dev] Eli Dourado on "governance" Gavin Andresen [not found] ` <1438640036.2828.0.camel@auspira.com> @ 2015-08-04 14:22 ` Anthony Towns 2015-08-04 18:28 ` Owen 2015-08-07 16:26 ` Thomas Zander 2 siblings, 1 reply; 29+ messages in thread From: Anthony Towns @ 2015-08-04 14:22 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2227 bytes --] On 4 August 2015 at 01:22, Gavin Andresen via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > And the preliminary results of using a prediction market to try to wrestle > with the tough tradeoffs looks roughly correct to me, too: > https://blocksizedebate.com/ > The scicast prediction market is shutdown atm (since early July?) so those numbers aren't live. But... Network hash rate 3,255.17 PH/s (same block size) 5,032.64 PH/s (block size increase) 4,969.68 PH/s (no replace-by-fee) 3,132.09 PH/s (replace-by-fee) Those numbers seem completely implausible: that's ~2.9-3.6 doublings of the current hashrate (< 400PH/s) in 17 months, when it's taken 12 months for the last doubling, and there's a block reward reduction due in that period too. (That might've been a reasonable prediction sometime in the past year, when doublings were slowing from once every ~45 days to once a year; it just doesn't seem a supportable prediction now) That the PH/s rate is higher with bigger blocks is surprising, but given that site also predicts USD/BTC will be $280 with no change but $555 with bigger blocks, so I assume that difference is mostly due to price. Also, 12.5btc at $555 each is about 23 btc at $300 each, so if that price increase is realistic, it would compensate for almost all of the block reward reduction. Daily transaction volume 168,438.22 tx/day (same block size) 193,773.08 tx/day (block size increase) 192,603.80 tx/day (no replace-by-fee) 168,406.73 tx/day (replace-by-fee) That's only a 15% increase in transaction volume due to the block size increase; I would have expected more? 168k-194k tx/day is also only a 30%-50% increase in transaction volume from 130k tx/day currently. If that's really the case, then a 1.5MB-2MB max block size would probably be enough for the next two years... (Predicting that the node count will drop from ~5000 to ~1200 due to increasing block sizes seems quite an indictment as far as centralisation risks go; but given I'm not that convinced by the other predictions, I'm not sure I want to give that much weight to that one either) Cheers, aj -- Anthony Towns <aj@erisian•com.au> [-- Attachment #2: Type: text/html, Size: 5271 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Eli Dourado on "governance" 2015-08-04 14:22 ` [bitcoin-dev] Eli Dourado on "governance" Anthony Towns @ 2015-08-04 18:28 ` Owen 2015-08-05 3:07 ` Eric Lombrozo 0 siblings, 1 reply; 29+ messages in thread From: Owen @ 2015-08-04 18:28 UTC (permalink / raw) To: Anthony Towns, Anthony Towns via bitcoin-dev, Gavin Andresen; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2800 bytes --] Given there is no money at stake in these prediction games, it is no surprise that the results are implausible. On August 4, 2015 10:22:19 AM EDT, Anthony Towns via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: >On 4 August 2015 at 01:22, Gavin Andresen via bitcoin-dev < >bitcoin-dev@lists•linuxfoundation.org> wrote: > >> And the preliminary results of using a prediction market to try to >wrestle >> with the tough tradeoffs looks roughly correct to me, too: >> https://blocksizedebate.com/ >> > >The scicast prediction market is shutdown atm (since early July?) so >those >numbers aren't live. But... > >Network hash rate >3,255.17 PH/s (same block size) >5,032.64 PH/s (block size increase) > >4,969.68 PH/s (no replace-by-fee) >3,132.09 PH/s (replace-by-fee) > >Those numbers seem completely implausible: that's ~2.9-3.6 doublings of >the >current hashrate (< 400PH/s) in 17 months, when it's taken 12 months >for >the last doubling, and there's a block reward reduction due in that >period >too. (That might've been a reasonable prediction sometime in the past >year, >when doublings were slowing from once every ~45 days to once a year; it >just doesn't seem a supportable prediction now) > >That the PH/s rate is higher with bigger blocks is surprising, but >given >that site also predicts USD/BTC will be $280 with no change but $555 >with >bigger blocks, so I assume that difference is mostly due to price. >Also, >12.5btc at $555 each is about 23 btc at $300 each, so if that price >increase is realistic, it would compensate for almost all of the block >reward reduction. > >Daily transaction volume >168,438.22 tx/day (same block size) >193,773.08 tx/day (block size increase) > >192,603.80 tx/day (no replace-by-fee) >168,406.73 tx/day (replace-by-fee) > >That's only a 15% increase in transaction volume due to the block size >increase; I would have expected more? 168k-194k tx/day is also only a >30%-50% increase in transaction volume from 130k tx/day currently. If >that's really the case, then a 1.5MB-2MB max block size would probably >be >enough for the next two years... > >(Predicting that the node count will drop from ~5000 to ~1200 due to >increasing block sizes seems quite an indictment as far as >centralisation >risks go; but given I'm not that convinced by the other predictions, >I'm >not sure I want to give that much weight to that one either) > >Cheers, >aj > >-- >Anthony Towns <aj@erisian•com.au> > > >------------------------------------------------------------------------ > >_______________________________________________ >bitcoin-dev mailing list >bitcoin-dev@lists•linuxfoundation.org >https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Type: text/html, Size: 6095 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Eli Dourado on "governance" 2015-08-04 18:28 ` Owen @ 2015-08-05 3:07 ` Eric Lombrozo 2015-08-05 6:32 ` Mashuri Clark 2015-08-05 13:28 ` Mashuri Clark 0 siblings, 2 replies; 29+ messages in thread From: Eric Lombrozo @ 2015-08-05 3:07 UTC (permalink / raw) To: Owen; +Cc: Anthony Towns via bitcoin-dev [-- Attachment #1.1: Type: text/plain, Size: 3236 bytes --] Rather than speculating on fake markets, why don’t we use theory, empirical data, and engineering to fix the damn problems? > On Aug 4, 2015, at 11:28 AM, Owen via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > > Given there is no money at stake in these prediction games, it is no surprise that the results are implausible. > > On August 4, 2015 10:22:19 AM EDT, Anthony Towns via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > On 4 August 2015 at 01:22, Gavin Andresen via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote: > And the preliminary results of using a prediction market to try to wrestle with the tough tradeoffs looks roughly correct to me, too: > https://blocksizedebate.com/ <https://blocksizedebate.com/> > > The scicast prediction market is shutdown atm (since early July?) so those numbers aren't live. But... > > Network hash rate > 3,255.17 PH/s (same block size) > 5,032.64 PH/s (block size increase) > > 4,969.68 PH/s (no replace-by-fee) > 3,132.09 PH/s (replace-by-fee) > > Those numbers seem completely implausible: that's ~2.9-3.6 doublings of the current hashrate (< 400PH/s) in 17 months, when it's taken 12 months for the last doubling, and there's a block reward reduction due in that period too. (That might've been a reasonable prediction sometime in the past year, when doublings were slowing from once every ~45 days to once a year; it just doesn't seem a supportable prediction now) > > That the PH/s rate is higher with bigger blocks is surprising, but given that site also predicts USD/BTC will be $280 with no change but $555 with bigger blocks, so I assume that difference is mostly due to price. Also, 12.5btc at $555 each is about 23 btc at $300 each, so if that price increase is realistic, it would compensate for almost all of the block reward reduction. > > Daily transaction volume > 168,438.22 tx/day (same block size) > 193,773.08 tx/day (block size increase) > > 192,603.80 tx/day (no replace-by-fee) > 168,406.73 tx/day (replace-by-fee) > > That's only a 15% increase in transaction volume due to the block size increase; I would have expected more? 168k-194k tx/day is also only a 30%-50% increase in transaction volume from 130k tx/day currently. If that's really the case, then a 1.5MB-2MB max block size would probably be enough for the next two years... > > (Predicting that the node count will drop from ~5000 to ~1200 due to increasing block sizes seems quite an indictment as far as centralisation risks go; but given I'm not that convinced by the other predictions, I'm not sure I want to give that much weight to that one either) > > Cheers, > aj > > -- > Anthony Towns <aj@erisian•com.au <mailto:aj@erisian•com.au>> > > > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #1.2: Type: text/html, Size: 7827 bytes --] [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 842 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Eli Dourado on "governance" 2015-08-05 3:07 ` Eric Lombrozo @ 2015-08-05 6:32 ` Mashuri Clark 2015-08-05 13:28 ` Mashuri Clark 1 sibling, 0 replies; 29+ messages in thread From: Mashuri Clark @ 2015-08-05 6:32 UTC (permalink / raw) To: bitcoin-dev, Owen, Eric Lombrozo; +Cc: Anthony Towns via bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 3285 bytes --] Why not speculate on a real market? Peter Sztorc proposed a sidechain that could be implemented now using Blockstream's method: http://www.truthcoin.info/blog/win-win-blocksize/ -- MC On Tue, Aug 4, 2015 at 8:08 PM -0700, "Eric Lombrozo via bitcoin-dev" <bitcoin-dev@lists•linuxfoundation.org> wrote: Rather than speculating on fake markets, why don’t we use theory, empirical data, and engineering to fix the damn problems? On Aug 4, 2015, at 11:28 AM, Owen via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: Given there is no money at stake in these prediction games, it is no surprise that the results are implausible. On August 4, 2015 10:22:19 AM EDT, Anthony Towns via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: On 4 August 2015 at 01:22, Gavin Andresen via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: And the preliminary results of using a prediction market to try to wrestle with the tough tradeoffs looks roughly correct to me, too: https://blocksizedebate.com/ The scicast prediction market is shutdown atm (since early July?) so those numbers aren't live. But... Network hash rate 3,255.17 PH/s (same block size) 5,032.64 PH/s (block size increase) 4,969.68 PH/s (no replace-by-fee) 3,132.09 PH/s (replace-by-fee) Those numbers seem completely implausible: that's ~2.9-3.6 doublings of the current hashrate (< 400PH/s) in 17 months, when it's taken 12 months for the last doubling, and there's a block reward reduction due in that period too. (That might've been a reasonable prediction sometime in the past year, when doublings were slowing from once every ~45 days to once a year; it just doesn't seem a supportable prediction now) That the PH/s rate is higher with bigger blocks is surprising, but given that site also predicts USD/BTC will be $280 with no change but $555 with bigger blocks, so I assume that difference is mostly due to price. Also, 12.5btc at $555 each is about 23 btc at $300 each, so if that price increase is realistic, it would compensate for almost all of the block reward reduction. Daily transaction volume 168,438.22 tx/day (same block size) 193,773.08 tx/day (block size increase) 192,603.80 tx/day (no replace-by-fee) 168,406.73 tx/day (replace-by-fee) That's only a 15% increase in transaction volume due to the block size increase; I would have expected more? 168k-194k tx/day is also only a 30%-50% increase in transaction volume from 130k tx/day currently. If that's really the case, then a 1.5MB-2MB max block size would probably be enough for the next two years... (Predicting that the node count will drop from ~5000 to ~1200 due to increasing block sizes seems quite an indictment as far as centralisation risks go; but given I'm not that convinced by the other predictions, I'm not sure I want to give that much weight to that one either) Cheers,aj -- Anthony Towns <aj@erisian•com.au> bitcoin-dev mailing list bitcoin-dev@lists•linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists•linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Type: text/html, Size: 8573 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Eli Dourado on "governance" 2015-08-05 3:07 ` Eric Lombrozo 2015-08-05 6:32 ` Mashuri Clark @ 2015-08-05 13:28 ` Mashuri Clark 1 sibling, 0 replies; 29+ messages in thread From: Mashuri Clark @ 2015-08-05 13:28 UTC (permalink / raw) To: bitcoin-dev, Owen, Eric Lombrozo; +Cc: Anthony Towns via bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 3186 bytes --] CORRECTION: That's Paul Sztorc. Not Peter. Apologies for my abysmal proofreading. -- MC On Tue, Aug 4, 2015 at 8:08 PM -0700, "Eric Lombrozo via bitcoin-dev" <bitcoin-dev@lists•linuxfoundation.org> wrote: Rather than speculating on fake markets, why don’t we use theory, empirical data, and engineering to fix the damn problems? On Aug 4, 2015, at 11:28 AM, Owen via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: Given there is no money at stake in these prediction games, it is no surprise that the results are implausible. On August 4, 2015 10:22:19 AM EDT, Anthony Towns via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: On 4 August 2015 at 01:22, Gavin Andresen via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: And the preliminary results of using a prediction market to try to wrestle with the tough tradeoffs looks roughly correct to me, too: https://blocksizedebate.com/ The scicast prediction market is shutdown atm (since early July?) so those numbers aren't live. But... Network hash rate 3,255.17 PH/s (same block size) 5,032.64 PH/s (block size increase) 4,969.68 PH/s (no replace-by-fee) 3,132.09 PH/s (replace-by-fee) Those numbers seem completely implausible: that's ~2.9-3.6 doublings of the current hashrate (< 400PH/s) in 17 months, when it's taken 12 months for the last doubling, and there's a block reward reduction due in that period too. (That might've been a reasonable prediction sometime in the past year, when doublings were slowing from once every ~45 days to once a year; it just doesn't seem a supportable prediction now) That the PH/s rate is higher with bigger blocks is surprising, but given that site also predicts USD/BTC will be $280 with no change but $555 with bigger blocks, so I assume that difference is mostly due to price. Also, 12.5btc at $555 each is about 23 btc at $300 each, so if that price increase is realistic, it would compensate for almost all of the block reward reduction. Daily transaction volume 168,438.22 tx/day (same block size) 193,773.08 tx/day (block size increase) 192,603.80 tx/day (no replace-by-fee) 168,406.73 tx/day (replace-by-fee) That's only a 15% increase in transaction volume due to the block size increase; I would have expected more? 168k-194k tx/day is also only a 30%-50% increase in transaction volume from 130k tx/day currently. If that's really the case, then a 1.5MB-2MB max block size would probably be enough for the next two years... (Predicting that the node count will drop from ~5000 to ~1200 due to increasing block sizes seems quite an indictment as far as centralisation risks go; but given I'm not that convinced by the other predictions, I'm not sure I want to give that much weight to that one either) Cheers,aj -- Anthony Towns <aj@erisian•com.au> bitcoin-dev mailing list bitcoin-dev@lists•linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists•linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Type: text/html, Size: 8422 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Eli Dourado on "governance" 2015-08-03 15:22 [bitcoin-dev] Eli Dourado on "governance" Gavin Andresen [not found] ` <1438640036.2828.0.camel@auspira.com> 2015-08-04 14:22 ` [bitcoin-dev] Eli Dourado on "governance" Anthony Towns @ 2015-08-07 16:26 ` Thomas Zander 2 siblings, 0 replies; 29+ messages in thread From: Thomas Zander @ 2015-08-07 16:26 UTC (permalink / raw) To: Bitcoin Dev On Monday 3. August 2015 11.22.14 Gavin Andresen via bitcoin-dev wrote: > (my only big disagreement with those predictions is the 'Number of nodes' > -- I don't think replace-by-fee would affect that number, and I think even > with no change we will see the number of full nodes on the network drop to > a couple thousand, because the general-purpose-home-PC is headed the way of > the dodo [] On the other hand, things like the Raspberry PI and similar hardware are gaining ground fast. And they can run a node just fine. I have many friends that run such small hardware for things like Owncloud.org because it is decentralized. When Bitcoin gets traction with these people, I have no doubt a nice portion of them will run a node for the same reason they are running their private cloud. Trust No One. Or, in other words, when Bitcoin grows in popularity and more people find it interesting (and we fix longstanding issues in Core), the desktop node that eventually get shut down will be replaced with the next generation hardware of a different kind of Bitcoin user. -- Thomas Zander ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2015-08-30 21:03 UTC | newest]
Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-08-03 15:22 [bitcoin-dev] Eli Dourado on "governance" Gavin Andresen
[not found] ` <1438640036.2828.0.camel@auspira.com>
2015-08-03 22:21 ` Gavin Andresen
2015-08-04 6:40 ` [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests Peter R
2015-08-04 18:41 ` Dave Hudson
2015-08-04 21:18 ` Peter Todd
2015-08-04 21:30 ` Gavin Andresen
2015-08-04 21:46 ` Peter Todd
2015-08-05 0:26 ` Milly Bitcoin
2015-08-05 0:40 ` Neil Fincham
2015-08-04 23:37 ` Dave Hudson
2015-08-05 22:15 ` Peter R
2015-08-05 22:44 ` Dave Hudson
2015-08-05 23:45 ` Tom Harding
2015-08-05 8:33 ` Benjamin
2015-08-05 9:18 ` Hector Chu
2015-08-05 9:57 ` Adam Back
2015-08-05 10:51 ` Hector Chu
2015-08-05 11:07 ` Adam Back
2015-08-05 11:35 ` Hector Chu
2015-08-05 19:04 ` Hector Chu
2015-08-05 10:26 ` Peter R
[not found] ` <CAAS2fgTzeFnmnr2ScZvf1pDUtF+M3HhF9xo0yhjVPObpqhgz0A@mail.gmail.com>
[not found] ` <6ED57388-6EC3-4515-BF3F-E753301537AB@gmx.com>
[not found] ` <CAAS2fgRoFna4i-d=hpmz-CpV35VQ=J1aEoTTT6B1oD4f15C1KA@mail.gmail.com>
[not found] ` <C8B38FEC-0EF2-483F-9E53-43AB937455A0@gmx.com>
[not found] ` <CAAS2fgQjXNTi9Y_YwLg2dR8baYZhvmEjw43ictt749zR2AOEWw@mail.gmail.com>
[not found] ` <6FED5604-4A6F-4CE1-B42E-36626375D557@gmx.com>
[not found] ` <CAAS2fgQ7hRRvRtD8igcZ2aWBmnqre6iM27peCFGxgC8ODb9jgw@mail.gmail.com>
[not found] ` <6BA86443-7534-4AAA-92BC-EC9B1603DE5F@gmx.com>
[not found] ` <CAAS2fgTTZKD9LQHpMmEH0OU=T8Ta7cCaavWzhM1yQ68-MAT8UQ@mail.gmail.com>
[not found] ` <27B16AB4-0DAD-4665-BF08-7A0C0A70D8D8@gmx.com>
[not found] ` <CAAS2fgRm_CSmWgr7CGmBUD0nX+V0fJ8N4TQN01Vchgip9-s6uQ@mail.gmail.com>
[not found] ` <CAAS2fgT+DP+DaoCMG276uF4=Yoi-w40YyNP-RDRG7NQgOmtpGw@mail.gmail.com>
[not found] ` <CAEgR2PGn_SER18sMuKPJJz5RT=1K=346eCm ph5FJQhhoLcV1zw@mail.gmail.com>
[not found] ` <CAEgR2PGn_SER18sMuKPJJz5RT=1K=346eCmph5FJQhhoLcV1zw@mail.gmail.com>
2015-08-30 20:08 ` Peter R
2015-08-30 21:02 ` Daniele Pinna
2015-08-04 14:22 ` [bitcoin-dev] Eli Dourado on "governance" Anthony Towns
2015-08-04 18:28 ` Owen
2015-08-05 3:07 ` Eric Lombrozo
2015-08-05 6:32 ` Mashuri Clark
2015-08-05 13:28 ` Mashuri Clark
2015-08-07 16:26 ` Thomas Zander
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox