Re: [Bitcoin-development] bits: Unit of account
Bit by bit, it's become clear that it's a bit much to worry even a little bit that overloading the word bit would be every bit as bad as a two bit horse with the bit between it's teeth that bit the hand that feeds it, or a drill bit broken to bits after just a bit of use. Aaron There's no trick to being a humorist when you have the whole government working for you -- Will Rodgers On Sat, May 3, 2014 at 10:18 PM, Drak d...@zikula.org wrote: +1 On 4 May 2014 02:06, Chris Pacia ctpa...@gmail.com wrote: Absent a concerted effort to move to something else other than 'bits', I would be willing to bet the nomenclature moves in that direction anyway. 'Bits' is just a shorten word for 'millibits' (or microbits, if you will). It's easier to say and my guess is people would tend to use it naturally own their own. Kind of like 'bucks' for dollars. The other synergies are: -bit is part of the word Bitcoin. The currency unit bit is part of a whole bitcoin. -bit symbolically represents the tech nature of the bitcoin. -bit used to be a unit of money way back when. This largely reclaims it. -when used as money bit when in references to a precession metal coin. The name 'bitcoin' references that as well as the mimicking of the gold standard in the protocol rules. All around I don't think there is a better fit. I doubt people will get confused by it. The context it's used in will distinguish it from other uses of the word. On 05/03/2014 12:27 PM, Mike Caldwell wrote: I agree with the sentiment that most people don't understand either computer science or Bitcoin. The goal of getting people to understand enough about Bitcoin to use it is achievable and a goal that is in scope of our efforts. Getting them to understand computer science at large at the same time, less so. The fact that people routinely confuse RAM and hard drive sizes has much to do with the fact that the average lay person has little need to prioritize this as something to keep in the forefront. They don't get horribly confused, they just simply don't get worked up over what looks to them like a rounding error, much to the dismay of anyone who believes that everyone should be an expert at computer science. The average joe may assess (accurately from his perspective) that the distinction isn't important enough to merit significant mental resources and he is justified in not expending them that way even if someone else thinks he should. Poor understanding is precisely what a proper effort to name this would be to avoid. It is not frill or aesthetics, it is a planned targeting of language to achieve the clearest communication to the widest possible target audience using the language most likely to be understood by them in light of our objectives. It's marketing. Mike Sent from my iPhone On May 3, 2014, at 9:49 AM, Christophe Biocca christophe.bio...@gmail.com wrote: Context as a disambiguator works fine when the interlocutors understand the topics they're talking about. Not a day goes by without me seeing neurotypical people get horribly confused between RAM and Hard Drive sizes, because they share the same units (not that that can be helped, as the units are supposed to be the same, base 1000 vs 1024 notwithstanding). Bit (as a unit) is already really confusing for anyone who doesn't deal with it on a regular basis. I think people who don't see an issue are making an assumption based on their own lack of confusion. We understand computer science AND Bitcoin. Most people have zero understanding of either. Bitcoin already has a ton of issues with terrible names for things: - Mining (for transaction validation). - Addresses (which are meant to be one-time use, and don't even really exist at the network level). - Wallets (which don't hold your bitcoins, can be copied, and all backups can be stolen from equally). I end up having to make the distinctions obvious every time I explain Bitcoin to someone new to it. There's an acceptable tradeoff here, because there were arguably no better words to assign to these concepts (although I'd argue mining is a really awful metaphor, and is the one that prompts the most questions from people). Then add to the pile a bunch of third parties naming themselves after parts of the protocol (Coinbase,Blockchain.info). Not blaming them for it, but I've definitiely seen average people get confused between the blockchain and blockchain.info (not so much Coinbase, because that name doesn't come up in beginner explanations). It seems downright masochistic to add yet-another-word-that-doesn't-mean-what-you-think-it-means to the pile for no reason other than aesthetics. Are we actively trying to confuse people? -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Re: [Bitcoin-development] bits: Unit of account
+1(bit) for your bit on bits. On 4/05/2014, at 2:18 pm, Aaron Voisine vois...@gmail.com wrote: Bit by bit, it's become clear that it's a bit much to worry even a little bit that overloading the word bit would be every bit as bad as a two bit horse with the bit between it's teeth that bit the hand that feeds it, or a drill bit broken to bits after just a bit of use. Aaron There's no trick to being a humorist when you have the whole government working for you -- Will Rodgers On Sat, May 3, 2014 at 10:18 PM, Drak d...@zikula.org wrote: +1 On 4 May 2014 02:06, Chris Pacia ctpa...@gmail.com wrote: Absent a concerted effort to move to something else other than 'bits', I would be willing to bet the nomenclature moves in that direction anyway. 'Bits' is just a shorten word for 'millibits' (or microbits, if you will). It's easier to say and my guess is people would tend to use it naturally own their own. Kind of like 'bucks' for dollars. The other synergies are: -bit is part of the word Bitcoin. The currency unit bit is part of a whole bitcoin. -bit symbolically represents the tech nature of the bitcoin. -bit used to be a unit of money way back when. This largely reclaims it. -when used as money bit when in references to a precession metal coin. The name 'bitcoin' references that as well as the mimicking of the gold standard in the protocol rules. All around I don't think there is a better fit. I doubt people will get confused by it. The context it's used in will distinguish it from other uses of the word. On 05/03/2014 12:27 PM, Mike Caldwell wrote: I agree with the sentiment that most people don't understand either computer science or Bitcoin. The goal of getting people to understand enough about Bitcoin to use it is achievable and a goal that is in scope of our efforts. Getting them to understand computer science at large at the same time, less so. The fact that people routinely confuse RAM and hard drive sizes has much to do with the fact that the average lay person has little need to prioritize this as something to keep in the forefront. They don't get horribly confused, they just simply don't get worked up over what looks to them like a rounding error, much to the dismay of anyone who believes that everyone should be an expert at computer science. The average joe may assess (accurately from his perspective) that the distinction isn't important enough to merit significant mental resources and he is justified in not expending them that way even if someone else thinks he should. Poor understanding is precisely what a proper effort to name this would be to avoid. It is not frill or aesthetics, it is a planned targeting of language to achieve the clearest communication to the widest possible target audience using the language most likely to be understood by them in light of our objectives. It's marketing. Mike Sent from my iPhone On May 3, 2014, at 9:49 AM, Christophe Biocca christophe.bio...@gmail.com wrote: Context as a disambiguator works fine when the interlocutors understand the topics they're talking about. Not a day goes by without me seeing neurotypical people get horribly confused between RAM and Hard Drive sizes, because they share the same units (not that that can be helped, as the units are supposed to be the same, base 1000 vs 1024 notwithstanding). Bit (as a unit) is already really confusing for anyone who doesn't deal with it on a regular basis. I think people who don't see an issue are making an assumption based on their own lack of confusion. We understand computer science AND Bitcoin. Most people have zero understanding of either. Bitcoin already has a ton of issues with terrible names for things: - Mining (for transaction validation). - Addresses (which are meant to be one-time use, and don't even really exist at the network level). - Wallets (which don't hold your bitcoins, can be copied, and all backups can be stolen from equally). I end up having to make the distinctions obvious every time I explain Bitcoin to someone new to it. There's an acceptable tradeoff here, because there were arguably no better words to assign to these concepts (although I'd argue mining is a really awful metaphor, and is the one that prompts the most questions from people). Then add to the pile a bunch of third parties naming themselves after parts of the protocol (Coinbase,Blockchain.info). Not blaming them for it, but I've definitiely seen average people get confused between the blockchain and blockchain.info (not so much Coinbase, because that name doesn't come up in beginner explanations). It seems downright masochistic to add yet-another-word-that-doesn't-mean-what-you-think-it-means to the pile for no reason other than aesthetics. Are we actively trying to confuse people? -- Accelerate Dev Cycles
Re: [Bitcoin-development] bits: Unit of account
On Sun, May 4, 2014 at 8:15 AM, Aaron Voisine vois...@gmail.com wrote: Bit by bit, it's become clear that it's a bit much to worry even a little bit that overloading the word bit would be every bit as bad as a two bit horse with the bit between it's teeth that bit the hand that feeds it, or a drill bit broken to bits after just a bit of use. +1 good summary And I think that's a good conclusion to this discussion about unit names on the development mailing list. Everything has been said now. Wladimir -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bits: Unit of account
Wladimir, what is missing is a decision to pull for the reference client. Or did I missed that bit? signature.asc Description: Message signed with OpenPGP using GPGMail -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bits: Unit of account
On Sun, May 4, 2014 at 8:36 AM, Tamas Blummer ta...@bitsofproof.com wrote: Wladimir, what is missing is a decision to pull for the reference client. Or did I missed that bit? No opinion - we'll follow whatever the rest does. Wladimir -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bug with handing of OP_RETURN?
Thanks, that makes sense, just wanted to make sure this what the problem was. On Sun, May 4, 2014 at 6:15 AM, Jeff Garzik jgar...@bitpay.com wrote: On Sat, May 3, 2014 at 2:04 PM, Flavien Charlon flavien.char...@coinprism.com wrote: Outputs are above dust, inputs are not spent. OP_RETURN is supposed to be standard in 0.9.1 and the data is well below 40 bytes, so why is this being rejected? The carried data must all be contained within one pushdata. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bug with handing of OP_RETURN?
On Sat, May 3, 2014 at 3:15 PM, Mark Friedenbach m...@monetize.io wrote: Is it more complex? The current implementation using template matching seems more complex than `if script.vch[0] == OP_RETURN script.vch.size() 42` Not much more complex. The template matches a two-chunk script with OP_RETURN + one pushdata (or just OP_RETURN with no push). The pushdata is further limited to MAX_OP_RETURN_RELAY bytes. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bits: Unit of account
I will drink to that! Bitte ein Bit! (A Bit please - aka Bitburger Beer) Mike Sent from my iPhone On May 4, 2014, at 12:17 AM, Aaron Voisine vois...@gmail.com wrote: Bit by bit, it's become clear that it's a bit much to worry even a little bit that overloading the word bit would be every bit as bad as a two bit horse with the bit between it's teeth that bit the hand that feeds it, or a drill bit broken to bits after just a bit of use. Aaron There's no trick to being a humorist when you have the whole government working for you -- Will Rodgers On Sat, May 3, 2014 at 10:18 PM, Drak d...@zikula.org wrote: +1 On 4 May 2014 02:06, Chris Pacia ctpa...@gmail.com wrote: Absent a concerted effort to move to something else other than 'bits', I would be willing to bet the nomenclature moves in that direction anyway. 'Bits' is just a shorten word for 'millibits' (or microbits, if you will). It's easier to say and my guess is people would tend to use it naturally own their own. Kind of like 'bucks' for dollars. The other synergies are: -bit is part of the word Bitcoin. The currency unit bit is part of a whole bitcoin. -bit symbolically represents the tech nature of the bitcoin. -bit used to be a unit of money way back when. This largely reclaims it. -when used as money bit when in references to a precession metal coin. The name 'bitcoin' references that as well as the mimicking of the gold standard in the protocol rules. All around I don't think there is a better fit. I doubt people will get confused by it. The context it's used in will distinguish it from other uses of the word. On 05/03/2014 12:27 PM, Mike Caldwell wrote: I agree with the sentiment that most people don't understand either computer science or Bitcoin. The goal of getting people to understand enough about Bitcoin to use it is achievable and a goal that is in scope of our efforts. Getting them to understand computer science at large at the same time, less so. The fact that people routinely confuse RAM and hard drive sizes has much to do with the fact that the average lay person has little need to prioritize this as something to keep in the forefront. They don't get horribly confused, they just simply don't get worked up over what looks to them like a rounding error, much to the dismay of anyone who believes that everyone should be an expert at computer science. The average joe may assess (accurately from his perspective) that the distinction isn't important enough to merit significant mental resources and he is justified in not expending them that way even if someone else thinks he should. Poor understanding is precisely what a proper effort to name this would be to avoid. It is not frill or aesthetics, it is a planned targeting of language to achieve the clearest communication to the widest possible target audience using the language most likely to be understood by them in light of our objectives. It's marketing. Mike Sent from my iPhone On May 3, 2014, at 9:49 AM, Christophe Biocca christophe.bio...@gmail.com wrote: Context as a disambiguator works fine when the interlocutors understand the topics they're talking about. Not a day goes by without me seeing neurotypical people get horribly confused between RAM and Hard Drive sizes, because they share the same units (not that that can be helped, as the units are supposed to be the same, base 1000 vs 1024 notwithstanding). Bit (as a unit) is already really confusing for anyone who doesn't deal with it on a regular basis. I think people who don't see an issue are making an assumption based on their own lack of confusion. We understand computer science AND Bitcoin. Most people have zero understanding of either. Bitcoin already has a ton of issues with terrible names for things: - Mining (for transaction validation). - Addresses (which are meant to be one-time use, and don't even really exist at the network level). - Wallets (which don't hold your bitcoins, can be copied, and all backups can be stolen from equally). I end up having to make the distinctions obvious every time I explain Bitcoin to someone new to it. There's an acceptable tradeoff here, because there were arguably no better words to assign to these concepts (although I'd argue mining is a really awful metaphor, and is the one that prompts the most questions from people). Then add to the pile a bunch of third parties naming themselves after parts of the protocol (Coinbase,Blockchain.info). Not blaming them for it, but I've definitiely seen average people get confused between the blockchain and blockchain.info (not so much Coinbase, because that name doesn't come up in beginner explanations). It seems downright masochistic to add yet-another-word-that-doesn't-mean-what-you-think-it-means to the pile for no reason other than aesthetics. Are we actively trying to confuse people?
Re: [Bitcoin-development] Proposal for extra nonce in block header
If changing the structure of the block header, wouldnt you also need to increment the version number to 3? No, in this case I don't think so. Incrementing the version number has two purposes: 1. inform old clients that something new is going on 2. be able to phase out old version numbers and block them once the new version number becomes a supermajority. None of these two is necessary here. Old clients already recognize the new block headers as something new because they look like very high version numbers to them. And there is no reason to ever phase out blocks that have zero in the MSBs of the version. On Sun, Apr 27, 2014 at 10:17:11AM +0200, Melvin Carvalho wrote: On 27 April 2014 09:07, Timo Hanke timo.ha...@web.de wrote: I'd like to put the following draft of a BIP up for discussion. Timo # Abstract There are incentives for miners to find cheap, non-standard ways to generate new work, which are not necessarily in the best interest of the protocol. In order to reduce these incentives this proposal re-assigns 2 bytes from the version field of the block header to a new extra nonce field. # Copyright # Specification The block version number field in the block header is reduced in size from 4 to 2 bytes. The third and fourth byte in the block header are assigned to the new extra nonce field inside the block header. # Motivation The motivation of this proposal is to provide miners with a cheap constant-complexity method to create new work that does not require altering the transaction tree. Furthermore, the motivation is to protect the version and timestamp fields in the block header from abuse. # Rationale Traditionally, the extra nonce is part of the coinbase field of the generation transaction, which is always the very first transaction of a block. After incrementing the extra nonce the minimum amount of work a miner has to do to re-calculate the block header is a) to hash the coinbase transaction and b) to re-calculate the left-most branch of the merkle tree all the way to the merkle root. This is necessary overhead a miner has to do besides hashing the block header itself. We shall call the process that leads to a new block header from the same transaction set the _pre-hashing_. First it should be noted that the relative cost of pre-hashing in its traditional form depends on the block size, which may create an unwanted incentive for miners to keep the block size small. However, this is not the main motivation for the current proposal. While the block header is hashed by ASICs, pre-hashing typically happens on a CPU because of the greater flexibility required. Consequently, as ASIC cost per hash performance drops the relative cost of pre-hashing increases. This creates an incentive for miners to find cheaper ways to create new work than by means of pre-hashing. An example of this currently happening is the on-device rolling of the timestamp into the future. These ways of creating new work are unlikely to be in the best interest of the protocol. For example, rolling the timestamp faster than the real time is unwanted (more so on faster blockchains). The version number in the block header is a possible target for alteration with the goal of cheaply creating new work. Currently, blocks with arbitrarily large version numbers get relayed and accepted by the network. As this is unwanted behaviour, there should not exist any incentive for a miner to abuse the version number in this way. The solution is to reduce the range of version numbers from 2^32 to 2^16 and to declare the third and forth bytes of the block header as legitimate space for an extra nonce. This will reduce the incentive for a miner to abuse the shortened version number by a factor in the order of 2^16. As a side effect, this proposal greatly reduces the bandwidth requirements of a blind pool protocol by only submitting the block header to the miner. # Backwards Compatibility Old versions of the client will accept blocks of this kind but will throw an alert at the user to upgrade. The only code change would be a cast of the version number to a short. Besides the upgrade alert, old and new versions of the client can co-exist and there is no need to introduce a new block version number or to phase-out old block versions. # Reference Implementation # Final implementation If changing the structure of the block header, wouldnt you also need to increment the version number to 3? -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests
Re: [Bitcoin-development] Proposal for extra nonce in block header
Although I agree 32 bits for a version is overkill, I really don't like the idea of you simply ignoring the protocol spec to try and reduce your own costs. Especially because in future we should make unknown versions a validation rule, so we can easily trigger hard forks. If this change was introduced through a proper process and software was properly upgraded to understand the new header format, that'd be one thing. Arbitrarily exploiting what is IMHO a missing rule in the rule set to shave a bit more profit is something else. On Sun, May 4, 2014 at 5:14 PM, Timo Hanke timo.ha...@web.de wrote: If changing the structure of the block header, wouldnt you also need to increment the version number to 3? No, in this case I don't think so. Incrementing the version number has two purposes: 1. inform old clients that something new is going on 2. be able to phase out old version numbers and block them once the new version number becomes a supermajority. None of these two is necessary here. Old clients already recognize the new block headers as something new because they look like very high version numbers to them. And there is no reason to ever phase out blocks that have zero in the MSBs of the version. On Sun, Apr 27, 2014 at 10:17:11AM +0200, Melvin Carvalho wrote: On 27 April 2014 09:07, Timo Hanke timo.ha...@web.de wrote: I'd like to put the following draft of a BIP up for discussion. Timo # Abstract There are incentives for miners to find cheap, non-standard ways to generate new work, which are not necessarily in the best interest of the protocol. In order to reduce these incentives this proposal re-assigns 2 bytes from the version field of the block header to a new extra nonce field. # Copyright # Specification The block version number field in the block header is reduced in size from 4 to 2 bytes. The third and fourth byte in the block header are assigned to the new extra nonce field inside the block header. # Motivation The motivation of this proposal is to provide miners with a cheap constant-complexity method to create new work that does not require altering the transaction tree. Furthermore, the motivation is to protect the version and timestamp fields in the block header from abuse. # Rationale Traditionally, the extra nonce is part of the coinbase field of the generation transaction, which is always the very first transaction of a block. After incrementing the extra nonce the minimum amount of work a miner has to do to re-calculate the block header is a) to hash the coinbase transaction and b) to re-calculate the left-most branch of the merkle tree all the way to the merkle root. This is necessary overhead a miner has to do besides hashing the block header itself. We shall call the process that leads to a new block header from the same transaction set the _pre-hashing_. First it should be noted that the relative cost of pre-hashing in its traditional form depends on the block size, which may create an unwanted incentive for miners to keep the block size small. However, this is not the main motivation for the current proposal. While the block header is hashed by ASICs, pre-hashing typically happens on a CPU because of the greater flexibility required. Consequently, as ASIC cost per hash performance drops the relative cost of pre-hashing increases. This creates an incentive for miners to find cheaper ways to create new work than by means of pre-hashing. An example of this currently happening is the on-device rolling of the timestamp into the future. These ways of creating new work are unlikely to be in the best interest of the protocol. For example, rolling the timestamp faster than the real time is unwanted (more so on faster blockchains). The version number in the block header is a possible target for alteration with the goal of cheaply creating new work. Currently, blocks with arbitrarily large version numbers get relayed and accepted by the network. As this is unwanted behaviour, there should not exist any incentive for a miner to abuse the version number in this way. The solution is to reduce the range of version numbers from 2^32 to 2^16 and to declare the third and forth bytes of the block header as legitimate space for an extra nonce. This will reduce the incentive for a miner to abuse the shortened version number by a factor in the order of 2^16. As a side effect, this proposal greatly reduces the bandwidth requirements of a blind pool protocol by only submitting the block header to the miner. # Backwards Compatibility Old versions of the client will
Re: [Bitcoin-development] Proposal for extra nonce in block header
On Sun, Apr 27, 2014 at 02:38:06AM -0700, Mark Friedenbach wrote: I'm not convinced of the necessity of this idea in general, but if it were to be implemented I would recommend serializing the nVersion field as a VarInt (Pieter Wuille's multi-byte serialization format) and using the remaining space of the 4 bytes as your extra nonce. That would allow serialization of numbers up to 0x1020407f (slightly over 28 bits) before the 4-byte field is exhausted. For version numbers less than 0x204080 there will be at least one byte of padding space left over for extra-nonce usage (two bytes if less than 0x4080, three bytes if less than 0x80). For version values up to 127, the format is exactly identical when the padding bytes are zero. Neat idea. It might somewhat reduce the flexibility in which the version field can be used in the future, though. For the sake of simplicity I lean towards a fixed length version field, but would be ok with either. Keep in mind that version numbers can be recycled after a couple of years. So there is effectively zero benefit in allowing varints to extend beyond 2 bytes. For that reason personally I think 1 byte of version number would be enough. On 04/27/2014 12:07 AM, Timo Hanke wrote: I'd like to put the following draft of a BIP up for discussion. Timo # Abstract There are incentives for miners to find cheap, non-standard ways to generate new work, which are not necessarily in the best interest of the protocol. In order to reduce these incentives this proposal re-assigns 2 bytes from the version field of the block header to a new extra nonce field. # Copyright # Specification The block version number field in the block header is reduced in size from 4 to 2 bytes. The third and fourth byte in the block header are assigned to the new extra nonce field inside the block header. # Motivation The motivation of this proposal is to provide miners with a cheap constant-complexity method to create new work that does not require altering the transaction tree. Furthermore, the motivation is to protect the version and timestamp fields in the block header from abuse. # Rationale Traditionally, the extra nonce is part of the coinbase field of the generation transaction, which is always the very first transaction of a block. After incrementing the extra nonce the minimum amount of work a miner has to do to re-calculate the block header is a) to hash the coinbase transaction and b) to re-calculate the left-most branch of the merkle tree all the way to the merkle root. This is necessary overhead a miner has to do besides hashing the block header itself. We shall call the process that leads to a new block header from the same transaction set the _pre-hashing_. First it should be noted that the relative cost of pre-hashing in its traditional form depends on the block size, which may create an unwanted incentive for miners to keep the block size small. However, this is not the main motivation for the current proposal. While the block header is hashed by ASICs, pre-hashing typically happens on a CPU because of the greater flexibility required. Consequently, as ASIC cost per hash performance drops the relative cost of pre-hashing increases. This creates an incentive for miners to find cheaper ways to create new work than by means of pre-hashing. An example of this currently happening is the on-device rolling of the timestamp into the future. These ways of creating new work are unlikely to be in the best interest of the protocol. For example, rolling the timestamp faster than the real time is unwanted (more so on faster blockchains). The version number in the block header is a possible target for alteration with the goal of cheaply creating new work. Currently, blocks with arbitrarily large version numbers get relayed and accepted by the network. As this is unwanted behaviour, there should not exist any incentive for a miner to abuse the version number in this way. The solution is to reduce the range of version numbers from 2^32 to 2^16 and to declare the third and forth bytes of the block header as legitimate space for an extra nonce. This will reduce the incentive for a miner to abuse the shortened version number by a factor in the order of 2^16. As a side effect, this proposal greatly reduces the bandwidth requirements of a blind pool protocol by only submitting the block header to the miner. # Backwards Compatibility Old versions of the client will accept blocks of this kind but will throw an alert at the user to upgrade. The only code change would be a cast of the version number to a short. Besides the upgrade alert, old and new versions of the client can co-exist and there is no need to introduce a new block version number or to phase-out old block versions. # Reference
Re: [Bitcoin-development] Proposal for extra nonce in block header
On Sun, May 04, 2014 at 05:26:06PM +0200, Mike Hearn wrote: Although I agree 32 bits for a version is overkill, I really don't like the idea of you simply ignoring the protocol spec to try and reduce your own costs. The purpose of the proposal is to change the protocol spec, not to ignore it. The argument for the proposal is explained in the Rationale section, and in abstracted form means precisely to make everybody follow the protocol spec by reducing incentives to ignore it. Specifically, it is about protecting the timestamp field. I talked about relative costs involved in hashing, and how those will change, and what incentives that creates. This development cannot be ignored. Especially because in future we should make unknown versions a validation rule, so we can easily trigger hard forks. Why does it require 32 bits? If this change was introduced through a proper process and software was properly upgraded to understand the new header format, that'd be one thing. Arbitrarily exploiting what is IMHO a missing rule in the rule set to shave a bit more profit is something else. Again, this is a BIP. I am proposing a software upgrade, which is absolutely required. When I said that version 3 is not required I meant that the software upgrade (which basically just turns the nonce into a short) does not have to be accompanied by a new version number for any technical reason. Is there another reason why it should be incremented? On Sun, May 4, 2014 at 5:14 PM, Timo Hanke timo.ha...@web.de wrote: If changing the structure of the block header, wouldnt you also need to increment the version number to 3? No, in this case I don't think so. Incrementing the version number has two purposes: 1. inform old clients that something new is going on 2. be able to phase out old version numbers and block them once the new version number becomes a supermajority. None of these two is necessary here. Old clients already recognize the new block headers as something new because they look like very high version numbers to them. And there is no reason to ever phase out blocks that have zero in the MSBs of the version. On Sun, Apr 27, 2014 at 10:17:11AM +0200, Melvin Carvalho wrote: On 27 April 2014 09:07, Timo Hanke timo.ha...@web.de wrote: I'd like to put the following draft of a BIP up for discussion. Timo # Abstract There are incentives for miners to find cheap, non-standard ways to generate new work, which are not necessarily in the best interest of the protocol. In order to reduce these incentives this proposal re-assigns 2 bytes from the version field of the block header to a new extra nonce field. # Copyright # Specification The block version number field in the block header is reduced in size from 4 to 2 bytes. The third and fourth byte in the block header are assigned to the new extra nonce field inside the block header. # Motivation The motivation of this proposal is to provide miners with a cheap constant-complexity method to create new work that does not require altering the transaction tree. Furthermore, the motivation is to protect the version and timestamp fields in the block header from abuse. # Rationale Traditionally, the extra nonce is part of the coinbase field of the generation transaction, which is always the very first transaction of a block. After incrementing the extra nonce the minimum amount of work a miner has to do to re-calculate the block header is a) to hash the coinbase transaction and b) to re-calculate the left-most branch of the merkle tree all the way to the merkle root. This is necessary overhead a miner has to do besides hashing the block header itself. We shall call the process that leads to a new block header from the same transaction set the _pre-hashing_. First it should be noted that the relative cost of pre-hashing in its traditional form depends on the block size, which may create an unwanted incentive for miners to keep the block size small. However, this is not the main motivation for the current proposal. While the block header is hashed by ASICs, pre-hashing typically happens on a CPU because of the greater flexibility required. Consequently, as ASIC cost per hash performance drops the relative cost of pre-hashing increases. This creates an incentive for miners to find cheaper ways to create new work than by means of pre-hashing. An
Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets
On Fri, Apr 11, 2014 at 5:54 PM, Gregory Maxwell gmaxw...@gmail.com wrote: For the non-error-coded case I believe nodes with random spans of blocks works out asymptotically to the same failure rates as random. If each block is really 512 blocks in sequence, then each slot is more likely to be hit. It effectively reduces the number of blocks by the minimum run lengths. ECC seemed cooler though. (The conversation Peter Todd was referring to was one where I was pointing out that with suitable error coding you also get an anti-censorship effect where its very difficult to provide part of the data without potentially providing all of it) Interesting too. I think in the network we have today and for the foreseeable future we can reasonably count on there being a reasonable number of nodes that store all the blocks... quite likely not enough to satisfy the historical block demand from the network alone, but easily enough to supply blocks that have otherwise gone missing. That's true. Scaling up the transactions per second increases the chance of data lost. With side/tree chains, the odds of data loss in the less important chains increases (though they are by definition lower value chains) -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
