Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)
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
[bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
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 cutpaste 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: hash/string 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 cutpaste is far from ideal. ___ 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)
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 bitcoin-dev@lists.linuxfoundation.org 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
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 bitcoin-dev@lists.linuxfoundation.org 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 cutpaste 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: hash/string 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 cutpaste 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
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 bitcoin-dev@lists.linuxfoundation.org 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 cutpaste 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: hash/string 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 cutpaste 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
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] RFC - BIP: URI scheme for Blockchain exploration
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] RFC - BIP: URI scheme for Blockchain exploration
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 bitcoin-dev@lists.linuxfoundation.org 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 bitcoin-dev@lists.linuxfoundation.org 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 cutpaste 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: hash/string 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 cutpaste 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 mailing list
Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
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 btcd...@gmail.com 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 bitcoin-dev@lists.linuxfoundation.org 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 bitcoin-dev@lists.linuxfoundation.org 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 cutpaste 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: hash/string 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
Re: [bitcoin-dev] [Bitcoin-development] [BIP draft] Motivation and deployment of consensus rules changes ([soft/hard]forks)
On Wed, Aug 26, 2015 at 1:20 AM, Andy Chase via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org 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] Variable Block Size Proposal
-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 bitcoin-dev@lists.linuxfoundation.org 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. Why wouldn't this work? What portion is flawed? Will the miners
Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
That's still not right, since mainnet and testnet are not host names. You'd have to do something like: blockchain:?network=testnettxid=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 bitcoin-dev@lists.linuxfoundation.org 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 bitcoin-dev@lists.linuxfoundation.org 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 cutpaste 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: hash/string 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 cutpaste is far from ideal.
Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)
On Sat, Aug 29, 2015 at 12:15 PM, Btc Drak btcd...@gmail.com wrote: On Sat, Aug 29, 2015 at 1:29 AM, Mark Friedenbach via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org 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 it's not identical, but I
Re: [bitcoin-dev] Your Gmaxwell exchange
On Sun, Aug 30, 2015 at 4:13 AM, Peter R pete...@gmx.com 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 your work? That
Re: [bitcoin-dev] On the Nature of Miner Advantages in Uncapped Block Size Fee Markets
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 lf-li...@mattcorallo.com 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 bitcoin-dev@lists.linuxfoundation.org mailto:bitcoin-dev@lists.linuxfoundation.org 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 http://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
Re: [bitcoin-dev] Your Gmaxwell exchange
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 gone out of my way in several public threads to point out your objection that the coding gain
Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
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 bitcoin-dev@lists.linuxfoundation.org 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] Your Gmaxwell exchange
On Sun, Aug 30, 2015 at 1:43 AM, Peter R pete...@gmx.com 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 be reasonable to demand that I
Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)
On Sun, Aug 23, 2015 at 8:42 AM, Tamas Blummer ta...@bitsofproof.com 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
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 bitcoin-dev@lists.linuxfoundation.org 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 elombr...@gmail.com 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 elombr...@gmail.com 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
