Re: [Bitcoin-development] Economics of information propagation
On Mon, Apr 21, 2014 at 01:30:28AM +, Jonathan Levin wrote: CC'ing bitcoin-research - may be more appropriate to move the discussion there as this discussion is delving into future scenarios. Hi all, I am a post-graduate economist writing a paper on the incentives of mining. Even though this issue has been debated in the forums, I think it is important to get a sense of the magnitude of the incentives at play and determine what implications this has for the transaction fee market. As it has been pointed out before the marginal cost for miners does not stem from the private cost of the miner validating the signature and including it in the list of transactions in the block but rather the increased probability that the block will be orphaned as a result of slower propagation. Gavin did some back of the envelope worst case calculations but these overstated the effect of propagation delay. The reason being the 80ms additional time to reach 50% of the network is spread throughout the time that it takes to reach 50% of the network. During this time miners are notified about the block and treat it as the longest chain and hence are no longer mining with the aim to produce a competing block. I am looking to calculate the change in the curvature of the probability mass function that a block hears about my block in any given second as a function of the block size. Although there is likely to be significant noise here, there seems to be some stable linear relationships with the time that it takes to reach different quartiles. Has anyone done this? I have used some empirical data that I am happy to share but ideally I would like analytical solutions. Following Peter Todd, I also find the concerning result that propagation delays results in increasing returns to higher shares of the hashing power. Indeed it may well be in the interest of large pools to publish large blocks to increase propagation delays on the network which would increase orphan rates particularly for small miners and miners that have not invested in sufficient bandwidth / connectivity. If a small miner hears about a block after 4.5 seconds on average there is a 0.7% chance that there is already a block in circulation. Large miners can increase the time that it takes for small miners to hear about blocks by increasing the size of their blocks. For example if the time that it takes for a small miner to hear about the block goes to 12 seconds there is a 2 percent chance there is already a block in circulation for the small miner. There is also a 1.2% chance that there will be a competing block published after a small miner propagates in the time that it gets to full propagation. Am I getting this right that the probability of a miner’s block being orphaned is comprised of the probability that the miner was not the first to find a valid block and the probability that given they are first, someone else in the absence of hearing about it finds a competing valid block. One question is: Are orphans probabilistic and only resolved after hearing about a new block that lengthens the chain or is there a way to know in advance? They're probabilistic; mining is progress free so per unit hashing power every miner has an equal chance of finding a block. As for resolution, well, currently nodes (and miners) mine on the block they saw first; if they learn about another block at the same height they stick to the block they are already mining on. First seen at same height is probably generally economically rational as the first block you see probably propagated to the most nodes, although tweaks to that are probably possible. Is it frowned upon to mine on top of a block that you have just found even though it is very likely going to end up an orphan? Not at all, in fact mining on top of the block is the best thing to do because it *prevents* your block from ending up as an orphan. Basically imagine I find block b1a, and you find conflicting block b1b. What I need to do is find block b2a, which is on top of b1a, before you find block b1b to avoid my block being orphaned. The best way to do that is mining on top of my block - that's what's most rational for me. Would be happy to share the draft form of the paper and receive any feedback. Sure thing. Finally, at coinometrics we are working on a modified client to capture information on network propagation and would invite any suggestions of any other useful statistics that would be useful in the development of software. So looking at the replies your post got in the past few days it looks like there's some misinformation going around. First of all is the question of how harmful it is if miners mine on top of blocks that they haven't actually validated, and yes, that's extremely harmful. For instance if I were an attacker I could mine an invalid block that makes coins out of thin air and use it to defraud
Re: [Bitcoin-development] Economics of information propagation
Jonathan - These are a few things I've been wishing for recent data on: - 95th percentile transaction propagation time vs. fees/kb, vs. total fees - Count of blocks bypassing well-propagated transactions vs. fees/kb, vs. total fees - Signed-double-spend confirmation probability vs. broadcast time offset from first spend On 4/20/2014 5:30 PM, Jonathan Levin wrote: at coinometrics we are working on a modified client to capture information on network propagation and would invite any suggestions of any other useful statistics that would be useful in the development of software. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Economics of information propagation
On Mon, Apr 21, 2014 at 5:06 AM, Peter Todd p...@petertodd.org wrote: Of course, in reality smaller miners can just mine on top of block headers and include no transactions and do no validation, but that is extremely harmful to the security of Bitcoin. I don't think it reduces security much. It is extremely unlikely that someone would publish an invalid block, since they would waste their POW. Presuming that new headers are correct is reasonable, as long as you check the full block within a few minutes of receiving the header. If anything, it increases security, since less hashing power is wasted while the full block is broadcast. Block propagation could take the form - broadcast new header - all miners switch to mining empty blocks - broadcast new block - miners update to a block with transactions If the block doesn't arrive within a timeout, then the miner could switch back to the old block. This would mean that a few percent of empty blocks end up in the blockchain, but that doesn't do any harm. It is only harmful, if it is used as a DOS attack on the network. The empty blocks will only occur when 2 blocks are found in quick succession, so it doesn't have much affect on average time until 1 confirm. Empty blocks are just as good for providing 1 of the 6 confirms needed too. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Economics of information propagation
I'm not convinced that headers first will result in miners hashing on top of the block with more work without knowing if it's valid yet instead of just keep hashing on top of the longest known-to-be-valid chain. Both options are risky for the miner in some way, and I guess the probability of someone hashing an invalid block above difficulty is too low to be the main concern, but there's intermediate solutions, like say, waiting to validate at least 5% of the block. But I don't see how miners mining headers first would result in empty blocks either. Why wouldn't them validate and include transactions after they have received the full block? They will likely know most of the transaction before receiving the block anyway. In a future where they ONLY live on transaction fees, why would they refuse to validate and include transactions? What are they hashing for then? If anything, looks like a threat to the current situation with huge mining subsidies coming from the seigniorage, not a problem that you would have when the the seigniorage is gone. In any case, it is true that this is mining policy and therefore out of the realm of what the protocol can regulate, so we should assume miners will do whatever it's best for them. The trade-off between tps and centralization remains: if you want higher tx volume, less full nodes will be able to process it. On 4/21/14, Tier Nolan tier.no...@gmail.com wrote: On Mon, Apr 21, 2014 at 5:06 AM, Peter Todd p...@petertodd.org wrote: Of course, in reality smaller miners can just mine on top of block headers and include no transactions and do no validation, but that is extremely harmful to the security of Bitcoin. I don't think it reduces security much. It is extremely unlikely that someone would publish an invalid block, since they would waste their POW. Presuming that new headers are correct is reasonable, as long as you check the full block within a few minutes of receiving the header. If anything, it increases security, since less hashing power is wasted while the full block is broadcast. Block propagation could take the form - broadcast new header - all miners switch to mining empty blocks - broadcast new block - miners update to a block with transactions If the block doesn't arrive within a timeout, then the miner could switch back to the old block. This would mean that a few percent of empty blocks end up in the blockchain, but that doesn't do any harm. It is only harmful, if it is used as a DOS attack on the network. The empty blocks will only occur when 2 blocks are found in quick succession, so it doesn't have much affect on average time until 1 confirm. Empty blocks are just as good for providing 1 of the 6 confirms needed too. -- Jorge Timón http://freico.in/ -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Economics of information propagation
On 04/21/2014 11:40 AM, Ashley Holman wrote: On Mon, Apr 21, 2014 at 1:36 PM, Peter Todd p...@petertodd.org mailto:p...@petertodd.org wrote: That is mistaken: you can't mine on top of just a block header, leaving small miners disadvantaged as they are earning no profit while they wait for the information to validate the block and update their UTXO sets. This results in the same problem as before, as the large pools who mine most blocks can validate either instantly - the self-mine case - or more quickly than the smaller miners. Under the headers first scenario, wouldn't the full block still reach everyone in the same time as it would under the current rules? So the small miner loses nothing in terms of updating their UTXO set, but gains an early heads up alert that a new block is coming. This allows them spend the propagation time working more productively on an empty block in the new chain rather than wasting time on an orphan. It's true that it doesn't solve the problem of larger pools vs smaller pools, but if it doesn't make it any worse then headers-first propagation would be a net benefit to the network since it removes the incentive to make small blocks. I think the most important part is that nodes can reliably decide on first received, regardless of how they subsequently act on it. I believe it would be fine for a node to receive a header and continue mining the old block, or a subsequently-verified competing block, until it has the necessary pieces to fully verify the first header received. If that block data doesn't come, then it will be naturally ignored. But if multiple blocks come at once, even if a competing block verifies first, the node would still switch to considering the first header received as the best block when it later receives proof it is valid (which may only be a couple seconds). In other words, the node will always consider the header-received time as the primary ordering criteria, but will not mine on anything until it has full proof of validity, even if /that/ is out of order. This means that new blocks effectively propagate at the speed of 80 bytes, which limits certain kinds of block-injection/racing attacks. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Economics of information propagation
That wasn't what I was saying. Right now the primacy of a block is determined by the time at which the `block` message is received, which is delays due to both the time it takes to transmit the block data and the time it takes to validate. Headers-first, on the other hand, has the option of basing primacy on the time the block header is received, which is O(1) time to transmit and to SPV-validate. Mining on that block doesn't actually commence until the full block is received and validated. To see how this works, take an example: two blocks with a common parent are found relatively close to each other, block A and block B. A is found first but is a large block with the maximum block size and many slow scripts. B is found a few seconds later and is an empty block. In the current regime it is entirely possible that block B, the later but smaller block, would get received and processed first by more mining peers than the larger block A, exactly as described in Jonathan Levin's email. With headers-first, however, the cost of propagation of the block header is the same and we should expect block A to win out over block B nearly every time. Miners will continue working on the old, known valid parent block until the contents of block A are received and processed. So the smaller block B is still found, and since it's data moves across the network faster, miners even briefly mine on block B. But as soon as they receive and process the contents of block A, they switch to that. The earlier, larger block A will only become stale if *two* blocks are found in the extra time it takes for block A to propagate the network. That is a substantially different risk, and probably a negligible concern to most miners. On 04/20/2014 09:06 PM, Peter Todd wrote: That is mistaken: you can't mine on top of just a block header, leaving small miners disadvantaged as they are earning no profit while they wait for the information to validate the block and update their UTXO sets. This results in the same problem as before, as the large pools who mine most blocks can validate either instantly - the self-mine case - or more quickly than the smaller miners. Of course, in reality smaller miners can just mine on top of block headers and include no transactions and do no validation, but that is extremely harmful to the security of Bitcoin. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Economics of information propagation
I haven't done the math on this, so it may be a terrible idea. :) I've been wondering if block propagation times could also be improved by allowing peers to request the list of transaction hashes that make up a block, and then making a follow-up request to only download any transactions not currently known. I'm not sure what percentage of transactions a node will usually already have when it receives a new block, but if it's high I figure this could be beneficial. Date: Mon, 21 Apr 2014 09:00:09 -0700 From: m...@monetize.io To: p...@petertodd.org; jonathan.le...@sant.ox.ac.uk CC: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Economics of information propagation That wasn't what I was saying. Right now the primacy of a block is determined by the time at which the `block` message is received, which is delays due to both the time it takes to transmit the block data and the time it takes to validate. Headers-first, on the other hand, has the option of basing primacy on the time the block header is received, which is O(1) time to transmit and to SPV-validate. Mining on that block doesn't actually commence until the full block is received and validated. To see how this works, take an example: two blocks with a common parent are found relatively close to each other, block A and block B. A is found first but is a large block with the maximum block size and many slow scripts. B is found a few seconds later and is an empty block. In the current regime it is entirely possible that block B, the later but smaller block, would get received and processed first by more mining peers than the larger block A, exactly as described in Jonathan Levin's email. With headers-first, however, the cost of propagation of the block header is the same and we should expect block A to win out over block B nearly every time. Miners will continue working on the old, known valid parent block until the contents of block A are received and processed. So the smaller block B is still found, and since it's data moves across the network faster, miners even briefly mine on block B. But as soon as they receive and process the contents of block A, they switch to that. The earlier, larger block A will only become stale if *two* blocks are found in the extra time it takes for block A to propagate the network. That is a substantially different risk, and probably a negligible concern to most miners. On 04/20/2014 09:06 PM, Peter Todd wrote: That is mistaken: you can't mine on top of just a block header, leaving small miners disadvantaged as they are earning no profit while they wait for the information to validate the block and update their UTXO sets. This results in the same problem as before, as the large pools who mine most blocks can validate either instantly - the self-mine case - or more quickly than the smaller miners. Of course, in reality smaller miners can just mine on top of block headers and include no transactions and do no validation, but that is extremely harmful to the security of Bitcoin. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Economics of information propagation
Pieter tried it already. If the two nodes views of each others mempools are not exactly in alignment it ends up being slower than just sending the data immediately and redundantly. On Mon, Apr 21, 2014 at 6:38 PM, Mark Friedenbach m...@monetize.io wrote: Yes, it certainly can be improved in this way. You can even extend the idea to distribute partial proofs of work (block headers + Merkle lists which represent significant but not sufficient work), and 'prime' your memory pools with the transactions contained within. This is, btw, basically what p2pool does, which is why last time I calculated you get roughly 1% better return from p2pool than a zero-fee mining pool would get you, specifically because of the lower stale rate. On 04/21/2014 09:22 AM, Paul Lyon wrote: I haven't done the math on this, so it may be a terrible idea. :) I've been wondering if block propagation times could also be improved by allowing peers to request the list of transaction hashes that make up a block, and then making a follow-up request to only download any transactions not currently known. I'm not sure what percentage of transactions a node will usually already have when it receives a new block, but if it's high I figure this could be beneficial. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Economics of information propagation
Thank you for your thoughts. The earlier, larger block A will only become stale if *two* blocks are found in the extra time it takes for block A to propagate the network. That is a substantially different risk, and probably a negligible concern to most miners. I really like Mark’s suggestion but one concern is that it might tip the needle too far. Currently, there is a private cost to include more transactions, which might be too high, but limit the amount of negative externalities that this creates on other miners. If I am able to create blocks that are very likely to be on the main chain with the maximum number of transactions then this makes imposing negative externalities on other miners less costly. Other nodes that are closely connected to me would experience a positive externality through this as well. Would have do some more thinking here but it seems that there is a balance to strike. If anything, looks like a threat to the current situation with huge mining subsidies coming from the seigniorage, not a problem that you would have when the the seigniorage is gone. The incentives remain so long as the ratio of the seignorage revenues to transaction fees remain very high. Even though the dollar price does not change that relationship it does mean that Bitcoin becomes more expensive in USD terms as the USD price of Bitcoin rises. I think the most important part is that nodes can reliably decide on first received, regardless of how they subsequently act on it. If we want to limit the amount of network time spent on redundant problems it would be best for miners to act on this information? What is the benefit of serialisation? Is it that the miner would consider it more likely to make it into the main chain rather than the block that came second? But I don't see how miners mining headers first would result in empty blocks either. I guess it is due to the fact that this is the only way a miner can be certain that none of the transactions have been spent already resulting in an orphan block. On 21 Apr 2014, at 17:00, Mark Friedenbach m...@monetize.io wrote: That wasn't what I was saying. Right now the primacy of a block is determined by the time at which the `block` message is received, which is delays due to both the time it takes to transmit the block data and the time it takes to validate. Headers-first, on the other hand, has the option of basing primacy on the time the block header is received, which is O(1) time to transmit and to SPV-validate. Mining on that block doesn't actually commence until the full block is received and validated. To see how this works, take an example: two blocks with a common parent are found relatively close to each other, block A and block B. A is found first but is a large block with the maximum block size and many slow scripts. B is found a few seconds later and is an empty block. In the current regime it is entirely possible that block B, the later but smaller block, would get received and processed first by more mining peers than the larger block A, exactly as described in Jonathan Levin's email. With headers-first, however, the cost of propagation of the block header is the same and we should expect block A to win out over block B nearly every time. Miners will continue working on the old, known valid parent block until the contents of block A are received and processed. So the smaller block B is still found, and since it's data moves across the network faster, miners even briefly mine on block B. But as soon as they receive and process the contents of block A, they switch to that. The earlier, larger block A will only become stale if *two* blocks are found in the extra time it takes for block A to propagate the network. That is a substantially different risk, and probably a negligible concern to most miners. On 04/20/2014 09:06 PM, Peter Todd wrote: That is mistaken: you can't mine on top of just a block header, leaving small miners disadvantaged as they are earning no profit while they wait for the information to validate the block and update their UTXO sets. This results in the same problem as before, as the large pools who mine most blocks can validate either instantly - the self-mine case - or more quickly than the smaller miners. Of course, in reality smaller miners can just mine on top of block headers and include no transactions and do no validation, but that is extremely harmful to the security of Bitcoin. signature.asc Description: Message signed with OpenPGP using GPGMail -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform
[Bitcoin-development] Economics of information propagation
Hi all, I am a post-graduate economist writing a paper on the incentives of mining. Even though this issue has been debated in the forums, I think it is important to get a sense of the magnitude of the incentives at play and determine what implications this has for the transaction fee market. As it has been pointed out before the marginal cost for miners does not stem from the private cost of the miner validating the signature and including it in the list of transactions in the block but rather the increased probability that the block will be orphaned as a result of slower propagation. Gavin did some back of the envelope worst case calculations but these overstated the effect of propagation delay. The reason being the 80ms additional time to reach 50% of the network is spread throughout the time that it takes to reach 50% of the network. During this time miners are notified about the block and treat it as the longest chain and hence are no longer mining with the aim to produce a competing block. I am looking to calculate the change in the curvature of the probability mass function that a block hears about my block in any given second as a function of the block size. Although there is likely to be significant noise here, there seems to be some stable linear relationships with the time that it takes to reach different quartiles. Has anyone done this? I have used some empirical data that I am happy to share but ideally I would like analytical solutions. Following Peter Todd, I also find the concerning result that propagation delays results in increasing returns to higher shares of the hashing power. Indeed it may well be in the interest of large pools to publish large blocks to increase propagation delays on the network which would increase orphan rates particularly for small miners and miners that have not invested in sufficient bandwidth / connectivity. If a small miner hears about a block after 4.5 seconds on average there is a 0.7% chance that there is already a block in circulation. Large miners can increase the time that it takes for small miners to hear about blocks by increasing the size of their blocks. For example if the time that it takes for a small miner to hear about the block goes to 12 seconds there is a 2 percent chance there is already a block in circulation for the small miner. There is also a 1.2% chance that there will be a competing block published after a small miner propagates in the time that it gets to full propagation. Am I getting this right that the probability of a miner’s block being orphaned is comprised of the probability that the miner was not the first to find a valid block and the probability that given they are first, someone else in the absence of hearing about it finds a competing valid block. One question is: Are orphans probabilistic and only resolved after hearing about a new block that lengthens the chain or is there a way to know in advance? Is it frowned upon to mine on top of a block that you have just found even though it is very likely going to end up an orphan? Would be happy to share the draft form of the paper and receive any feedback. Finally, at coinometrics we are working on a modified client to capture information on network propagation and would invite any suggestions of any other useful statistics that would be useful in the development of software. Best, Jonathan On 21 Apr 2014, at 01:16, bitcoin-development-requ...@lists.sourceforge.net bitcoin-development-requ...@lists.sourceforge.net wrote: Send Bitcoin-development mailing list submissions to bitcoin-development@lists.sourceforge.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/bitcoin-development or, via email, send a message with subject or body 'help' to bitcoin-development-requ...@lists.sourceforge.net You can reach the person managing the list at bitcoin-development-ow...@lists.sourceforge.net When replying, please edit your Subject line so it is more specific than Re: Contents of Bitcoin-development digest... Today's Topics: 1. Re: bits: Unit of account (Oliver Egginger) 2. Re: bits: Unit of account (Christophe Biocca) 3. Re: bits: Unit of account (Gmail) 4. Re: bits: Unit of account (Mike Caldwell) 5. Re: bits: Unit of account (Justin A) -- Message: 1 Date: Sun, 20 Apr 2014 20:43:24 +0200 From: Oliver Egginger bitc...@olivere.de Subject: Re: [Bitcoin-development] bits: Unit of account To: Bitcoin Development bitcoin-development@lists.sourceforge.net Message-ID: 5354154c.1080...@olivere.de Content-Type: text/plain; charset=ISO-8859-1 Hello, just my two 'cents': Terms arises by itself. Just as most people speak of coins when they mean bitcoins. I do not see that bitcoin is currently in common use except for speculation.
Re: [Bitcoin-development] Economics of information propagation
As soon as we switch to headers first - which will be soon - there will be no difference in propagation time no matter how large the block is. Only 80 bites will be required to propagate the block header which establishes priority for when the block is fully validated. On Apr 20, 2014 6:56 PM, Jonathan Levin jonathan.le...@sant.ox.ac.uk wrote: Hi all, I am a post-graduate economist writing a paper on the incentives of mining. Even though this issue has been debated in the forums, I think it is important to get a sense of the magnitude of the incentives at play and determine what implications this has for the transaction fee market. As it has been pointed out before the marginal cost for miners does not stem from the private cost of the miner validating the signature and including it in the list of transactions in the block but rather the increased probability that the block will be orphaned as a result of slower propagation. Gavin did some back of the envelope worst case calculations but these overstated the effect of propagation delay. The reason being the 80ms additional time to reach 50% of the network is spread throughout the time that it takes to reach 50% of the network. During this time miners are notified about the block and treat it as the longest chain and hence are no longer mining with the aim to produce a competing block. I am looking to calculate the change in the curvature of the probability mass function that a block hears about my block in any given second as a function of the block size. Although there is likely to be significant noise here, there seems to be some stable linear relationships with the time that it takes to reach different quartiles. Has anyone done this? I have used some empirical data that I am happy to share but ideally I would like analytical solutions. Following Peter Todd, I also find the concerning result that propagation delays results in increasing returns to higher shares of the hashing power. Indeed it may well be in the interest of large pools to publish large blocks to increase propagation delays on the network which would increase orphan rates particularly for small miners and miners that have not invested in sufficient bandwidth / connectivity. If a small miner hears about a block after 4.5 seconds on average there is a 0.7% chance that there is already a block in circulation. Large miners can increase the time that it takes for small miners to hear about blocks by increasing the size of their blocks. For example if the time that it takes for a small miner to hear about the block goes to 12 seconds there is a 2 percent chance there is already a block in circulation for the small miner. There is also a 1.2% chance that there will be a competing block published after a small miner propagates in the time that it gets to full propagation. Am I getting this right that the probability of a miner’s block being orphaned is comprised of the probability that the miner was not the first to find a valid block and the probability that given they are first, someone else in the absence of hearing about it finds a competing valid block. One question is: Are orphans probabilistic and only resolved after hearing about a new block that lengthens the chain or is there a way to know in advance? Is it frowned upon to mine on top of a block that you have just found even though it is very likely going to end up an orphan? Would be happy to share the draft form of the paper and receive any feedback. Finally, at coinometrics we are working on a modified client to capture information on network propagation and would invite any suggestions of any other useful statistics that would be useful in the development of software. Best, Jonathan On 21 Apr 2014, at 01:16, bitcoin-development-requ...@lists.sourceforge.net bitcoin-development-requ...@lists.sourceforge.net wrote: Send Bitcoin-development mailing list submissions to bitcoin-development@lists.sourceforge.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/bitcoin-development or, via email, send a message with subject or body 'help' to bitcoin-development-requ...@lists.sourceforge.net You can reach the person managing the list at bitcoin-development-ow...@lists.sourceforge.net When replying, please edit your Subject line so it is more specific than Re: Contents of Bitcoin-development digest... Today's Topics: 1. Re: bits: Unit of account (Oliver Egginger) 2. Re: bits: Unit of account (Christophe Biocca) 3. Re: bits: Unit of account (Gmail) 4. Re: bits: Unit of account (Mike Caldwell) 5. Re: bits: Unit of account (Justin A) -- Message: 1 Date: Sun, 20 Apr 2014 20:43:24 +0200 From: Oliver Egginger bitc...@olivere.de Subject: Re:
Re: [Bitcoin-development] Economics of information propagation
Of course, in reality smaller miners can just mine on top of block headers and include no transactions and do no validation, but that is extremely harmful to the security of Bitcoin. If it's only during the few seconds that it takes to to verify the block, then would this really be that big of a deal? E.g. even if all miners did this, a 10 second delay would only yield an average of a couple blind/empty blocks per day. On Sun, Apr 20, 2014 at 10:06 PM, Peter Todd p...@petertodd.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 That is mistaken: you can't mine on top of just a block header, leaving small miners disadvantaged as they are earning no profit while they wait for the information to validate the block and update their UTXO sets. This results in the same problem as before, as the large pools who mine most blocks can validate either instantly - the self-mine case - or more quickly than the smaller miners. Of course, in reality smaller miners can just mine on top of block headers and include no transactions and do no validation, but that is extremely harmful to the security of Bitcoin. On 20 April 2014 23:58:58 GMT-04:00, Mark Friedenbach m...@monetize.io wrote: As soon as we switch to headers first - which will be soon - there will be no difference in propagation time no matter how large the block is. Only 80 bites will be required to propagate the block header which establishes priority for when the block is fully validated. On Apr 20, 2014 6:56 PM, Jonathan Levin jonathan.le...@sant.ox.ac.uk wrote: Hi all, I am a post-graduate economist writing a paper on the incentives of mining. Even though this issue has been debated in the forums, I think it is important to get a sense of the magnitude of the incentives at play and determine what implications this has for the transaction fee market. As it has been pointed out before the marginal cost for miners does not stem from the private cost of the miner validating the signature and including it in the list of transactions in the block but rather the increased probability that the block will be orphaned as a result of slower propagation. Gavin did some back of the envelope worst case calculations but these overstated the effect of propagation delay. The reason being the 80ms additional time to reach 50% of the network is spread throughout the time that it takes to reach 50% of the network. During this time miners are notified about the block and treat it as the longest chain and hence are no longer mining with the aim to produce a competing block. I am looking to calculate the change in the curvature of the probability mass function that a block hears about my block in any given second as a function of the block size. Although there is likely to be significant noise here, there seems to be some stable linear relationships with the time that it takes to reach different quartiles. Has anyone done this? I have used some empirical data that I am happy to share but ideally I would like analytical solutions. Following Peter Todd, I also find the concerning result that propagation delays results in increasing returns to higher shares of the hashing power. Indeed it may well be in the interest of large pools to publish large blocks to increase propagation delays on the network which would increase orphan rates particularly for small miners and miners that have not invested in sufficient bandwidth / connectivity. If a small miner hears about a block after 4.5 seconds on average there is a 0.7% chance that there is already a block in circulation. Large miners can increase the time that it takes for small miners to hear about blocks by increasing the size of their blocks. For example if the time that it takes for a small miner to hear about the block goes to 12 seconds there is a 2 percent chance there is already a block in circulation for the small miner. There is also a 1.2% chance that there will be a competing block published after a small miner propagates in the time that it gets to full propagation. Am I getting this right that the probability of a miner’s block being orphaned is comprised of the probability that the miner was not the first to find a valid block and the probability that given they are first, someone else in the absence of hearing about it finds a competing valid block. One question is: Are orphans probabilistic and only resolved after hearing about a new block that lengthens the chain or is there a way to know in advance? Is it frowned upon to mine on top of a block that you have just found even though it is very likely going to end up an orphan? Would be happy to share the draft form of the paper and receive any feedback. Finally, at coinometrics we are working on a modified client to capture information on network propagation and would invite any
