Re: [bitcoin-dev] A Small Modification to Segwit
Makes sense. I would love if GPUs were back as the main hashing tool. However, we need to consider the environmental impact of mining, which currently consumes a quite exorbitant amount of energy. Any ideas on this front? -- Garrett MacDonald +1 720 515 2248 g...@cognitive.ch GPG Key On Apr 10, 2017, 12:17 PM -0600, Erik Aronesty , wrote: > I own some miners, but realistically their end of life is what, 6 months from > now if I'm lucky? If we used difficulty ramps on two selected POW's, then > the migration could be made smooth. I don't think changing the POW would be > very challenging. Personally, I would absolutely love to be back in the > business of buying GPU's instead of ASICs which are uniformly sketchy. Does > anyone *not* mine their own equipment before "shipping late" these days? > > Maybe sample a video game's GPU operations and try to develop a secure hash > whose optimal implementation uses them in a similar ratio? Ultimately, I > think it would very challenging to find a POW that doesn't make a bad problem > worse. I understand that's why you suggested SHA3. > > Hopefully, the "nanometer race" we have will work more smoothly once the > asicboost issue is resolved and competition can return to normal. But > "waiting things out" rarely seems to work in Bitcoin land. > > > > > > > > On Mon, Apr 10, 2017 at 11:25 AM, g wrote: > > > Erik, > > > > > > I completely agree that it will be in the long term interest of bitcoin > > > to migrate, gradually, toward a commoditized POW away from the current > > > mass centralization. There is a big problem here though: Hundreds of > > > millions of dollars have been spent on the current algorithm, and will be > > > a huge loss if this is not done slowly enough, and the miners who control > > > the chain currently would likely never allow this change to happen. > > > > > > Do you have any ideas regarding how to mitigate the damage of such a > > > change for the invested parties? Or even how we can make the change > > > agreeable for them? > > > > > > Warm regards, > > > Garrett > > > > > > -- > > > Garrett MacDonald > > > +1 720 515 2248 > > > g...@cognitive.ch > > > GPG Key > > > > > > On Apr 9, 2017, 2:16 PM -0600, Erik Aronesty via bitcoin-dev > > > , wrote: > > > > Curious: I'm not sure why a serious discussion of POW change is not on > > > > the table as a part of a longer-term roadmap. > > > > > > > > Done right, a ramp down of reliance on SHA-256 and a ramp-up on some of > > > > the proven, np-complete graph-theoretic or polygon manipulation POW > > > > would keep Bitcoin in commodity hardware and out of the hands of > > > > centralized manufacturing for many years. > > > > > > > > Clearly a level-playing field is critical to keeping centralization > > > > from being a "defining feature" of Bitcoin over the long term. I've > > > > heard the term "level playing field" bandied about quite a bit. And > > > > it seems to me that the risk of state actor control and botnet attacks > > > > is less than state-actor manipulation of specialized manufacturing of > > > > "SHA-256 forever" hardware. Indeed, the reliance on a fairly simple > > > > hash seems less and less likely a "feature" and more of a baggage. > > > > > > > > Perhaps regular, high-consensus POW changes might even be *necessary* > > > > as a part of good maintenance of cryptocurrency in general. Killing > > > > the existing POW, and using an as-yet undefined, but deployment-bit > > > > ready POW field to flip-flop between the current and the "next one" > > > > every 8 years or or so, with a ramp down beginning in the 7th year > > > > A stub function that is guaranteed to fail unless a new consensus POW > > > > is selected within 7 years. > > > > > > > > Something like that? > > > > > > > > Haven't thought about it *that* much, but I think the network would > > > > respond well to a well known cutover date. This would enable > > > > rapid-response to quantum tech, or some other needed POW switch as > > > > well... because the mechanisms would be in-place and ready to switch as > > > > needed. > > > > > > > > Lots of people seem to panic over POW changes as "irresponsible", but > > > > it's only irresponsible if done irresponsibly. > > > > > > > > > > > > > On Fri, Apr 7, 2017 at 9:48 PM, praxeology_guy via bitcoin-dev > > > > > wrote: > > > > > > Jimmy Song, > > > > > > > > > > > > Why would the actual end users of Bitcoin (the long term and short > > > > > > term owners of bitcoins) who run fully verifying nodes want to > > > > > > change Bitcoin policy in order to make their money more vulnerable > > > > > > to 51% attack? > > > > > > > > > > > > If anything, we would be making policy changes to prevent the use > > > > > > of patented PoW algorithms instead of making changes to enable them. > > > > > > > > > > > > Thanks, > > > > > > Praxeology Guy > > > > > > > > > > > > ___
Re: [bitcoin-dev] A Small Modification to Segwit
The version field is still needed to actually allow future block version upgrades. We would cut off our road forward if that were to be blocked. On Friday, 7 April 2017 22:06:39 CEST Jimmy Song via bitcoin-dev wrote: > Currently, the version bits (currently 4 bytes, or 32 bits) in the header > are used for BIP9 signaling. We change the version bits to a nonce-space > so the miners can use it for overt ASICBoost. The 32-bits are now moved > over to the Coinbase transaction as part of the witness commitment. The > witness commitment goes from 38 bytes to 42 bytes, with the last 4 bytes > being used as the version bits in the block header previously. The > witness commitment becomes required as per Gregory Maxwell’s proposal. > Reasoning -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Using a storage engine without UTXO-index
On Tue, Apr 11, 2017, at 03:44, Eric Voskuil wrote: > As I understand it you would split tx inputs and outputs and send them > independently, and that you intend this to be a P2P network > optimization - not a consensus rule change. So my comments are based > on those inferences. If we are talking about consensus changes this > conversation will end up in an entirely different place. > I don't agree with the input/output relevance statements above. When a > tx is announced the entire tx is relevant. It cannot be validated as > outputs only. If it cannot be validated it cannot be stored by the > node. Validating the outputs only would require the node store invalid > transactions. Splitting transactions only happens *on storage* and is just a minor optimization compared to storing them in full. (actually a very recent change with only marginally better results). This is simply because the output scripts are read on script validation, and storing the outputs of the transaction separately ensures better spatial locality of reference (the inputs are just "in the way"). This is not relevant when using a UTXO-index, because the outputs are then directly stored in the index, where bitcrust has to read them from the transaction data. It is not my intention to send them independently. > I do accept that a double-spend detection is not an optimal criteria > by which to discard a tx. One also needs fee information. But without > double-spend knowledge the node has no rational way to defend itself > against an infinity of transactions that spend the minimal fee but > also have conflicting inputs (i.e. risking the fee only once). So tx > (pool) validation requires double-spend knowledge and at least a > summary from outputs. Double spent information is still available to the network node and could still be used for DoS protection, although I do believe alternatives may exist. > > A reorg is conceptual and cannot be engineered out. What you are > referring to is a restructuring of stored information as a consequence > of a reorg. I don't see this as related to the above. The ability to > perform reorganization via a branch pointer swap is based not on the > order or factoring of validation but instead on the amount of > information stored. It requires more information to maintain multiple > branches. > > Transactions have confirmation states, validation contexts and spender > heights for potentially each branch of an unbounded number of > branches. It is this requirement to maintain that state for each > branch that makes this design goal a very costly trade-off of space > and complexity for reorg speed. As I mentioned earlier, it's the > optimization for this scenario that I find questionable. Sure, we can still call switching tips a "reorg". And it is indeed a trade off as orphan blocks are stored, but a block in the spend tree takes only ~12kb and contains the required state information. I believe this trade off reduced complexity. For the earlier tree this could be pruned. > Because choosing the lesser amount of work is non-consensus behavior. > Under the same circumstances (i.e. having seen the same set of blocks) > two nodes will disagree on whether there is one confirmation or no > confirmations for a given tx. This disagreement will persist (i.e. why > take the weaker block only to turn around and replace it with the > stronger block that arrives a few seconds or minutes later). It stands > to reason that if one rejects a stronger block under a race condition, > one would reorg out a stronger block when a weaker block arrives a > little after the stronger block. Does this "optimization" then apply > to chains of blocks too? The blockchain is - by design - only eventually consistent across nodes. Even if nodes would use the same "tip-selection" rules, you cannot rely on all blocks being propagated and hence each transaction having the same number of confirmations across all nodes. As a simpler example, if two miners both mine a block at approximately the same time and send it to each other, then surely they would want to continue mining on their own block. Otherwise they would be throwing away their own reward. And yes, this can also happen over multiple blocks, but the chances of consistency are vastly increased with each confirmation. > Accepting a block that all previous implementations would have > rejected under the same circumstance could be considered a hard fork, > but you may be right. I am not talking about rejecting blocks, I am only talking choosing on which tip to mine. > > Frankly, I think this is a bit of an exaggeration. Soft forks are > > counted on a hand, and I don't think there are many - if any - > > transactions in the current chain that have changed compliance > > based on height. > > Hope is a bug. > > If you intend this to be useful it has to help build the chain, not > just rely on hardwiring checkpoints once rule changes are presumed to > be buried deeply
Re: [bitcoin-dev] A Small Modification to Segwit
> I completely agree that it will be in the long term interest of bitcoin to > migrate, gradually, toward a commoditized POW away from the current mass > centralization. There is a big problem here though: Hundreds of millions of > dollars have been spent on the current algorithm, and will be a huge loss if > this is not done slowly enough, and the miners who control the chain > currently would likely never allow this change to happen. > Do you have any ideas regarding how to mitigate the damage of such a change > for the invested parties? Or even how we can make the change agreeable for > them? Apologies for interjecting a thought on this topic. My belief is that Bitcoin could grow freely, and become worth enough so that mining becomes profitable even for those of us in countries without free / subsidized electricity. By that time, buying commodity mining equipment (ASIC-based) from major manufacturers should be no problem, esp. not for existing Bitcoin holders. I see no sign that current major miners are principally opposed to such a natural process of decentralization of Bitcoin mining. Sancho___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Using a storage engine without UTXO-index
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/11/2017 01:43 AM, Tomas wrote: > Splitting transactions only happens *on storage* and is just a > minor optimization compared to storing them in full. Ok > Sure, we can still call switching tips a "reorg". And it is indeed > a trade off as orphan blocks are stored, but a block in the spend > tree takes only ~12kb and contains the required state information. > It's not the headers/tx-hashes of the blocks that I'm referring to, it is the confirmation and spend information relative to all txs and all outputs for each branch. This reverse navigation (i.e. utxo information) is essential, must be persistent and is branch-relative. > The blockchain is - by design - only eventually consistent across > nodes. Even if nodes would use the same "tip-selection" rules, you > cannot rely on all blocks being propagated and hence each > transaction having the same number of confirmations across all > nodes. > > As a simpler example, if two miners both mine a block at > approximately the same time and send it to each other, then surely > they would want to continue mining on their own block. Otherwise > they would be throwing away their own reward. That's not your concurrent validation scenario. In the scenario you described, the person chooses the weaker block of two that require validation because it's better somehow, not because it's his own (which does not require validation). > And yes, this can also happen over multiple blocks, but the chances > of consistency are vastly increased with each confirmation. Consistency is reached, despite seeing things at different times, because people use the same rules. If the economy ran on arbitrary block preference consistency would be elusive. > I am not talking about rejecting blocks, I am only talking choosing > on which tip to mine. This line of reasoning has me a bit baffled. Yet as I said, it's not important to the question at hand. It is not likely to be optimal to validate concurrently even if you consider selection of a weaker block advantageous. >> If you intend this to be useful it has to help build the chain, >> not just rely on hardwiring checkpoints once rule changes are >> presumed to be buried deeply enough to do so (as the result of >> other implementations ). >> >> I understand this approach, it was ours at one time. There is a >> significant difference, and your design is to some degree based >> on a failure to fully consider this. I encourage you to not >> assume any consensus-related detail is too small. > > I am not failing to consider this, and I don't consider this too > small . But ensuring contextual transaction validity by "validate > => valid with rules X,Y,Z" and then checking the active rules > (softfork activation) on order validation, will give logically the > same results as "validate with X,Y,Z => valid". This is not > "hardwiring checkpoints" at all. Storing the validation flags with each tx is exactly what libbitcoin does (otherwise pre-validation would be infeasible). But that was not the full point. You said on this in response previously: >>> ...height-based compliance as meta data of validation seems to >>> be adequate and safe. I read this as encoding the height at which a fork historically activated. If you intend to track activation for each branch that will not be "height-based" it will be history based. e -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJY7KTHAAoJEDzYwH8LXOFOI+QH/RzX++1TNLC9DEMWioE7SmMj yKOrP8WEkOnnrZdFKxVmwV9oZBekEvDABMnJmFiW5TMjsmPz7XwKAYzV0Y5L5oGU fZYo3IOPyr0dA9TcpP15gNziR6pFUBq/QTYB6BcbUvvlkJv6xjgIdedgDMEyREWU Hm/JU5g7gQUQd6MIDWbQ9FbYjtPuNSRQi851YfIn5mDivT4HuidaqQYMd9t5yS2Z FuoQBI6L5GTJIqml1bTwJ0wsA7+ZseBEgMn1TT1ehy2v1FFJTojTpzIwG+m3eiXg TxN3U/+fNAj+sKBb8Hq+nb7DvgjvKHyHuyRryBju7yq5d5rsb6meXcoiOtAznP8= =fRXf -END PGP SIGNATURE- ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Using a storage engine without UTXO-index
On Tue, Apr 11, 2017, at 11:41, Eric Voskuil wrote: > It's not the headers/tx-hashes of the blocks that I'm referring to, it > is the confirmation and spend information relative to all txs and all > outputs for each branch. This reverse navigation (i.e. utxo > information) is essential, must be persistent and is branch-relative. That is exactly what is stored in the spend-tree. >> As a simpler example, if two miners both mine a block at >> approximately the same time and send it to each other, then surely >> they would want to continue mining on their own block. Otherwise >> they would be throwing away their own reward. > That's not your concurrent validation scenario. In the scenario you > described, the person chooses the weaker block of two that require > validation because it's better somehow, not because it's his own > (which does not require validation). > Consistency is reached, despite seeing things at different times, > because people use the same rules. If the economy ran on arbitrary > block preference consistency would be elusive. No but my example shows that it is up to the miner to choose which tip to work on. This is not using different rules, it is just optimizing its income. This means that the economy *does* run on arbitrary "block preference", even if it is not running on arbitrary rules. If two blocks are competing, a miner could optimize its decision which to mine on, not just on whether one of the blocks is his own, but also on fees, or on excessive validation costs. > I read this as encoding the height at which a fork historically > activated. If you intend to track activation for each branch that will > not be "height-based" it will be history based. I understand "height-based" was not the right wording, as it is of course branch-specific. Per tip ruleset metadata, must be matched with per-transaction ruleset metadata. Tomas ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] A Small Modification to Segwit
The discussion is going offtopic. Can we please take vague discussions about changing pow, so called "asic resistance", the environment etc to bitcoin-disscuss or some other forum? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Proposed CSV configuration file format for bip-genvbvoting
Hi, The link below includes documentation about a proposed CSV-based file format for fork deployment data (tentative config filename: forks.csv). This is planned to be used by my reference implementation of bip-genvbvoting (which is still in development - TBA later). Other BIP9 improvement proposals are of course encouraged to use this format, and I'm happy to discuss extensions of it for things like supporting flag days or direct-to-activation transitions. Regards, Sancho https://raw.githubusercontent.com/sanch0panza/bitcoin/genvbvoting-bu-dev/doc/genvbvoting.md___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] A Small Modification to Segwit
Tom Zander wrote: > The version field is still needed to actually allow future block version > upgrades. We would cut off our road forward if that were to be blocked. I tend to agree, if all 32 bits were given up to grinding. But it's worth pointing out that BIP9 is purely informational, and the top 3 bits are still reserved for other purposes. One of them could perhaps be used to signal for an extended version field somewhere else, leaving the bottom 29 as entropy? Not a direction I prefer, but just a technical possibility perhaps.___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] A Small Modification to Segwit
I've changed the proposal so only 8 bits are given to grinding so something like 20 bits are available for signaling. I have to say I'm at a loss here as to what's next? Should I make a new BIP or try to convince the authors of BIP141 to modify their BIP? Could someone inform me on the next part of the process? On Tue, Apr 11, 2017 at 8:25 AM, Sancho Panza via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Tom Zander wrote: > > > The version field is still needed to actually allow future block version > upgrades. We would cut off our road forward if that were to be blocked. > > I tend to agree, if all 32 bits were given up to grinding. > > But it's worth pointing out that BIP9 is purely informational, and the top > 3 bits are still reserved for other purposes. One of them could perhaps be > used to signal for an extended version field somewhere else, leaving the > bottom 29 as entropy? > > Not a direction I prefer, but just a technical possibility perhaps. > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] A Small Modification to Segwit
g via bitcoin-dev schreef op ma 10-04-2017 om 20:39 [-0600]: > > However, we need to consider the environmental impact of mining, which > currently consumes a quite exorbitant amount of energy. Any ideas on > this front? Everything is relative. Some months ago I did some investigation and Bitcoin mining used lees energy than the diesel used by the gold ore mining industry... greets, Staf. signature.asc Description: This is a digitally signed message part ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] A Small Modification to Segwit
On Tue, Apr 11, 2017 at 4:40 PM, Jimmy Song via bitcoin-dev wrote: > I've changed the proposal so only 8 bits are given to grinding so something > like 20 bits are available for signaling. > > I have to say I'm at a loss here as to what's next? Should I make a new BIP > or try to convince the authors of BIP141 to modify their BIP? Could someone > inform me on the next part of the process? See bip2, specifically https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#bip-workflow "Following a discussion, the proposal should be submitted to the BIPs git repository as a pull request. This draft must be written in BIP style as described below, and named with an alias such as "bip-johndoe-infinitebitcoins" until the editor has assigned it a BIP number (authors MUST NOT self-assign BIP numbers)." But I think it's kind of late to modify bip141, given that there's code out there with the current specification. I guess you can propose extensions or alternatives to replace it. I'm really not sure what's the next step, but I don't think you have provided enough motivation as to why we would want to maintain asicboost. You said it makes the network more secure, but that's not the case, as explained, not even if all honest miners use it. > On Tue, Apr 11, 2017 at 8:25 AM, Sancho Panza via bitcoin-dev > wrote: >> >> Tom Zander wrote: >> >> > The version field is still needed to actually allow future block version >> > upgrades. We would cut off our road forward if that were to be blocked. >> >> I tend to agree, if all 32 bits were given up to grinding. >> >> But it's worth pointing out that BIP9 is purely informational, and the top >> 3 bits are still reserved for other purposes. One of them could perhaps be >> used to signal for an extended version field somewhere else, leaving the >> bottom 29 as entropy? >> >> Not a direction I prefer, but just a technical possibility perhaps. >> >> ___ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] A Small Modification to Segwit
Jorge, I'll be happy to discuss with you more about whether allowing ASICBoost would actually secure the network more or not, but that's not my main motivation. My main motivation is to get more miners to accept segwit. The version bit usage part, I don't believe requires any code changes as those bits aren't being used by BIP9 anyway, though some cleanup to restrict them later is probably a good idea. The requiring witness commitment part would require some changes, but according to Timo Hanke, that's actually not necessary as overt is so much more efficient. In any case, I'm happy to close this discussion until there's some indication that more miners would accept segwit as a result of this change. Jimmy On Tue, Apr 11, 2017 at 4:25 PM, Jorge Timón wrote: > On Tue, Apr 11, 2017 at 4:40 PM, Jimmy Song via bitcoin-dev > wrote: > > I've changed the proposal so only 8 bits are given to grinding so > something > > like 20 bits are available for signaling. > > > > I have to say I'm at a loss here as to what's next? Should I make a new > BIP > > or try to convince the authors of BIP141 to modify their BIP? Could > someone > > inform me on the next part of the process? > > See bip2, specifically > https://github.com/bitcoin/bips/blob/master/bip-0002. > mediawiki#bip-workflow > > "Following a discussion, the proposal should be submitted to the BIPs > git repository as a pull request. This draft must be written in BIP > style as described below, and named with an alias such as > "bip-johndoe-infinitebitcoins" until the editor has assigned it a BIP > number (authors MUST NOT self-assign BIP numbers)." > > But I think it's kind of late to modify bip141, given that there's > code out there with the current specification. > I guess you can propose extensions or alternatives to replace it. I'm > really not sure what's the next step, but I don't think you have > provided enough motivation as to why we would want to maintain > asicboost. You said it makes the network more secure, but that's not > the case, as explained, not even if all honest miners use it. > > > On Tue, Apr 11, 2017 at 8:25 AM, Sancho Panza via bitcoin-dev > > wrote: > >> > >> Tom Zander wrote: > >> > >> > The version field is still needed to actually allow future block > version > >> > upgrades. We would cut off our road forward if that were to be > blocked. > >> > >> I tend to agree, if all 32 bits were given up to grinding. > >> > >> But it's worth pointing out that BIP9 is purely informational, and the > top > >> 3 bits are still reserved for other purposes. One of them could perhaps > be > >> used to signal for an extended version field somewhere else, leaving the > >> bottom 29 as entropy? > >> > >> Not a direction I prefer, but just a technical possibility perhaps. > >> > >> ___ > >> bitcoin-dev mailing list > >> bitcoin-dev@lists.linuxfoundation.org > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >> > > > > > > ___ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
