Re: [bitcoin-dev] A reason we can all agree on to increase block size
On Mon, Aug 3, 2015 at 8:53 AM, Jim Phillips via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Yes I've had a couple other people point that out to me as well and the logic is sound. Unfortunately that doesn't help solve the actual issue that mining is currently consolidated within the jurisdiction of a single political body that is not exactly Bitcoin friendly. I don't know how to solve that issue aside from pointing it out and hoping miners outside of China point to different pools and build more farms in smaller countries. Venezuela for example has cheap electricity and could be a good place to mine. Iceland too. It's interesting how realizing that the blocksize consensus limit does the opposite of what you initially thought when starting the thread didn't changed your conclusion from If you're truly worried about larger blocks causing centralization, think about how, by restricting blocksize, you're enabling the Communist Chinese government to maintain centralized control over 57% of the Bitcoin hashing power. to If you're truly worried about larger blocks causing centralization, think about how, by INCREASING blocksize, you're enabling the Communist Chinese government to POTENTIALLY INCREASE ITS centralized control over 57% of the Bitcoin hashing power. The new conclusion is just somebody should mine from Venezuela and Iceland instead. If you were so concerned about mining centralization, now that you understand how the blocksize maximum influences it (by being the only consensus rule that limits it) and if you were consequent, now you would warn about the dangers of increasing the blocksize consensus limit in this particular moment in time when mining centralization looks already really bad (ie 57% hashrate in the same jurisdiction). Another possibility is that you don't really care about mining centralization and you were only looking for an argument in favor of increasing the blocksize, which for some other reason you have already concluded that must be done as soon as possible. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Block size following technological growth
Mike's position is that he wants the block size limit to eventually be removed. That is of course an extreme view. Meanwhile, your view that the block size should be artificially constrained below the organic growth curve (in a way that will penalize a majority of existing and future users) lies at the other extreme. The majority position lies somewhere in between (i.e. a one-time increase to 8MB). This is the position that ultimately matters. If the block size is increased to 8MB and things get demonstrably a whole lot worse, then you will have a solid leg to stand on. In that case we can always do another hard fork later to reduce the block size back to something smaller, and henceforth the block size will never be touched again. On 4 August 2015 at 11:35, Jorge Timón bitcoin-dev@lists.linuxfoundation.org wrote: On Fri, Jul 31, 2015 at 4:58 PM, Mike Hearn he...@vinumeris.com wrote: How more users or more nodes can bring more miners, or more importantly, improve mining decentralization? Because the bigger the ecosystem is the more interest there is in taking part? As explained by Venzen, this is a non-sequitur. I mean, I guess I don't know how to answer your question. I don't know the answer either, that's fine. It's the opposite question that I've been insistently repeating and you've been (consciously or not) consistently evading. But that's also fine because I believe you finally answer it a few lines below. When Bitcoin was new it had almost no users and almost no miners. Now there are millions of users and factories producing ASICs just for Bitcoin. The emergence of a btc price enabled the emergence of professional miners, which in turn enabled the emergence of sha256d-specialized hardware production companies. Nothing surprising there. By no means it consitutes an example of how a bigger consensus sizes can cause less mining centralization. Surely the correlation is obvious? Correlation does not imply causation. I will better leave it at that... I'm sorry, but until there's a simulation that I can run with different sizes' testchains (for example using #6382) to somehow compare them, I will consider any value arbitrary. Gavin did run simulations. 20mb isn't arbitrary, the process behind it was well documented here: http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-centralized I chose 20MB as a reasonable block size to target because 170 gigabytes per month comfortably fits into the typical 250-300 gigabytes per month data cap– so you can run a full node from home on a “pretty good” broadband plan. Did you think 20mb was picked randomly? No, I think 20 MB was chosen very optimistically, considering 3rd party services rates (not the same service as self-hosting) in the so-called first world. And then 20 MB goes to 20 GB, again with optimistic and by no means scientific expectations. But where the number comes from it's not really what I'm demaning, what I want is some criterion that can tell you that a given size would be too centralized but another one isn't. I haven't read any analysis on why 8GB is a better option than 7GB and 9GB for a given criterion (nor one declaring 20 GB a winner over 19 GB or 21 GB). A simulation test passing 20 GB but not 21 GB would make it far less arbitrary. Agreed on the first sentence, I'm just saying that the influence of the blocksize in that function is monotonic: with bigger sizes, equal or worse mining centralization. I have a hard time agreeing with this because I've seen Bitcoin go from blocks that were often empty to blocks that are often full, and in this time the number of miners and hash power on the network has gone up a huge amount too. I'm of course talking about consensus maximum blocksize, not about actual blocksize. Yes, again, when mining becomes profitable, economic actors tend to appear and get those profits. But don't confuse total hashrate improvements with an increase in the number of miners or with mining decentralization. You can argue that a miner doesn't count if they pool mine. But if a miner mines on a pool that uses exactly the same software and settings as the miner would have done anyway, then it makes no difference. Miners can switch between pools to find one that works the way they like, so whilst less pooling or more decentralised pools would be nice (e.g. getblocktemplate), and I've written about how to push it forward before, I still say there are many more miners than in the past. If I had to pick between two changes to improve mining decentralisation: 1) Lower block size Finally, I think you finally answered my repetitive question here. If I say Mike Hearn understands that the consensus block size maximum rule is a tool for limitting mining centralization I'm not putting words in your mouth, right? I think many users advocating for an increase in the
Re: [bitcoin-dev] Block size following technological growth
On Tue, Aug 4, 2015 at 3:12 PM, Gavin Andresen gavinandre...@gmail.com wrote: On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: I would say that things already demonstrately got terrible. The mining landscape is very centralized, with apparently a majority depending on agreements to trust each other's announced blocks without validation. And that is a problem... why? If miners need to form alliances of trusting each other's blocks without validation to overcome the inefficiencies of slow block propagation, I think we have a system that is in direct conflict with the word permissionless that you use later. As Bitcoin grows, pieces of the ecosystem will specialize. Satoshi's original code did everything: hashing, block assembly, wallet, consensus, network. That is changing, and that is OK. Specialization is perfectly fine. I believe that if the above would have happened overnight, people would have cried wolf. But somehow it happened slow enough, and things kept working. I don't think that this is a good criterion. Bitcoin can work with gigabyte blocks today, if everyone uses the same few blockchain validation services, the same few online wallets, and mining is done by a cartel that only allows joining after signing a contract so they can sue you if you create an invalid block. Do you think people will then agree that things got demonstratebly worse? Don't turn Bitcoin into something uninteresting, please. Why is what you, personally, find interesting relevant? I find it interesting to build a system that has potential to bring about innovation. I understand you want to build an extremely decentralized system, where everybody participating trusts nothing except the genesis block hash. That is not true, I'm sorry if that is the impression I gave. I see centralization and scalability as a trade-off, and for better or for worse, the block chain only offers one trade-off. I want to see technology built on top that introduces lower levels of trust than typical fully centralized systems, while offering increased convenience, speed, reliability, and scale. I just don't think that all of that can happen on the lowest layer without hurting everything built on top. We need different trade-offs, and the blockchain is just one, but a very fundamental one. I think it is more interesting to build a system that works for hundreds of millions of people, with no central point of control and the opportunity for ANYBODY to participate at any level. Permission-less innovation is what I find interesting. That sounds amazing, but do you think that Bitcoin, as it exists today, can scale to hundreds of millions of users, while retaining any glimpse of permission-lessness and decentralization? I think we need low-trust off-chain systems and other innovations to make that happen. And I think the current demonstrably terrible Bitcoin system is still INCREDIBLY interesting. I'm happy for you, then. -- Pieter ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Eli Dourado on governance
On 4 August 2015 at 01:22, Gavin Andresen via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: And the preliminary results of using a prediction market to try to wrestle with the tough tradeoffs looks roughly correct to me, too: https://blocksizedebate.com/ The scicast prediction market is shutdown atm (since early July?) so those numbers aren't live. But... Network hash rate 3,255.17 PH/s (same block size) 5,032.64 PH/s (block size increase) 4,969.68 PH/s (no replace-by-fee) 3,132.09 PH/s (replace-by-fee) Those numbers seem completely implausible: that's ~2.9-3.6 doublings of the current hashrate ( 400PH/s) in 17 months, when it's taken 12 months for the last doubling, and there's a block reward reduction due in that period too. (That might've been a reasonable prediction sometime in the past year, when doublings were slowing from once every ~45 days to once a year; it just doesn't seem a supportable prediction now) That the PH/s rate is higher with bigger blocks is surprising, but given that site also predicts USD/BTC will be $280 with no change but $555 with bigger blocks, so I assume that difference is mostly due to price. Also, 12.5btc at $555 each is about 23 btc at $300 each, so if that price increase is realistic, it would compensate for almost all of the block reward reduction. Daily transaction volume 168,438.22 tx/day (same block size) 193,773.08 tx/day (block size increase) 192,603.80 tx/day (no replace-by-fee) 168,406.73 tx/day (replace-by-fee) That's only a 15% increase in transaction volume due to the block size increase; I would have expected more? 168k-194k tx/day is also only a 30%-50% increase in transaction volume from 130k tx/day currently. If that's really the case, then a 1.5MB-2MB max block size would probably be enough for the next two years... (Predicting that the node count will drop from ~5000 to ~1200 due to increasing block sizes seems quite an indictment as far as centralisation risks go; but given I'm not that convinced by the other predictions, I'm not sure I want to give that much weight to that one either) Cheers, aj -- Anthony Towns a...@erisian.com.au ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] A Transaction Fee Market Exists Without a Block Size Limit--new research paper suggests
Dear Bitcoin-Dev Mailing list, I’d like to share a research paper I’ve recently completed titled “A Transaction Fee Market Exists Without a Block Size Limit.” In addition to presenting some useful charts such as the cost to produce large spam blocks, I think the paper convincingly demonstrates that, due to the orphaning cost, a block size limit is not necessary to ensure a functioning fee market. The paper does not argue that a block size limit is unnecessary in general, and in fact brings up questions related to mining cartels and the size of the UTXO set. It can be downloaded in PDF format here: https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf Or viewed with a web-browser here: https://www.scribd.com/doc/273443462/A-Transaction-Fee-Market-Exists-Without-a-Block-Size-Limit Abstract. This paper shows how a rational Bitcoin miner should select transactions from his node’s mempool, when creating a new block, in order to maximize his profit in the absence of a block size limit. To show this, the paper introduces the block space supply curve and the mempool demand curve. The former describes the cost for a miner to supply block space by accounting for orphaning risk. The latter represents the fees offered by the transactions in mempool, and is expressed versus the minimum block size required to claim a given portion of the fees. The paper explains how the supply and demand curves from classical economics are related to the derivatives of these two curves, and proves that producing the quantity of block space indicated by their intersection point maximizes the miner’s profit. The paper then shows that an unhealthy fee market—where miners are incentivized to produce arbitrarily large blocks—cannot exist since it requires communicating information at an arbitrarily fast rate. The paper concludes by considering the conditions under which a rational miner would produce big, small or empty blocks, and by estimating the cost of a spam attack. Best regards, Peter___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Wrapping up the block size debate with voting
On 4 August 2015 at 10:03, Pieter Wuille via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: If you want to let a majority decide about economic policy of a currency, I suggest fiat currencies. They have been using this approach for quite a while, I hear. Nearly all the fiat currencies I'm familiar with have their economic policy dictated by the government or the relevant central bank committee. Ordinary users of the banking system are not consulted. Bitcoin's consensus rules are a consensus system, not a democracy. Find a solution that everyone agrees on, or don't. That's correct. The people who disagree will cease using the system, and quite possibly move to a different one (i.e. Bitcoin XT). The people left on the old system will indeed have a solution that they all can agree on. On Aug 4, 2015 9:51 AM, jl2012 via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: As now we have some concrete proposals ( https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html), I think we should wrap up the endless debate with voting by different stakeholder groups. - Candidate proposals Candidate proposals must be complete BIPs with reference implementation which are ready to merge immediately. They must first go through the usual peer review process and get approved by the developers in a technical standpoint, without political or philosophical considerations. Any fine tune of a candidate proposal may not become an independent candidate, unless it introduces some “real” difference. “No change” is also one of the voting options. - Voter groups There will be several voter groups and their votes will be counted independently. (The time frames mentioned below are just for example.) Miners: miners of blocks with timestamp between 1 to 30 Sept 2015 are eligible to vote. One block one vote. Miners will cast their votes by signing with the bitcoin address in coinbase. If there are multiple coinbase outputs, the vote is discounted by output value / total coinbase output value. Many well-known pools are reusing addresses and they may not need to digitally sign their votes. In case there is any dispute, the digitally signed vote will be counted. Bitcoin holders: People with bitcoin in the UTXO at block 372500 (around early September) are eligible to vote. The total “balance” of each scriptPubKey is calculated and this is the weight of the vote. People will cast their votes by digital signature. Special output types: Multi-sig: vote must be signed according to the setting of the multi-sig. P2SH: the serialized script must be provided Publicly known private key: not eligible to vote Non-standard script according to latest Bitcoin Core rules: not eligible to vote in general. May be judged case-by-case Developers: People with certain amount of contribution in the past year in Bitcoin Core or other open sources wallet / alternative implementations. One person one vote. Exchanges: Centralized exchanges listed on Coindesk Bitcoin Index, Winkdex, or NYSE Bitcoin index, with 30 days volume 100,000BTC are invited. This includes Bitfinex, BTC China, BitStamp, BTC-E, itBit, OKCoin, Huobi, Coinbase. Exchanges operated for at least 1 year with 100,000BTC 30-day volume may also apply to be a voter in this category. One exchange one vote. Merchants and service providers: This category includes all bitcoin accepting business that is not centralized fiat-currency exchange, e.g. virtual or physical stores, gambling sites, online wallet service, payment processors like Bitpay, decentralized exchange like Localbitcoin, ETF operators like Secondmarket Bitcoin Investment Trust. They must directly process bitcoin without relying on third party. They should process at least 100BTC in the last 30-days. One merchant one vote. Full nodes operators: People operating full nodes for at least 168 hours (1 week) in July 2015 are eligible to vote, determined by the log of Bitnodes. Time is set in the past to avoid manipulation. One IP address one vote. Vote must be sent from the node’s IP address. Voting system Single transferable vote is applied. ( https://en.wikipedia.org/wiki/Single_transferable_vote). Voters are required to rank their preference with “1”, “2”, “3”, etc, or use “N” to indicate rejection of a candidate. Vote counting starts with every voter’s first choice. The candidate with fewest votes is eliminated and those votes are transferred according to their second choice. This process repeats until only one candidate is left, which is the most popular candidate. The result is presented as the approval rate: final votes for the most popular candidate / all valid votes After the most popular candidate is determined, the whole counting process is repeated by eliminating this candidate, which will find the approval rate for the second
[bitcoin-dev] Wrapping up the block size debate with voting
As now we have some concrete proposals (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html), I think we should wrap up the endless debate with voting by different stakeholder groups. - Candidate proposals Candidate proposals must be complete BIPs with reference implementation which are ready to merge immediately. They must first go through the usual peer review process and get approved by the developers in a technical standpoint, without political or philosophical considerations. Any fine tune of a candidate proposal may not become an independent candidate, unless it introduces some “real” difference. “No change” is also one of the voting options. - Voter groups There will be several voter groups and their votes will be counted independently. (The time frames mentioned below are just for example.) Miners: miners of blocks with timestamp between 1 to 30 Sept 2015 are eligible to vote. One block one vote. Miners will cast their votes by signing with the bitcoin address in coinbase. If there are multiple coinbase outputs, the vote is discounted by output value / total coinbase output value. Many well-known pools are reusing addresses and they may not need to digitally sign their votes. In case there is any dispute, the digitally signed vote will be counted. Bitcoin holders: People with bitcoin in the UTXO at block 372500 (around early September) are eligible to vote. The total “balance” of each scriptPubKey is calculated and this is the weight of the vote. People will cast their votes by digital signature. Special output types: Multi-sig: vote must be signed according to the setting of the multi-sig. P2SH: the serialized script must be provided Publicly known private key: not eligible to vote Non-standard script according to latest Bitcoin Core rules: not eligible to vote in general. May be judged case-by-case Developers: People with certain amount of contribution in the past year in Bitcoin Core or other open sources wallet / alternative implementations. One person one vote. Exchanges: Centralized exchanges listed on Coindesk Bitcoin Index, Winkdex, or NYSE Bitcoin index, with 30 days volume 100,000BTC are invited. This includes Bitfinex, BTC China, BitStamp, BTC-E, itBit, OKCoin, Huobi, Coinbase. Exchanges operated for at least 1 year with 100,000BTC 30-day volume may also apply to be a voter in this category. One exchange one vote. Merchants and service providers: This category includes all bitcoin accepting business that is not centralized fiat-currency exchange, e.g. virtual or physical stores, gambling sites, online wallet service, payment processors like Bitpay, decentralized exchange like Localbitcoin, ETF operators like Secondmarket Bitcoin Investment Trust. They must directly process bitcoin without relying on third party. They should process at least 100BTC in the last 30-days. One merchant one vote. Full nodes operators: People operating full nodes for at least 168 hours (1 week) in July 2015 are eligible to vote, determined by the log of Bitnodes. Time is set in the past to avoid manipulation. One IP address one vote. Vote must be sent from the node’s IP address. Voting system Single transferable vote is applied. (https://en.wikipedia.org/wiki/Single_transferable_vote). Voters are required to rank their preference with “1”, “2”, “3”, etc, or use “N” to indicate rejection of a candidate. Vote counting starts with every voter’s first choice. The candidate with fewest votes is eliminated and those votes are transferred according to their second choice. This process repeats until only one candidate is left, which is the most popular candidate. The result is presented as the approval rate: final votes for the most popular candidate / all valid votes After the most popular candidate is determined, the whole counting process is repeated by eliminating this candidate, which will find the approval rate for the second most popular candidate. The process repeats until all proposals are ranked with the approval rate calculated. Interpretation of results: It is possible that a candidate with lower ranking to have higher approval rate. However, ranking is more important than the approval rate, unless the difference in approval rate is really huge. 90% support would be excellent; 70% is good; 50% is marginal; 50% is failed. Technical issues: Voting by the miners, developers, exchanges, and merchants are probably the easiest. We need a trusted person to verify the voters’ identity by email, website, or digital signature. The trusted person will collect votes and publish the named votes so anyone could verify the results. For full nodes, we need a trusted person to setup a website as an interface to vote. The votes with IP address will be published. For bitcoin holders,
Re: [bitcoin-dev] Block size following technological growth
Things apparently aren't bad enough to prevent the majority from clamoring for larger blocks. If the majority agreed that things had got worse till this point, and that this was to be blamed on the block size, they would be campaigning for the other direction. Even yourselves aren't asking for a reduction in the block size, as you know full well that you would be laughed out. On 4 August 2015 at 12:27, Pieter Wuille pieter.wui...@gmail.com wrote: I would say that things already demonstrately got terrible. The mining landscape is very centralized, with apparently a majority depending on agreements to trust each other's announced blocks without validation. Full node count is at its historically lowest value in years, and outsourcing of full validation keeps growing. I believe that if the above would have happened overnight, people would have cried wolf. But somehow it happened slow enough, and things kept working. I don't think that this is a good criterion. Bitcoin can work with gigabyte blocks today, if everyone uses the same few blockchain validation services, the same few online wallets, and mining is done by a cartel that only allows joining after signing a contract so they can sue you if you create an invalid block. Do you think people will then agree that things got demonstratebly worse? Don't turn Bitcoin into something uninteresting, please. -- Pieter On Aug 4, 2015 1:04 PM, Hector Chu via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Mike's position is that he wants the block size limit to eventually be removed. That is of course an extreme view. Meanwhile, your view that the block size should be artificially constrained below the organic growth curve (in a way that will penalize a majority of existing and future users) lies at the other extreme. The majority position lies somewhere in between (i.e. a one-time increase to 8MB). This is the position that ultimately matters. If the block size is increased to 8MB and things get demonstrably a whole lot worse, then you will have a solid leg to stand on. In that case we can always do another hard fork later to reduce the block size back to something smaller, and henceforth the block size will never be touched again. On 4 August 2015 at 11:35, Jorge Timón bitcoin-dev@lists.linuxfoundation.org wrote: On Fri, Jul 31, 2015 at 4:58 PM, Mike Hearn he...@vinumeris.com wrote: How more users or more nodes can bring more miners, or more importantly, improve mining decentralization? Because the bigger the ecosystem is the more interest there is in taking part? As explained by Venzen, this is a non-sequitur. I mean, I guess I don't know how to answer your question. I don't know the answer either, that's fine. It's the opposite question that I've been insistently repeating and you've been (consciously or not) consistently evading. But that's also fine because I believe you finally answer it a few lines below. When Bitcoin was new it had almost no users and almost no miners. Now there are millions of users and factories producing ASICs just for Bitcoin. The emergence of a btc price enabled the emergence of professional miners, which in turn enabled the emergence of sha256d-specialized hardware production companies. Nothing surprising there. By no means it consitutes an example of how a bigger consensus sizes can cause less mining centralization. Surely the correlation is obvious? Correlation does not imply causation. I will better leave it at that... I'm sorry, but until there's a simulation that I can run with different sizes' testchains (for example using #6382) to somehow compare them, I will consider any value arbitrary. Gavin did run simulations. 20mb isn't arbitrary, the process behind it was well documented here: http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-centralized I chose 20MB as a reasonable block size to target because 170 gigabytes per month comfortably fits into the typical 250-300 gigabytes per month data cap– so you can run a full node from home on a “pretty good” broadband plan. Did you think 20mb was picked randomly? No, I think 20 MB was chosen very optimistically, considering 3rd party services rates (not the same service as self-hosting) in the so-called first world. And then 20 MB goes to 20 GB, again with optimistic and by no means scientific expectations. But where the number comes from it's not really what I'm demaning, what I want is some criterion that can tell you that a given size would be too centralized but another one isn't. I haven't read any analysis on why 8GB is a better option than 7GB and 9GB for a given criterion (nor one declaring 20 GB a winner over 19 GB or 21 GB). A simulation test passing 20 GB but not 21 GB would make it far less arbitrary. Agreed on the first sentence, I'm just saying that the influence of the blocksize in that
Re: [bitcoin-dev] Wrapping up the block size debate with voting
Bitcoin's consensus rules are a consensus system What is your definition of consensus? Do you mean 100% agreement? Without a vote how do you know there is 100% (or whatever percentage) agreement? Find a solution that everyone agrees on, or don't. Who are the everyone? Pieter Wuille 於 2015-08-04 05:03 寫到: I would like to withdraw my proposal from your self-appointed vote. If you want to let a majority decide about economic policy of a currency, I suggest fiat currencies. They have been using this approach for quite a while, I hear. Bitcoin's consensus rules are a consensus system, not a democracy. Find a solution that everyone agrees on, or don't. On Aug 4, 2015 9:51 AM, jl2012 via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: As now we have some concrete proposals (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html [1]), I think we should wrap up the endless debate with voting by different stakeholder groups. - Candidate proposals Candidate proposals must be complete BIPs with reference implementation which are ready to merge immediately. They must first go through the usual peer review process and get approved by the developers in a technical standpoint, without political or philosophical considerations. Any fine tune of a candidate proposal may not become an independent candidate, unless it introduces some “real” difference. “No change” is also one of the voting options. - Voter groups There will be several voter groups and their votes will be counted independently. (The time frames mentioned below are just for example.) Miners: miners of blocks with timestamp between 1 to 30 Sept 2015 are eligible to vote. One block one vote. Miners will cast their votes by signing with the bitcoin address in coinbase. If there are multiple coinbase outputs, the vote is discounted by output value / total coinbase output value. Many well-known pools are reusing addresses and they may not need to digitally sign their votes. In case there is any dispute, the digitally signed vote will be counted. Bitcoin holders: People with bitcoin in the UTXO at block 372500 (around early September) are eligible to vote. The total “balance” of each scriptPubKey is calculated and this is the weight of the vote. People will cast their votes by digital signature. Special output types: Multi-sig: vote must be signed according to the setting of the multi-sig. P2SH: the serialized script must be provided Publicly known private key: not eligible to vote Non-standard script according to latest Bitcoin Core rules: not eligible to vote in general. May be judged case-by-case Developers: People with certain amount of contribution in the past year in Bitcoin Core or other open sources wallet / alternative implementations. One person one vote. Exchanges: Centralized exchanges listed on Coindesk Bitcoin Index, Winkdex, or NYSE Bitcoin index, with 30 days volume 100,000BTC are invited. This includes Bitfinex, BTC China, BitStamp, BTC-E, itBit, OKCoin, Huobi, Coinbase. Exchanges operated for at least 1 year with 100,000BTC 30-day volume may also apply to be a voter in this category. One exchange one vote. Merchants and service providers: This category includes all bitcoin accepting business that is not centralized fiat-currency exchange, e.g. virtual or physical stores, gambling sites, online wallet service, payment processors like Bitpay, decentralized exchange like Localbitcoin, ETF operators like Secondmarket Bitcoin Investment Trust. They must directly process bitcoin without relying on third party. They should process at least 100BTC in the last 30-days. One merchant one vote. Full nodes operators: People operating full nodes for at least 168 hours (1 week) in July 2015 are eligible to vote, determined by the log of Bitnodes. Time is set in the past to avoid manipulation. One IP address one vote. Vote must be sent from the node’s IP address. Voting system Single transferable vote is applied. (https://en.wikipedia.org/wiki/Single_transferable_vote [2]). Voters are required to rank their preference with “1”, “2”, “3”, etc, or use “N” to indicate rejection of a candidate. Vote counting starts with every voter’s first choice. The candidate with fewest votes is eliminated and those votes are transferred according to their second choice. This process repeats until only one candidate is left, which is the most popular candidate. The result is presented as the approval rate: final votes for the most popular candidate / all valid votes After the most popular candidate is determined, the whole counting process is repeated by eliminating this candidate, which will find the approval rate for the second most popular candidate. The process repeats until all proposals are ranked with the approval rate calculated. Interpretation of results: It is possible that a candidate with lower ranking
Re: [bitcoin-dev] Block size following technological growth
On 4 August 2015 at 14:13, Jorge Timón jti...@jtimon.cc wrote: 2) It doesn't matter who is to blame about the current centralization: the fact remains that the blocksize maximum is the only** consensus rule to limit mining centralization. Repeating a claim ad-nauseum doesn't make it necessarily true. A block size limit won't prevent miners in the future from buying each other out. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Block size following technological growth
On Tue, Aug 4, 2015 at 2:19 PM, Hector Chu hector...@gmail.com wrote: On 4 August 2015 at 12:59, Jorge Timón jti...@jtimon.cc wrote: That is not my position. Again, I don't know what the right blocksize for the short term is (I don't think anybody does). You have no position (i.e. neutral). In other words, keeping the existing limit. No, I think 1 MB is just as arbitrary as any other size proposed. All I want is for consensus change proponents to try harder to convince other users (including me) Therefore how the change can affect mining centralization must be the main concern, instead of (also artificial) projections about usage growth (no matter how organic their curves look). The degree of mining decentralization is only one of many concerns. Users' main concern is timely confirmation of low-fee transactions. Miners' concern is the amount of profit they make. No, if the changed rule only serves to limit centralization, then how that limitation to centralization is affected should be the first thing to consider. If miners' concern was only the amount of profit they make they wouldn't mine free transactions already. You cannot possibly know what all users' are concern about, so I will just ignore any further claim in that direction. Talk for yourself: your arguments won't be more reasonable just because you claim that all users think like you do. Also I don't think hitting the limit must be necessarily harmful and if it is, I don't understand why hitting it at 1MB will be more harmful than hitting it at 2MB, 8MB or 8GB. The limit won't even get to be hit, because all the users that get thrown out of Bitcoin will have moved over to a system supporting a larger block size. I disagree with this wild prediction as well. I don't know where you get your majority from or what it even means (majority of users, majority of the coins, of miners?) The majority which the miners are beholden to is the economic majority. https://en.bitcoin.it/wiki/Economic_majority And I assume the way that vaguely defined economic majority communicates with you through a crystal ball or something But there's something I'm missing something there...why my position doesn't matter if it's not a majority? Your position is only one of many and it does not carry excess weight to the others. Individually it won't matter, because you can't control the implementation that other people run. No more, but not less either. Nobody can't control the implementation that I (or other people concerned with centralization) run either. How is what the the majority has been told it's best an objective argument? Don't fight the market. The way the system is designed, the miners will follow along with what the economic majority have decided. How is allowing fees from rising above zero fighting the market? The system is currently designed with a 1 MB limit. I don't think that's sacred or anything, but I really don't feel like I'm fighting the market or the way the system is designed. In any case, what do the market and the way the system is designed have to do with what the majority have been told it's best (which you seem to think should be a source of truth for some reason I'm still missing)? So if you say 8, I must ask, why not 9? Why 9 MB is not safe for mining centralization but 8 MB is? 8MB has simply been the focal point for this debate. 9MB is also safe if 8MB is, but I suppose the opponents will be even less happy with 9 than with 8, and we don't want to unnecessarily increase the conflict. Why 9 MB is safe but 10 MB isn't? The conflict won't be resolved by evading hard questions... It seems like the rationale it's always the bigger the better and the only limitation is what a few people concerned with mining centralization (while they still have time to discuss this) are willing to accept. If that's the case, then there won't be effectively any limit in the long term and Bitcoin will probably fail in its decentralization goals. A one-time increase to 8MB is safer than a dynamically growing limit over time for exactly this reason. Admittedly whenever the next debate to increase the block size over 8MB happens it will be even more painful and non-obvious, but that is the safety check to prevent unbounded block size increase. Will there ever be a debate that results in further blocksize increases at this point are very risky for mining centralization? How will we tell then? Can't we use the same criteria now? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Block size following technological growth
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/04/2015 08:28 PM, Hector Chu via bitcoin-dev wrote: On 4 August 2015 at 14:13, Jorge Timón jti...@jtimon.cc mailto:jti...@jtimon.cc wrote: 2) It doesn't matter who is to blame about the current centralization: the fact remains that the blocksize maximum is the only** consensus rule to limit mining centralization. Repeating a claim ad-nauseum doesn't make it necessarily true. A block size limit won't prevent miners in the future from buying each other out. It plays both ways, the technical list requires a proof of concept and simulation upon which to base judgment going forward, else we'll just be talking out our backsides (like certain people) without making any progress. The tools for simulation exist: Jorge Timon created a variable blocksize regtest PR here: https://github.com/bitcoin/bitcoin/pull/6382 No-one needs to postulate what different blocksizes imply - anyone can run a simulation and demonstrate what they're talking about. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVwMFEAAoJEGwAhlQc8H1mo/EH/2USw5YUL/7sgFAsjpXdpcS+ 9XZ0M0AK4PNSo36GBBhjaF9rRa76FtK6Vt9nLe+7lgYmeHSkcQ65OLKfP47hCnsz 9XfVR0n7nv+0TqHQKPcjm+WNBoVndKRHGEwNQoQw//bAmO4LOcmQCMXAkk9RfaKm 4olay0nUmAFNqh/7wVOunOUFMJNIRpy/neAlFYxRAHBIJLcc0KQNiLqAHbzwPDZq e9kLjtIusWwLUCgHFvox01bIEOx+VYIxzjMVRz1MNGyRGwDweg7zk54WA48nYwmx 70Ggdde9kiLytPDwB2ey/IRE4mv/4KS2zivJy36XAsjPExTNeGKxGeGfBqXNwSI= =aya4 -END PGP SIGNATURE- ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Fwd: Re: Block size following technological growth
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 correction: My finance readers, in one camp, and Bitcoin investors, in the other, want to see the XT 8MB hard-fork testing data that you mentioned for BIP101 (not 100). - Forwarded Message Subject: Re: [bitcoin-dev] Block size following technological growth Date: Tue, 04 Aug 2015 21:30:40 +0700 From: Venzen Khaosan via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org Reply-To: ven...@mail.bihthai.net Organization: Bihthai Bai Mai To: Gavin Andresen gavinandre...@gmail.com, Bitcoin Dev bitcoin-dev@lists.linuxfoundation.org On 08/04/2015 08:12 PM, Gavin Andresen via bitcoin-dev wrote: On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org mailto:bitcoin-dev@lists.linuxfoundation.org wrote: I would say that things already demonstrately got terrible. The mining landscape is very centralized, with apparently a majority depending on agreements to trust each other's announced blocks without validation. And that is a problem... why? As far as I can tell, [snip] It's a big problem. What are you dismissing it for? With Bitcoin in fledgling 0.x version state this is neither desirable nor encouraging. Development did not freeze at some time in the past and now we see how the userbase reacts. Miners, btw, are arguibly still a class of user as long as they are guaranteed coinbase. When they start making and proving themselves useful in a free floating fee market absent coinbase subsidy, we can revisit this topic, with the benefit of hindsight. As Bitcoin grows, pieces of the ecosystem will specialize. Satoshi's original code did everything: hashing, block assembly, wallet, consensus, network. That is changing, and that is OK. [snip] And I think the current demonstrably terrible Bitcoin system is still INCREDIBLY interesting. Pieter never said it wasn't interesting, so this emphatic statement is strange - like someone is trying to convince an audience - but anyway... as you, a veritable spring-chicken by your actions and words, said the other day: having graduated in '88 you're old and speak from experience. Don't come with that jive, bossy man - bring facts and testing to the technical list. My finance readers, in one camp, and Bitcoin investors, in the other, want to see the XT 8MB hard-fork testing data that you mentioned for BIP100. Being ignorant is not so much a shame, as being unwilling to learn. - - Benjamin Franklin -- -- Gavin Andresen Venzen Khaosan ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVwM93AAoJEGwAhlQc8H1mwcEH/RwxpWyvjlWBrPok5GNRed+/ 8O46a4G1T6+Y2+yKWDFQTqG0D2oFEqunHW1A+e7UYABrhijbr1Xwpv0Y//VSuY3p TnRXPj3+q3j4BdB607y5i0jCo61G4IrXaCUEHpBMzrD5T7SMDC1a31FLgAjx9WDM etKmT9doWn9aiWzxAl/q8SEY4M04RLyS5kijs95M9YMGp1KVw2jNDfJM37EhPDu2 qDUMQEvcq0qTPCeHn6tCaXC0rWzIpylE6Xaso3VMepmbdzf0Dea92asBmmE0ygsW Tcfx95UWW+Bb/h2JEO3TCjKpLCwdfiWP/2eXIMKkcdSJIVf/yE32gIxzqPx5ogU= =BwgG -END PGP SIGNATURE- ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Block size following technological growth
On Tue, Aug 4, 2015 at 9:12 AM, Gavin Andresen via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: I would say that things already demonstrately got terrible. The mining landscape is very centralized, with apparently a majority depending on agreements to trust each other's announced blocks without validation. And that is a problem... why? As far as I can tell, nobody besides miners running old and/or buggy software lost money due to outsourced mining validation (please correct me if I'm wrong-- I'm looking forward to Greg's post-mortem). The operators of bitcoin.org seem to have freaked out and pushed the panic button (with dire warnings of not trusting transactions until 20 confirmations), but theymos was well known for using an old, patched version of Core for blockexplorer.com so maybe that's not surprising. I'm also looking forward to Greg's post-mortem, because I had a completely different takeaway from the BIP66 mini-forks. My view is that despite the extremely cautious and conservative planning for the completely uncontentious fork, the damage could and would have been very significant if it had not been for several core devs manually monitoring, intervening and problem solving for other network participants. I don't believe thats the way the system should work. Participants in the Bitcoin community have come to rely on the devs for just making sure everything works for them. That's not sustainable. The system needs to be made fundamentally more secure if its going to succeed, not depend on the good will of any particular parties, otherwise it certainly will no longer be permissionless. The BIP66 fork was urgently required to fix an undisclosed consensus bug, unanimously agreed on and without technical objection, and it was still fraught with problems. That's the most clear cut example of when we should have a fork. A change to a consensus limit that a significant proportion of the community disagrees with for economic or technical reasons or both should be raising a sea of red flags. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Block size following technological growth
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/04/2015 08:12 PM, Gavin Andresen via bitcoin-dev wrote: On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org mailto:bitcoin-dev@lists.linuxfoundation.org wrote: I would say that things already demonstrately got terrible. The mining landscape is very centralized, with apparently a majority depending on agreements to trust each other's announced blocks without validation. And that is a problem... why? As far as I can tell, [snip] It's a big problem. What are you dismissing it for? With Bitcoin in fledgling 0.x version state this is neither desirable nor encouraging. Development did not freeze at some time in the past and now we see how the userbase reacts. Miners, btw, are arguibly still a class of user as long as they are guaranteed coinbase. When they start making and proving themselves useful in a free floating fee market absent coinbase subsidy, we can revisit this topic, with the benefit of hindsight. As Bitcoin grows, pieces of the ecosystem will specialize. Satoshi's original code did everything: hashing, block assembly, wallet, consensus, network. That is changing, and that is OK. [snip] And I think the current demonstrably terrible Bitcoin system is still INCREDIBLY interesting. Pieter never said it wasn't interesting, so this emphatic statement is strange - like someone is trying to convince an audience - but anyway... as you, a veritable spring-chicken by your actions and words, said the other day: having graduated in '88 you're old and speak from experience. Don't come with that jive, bossy man - bring facts and testing to the technical list. My finance readers, in one camp, and Bitcoin investors, in the other, want to see the XT 8MB hard-fork testing data that you mentioned for BIP100. Being ignorant is not so much a shame, as being unwilling to learn. - - Benjamin Franklin -- -- Gavin Andresen Venzen Khaosan -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVwMyOAAoJEGwAhlQc8H1mho4IAKEHVxE4lAs3aIoLXa2fxLP8 3q7MhfM5vIW9QAM7rjz8YzheMg3Wj2CNfZPuUV7YDTVrLZPrIN/aMY6CIftr7GUS pjMI9nnwezFwYX5oyRU+gW51AMFhvexV6ITZYpiLRtWHgK1FZtXWMG13eO/6Jb5U Wjflub7suMDvg+ST2PplhQf7fFmnPHrLZg3ISDqK+hvgw20geW1rXC/wCChlewfd DqSt9fxqs+NIvbIzS2TgLTkIcHlbKNeI5AeqbaFoaIQtvYALD3Ojt2I/qoCJU1za rB8Il7UK0B5uf6xxgErGcYAHzjVpR6Zhsdzo6MiBF1j4ClfNPEQAlG49YjrRXpI= =4nai -END PGP SIGNATURE- ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Wrapping up the block size debate with voting
I would like to withdraw my proposal from your self-appointed vote. If you want to let a majority decide about economic policy of a currency, I suggest fiat currencies. They have been using this approach for quite a while, I hear. Bitcoin's consensus rules are a consensus system, not a democracy. Find a solution that everyone agrees on, or don't. On Aug 4, 2015 9:51 AM, jl2012 via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: As now we have some concrete proposals ( https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html), I think we should wrap up the endless debate with voting by different stakeholder groups. - Candidate proposals Candidate proposals must be complete BIPs with reference implementation which are ready to merge immediately. They must first go through the usual peer review process and get approved by the developers in a technical standpoint, without political or philosophical considerations. Any fine tune of a candidate proposal may not become an independent candidate, unless it introduces some “real” difference. “No change” is also one of the voting options. - Voter groups There will be several voter groups and their votes will be counted independently. (The time frames mentioned below are just for example.) Miners: miners of blocks with timestamp between 1 to 30 Sept 2015 are eligible to vote. One block one vote. Miners will cast their votes by signing with the bitcoin address in coinbase. If there are multiple coinbase outputs, the vote is discounted by output value / total coinbase output value. Many well-known pools are reusing addresses and they may not need to digitally sign their votes. In case there is any dispute, the digitally signed vote will be counted. Bitcoin holders: People with bitcoin in the UTXO at block 372500 (around early September) are eligible to vote. The total “balance” of each scriptPubKey is calculated and this is the weight of the vote. People will cast their votes by digital signature. Special output types: Multi-sig: vote must be signed according to the setting of the multi-sig. P2SH: the serialized script must be provided Publicly known private key: not eligible to vote Non-standard script according to latest Bitcoin Core rules: not eligible to vote in general. May be judged case-by-case Developers: People with certain amount of contribution in the past year in Bitcoin Core or other open sources wallet / alternative implementations. One person one vote. Exchanges: Centralized exchanges listed on Coindesk Bitcoin Index, Winkdex, or NYSE Bitcoin index, with 30 days volume 100,000BTC are invited. This includes Bitfinex, BTC China, BitStamp, BTC-E, itBit, OKCoin, Huobi, Coinbase. Exchanges operated for at least 1 year with 100,000BTC 30-day volume may also apply to be a voter in this category. One exchange one vote. Merchants and service providers: This category includes all bitcoin accepting business that is not centralized fiat-currency exchange, e.g. virtual or physical stores, gambling sites, online wallet service, payment processors like Bitpay, decentralized exchange like Localbitcoin, ETF operators like Secondmarket Bitcoin Investment Trust. They must directly process bitcoin without relying on third party. They should process at least 100BTC in the last 30-days. One merchant one vote. Full nodes operators: People operating full nodes for at least 168 hours (1 week) in July 2015 are eligible to vote, determined by the log of Bitnodes. Time is set in the past to avoid manipulation. One IP address one vote. Vote must be sent from the node’s IP address. Voting system Single transferable vote is applied. ( https://en.wikipedia.org/wiki/Single_transferable_vote). Voters are required to rank their preference with “1”, “2”, “3”, etc, or use “N” to indicate rejection of a candidate. Vote counting starts with every voter’s first choice. The candidate with fewest votes is eliminated and those votes are transferred according to their second choice. This process repeats until only one candidate is left, which is the most popular candidate. The result is presented as the approval rate: final votes for the most popular candidate / all valid votes After the most popular candidate is determined, the whole counting process is repeated by eliminating this candidate, which will find the approval rate for the second most popular candidate. The process repeats until all proposals are ranked with the approval rate calculated. Interpretation of results: It is possible that a candidate with lower ranking to have higher approval rate. However, ranking is more important than the approval rate, unless the difference in approval rate is really huge. 90% support would be excellent; 70% is good; 50% is marginal; 50% is failed.
Re: [bitcoin-dev] Wrapping up the block size debate with voting
As I mentioned, the candidate proposals must go through usual peer review process, which includes proper testing, I assume. Scaling down is always possible with softforks, or miners will simply produce smaller blocks. BIP100 has a scaling down mechanism but it still requires miners to vote so it doesn't really make much difference But anyway, this is off-topic, as candidate proposals may include mechanism for scaling down. Venzen Khaosan 於 2015-08-04 05:23 寫到: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It is not scientific or sensible to go from proposal stage straight to voting and then implementation stage. The proposals you have diligently gathered, summarized and presented in your document must go through testing, and scenario simulation with published results, in order for objective evaluation to be made possible. For that matter, even running up against a capacity limit has not been simulated or tested. Additionally, (and looking the other way) there is a lack of provision for scaling DOWN in the current proposals - - hard to envision, yes - but what goes up will eventually come down. A global credit contraction is not unlikely, nor is natural disaster, and these scenarios have implications for usage, scale, degree of decentralization and security. CS is science, there is no reason for this generation not to apply rigorous Computer Science to Bitcoin. Venzen On 08/04/2015 02:50 PM, jl2012 via bitcoin-dev wrote: As now we have some concrete proposals (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html), I think we should wrap up the endless debate with voting by different stakeholder groups. - Candidate proposals Candidate proposals must be complete BIPs with reference implementation which are ready to merge immediately. They must first go through the usual peer review process and get approved by the developers in a technical standpoint, without political or philosophical considerations. Any fine tune of a candidate proposal may not become an independent candidate, unless it introduces some “real” difference. “No change” is also one of the voting options. - Voter groups There will be several voter groups and their votes will be counted independently. (The time frames mentioned below are just for example.) Miners: miners of blocks with timestamp between 1 to 30 Sept 2015 are eligible to vote. One block one vote. Miners will cast their votes by signing with the bitcoin address in coinbase. If there are multiple coinbase outputs, the vote is discounted by output value / total coinbase output value. Many well-known pools are reusing addresses and they may not need to digitally sign their votes. In case there is any dispute, the digitally signed vote will be counted. Bitcoin holders: People with bitcoin in the UTXO at block 372500 (around early September) are eligible to vote. The total “balance” of each scriptPubKey is calculated and this is the weight of the vote. People will cast their votes by digital signature. Special output types: Multi-sig: vote must be signed according to the setting of the multi-sig. P2SH: the serialized script must be provided Publicly known private key: not eligible to vote Non-standard script according to latest Bitcoin Core rules: not eligible to vote in general. May be judged case-by-case Developers: People with certain amount of contribution in the past year in Bitcoin Core or other open sources wallet / alternative implementations. One person one vote. Exchanges: Centralized exchanges listed on Coindesk Bitcoin Index, Winkdex, or NYSE Bitcoin index, with 30 days volume 100,000BTC are invited. This includes Bitfinex, BTC China, BitStamp, BTC-E, itBit, OKCoin, Huobi, Coinbase. Exchanges operated for at least 1 year with 100,000BTC 30-day volume may also apply to be a voter in this category. One exchange one vote. Merchants and service providers: This category includes all bitcoin accepting business that is not centralized fiat-currency exchange, e.g. virtual or physical stores, gambling sites, online wallet service, payment processors like Bitpay, decentralized exchange like Localbitcoin, ETF operators like Secondmarket Bitcoin Investment Trust. They must directly process bitcoin without relying on third party. They should process at least 100BTC in the last 30-days. One merchant one vote. Full nodes operators: People operating full nodes for at least 168 hours (1 week) in July 2015 are eligible to vote, determined by the log of Bitnodes. Time is set in the past to avoid manipulation. One IP address one vote. Vote must be sent from the node’s IP address. Voting system Single transferable vote is applied. (https://en.wikipedia.org/wiki/Single_transferable_vote). Voters are required to rank their preference with “1”, “2”, “3”, etc, or use “N” to indicate rejection of a candidate. Vote counting starts with every voter’s first
Re: [bitcoin-dev] Block size following technological growth
On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: I would say that things already demonstrately got terrible. The mining landscape is very centralized, with apparently a majority depending on agreements to trust each other's announced blocks without validation. And that is a problem... why? As far as I can tell, nobody besides miners running old and/or buggy software lost money due to outsourced mining validation (please correct me if I'm wrong-- I'm looking forward to Greg's post-mortem). The operators of bitcoin.org seem to have freaked out and pushed the panic button (with dire warnings of not trusting transactions until 20 confirmations), but theymos was well known for using an old, patched version of Core for blockexplorer.com so maybe that's not surprising. As Bitcoin grows, pieces of the ecosystem will specialize. Satoshi's original code did everything: hashing, block assembly, wallet, consensus, network. That is changing, and that is OK. I understand there are parts of the ecosystem you'd rather not see specialized, like transaction selection / block assembly or validation. I see it as a natural maturation. The only danger I see is if some unnatural barriers to competition spring up. Full node count is at its historically lowest value in years, and outsourcing of full validation keeps growing. Both side effects of increasing specialization, in my opinion. Many companies quite reasonably would rather hire somebody who specializes in running nodes, keeping keys secure, etc rather than develop that expertise themselves. Again, not a problem UNLESS some unnatural barriers to competition spring up. I believe that if the above would have happened overnight, people would have cried wolf. But somehow it happened slow enough, and things kept working. I don't think that this is a good criterion. Bitcoin can work with gigabyte blocks today, if everyone uses the same few blockchain validation services, the same few online wallets, and mining is done by a cartel that only allows joining after signing a contract so they can sue you if you create an invalid block. Do you think people will then agree that things got demonstratebly worse? Don't turn Bitcoin into something uninteresting, please. Why is what you, personally, find interesting relevant? I understand you want to build an extremely decentralized system, where everybody participating trusts nothing except the genesis block hash. I think it is more interesting to build a system that works for hundreds of millions of people, with no central point of control and the opportunity for ANYBODY to participate at any level. Permission-less innovation is what I find interesting. And I think the current demonstrably terrible Bitcoin system is still INCREDIBLY interesting. -- -- Gavin Andresen ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Block size following technological growth
On Tue, Aug 4, 2015 at 1:34 PM, Hector Chu hector...@gmail.com wrote: Things apparently aren't bad enough to prevent the majority from clamoring for larger blocks. Nobody is preventing anyone from claiming anything. Some developers are encouraging users to ask for bigger blocks. Others don't want to impose consensus rule changes against the will of the users (even if they're 10% of the users). Still, Things apparently aren't bad enough is just your opinion. If the majority agreed that things had got worse till this point, and that this was to be blamed on the block size, they would be campaigning for the other direction. Even yourselves aren't asking for a reduction in the block size, as you know full well that you would be laughed out. 1) I don't care what the so-called majority thinks: I don't want to impose consensus rule changes against the will of a reasonable minority. 2) It doesn't matter who is to blame about the current centralization: the fact remains that the blocksize maximum is the only** consensus rule to limit mining centralization. 3) In fact I think Luke Dashjr proposed to reduced it to 400 KB, but I would ask the same thing: please create a simulation in which the change is better (or at least no much worse) than the current rules by ANY metric. Please read the point 2 with special attention because it's not the first time I say this in this thread. ** There's also the maximum block sigops consensus rule to limit mining centralization. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Block size following technological growth
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/04/2015 06:34 PM, Hector Chu via bitcoin-dev wrote: Things apparently aren't bad enough to prevent the majority from clamoring for larger blocks. If the majority agreed that things had got worse till this point, and that this was to be blamed on the block size, they would be campaigning for the other direction. Even yourselves aren't asking for a reduction in the block size, as you know full well that you would be laughed out. Hector, if you could provide data that convinces why 8MB is better than 6.18MB or 1MB then we'd get out of the realm of opinion and pointless rhetoric that threatens to keep this debate in a quagmire. We'd have actual figures to work with and projections to go by. But fetching majority agreement (where from?) does not cut it for setting Bitcoin on a future path. If we go by that then we'd soon be giving coinbase rewards to users for being loyal supporters because, as a majority, they think that's what they'd like to see. If a proposal is demonstrably, and provably, a good idea - and a developer consensus agrees - then it should go to testing, and eventually, code. Other than that it's just conjecture and words without a research paper and data. In the final analysis, do we want Bitcoin to be steered by an uninformed and fickle majority, or do we want to use this list as a forum to present research proposals containing repeatable, verifiable facts? A progressive process of convincing those most familiar with Bitcoin's code and operation so they may implement Good Ideas during the next century and after is surely preferable to Vote-my-code-Coin. :) On 4 August 2015 at 12:27, Pieter Wuille pieter.wui...@gmail.com mailto:pieter.wui...@gmail.com wrote: I would say that things already demonstrately got terrible. The mining landscape is very centralized, with apparently a majority depending on agreements to trust each other's announced blocks without validation. Full node count is at its historically lowest value in years, and outsourcing of full validation keeps growing. I believe that if the above would have happened overnight, people would have cried wolf. But somehow it happened slow enough, and things kept working. I don't think that this is a good criterion. Bitcoin can work with gigabyte blocks today, if everyone uses the same few blockchain validation services, the same few online wallets, and mining is done by a cartel that only allows joining after signing a contract so they can sue you if you create an invalid block. Do you think people will then agree that things got demonstratebly worse? Don't turn Bitcoin into something uninteresting, please. -- Pieter On Aug 4, 2015 1:04 PM, Hector Chu via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org mailto:bitcoin-dev@lists.linuxfoundation.org wrote: Mike's position is that he wants the block size limit to eventually be removed. That is of course an extreme view. Meanwhile, your view that the block size should be artificially constrained below the organic growth curve (in a way that will penalize a majority of existing and future users) lies at the other extreme. The majority position lies somewhere in between (i.e. a one-time increase to 8MB). This is the position that ultimately matters. If the block size is increased to 8MB and things get demonstrably a whole lot worse, then you will have a solid leg to stand on. In that case we can always do another hard fork later to reduce the block size back to something smaller, and henceforth the block size will never be touched again. On 4 August 2015 at 11:35, Jorge Timón bitcoin-dev@lists.linuxfoundation.org mailto:bitcoin-dev@lists.linuxfoundation.org wrote: On Fri, Jul 31, 2015 at 4:58 PM, Mike Hearn he...@vinumeris.com mailto:he...@vinumeris.com wrote: How more users or more nodes can bring more miners, or more importantly, improve mining decentralization? Because the bigger the ecosystem is the more interest there is in taking part? As explained by Venzen, this is a non-sequitur. I mean, I guess I don't know how to answer your question. I don't know the answer either, that's fine. It's the opposite question that I've been insistently repeating and you've been (consciously or not) consistently evading. But that's also fine because I believe you finally answer it a few lines below. When Bitcoin was new it had almost no users and almost no miners. Now there are millions of users and factories producing ASICs just for Bitcoin. The emergence of a btc price enabled the emergence of professional miners, which in turn enabled the emergence of sha256d-specialized hardware production companies. Nothing surprising there. By no means it consitutes an example of how a bigger consensus sizes can cause less mining centralization. Surely the correlation is obvious? Correlation does not imply causation. I
Re: [bitcoin-dev] Block size following technological growth
On 4 August 2015 at 12:59, Jorge Timón jti...@jtimon.cc wrote: That is not my position. Again, I don't know what the right blocksize for the short term is (I don't think anybody does). You have no position (i.e. neutral). In other words, keeping the existing limit. Therefore how the change can affect mining centralization must be the main concern, instead of (also artificial) projections about usage growth (no matter how organic their curves look). The degree of mining decentralization is only one of many concerns. Users' main concern is timely confirmation of low-fee transactions. Miners' concern is the amount of profit they make. Also I don't think hitting the limit must be necessarily harmful and if it is, I don't understand why hitting it at 1MB will be more harmful than hitting it at 2MB, 8MB or 8GB. The limit won't even get to be hit, because all the users that get thrown out of Bitcoin will have moved over to a system supporting a larger block size. I don't know where you get your majority from or what it even means (majority of users, majority of the coins, of miners?) The majority which the miners are beholden to is the economic majority. https://en.bitcoin.it/wiki/Economic_majority But there's something I'm missing something there...why my position doesn't matter if it's not a majority? Your position is only one of many and it does not carry excess weight to the others. Individually it won't matter, because you can't control the implementation that other people run. How is what the the majority has been told it's best an objective argument? Don't fight the market. The way the system is designed, the miners will follow along with what the economic majority have decided. So if you say 8, I must ask, why not 9? Why 9 MB is not safe for mining centralization but 8 MB is? 8MB has simply been the focal point for this debate. 9MB is also safe if 8MB is, but I suppose the opponents will be even less happy with 9 than with 8, and we don't want to unnecessarily increase the conflict. It seems like the rationale it's always the bigger the better and the only limitation is what a few people concerned with mining centralization (while they still have time to discuss this) are willing to accept. If that's the case, then there won't be effectively any limit in the long term and Bitcoin will probably fail in its decentralization goals. A one-time increase to 8MB is safer than a dynamically growing limit over time for exactly this reason. Admittedly whenever the next debate to increase the block size over 8MB happens it will be even more painful and non-obvious, but that is the safety check to prevent unbounded block size increase. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] A Transaction Fee Market Exists Without a Block Size Limit--new research paper suggests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 4 August 2015 17:30:28 GMT-04:00, Gavin Andresen via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: On Tue, Aug 4, 2015 at 2:41 PM, Dave Hudson via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Fundamentally a block maker (pool or aggregation of pools) does not orphan its own blocks. Unless the block maker has an infinitely fast connection to it's hashpower OR it's hashpower is not parallelized at all, that's not strictly true -- it WILL orphan its own blocks because two hashing units will find solutions in the time it takes to communicate that solution to the block maker and to the rest of the hashing units. That's getting into how many miners can dance on the head of a pin territory, though. I don't think we know whether the communication advantages of putting lots of hashing power physically close together will outweigh the extra cooling costs of doing that (or maybe some other tradeoff I haven't thought of). That would be a fine topic for another paper I'd suggest you do more research into how Bitcoin and mining works as the above has a number of serious misunderstandings. Or, I could just point out the obvious rather than try to be polite: you know exactly why the above makes no sense as a reply to this thread and are deliberately lying. If the situation is the latter, your conduct is toxic to the development mailing list discussion, not to mention a waste of all our time, and you should leave. -BEGIN PGP SIGNATURE- iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVwTKi AAoJEMCF8hzn9Lnc47AH/0txNyw9dLdsfQOsNE14jLEcQifxOkaKLqTJV1O4gn6O L4+T6rPo9pVLTBuVWcsm2A24R/gBL+pYaWgaIyk/3fbSRpg4GfVau0xxh54vQU6m U4L7FPHsdZ2y67frv/+5ExJ2xrVuedhpTciTi2SqSE6C0fioO+YarH0Dvd8I5Wjx f9GnmxLdKytoj2kUaoriSSxsUzMNzxVzq78jEmhMR85TGy73ApeLdgBC/pdNgxZa oAQ0CXCMYgsE59HUOO05xFLazGxNh2epPADTbTTgoNQ9py38evlW254okhRmk9p9 v4i1yTzuv/Y6C0qw2RZcEiT/GTdvajkMKCidLEm3LbY= =W/Ke -END PGP SIGNATURE- ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] A Transaction Fee Market Exists Without a Block Size Limit--new research paper suggests
On 4 Aug 2015, at 14:30, Gavin Andresen gavinandre...@gmail.com wrote: On Tue, Aug 4, 2015 at 2:41 PM, Dave Hudson via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org mailto:bitcoin-dev@lists.linuxfoundation.org wrote: Fundamentally a block maker (pool or aggregation of pools) does not orphan its own blocks. Unless the block maker has an infinitely fast connection to it's hashpower OR it's hashpower is not parallelized at all, that's not strictly true -- it WILL orphan its own blocks because two hashing units will find solutions in the time it takes to communicate that solution to the block maker and to the rest of the hashing units. That's getting into how many miners can dance on the head of a pin territory, though. I don't think we know whether the communication advantages of putting lots of hashing power physically close together will outweigh the extra cooling costs of doing that (or maybe some other tradeoff I haven't thought of). That would be a fine topic for another paper Yes, but the block maker won't publish the second block it finds for the same set of transactions. It won't orphan its own block. In fact even if it does it still doesn't matter because the block maker still gets the block reward irrespective of which of the two solutions are published. It's not about which hash wins, the issue is who gets paid as a result. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Consensus fork activation thresholds: Block.nTime vs median time vs block.nHeight
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 4 August 2015 16:02:53 GMT-04:00, Jorge Timón via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: One thing I've noticed there seems to be disagreement on is whether miners' upgrade confirmation (aka voting) is necessary for uncontroversial hardforks or not. To be clear, without a strong supermajority of miner support the fork risks attack. Requiring 95% approval - which is actually just a 50% majority vote as the majority can squelch the minority - is an obvious minimum safety requirement. Another option is Hearn's proposal of using centralised checkpoints to override PoW consensus; obviously that raises serious questions, including legal issues. For forks without miner approval miners have a number of options to defeat them. For instance, they can make their own fork with a new consensus algorithm that requires miners to prove they're attacking the unwanted chain - Garzik's recent 2MB blocks proposal is a hilarious, and probably accidental, example of such a design, with the original Bitcoin protocol rules having the effect of attacking the Garzik 2MB chain. -BEGIN PGP SIGNATURE- iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVwS7F AAoJEMCF8hzn9Lnc47AH/3926JLE4Rn9Fil+wvfxhfmBqIm0wtfStPDAqsQMDIbh kbxOw/Mai/AbqNUkYUWvoM2ZfJ/JNkA6HA977CE6huT1ozYVz8TJQmcqN/p1QXfX w1559UsXXop2fepY1dbnyBUwB6w6VwBrfj3awYkJsblgcdHrEsAesYeAHphAkwL/ kxQ0b+QmttaDCSK76hNloKVcN7AczdCSw1pux2rzmsG9zkwWJrIqR/prAO1nuk9Y LgQUCvYkZiMmMD8kNx9ZVRG2Y951uLS6594Qy6ZoAMAdA6QxNsP4qyE7s8M2HAon WjdS0UqTRyJuDVqpNav6WX4jTllK/UuHRUAOmBmYaRs= =0cKq -END PGP SIGNATURE- ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP65 / CHECKLOCKTIMEVERIFY deployment
On Sun, Jun 28, 2015 at 9:50 PM, Peter Todd p...@petertodd.org wrote: On Thu, Jun 25, 2015 at 06:33:44PM -0400, Peter Todd wrote: Thoughts? If there are no objections I'll go ahead and write that code, using the same thresholds as BIP66. I've opened a pull-req to deploy CHECKLOCKTIMEVERIFY via the IsSuperMajority() mechanism: https://github.com/bitcoin/bitcoin/pull/6351 Final step towards CLTV deployment on mainnet. I've copied the logic and tests from the previous BIP66 (DERSIG) soft-fork line-by-line for ease of review; any code review applicable to BIP66 should be applicable to BIP65. ACK on merging using IsSuperMajority. -- Pieter ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] A Transaction Fee Market Exists Without a Block Size Limit--new research paper suggests
The paper is nicely done, but I'm concerned that there's a real problem with equation 4. The orphan rate is not just a function of time; it's also a function of the block maker's proportion of the network hash rate. Fundamentally a block maker (pool or aggregation of pools) does not orphan its own blocks. In a degenerate case a 100% pool has no orphaned blocks. Consider that a 1% miner must assume a greater risk from orphaning than, say, a pool with 25%, or worse 40% of the hash rate. I suspect this may well change some of the conclusions as larger block makers will definitely be able to create larger blocks than their smaller counterparts. Cheers, Dave On 3 Aug 2015, at 23:40, Peter R via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Dear Bitcoin-Dev Mailing list, I’d like to share a research paper I’ve recently completed titled “A Transaction Fee Market Exists Without a Block Size Limit.” In addition to presenting some useful charts such as the cost to produce large spam blocks, I think the paper convincingly demonstrates that, due to the orphaning cost, a block size limit is not necessary to ensure a functioning fee market. The paper does not argue that a block size limit is unnecessary in general, and in fact brings up questions related to mining cartels and the size of the UTXO set. It can be downloaded in PDF format here: https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf Or viewed with a web-browser here: https://www.scribd.com/doc/273443462/A-Transaction-Fee-Market-Exists-Without-a-Block-Size-Limit https://www.scribd.com/doc/273443462/A-Transaction-Fee-Market-Exists-Without-a-Block-Size-Limit Abstract. This paper shows how a rational Bitcoin miner should select transactions from his node’s mempool, when creating a new block, in order to maximize his profit in the absence of a block size limit. To show this, the paper introduces the block space supply curve and the mempool demand curve. The former describes the cost for a miner to supply block space by accounting for orphaning risk. The latter represents the fees offered by the transactions in mempool, and is expressed versus the minimum block size required to claim a given portion of the fees. The paper explains how the supply and demand curves from classical economics are related to the derivatives of these two curves, and proves that producing the quantity of block space indicated by their intersection point maximizes the miner’s profit. The paper then shows that an unhealthy fee market—where miners are incentivized to produce arbitrarily large blocks—cannot exist since it requires communicating information at an arbitrarily fast rate. The paper concludes by considering the conditions under which a rational miner would produce big, small or empty blocks, and by estimating the cost of a spam attack. Best regards, Peter ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Block size following technological growth
On Tue, Aug 4, 2015 at 3:28 PM, Hector Chu hector...@gmail.com wrote: On 4 August 2015 at 14:13, Jorge Timón jti...@jtimon.cc wrote: 2) It doesn't matter who is to blame about the current centralization: the fact remains that the blocksize maximum is the only** consensus rule to limit mining centralization. Repeating a claim ad-nauseum doesn't make it necessarily true. A block size limit won't prevent miners in the future from buying each other out. But reading it 10 times may help you understand the claim, you will never find out until you try. Miners buying each other out is not the only way in which mining centralization can get even worse. A Blocksize limit may not be able to prevent such a scenario, but it's still the only consensus tool to limit mining centralization. If you want to prove that claim wrong you need to find a counter-example of another consensus rule that somehow limits mining centralization. You could also prove that this rule doesn't help with mining centralization at all. But that's much more difficult and if you just claim it (and consequently advocate for the complete removal of the consensus rule) we will have already advanced a lot. But you denying that the limits serves limiting mining centralization and at the same time advocating for keeping a limit at all doesn't seem very consistent. If you don't want that rule to limit mining centralization pressures, what do you want it for? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Eli Dourado on governance
Given there is no money at stake in these prediction games, it is no surprise that the results are implausible. On August 4, 2015 10:22:19 AM EDT, Anthony Towns via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: On 4 August 2015 at 01:22, Gavin Andresen via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: And the preliminary results of using a prediction market to try to wrestle with the tough tradeoffs looks roughly correct to me, too: https://blocksizedebate.com/ The scicast prediction market is shutdown atm (since early July?) so those numbers aren't live. But... Network hash rate 3,255.17 PH/s (same block size) 5,032.64 PH/s (block size increase) 4,969.68 PH/s (no replace-by-fee) 3,132.09 PH/s (replace-by-fee) Those numbers seem completely implausible: that's ~2.9-3.6 doublings of the current hashrate ( 400PH/s) in 17 months, when it's taken 12 months for the last doubling, and there's a block reward reduction due in that period too. (That might've been a reasonable prediction sometime in the past year, when doublings were slowing from once every ~45 days to once a year; it just doesn't seem a supportable prediction now) That the PH/s rate is higher with bigger blocks is surprising, but given that site also predicts USD/BTC will be $280 with no change but $555 with bigger blocks, so I assume that difference is mostly due to price. Also, 12.5btc at $555 each is about 23 btc at $300 each, so if that price increase is realistic, it would compensate for almost all of the block reward reduction. Daily transaction volume 168,438.22 tx/day (same block size) 193,773.08 tx/day (block size increase) 192,603.80 tx/day (no replace-by-fee) 168,406.73 tx/day (replace-by-fee) That's only a 15% increase in transaction volume due to the block size increase; I would have expected more? 168k-194k tx/day is also only a 30%-50% increase in transaction volume from 130k tx/day currently. If that's really the case, then a 1.5MB-2MB max block size would probably be enough for the next two years... (Predicting that the node count will drop from ~5000 to ~1200 due to increasing block sizes seems quite an indictment as far as centralisation risks go; but given I'm not that convinced by the other predictions, I'm not sure I want to give that much weight to that one either) Cheers, aj -- Anthony Towns a...@erisian.com.au ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Consensus fork activation thresholds: Block.nTime vs median time vs block.nHeight
On Thu, Jul 30, 2015 at 8:16 PM, Gavin Andresen gavinandre...@gmail.com wrote: I still think using the version and timestamp fields in the block header are simplest and best. To be clear, all options can use the version. Advantages: Available to SPV nodes with no change to the network protocol Available after headers downloaded, before full block data is available Once well past a fork, allows all block validation except validation against the UTXO to happen in parallel, out-of-order, independent of any other block. All advantages shared with the height option. Disadvantages: Not monotonically increasing I think discussion about transactions in the memory pool are just a distraction: no matter what criteria is used (timestamp, height, median time), a blockchain re-organization could mean the validity of transactions you've accepted into the memory pool (if you're accepting transactions that switch from valid to invalid at the consensus change -- Core tries hard not to do that via IsStandard policy) must be re-evaluated. I'm talking about the non-reorg case. Without reorg, you know what the next height or current median time is, but you don't know what the next block time is. I don't strongly care if median time or block timestamp is used, I think either will work. I don't like height, there are too many cases where the time is known but the block height isn't (see, for example, the max-outputs-in-a-transaction sanity check computation at line 190 of bitcoin-tx.cpp -- bitcoin-tx.cpp has no idea what the current block height is). How does bitcoin-tx know about the next block time? It doesn't. You would need to use the current time as a proxy for the median time or the block.nTime which you don't know either. Or just keep the sanity check as it is. Note that this case is blocksize-specific: other hardforks (like my previous example, or the code proposal in BIP99) don't share that concern. One thing I've noticed there seems to be disagreement on is whether miners' upgrade confirmation (aka voting) is necessary for uncontroversial hardforks or not. In BIP99 the advice for uncontroversial hardforks is setting a threshold (based on height, but we can change it) and then wait for 95% of the hashrate to upgrade to enforce the chain. But maybe the voting can happen first and then the threshold is added to the miners' confirmation height/time. I think that may influence which of the three discussed options (height, block time and median time) is better, so maybe we should discuss that first. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Eli Dourado on governance
Rather than speculating on fake markets, why don’t we use theory, empirical data, and engineering to fix the damn problems? On Aug 4, 2015, at 11:28 AM, Owen via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Given there is no money at stake in these prediction games, it is no surprise that the results are implausible. On August 4, 2015 10:22:19 AM EDT, Anthony Towns via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: On 4 August 2015 at 01:22, Gavin Andresen via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org mailto:bitcoin-dev@lists.linuxfoundation.org wrote: And the preliminary results of using a prediction market to try to wrestle with the tough tradeoffs looks roughly correct to me, too: https://blocksizedebate.com/ https://blocksizedebate.com/ The scicast prediction market is shutdown atm (since early July?) so those numbers aren't live. But... Network hash rate 3,255.17 PH/s (same block size) 5,032.64 PH/s (block size increase) 4,969.68 PH/s (no replace-by-fee) 3,132.09 PH/s (replace-by-fee) Those numbers seem completely implausible: that's ~2.9-3.6 doublings of the current hashrate ( 400PH/s) in 17 months, when it's taken 12 months for the last doubling, and there's a block reward reduction due in that period too. (That might've been a reasonable prediction sometime in the past year, when doublings were slowing from once every ~45 days to once a year; it just doesn't seem a supportable prediction now) That the PH/s rate is higher with bigger blocks is surprising, but given that site also predicts USD/BTC will be $280 with no change but $555 with bigger blocks, so I assume that difference is mostly due to price. Also, 12.5btc at $555 each is about 23 btc at $300 each, so if that price increase is realistic, it would compensate for almost all of the block reward reduction. Daily transaction volume 168,438.22 tx/day (same block size) 193,773.08 tx/day (block size increase) 192,603.80 tx/day (no replace-by-fee) 168,406.73 tx/day (replace-by-fee) That's only a 15% increase in transaction volume due to the block size increase; I would have expected more? 168k-194k tx/day is also only a 30%-50% increase in transaction volume from 130k tx/day currently. If that's really the case, then a 1.5MB-2MB max block size would probably be enough for the next two years... (Predicting that the node count will drop from ~5000 to ~1200 due to increasing block sizes seems quite an indictment as far as centralisation risks go; but given I'm not that convinced by the other predictions, I'm not sure I want to give that much weight to that one either) Cheers, aj -- Anthony Towns a...@erisian.com.au mailto:a...@erisian.com.au bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev signature.asc Description: Message signed with OpenPGP using GPGMail ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] A Transaction Fee Market Exists Without a Block Size Limit--new research paper suggests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 4 August 2015 14:41:53 GMT-04:00, Dave Hudson via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: The paper is nicely done, but I'm concerned that there's a real problem with equation 4. The orphan rate is not just a function of time; it's also a function of the block maker's proportion of the network hash rate. Fundamentally a block maker (pool or aggregation of pools) does not orphan its own blocks. In a degenerate case a 100% pool has no orphaned blocks. Consider that a 1% miner must assume a greater risk from orphaning than, say, a pool with 25%, or worse 40% of the hash rate. I suspect this may well change some of the conclusions as larger block makers will definitely be able to create larger blocks than their smaller counterparts. Quite correct; this paper is fatally flawed and at best rehashes what we already know happens in the spherical cow case, without making it clear that it refers to a completely unrealistic setup. It'd be interested to know who actually wrote it - Peter R is obviously a pseudonym and the paper goes into sufficient detail that it makes you wonder why the author didn't see the flaws in it. For those wishing to do actual research, esp. people such as profs mentoring students, keep in mind that in Bitcoin situations where large miners have an advantage over small miners are security exploits, with severity proportional to the difference in profitability. A good example of the type of analysis required is the well known selfish mining paper, which shows how a miner adopting a selfish strategy has an advantage - more profit per unit hashing power - than miners who do not adopt that strategy, and additionally, that excess profits scales with increasing hashing power. As for the OP, if this wasn't an attempt at misinformation, my apologies. But keep in mind that you're wading into a highly politically charged research field with billions hanging on the blocksize limit; understand that people aren't happy when flawed papers end up on reddit being used to promote bad ideas. You'd be wise to run future work past experts in the field prior to publishing widely if you dislike heated controversy. -BEGIN PGP SIGNATURE- iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVwSwJ AAoJEMCF8hzn9Lnc47AH/RknSZpnZ8r4WA4r+S0yJmlo0hKm8gsjUGhaqX7cnuSR dB1ewrsjC4uPtSc8Ej1hzf37E67DTxiz6STq9XdtFSij+ww7SPx+z8yjEpQ0Ld0K OIidQ80WRGJ1UPMUt7pFDU3pxNZI/A46Lg3EmqjY+xAe6+wDlOHjT/miO3tv0uws nNYwrelA4f/KQXkUggGUOW62Sc3fJpUxLurq4eQHflIxtk3KM1reSxwG28KG02j6 lTUEHmMsmE7qoQAl60vwfvVKvvy/RwxpildwNey6IgtCQqWqqEy+WoTsgyVAGIbn +8gR//W2hEIp+W5OSsiVNZ5S/KpcwaIBqZFcoca8838= =HJiv -END PGP SIGNATURE- ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
