Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database
Makes sense.. So with that said, I'd propose the following criteria for selecting UTXOs: 1. Select the smallest possible set of addresses that can be linked in order to come up with enough BTC to send to the payee. 2. Given multiple possible sets, select the one that has the largest number of UTXOs. 3. Given multiple possible sets, choose the one that contains the largest amount of total BTC. 4. Given multiple possible sets, select the one that destroys the most bitcoin days. 5. If there's still multiple possible sets, just choose one at random. Once the final set of addresses has been identified, use ALL UTXOs from that set, sending appropriate outputs to the recipient(s), a new change address, and a mining fee. Miners should be cognisant of and reward the fact that the user is making an effort to consolidate UTXOs. They can easily spot these transactions by looking at whether all possible UTXOs from each input addresses have been used. Since most miners use Bitcoin Core, and its defaults, this test can be built into Bitcoin Core's logic for determining which transactions to include when mining a block. -- *James G. Phillips IV* https://plus.google.com/u/0/113107039501292625391/posts http://www.linkedin.com/in/ergophobe *Don't bunt. Aim out of the ball park. Aim for the company of immortals. -- David Ogilvy* *This message was created with 100% recycled electrons. Please think twice before printing.* On Sat, May 9, 2015 at 3:38 PM, Pieter Wuille pieter.wui...@gmail.com wrote: Miners do not care about the age of a UTXO entry, apart for two exceptions. It is also economically irrelevant. * There is a free transaction policy, which sets a small portion of block space aside for transactions which do not pay sufficient fee. This is mostly an altruistic way of encouraging Bitcoin adoption. As a DoS prevention mechanism, there is a requirement that these free transactions are of sufficient priority (computed as BTC-days-destroyed per byte), essentially requiring these transactions to consume another scarce resource, even if not money. * Coinbase transaction outputs can, as a consensus rule, only be spent after 100 confirmations. This is to prevent random reorganisations from invalidating transactions that spend young coinbase transactions (which can't move to the new chain). In addition, wallets also select more confirmed outputs first to consume, for the same reason. On May 9, 2015 1:20 PM, Raystonn rayst...@hotmail.com wrote: That policy is included in Bitcoin Core. Miners use it because it is the default. The policy was likely intended to help real transactions get through in the face of spam. But it favors those with more bitcoin, as the priority is determined by amount spent multiplied by age of UTXOs. At the very least the amount spent should be removed as a factor, or fees are unlikely to ever be paid by those who can afford them. We can reassess the role age plays later. One change at a time is better. On 9 May 2015 12:52 pm, Jim Phillips j...@ergophobia.org wrote: On Sat, May 9, 2015 at 2:43 PM, Raystonn rayst...@hotmail.com wrote: How about this as a happy medium default policy: Rather than select UTXOs based solely on age and limiting the size of the transaction, we select as many UTXOs as possible from as few addresses as possible, prioritizing which addresses to use based on the number of UTXOs it contains (more being preferable) and how old those UTXOs are (in order to reduce the fee)? If selecting older UTXOs gives higher priority for a lesser (or at least not greater) fee, that is an incentive for a rational user to use the older UTXOs. Such policy needs to be defended or removed. It doesn't support privacy or a reduction in UTXOs. Before starting this thread, I had completely forgotten that age was even a factor in determining which UTXOs to use. Frankly, I can't think of any reason why miners care how old a particular UTXO is when determining what fees to charge. I'm sure there is one, I just don't know what it is. I just tossed it in there as homage to Andreas who pointed out to me that it was still part of the selection criteria. -- 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] A suggestion for reducing the size of the UTXO database
That policy is included in Bitcoin Core. Miners use it because it is the default. The policy was likely intended to help real transactions get through in the face of spam. But it favors those with more bitcoin, as the priority is determined by amount spent multiplied by age of UTXOs. At the very least the amount spent should be removed as a factor, or fees are unlikely to ever be paid by those who can afford them. We can reassess the role age plays later. One change at a time is better. On 9 May 2015 12:52 pm, Jim Phillips j...@ergophobia.org wrote:On Sat, May 9, 2015 at 2:43 PM, Raystonn raystonn@hotmail.com wrote:How about this as a happy medium default policy: Rather than select UTXOs based solely on age and limiting the size of the transaction, we select as many UTXOs as possible from as few addresses as possible, prioritizing which addresses to use based on the number of UTXOs it contains (more being preferable) and how old those UTXOs are (in order to reduce the fee)? If selecting older UTXOs gives higher priority for a lesser (or at least not greater) fee, that is an incentive for a rational user to use the older UTXOs. Such policy needs to be defended or removed. It doesnt support privacy or a reduction in UTXOs.Before starting this thread, I had completely forgotten that age was even a factor in determining which UTXOs to use. Frankly, I cant think of any reason why miners care how old a particular UTXO is when determining what fees to charge. Im sure there is one, I just dont know what it is. I just tossed it in there as homage to Andreas who pointed out to me that it was still part of the selection criteria. -- 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] A suggestion for reducing the size of the UTXO database
Minimizing the number of UTXOs in a wallet is sometimes not in the best interests of the user. In fact, quite often I've wished for a configuration option like Try to maintain _[number]_ UTXOs in the wallet. This is because I often want to make multiple spends from my wallet within one block, but spends of unconfirmed inputs are less reliable than spends of confirmed inputs, and some wallets (e.g., Andreas Schildbach's wallet) don't even allow it - you can only spend confirmed UTXOs. I can't tell you how aggravating it is to have to tell a friend, Oh, oops, I can't pay you yet. I have to wait for the last transaction I did to confirm first. All the more aggravating because I know, if I have multiple UTXOs in my wallet, I can make multiple spends within the same block. On Saturday, 9 May 2015, at 12:09 pm, Jim Phillips wrote: Forgive me if this idea has been suggested before, but I made this suggestion on reddit and I got some feedback recommending I also bring it to this list -- so here goes. I wonder if there isn't perhaps a simpler way of dealing with UTXO growth. What if, rather than deal with the issue at the protocol level, we deal with it at the source of the problem -- the wallets. Right now, the typical wallet selects only the minimum number of unspent outputs when building a transaction. The goal is to keep the transaction size to a minimum so that the fee stays low. Consequently, lots of unspent outputs just don't get used, and are left lying around until some point in the future. What if we started designing wallets to consolidate unspent outputs? When selecting unspent outputs for a transaction, rather than choosing just the minimum number from a particular address, why not select them ALL? Take all of the UTXOs from a particular address or wallet, send however much needs to be spent to the payee, and send the rest back to the same address or a change address as a single output? Through this method, we should wind up shrinking the UTXO database over time rather than growing it with each transaction. Obviously, as Bitcoin gains wider adoption, the UTXO database will grow, simply because there are 7 billion people in the world, and eventually a good percentage of them will have one or more wallets with spendable bitcoin. But this idea could limit the growth at least. The vast majority of users are running one of a handful of different wallet apps: Core, Electrum; Armory; Mycelium; Breadwallet; Coinbase; Circle; Blockchain.info; and maybe a few others. The developers of all these wallets have a vested interest in the continued usefulness of Bitcoin, and so should not be opposed to changing their UTXO selection algorithms to one that reduces the UTXO database instead of growing it. From the miners perspective, even though these types of transactions would be larger, the fee could stay low. Miners actually benefit from them in that it reduces the amount of storage they need to dedicate to holding the UTXO. So miners are incentivized to mine these types of transactions with a higher priority despite a low fee. Relays could also get in on the action and enforce this type of behavior by refusing to relay or deprioritizing the relay of transactions that don't use all of the available UTXOs from the addresses used as inputs. Relays are not only the ones who benefit the most from a reduction of the UTXO database, they're also in the best position to promote good behavior. -- *James G. Phillips IV* https://plus.google.com/u/0/113107039501292625391/posts *Don't bunt. Aim out of the ball park. Aim for the company of immortals. -- David Ogilvy* *This message was created with 100% recycled electrons. Please think twice before printing.* -- 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] A suggestion for reducing the size of the UTXO database
Miners do not care about the age of a UTXO entry, apart for two exceptions. It is also economically irrelevant. * There is a free transaction policy, which sets a small portion of block space aside for transactions which do not pay sufficient fee. This is mostly an altruistic way of encouraging Bitcoin adoption. As a DoS prevention mechanism, there is a requirement that these free transactions are of sufficient priority (computed as BTC-days-destroyed per byte), essentially requiring these transactions to consume another scarce resource, even if not money. * Coinbase transaction outputs can, as a consensus rule, only be spent after 100 confirmations. This is to prevent random reorganisations from invalidating transactions that spend young coinbase transactions (which can't move to the new chain). In addition, wallets also select more confirmed outputs first to consume, for the same reason. On May 9, 2015 1:20 PM, Raystonn rayst...@hotmail.com wrote: That policy is included in Bitcoin Core. Miners use it because it is the default. The policy was likely intended to help real transactions get through in the face of spam. But it favors those with more bitcoin, as the priority is determined by amount spent multiplied by age of UTXOs. At the very least the amount spent should be removed as a factor, or fees are unlikely to ever be paid by those who can afford them. We can reassess the role age plays later. One change at a time is better. On 9 May 2015 12:52 pm, Jim Phillips j...@ergophobia.org wrote: On Sat, May 9, 2015 at 2:43 PM, Raystonn rayst...@hotmail.com wrote: How about this as a happy medium default policy: Rather than select UTXOs based solely on age and limiting the size of the transaction, we select as many UTXOs as possible from as few addresses as possible, prioritizing which addresses to use based on the number of UTXOs it contains (more being preferable) and how old those UTXOs are (in order to reduce the fee)? If selecting older UTXOs gives higher priority for a lesser (or at least not greater) fee, that is an incentive for a rational user to use the older UTXOs. Such policy needs to be defended or removed. It doesn't support privacy or a reduction in UTXOs. Before starting this thread, I had completely forgotten that age was even a factor in determining which UTXOs to use. Frankly, I can't think of any reason why miners care how old a particular UTXO is when determining what fees to charge. I'm sure there is one, I just don't know what it is. I just tossed it in there as homage to Andreas who pointed out to me that it was still part of the selection criteria. -- 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
The nice thing about 1 MB is that you can store ALL bitcoin transactions relevant to your lifetime (~100 years) on one 5 TB hard drive (1*6*24*365*100=5256000). Any regular person can run a full node and store this 5 TB hard drive easily at their home. With 10 MB blocks you need a 50 TB drive just for your bitcoin transactions! This is not doable for most regular people due to space and monetary constraints. Being able to review all transactions relevant to your lifetime is one of the key important properties of Bitcoin. How else can people audit the financial transactions of companies and governments that are using the Bitcoin blockchain? How else can we achieve this level of transparency that is essential to keeping corrupt governments/companies in check? How else can we keep track of our own personal transactions without relying on others to keep track of them for us? As time passes, storage technology may increase, but so may human life expectancy. So yes, in this sense, 1 MB just may be the magic number. Assuming that we have a perfectly functional off-chain transaction system, what do we actually gain by going from 1 MB to 1000 MB (my approximate limit for regular users having enough processing power)? If there is no clear and substantial gain, then it is foolish to venture into this territory, i.e. KEEP IT AT 1 MB! For example Angel said he wants to see computers transacting with computers at super speeds. Why do you need to do this on the main chain? You will lose all the transparency of the current system, an essential feature. On Fri, May 8, 2015 at 10:36 PM, Angel Leon gubat...@gmail.com wrote: I believe 100MB is still very conservative, I think that's barely 666 tps. I also find it not very creative that people are imagining these limits for 10 billion people using bitcoin, I think bitcoin's potential is realized with computers transacting with computers, which can eat those 666 tps in a single scoup (what if bittorrent developers got creative with seeding, or someone created a decentralized paid itunes on top of bitcoin, or the openbazaar developers actually pulled a decentralized amazon with no off-chain transaction since they want the thing to be fully decentralized, bitcoin would collapse right away) I truly hope people see past regular people running nodes at home, that's never going to happen. This should be about the miner's networking, storage and cpu capacity. They will have gigabit access, they will have shitload of storage, and they already have plenty of processing power, all of which are only going to get cheaper. In order to have the success we all dream we'll need gigabit blocks. Let's hope adoption remains slow. http://twitter.com/gubatron On Fri, May 8, 2015 at 1:51 PM, Alan Reiner etothe...@gmail.com wrote: Actually I believe that side chains and off-main-chain transactions will be a critical part for the overall scalability of the network. I was actually trying to make the point that (insert some huge block size here) will be needed to even accommodate the reduced traffic. I believe that it is definitely over 20MB. If it was determined to be 100 MB ten years from now, that wouldn't surprise me. Sent from my overpriced smartphone On May 8, 2015 1:17 PM, Andrew onelinepr...@gmail.com wrote: On Fri, May 8, 2015 at 2:59 PM, Alan Reiner etothe...@gmail.com wrote: This isn't about everyone's coffee. This is about an absolute minimum amount of participation by people who wish to use the network. If our goal is really for bitcoin to really be a global, open transaction network that makes money fluid, then 7tps is already a failure. If even 5% of the world (350M people) was using the network for 1 tx per month (perhaps to open payment channels, or shift money between side chains), we'll be above 100 tps. And that doesn't include all the non-individuals (organizations) that want to use it. The goals of a global transaction network and everyone must be able to run a full node with their $200 dell laptop are not compatible. We need to accept that a global transaction system cannot be fully/constantly audited by everyone and their mother. The important feature of the network is that it is open and anyone *can* get the history and verify it. But not everyone is required to. Trying to promote a system wher000e the history can be forever handled by a low-end PC is already falling out of reach, even with our miniscule 7 tps. Clinging to that goal needlessly limits the capability for the network to scale to be a useful global payments system These are good points and got me thinking (but I think you're wrong). If we really want each of the 10 billion people soon using bitcoin once per month, that will require 500MB blocks. That's about 2 TB per month. And if you relay it to 4 peers, it's 10 TB per month. Which I suppose is doable for a home desktop, so you can just run a pruned full node with all transactions
Re: [Bitcoin-development] CLTV opcode allocation; long-term plans?
On Tue, May 05, 2015 at 01:54:33AM +0100, Btc Drak wrote: That said, if people have strong feelings about this, I would be willing to make OP_CLTV work as follows: nLockTime 1 OP_CLTV Where the 1 selects absolute mode, and all others act as OP_NOP's. A future relative CLTV could then be a future soft-fork implemented as follows: relative nLockTime 2 OP_CLTV On the bad side it'd be two or three days of work to rewrite all the existing tests and example code and update the BIP, and (slightly) gets us away from the well-tested existing implementation. It also may complicate the codebase compared to sticking with just doing a Script v2.0, with the additional execution environment data required for v2.0 scripts cleanly separated out. But all in all, the above isn't too big of a deal. Adding a parameter to OP_CLTV makes it much more flexible and is the most economic use of precious NOPs. The extra time required is ok and it would be good to make this change to the PR in time for the feature freeze. Done! https://github.com/bitcoin/bitcoin/pull/5496#issuecomment-100454263 -- 'peter'[:-1]@petertodd.org 12c438a597ad15df697888be579f4f818a30517cd60fbdc8 signature.asc Description: Digital signature -- 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
RE: fixing sigop counting, and building in UTXO cost: great idea! One of the problems with this debate is it is easy for great ideas get lost in all the noise. RE: a hard upper limit, with a dynamic limit under it: I like that idea. Can we drill down on the hard upper limit? There are lots of people who want a very high upper limit, right now (all the big Bitcoin companies, and anybody who thinks as-rapid-as-possible growth now is the best path to long-term success). This is the it is OK if you have to run full nodes in a data center camp. There are also lots of people who want an upper limit low enough that they can continue to run Bitcoin on the hardware and Internet connection that they have (or are concerned about centralization, so want to make sure OTHER people can continue to run). Is there an upper limit we can choose to make both sets of people mostly happy? I've proposed must be inexpensive enough that a 'hobbyist' can afford to run a full node ... Is the limit chosen once, now, via hard-fork, or should we expect multiple hard-forks to change it when necessary ? The economics change every time the block reward halves, which make me think that might be a good time to adjust the hard upper limit. If we have a hard upper limit and a lower dynamic limit, perhaps adjusting the hard upper limit (up or down) to account for the block reward halving, based on the dynamic limit RE: the lower dynamic limit algorithm: I REALLY like that idea. -- -- Gavin Andresen -- 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] Bitcoin-development Digest, Vol 48, Issue 41
On Sat, May 09, 2015 at 12:42:08AM +, Gregory Maxwell wrote: On Sat, May 9, 2015 at 12:00 AM, Damian Gomez dgomez1...@gmail.com wrote: where w represents the weight of the total number of semantical constraints that an idivdual has expressed throught emotivoe packets that I am working on (implementation os difficutlt). I think this is the appropriate route to implemeting a greating block size that will be used in preventing interception of bundled informations and replace value. Client side implmentation will cut down transaction fees for the additional 264 bit implementation and greatly reduce need for ewallet providers to do so. In these posts I am reminded of and sense some qualitative similarities with a 2012 proposal by Mr. NASDAQEnema of Bitcointalk with respect to multigenerational token architectures. In particula,r your AES ModuleK Hashcodes (especially in light of Winternitz compression) may constitute an L_2 norm attractor similar to the motherbase birthpoint metric presented in that prior work. Rethaw and I provided a number of points for consideration which may be equally applicable to your work: https://bitcointalk.org/index.php?topic=57253.msg682056#msg682056 Mr Gomez may find my thesis paper on the creation of imitations of reality with the mathematical technique of Bolshevik Statistics (BS) to be of aid: https://s3.amazonaws.com/peter.todd/congestion.pdf -- 'peter'[:-1]@petertodd.org 00b0388c459b9aff8a93d02bbb87aac6d74b65e9faf7e4c9 signature.asc Description: Digital signature -- 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 9, 2015 at 12:58 PM, Gavin Andresen gavinandre...@gmail.com wrote: RE: fixing sigop counting, and building in UTXO cost: great idea! One of the problems with this debate is it is easy for great ideas get lost in all the noise. If the UTXO set cost is built in, UTXO database entries suddenly are worth something, in addition to the bitcoin held in that entry. A user's client might display how many they own. When sending money to a merchant, the user might demand the merchant indicate a slot to pay to. The user could send an ANYONE_CAN_PAY partial transaction. The transaction would guarantee that the user has at least as many UTXOs as before. Discussing the possibility of doing this creates an incentive to bloat the UTXO set right now, since UTXOs would be valuable in the future. The objective would be to make them valuable enough to encourage conservation, but not so valuable that the UTXO contains more value than the bitcoins in the output. Gmaxwell's suggested tx_size = MAX( real_size 1, real_size + 4*utxo_created_size - 3*utxo_consumed_size) for a 250 byte transaction with 1 input and 2 outputs has very little effect. real_size + 4 * (2) - 3 * 1 = 255 That gives a 2% size penalty for adding an extra UTXO. I doubt that is enough to change behavior. The UTXO set growth could be limited directly. A block would be invalid if it increases the number of UTXO entries above the charted path. RE: a hard upper limit, with a dynamic limit under it: If the block is greater than 32MB, then it means an update to how blocks are broadcast, so that could be a reasonable hard upper limit (or maybe 31MB, or just the 20MB already suggested). -- 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/09/2015 02:02 PM, Andrew wrote: The nice thing about 1 MB is that you can store ALL bitcoin transactions relevant to your lifetime (~100 years) on one 5 TB hard drive (1*6*24*365*100=5256000). Any regular person can run a full node and store this 5 TB hard drive easily at their home. With 10 MB blocks you need a 50 TB drive just for your bitcoin transactions! This is not doable for most regular people due to space and monetary constraints. Being able to review all transactions relevant to your lifetime is one of the key important properties of Bitcoin. How else can people audit the financial transactions of companies and governments that are using the Bitcoin blockchain? How else can we achieve this level of transparency that is essential to keeping corrupt governments/companies in check? How else can we keep track of our own personal transactions without relying on others to keep track of them for us? As time passes, storage technology may increase, but so may human life expectancy. So yes, in this sense, 1 MB just may be the magic number. How many individuals and companies do you propose will ever use Bitcoin (order of magnitude estimates are fine) Whatever number you select above, please describe approximately how many lifetime Bitcoin transactions each individual and company will be capable of performing with a 1 MB block size limit. -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJVTgNcAAoJECpf2nDq2eYjM8AP/2kwSF+HMPR1KdaZsATL4rog xSS97Q5iEX8StA61jUqHQmpXL5pG6z5DeeKT/liwcMnYnVqOEOLvoVctr3gXfgRz 9GJeTOlmN5l9xBeX/nWa0A2ql0kWZpYolBS1FwYadWReAD8R0X9UeBd9YXLZNy33 Ow9JjwRjKHhsuyrlMP8pRDKlGPoa/U+2aW4FwiysMLa0Gu6dbFjTrp3bHw4Fccpi X0E/aDN68U4FV+lZ4NzkMsBK9VARzmC8KI0DQ540pqfkcnyoYf0VERl/gslPWhfq t6Rqa7vHHMqFe82lgCd3ji8Qhsz8oBrDS4u4jqwATvgihgImOB6K85JoKmf3y2JS jByjMGd4Ep0F80Z2MRhi6HuEoRU69uY2u6l9bZxMjzvLX8sG6QTNk3uLMS3ARXcY JBjZ/g13DXgcRj01fq05CHbCTJYZgTA9pRZTY+ZKH4r0mu86b9ua7hjvyKHS6q54 uaFmRkNcnKlpCY+fvH/JUdvvmwrA0ETUdHhRyk8vzWIMi+aH4//GwrCmBNRrugzv 9JtQ1BC+tQqtSX2VkFEhAVISitgkBqurVVlGk18FvVKPFO8cnFS/6NWoPE0WLLzW 2pTuhEPjdz9UAHD3RW601rb4C0LbuwVlGO4tYBjyqCmk/vBlES2XIjQKctXZLBEy eLgn3gMwEXUTU6UdGyvb =RPhK -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- 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 09, 2015 at 01:36:56AM +0300, Joel Joonatan Kaartinen wrote: such a contract is a possibility, but why would big owners give an exclusive right to such pools? It seems to me it'd make sense to offer those for any miner as long as the get paid a little for it. Especially when it's as simple as offering an incomplete transaction with the appropriate SIGHASH flags. Like many things, the fact that they need to negotiate the right at all is a *huge* barrier to smaller mining operations, as well as being an attractive point of control for regulators. a part of the reason I like this idea is because it will allow stakeholders a degree of influence on how large the fees are. At least from the surface, it looks like incentives are pretty well matched. They have an incentive to not let the fees drop too low so the network continues to be usable and they also have an incentive to not raise them too high because it'll push users into using other systems. Also, there'll be competition between stakeholders, which should keep the fees reasonable. If you want to allow stakeholders influence you should look into John Dillon's proof-of-stake blocksize voting scheme: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html -- 'peter'[:-1]@petertodd.org 0e7980aab9c096c46e7f34c43a661c5cb2ea71525ebb8af7 signature.asc Description: Digital signature -- 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
On Sat, May 9, 2015 at 12:53 PM, Justus Ranvier justusranv...@riseup.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/09/2015 02:02 PM, Andrew wrote: The nice thing about 1 MB is that you can store ALL bitcoin transactions relevant to your lifetime (~100 years) on one 5 TB hard drive (1*6*24*365*100=5256000). Any regular person can run a full node and store this 5 TB hard drive easily at their home. With 10 MB blocks you need a 50 TB drive just for your bitcoin transactions! This is not doable for most regular people due to space and monetary constraints. Being able to review all transactions relevant to your lifetime is one of the key important properties of Bitcoin. How else can people audit the financial transactions of companies and governments that are using the Bitcoin blockchain? How else can we achieve this level of transparency that is essential to keeping corrupt governments/companies in check? How else can we keep track of our own personal transactions without relying on others to keep track of them for us? As time passes, storage technology may increase, but so may human life expectancy. So yes, in this sense, 1 MB just may be the magic number. How many individuals and companies do you propose will ever use Bitcoin (order of magnitude estimates are fine) Whatever number you select above, please describe approximately how many lifetime Bitcoin transactions each individual and company will be capable of performing with a 1 MB block size limit. I would expect at least 10 billion people (directly or indirectly) to be using it at once for at least 100 years. But I think it's pointless to guess how many will use it, but rather make the system ready for 10 billion people. The point is that for small transactions, they will be done off-chain. The actual Bitcoin blockchain will only show very large transactions (such as a military purchasing a new space shuttle) or aggregate transactions (i.e. a transaction consisting of multiple smaller transactions done off-chain). There can also be multiple layers of chains creating a tree-like structure. Each chain above will validate the aggregate transactions of the chain below. You can think of the Bitcoin blockchain as the hypervisor that manages all the other chains. While your coffee purchase 4 days ago may not be directly visible within the Bitcoin blockchain (the main chain), you can trace it down the sequence of chains until you find it. Same with that fancy dinner your government MP paid for using public funds. You don't have to store a copy of all transactions that occurred for each chain in existence, but rather just the transactions for the chains that you use or are relevant to you. As you see, this kind of system is totally transparent to all users and totally flexible (you can choose your sub chains). The flexibility also allows you to have arbitrarily fast transactions (choose a chain or lightning channel attached to that chain that supports it), and you can enjoy a wide variety of features from other chains, like using one chain that is known to have good anonymity properties. -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJVTgNcAAoJECpf2nDq2eYjM8AP/2kwSF+HMPR1KdaZsATL4rog xSS97Q5iEX8StA61jUqHQmpXL5pG6z5DeeKT/liwcMnYnVqOEOLvoVctr3gXfgRz 9GJeTOlmN5l9xBeX/nWa0A2ql0kWZpYolBS1FwYadWReAD8R0X9UeBd9YXLZNy33 Ow9JjwRjKHhsuyrlMP8pRDKlGPoa/U+2aW4FwiysMLa0Gu6dbFjTrp3bHw4Fccpi X0E/aDN68U4FV+lZ4NzkMsBK9VARzmC8KI0DQ540pqfkcnyoYf0VERl/gslPWhfq t6Rqa7vHHMqFe82lgCd3ji8Qhsz8oBrDS4u4jqwATvgihgImOB6K85JoKmf3y2JS jByjMGd4Ep0F80Z2MRhi6HuEoRU69uY2u6l9bZxMjzvLX8sG6QTNk3uLMS3ARXcY JBjZ/g13DXgcRj01fq05CHbCTJYZgTA9pRZTY+ZKH4r0mu86b9ua7hjvyKHS6q54 uaFmRkNcnKlpCY+fvH/JUdvvmwrA0ETUdHhRyk8vzWIMi+aH4//GwrCmBNRrugzv 9JtQ1BC+tQqtSX2VkFEhAVISitgkBqurVVlGk18FvVKPFO8cnFS/6NWoPE0WLLzW 2pTuhEPjdz9UAHD3RW601rb4C0LbuwVlGO4tYBjyqCmk/vBlES2XIjQKctXZLBEy eLgn3gMwEXUTU6UdGyvb =RPhK -END PGP SIGNATURE- -- 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 -- PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647 -- 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.
Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database
Actually your assumption is wrong. Bitcoin Wallet (and I think most, if not all, other bitcoinj based wallets) picks UTXO by age, in order to maximize priority. So it keeps the number of UTXOs low, though not as low as if it would always pick *all* UTXOs. On 05/09/2015 07:09 PM, Jim Phillips wrote: Forgive me if this idea has been suggested before, but I made this suggestion on reddit and I got some feedback recommending I also bring it to this list -- so here goes. I wonder if there isn't perhaps a simpler way of dealing with UTXO growth. What if, rather than deal with the issue at the protocol level, we deal with it at the source of the problem -- the wallets. Right now, the typical wallet selects only the minimum number of unspent outputs when building a transaction. The goal is to keep the transaction size to a minimum so that the fee stays low. Consequently, lots of unspent outputs just don't get used, and are left lying around until some point in the future. What if we started designing wallets to consolidate unspent outputs? When selecting unspent outputs for a transaction, rather than choosing just the minimum number from a particular address, why not select them ALL? Take all of the UTXOs from a particular address or wallet, send however much needs to be spent to the payee, and send the rest back to the same address or a change address as a single output? Through this method, we should wind up shrinking the UTXO database over time rather than growing it with each transaction. Obviously, as Bitcoin gains wider adoption, the UTXO database will grow, simply because there are 7 billion people in the world, and eventually a good percentage of them will have one or more wallets with spendable bitcoin. But this idea could limit the growth at least. The vast majority of users are running one of a handful of different wallet apps: Core, Electrum; Armory; Mycelium; Breadwallet; Coinbase; Circle; Blockchain.info; and maybe a few others. The developers of all these wallets have a vested interest in the continued usefulness of Bitcoin, and so should not be opposed to changing their UTXO selection algorithms to one that reduces the UTXO database instead of growing it. From the miners perspective, even though these types of transactions would be larger, the fee could stay low. Miners actually benefit from them in that it reduces the amount of storage they need to dedicate to holding the UTXO. So miners are incentivized to mine these types of transactions with a higher priority despite a low fee. Relays could also get in on the action and enforce this type of behavior by refusing to relay or deprioritizing the relay of transactions that don't use all of the available UTXOs from the addresses used as inputs. Relays are not only the ones who benefit the most from a reduction of the UTXO database, they're also in the best position to promote good behavior. -- *James G. Phillips IV* https://plus.google.com/u/0/113107039501292625391/posts /Don't bunt. Aim out of the ball park. Aim for the company of immortals. -- David Ogilvy / /This message was created with 100% recycled electrons. Please think twice before printing./ -- 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 -- 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] A suggestion for reducing the size of the UTXO database
On Sat, May 9, 2015 at 1:45 PM, Peter Todd p...@petertodd.org wrote: On Sat, May 09, 2015 at 12:09:32PM -0500, Jim Phillips wrote: The vast majority of users are running one of a handful of different wallet apps: Core, Electrum; Armory; Mycelium; Breadwallet; Coinbase; Circle; Blockchain.info; and maybe a few others. The developers of all these wallets have a vested interest in the continued usefulness of Bitcoin, and so should not be opposed to changing their UTXO selection algorithms to one that reduces the UTXO database instead of growing it. You can't assume that UTXO growth will be driven by walles at all; the UTXO set's global consensus functionality is incredibly useful and will certainly be used by all manner of applications, many having nothing to do with Bitcoin. You're correct in this point. Future UTXO growth will be coming from all directions. But I'm a believer in the idea that whatever can be done should be done. If we get Bitcoin devs into the mindset now that UTXOs are expensive to those that have to store them, and that they should be good netizens and do what they can to limit them, then hopefully that will ideal will be passed down to future developers. I don't believe consolidating UTXOs in the wallet is the only solution.. I just think it is a fairly easy one to implement, and can only help the problem from getting worse in the future. -- *James G. Phillips IV* https://plus.google.com/u/0/113107039501292625391/posts http://www.linkedin.com/in/ergophobe *Don't bunt. Aim out of the ball park. Aim for the company of immortals. -- David Ogilvy* *This message was created with 100% recycled electrons. Please think twice before printing.* -- 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] A suggestion for reducing the size of the UTXO database
It's a very complex trade-off, which is hard to optimize for all use cases. Using more UTXOs requires larger transactions, and thus more fees in general. In addition, it results in more linkage between coins/addresses used, so lower privacy. The only way you can guarantee an economical reason to keep the UTXO set small is by actually having a consensus rule that punishes increasing its size. On May 9, 2015 12:02 PM, Andreas Schildbach andr...@schildbach.de wrote: Actually your assumption is wrong. Bitcoin Wallet (and I think most, if not all, other bitcoinj based wallets) picks UTXO by age, in order to maximize priority. So it keeps the number of UTXOs low, though not as low as if it would always pick *all* UTXOs. On 05/09/2015 07:09 PM, Jim Phillips wrote: Forgive me if this idea has been suggested before, but I made this suggestion on reddit and I got some feedback recommending I also bring it to this list -- so here goes. I wonder if there isn't perhaps a simpler way of dealing with UTXO growth. What if, rather than deal with the issue at the protocol level, we deal with it at the source of the problem -- the wallets. Right now, the typical wallet selects only the minimum number of unspent outputs when building a transaction. The goal is to keep the transaction size to a minimum so that the fee stays low. Consequently, lots of unspent outputs just don't get used, and are left lying around until some point in the future. What if we started designing wallets to consolidate unspent outputs? When selecting unspent outputs for a transaction, rather than choosing just the minimum number from a particular address, why not select them ALL? Take all of the UTXOs from a particular address or wallet, send however much needs to be spent to the payee, and send the rest back to the same address or a change address as a single output? Through this method, we should wind up shrinking the UTXO database over time rather than growing it with each transaction. Obviously, as Bitcoin gains wider adoption, the UTXO database will grow, simply because there are 7 billion people in the world, and eventually a good percentage of them will have one or more wallets with spendable bitcoin. But this idea could limit the growth at least. The vast majority of users are running one of a handful of different wallet apps: Core, Electrum; Armory; Mycelium; Breadwallet; Coinbase; Circle; Blockchain.info; and maybe a few others. The developers of all these wallets have a vested interest in the continued usefulness of Bitcoin, and so should not be opposed to changing their UTXO selection algorithms to one that reduces the UTXO database instead of growing it. From the miners perspective, even though these types of transactions would be larger, the fee could stay low. Miners actually benefit from them in that it reduces the amount of storage they need to dedicate to holding the UTXO. So miners are incentivized to mine these types of transactions with a higher priority despite a low fee. Relays could also get in on the action and enforce this type of behavior by refusing to relay or deprioritizing the relay of transactions that don't use all of the available UTXOs from the addresses used as inputs. Relays are not only the ones who benefit the most from a reduction of the UTXO database, they're also in the best position to promote good behavior. -- *James G. Phillips IV* https://plus.google.com/u/0/113107039501292625391/posts /Don't bunt. Aim out of the ball park. Aim for the company of immortals. -- David Ogilvy / /This message was created with 100% recycled electrons. Please think twice before printing./ -- 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 -- 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] A suggestion for reducing the size of the UTXO database
On Sat, May 9, 2015 at 2:00 PM, Andreas Schildbach andr...@schildbach.de wrote: Actually your assumption is wrong. Bitcoin Wallet (and I think most, if not all, other bitcoinj based wallets) picks UTXO by age, in order to maximize priority. So it keeps the number of UTXOs low, though not as low as if it would always pick *all* UTXOs. Is it not fair to say though that UTXO database growth is not considered when selecting the UTXOs to use? And that size of transaction is a priority if not the top priority? -- 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] A suggestion for reducing the size of the UTXO database
On Sat, May 9, 2015 at 2:06 PM, Pieter Wuille pieter.wui...@gmail.com wrote: It's a very complex trade-off, which is hard to optimize for all use cases. Using more UTXOs requires larger transactions, and thus more fees in general. Unless the miner determines that the reduction in UTXO storage requirements is worth the lower fee. There's no protocol level enforcement of a fee as far as I understand it. It's enforced by the miners and their willingness to include a transaction in a block. In addition, it results in more linkage between coins/addresses used, so lower privacy. Not if you only select all the UTXOs from a single address. A wallet that is geared more towards privacy minded individuals may want to reduce the amount of address linkage, but a wallet geared towards the general masses probably won't have to worry so much about that. The only way you can guarantee an economical reason to keep the UTXO set small is by actually having a consensus rule that punishes increasing its size. There's an economical reason right now to keeping the UTXO set small. The smaller it is, the easier it is for the individual to run a full node. The easier it is to run a full node, the faster Bitcoin will spread to the masses. The faster it spreads to the masses, the more valuable it becomes. -- 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] A suggestion for reducing the size of the UTXO database
Lack of privacy is viral. We shouldn't encourage policy in most wallets that discourages privacy. It adversely affects privacy across the entire network. On 9 May 2015 12:17 pm, Jim Phillips j...@ergophobia.org wrote:On Sat, May 9, 2015 at 2:06 PM, Pieter Wuille pieter.wuille@gmail.com wrote:Its a very complex trade-off, which is hard to optimize for all use cases. Using more UTXOs requires larger transactions, and thus more fees in general. Unless the miner determines that the reduction in UTXO storage requirements is worth the lower fee. Theres no protocol level enforcement of a fee as far as I understand it. Its enforced by the miners and their willingness to include a transaction in a block.In addition, it results in more linkage between coins/addresses used, so lower privacy. Not if you only select all the UTXOs from a single address. A wallet that is geared more towards privacy minded individuals may want to reduce the amount of address linkage, but a wallet geared towards the general masses probably wont have to worry so much about that. The only way you can guarantee an economical reason to keep the UTXO set small is by actually having a consensus rule that punishes increasing its size.Theres an economical reason right now to keeping the UTXO set small. The smaller it is, the easier it is for the individual to run a full node. The easier it is to run a full node, the faster Bitcoin will spread to the masses. The faster it spreads to the masses, the more valuable it becomes. -- 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] A suggestion for reducing the size of the UTXO database
On Sat, May 9, 2015 at 2:12 PM, Patrick Mccorry (PGR) patrick.mcco...@newcastle.ac.uk wrote: Not necessarily. If you want to ensure privacy, you could limit the selection of UTXOs to a single address, and even go so far as to send change back to that same address. This wouldn't be as effective as combining the UTXOs from multiple addresses, but it would help. The key is to do everything that can be done when building a transaction to ensure that as many inputs as possible are consolidated into as few outputs as possible. I would agree if you have multiple utxo for a single address then it makes sense since there is no privacy loss. However sending the change back to the same address would damage privacy (Hive does this) as it is then obvious from looking at the transaction which output is change and which output is sending funds. I tend to agree with you here. But the change output could just as easily be sent to a new change address. Also not everyone is concerned with their own privacy, and I'm not aware of any HD-wallet implementations that won't already combine inputs from multiple addresses within that wallet without user input. For people who do not care for privacy then it would work fine. But adding it into the wallet as default behaviour would deter those who do care for privacy - and making it a customisable option just adds complexity for the users. Wallets do need to combine utxo at times to spend bitcoins which is how people can be tracked today, using the minimum set of utxo tries to reduce the risk. Different wallets are targeted at different demographics. Some are geared towards more mainstream users (for whom the privacy issue is less a concern) and some (such as DarkWallet) are geared more towards the privacy advocates. These wallets may choose to set their defaults at oposite ends of the spectrum as to how they choose to select and link addresses and UTXOs, but they can all improve on their current algorithms and promote some degree of consolidation. Additionally, large wallets that have lots of addresses owned by multiple users like exchanges, blockchain.info, and Coinbase can consolidate UTXOs very effectively when building transactions That's true - I'm not sure how they would feel about it though. I imagine they probably are already to minimise key management. That's what these discussions are for. Hopefully this thread will be seen by developers of these wallets and give them something to consider. -- 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] A suggestion for reducing the size of the UTXO database
On Sat, May 9, 2015 at 2:25 PM, Raystonn rayst...@hotmail.com wrote: Lack of privacy is viral. We shouldn't encourage policy in most wallets that discourages privacy. It adversely affects privacy across the entire network. How about this as a happy medium default policy: Rather than select UTXOs based solely on age and limiting the size of the transaction, we select as many UTXOs as possible from as few addresses as possible, prioritizing which addresses to use based on the number of UTXOs it contains (more being preferable) and how old those UTXOs are (in order to reduce the fee)? -- 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] A suggestion for reducing the size of the UTXO database
If selecting older UTXOs gives higher priority for a lesser (or at least not greater) fee, that is an incentive for a rational user to use the older UTXOs. Such policy needs to be defended or removed. It doesn't support privacy or a reduction in UTXOs. On 9 May 2015 12:33 pm, Jim Phillips j...@ergophobia.org wrote:On Sat, May 9, 2015 at 2:25 PM, Raystonn raystonn@hotmail.com wrote:Lack of privacy is viral. We shouldnt encourage policy in most wallets that discourages privacy. It adversely affects privacy across the entire network.How about this as a happy medium default policy: Rather than select UTXOs based solely on age and limiting the size of the transaction, we select as many UTXOs as possible from as few addresses as possible, prioritizing which addresses to use based on the number of UTXOs it contains (more being preferable) and how old those UTXOs are (in order to reduce the fee)? -- 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] A suggestion for reducing the size of the UTXO database
I think potential fee subsidies for cleaning up UTXO (and/or penalties for creating more UTXO than you burn) are worth thinking about. As Gavin's post ( gavinandresen.ninja/utxo-uhoh ) indicates, UTXO cost is far higher than block storage, so charging differently for the in/out mismatches should make good economic sense. Ross On 09/05/2015 20:16, Jim Phillips wrote: On Sat, May 9, 2015 at 2:06 PM, Pieter Wuille pieter.wui...@gmail.com mailto:pieter.wui...@gmail.com wrote: It's a very complex trade-off, which is hard to optimize for all use cases. Using more UTXOs requires larger transactions, and thus more fees in general. Unless the miner determines that the reduction in UTXO storage requirements is worth the lower fee. There's no protocol level enforcement of a fee as far as I understand it. It's enforced by the miners and their willingness to include a transaction in a block. In addition, it results in more linkage between coins/addresses used, so lower privacy. Not if you only select all the UTXOs from a single address. A wallet that is geared more towards privacy minded individuals may want to reduce the amount of address linkage, but a wallet geared towards the general masses probably won't have to worry so much about that. The only way you can guarantee an economical reason to keep the UTXO set small is by actually having a consensus rule that punishes increasing its size. There's an economical reason right now to keeping the UTXO set small. The smaller it is, the easier it is for the individual to run a full node. The easier it is to run a full node, the faster Bitcoin will spread to the masses. The faster it spreads to the masses, the more valuable it becomes. -- 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 -- 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] A suggestion for reducing the size of the UTXO database
On Sat, May 9, 2015 at 2:43 PM, Raystonn rayst...@hotmail.com wrote: How about this as a happy medium default policy: Rather than select UTXOs based solely on age and limiting the size of the transaction, we select as many UTXOs as possible from as few addresses as possible, prioritizing which addresses to use based on the number of UTXOs it contains (more being preferable) and how old those UTXOs are (in order to reduce the fee)? If selecting older UTXOs gives higher priority for a lesser (or at least not greater) fee, that is an incentive for a rational user to use the older UTXOs. Such policy needs to be defended or removed. It doesn't support privacy or a reduction in UTXOs. Before starting this thread, I had completely forgotten that age was even a factor in determining which UTXOs to use. Frankly, I can't think of any reason why miners care how old a particular UTXO is when determining what fees to charge. I'm sure there is one, I just don't know what it is. I just tossed it in there as homage to Andreas who pointed out to me that it was still part of the selection criteria. -- 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
