[bitcoin-dev] Eli Dourado on "governance"

[bitcoin-dev] Eli Dourado on "governance"

[Gavin Andresen]

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

Re: [bitcoin-dev] Eli Dourado on "governance"

[Gavin Andresen]

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

[bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests

[Peter R]

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

Re: [bitcoin-dev] Eli Dourado on "governance"

[Anthony Towns]

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

Re: [bitcoin-dev] Eli Dourado on "governance"

[Owen]

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

Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests

[Dave Hudson]

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

Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests

[Peter Todd]

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

Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests

[Gavin Andresen]

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

Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests

[Peter Todd]

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

Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests

[Dave Hudson]

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

Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests

[Milly Bitcoin]

>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

Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests

[Neil Fincham]

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

Re: [bitcoin-dev] Eli Dourado on "governance"

[Eric Lombrozo]

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

Re: [bitcoin-dev] Eli Dourado on "governance"

[Mashuri Clark]

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

Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests

[Benjamin]

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

Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests

[Hector Chu]

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

Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests

[Adam Back]

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

Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests

[Peter R]

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

Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests

[Hector Chu]

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

Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests

[Adam Back]

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

Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests

[Hector Chu]

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

Re: [bitcoin-dev] Eli Dourado on "governance"

[Mashuri Clark]

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

Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests

[Hector Chu]

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

Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests

[Peter R]

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

Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests

[Dave Hudson]

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

Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests

[Tom Harding]

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

Re: [bitcoin-dev] Eli Dourado on "governance"

[Thomas Zander]

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

Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests

[Peter R]

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

Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests

[Daniele Pinna]

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