Re: [Bitcoin-development] Blocking uneconomical UTXO creation
Just activate a non-proportional demurrage demurrage of any kind will never, ever happen, just give up on that idea. The negative publicity of the bitcoin developers are destroying YOUR coins! would be devastating. -- -- Gavin Andresen -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Blocking uneconomical UTXO creation
Why does demurrage even still come up? The base rules of Bitcoin will not be changing in such a fundamental way. With regards to trying to minimize the size of the UTXO set, this again feels like a solution in search of a problem. Even with SD abusing micropayments as messages, it's only a few hundred megabytes today. That fits in RAM, let alone disk. If one day people do get concerned about the working set size, miners can independently set their own policies for what they confirm, for instance maybe they just bump the priority of any transaction that has fewer outputs than inputs. An IsStandard() rule now that tries to ban micropayments will just risk hurting interesting applications for no real benefit. It's like trying to anticipate and fix problems we might face in 2020. There are lots of less invasive changes for improving scalability, like making transaction validation multi-threaded in every case, transmitting merkle blocks instead of full blocks, moving blocking disk IO off the main loop so nodes don't go unresponsive when somebody downloads the chain from them, and finishing the payment protocol work so there's less incentive to replicate the SD transactions as messages design. -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Blocking uneconomical UTXO creation
That solution seems good enough to me. Smartcoin users would just need to move their assets before 10 years, totally acceptable. And regular users don't need to think about it since they're probably always sending more than they pay in fees. On 3/11/13, Benjamin Lindner b...@benlabs.net wrote: On Mar 11, 2013, at 12:54 PM, Mike Hearn m...@plan99.net wrote: With regards to trying to minimize the size of the UTXO set, this again feels like a solution in search of a problem. Even with SD abusing micropayments as messages, it's only a few hundred megabytes today. That fits in RAM, let alone disk. If one day people do get The problem of UTXO in principal scales with the block size limit. Thus it should be fixed BEFORE you consider increasing the block size limit. Otherwise you just kick the can down the road, making it bigger. concerned about the working set size, miners can independently set their own policies for what they confirm, for instance maybe they just Problem is the skewed incentive structure. Rational miners will always include dust output with fees, because the eternal cost of UTXO is payed by the network and future miners, not the current/individual miner. On Mar 11, 2013, at 7:01 AM, Jorge Timón jtimo...@gmail.com wrote: On 3/10/13, Peter Todd p...@petertodd.org wrote: It's also been suggested multiple times to make transaction outputs with a value less than the transaction fee non-standard, either with a fixed constant or by some sort of measurement. As said on the bitcointalk thread, I think this is the wrong approach. This way you effectively disable legitimate use cases for payments that are worth less than the fees like smart property/colored coins. this. Just activate a non-proportional demurrage (well, I won't complain if you just turn bitcoin into freicoin, just think that non-proportional would be more acceptable by most bitcoiners) that incentives old transactions to be moved You could delegate the decision to the user with a rule like: if (outputfee): limit lifetime of the UTXO to 10 years. if (outputfee): unlimited lifetime Then, when a user creates a transaction, he can decide whether he wants to have limited or unlimited lifetime. The rationale for limiting the lifetime for (outputfee) transactions is that they may have no inherent economic incentive to be spend. -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jorge Timón http://freico.in/ http://archive.ripple-project.org/ -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Blocking uneconomical UTXO creation
On 03/11/2013 08:17 PM, Benjamin Lindner wrote: The problem of UTXO in principal scales with the block size limit. Thus it should be fixed BEFORE you consider increasing the block size limit. Otherwise you just kick the can down the road, making it bigger. Let's assume bitcoin has scaled up to 2000 tx/s. We all want this, right? https://en.bitcoin.it/wiki/Scalability. Block size is 500 MB. CPU, network and archival blockchain storage seem to solvable. Let's say SatoshiDice-like systems are doing informational transactions that produce unspendable outputs, because they can and users are paying for it anyway (proved in real life). 400 unspendable outputs per second would be realistic. This would be bloating UTXO data at a speed of 52 GB/year. That's a very big memory leak. And this is just the unspendable outputs. Bitcoin cannot scale up until such dust output spamming is discouraged at the protocol level. -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [PATCH] Change recommended fee to 0.001 BTC
On Monday, March 11, 2013 7:27:51 PM Rune K. Svendsen wrote: From: Rune K. Svendsen runesv...@gmail.com On the Main tab in the Options dialog, it previously said a minimum fee of 0.01 is recommended. This amounts to about $0.50 at today's price. Change this to 0.001 to be more sensible. We could even go lower, perhaps. Please use GitHub pull requests (or at least publish a git repository) rather than mailing patches.. I'd suggest two commits for this: 1. Move the recommended fee outside the translatable string (bonus points to format it using the user's preferred unit) 2. Change the recommended fee in one place Whether the recommended fee *should* be changed or not, I have no opinion on. Eligius uses a lower minimum fee, but I believe most pools/miners will treat anything under 0.01 BTC as if it were no fee at all... Luke -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Blocking uneconomical UTXO creation
The point with UTXO is in the long run to be able to switch from a p2p network where everyone stores, validates and verifies everything to a DHT where the load of storing, validating and verifying can be shared. If we succeed with that then I don't see a problem in a growing set of UTXO, may that be due to abuse/misuse or just massive use. A properly designed DHT should be able to scale to this. However, that being said, if you worry about the size of the UTXO set you should change the current coin choosing algorithm to simply get rid of dust. The current algorithm (ApproximateBestSubset) tend to accumulate dust as dust tend to be on an other scale than a real transactions and hence it is never included. Regarding the demurrage/escheatment road, I agree that this is for another project. However, if users/developers like this idea, they can just implement a coin choosing algorithm donating dust as miner fee and use it on their satoshi-dice polluted wallet ;) /M On 11/03/2013, at 21:08, Rune Kjær Svendsen runesv...@gmail.com wrote: On Mon, Mar 11, 2013 at 12:01 PM, Jorge Timón jtimo...@gmail.com wrote: On 3/10/13, Peter Todd p...@petertodd.org wrote: It's also been suggested multiple times to make transaction outputs with a value less than the transaction fee non-standard, either with a fixed constant or by some sort of measurement. As said on the bitcointalk thread, I think this is the wrong approach. This way you effectively disable legitimate use cases for payments that are worth less than the fees like smart property/colored coins. While the transactions pay fees, they should not be considered spam regardless of how little the quantities being moved are. Then your only concern are unspent outputs and comparing fees with values doesn't help in any way. Just activate a non-proportional demurrage (well, I won't complain if you just turn bitcoin into freicoin, just think that non-proportional would be more acceptable by most bitcoiners) that incentives old transactions to be moved and destroys unspent transactions with small amounts that don't move to another address periodically. This has been proposed many times before too, and I think it makes a lot more sense. From an economic point of view this *does* make sense, in my opinion. Storing an unspent transaction in the block chain costs money because we can't prune it. However, it would completely destroy confidence in Bitcoin, as far as I can see. It makes sense economically, but it isn't feasible if we want to maintain people's confidence in Bitcoin. I like Jeff's proposal of letting an alt-coin implement this. If it gets to the point where Bitcoin can't function without this functionality, it'll be a lot easier to make the transition, instead of now, when it's not really needed, and the trust in Bitcoin really isn't that great. /Rune -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Blocking uneconomical UTXO creation
On Mon, Mar 11, 2013 at 1:36 PM, Michael Gronager grona...@ceptacle.com wrote: The point with UTXO is in the long run to be able to switch from a p2p network where everyone stores, validates and verifies everything to a DHT where the load of storing, validating and verifying can be shared. I believe you are confusing disjoint things. -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [PATCH] Change recommended fee to 0.001 BTC
On Mon, Mar 11, 2013 at 9:46 PM, Luke-Jr l...@dashjr.org wrote: On Monday, March 11, 2013 8:34:52 PM Rune Kjær Svendsen wrote: Ok. I'll fork on Github. Looking at the source, and some Qt documentation, it should be doable to do string substitution for both the value and the unit. Side note: I imagine you'd be substituting a formatted string, and using some other function to format the string (which already exists to decide how to display units elsewhere). I'm not entirely sure what you mean by this. I plan on using the method described on this page http://doc.qt.digia.com/3.1/i18n.html under Use QString::arg() for Simple Arguments and then just putting a %1 and %2 in the translation strings and substituting for value and unit, respectively. Haven't tested it yet, but that's what I plan to do. Where do you want the constant defined? In main.h alongside MIN_TX_FEE and MIN_RELAY_TX_FEE? /Rune -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [PATCH] Change recommended fee to 0.001 BTC
On Monday, March 11, 2013 9:17:25 PM Rune Kjær Svendsen wrote: On Mon, Mar 11, 2013 at 9:46 PM, Luke-Jr l...@dashjr.org wrote: On Monday, March 11, 2013 8:34:52 PM Rune Kjær Svendsen wrote: Ok. I'll fork on Github. Looking at the source, and some Qt documentation, it should be doable to do string substitution for both the value and the unit. Side note: I imagine you'd be substituting a formatted string, and using some other function to format the string (which already exists to decide how to display units elsewhere). I'm not entirely sure what you mean by this. I plan on using the method described on this page http://doc.qt.digia.com/3.1/i18n.html under Use QString::arg() for Simple Arguments and then just putting a %1 and %2 in the translation strings and substituting for value and unit, respectively. Haven't tested it yet, but that's what I plan to do. eg, use a single %1 with BitcoinUnits::format(walletModel-getOptionsModel()-getDisplayUnit(), amount) Where do you want the constant defined? In main.h alongside MIN_TX_FEE and MIN_RELAY_TX_FEE? Sounds reasonable. -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Blocking uneconomical UTXO creation
This would be bloating UTXO data at a speed of 52 GB/year. That's a very big memory leak. And this is just the unspendable outputs. Firstly, the UTXO set is a LevelDB, it's not stored in memory. Outputs that never get spent are not in the working set by definition, after a while they just end up in the bottom levels and hardly ever get accessed. If need be we can always help LevelDB out a bit by moving outputs that we suspect are unlikely to get spent into a separate database, but I doubt it's needed. Secondly, if an output can be proven unspendable it can be pruned immediately. We already reached consensus on adding some standard template using OP_RETURN that results in insta-pruning. So people who want to create unspendable outputs can do so with the only side-effect being long term chain storage. It would be effectively free to pruning nodes. So the issue is not really with unspendable outputs but with low-value spendable outputs. Wallets with lots of tiny outputs end up generating large transactions that take a long time to verify, in situations where the network redlines those transactions would end up at the bottom of the priority queue and might take longer to confirm. So wallet apps already have incentives to try and find a good balance in output sizes and defragment themselves if their average output gets too low in value, eg, by send-to-self transactions at night. -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Blocking uneconomical UTXO creation
On 03/12/2013 12:19 AM, Mike Hearn wrote: Firstly, the UTXO set is a LevelDB, it's not stored in memory. Outputs that never get spent are not in the working set by definition, after a while they just end up in the bottom levels and hardly ever get accessed. If need be we can always help LevelDB out a bit by moving outputs that we suspect are unlikely to get spent into a separate database, but I doubt it's needed. Isn't there danger of an attack if UTXO is not stored in fast storage? -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Can this tx be formed?
Say Alice signs and broadcasts a tx with input Ai, with SIGHASH_SINGLE to Ao and SIGHASH_ANYONECANPAY Bob signs and broadcasts a tx with input Bi, with SIGHASH_SINGLE to Bo and SIGHASH_ANYONECANPAY Can Carol complete the tx so that it is valid to be published in the chain? It only has to make Ai + Bi + Ci + F = Ao + Bo + Co but it all must be contained in a single transaction. -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Blocking uneconomical UTXO creation
On 03/12/2013 12:39 AM, Mike Hearn wrote: RAM is used as a database cache. But regardless, what kind of attack are you thinking of? Using up all available disk seeks by sending a node a lot of fake transactions that connect to unspent outputs, but have invalid transactions? You'll get yourself disconnected and the IP banned even with todays code. I'm thinking that (assuming 2000 tx/s and UTXO growing 50 GB/year) a malicious miner could create 1 GB of unspent outputs and then spam nodes with valid transactions. This would not be dangerous, if UTXO were smaller and fit on RAM. Thank you for reading and correcting me :) -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Warning: many 0.7 nodes break on large number of tx/block; fork risk
Hello everyone, Í've just seen many reports of 0.7 nodes getting stuck around block 225430, due to running out of lock entries in the BDB database. 0.8 nodes do not seem to have a problem. In any case, if you do not have this block: 2013-03-12 00:00:10 SetBestChain: new best=015aab28064a4c521d6a5325ff6e251e8ca2edfdfe6cb5bf832c height=225439 work=853779625563004076992 tx=14269257 date=2013-03-11 23:49:08 you're likely stuck. Check debug.log and db.log (look for 'Lock table is out of available lock entries'). If this is a widespread problem, it is an emergency. We risk having (several) forked chains with smaller blocks, which are accepted by 0.7 nodes. Can people contact pool operators to see which fork they are on? Blockexplorer and blockchain.info seem to be stuck as well. Immediate solution is upgrading to 0.8, or manually setting the number of lock objects higher in your database. I'll follow up with more concrete instructions. If you're unsure, please stop processing transactions. -- Pieter -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
