Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)

[Elliot Olds via bitcoin-dev]

On Fri, Aug 28, 2015 at 4:46 PM, Btc Drak via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sat, Aug 29, 2015 at 12:35 AM, Chris Pacia via bitcoin-dev
> > It may be in everyone's collective interest to raise the block size but
> not
> > their individual interest.
>
> It is clear from recent events that miners are willing to collaborate
> together for the greater good of their industry. Miners have also
> publicly shown support for raising the blocksize collaboratively.
>

When have miners shown a willingness to make sacrifices for miners as a
whole when they've been in a "public good"[1] situation? Miners
collaborating to release statements to the public about which BIPs they
support is very different from miners incurring costs only to themselves in
order to help the entire group. They might do so, but it isn't clear.

I agree with Jorge and Mark that allowing miners to vote on the block size
is not ideal. Miners interests are somewhat aligned with those of the
broader community, but not perfectly aligned. The block size level that
maximizes miner revenue is not necessarily desirable overall. More miner
revenue is only good if the marginal extra security that it buys is worth
the extra cost. In addition to the cost of higher user fees, there's
another hidden cost. In Bitcoin's early stages trying to maximize revenue
too soon can slow growth and result in less revenue when it's more needed
(when block rewards are much lower).

[1] https://en.wikipedia.org/wiki/Public_good
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)

[jl2012 via bitcoin-dev]

We need some game theory experts to analyse this but I see there are 3 
major problems:


1. Tragedy of the commons: Some miners have to scarify their income to 
increase the block size, and all miners will share the beneficial 
outcome of the increase. All miners would like to be free riders.


2. Promote the formation of mining cartel: miners have to make sure that 
their vote for increase is supported by at least 50% of miners, or they 
will lose income for nothing. A miner also needs to make sure that he is 
not voting "excessively" (in terms of size and vote count), as the 
excessive part will never be counted due to the use of median. So 
basically you will either have exactly 1009 miners voting for the same 
size increase in a cycle, or have no vote for increase at all. That will 
require a lot of offline negotiations. Such cartel may work ONLY if 
mining is highly centralized, and miners trust each other. Also, there 
is no mechanism to punish those who betray the cartel.


3. Imbalance of power: it is costly to increase the size, while totally 
free to decrease the size



Btc Drak via bitcoin-dev 於 2015-08-28 16:28 寫到:

I have received a lot of feedback on the original gist[1], reddit[2],
ML and IRC and have reworked the text somewhat.

I also request the BIP maintainer for a BIP number assignment

[1] https://gist.github.com/btcdrak/1c3a323100a912b605b5
[2]
https://www.reddit.com/r/Bitcoin/comments/3ibia0/bipxx_consensus_based_block_size_retargeting/

Pull request: https://github.com/bitcoin/bips/pull/187


  BIP: XX
  Title: Consensus based block size retargeting algorithm
  Author: BtcDrak 
  Status: Draft
  Type: Standards Track
  Created: 2015-08-21


==Abstract==

A method of altering the maximum allowed block size of the Bitcoin 
protocol

using a consensus based approach.

==Motivation==

There is a belief that Bitcoin cannot easily respond to raising the
blocksize limit if popularity was to suddenly increase due to a mass 
adoption
curve, because co-ordinating a hard fork takes considerable time, and 
being
unable to respond in a timely manner would irreparably harm the 
credibility of

bitcoin.

Additionally, predetermined block size increases are problematic 
because they

attempt to predict the future, and if too large could have unintended
consequences like damaging the possibility for a fee market to develop
as block subsidy decreases substantially over the next 9 years; 
introducing
or exacerbating mining attack vectors; or somehow affect the network in 
unknown
or unpredicted ways. Since fixed changes are hard to deploy, the damage 
could be

extensive.

Dynamic block size adjustments also suffer from the potential to be 
gamed by the

larger hash power.

Free voting as suggested by BIP100 allows miners to sell their votes 
out of band
at no risk, and enable the sponsor the ability to manipulate the 
blocksize.
It also provides a cost free method or the larger pools to vote in ways 
to

manipulate the blocksize such to disadvantage or attack smaller pools.


==Rationale==

By introducing a cost to increase the block size ensures the mining 
community
will collude to increase it only when there is a clear necessity, and 
reduce it
when it is unnecessary. Larger miners cannot force their wishes so 
easily
because not only will they have to pay extra a difficulty target, then 
can be

downvoted at no cost by the objecting hash power.

Using difficulty as a penalty is better than a fixed cost in bitcoins 
because it

is less predictable.


==Specification==

The initial block size limit shall be 1MB.

Each time a miner creates a block, they may vote to increase or 
decrease the
blocksize by a maximum of 10% of the current block size limit. These 
votes will

be used to recalculate the new block size limit every 2016 blocks.

Votes are cast using the block's coinbase field.

The first 4 bytes of the coinbase field shall be repurposed for voting 
as an

unsigned long integer which will be the block size in bytes.

If a miner votes for an increase, the block hash must meet a difficulty 
target
which is proportionally larger than the standard difficulty target 
based on the

percentage increase they voted for.

Votes proposing decreasing the block size limit do not need to meet a 
higher

difficulty target.

Miners can vote for no change by voting for the current block size.

For blocks to be valid the blockhash must meet the required difficulty 
target

for the vote otherwise the block is invalid and will be rejected.

Every 2016 blocks, the block size limit will be recalculated by the 
median of
all votes in the last 2016 blocks. This will redefine the block size 
limit for

the next 2016 blocks.

Blocks that are larger than the calculated base block size limit are 
invalid and

will be rejected.

The base block size limit may not reduce below 1MB.


==Acknowledgements==

This proposal is based on ideas and concepts derived from the writings 
of

Meni Rosenfeld and Gregory Maxwell.


==

Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)

[Btc Drak via bitcoin-dev]

On Sat, Aug 29, 2015 at 1:29 AM, Mark Friedenbach via bitcoin-dev
 wrote:
> Ah, then my mistake. It seemed so similar to an idea that was proposed
> before on this mailing list:
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008033.html
>
> that my mind just filled in the gaps. I concur -- having miners -- or any
> group -- vote on block size is not an intrinsically good thing. The the
> original proposal due to Greg Maxwell et al was not a mechanism for "voting"
> but rather a feedback control that made the maximum block size that which
> generated the most fees.

Mark and Jorge,

I am very glad you have brought up this particular objection because
it's something I thought about but was unclear if it was an opinion
that would be shared by others. I chose to omit it from the proposal
to see if it would come up during peer review.

I feel that giving miners a blank cheque to increase blocksize, by any
means, goes against a key design of bitcoin's security model. Full
nodes keep miners honest by ensuring by validating their blocks. Under
any voting-only scheme there is no way for full nodes to keep miners
in cheque because miner have free reign to increase the blocksize.

This problem can be solved by introducing a hard cap on blocksize. By
introducing an upper limit miners now have the freedom to increase
blocksize but only within defined parameters.  Remember my proposal
allows blocksize to increase and decrease in such a way that miners
must collectively agree if they want the size to increase.

I believe the idea of a hard upper limit has become rather politicised
but is essential to the security model of bitcoin.

With respect to the flexicap idea where miners can create a larger
block by paying extra difficulty, I believe that proposal has a
critical flaw because, as Gavin pointed out, it makes it very
expensive (and risky) to include a few extra transactions. I believe
it suffers from tragedy of the commons because there is no incentive
for the mining community to reach consensus. Each and every block is
going to be a gamble, "should we include a few extra transactions at
the risk of losing the block?". Under my proposal miners can
collectively agree to change the blocksize. Let's say they want a 10%
increase, they can collude together to make that increase and once
reached, it remains until they want to change it again. Yet, the upper
hard limit keeps the ultimate control of the maximum block size
squarely in the hands of full nodes.

Whilst the exact number may be up for discussion, I would propose an
initial upper limit of 8MB, so under my proposal the blocksize would
be flexible between 1MB and 8MB.

An alternative methodology to voting in the coinbase would be to
change the vote to be the blocksize itself

1. miners pay extra difficulty to create a larger block.
2. every 2016 blocks the average or median of the last 2016 blocks is
calculated and becomes the new maximum blocksize limit.

This would retain incentive to collude to increase blocksize, as well
as the property of costing to increase while being free to propose
decrease.

It would still require an upper blocksize limit in order for full
nodes to retain control. Without an upper limit, any proposal is going
to break the security model as full nodes give up some oversight
control over miners.

Another way of looking at these ideas is we're raising blocksize hard
limit (to 8MB or whatever is decided), but making a soft of "softer"
or inner limit part of consensus. Such a concept is not really
departing from the current idea of a soft limit except to make it
consensus enforced. Obviously it's not identical, but I think you can
see the similarities.

Does that make sense?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration

[Marco Pontello via bitcoin-dev]

Hi!
My first post here, hope I'm following the right conventions.
I had this humble idea for a while, so I thought to go ahead and propose
it.

BIP: XX
Title: URI scheme for Blockchain exploration
Author: Marco Pontello
Status: Draft
Type: Standards Track
Created: 29 August 2015

Abstract

This BIP propose a simple URI scheme for looking up blocks, transactions,
addresses on a Blockchain explorer.

Motivation
==
The purpose of this URI scheme is to enable users to handle all the
requests for details about blocks, transactions, etc. with their preferred
tool (being that a web service or a local application).

Currently a Bitcoin client usually point to an arbitrary blockchain
explorer when the user look for the details of a transaction (es. Bitcoin
Wallet use BitEasy, Mycelium or Electrum use Blockchain.info, etc.).
Other times resorting to cut&paste is needed.
The same happens with posts and messages that reference some particular
txs or blocks, if they provide links at all.

Specification
=
The URI follow this simple form:

blockchain: 

Examples:

blockchain:1003e880d500968d51157f210c632e08a652af3576600198
blockchain:001949
blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a

Rationale
=
I thought about using some more complex scheme, or adding qualifiers to
distinguish blocks from txs, but in the end I think that keeping it simple
should be practical enough. Blockchain explorers can apply the same
disambiguation rules they are already using to process the usual search
box.

>From the point of view of a wallet developer (or other tool that need to
show any kind of Blockchain references), using this scheme mean that he
can simply make it a blockchain: link and be done with it, without having
to worry about any specific Blockchain explorer or provide a means for the
user to select one.

Blockchain explorers in turn will simply offer to handle the blockchain:
URI, the first time the user visit their website, or launch/install the
application, or even set themselves if there isn't already one.

Users get the convenience of using always their preferred explorer, which
can be especially handy on mobile devices, where juggling with cut&paste
is far from ideal.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Variable Block Size Proposal

[Jameson Lopp via bitcoin-dev]

I don't think you'll find much support for introducing a mandatory minimum
block size. It's quite wasteful to "pad" blocks with transactions that the
miner is just sending back to themself. If you want to solve the block
propagation issue, I'd recommend instead working on O(1) block propagation.

The Bitcoin Relay Network already allows miners to relay blocks much
faster: http://bitcoinrelaynetwork.org/

The next step would be getting O(1) block propagation into the Bitcoin
protocol. Check out Gavin's proposal:
https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2

- Jameson

On Sat, Aug 29, 2015 at 1:41 AM, Justin M. Wray via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hey Bitcoiners!
>
> While I am an avid Bitcoin supporter, long-term user, and have done
> development work on tools and platforms surrounding Bitcoin, I have
> been very busy these past few weeks and haven't had a chance to fully
> (or closely) monitor the Block Size debate.
>
> I'm familiar with the basics, and have read abstracts about the
> front-running proposals (BIP 100, 101, and 102). Though I've honestly
> not read those in depth either. With that said, I was driving
> the other day and thought of a potential idea. I'll be clear, this is
> just an idea, and I haven't fully fleshed it out. But I thought I'd
> throw it out there and see what people thought.
>
> My Goal:
>
> Provide a variable block size that provides for sustainable, long-term
> growth, and balances the block propagation, while also being mindful
> of potential spam attacks.
>
> The Proposal:
>
> Every 2016 blocks (approximately every two weeks, at the same time the
> difficulty is adjusted), the new block size parameters are calculated.
>
> The calculation determines the average (mean) size of the past 2016
> blocks. This "average" size is then doubled (200%) and used as the
> maximum block size for the subsequent 2016 blocks. At any point, if
> the new maximum size is calculated to be below 1MB, 1MB is used
> instead (which prevents regression from our current state).
>
> Introduce a block minimum, the minimum will be 25% of the current
> maximum, calculated at the same time (that is, every 2016 blocks, at
> the same time the maximum is calculated). All blocks must be at least
> this size in order to be valid, for blocks that do not have enough
> transactions to meet the 25%, padding will be used. This devalues the
> incentive to mine empty blocks in either an attempt to deflate the
> block size, or to obtain a propagation advantage. Miners will be
> incentivized to include transactions, as the block must meet the
> minimum. This should ensure that even miners wishing to always mine
> the minimum are still confirming Bitcoin transactions.
>
> At the block in which this is introduced the maximum would stay at 1MB
> for the subsequent 2016 blocks. With the minimum being enforced of 256KB
> .
>
> Example:
>
> * Average Block Size for the last 2016 blocks: 724KB
> * New Maximum: 1448KB
> * New Minimum: 362KB
>
> Example: (Regression Prevention)
>
> * Average Block Size for the last 2016 blocks: 250KB
> * New Maximum: 1MB
> * New Minimum: 256KB
>
> The Future:
>
> I believe that the 1MB regression prevention might need to be changed
> in the future, to prevent a large mining population from continually
> deflating the block size (and keeping us at the 1MB limit).
>
> For this, the hard limit could be changed in the future manually,
> through a process similar to the current one, though hopefully with
> far less urgency and hysteria.
>
> Another option is to add an additional calculation, preventing the new
> maximum from being lower than 75% of the current maximum. This would
> substantially slow down a block-size deflation attack.
>
>  Example of Block-Size Deflation Attack Prevention:
>
>  * Average Block Size for the last 2016 blocks:  4MB
>  * New Maximum:  8MB
>  * New Minimum:  2MB
>
>  * Average Block Size for the last 2016 blocks:  2MB
>  * New Maximum:  6MB  (2 * 200% = 4, 4< 75% of 8, So use 8 * .75 = 6)
>  * New Minimum:  1.5MB
>
> This would provide a maximum growth of 200% per recalculation, but a
> maximum shrinkage of 75%.
>
> Request For Comments:
>
> I'd love to hear your thoughts. Why wouldn't this work? What portion
> is flawed? Will the miners support such a proposal? Would this even
> solve the block size issue?
>
> I will note that I don't find the 100% and 25% to be hard and fast in
> my idea. Those we're just the values that initially jumped out at me.
> I could easily see the minimum being anything below 50% (above 50% and
> the network can never adjust to smaller block sizes). I could also see
> the maximum being anything over 100%.  Lastly, if a inflation attack
> is a valid concern, a hard upper limit could be set (or the historical
> 32MB limit could remain).
>
> I think the great part about this variable approach is that the
> network can ad

Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration

[Richard Moore via bitcoin-dev]

I like the idea of having a standard for this, that all explorers (and even 
core, eventually) would understand.

I would recommend 2 changes though. First, using a real URI scheme, 
blockchain:// so that we can just use normal URL parsing libraries. The 
bitcoin: thing leads to additional code to mutate it into a proper URI before 
passing it to URL parsing. And I think it would be fine to include the type 
looking up. For example:

blockchain://blockhash/1003e880d500968d51157f210c632e08a652af3576600198
blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
blockchain://block/189000
blockchain://address/1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn

I think this would help the URI be more human understandable as well as give 
the explorers the ability to optimize a bit what they are looking for when 
hitting various databases.

A possible future path could also include blockchain://tx/123000/4 for block 
height, tx index... Another possibility could be blockchain://version which 
would return a list of supported paths, version of the BIP supported, etc.

The BIP should also specify little endian searching. I'm not sure, but would it 
also make sense for this BIP to include what the return results should look 
like? Maybe another, related BIP.

RicMoo

Sent from my self-aware iPhone

.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>

Richard Moore ~ Founder
Genetic Mistakes Software Inc.
phone: (778) 882-6125
email: ric...@geneticmistakes.com
www: http://GeneticMistakes.com

> On Aug 29, 2015, at 7:48 AM, Marco Pontello via bitcoin-dev 
>  wrote:
> 
> Hi!
> My first post here, hope I'm following the right conventions.
> I had this humble idea for a while, so I thought to go ahead and propose
> it.
> 
> BIP: XX
> Title: URI scheme for Blockchain exploration
> Author: Marco Pontello
> Status: Draft
> Type: Standards Track
> Created: 29 August 2015
> 
> Abstract
> 
> This BIP propose a simple URI scheme for looking up blocks, transactions,
> addresses on a Blockchain explorer.
> 
> Motivation
> ==
> The purpose of this URI scheme is to enable users to handle all the
> requests for details about blocks, transactions, etc. with their preferred
> tool (being that a web service or a local application).
> 
> Currently a Bitcoin client usually point to an arbitrary blockchain
> explorer when the user look for the details of a transaction (es. Bitcoin
> Wallet use BitEasy, Mycelium or Electrum use Blockchain.info, etc.).
> Other times resorting to cut&paste is needed.
> The same happens with posts and messages that reference some particular
> txs or blocks, if they provide links at all.
> 
> Specification
> =
> The URI follow this simple form:
> 
> blockchain:   
> 
> Examples:
> 
> blockchain:1003e880d500968d51157f210c632e08a652af3576600198
> blockchain:001949
> blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> 
> Rationale
> =
> I thought about using some more complex scheme, or adding qualifiers to
> distinguish blocks from txs, but in the end I think that keeping it simple
> should be practical enough. Blockchain explorers can apply the same
> disambiguation rules they are already using to process the usual search
> box. 
> 
> From the point of view of a wallet developer (or other tool that need to
> show any kind of Blockchain references), using this scheme mean that he
> can simply make it a blockchain: link and be done with it, without having
> to worry about any specific Blockchain explorer or provide a means for the
> user to select one.
> 
> Blockchain explorers in turn will simply offer to handle the blockchain:
> URI, the first time the user visit their website, or launch/install the
> application, or even set themselves if there isn't already one.
> 
> Users get the convenience of using always their preferred explorer, which
> can be especially handy on mobile devices, where juggling with cut&paste
> is far from ideal.
> 
> 
> ___
> 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

[bitcoin-dev] On the Nature of Miner Advantages in Uncapped Block Size Fee Markets

[Daniele Pinna via bitcoin-dev]

I'd like to submit this paper to the dev-list which analyzes how miner
advantages scale with network and mempool properties in a scenario of
uncapped block sizes. The work proceeds, in a sense, from where Peter R's
work left off correcting a mistake and addressing the critiques made by the
community to his work.

The main result of the work is a detailed analysis of mining advantages
(defined as the added profit per unit of hash) as a function of miner
hashrate. In it, I show how large block subsidies (or better, low mempool
fees-to-subsidy ratios) incentivize the pooling of large hashrates due to
the steady increasing of marginal profits as hashrates grow.

The paper also shows that part of the large advantage the large miners have
today is due to there being a barrier to entry into a high-efficiency
mining class which has access to expected profits an order of magnitude
larger than everyone else. As block subsidies decrease, this
high-efficiency class is expected to vanish leading to a marginal profit
structure which decreases as a function of hashrate.

This work has vacuumed my entire life for the past two weeks leading me to
lag behind on a lot of work. I apologize for typos which I may not have
seen. I stand by for any comments the community may have and look forward
to reigniting consideration of a block size scaling proposal (BIP101)
which, due to the XT fork drama, I believe has been placed hastily and
undeservedly on the chopping block.

https://www.scribd.com/doc/276849939/On-the-Nature-of-Miner-Advantages-in-Uncapped-Block-Size-Fee-Markets

Regards,
Daniele
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration

[Matt Whitlock via bitcoin-dev]

bitcoin:12345 *is* a "real" URI. It's just not an absolute, hierarchical URI 
(a.k.a. a URL); rather, it's an opaque URI.

And your suggestion is actually in violation of the URI spec, since 
"blockhash", "txid", "block", and "address" are not host names.

More correct would be:

blockchain:?blockhash=1003e880d500968d51157f210c632e08a652af3576600198
blockchain:?txid=3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
blockchain:?block=189000
blockchain:?address=1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn

You should read the URI syntax RFC: https://tools.ietf.org/html/rfc3986


On Saturday, 29 August 2015, at 12:31 pm, Richard Moore via bitcoin-dev wrote:
> I like the idea of having a standard for this, that all explorers (and even 
> core, eventually) would understand.
> 
> I would recommend 2 changes though. First, using a real URI scheme, 
> blockchain:// so that we can just use normal URL parsing libraries. The 
> bitcoin: thing leads to additional code to mutate it into a proper URI before 
> passing it to URL parsing. And I think it would be fine to include the type 
> looking up. For example:
> 
> blockchain://blockhash/1003e880d500968d51157f210c632e08a652af3576600198
> blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> blockchain://block/189000
> blockchain://address/1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn
> 
> I think this would help the URI be more human understandable as well as give 
> the explorers the ability to optimize a bit what they are looking for when 
> hitting various databases.
> 
> A possible future path could also include blockchain://tx/123000/4 for block 
> height, tx index... Another possibility could be blockchain://version which 
> would return a list of supported paths, version of the BIP supported, etc.
> 
> The BIP should also specify little endian searching. I'm not sure, but would 
> it also make sense for this BIP to include what the return results should 
> look like? Maybe another, related BIP.
> 
> > On Aug 29, 2015, at 7:48 AM, Marco Pontello via bitcoin-dev 
> >  wrote:
> > 
> > Hi!
> > My first post here, hope I'm following the right conventions.
> > I had this humble idea for a while, so I thought to go ahead and propose
> > it.
> > 
> > BIP: XX
> > Title: URI scheme for Blockchain exploration
> > Author: Marco Pontello
> > Status: Draft
> > Type: Standards Track
> > Created: 29 August 2015
> > 
> > Abstract
> > 
> > This BIP propose a simple URI scheme for looking up blocks, transactions,
> > addresses on a Blockchain explorer.
> > 
> > Motivation
> > ==
> > The purpose of this URI scheme is to enable users to handle all the
> > requests for details about blocks, transactions, etc. with their preferred
> > tool (being that a web service or a local application).
> > 
> > Currently a Bitcoin client usually point to an arbitrary blockchain
> > explorer when the user look for the details of a transaction (es. Bitcoin
> > Wallet use BitEasy, Mycelium or Electrum use Blockchain.info, etc.).
> > Other times resorting to cut&paste is needed.
> > The same happens with posts and messages that reference some particular
> > txs or blocks, if they provide links at all.
> > 
> > Specification
> > =
> > The URI follow this simple form:
> > 
> > blockchain:   
> > 
> > Examples:
> > 
> > blockchain:1003e880d500968d51157f210c632e08a652af3576600198
> > blockchain:001949
> > blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> > 
> > Rationale
> > =
> > I thought about using some more complex scheme, or adding qualifiers to
> > distinguish blocks from txs, but in the end I think that keeping it simple
> > should be practical enough. Blockchain explorers can apply the same
> > disambiguation rules they are already using to process the usual search
> > box. 
> > 
> > From the point of view of a wallet developer (or other tool that need to
> > show any kind of Blockchain references), using this scheme mean that he
> > can simply make it a blockchain: link and be done with it, without having
> > to worry about any specific Blockchain explorer or provide a means for the
> > user to select one.
> > 
> > Blockchain explorers in turn will simply offer to handle the blockchain:
> > URI, the first time the user visit their website, or launch/install the
> > application, or even set themselves if there isn't already one.
> > 
> > Users get the convenience of using always their preferred explorer, which
> > can be especially handy on mobile devices, where juggling with cut&paste
> > is far from ideal.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] On the Nature of Miner Advantages in Uncapped Block Size Fee Markets

[Jorge Timón via bitcoin-dev]

On Aug 29, 2015 9:43 AM, "Daniele Pinna via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> This work has vacuumed my entire life for the past two weeks leading me
to lag behind on a lot of work. I apologize for typos which I may not have
seen. I stand by for any comments the community may have and look forward
to reigniting consideration of a block size scaling proposal (BIP101)
which, due to the XT fork drama, I believe has been placed hastily and
undeservedly on the chopping block.

I don't like relying on exponential growth (that's why I don't like neither
Gavin's 101 nor Pieter's 103).

But I don't think it's too late to turn bip101 into just another proposal
for an uncontroversial hardfork (changing the 75% to 95% would be the first
step) and xt into just another software fork.

My favorite one so far is bip102 (even though I still consider "2mb now"
arbitrary and I'm worried about making mining centralization even worse
than it is now), but if it was framed as a schism hardfork like bip101 I
would also warn about the dangers of a schism hardfork for it.

>
https://www.scribd.com/doc/276849939/On-the-Nature-of-Miner-Advantages-in-Uncapped-Block-Size-Fee-Markets

I'll read it to try to understand your claims. Are you presentung this in
the scaling workshop?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)

[Eric Lombrozo via bitcoin-dev]

In principle I am sympathetic to dynamic block size proposals...but in
practice it seems we're barking up the wrong tree. Without mechanisms for
incentivizing validators...and checks and balances between the interests of
regular users (who want to reduce fees and confirmation time), miners (who
want to balance hashing and propagation time costs with revenue), and
validator nodes (who currrently lack any direct incentives), I think we're
talking about significant protocol complications with potential benefits
that are hard to model at best.

On Sat, Aug 29, 2015, 3:16 AM Btc Drak via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sat, Aug 29, 2015 at 1:29 AM, Mark Friedenbach via bitcoin-dev
>  wrote:
> > Ah, then my mistake. It seemed so similar to an idea that was proposed
> > before on this mailing list:
> >
> >
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008033.html
> >
> > that my mind just filled in the gaps. I concur -- having miners -- or any
> > group -- vote on block size is not an intrinsically good thing. The the
> > original proposal due to Greg Maxwell et al was not a mechanism for
> "voting"
> > but rather a feedback control that made the maximum block size that which
> > generated the most fees.
>
> Mark and Jorge,
>
> I am very glad you have brought up this particular objection because
> it's something I thought about but was unclear if it was an opinion
> that would be shared by others. I chose to omit it from the proposal
> to see if it would come up during peer review.
>
> I feel that giving miners a blank cheque to increase blocksize, by any
> means, goes against a key design of bitcoin's security model. Full
> nodes keep miners honest by ensuring by validating their blocks. Under
> any voting-only scheme there is no way for full nodes to keep miners
> in cheque because miner have free reign to increase the blocksize.
>
> This problem can be solved by introducing a hard cap on blocksize. By
> introducing an upper limit miners now have the freedom to increase
> blocksize but only within defined parameters.  Remember my proposal
> allows blocksize to increase and decrease in such a way that miners
> must collectively agree if they want the size to increase.
>
> I believe the idea of a hard upper limit has become rather politicised
> but is essential to the security model of bitcoin.
>
> With respect to the flexicap idea where miners can create a larger
> block by paying extra difficulty, I believe that proposal has a
> critical flaw because, as Gavin pointed out, it makes it very
> expensive (and risky) to include a few extra transactions. I believe
> it suffers from tragedy of the commons because there is no incentive
> for the mining community to reach consensus. Each and every block is
> going to be a gamble, "should we include a few extra transactions at
> the risk of losing the block?". Under my proposal miners can
> collectively agree to change the blocksize. Let's say they want a 10%
> increase, they can collude together to make that increase and once
> reached, it remains until they want to change it again. Yet, the upper
> hard limit keeps the ultimate control of the maximum block size
> squarely in the hands of full nodes.
>
> Whilst the exact number may be up for discussion, I would propose an
> initial upper limit of 8MB, so under my proposal the blocksize would
> be flexible between 1MB and 8MB.
>
> An alternative methodology to voting in the coinbase would be to
> change the vote to be the blocksize itself
>
> 1. miners pay extra difficulty to create a larger block.
> 2. every 2016 blocks the average or median of the last 2016 blocks is
> calculated and becomes the new maximum blocksize limit.
>
> This would retain incentive to collude to increase blocksize, as well
> as the property of costing to increase while being free to propose
> decrease.
>
> It would still require an upper blocksize limit in order for full
> nodes to retain control. Without an upper limit, any proposal is going
> to break the security model as full nodes give up some oversight
> control over miners.
>
> Another way of looking at these ideas is we're raising blocksize hard
> limit (to 8MB or whatever is decided), but making a soft of "softer"
> or inner limit part of consensus. Such a concept is not really
> departing from the current idea of a soft limit except to make it
> consensus enforced. Obviously it's not identical, but I think you can
> see the similarities.
>
> Does that make sense?
> ___
> 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

Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration

[Andreas Schildbach via bitcoin-dev]

On 08/29/2015 06:31 PM, Richard Moore via bitcoin-dev wrote:

> I like the idea of having a standard for this, that all explorers (and
> even core, eventually) would understand.
> 
> I would recommend 2 changes though. First, using a real URI scheme,
> blockchain:// so that we can just use normal URL parsing libraries. The
> bitcoin: thing leads to additional code to mutate it into a proper URI
> before passing it to URL parsing. And I think it would be fine to
> include the type looking up. For example:
> 
> blockchain://blockhash/1003e880d500968d51157f210c632e08a652af3576600198
> blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> blockchain://block/189000
> blockchain://address/1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn

Good thinking! It might make sense to look at the existing de-facto
standard (e.g. blockexplorer.com, blockchain.info):

/tx/ for transactions
/block/ for blocks, supports both hash or height
/address/ for address


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Variable Block Size Proposal

[Justin M. Wray via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

That's fine too.  Obviously the variable maximum would work just fine
without a minimum.  In fact, with the O(1) propagation proposal, a
minimum number of transactions could be enforced, think - a percentage
of the current mempool.  That's actually far more meaningful to both
miners and consumers.

On 8/29/15 10:22 AM, Jameson Lopp wrote:
> I don't think you'll find much support for introducing a mandatory minimum 
> block size. It's quite
wasteful to "pad" blocks with transactions that the miner is just
sending back to themself. If you want to solve the block propagation
issue, I'd recommend instead working on O(1) block propagation.
>
> The Bitcoin Relay Network already allows miners to relay blocks much
faster: http://bitcoinrelaynetwork.org/
>
> The next step would be getting O(1) block propagation into the Bitcoin
protocol. Check out Gavin's proposal:
https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2
>
> - Jameson
>
> On Sat, Aug 29, 2015 at 1:41 AM, Justin M. Wray via bitcoin-dev
mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hey Bitcoiners!
>
> While I am an avid Bitcoin supporter, long-term user, and have done
> development work on tools and platforms surrounding Bitcoin, I have
> been very busy these past few weeks and haven't had a chance to fully
> (or closely) monitor the Block Size debate.
>
> I'm familiar with the basics, and have read abstracts about the
> front-running proposals (BIP 100, 101, and 102). Though I've honestly
> not read those in depth either. With that said, I was driving
> the other day and thought of a potential idea. I'll be clear, this is
> just an idea, and I haven't fully fleshed it out. But I thought I'd
> throw it out there and see what people thought.
>
> My Goal:
>
> Provide a variable block size that provides for sustainable, long-term
> growth, and balances the block propagation, while also being mindful
> of potential spam attacks.
>
> The Proposal:
>
> Every 2016 blocks (approximately every two weeks, at the same time the
> difficulty is adjusted), the new block size parameters are calculated.
>
> The calculation determines the average (mean) size of the past 2016
> blocks. This "average" size is then doubled (200%) and used as the
> maximum block size for the subsequent 2016 blocks. At any point, if
> the new maximum size is calculated to be below 1MB, 1MB is used
> instead (which prevents regression from our current state).
>
> Introduce a block minimum, the minimum will be 25% of the current
> maximum, calculated at the same time (that is, every 2016 blocks, at
> the same time the maximum is calculated). All blocks must be at least
> this size in order to be valid, for blocks that do not have enough
> transactions to meet the 25%, padding will be used. This devalues the
> incentive to mine empty blocks in either an attempt to deflate the
> block size, or to obtain a propagation advantage. Miners will be
> incentivized to include transactions, as the block must meet the
> minimum. This should ensure that even miners wishing to always mine
> the minimum are still confirming Bitcoin transactions.
>
> At the block in which this is introduced the maximum would stay at 1MB
> for the subsequent 2016 blocks. With the minimum being enforced of
256KB
> .
>
> Example:
>
> * Average Block Size for the last 2016 blocks: 724KB
> * New Maximum: 1448KB
> * New Minimum: 362KB
>
> Example: (Regression Prevention)
>
> * Average Block Size for the last 2016 blocks: 250KB
> * New Maximum: 1MB
> * New Minimum: 256KB
>
> The Future:
>
> I believe that the 1MB regression prevention might need to be changed
> in the future, to prevent a large mining population from continually
> deflating the block size (and keeping us at the 1MB limit).
>
> For this, the hard limit could be changed in the future manually,
> through a process similar to the current one, though hopefully with
> far less urgency and hysteria.
>
> Another option is to add an additional calculation, preventing the new
> maximum from being lower than 75% of the current maximum. This would
> substantially slow down a block-size deflation attack.
>
>  Example of Block-Size Deflation Attack Prevention:
>
>  * Average Block Size for the last 2016 blocks:  4MB
>  * New Maximum:  8MB
>  * New Minimum:  2MB
>
>  * Average Block Size for the last 2016 blocks:  2MB
>  * New Maximum:  6MB  (2 * 200% = 4, 4< 75% of 8, So use 8 * .75 = 6)
>  * New Minimum:  1.5MB
>
> This would provide a maximum growth of 200% per recalculation, but a
> maximum shrinkage of 75%.
>
> Request For Comments:
>
> I'd love to hear your thoughts. Wh

Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration

[Btc Drak via bitcoin-dev]

What about supporting different networks? What if I want to look up
testnet for example?

blockchain://mainnet/txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
blockchain://testnet/txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a

or

blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a?network=testnet

On Sat, Aug 29, 2015 at 5:31 PM, Richard Moore via bitcoin-dev
 wrote:
> I like the idea of having a standard for this, that all explorers (and even
> core, eventually) would understand.
>
> I would recommend 2 changes though. First, using a real URI scheme,
> blockchain:// so that we can just use normal URL parsing libraries. The
> bitcoin: thing leads to additional code to mutate it into a proper URI
> before passing it to URL parsing. And I think it would be fine to include
> the type looking up. For example:
>
> blockchain://blockhash/1003e880d500968d51157f210c632e08a652af3576600198
> blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> blockchain://block/189000
> blockchain://address/1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn
>
> I think this would help the URI be more human understandable as well as give
> the explorers the ability to optimize a bit what they are looking for when
> hitting various databases.
>
> A possible future path could also include blockchain://tx/123000/4 for block
> height, tx index... Another possibility could be blockchain://version which
> would return a list of supported paths, version of the BIP supported, etc.
>
> The BIP should also specify little endian searching. I'm not sure, but would
> it also make sense for this BIP to include what the return results should
> look like? Maybe another, related BIP.
>
> RicMoo
>
> Sent from my self-aware iPhone
>
> .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
>
> Richard Moore ~ Founder
> Genetic Mistakes Software Inc.
> phone: (778) 882-6125
> email: ric...@geneticmistakes.com
> www: http://GeneticMistakes.com
>
> On Aug 29, 2015, at 7:48 AM, Marco Pontello via bitcoin-dev
>  wrote:
>
> Hi!
> My first post here, hope I'm following the right conventions.
> I had this humble idea for a while, so I thought to go ahead and propose
> it.
>
> BIP: XX
> Title: URI scheme for Blockchain exploration
> Author: Marco Pontello
> Status: Draft
> Type: Standards Track
> Created: 29 August 2015
>
> Abstract
> 
> This BIP propose a simple URI scheme for looking up blocks, transactions,
> addresses on a Blockchain explorer.
>
> Motivation
> ==
> The purpose of this URI scheme is to enable users to handle all the
> requests for details about blocks, transactions, etc. with their preferred
> tool (being that a web service or a local application).
>
> Currently a Bitcoin client usually point to an arbitrary blockchain
> explorer when the user look for the details of a transaction (es. Bitcoin
> Wallet use BitEasy, Mycelium or Electrum use Blockchain.info, etc.).
> Other times resorting to cut&paste is needed.
> The same happens with posts and messages that reference some particular
> txs or blocks, if they provide links at all.
>
> Specification
> =
> The URI follow this simple form:
>
> blockchain: 
>
> Examples:
>
> blockchain:1003e880d500968d51157f210c632e08a652af3576600198
> blockchain:001949
> blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
>
> Rationale
> =
> I thought about using some more complex scheme, or adding qualifiers to
> distinguish blocks from txs, but in the end I think that keeping it simple
> should be practical enough. Blockchain explorers can apply the same
> disambiguation rules they are already using to process the usual search
> box.
>
> From the point of view of a wallet developer (or other tool that need to
> show any kind of Blockchain references), using this scheme mean that he
> can simply make it a blockchain: link and be done with it, without having
> to worry about any specific Blockchain explorer or provide a means for the
> user to select one.
>
> Blockchain explorers in turn will simply offer to handle the blockchain:
> URI, the first time the user visit their website, or launch/install the
> application, or even set themselves if there isn't already one.
>
> Users get the convenience of using always their preferred explorer, which
> can be especially handy on mobile devices, where juggling with cut&paste
> is far from ideal.
>
>
> ___
> 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
>
___

Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration

[Matt Whitlock via bitcoin-dev]

That's still not right, since "mainnet" and "testnet" are not host names.

You'd have to do something like:

blockchain:?network=testnet&txid=3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a


On Saturday, 29 August 2015, at 7:58 pm, Btc Drak via bitcoin-dev wrote:
> What about supporting different networks? What if I want to look up
> testnet for example?
> 
> blockchain://mainnet/txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> blockchain://testnet/txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> 
> or
> 
> blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a?network=testnet
> 
> On Sat, Aug 29, 2015 at 5:31 PM, Richard Moore via bitcoin-dev
>  wrote:
> > I like the idea of having a standard for this, that all explorers (and even
> > core, eventually) would understand.
> >
> > I would recommend 2 changes though. First, using a real URI scheme,
> > blockchain:// so that we can just use normal URL parsing libraries. The
> > bitcoin: thing leads to additional code to mutate it into a proper URI
> > before passing it to URL parsing. And I think it would be fine to include
> > the type looking up. For example:
> >
> > blockchain://blockhash/1003e880d500968d51157f210c632e08a652af3576600198
> > blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> > blockchain://block/189000
> > blockchain://address/1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn
> >
> > I think this would help the URI be more human understandable as well as give
> > the explorers the ability to optimize a bit what they are looking for when
> > hitting various databases.
> >
> > A possible future path could also include blockchain://tx/123000/4 for block
> > height, tx index... Another possibility could be blockchain://version which
> > would return a list of supported paths, version of the BIP supported, etc.
> >
> > The BIP should also specify little endian searching. I'm not sure, but would
> > it also make sense for this BIP to include what the return results should
> > look like? Maybe another, related BIP.
> >
> > RicMoo
> >
> > Sent from my self-aware iPhone
> >
> > .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
> >
> > Richard Moore ~ Founder
> > Genetic Mistakes Software Inc.
> > phone: (778) 882-6125
> > email: ric...@geneticmistakes.com
> > www: http://GeneticMistakes.com
> >
> > On Aug 29, 2015, at 7:48 AM, Marco Pontello via bitcoin-dev
> >  wrote:
> >
> > Hi!
> > My first post here, hope I'm following the right conventions.
> > I had this humble idea for a while, so I thought to go ahead and propose
> > it.
> >
> > BIP: XX
> > Title: URI scheme for Blockchain exploration
> > Author: Marco Pontello
> > Status: Draft
> > Type: Standards Track
> > Created: 29 August 2015
> >
> > Abstract
> > 
> > This BIP propose a simple URI scheme for looking up blocks, transactions,
> > addresses on a Blockchain explorer.
> >
> > Motivation
> > ==
> > The purpose of this URI scheme is to enable users to handle all the
> > requests for details about blocks, transactions, etc. with their preferred
> > tool (being that a web service or a local application).
> >
> > Currently a Bitcoin client usually point to an arbitrary blockchain
> > explorer when the user look for the details of a transaction (es. Bitcoin
> > Wallet use BitEasy, Mycelium or Electrum use Blockchain.info, etc.).
> > Other times resorting to cut&paste is needed.
> > The same happens with posts and messages that reference some particular
> > txs or blocks, if they provide links at all.
> >
> > Specification
> > =
> > The URI follow this simple form:
> >
> > blockchain: 
> >
> > Examples:
> >
> > blockchain:1003e880d500968d51157f210c632e08a652af3576600198
> > blockchain:001949
> > blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> >
> > Rationale
> > =
> > I thought about using some more complex scheme, or adding qualifiers to
> > distinguish blocks from txs, but in the end I think that keeping it simple
> > should be practical enough. Blockchain explorers can apply the same
> > disambiguation rules they are already using to process the usual search
> > box.
> >
> > From the point of view of a wallet developer (or other tool that need to
> > show any kind of Blockchain references), using this scheme mean that he
> > can simply make it a blockchain: link and be done with it, without having
> > to worry about any specific Blockchain explorer or provide a means for the
> > user to select one.
> >
> > Blockchain explorers in turn will simply offer to handle the blockchain:
> > URI, the first time the user visit their website, or launch/install the
> > application, or even set themselves if there isn't already one.
> >
> > Users get the convenience of using always their preferred explorer, which
> > ca

Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)

[jl2012 via bitcoin-dev]

I am quite skeptical about any pay-to-increase proposal because it is 
difficult to predict the game dynamics and determine the right amount of 
penalty. But anyway, here is my response to your revised proposal:


1. I agree with you that there should be a cap in the rate of change, 
and also the maximum possible size. This is already part of BIP100


2. Requiring a higher difficulty is bad for everyone:
 a) it increases the variance of the miner;
 b) average confirmation time for all tx are increased. It may even 
cause a feedback: many tx in mempool -> increase block size -> wait 
longer for confirmation -> more tx in mempool;
 c) difficulty of the next round will be decreased, leading to a greater 
fluctuation in confirmation time.


Instead, you should require miners to burn their coinbase reward. This 
is effectively same as higher difficulty but is good for everyone: a) 
mining variance and confirmation time unchanged; b) all bitcoin holders 
become relatively richer


If you don't want to burn any bitcoin, you may require the miner the 
send to penalty to <84 + current height> OP_CHECKLOCKTIMEVERIFY, 
which will subsidize the mining when the block reward drops below 1 BTC


3. It is a better idea to allow mining of a bigger block immediately, 
which reduces (but not eliminates) the problem of tragedy of the 
commons. However, you can't use the blocksize as the vote. Mining an 
empty block doesn't mean the miner wants to decrease the block size to 
200 bytes. That will just encourage some miners to fill up a block with 
garbage which does no good for anyone. Therefore, you need to look at 
both the actual block size and the coinbase vote, and always take the 
bigger value to determine the penalty and the max block size of next 
round. If a miner includes nothing in the coinbase, it should be 
consider as a vote for the current max block size.




Btc Drak via bitcoin-dev 於 2015-08-29 06:15 寫到:

On Sat, Aug 29, 2015 at 1:29 AM, Mark Friedenbach via bitcoin-dev
 wrote:

Mark and Jorge,

I am very glad you have brought up this particular objection because
it's something I thought about but was unclear if it was an opinion
that would be shared by others. I chose to omit it from the proposal
to see if it would come up during peer review.

I feel that giving miners a blank cheque to increase blocksize, by any
means, goes against a key design of bitcoin's security model. Full
nodes keep miners honest by ensuring by validating their blocks. Under
any voting-only scheme there is no way for full nodes to keep miners
in cheque because miner have free reign to increase the blocksize.

This problem can be solved by introducing a hard cap on blocksize. By
introducing an upper limit miners now have the freedom to increase
blocksize but only within defined parameters.  Remember my proposal
allows blocksize to increase and decrease in such a way that miners
must collectively agree if they want the size to increase.

I believe the idea of a hard upper limit has become rather politicised
but is essential to the security model of bitcoin.

With respect to the flexicap idea where miners can create a larger
block by paying extra difficulty, I believe that proposal has a
critical flaw because, as Gavin pointed out, it makes it very
expensive (and risky) to include a few extra transactions. I believe
it suffers from tragedy of the commons because there is no incentive
for the mining community to reach consensus. Each and every block is
going to be a gamble, "should we include a few extra transactions at
the risk of losing the block?". Under my proposal miners can
collectively agree to change the blocksize. Let's say they want a 10%
increase, they can collude together to make that increase and once
reached, it remains until they want to change it again. Yet, the upper
hard limit keeps the ultimate control of the maximum block size
squarely in the hands of full nodes.

Whilst the exact number may be up for discussion, I would propose an
initial upper limit of 8MB, so under my proposal the blocksize would
be flexible between 1MB and 8MB.

An alternative methodology to voting in the coinbase would be to
change the vote to be the blocksize itself

1. miners pay extra difficulty to create a larger block.
2. every 2016 blocks the average or median of the last 2016 blocks is
calculated and becomes the new maximum blocksize limit.

This would retain incentive to collude to increase blocksize, as well
as the property of costing to increase while being free to propose
decrease.

It would still require an upper blocksize limit in order for full
nodes to retain control. Without an upper limit, any proposal is going
to break the security model as full nodes give up some oversight
control over miners.

Another way of looking at these ideas is we're raising blocksize hard
limit (to 8MB or whatever is decided), but making a soft of "softer"
or inner limit part of consensus. Such a concept is not really
departing from the current idea of

Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)

[Natanael via bitcoin-dev]

My current idea:

* There's a scheduled hardcap that goes up over time.

* Miners vote on the blocksize limit within the hardcap, choosing the new
votecap. No particular idea for scheduling change. The 2016 block period
seems a bit long though, in case of sudden peak load.
(I'd suggest rolling vote over X blocks, enacted Y blocks later (with votes
counted from block A to block B = block A+X, the change is enacted at block
C = B+Y = A+X+Y). I'm fine with fixed-period schedules too if they span a
reasonable time, such as IMHO 2 days - we need rapid peak adjustment. No
suggestion on vote result calculation mechanism.)

* Casting votes are free.

* The mean (average) blocksize over the last time period X is calculated
for every block, or at the end of every fixed-length period (depending on
what scheduling is used for votes).

* Creating blocks larger than the mean but below the votecap raises the
difficulty target for the miner (and slightly raises the mean for future
blocks).

* The degree of difficulty raise depends on where between the mean and
votecap that the size of the given block is (and it follows that lots of
votes for large raise reduces per-extra-Kb penalty, allowing for cheaper
peak load adjustment if a large miner majority agrees). The degree of
increase may be either linear or logarithmic, I've got no suggestion
currently on any particular metric.
(Some might think this is an easy way for miners to collude to make large
blocks cheaper. If so, you could commit to only pay fee to miners that
don't vote for a block size above the size you accept, as a
counter-incentive.)

* Question: When the votecap is lowered, should the calculated mean be
forced down to follow (forcing a penalty for making blocks close to the
votecap straight after the change)? If so, how? Or should it be allowed to
fall naturally as new blocks with size below the votecap are created?

This is how miners would pay for actually creating larger blocks, and
leaves us with three methods of keeping the size in check (hardcap, votecap
and softcap). The softcap mechanism is then our third check to use if
deemed necessary (orphaning valid blocks if considered problematically
large). This third option do not need coordination with miners, they just
need to be aware which block size is accepted by the community.

I can't think of any sensible non-miner mechanism of deciding max block
size outside of using a community coordinated softcap, anything else will
not work reliably. Too hard to measure objectively and judge fairly.

The community would thus agree on a hardcap schedule in advance, and have
the option to threaten orphaning blocks via softfork later on if
circumstances would change and the votecap is too large.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration

[Richard Moore via bitcoin-dev]

I apologize, you are correct, I should not have used the word "real". 

However, if you look at section 3 of the RFC, the first hierarchal level (which 
in http is used to describe hosts) can be any "authority", not necessarily a 
hostname.

So, you could use tx, block, address, etc. as the authority for their paths.

RicMoo

Sent from my self-aware iPhone

.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>

Richard Moore ~ Founder
Genetic Mistakes Software Inc.
phone: (778) 882-6125
email: ric...@geneticmistakes.com
www: http://GeneticMistakes.com

> On Aug 29, 2015, at 1:19 PM, Matt Whitlock  wrote:
> 
> bitcoin:12345 *is* a "real" URI. It's just not an absolute, hierarchical URI 
> (a.k.a. a URL); rather, it's an opaque URI.
> 
> And your suggestion is actually in violation of the URI spec, since 
> "blockhash", "txid", "block", and "address" are not host names.
> 
> More correct would be:
> 
> blockchain:?blockhash=1003e880d500968d51157f210c632e08a652af3576600198
> blockchain:?txid=3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> blockchain:?block=189000
> blockchain:?address=1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn
> 
> You should read the URI syntax RFC: https://tools.ietf.org/html/rfc3986
> 
> 
>> On Saturday, 29 August 2015, at 12:31 pm, Richard Moore via bitcoin-dev 
>> wrote:
>> I like the idea of having a standard for this, that all explorers (and even 
>> core, eventually) would understand.
>> 
>> I would recommend 2 changes though. First, using a real URI scheme, 
>> blockchain:// so that we can just use normal URL parsing libraries. The 
>> bitcoin: thing leads to additional code to mutate it into a proper URI 
>> before passing it to URL parsing. And I think it would be fine to include 
>> the type looking up. For example:
>> 
>> blockchain://blockhash/1003e880d500968d51157f210c632e08a652af3576600198
>> blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
>> blockchain://block/189000
>> blockchain://address/1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn
>> 
>> I think this would help the URI be more human understandable as well as give 
>> the explorers the ability to optimize a bit what they are looking for when 
>> hitting various databases.
>> 
>> A possible future path could also include blockchain://tx/123000/4 for block 
>> height, tx index... Another possibility could be blockchain://version which 
>> would return a list of supported paths, version of the BIP supported, etc.
>> 
>> The BIP should also specify little endian searching. I'm not sure, but would 
>> it also make sense for this BIP to include what the return results should 
>> look like? Maybe another, related BIP.
>> 
>>> On Aug 29, 2015, at 7:48 AM, Marco Pontello via bitcoin-dev 
>>>  wrote:
>>> 
>>> Hi!
>>> My first post here, hope I'm following the right conventions.
>>> I had this humble idea for a while, so I thought to go ahead and propose
>>> it.
>>> 
>>> BIP: XX
>>> Title: URI scheme for Blockchain exploration
>>> Author: Marco Pontello
>>> Status: Draft
>>> Type: Standards Track
>>> Created: 29 August 2015
>>> 
>>> Abstract
>>> 
>>> This BIP propose a simple URI scheme for looking up blocks, transactions,
>>> addresses on a Blockchain explorer.
>>> 
>>> Motivation
>>> ==
>>> The purpose of this URI scheme is to enable users to handle all the
>>> requests for details about blocks, transactions, etc. with their preferred
>>> tool (being that a web service or a local application).
>>> 
>>> Currently a Bitcoin client usually point to an arbitrary blockchain
>>> explorer when the user look for the details of a transaction (es. Bitcoin
>>> Wallet use BitEasy, Mycelium or Electrum use Blockchain.info, etc.).
>>> Other times resorting to cut&paste is needed.
>>> The same happens with posts and messages that reference some particular
>>> txs or blocks, if they provide links at all.
>>> 
>>> Specification
>>> =
>>> The URI follow this simple form:
>>> 
>>> blockchain:   
>>> 
>>> Examples:
>>> 
>>> blockchain:1003e880d500968d51157f210c632e08a652af3576600198
>>> blockchain:001949
>>> blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
>>> 
>>> Rationale
>>> =
>>> I thought about using some more complex scheme, or adding qualifiers to
>>> distinguish blocks from txs, but in the end I think that keeping it simple
>>> should be practical enough. Blockchain explorers can apply the same
>>> disambiguation rules they are already using to process the usual search
>>> box. 
>>> 
>>> From the point of view of a wallet developer (or other tool that need to
>>> show any kind of Blockchain references), using this scheme mean that he
>>> can simply make it a blockchain: link and be done with it, without having
>>> to worry about any specific Blockchain explorer or provide a means for the
>>> user to select one.
>>> 
>>> Blockchain explorers in turn will simply offer to handle the blockchain:
>>> URI, t

Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration

[Richard Moore via bitcoin-dev]

Yes! Good point, network should be encoded. Not sure I like this format yet, 
but what if it was part of the authority, like block:testnet. Like http uses 
port 80 by default, you could have block by default refer to block:mainnet.

Eg.
blockchain://tx:testnet3/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a

I will read the RFC over more thoroughly tomorrow to get an idea of what types 
of things make more or less sense.

RicMoo

Sent from my self-aware iPhone

.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>

Richard Moore ~ Founder
Genetic Mistakes Software Inc.
phone: (778) 882-6125
email: ric...@geneticmistakes.com
www: http://GeneticMistakes.com

> On Aug 29, 2015, at 2:58 PM, Btc Drak  wrote:
> 
> What about supporting different networks? What if I want to look up
> testnet for example?
> 
> blockchain://mainnet/txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> blockchain://testnet/txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> 
> or
> 
> blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a?network=testnet
> 
> On Sat, Aug 29, 2015 at 5:31 PM, Richard Moore via bitcoin-dev
>  wrote:
>> I like the idea of having a standard for this, that all explorers (and even
>> core, eventually) would understand.
>> 
>> I would recommend 2 changes though. First, using a real URI scheme,
>> blockchain:// so that we can just use normal URL parsing libraries. The
>> bitcoin: thing leads to additional code to mutate it into a proper URI
>> before passing it to URL parsing. And I think it would be fine to include
>> the type looking up. For example:
>> 
>> blockchain://blockhash/1003e880d500968d51157f210c632e08a652af3576600198
>> blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
>> blockchain://block/189000
>> blockchain://address/1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn
>> 
>> I think this would help the URI be more human understandable as well as give
>> the explorers the ability to optimize a bit what they are looking for when
>> hitting various databases.
>> 
>> A possible future path could also include blockchain://tx/123000/4 for block
>> height, tx index... Another possibility could be blockchain://version which
>> would return a list of supported paths, version of the BIP supported, etc.
>> 
>> The BIP should also specify little endian searching. I'm not sure, but would
>> it also make sense for this BIP to include what the return results should
>> look like? Maybe another, related BIP.
>> 
>> RicMoo
>> 
>> Sent from my self-aware iPhone
>> 
>> .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
>> 
>> Richard Moore ~ Founder
>> Genetic Mistakes Software Inc.
>> phone: (778) 882-6125
>> email: ric...@geneticmistakes.com
>> www: http://GeneticMistakes.com
>> 
>> On Aug 29, 2015, at 7:48 AM, Marco Pontello via bitcoin-dev
>>  wrote:
>> 
>> Hi!
>> My first post here, hope I'm following the right conventions.
>> I had this humble idea for a while, so I thought to go ahead and propose
>> it.
>> 
>> BIP: XX
>> Title: URI scheme for Blockchain exploration
>> Author: Marco Pontello
>> Status: Draft
>> Type: Standards Track
>> Created: 29 August 2015
>> 
>> Abstract
>> 
>> This BIP propose a simple URI scheme for looking up blocks, transactions,
>> addresses on a Blockchain explorer.
>> 
>> Motivation
>> ==
>> The purpose of this URI scheme is to enable users to handle all the
>> requests for details about blocks, transactions, etc. with their preferred
>> tool (being that a web service or a local application).
>> 
>> Currently a Bitcoin client usually point to an arbitrary blockchain
>> explorer when the user look for the details of a transaction (es. Bitcoin
>> Wallet use BitEasy, Mycelium or Electrum use Blockchain.info, etc.).
>> Other times resorting to cut&paste is needed.
>> The same happens with posts and messages that reference some particular
>> txs or blocks, if they provide links at all.
>> 
>> Specification
>> =
>> The URI follow this simple form:
>> 
>> blockchain: 
>> 
>> Examples:
>> 
>> blockchain:1003e880d500968d51157f210c632e08a652af3576600198
>> blockchain:001949
>> blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
>> 
>> Rationale
>> =
>> I thought about using some more complex scheme, or adding qualifiers to
>> distinguish blocks from txs, but in the end I think that keeping it simple
>> should be practical enough. Blockchain explorers can apply the same
>> disambiguation rules they are already using to process the usual search
>> box.
>> 
>> From the point of view of a wallet developer (or other tool that need to
>> show any kind of Blockchain references), using this scheme mean that he
>> can simply make it a blockchain: link and be done with it, without having
>> to worry about any specific Blockcha

Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration

[Jorge Timón via bitcoin-dev]

On Sat, Aug 29, 2015 at 9:01 PM, Matt Whitlock via bitcoin-dev
 wrote:
> That's still not right, since "mainnet" and "testnet" are not host names.
>
> You'd have to do something like:
>
> blockchain:?network=testnet&txid=3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a

I would really prefer chain= over network=
By chainID I mean the hash of the genesis block, see
https://github.com/jtimon/bitcoin/commit/3191d5e8e75687a27cf466b7a4c70bdc04809d39
I'm completely fine with doing that using an optional parameter (for
backwards compatibility).

I agree with Andreas Schildbach that respecting the most commonly used
schemes is desirable.
So my preference would be:

/tx/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a?chain=0933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943

(a tx in testnet)

/block/0b0d504d142ac8bdd1a2721d19f423a8146d0d6de882167b?chain=0019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f

(a block in bitcoin's mainnet)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)

[Jorge Timón via bitcoin-dev]

On Sat, Aug 29, 2015 at 12:15 PM, Btc Drak  wrote:
> On Sat, Aug 29, 2015 at 1:29 AM, Mark Friedenbach via bitcoin-dev
>  wrote:
>> Ah, then my mistake. It seemed so similar to an idea that was proposed
>> before on this mailing list:
>>
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008033.html
>>
>> that my mind just filled in the gaps. I concur -- having miners -- or any
>> group -- vote on block size is not an intrinsically good thing. The the
>> original proposal due to Greg Maxwell et al was not a mechanism for "voting"
>> but rather a feedback control that made the maximum block size that which
>> generated the most fees.
>
> Mark and Jorge,
>
> I am very glad you have brought up this particular objection because
> it's something I thought about but was unclear if it was an opinion
> that would be shared by others. I chose to omit it from the proposal
> to see if it would come up during peer review.
>
> I feel that giving miners a blank cheque to increase blocksize, by any
> means, goes against a key design of bitcoin's security model. Full
> nodes keep miners honest by ensuring by validating their blocks. Under
> any voting-only scheme there is no way for full nodes to keep miners
> in cheque because miner have free reign to increase the blocksize.
>
> This problem can be solved by introducing a hard cap on blocksize. By
> introducing an upper limit miners now have the freedom to increase
> blocksize but only within defined parameters.  Remember my proposal
> allows blocksize to increase and decrease in such a way that miners
> must collectively agree if they want the size to increase.

Then I only care about the hard cap (for example, to me bip100 is
practically equivalent to just raise the limit to 32 MB directly).
Miners can always produce smaller blocks by modifying their local policy.
So if we need a maximum that cannot be altered by miners anyway, why
take the additional complexity of miners voting on a lower and
changing maximum size?

> With respect to the flexicap idea where miners can create a larger
> block by paying extra difficulty, I believe that proposal has a
> critical flaw because, as Gavin pointed out, it makes it very
> expensive (and risky) to include a few extra transactions. I believe
> it suffers from tragedy of the commons because there is no incentive
> for the mining community to reach consensus. Each and every block is
> going to be a gamble, "should we include a few extra transactions at
> the risk of losing the block?".

How expensive it is depends on the concrete function f(extra_nBits) =
extra_size_allowed
But the goal of that proposal is not to raise the size maximum
permanently, but rather temporarily allow bigger blocks when there are
spikes in demand (ie many fees to collect in unconfirmed
transactions).
Yes miners will ask that question to themselves, and the answer will
depend on the concrete function and on the fees of those extra
transactions.
The miner paying for the costs will get the gains: no tragedy of the
commons here.

> Under my proposal miners can
> collectively agree to change the blocksize. Let's say they want a 10%
> increase, they can collude together to make that increase and once
> reached, it remains until they want to change it again. Yet, the upper
> hard limit keeps the ultimate control of the maximum block size
> squarely in the hands of full nodes.

I believe the tragedy of the commons actually happens with your
proposal. Why would I pay alone for something that benefits all
miners?

> An alternative methodology to voting in the coinbase would be to
> change the vote to be the blocksize itself
>
> 1. miners pay extra difficulty to create a larger block.
> 2. every 2016 blocks the average or median of the last 2016 blocks is
> calculated and becomes the new maximum blocksize limit.
>
> This would retain incentive to collude to increase blocksize, as well
> as the property of costing to increase while being free to propose
> decrease.

This seems to solve the tragedy of the commons problem with your
current proposal.
It would be like flexcap but instead of the change in size being
temporary, it affects the next maximum size permanently.
One thing to worry about is miners filling blocks with
pay-to-themselves garbage to avoid reducing the size when they don't
have enough attractive transactions to include (ie it may not be free
for the network for miners to vote on "maintain current size").

> It would still require an upper blocksize limit in order for full
> nodes to retain control. Without an upper limit, any proposal is going
> to break the security model as full nodes give up some oversight
> control over miners.
>
> Another way of looking at these ideas is we're raising blocksize hard
> limit (to 8MB or whatever is decided), but making a soft of "softer"
> or inner limit part of consensus. Such a concept is not really
> departing from the current idea of a soft limit except to make it
> consensus enforced. Obviously

Re: [bitcoin-dev] Variable Block Size Proposal

[Jorge Timón via bitcoin-dev]

On Sat, Aug 29, 2015 at 4:22 PM, Jameson Lopp via bitcoin-dev
 wrote:
> I don't think you'll find much support for introducing a mandatory minimum
> block size. It's quite wasteful to "pad" blocks with transactions that the
> miner is just sending back to themself. If you want to solve the block
> propagation issue, I'd recommend instead working on O(1) block propagation.

O(1) propagation can never be achieved without a centralized topology.
No matter how efficient of an IBLT (or similar) we implement, O(1) can
only be achieved for transmitting a block between 2 nodes. The
propagation time of a block across the whole network (or even to the
miner's sub-network) will always depend on the concrete network
topology.

That's not to say that transmitting a block between to peers in
constant time wouldn't greatly help with mining centralization
concerns related the maximum block size, but I'm concerned about this
incorrect "O(1) block propagation" meme keeps spreading.
Even with ansibles [1] and safe zk-SNARKS [2] for constant time block
validation (somehow removing the trusted setup), both of which are
science fiction right now you need to verify the snark proof for every
node receiving and relaying the block.
At that point block propagation would be meaningless as a
miner-centralization concern for not raising the maximum block size
though: the minimum CPU costs for being able to mine profitably would
be the next concern or "bottleneck".

I completely agree with the minimum block size being inappropriate
though. I don't even believe that the stated goals of the size minimum
can be accomplished with it.

[1] https://en.wikipedia.org/wiki/Ansible
[2] https://eprint.iacr.org/2013/879.pdf
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] On the Nature of Miner Advantages in Uncapped Block Size Fee Markets

[Matt Corallo via bitcoin-dev]

I believe it was pointed out previously in the discussion of the Peter R
paper, but I'll repeat it here so that its visible - this seems to
ignore the effects of transaction validation caches and block
compression protocols. Many large miners already have their own network
to relay blocks around the globe with only a few bytes on the wire at
block-time, and there is also the bitcoinrelaynetwork.org network, which
does the same for smaller miners, albeit with slightly less efficiency.
Also, transaction validation time upon receiving a block can be rather
easily made negligible (ie the only validation time you should have is
the DB modify-utxo-set time). Thus, the increased orphan risk for
including a transaction can be reduced to a very, very tiny amount,
making the optimal blocksize, essentially, including everything that
you're confident is in the mempool of other reasonably large miners.

Matt

On 08/29/15 16:43, Daniele Pinna via bitcoin-dev wrote:
> I'd like to submit this paper to the dev-list which analyzes how miner
> advantages scale with network and mempool properties in a scenario of
> uncapped block sizes. The work proceeds, in a sense, from where Peter
> R's work left off correcting a mistake and addressing the critiques made
> by the community to his work.
> 
> The main result of the work is a detailed analysis of mining advantages
> (defined as the added profit per unit of hash) as a function of miner
> hashrate. In it, I show how large block subsidies (or better, low
> mempool fees-to-subsidy ratios) incentivize the pooling of large
> hashrates due to the steady increasing of marginal profits as hashrates
> grow. 
> 
> The paper also shows that part of the large advantage the large miners
> have today is due to there being a barrier to entry into a
> high-efficiency mining class which has access to expected profits an
> order of magnitude larger than everyone else. As block subsidies
> decrease, this high-efficiency class is expected to vanish leading to a
> marginal profit structure which decreases as a function of hashrate.
> 
> This work has vacuumed my entire life for the past two weeks leading me
> to lag behind on a lot of work. I apologize for typos which I may not
> have seen. I stand by for any comments the community may have and look
> forward to reigniting consideration of a block size scaling proposal
> (BIP101) which, due to the XT fork drama, I believe has been placed
> hastily and undeservedly on the chopping block.
> 
> https://www.scribd.com/doc/276849939/On-the-Nature-of-Miner-Advantages-in-Uncapped-Block-Size-Fee-Markets
> 
> 
> Regards,
> Daniele
> 
> 
> ___
> 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

Re: [bitcoin-dev] [Bitcoin-development] [BIP draft] Motivation and deployment of consensus rules changes ([soft/hard]forks)

[Jorge Timón via bitcoin-dev]

On Wed, Aug 26, 2015 at 1:20 AM, Andy Chase via bitcoin-dev
 wrote:
> As I understand Github is not to be used for the high-level discussion
> of a draft BIP so I will post my thoughts here (is this specified
> somewhere? Can we specify this in BIP-0001?).

As specified in BIP001, there's an optional field to link to the
discussion on the mailing list, which in this case links to this
thread (that's why I'm replying here):

https://github.com/bitcoin/bips/pull/181/files#diff-e331b8631759a4ed6a4cfb4d10f473caR8

> -   I have some concerns about the structure and the wording of this
> proposal. I think both the structure and the internal wording can be
> slimmed down and simplified

You are probably right, but that is too vague for me to take any action.
Can you propose something more concrete as a PR to my branch?

https://github.com/jtimon/bips/tree/bip-forks

> -   I also believe the "history lessons" should be trimmed out,
> mentioned at best

Can you explain why?
I think they're helpful as examples for the explanations (even though
the concrete texts can probably improved/summarized).

> -   There's separate BIP for at least one of the code forks

I'm not sure I understand this.
What do you mean by "code forks"?
If you mean "software fork" (like libcoin or bitcoin xt
[pre-controversial-bip101]) those are completely fine and out of scope
for this BIP, since they don't require coordination by the different
users/implementations to upgrade/re-implement the consensus changes.


> -   BIP-001 specifies that BIP proposals should not be given a BIP
> number until after they have been spelled checked and approved by an
> editor. Greg Maxwell: was this followed?

I don't think the spell checking had been followed at all for this or
any other BIP, but yes, Greg assigned the number 99 (he did so
privately instead of here on this thread, which I find very annoying
because you are the second person who complains about this).

> -   What kind of proposal is this? Informational, Process or Standards
> track?
>
> -   I believe it should be Standards Track. Include the proposed
> upgrade path as a patch into core as a module that hard forks
> can use in the future. This will also give us some space to work
> through some of the complexities of forks in a definite way.
> -   Alternatively maybe we can split up this BIP into a Standards
> track and a separate Informational BIP?

That is a good question. The proposal currently says "informational |
process": 
https://github.com/bitcoin/bips/pull/181/files#diff-e331b8631759a4ed6a4cfb4d10f473caR6
But I wasn't really convinced about this so I'm happy to change it to
whatever it's more appropriate.
The contained code is an example of an uncontroversial hardfork to
create a precedent. I'm not sure I understand your proposal for a
"patch into core as a module that hard forks can use in the future".
Can you elaborate what would go in that patch?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

[Jorge Timón via bitcoin-dev]

On Sat, Aug 22, 2015 at 1:04 PM, Tamas Blummer  wrote:
> On Aug 21, 2015, at 21:46, Jorge Timón  wrote:
>
> On Thu, Aug 20, 2015 at 10:35 AM, Tamas Blummer 
> wrote:
>
> Every re-implementation, re-factoring even copy-paste introduces a risk of
> disagreement,
> but also open the chance of doing the work better, in the sense of software
> engineering.
>
>
> But you don't want something better, you want something functionally
> identical.
> You may want to watch sipa's explanation on why "the implementation is
> the specification" and the reasons to separate libconsensus:
> https://youtu.be/l3O4nh79CUU?t=764
>
>
> I do want something better, but not for the focus you have.
>
> Not because what you produce was not high quality, but because quality is
> achieved at a very
> high cost and is hard to uphold over generations of developer. You focus on
> a single use case
> while there are many out there for distributed ledgers.
>
> I think in an infrastructure for enterprise applications, building consensus
> on the ledger is a
> cornerstone there, but is only a piece of the solution. I built several
> commercially successful
> deployments where I delegated the consensus building to a border router, a
> Bitcoin Core,
> then interfaced that trusted peer with my  implementation that accepted
> Core’s decisions
> in an SPV manner. One might think of this setup as wasteful and unsuitable
> for “small devices”
> therefore an example of centralization people here try to avoid.
>
> Enterprises have sufficient resources. Solving the business problem is
> valuable to them even at
> magnitudes higher cost than a hobbyist would bear.
>
> For mainstream adoption you need to get enterprises on board too, and  that
> is what I care of.
> Enterprises want code that is not only high quality, but is easy to maintain
> with a development
> team with high attrition. One has to take whatever help is offered for that,
> and one is modern
> languages and runtimes.
>
> Bits of Proof’s own implementation of the scripts was not practically
> relevant in my commercially
> successful deployments, because of the use of a border router, but it helped
> development,
> enabling easier debug and precise error feedback esp. end even after Core
> had a reject message.

In fact I have been accused in the past (by at least Peter Todd) of
having "too many cases in mind" or "doing refactors that are good for
altchains".
That's why I'm very cautious about proposing changes that are not
strict improvments in maintainability to bitcoin itself.
But I actually have freicoin, sidechains and private chains (defined
in freimarkets, used in elements alpha as "block signing") in mind.
Some of the consensus changes I have in mind are support for multiple
assets or interest-bearing assets, for example.
But if you need to change the consensus rules you need to change the
code, there's no way around that.
It will be much simpler to only adapt libconsensus to other chains
than it is to adapt the whole Bitcoin Core code base.
Libconsensus can free you from the need of running "border routers"
(which you need to adapt if you depend on them and are supporting
chains with different rules).
When libconsensus has it's own independent repository, will I fork the
project to have a multi-consensus library supporting multiple
different chains (apart from bitcoin and its testchains)? Maybe, I'm
not sure it makes sense, maybe it's just simpler to maintain a
different project for each different chain (ie libfreicoinconsensus,
libbetaconsensus, etc).

> I integrated libconsensus only for the hope that is significantly fastens
> application side tx verification,
>  which it has turned out it does not, until secp265k1 is integrated.

That is very sad to hear. The main reason to integrate libconsensus is
to avoid consensus fork bugs (or to not depend on the "border routers"
to avoid those bugs).

> I would likely use an other extended libconsensus too, but do not think
> there was a dependency on
> that for enterprise development.
>
> It would help there more to have a slim protocol server, no wallet, no rpc,
> no qt but a high
> performance remoting API.

That's out of scope for libconsensus which will be stateless and whose
only API would be in C.
But the refactors in Bitcoin Core will hopefully make it easier to
support such a minimal node in it (you know you can "./configure
--disable-wallet --without-gui" already, right?, about RPC, that's the
remaining API!).

> Since you already depend on libconsensus for VerifyScript, wouldn't it
> be nice that it also offered VerifyTx, VerifyHeader and VerifyBlock?
> You would still have complete control over storage, concurrency,
> networking, policy...
> My plan is for the C API to interface with the external storage by
> passing a function pointer to it.
>
>
> Storage and validation is non-trivially interconnected, but I now the
> separation can be done,
> since I did it.
>
> Excuse me, but function pointers is a pattern I used in the 

Re: [bitcoin-dev] On the Nature of Miner Advantages in Uncapped Block Size Fee Markets

[Peter R via bitcoin-dev]

Hello Matt and Daniele,

>  this seems to ignore the effects of transaction validation caches and block
> compression protocols. 

The effect of block compression protocols is included.  This is what I call the 
"coding gain" and use the Greek letter "gamma" to represent. 

As long as the block solution announcements contain information (i.e., Shannon 
Entropy) about the transactions included in a block, then the fee market will 
be "healthy" according to the definitions given in the linked paper (see 
below).  This is the case right now, this is the case with your relay network, 
and this would be the case using any implementation of IBLTs that I can 
imagine, so long as miners can still construct blocks according to their own 
volition.  The "healthy fee market" result follows from the Shannon-Hartley 
theorem; the SH-theorem describes the maximum rate at which information 
(Shannon Entropy) can be transmitted over a physical communication channel.   

 https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf

I've exchanged emails with Greg Maxwell about (what IMO is) an academic 
scenario where the block solutions announcements contain no information at all 
about the transactions included in the blocks.  Although the fee market would 
not be healthy in such a scenario, it is my feeling that this also requires 
miners to relinquish their ability to construct blocks according to their own 
volition (i.e., the system would already be centralized).  I look forward to a 
white paper demonstrating otherwise!

Best regards,
Peter



On 2015-08-29, at 2:07 PM, Matt Corallo via bitcoin-dev 
 wrote:

> I believe it was pointed out previously in the discussion of the Peter R
> paper, but I'll repeat it here so that its visible - this seems to
> ignore the effects of transaction validation caches and block
> compression protocols. Many large miners already have their own network
> to relay blocks around the globe with only a few bytes on the wire at
> block-time, and there is also the bitcoinrelaynetwork.org network, which
> does the same for smaller miners, albeit with slightly less efficiency.
> Also, transaction validation time upon receiving a block can be rather
> easily made negligible (ie the only validation time you should have is
> the DB modify-utxo-set time). Thus, the increased orphan risk for
> including a transaction can be reduced to a very, very tiny amount,
> making the optimal blocksize, essentially, including everything that
> you're confident is in the mempool of other reasonably large miners.
> 
> Matt
> 
> On 08/29/15 16:43, Daniele Pinna via bitcoin-dev wrote:
>> I'd like to submit this paper to the dev-list which analyzes how miner
>> advantages scale with network and mempool properties in a scenario of
>> uncapped block sizes. The work proceeds, in a sense, from where Peter
>> R's work left off correcting a mistake and addressing the critiques made
>> by the community to his work.
>> 
>> The main result of the work is a detailed analysis of mining advantages
>> (defined as the added profit per unit of hash) as a function of miner
>> hashrate. In it, I show how large block subsidies (or better, low
>> mempool fees-to-subsidy ratios) incentivize the pooling of large
>> hashrates due to the steady increasing of marginal profits as hashrates
>> grow. 
>> 
>> The paper also shows that part of the large advantage the large miners
>> have today is due to there being a barrier to entry into a
>> high-efficiency mining class which has access to expected profits an
>> order of magnitude larger than everyone else. As block subsidies
>> decrease, this high-efficiency class is expected to vanish leading to a
>> marginal profit structure which decreases as a function of hashrate.
>> 
>> This work has vacuumed my entire life for the past two weeks leading me
>> to lag behind on a lot of work. I apologize for typos which I may not
>> have seen. I stand by for any comments the community may have and look
>> forward to reigniting consideration of a block size scaling proposal
>> (BIP101) which, due to the XT fork drama, I believe has been placed
>> hastily and undeservedly on the chopping block.
>> 
>> https://www.scribd.com/doc/276849939/On-the-Nature-of-Miner-Advantages-in-Uncapped-Block-Size-Fee-Markets
>> 
>> 
>> Regards,
>> Daniele
>> 
>> 
>> ___
>> 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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

[Jorge Timón via bitcoin-dev]

I completely agree and I share your frustration.
The importance of modularization is often disregarded but in my
opinion it has a deep positive impact in the long term: more people
are able to contribute with code and review (in the areas they know
better), the risks associated with each change become more clear
(there was a time when almost any change implied consensus risks),
more alternative code bases can be implemented on top of the basic
ones without fear of consensus bugs, etc.

When I first read some of the code in 2011, I concluded that almost
everything was in main.cpp (which I found ridiculous from a software
engineering perspective). When I started to contribute with code in
2014, main.cpp was still (and still is in my opinion) giant, but the
modularization had greatly improved thanks to changes like moving the
serialization code out of main (thank you very much for that). We
still have a lot of work ahead, but we've certainly advanced a lot.

Unfortunately we cannot force reviewers to pay more attention to
modularization PRs, many of them are usually more interested in
changes that add or remove functionality in the short term. This
problem gets exacerbated when modularization changes are required to
be done in small increments to make them more easily reviewable and
less disruptive to other open PRs, since it's harder for people to see
the big picture and the rationale for those small changes (that often
don't hcange functionality or performance at all).

I know we are not alone on this and people like Wladimir, Pieter, Cory
and Jonas Schnelli (at least, probably more people do) deeply care
about modularization, even if I subjectively and selfishly interpret
the lack of review on some of my PRs as a symptom of the opposite.
So I suggest that people who think this is a high priority join and
review each other's PRs on the subject.

Currently I focus on 3 modularization areas:

1) Chainparams: supporting multiple chains (ie multiple testchains is
all what Bitcoin cares about) is a great goal but there's still many
barriers to create a new testchain. I started this work with #3824,
but even after #6382 there are still more things to do.

2) Consensus: separating the consensus code, Matt Corallo had the idea
of also exposing it in libconsensus. I started with #3839, the latest
things I still have open are #6591 and #6445, please review.

3) Policy: separate node local policy code. Luke Dashjr started with
#5071, I started with #6335 (after several failed attempts), the next
little step blocking many other changes I have ready for way too long
is #6068 (#6424 also helps), please review.

I know Jonas Schnelli is focusing on the wallet. Cory Fields has
recently focused on checkpoints and chainparams.

Now that I know that you also care about modularization I will ask you
for review as well, I hope not to be too annoying like I've been with
Wladimir and Cory some times (and I usually am with some of my
coworkers at blockstream). Please do the same with me: point me to any
modularization PR you have opened.

Regarding your next post, I agree that an additional "Layer" field in
BIPs could be useful. Maybe you should start a BIP for that?

On Sun, Aug 23, 2015 at 3:23 AM, Eric Lombrozo  wrote:
> I've been pushing for greater modularization since I first got into bitcoin.
> I got quickly frustrated when I was only able to get through very few things
> (i.e. moving core structure serialization classes to a separate unit not
> called main). Working on Bitcoin has an added layer of frustration that goes
> beyond most open source projects: even though we're clearly in userland
> working at the application layer, a good layered protocol design is still
> lacking. We have no standards process separate from what basically amount to
> updates to one specific reference implementation. And we all need to agree
> on any major change, since a blockchain that is easily forked in contentious
> ways pretty much defeats its own purpose.
>
> I went off to develop my own stack, where I could more easily avoid politics
> and focus on engineering. But I now understand the politics are inevitable.
> Bitcoin is inherently a cooperative project. Several people have poured
> themselves passionately into the reference codebase, most of whom did it (at
> least initially) purely as unpaid volunteers. There's a lot of love that's
> gone into this. But it's become pretty clear that the modularization is no
> longer merely a matter of good engineering - it is essential to resolving
> serious political challenges.
>
> Perhaps the most frustrating thing of all is watching people pushing for
> relatively superficial yet highly controversial changes while we still lack
> the proper infrastructure to handle these kinds of divergences of opinion
> without either stagnating or becoming polarized.
>
> I could continue working to reimplement an entire stack from scratch, as
> several others have also done - but besides the serious effort dup

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

[Jorge Timón via bitcoin-dev]

On Sun, Aug 23, 2015 at 8:42 AM, Tamas Blummer  wrote:
> I see the huge amount of sweat and love that went into core and it actually
> hurts to see that most is expended in friction and lack of a vision for the
> software architecture.
>
> To be concrete, this was my plan if dealing with the Core code base:
>
> 1) I'd consider the separation of networking and storage as suggested for a
> future extended libconsensus low priority, as their design should be (are)
> dominated by the need of the consensus logic only.
>
> 2) create an API to the consensus+networking+storage service that is not at
> the C++ language level but some scaleable cross-platform remoting, like eg.
> ZeroMQ.
> This API should be minimal and simple, assuming that one fully trusts the
> node answering it. This API would unlock user land development by distinct
> teams with diverse technologies.

I plan to replicate the RPC API (or a subset of it) using ZMQ's
req/rep pattern, but #6103 comes first.

> 3) move the wallet, QT and RPC and other backward compatibility stuff (if
> e.g. there is some mining support) in-top of the new API and into distinct
> source code repositories.

Well, the RPC is the API. For libconsensus, its C API is the API.
We've been talking about separating the wallet and qt to a different
repository for long, but modularization is a prerequisite.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Splitting BIPs

[Jorge Timón via bitcoin-dev]

Concept ACK. As suggested in the other thread, maybe it is worth to
start a new BIP draft for this?


On Thu, Aug 27, 2015 at 10:51 PM, Eric Lombrozo via bitcoin-dev
 wrote:
> I posted a new draft of the proposal:
> http://blockhawk.net/bitcoin-dev/bipwiki.html
>
> The subsections still need to be fleshed out a bit more. I'd love any
> comments or suggestions.
>
>
> On Mon, Aug 24, 2015, 4:30 PM Eric Lombrozo  wrote:
>>
>> Also, the current "type" attribute needs modification. There are different
>> degrees of "standard". Just because a lot of people do X doesn't need to
>> mean that doing X is "officially" endorsed by any other devs. At most levels
>> below 1, disagreements might be entirely tolerable for many things.
>>
>>
>> On Mon, Aug 24, 2015, 2:06 PM Eric Lombrozo  wrote:
>>>
>>>
>>> Seems like a lot of effort and goodwill is being wasted on contention
>>> over things we don't really need to agree upon. In order to help us better
>>> prioritize, I propose adding an extra attribute to BIPs indicating their
>>> "level" which is split into five as follows:
>>>
>>> 1. Consensus (hard/soft fork)
>>> 2. Peer Services
>>> 3. RPC
>>> 4. Implementations
>>> 5. Applications
>>>
>>> I posted an example of what such a table might look like here:
>>> http://blockhawk.net/bitcoin-dev/bipwiki.html
>>>
>>> If other folks also think this is a good idea I'll start working on a BIP
>>> draft for this.
>
>
> ___
> 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

[bitcoin-dev] Fwd: Your Gmaxwell exchange

[Peter R via bitcoin-dev]

Dear Greg,

I am moving our conversation into public as I've recently learned that you've 
been forwarding our private email conversation verbatim without my permission 
[I received permission from dpinna to share the email that proves this fact: 
http://pastebin.com/jFgkk8M3].
> Greg wrote to Peter R:  "You know that your "proof" of this problematic-- 
> outright false under the discussion we had, or at least likely of little 
> pratical relevance under reasonable, pratical assumptions.  But you respond 
> to dpinna agreeing with him and not cautioning him on relying on these
> 
The proof is not "problematic."  Right now you're providing an example of what 
Mike Hearn refers to as "black-and-white" thinking.  Just because the proof 
makes simplifying assumptions, doesn't mean it's not useful in helping us to 
understand the dynamics of the transaction fee market.  Proofs about physical 
systems need to make simplifying assumptions because the physical world is 
messy (unlike the world of pure math).  

My proof assumes very reasonably that block solutions contain information 
(i.e., Shannon Entropy) about the transactions included in a block.  As long as 
this is true, and as long as miners act rationally to maximize their profit, 
then the fee market will remain "healthy" according to the definitions given in 
my paper.  This is the case right now, this is the case with the Relay Network, 
and this would be the case using any implementation of IBLTs that I can 
imagine, so long as miners retain the ability to construct blocks according to 
their own volition.  The "healthy fee market" result follows from the 
Shannon-Hartley theorem; the SH-theorem describes the maximum rate at which 
information (Shannon Entropy) can be transmitted over a physical communication 
channel.   

You are imagining an academic scenario (to use your own words: "perhaps of 
little practical relevance") where all of the block solutions announcements 
contain no information at all about the transactions included in the blocks.  
Although I agree that the fee market would not be healthy in such a scenario, 
it is my feeling that this also requires miners to relinquish their ability to 
construct blocks according to their own volition (i.e., the system would 
already be centralized).  I look forward to reading a white paper where you 
show:

(a) Under what assumptions/requirements such a communication scheme is 
physically possible.

(b) That such a configuration is not equivalent to a single entity[1] 
controlling >50% of the hash power.

(c) That the network moving into such a configuration is plausible.

Lastly, I'd like to conclude by saying that we are all here trying to learn 
about this new amazing thing called Bitcoin.  Please go ahead and write a paper 
that shows under what network configuration my results don't hold.  I'd love to 
read it!  This is how we make progress in science!!

Sincerely, 
Peter

[1] For example, if--in order to achieve such a configuration with infinite 
coding gain--miners can no longer choose how to structure their blocks 
according to their own volition, then I would classify those miners as slaves 
rather than as peers, and the network as already centralized.


Link to forwarded email pastebin: http://pastebin.com/jFgkk8M3

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration

[Chun Wang via bitcoin-dev]

On Sun, Aug 30, 2015 at 4:10 AM, Jorge Timón
 wrote:
/tx/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a?chain=0933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943
>
> (a tx in testnet)
>
> /block/0b0d504d142ac8bdd1a2721d19f423a8146d0d6de882167b?chain=0019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f

Some altcoins (LTC and FTC for example) have the same genesis block hash.

On Sun, Aug 30, 2015 at 4:10 AM, Jorge Timón
 wrote:
> On Sat, Aug 29, 2015 at 9:01 PM, Matt Whitlock via bitcoin-dev
>  wrote:
>> That's still not right, since "mainnet" and "testnet" are not host names.
>>
>> You'd have to do something like:
>>
>> blockchain:?network=testnet&txid=3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
>
> I would really prefer chain= over network=
> By chainID I mean the hash of the genesis block, see
> https://github.com/jtimon/bitcoin/commit/3191d5e8e75687a27cf466b7a4c70bdc04809d39
> I'm completely fine with doing that using an optional parameter (for
> backwards compatibility).
>
> I agree with Andreas Schildbach that respecting the most commonly used
> schemes is desirable.
> So my preference would be:
>
> /tx/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a?chain=0933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943
>
> (a tx in testnet)
>
> /block/0b0d504d142ac8bdd1a2721d19f423a8146d0d6de882167b?chain=0019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
>
> (a block in bitcoin's mainnet)
> ___
> 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

Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration

[Jorge Timón via bitcoin-dev]

On Aug 29, 2015 7:02 PM, "Chun Wang via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Sun, Aug 30, 2015 at 4:10 AM, Jorge Timón
>  wrote:
>
/tx/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a?chain=0933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943
> >
> > (a tx in testnet)
> >
> >
/block/0b0d504d142ac8bdd1a2721d19f423a8146d0d6de882167b?chain=0019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
>
> Some altcoins (LTC and FTC for example) have the same genesis block hash.

That's obviously a design mistake in FTC, but it's not unsolvable. FTC
could move their genesis block to the next block (or the first one that is
not identical to LTC's).

Bitcoin and all its test chains have different genesis blocks, so I'm not
sure FTC should be a concern for a BIP anyway...
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] On the Nature of Miner Advantages in Uncapped Block Size Fee Markets

[Matt Corallo via bitcoin-dev]

It is not a purely academic scenario that blocks contain effectively no
information (that was not previously relayed). I'm not aware of any
public code to do so, but I know several large miners who pre-relay the
block(s) they are working on to other nodes of theirs around the globe.
This means at announce-time you have only a few bytes to broadcast (way
less than a packet, and effects of using smaller packets to relay things
vs larger packets are very small, if anything). After you've broadcast
to all of your nodes, hops to other mining nodes are probably only a
handful of ms away with very low packet loss, so relay time is no longer
connected to transaction inclusion at all (unless you're talking about
multi-GB blocks). Of course, this is relay time for large miners who can
invest time and money to build such systems. Small miners are completely
screwed in such a system.

Thus, the orphan risk for including a transaction is related to the
validation time (which is only DB modify-utxo-set time, essentially,
which maybe you can optimize much of that away, too, and only have to
pass over mempool or so). Anyway, my point, really, is that though
miners will have an incentive to not include transactions which will
trigger validation by other nodes (ie things not already in their
mempool), the incentive to not include transactions which have already
been relayed around sufficiently is, while not theoretically zero, as
near to zero in practice as you can get.

Matt

On 08/29/15 23:17, Peter R wrote:
> Hello Matt and Daniele,
> 
>>  this seems to ignore the effects of transaction validation caches and
>> *block
>> compression protocols. *
> 
> The effect of block compression protocols is included.  This is what I
> call the "coding gain" and use the Greek letter "gamma" to represent. 
> 
> As long as the block solution announcements contain information (i.e.,
> Shannon Entropy) about the transactions included in a block, then the
> fee market will be "healthy" according to the definitions given in the
> linked paper (see below).  This is the case right now, this is the case
> with your relay network, and this would be the case using any
> implementation of IBLTs that I can imagine, so long as miners can still
> construct blocks according to their own volition.  The "healthy fee
> market" result follows from the Shannon-Hartley theorem; the SH-theorem
> describes the maximum rate at which information (Shannon Entropy) can be
> transmitted over a physical communication channel.   
> 
>  https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf
> 
> I've exchanged emails with Greg Maxwell about (what IMO is) an academic
> scenario where the block solutions announcements contain *no information
> at all* about the transactions included in the blocks.  Although the fee
> market would not be healthy in such a scenario, it is my feeling that
> this also requires miners to relinquish their ability to construct
> blocks according to their own volition (i.e., the system would already
> be centralized).  I look forward to a white paper demonstrating otherwise!
> 
> Best regards,
> Peter
> 
> 
> 
> On 2015-08-29, at 2:07 PM, Matt Corallo via bitcoin-dev
>  > wrote:
> 
>> I believe it was pointed out previously in the discussion of the Peter R
>> paper, but I'll repeat it here so that its visible - this seems to
>> ignore the effects of transaction validation caches and block
>> compression protocols. Many large miners already have their own network
>> to relay blocks around the globe with only a few bytes on the wire at
>> block-time, and there is also the bitcoinrelaynetwork.org
>>  network, which
>> does the same for smaller miners, albeit with slightly less efficiency.
>> Also, transaction validation time upon receiving a block can be rather
>> easily made negligible (ie the only validation time you should have is
>> the DB modify-utxo-set time). Thus, the increased orphan risk for
>> including a transaction can be reduced to a very, very tiny amount,
>> making the optimal blocksize, essentially, including everything that
>> you're confident is in the mempool of other reasonably large miners.
>>
>> Matt
>>
>> On 08/29/15 16:43, Daniele Pinna via bitcoin-dev wrote:
>>> I'd like to submit this paper to the dev-list which analyzes how miner
>>> advantages scale with network and mempool properties in a scenario of
>>> uncapped block sizes. The work proceeds, in a sense, from where Peter
>>> R's work left off correcting a mistake and addressing the critiques made
>>> by the community to his work.
>>>
>>> The main result of the work is a detailed analysis of mining advantages
>>> (defined as the added profit per unit of hash) as a function of miner
>>> hashrate. In it, I show how large block subsidies (or better, low
>>> mempool fees-to-subsidy ratios) incentivize the pooling of large
>>> hashrates due to the steady increasing of marginal profits as h

Re: [bitcoin-dev] On the Nature of Miner Advantages in Uncapped Block Size Fee Markets

[Matt Corallo via bitcoin-dev]

Of course this assumes the network does not change any as a result of
such a system. But such a system provides strong incentives for the
network to centralize in other ways (put all the mining nodes in one DC
for all miners, etc).

Matt

On 08/30/15 02:33, Matt Corallo via bitcoin-dev wrote:
> It is not a purely academic scenario that blocks contain effectively no
> information (that was not previously relayed). I'm not aware of any
> public code to do so, but I know several large miners who pre-relay the
> block(s) they are working on to other nodes of theirs around the globe.
> This means at announce-time you have only a few bytes to broadcast (way
> less than a packet, and effects of using smaller packets to relay things
> vs larger packets are very small, if anything). After you've broadcast
> to all of your nodes, hops to other mining nodes are probably only a
> handful of ms away with very low packet loss, so relay time is no longer
> connected to transaction inclusion at all (unless you're talking about
> multi-GB blocks). Of course, this is relay time for large miners who can
> invest time and money to build such systems. Small miners are completely
> screwed in such a system.
> 
> Thus, the orphan risk for including a transaction is related to the
> validation time (which is only DB modify-utxo-set time, essentially,
> which maybe you can optimize much of that away, too, and only have to
> pass over mempool or so). Anyway, my point, really, is that though
> miners will have an incentive to not include transactions which will
> trigger validation by other nodes (ie things not already in their
> mempool), the incentive to not include transactions which have already
> been relayed around sufficiently is, while not theoretically zero, as
> near to zero in practice as you can get.
> 
> Matt
> 
> On 08/29/15 23:17, Peter R wrote:
>> Hello Matt and Daniele,
>>
>>>  this seems to ignore the effects of transaction validation caches and
>>> *block
>>> compression protocols. *
>>
>> The effect of block compression protocols is included.  This is what I
>> call the "coding gain" and use the Greek letter "gamma" to represent. 
>>
>> As long as the block solution announcements contain information (i.e.,
>> Shannon Entropy) about the transactions included in a block, then the
>> fee market will be "healthy" according to the definitions given in the
>> linked paper (see below).  This is the case right now, this is the case
>> with your relay network, and this would be the case using any
>> implementation of IBLTs that I can imagine, so long as miners can still
>> construct blocks according to their own volition.  The "healthy fee
>> market" result follows from the Shannon-Hartley theorem; the SH-theorem
>> describes the maximum rate at which information (Shannon Entropy) can be
>> transmitted over a physical communication channel.   
>>
>>  https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf
>>
>> I've exchanged emails with Greg Maxwell about (what IMO is) an academic
>> scenario where the block solutions announcements contain *no information
>> at all* about the transactions included in the blocks.  Although the fee
>> market would not be healthy in such a scenario, it is my feeling that
>> this also requires miners to relinquish their ability to construct
>> blocks according to their own volition (i.e., the system would already
>> be centralized).  I look forward to a white paper demonstrating otherwise!
>>
>> Best regards,
>> Peter
>>
>>
>>
>> On 2015-08-29, at 2:07 PM, Matt Corallo via bitcoin-dev
>> > > wrote:
>>
>>> I believe it was pointed out previously in the discussion of the Peter R
>>> paper, but I'll repeat it here so that its visible - this seems to
>>> ignore the effects of transaction validation caches and block
>>> compression protocols. Many large miners already have their own network
>>> to relay blocks around the globe with only a few bytes on the wire at
>>> block-time, and there is also the bitcoinrelaynetwork.org
>>>  network, which
>>> does the same for smaller miners, albeit with slightly less efficiency.
>>> Also, transaction validation time upon receiving a block can be rather
>>> easily made negligible (ie the only validation time you should have is
>>> the DB modify-utxo-set time). Thus, the increased orphan risk for
>>> including a transaction can be reduced to a very, very tiny amount,
>>> making the optimal blocksize, essentially, including everything that
>>> you're confident is in the mempool of other reasonably large miners.
>>>
>>> Matt
>>>
>>> On 08/29/15 16:43, Daniele Pinna via bitcoin-dev wrote:
 I'd like to submit this paper to the dev-list which analyzes how miner
 advantages scale with network and mempool properties in a scenario of
 uncapped block sizes. The work proceeds, in a sense, from where Peter
 R's work left off correcting a mistake and addressing the critiques 

Re: [bitcoin-dev] On the Nature of Miner Advantages in Uncapped Block Size Fee Markets

[Peter R via bitcoin-dev]

Hello Matt,

> It is not a purely academic scenario that blocks contain effectively no
> information (that was not previously relayed).

The results of my paper hold unless the information about the included 
transactions is identically zero.  If this information is extremely small, then 
I agree that something other than the orphan cost would drive the fee market. I 
don't think this will ever by the case, however.

> I'm not aware of any
> public code to do so, but I know several large miners who pre-relay the
> block(s) they are working on to other nodes of theirs around the globe….

In this paragraph, you are talking about intra-miner communication (you refer 
to other nodes "of theirs").   I agree that this can be very fast because 
there's only one entity involved. 

> Thus, the orphan risk for including a transaction is related to the
> validation time … the incentive to not include transactions which have already
> been relayed around sufficiently is, while not theoretically zero, as
> near to zero in practice as you can get.

I look forward to hearing your talk about the Relay Network.  Let's image there 
was no block size limit.  Using the Relay Network as it currently operates now, 
how big would the block solution announcement be:

(1) if a miner published a 10 MB block where 100% of the transactions are known 
by the other nodes?  

(2) if a miner published a 10 MB block where 90% of the transactions are known 
by the other nodes?  

(3) if a miner published a 100 MB spam block where 0% of the transactions are 
known by the other nodes?

Best regards,
Peter


> 
> Matt
> 
> On 08/29/15 23:17, Peter R wrote:
>> Hello Matt and Daniele,
>> 
>>> this seems to ignore the effects of transaction validation caches and
>>> *block
>>> compression protocols. *
>> 
>> The effect of block compression protocols is included.  This is what I
>> call the "coding gain" and use the Greek letter "gamma" to represent. 
>> 
>> As long as the block solution announcements contain information (i.e.,
>> Shannon Entropy) about the transactions included in a block, then the
>> fee market will be "healthy" according to the definitions given in the
>> linked paper (see below).  This is the case right now, this is the case
>> with your relay network, and this would be the case using any
>> implementation of IBLTs that I can imagine, so long as miners can still
>> construct blocks according to their own volition.  The "healthy fee
>> market" result follows from the Shannon-Hartley theorem; the SH-theorem
>> describes the maximum rate at which information (Shannon Entropy) can be
>> transmitted over a physical communication channel.   
>> 
>> https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf
>> 
>> I've exchanged emails with Greg Maxwell about (what IMO is) an academic
>> scenario where the block solutions announcements contain *no information
>> at all* about the transactions included in the blocks.  Although the fee
>> market would not be healthy in such a scenario, it is my feeling that
>> this also requires miners to relinquish their ability to construct
>> blocks according to their own volition (i.e., the system would already
>> be centralized).  I look forward to a white paper demonstrating otherwise!
>> 
>> Best regards,
>> Peter
>> 
>> 
>> 
>> On 2015-08-29, at 2:07 PM, Matt Corallo via bitcoin-dev
>> > > wrote:
>> 
>>> I believe it was pointed out previously in the discussion of the Peter R
>>> paper, but I'll repeat it here so that its visible - this seems to
>>> ignore the effects of transaction validation caches and block
>>> compression protocols. Many large miners already have their own network
>>> to relay blocks around the globe with only a few bytes on the wire at
>>> block-time, and there is also the bitcoinrelaynetwork.org
>>>  network, which
>>> does the same for smaller miners, albeit with slightly less efficiency.
>>> Also, transaction validation time upon receiving a block can be rather
>>> easily made negligible (ie the only validation time you should have is
>>> the DB modify-utxo-set time). Thus, the increased orphan risk for
>>> including a transaction can be reduced to a very, very tiny amount,
>>> making the optimal blocksize, essentially, including everything that
>>> you're confident is in the mempool of other reasonably large miners.
>>> 
>>> Matt
>>> 
>>> On 08/29/15 16:43, Daniele Pinna via bitcoin-dev wrote:
 I'd like to submit this paper to the dev-list which analyzes how miner
 advantages scale with network and mempool properties in a scenario of
 uncapped block sizes. The work proceeds, in a sense, from where Peter
 R's work left off correcting a mistake and addressing the critiques made
 by the community to his work.
 
 The main result of the work is a detailed analysis of mining advantages
 (defined as the added profit per unit of hash) as a function of miner
 hashr

Re: [bitcoin-dev] On the Nature of Miner Advantages in Uncapped Block Size Fee Markets

[Peter R via bitcoin-dev]

> Of course this assumes the network does not change any as a result of
> such a system. But such a system provides strong incentives for the
> network to centralize in other ways (put all the mining nodes in one DC
> for all miners, etc).

If all the mining nodes are in one data center, and if all the nodes are 
programmed to build blocks in essentially the same way, then I would agree that 
the orphan cost would be negligible!  I will add this as an example of a 
network configuration where the results of my paper would be less relevant.  

Peter  


On 2015-08-29, at 7:35 PM, Matt Corallo  wrote:

> Of course this assumes the network does not change any as a result of
> such a system. But such a system provides strong incentives for the
> network to centralize in other ways (put all the mining nodes in one DC
> for all miners, etc).
> 
> Matt
> 
> On 08/30/15 02:33, Matt Corallo via bitcoin-dev wrote:
>> It is not a purely academic scenario that blocks contain effectively no
>> information (that was not previously relayed). I'm not aware of any
>> public code to do so, but I know several large miners who pre-relay the
>> block(s) they are working on to other nodes of theirs around the globe.
>> This means at announce-time you have only a few bytes to broadcast (way
>> less than a packet, and effects of using smaller packets to relay things
>> vs larger packets are very small, if anything). After you've broadcast
>> to all of your nodes, hops to other mining nodes are probably only a
>> handful of ms away with very low packet loss, so relay time is no longer
>> connected to transaction inclusion at all (unless you're talking about
>> multi-GB blocks). Of course, this is relay time for large miners who can
>> invest time and money to build such systems. Small miners are completely
>> screwed in such a system.
>> 
>> Thus, the orphan risk for including a transaction is related to the
>> validation time (which is only DB modify-utxo-set time, essentially,
>> which maybe you can optimize much of that away, too, and only have to
>> pass over mempool or so). Anyway, my point, really, is that though
>> miners will have an incentive to not include transactions which will
>> trigger validation by other nodes (ie things not already in their
>> mempool), the incentive to not include transactions which have already
>> been relayed around sufficiently is, while not theoretically zero, as
>> near to zero in practice as you can get.
>> 
>> Matt
>> 
>> On 08/29/15 23:17, Peter R wrote:
>>> Hello Matt and Daniele,
>>> 
 this seems to ignore the effects of transaction validation caches and
 *block
 compression protocols. *
>>> 
>>> The effect of block compression protocols is included.  This is what I
>>> call the "coding gain" and use the Greek letter "gamma" to represent. 
>>> 
>>> As long as the block solution announcements contain information (i.e.,
>>> Shannon Entropy) about the transactions included in a block, then the
>>> fee market will be "healthy" according to the definitions given in the
>>> linked paper (see below).  This is the case right now, this is the case
>>> with your relay network, and this would be the case using any
>>> implementation of IBLTs that I can imagine, so long as miners can still
>>> construct blocks according to their own volition.  The "healthy fee
>>> market" result follows from the Shannon-Hartley theorem; the SH-theorem
>>> describes the maximum rate at which information (Shannon Entropy) can be
>>> transmitted over a physical communication channel.   
>>> 
>>> https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf
>>> 
>>> I've exchanged emails with Greg Maxwell about (what IMO is) an academic
>>> scenario where the block solutions announcements contain *no information
>>> at all* about the transactions included in the blocks.  Although the fee
>>> market would not be healthy in such a scenario, it is my feeling that
>>> this also requires miners to relinquish their ability to construct
>>> blocks according to their own volition (i.e., the system would already
>>> be centralized).  I look forward to a white paper demonstrating otherwise!
>>> 
>>> Best regards,
>>> Peter
>>> 
>>> 
>>> 
>>> On 2015-08-29, at 2:07 PM, Matt Corallo via bitcoin-dev
>>> >> > wrote:
>>> 
 I believe it was pointed out previously in the discussion of the Peter R
 paper, but I'll repeat it here so that its visible - this seems to
 ignore the effects of transaction validation caches and block
 compression protocols. Many large miners already have their own network
 to relay blocks around the globe with only a few bytes on the wire at
 block-time, and there is also the bitcoinrelaynetwork.org
  network, which
 does the same for smaller miners, albeit with slightly less efficiency.
 Also, transaction validation time upon receiving a block can be rather
 easily made negligible (ie 

Re: [bitcoin-dev] Your Gmaxwell exchange

[Gregory Maxwell via bitcoin-dev]

On Sun, Aug 30, 2015 at 1:43 AM, Peter R  wrote:
> Dear Greg,
>
> I am moving our conversation into public as I've recently learned that
> you've been forwarding our private email conversation verbatim without
> my permission [I received permission from dpinna to share the email
> below that proves this fact].

Unfortunately, your work extensive as it was made at least two
non-disclosed or poorly-disclosed simplifying assumptions and a significant
system understanding error which, I believe, undermined it completely.

In short these were:

* You assume miners do not have the ability to change their level
centralization.

 -- In fact they do, not just in theory but in pratice have responded
to orphaning this way in the past; and it is one of the major
concerns in this space.

* You assume the supply of bitcoin is infinite (that subsidy never
declines)

 -- It declines geometrically, and must if the 21m limit is to be upheld.
(Though I think this is not equally important as the other concerns)

* You argue, incorrectly, that amount of information which must be
transmitted at the moment a block is discovered is proportional to the
block's size.

 -- Instead the same information can be transmitted _in advance_, as
 has been previously proposed, and various techniques can make doing
 so arbitrarily efficient.

[I would encourage anyone who is interested to read the posted off-list
discussion]

I contacted you in private as a courtesy in the hope that it would be
a more productive pathway to improving our collective understanding; as well
as a courtesy to the readers of the list in consideration of traffic levels.

In one sense, this was a success: Our conversation concluded with you
enumerating a series of corrective actions that you would take:


> 1.  I will make it more clear that the results of the paper hinge on
> the assumption that block solutions are propagated across channels,
> and that the quantity of pure information communicated per solution
> is proportional to the amount of information contained within the block.
>
> 2.  I will add a note [unless you ask me not to] something to the effect
> of "Greg Maxwell challenges the claim that the coding gain cannot
> be infinite…" followed by a summary of the scenario you described.
> I will reference "personal communication."  I will also run the note
> by you before I make the next revision public.
>
> 3.  I will point out that if the coding gain can be made spectacularly
> high, that the propagation impedance in my model will become very small,
> and that although a fee market may strictly exist in the asymptotic
> sense, such a fee market may not be relevant (the phenomena in the paper
> would be negligible compared to the dynamics from some other effect).
>
> 4. [UNRELATED] I also plan to address Dave Hudson's objections in my
> next revision (the "you don't orphan your own block" point).
>
> Lastly, thank you for the note about what might happen when fees >
> rewards.  I've have indeed been thinking about this.  I believe it is
> outside the scope of the present paper, although I am doing some work
> on the topic.  (Perhaps I'll add a bit more discussion on this topic
> to the present paper to get the reader thinking in this direction).


To the best of my knowledge, you've taken none of these corrective
actions in the nearly month that has passed.  I certainly understand being
backlogged, but you've also continued to make public comments about your
work seemingly (to me) in contradiction with the above corrective actions.

Today I discovered that another author spent their time extending your
work and wasn't made aware of these points.  A result was that the other
author's work may require significant revisions.

I complained about this to you, again privately, and your (apparent)
response was to post to that thread stating that there was a
details-unspecified academic disagreement with me and "I look forward
to a white paper demonstrating otherwise!", in direct contradiction to
your remarks to me three weeks ago in private correspondence: In private
you said that your model may only hold in an asymptotic sense and that
"the phenomena in the paper (may) be negligible compared to the dynamics
from some other effect"; but in public you said /my/ position was
"academic".

At this point I thought continuing to withhold this information from
the other author was unreasonable and no longer justified by courtesy
to you, and I forwarded our complete discussion to the other author
with the comment "I'll forward you a set of private correspondence
that I've had with Peter R.  I would recommend you take the time to
read it and consider it.".

I apologize if in doing so I've breached your confidence, none of the
material we discussed was a sort that I would have ordinarily considered
private, and you had already talked about making the product of our
communication published as part of your corrective actions.
I do not think it would 

Re: [bitcoin-dev] On the Nature of Miner Advantages in Uncapped Block Size Fee Markets

[Matt Corallo via bitcoin-dev]

On 08/30/15 02:49, Peter R wrote:
> Hello Matt,
> 
>> It is not a purely academic scenario that blocks contain *effectively* no
>> information (that was not previously relayed). 
> 
> The results of my paper hold unless the information about the included
> transactions is *identically zero*.  If this information is extremely
> small, then I agree that something other than the orphan cost would
> drive the fee market. I don't think this will ever by the case, however.

You missed one key point - information transmitted across networks is
not slowed down on a per-bit basis, its (largely) slowed down on a
per-packet basis! You have some 1400+ bytes to work with before you
notice the increase in information in relay cost. Of course this only
applies if you are talking about long-haul links (across oceans, between
countries, etc), if you're talking about short links it is a per-byte
cost, but your time is probably negligible for anything but VERY large
blocks.

>> I'm not aware of any
>> public code to do so, but I know several large miners who pre-relay the
>> block(s) they are working on to other nodes *of theirs* around the globe….
> 
> In this paragraph, you are talking about intra-miner communication (you
> refer to other nodes "of theirs").   I agree that this can be very fast
> because there's only one entity involved. 

Very fast is an understatement. My point was that it is literally always
a single packet, and a very small packet, at that.

>> Thus, the orphan risk for including a transaction is related to the
>> validation time … the incentive to not include transactions which have
>> already
>> been relayed around sufficiently is, while not theoretically zero, *as
>> near to zero in practice as you can get*.
> 
> I look forward to hearing your talk about the Relay Network.  Let's
> image there was no block size limit.  Using the Relay Network*as it
> currently operates now*, how big would the block solution announcement be:

I think you missed it, this mail was not about the relay network. Let's
ignore the relay network entirely for now. Several miners have nodes
well distributed all over the globe which peer either directly with
other miners in the area, or just connect to a ton of nodes, probably
hitting other miners. The cost to transmit from their pool server to
their relay server is one packet, always. They pre-relay everything
they're gonna include, so, at max, they might have to pick between a few
pre-relayed blocks (what, like, 2/5 bits?). From there, you assume they
are transmitting to a node in the same DC, or at least very close (say,
local within AWS-US-East/maybe between AWS-US-East and somewhere in
NYC), where transmitting even 100MB is really fast.

> (1) if a miner published a 10 MB block where 100% of the transactions
> are known by the other nodes?  
> 
> (2) if a miner published a 10 MB block where 90% of the transactions are
> known by the other nodes?  
> 
> (3) if a miner published a 100 MB spam block where 0% of the
> transactions are known by the other nodes?
> 
> Best regards,
> Peter
> 
> 
>>
>> Matt
>>
>> On 08/29/15 23:17, Peter R wrote:
>>> Hello Matt and Daniele,
>>>
 this seems to ignore the effects of transaction validation caches and
 *block
 compression protocols. *
>>>
>>> The effect of block compression protocols is included.  This is what I
>>> call the "coding gain" and use the Greek letter "gamma" to represent.
>>>
>>> As long as the block solution announcements contain information (i.e.,
>>> Shannon Entropy) about the transactions included in a block, then the
>>> fee market will be "healthy" according to the definitions given in the
>>> linked paper (see below).  This is the case right now, this is the case
>>> with your relay network, and this would be the case using any
>>> implementation of IBLTs that I can imagine, so long as miners can still
>>> construct blocks according to their own volition.  The "healthy fee
>>> market" result follows from the Shannon-Hartley theorem; the SH-theorem
>>> describes the maximum rate at which information (Shannon Entropy) can be
>>> transmitted over a physical communication channel.   
>>>
>>> https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf
>>>
>>> I've exchanged emails with Greg Maxwell about (what IMO is) an academic
>>> scenario where the block solutions announcements contain *no information
>>> at all* about the transactions included in the blocks.  Although the fee
>>> market would not be healthy in such a scenario, it is my feeling that
>>> this also requires miners to relinquish their ability to construct
>>> blocks according to their own volition (i.e., the system would already
>>> be centralized).  I look forward to a white paper demonstrating
>>> otherwise!
>>>
>>> Best regards,
>>> Peter
>>>
>>>
>>>
>>> On 2015-08-29, at 2:07 PM, Matt Corallo via bitcoin-dev
>>> >> 
>>> > wrote:
>>>
 I belie

Re: [bitcoin-dev] Your Gmaxwell exchange

[Peter R via bitcoin-dev]

Hi Greg,

> Unfortunately, your work extensive as it was made at least two
> non-disclosed or poorly-disclosed simplifying assumptions and a significant
> system understanding error which, I believe, undermined it completely.
> 
> In short these were:
> 
> * You assume miners do not have the ability to change their level
> centralization.
> 
> -- In fact they do, not just in theory but in pratice have responded
>to orphaning this way in the past; and it is one of the major
>concerns in this space.

I agree that miners may change their level of centralization.  This neither 
affects the model nor the results presented in the paper.

> * You assume the supply of bitcoin is infinite (that subsidy never
> declines)
> 
> -- It declines geometrically, and must if the 21m limit is to be upheld.
>(Though I think this is not equally important as the other concerns)

No I don't.  I assume the inflation rate is R/T, where R is a variable.  

The last paragraph of the conclusion speaks to the paradox of what happens when 
R -> 0 as an area for future research. 


> * You argue, incorrectly, that amount of information which must be
> transmitted at the moment a block is discovered is proportional to the
> block's size.
> 
> -- Instead the same information can be transmitted _in advance_, as
> has been previously proposed, and various techniques can make doing
> so arbitrarily efficient.

I assume, very reasonably, that the block solutions contain information about 
the transactions included in the block.  This is the case today, this is the 
case using the relay network, and this would be the case using any compression 
scheme I can personally imagine actually occurring in the future.  

(I've always agreed that if block solutions can be communicated to all of the 
hash power in such a way that they don't include any information about the 
transactions they contain, then the conditions for a healthy fee market would 
not be met [this would be gamma --> infinity in my model]). 


> [I would encourage anyone who is interested to read the posted off-list
> discussion]

As would I.  

> I contacted you in private as a courtesy in the hope that it would be
> a more productive pathway to improving our collective understanding; as well
> as a courtesy to the readers of the list in consideration of traffic levels.

I appreciated the discussion we were having and I thought we had come to some 
kind of an understanding.  I acknowledged that when I made the other 
corrections to my paper that I would further clarify the assumptions (I agreed 
that the presentation could be improved).  

What was not courteous was that you forwarded the entire private email chain to 
other people without my permission.

> In one sense, this was a success: Our conversation concluded with you
> enumerating a series of corrective actions that you would take:
> 
> 
>> 1.  I will make it more clear that the results of the paper hinge on
>> the assumption that block solutions are propagated across channels,
>> and that the quantity of pure information communicated per solution
>> is proportional to the amount of information contained within the block.
>> 
>> 2.  I will add a note [unless you ask me not to] something to the effect
>> of "Greg Maxwell challenges the claim that the coding gain cannot
>> be infinite…" followed by a summary of the scenario you described.
>> I will reference "personal communication."  I will also run the note
>> by you before I make the next revision public.
>> 
>> 3.  I will point out that if the coding gain can be made spectacularly
>> high, that the propagation impedance in my model will become very small,
>> and that although a fee market may strictly exist in the asymptotic
>> sense, such a fee market may not be relevant (the phenomena in the paper
>> would be negligible compared to the dynamics from some other effect).
>> 
>> 4. [UNRELATED] I also plan to address Dave Hudson's objections in my
>> next revision (the "you don't orphan your own block" point).
>> 
>> Lastly, thank you for the note about what might happen when fees >
>> rewards.  I've have indeed been thinking about this.  I believe it is
>> outside the scope of the present paper, although I am doing some work
>> on the topic.  (Perhaps I'll add a bit more discussion on this topic
>> to the present paper to get the reader thinking in this direction).

I stand by all of these four points.  My paper wasn't perfectly presented.  
Making these clarifications will strengthen the manuscript by showing how 
strong the claim "a healthy transaction fee market exists without a block size 
limit" is.  


> To the best of my knowledge, you've taken none of these corrective
> actions in the nearly month that has passed.  I certainly understand being
> backlogged, but you've also continued to make public comments about your
> work seemingly (to me) in contradiction with the above corrective actions.

My public comments have been factual.  I've even

Re: [bitcoin-dev] Your Gmaxwell exchange

[Gregory Maxwell via bitcoin-dev]

On Sun, Aug 30, 2015 at 4:13 AM, Peter R  wrote:
> I agree that miners may change their level of centralization.  This neither
> affects the model nor the results presented in the paper.

It has tremdous significance to the real-world impact of your results.

If not for the other errors in your work, this point would make the
take away of your work not "a healthy transaction fee market exists
without a block size limit" but rather "a decenteralized bitcoin
cannot exist"-- as, accepting the other errors as fact your model
shows that centralizing mining is always strictly more profitable at
any level of fee demand; because your model equivilent shows that for
any level of fee demand and gamma miners could increase their income
by centeralizing further.

I absolutely agree that simplifications are useful and essential, but
it is critically important to call them out before someone mistakes
theoretical work as useful motivation for policy in the non-simplified
system.

> -- Instead the same information can be transmitted _in advance_, as
> has been previously proposed, and various techniques can make doing
> so arbitrarily efficient.
>
> I assume, very reasonably, that the block solutions contain information
> about the transactions included in the block.  This is the case today, this
> is the case using the relay network, and this would be the case using any
> compression scheme I can personally imagine actually occurring in the
> future.

This assumption is unreasonable, and does not-- in fact-- accurately
reflect the situation today.

For example it does not reflect how hashers return work to pools
_today_ (and since 2011) as they so to only by referencing the merkel
root... the pool already knows the  transaction set. In that
particular case it knows it because it selected it to begin with, but
the same behavior holds if the hasher selects the transaction set and
sends it first.

It only _very_ weakly reflects how the relay protocol works (only the
selection and permutation is communicated; not the transaction data
itself; for already known transactions). Even if you assume nothing
more than that (in spite of the existing reality) you have not shown
that the compressed data must be linear in the size of the block.

It does not reflect how P2Pool works (which also sends the
transactions in advance).

There is a simple, and intuitive understanding that does not require
any complex supposition:  You argue that the information must be
transfered when a block is found, thus delaying it.  I point out, no,
any required information (to the extent that there is any at all after
efficient encoding) can be sent in advance of the block.

I believe that you've allowed the fact that the specifc example block
relay protocol doesn't bother sending _all_ information in advance to
confuse it for mere compression.

> My public comments have been factual.  I've even gone out of my way in
> several public threads to point out your objection that the coding gain
> could be zero (even though I think it is flawed "black-and-white thinking"
> about an academic scenario that will never unfold and might actually be
> physically impossible without Bitcoin already being centralized).

I believe my reponses are firmly grounded in the physical reality of
actually deployed systems and constructable protocols.

By comparison, even if I were to agree that the bound is not actually
exactly 0 proporionality  you have already agreed that with
"compression" the amount sent could be arbritarily low. The result
being that the behavior you're describing would only be asymptoic and
have no relationship to the actual Bitcoin system that exists in a
finite universe.

But you continue to demand debate over this meaningless point.

> I'll end by saying that I am the one describing things as the presently are.
> You are talking about a hypothetical future that may or may not exist (and
> may not even be possible).  The results of my paper logically follow from
> the assumptions made. You think the assumption that "block solutions contain
> information about the transactions included in the block" will not hold in
> the future.  Can you show:
>
> (a) Under what assumptions/requirements your communication scheme is
> physically possible.

Pratically every block today is mined under a protocol which does not
need to communicate anything but constant data when a block is found.

I am getting a little tired of people suggesting things which are
widely deployed are not physically possible.

Yes, that particular example is not the most powerful form of that
idea-- but it has the benefit of _universal_ use.

> (b) That such a configuration is not equivalent to a single entity[1]
> controlling >50% of the hash power.

I find this a little amusing. Even in this messsage you defend
ignoring of centeralization considerations in your paper. But here ask
that I address concerns which you refused to suggest. Why do you
demand my correction use weaker assumptions than

Re: [bitcoin-dev] Your Gmaxwell exchange

[Adam Ritter via bitcoin-dev]

I don't really see any problem with the paper:
All it states is that having the assumption that miners don't
centralize, transaction fees don't go to zero even without the
blocksize limit. I think we can accept this as a nice academic
research, and I believe that it's true.
Still, it doesn't have anything that is practical for me as an user of
the Bitcoin network (I use it for storing long-term purchase value, as
most of the people who I know): it doesn't help me if I still need to
pay transaction fees after the blocksize limit is gone. My (and other
users') main concern is about centralization, which has nothing to do
with transaction fees. I would be OK with $100 transaction fee as
well, as long as the network is fair and secure (which comes from
decentralization).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev