Re: [Bitcoin-development] Long-term mining incentives
On 05/13/2015 09:31 PM, Aaron Voisine wrote: by people and businesses deciding to not use on-chain settlement. I completely agree. Increasing fees will cause people voluntary economize on blockspace by finding alternatives, i.e. not bitcoin. This strikes me as a leap. There are alternatives that still use bitcoin as the unit of value, such as sidechains, offchain, etc. To say that these are not bitcoin is misleading. A fee however is a known, upfront cost... unpredictable transaction failure in most cases will be a far higher, unacceptable cost to the user than the actual fee. Are we sure that raising the block size is the only way to avoid unpredictable transaction failure? If so, and it's as bad as you say it is, aren't we screwed anyway when we inevitably start hitting the cap (even if it's raised 10x or 20x)? And if that's the case, then don't we do a disservice to users by continuing to pretend that we can make this problem go away? The higher the costs of using the system, the lower the adoption as a store-of-value. On what do you base this? Gold has a very high cost of using (storage, transport) and yet is perhaps the most widely accepted store of value. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
On Sat, May 16, 2015 at 1:22 AM, Rusty Russell ru...@rustcorp.com.au wrote: Some tweaks: 1) Nomenclature: call tx_size tx_cost and real_size tx_bytes? Fair enough. 2) If we have a reasonable hard *byte* limit, I don't think that we need the MAX(). In fact, it's probably OK to go negative. I agree, we want people to compress the UTXO space and a transaction with 100 inputs and one output is great. It may have privacy problem though. 3) ... or maybe not, if any consumed UTXO was generated before the soft fork (reducing Tier's perverse incentive). The incentive problem can be fixed by excluding UTXOs from blocks before a certain count. UTXOs in blocks before 375000 don't count. 4) How do we measure UTXO size? There are some constant-ish things in there (eg. txid as key, height, outnum, amount). Maybe just add 32 to scriptlen? They can be stored as a fixed digest. That can be any size, depending on security requirements. Gmaxwell's cost proposal is 3-4 bytes per UTXO change. It isn't 4*UXTO.size - 3*UTXO.size It is only a small nudge. With only 10% of the block space to play with it can't be massive. This requires that transactions include scriptPubKey information when broadcasting them. 5) Add a CHECKSIG cost. Naively, since we allow 20,000 CHECKSIGs and 1MB blocks, that implies a cost of 50 bytes per CHECKSIG (but counted correctly, unlike now). This last one implies that the initial cost limit would be 2M, but in practice probably somewhere in the middle. tx_cost = 50*num-CHECKSIG + tx_bytes + 4*utxo_created_size - 3*utxo_consumed_size A 250 byte transaction with 2 inputs and 2 outputs would have an adjusted size of 252 bytes. Now cost == 352. That is to large a cost for a 10% block change. It could be included in the block size hard fork though. I think have one combined cost for transactions is good. It means much fewer spread out transaction checks. The code for the cost formula would be in one place. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase Requirements
On Sat, May 9, 2015 at 4:08 AM, Peter Todd p...@petertodd.org wrote: I wonder if having a miner flag would be good for the network. Makes it trivial to find miners and DoS attack them - a huge risk to the network as a whole, as well as the miners. To mitigate against this, two chaintips could be tracked. The miner tip and the client tip. Miners would build on the miner tip. When performing client services, like wallets, they would use the client tip. The client would act exactly the same as any node, the only change would be that it gives miner work based on the mining tip. If the two tips end up significantly forking, there would be a warning to the miner and perhaps eventually refuse to give out new work. That would happen when there was a miner level hard-fork. That'd be an excellent way to double-spend merchants, significantly increasing the chance that the double-spend would succeed as you only have to get sufficient hashing power to get the lucky blocks; you don't need enough hashing power to *also* ensure those blocks don't become the longest chain, removing the need to sybil attack your target. To launch that attack, you need to produce fake blocks. That is expensive. Stephen Cale's suggestion to wait more than one block before counting a transaction as confirmed would also help mitigate. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase Requirements
On Sat, May 16, 2015 at 5:39 AM, Stephen stephencalebmo...@gmail.com wrote: I think this could be mitigated by counting confirmations differently. We should think of confirmations as only coming from blocks following the miners' more strict rule set. So if a merchant were to see payment for the first time in a block that met their own size restrictions but not the miners', then they would simply count it as unconfirmed. In effect, there is a confirm penalty for less strict blocks. Confirms = max(miner_confirms, merchant_confirms - 3, 0) Merchants who don't upgrade end up having to wait longer to hit confirmations. If they get deep enough in the chain, though, the client should probably count them as being confirmed anyway, even if they don't meet the client nodes' expectation of the miners' block size limit. This happening probably just means that the client has not updated their software (or -minermaxblocksize configuration, depending on how it is implemented) in a long time. That is a good idea. Any parameters that have miner/merchant differences should be modifiable (but only upwards) in the command line. Why are my transactions taking longer to confirm? There was a soft fork to make the block size larger and your client is being careful. You need to add minermaxblocksize=4MB to your bitcoin.conf file. Hah, it could be called a semi-hard fork? -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Long-term mining incentives
On Sat, May 16, 2015 at 1:35 PM, Owen Gunden ogun...@phauna.org wrote: This strikes me as a leap. There are alternatives that still use bitcoin as the unit of value, such as sidechains, offchain, etc. To say that these are not bitcoin is misleading. The only options available today and in the near future that I'm aware of are of the centralized custody variety, which is pretty bad in my opinion, but your point is taken. Are we sure that raising the block size is the only way to avoid unpredictable transaction failure? If so, and it's as bad as you say it is, aren't we screwed anyway when we inevitably start hitting the cap (even if it's raised 10x or 20x)? And if that's the case, then don't we do a disservice to users by continuing to pretend that we can make this problem go away? When we start bumping up against the block size limit, the transactions at the margins will experience failure in a way that will be unpredictable to current wallet software. We can slow blockchain growth by increasing fees alone, without introducing the additional cost of unpredictability around confirmation failure, which when it comes down to it is just another (extreme) way to keep usage low. Instead of fees and unpredictable confirmation, why not just have fees alone. A single, upfront, known cost. On what do you base this? Gold has a very high cost of using (storage, transport) and yet is perhaps the most widely accepted store of value. I would argue that the reason gold is not the one world global currency that it once was is because of those costs. That's why people shifted over time to gold backed bank notes and eventually fiat. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] No Bitcoin For You
I agree with this analysis. I'm not sure if we will increase 1 MB block size or not, but with a block size that small, it is all but impossible for most people on the planet to ever own even a single utxo. At 7tps, how long would it take to give 1 utxo to all of the 7 billion people currently alive? It would take 1 billion seconds, or about 32 years.[1] So for all practical purposes, at 1 MB block size, far less than 1% of people will ever be able to own even a single satoshi. Unless those people are willing to wait around 30 years for their lightning network to settle, they will either not use bitcoin, or they will use a substitute (such as a parallel decentralized network, or a centralized service) that lacks the full trust-minimized security guarantees of the main bitcoin blockchain. I can't speak for most people, but for me personally, the thing I care most about as an individual (besides being able to send bitcoin to and from anyone on the planet) is being able to validate the blockchain. With a pruning node, this means I need to download the blockchain one time (not store it), and maintain the utxo set. The utxo set is, roughly speaking, 30 bytes per utxo, and therefore, at one utxo per person, about 7*30 billion bytes, or 210 GB. That's very achievable on the hardware of today. Of course, some individuals or companies will have far more than one utxo. Estimating an average of ten utxos per person, that will be 2.1 TB. Also very achievable on the hardware of today. I don't think every transaction in the world should be on the blockchain, but I think it should be able to handle (long-term) enough transactions that everyone can have their transactions settled on a timescale suitable for human life. 30 years is unsuitable, but 1 day would be pretty good. It would be great if I could send trillions of transactions per day on networks built on top of bitcoin, and have my transactions settle on the actual blockchain once per day. This means we would need to support about 1 utxo per person per day, or 7 billion transactions per day. That translates to about 81 thousand transactions per second [2], or approximately 10,000 times the current rate. That would be 10 GB per ten minutes, which is achievable on current hardware (albeit not yet inexpensively). Using SPV security rather than pruning security makes the cost even lower. A person relying on SPV would not have to download every 10 GB block, but only their transactions (or a small superset of them), which is already being done - scaling to 7 billion people would not require that SPV nodes perform any more computation than they already do. Nonetheless, I think pruning should be considered the default minimum, since that it what is required to get the full trust-minimized security guarantees of the blockchain. And that requires 10 GB blocks (or thereabouts). The number of people on the planet will also grow, perhaps to 14 billion people in the next few decades. However, the estimates here would still be roughly correct. 10 GB blocks, or approximately so, allows everyone in the world to have their transactions settled on the blockchain in a timely manner, whereas 1 MB blocks do not. And this is already achievable on current hardware. The most significant cost is bandwidth, but that will probably become substantially less expensive in the coming years, making it possible for everyone to inexpensively and securely send and receive bitcoin to anyone else, without having to use a parallel network with reduced security or rely on trusted third parties. [1] 10^9 / 60 / 60 / 24 / 365 ~= 32. [2] 7*10^9 / 24 / 60 / 60 ~= 81018 On 05/14/2015 08:22 AM, Tom Harding wrote: A recent post, which I cannot find after much effort, made an excellent point. If capacity grows, fewer individuals would be able to run full nodes. Those individuals, like many already, would have to give up running a full-node wallet :( That sounds bad, until you consider that the alternative is running a full node on the bitcoin 'settlement network', while massive numbers of people *give up any hope of directly owning bitcoin at all*. If today's global payments are 100Ktps, and move to the Lightning Network, they will have to be consolidated by a factor of 25000:1 to fit into bitcoin's current 4tps capacity as a settlement network. You executing a personal transaction on that network will be about as likely as you personally conducting a $100 SWIFT transfer to yourself today. For current holders, just selling or spending will get very expensive! Forcing block capacity to stay small, so that individuals can run full nodes, is precisely what will force bitcoin to become a backbone that is too expensive for individuals to use. I can't avoid the conclusion that Bitcoin has to scale, and we might as well be thinking about how. There may be a an escape window. As current trends continue toward a landscape of billions of SPV wallets, it may still be possible
Re: [Bitcoin-development] Long-term mining incentives
On 5/16/2015 1:35 PM, Owen Gunden wrote: There are alternatives that still use bitcoin as the unit of value, such as sidechains, offchain, etc. To say that these are not bitcoin is misleading. Is it? Nobody thinks euro accepted implies Visa is ok, even though Visa is just a bunch of extra protocol surrounding an eventual bank deposit. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
