Re: [Bitcoin-development] Mailing list abuse
Not a bad idea. Semantics of the word abuse not withstanding. I don't want to become the self appointed mailing list cop, but I notice it maybe more than others because I almost exclusively read this mailing list on a mobile device. Hence my asking for feedback without publicly calling anyone out. Thanks for taking the time to reply. Rodney On 21/04/2014 3:47 pm, Wladimir laa...@gmail.com wrote: On Mon, Apr 21, 2014 at 6:58 AM, Rodney Morris rodney.mor...@gmail.com wrote: What is the procedure for dealing with it? Is it considered abuse to reply to and quote the entire digest for the sake of a few lines of content? Am I the only one annoyed by this (if so I'll just shut right up). I would not go as far as calling it 'abuse' if it is not done on purpose. Probably the person doesn't even know he/she is doing this. Best to mail the person and ask (nicely) instead of complaining to the list. Wladimir -- 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] bits: Unit of account
Here is one to please those looking for a “fully qualified” slang word, that links with the official XBT: xbit (spoken: ex-bit) would rationalise XBT (where X comes from supranational use) and is unique. I personally associate from x to six also supporting the 1e-6 divisor of Bitcoin. Regarding XBT: No matter who used it for what. The way Bloomberg will use it will define its use in finance, and since that did not happen yet, we are not late to shape. Regards, Tamas Blummer http://bitsofproof.com On 21.04.2014, at 07:41, Pieter Wuille pieter.wui...@gmail.com wrote: On Apr 21, 2014 3:37 AM, Un Ix slashdevn...@hotmail.com wrote: Something tells me this would be reduced to a single syllable in common usage I.e. bit. What units will be called colloquially is not something developers will determine. It will vary, depend on language and culture, and is not relevant to this discussion in my opinion. It may well be that people in some geographic or language area will end up (or for a while) calling 1e-06 BTC bits. That's fine, but using that as official name in software would be very strange and potentially confusing in my opinion. As mentioned by others, that would seem to me like calling dollars bucks in bank software. Nobody seems to have a problem with having colloquial names, but US dollar or euro are far less ambiguous than bit. I think we need a more distinctive name. -- Pieter -- 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 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 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] bits: Unit of account
Let me make a sacrilegious proposal: keep using the name bitcoin, and shift the decimal point. There would be a short adaption period, where people will need to talk about new bitcoins and old bitcoins in order to disambiguate them. However, Bitcoin users are techies, so I don't think that the ambiguity will be a big issue. I don't think lots of people will mistakenly send 1000 times more than the amount they intended. The name bitcoin has a huge advantage over any other proposal, because it is already established. No marketing is needed. This kind of renaming has already taken place many times in history, because the currency was debased. Bitcoin would be the first time it happens in the other direction. -- 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] bits: Unit of account
Thomas V: Your proposal misses the points that: - this is about a unit with 1e-6 Bitcoins or 100 satoshis. - it is not about people who know Bitcoin and are techies, but about those who don’t and aren’t. The reasons for such a unit are more than shifting the comma some places for convinience, but to align Bitcoin with capabilities of existing financial software and customs of finance and average people, and ISO standard of currency abbreviations. bit and XBT seems to check the boxes. I would love to have some feedback on xbit as per my previous mail. Regards, Tamas Blummer http://bitsofproof.com 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 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] bits: Unit of account
Tamas, xbit is only a typo or spelling error away from XBT, and some folks may assume they refer to the same unit of measure, not knowing the new currency system as developers here do. From your email, I got the idea of using x as a suffix at the end of a number of bits e.g. 17500x, like cents or centavos. I guess this might clash with formal S.I. notation but it's easy to read and has less ambiguity, IMHO. On 21/04/2014, at 2:21 pm, Tamas Blummer ta...@bitsofproof.com wrote: Here is one to please those looking for a “fully qualified” slang word, that links with the official XBT: xbit (spoken: ex-bit) would rationalise XBT (where X comes from supranational use) and is unique. I personally associate from x to six also supporting the 1e-6 divisor of Bitcoin. Regarding XBT: No matter who used it for what. The way Bloomberg will use it will define its use in finance, and since that did not happen yet, we are not late to shape. Regards, Tamas Blummer http://bitsofproof.com On 21.04.2014, at 07:41, Pieter Wuille pieter.wui...@gmail.com wrote: On Apr 21, 2014 3:37 AM, Un Ix slashdevn...@hotmail.com wrote: Something tells me this would be reduced to a single syllable in common usage I.e. bit. What units will be called colloquially is not something developers will determine. It will vary, depend on language and culture, and is not relevant to this discussion in my opinion. It may well be that people in some geographic or language area will end up (or for a while) calling 1e-06 BTC bits. That's fine, but using that as official name in software would be very strange and potentially confusing in my opinion. As mentioned by others, that would seem to me like calling dollars bucks in bank software. Nobody seems to have a problem with having colloquial names, but US dollar or euro are far less ambiguous than bit. I think we need a more distinctive name. -- Pieter -- 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] bits: Unit of account
xbit is close to XBT because it would be the same unit, both would mean 100 satoshi or 1e-6 Bitcoin. xbit would be for everyday use, XBT for ISO. I know, the XBT was used by some sites to be a synonym for BTC that is however in my opinion not yet graved in stone until it is used by e.g. Bloomberg. Regards, Tamas Blummer http://bitsofproof.com On 21.04.2014, at 14:14, Un Ix slashdevn...@hotmail.com wrote: Tamas, xbit is only a typo or spelling error away from XBT, and some folks may assume they refer to the same unit of measure, not knowing the new currency system as developers here do. 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 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
