- Dec 16, 2015
- 2,806
- 6,088
Announcement - Bitcoin project to full fork to flexible blocksizes
- Thread starter largerblocks
- Start date
- Dec 16, 2015
- 2,806
- 6,088
It would be great to know what the outstanding issues on the satoshisbitcoin fork were, so that perhaps someone else could assist / pick it up if he's inconvenienced or exited. @rocks?
The only serious thing I'm aware of - although not sure whether @rocks wanted to do something about it in his fork as it's a matter of philosophy to a degree - is that essentially the P2P protocol would also need to be forked if one wanted to ensure complete self-determination of one's transactions on the old/new chains (due to the possibility of a tx synchronization "attack" by involuntary bridges between the forks).
This is vitally important for fork arbitrage, which may play a crucial role in the success of a fork...
The only serious thing I'm aware of - although not sure whether @rocks wanted to do something about it in his fork as it's a matter of philosophy to a degree - is that essentially the P2P protocol would also need to be forked if one wanted to ensure complete self-determination of one's transactions on the old/new chains (due to the possibility of a tx synchronization "attack" by involuntary bridges between the forks).
This is vitally important for fork arbitrage, which may play a crucial role in the success of a fork...
- Dec 16, 2015
- 2,806
- 6,088
Tsontar
New Member
- Apr 9, 2016
- 24
- 79
> The entire network then becomes the deciding factor to find out which one "wins".
The problem I have with this argument @freetrader is that it stems from this idea that "there can be only one" coin and it simply eludes them that both chains will be viable, though likely the new fork will emerge with much less value. The idea isn't to "win" by "beating" the other coin, it's simply to take our current coin distributions and move them onto our prefered version of Bitcoin.
First off, most people are simply not going to sell their coins on the new chain, at least not all at once. Frankly, most people will be unaware of the fork for quite some time, as news will remain censored etc. And we know that Bitcoin holders don't trade on "news" anyway. So only a minority of holders will bother to sell their coins on the new chain anyway.
Secondly, nobody is going to "scam" anyone by sending them coins they can't accept, any more than people scam Bitcoin holders today by telling them they'll send them some Litecoin. A hard fork means that old clients will not accept the transactions / work of the new clients.
The problem I have with this argument @freetrader is that it stems from this idea that "there can be only one" coin and it simply eludes them that both chains will be viable, though likely the new fork will emerge with much less value. The idea isn't to "win" by "beating" the other coin, it's simply to take our current coin distributions and move them onto our prefered version of Bitcoin.
First off, most people are simply not going to sell their coins on the new chain, at least not all at once. Frankly, most people will be unaware of the fork for quite some time, as news will remain censored etc. And we know that Bitcoin holders don't trade on "news" anyway. So only a minority of holders will bother to sell their coins on the new chain anyway.
Secondly, nobody is going to "scam" anyone by sending them coins they can't accept, any more than people scam Bitcoin holders today by telling them they'll send them some Litecoin. A hard fork means that old clients will not accept the transactions / work of the new clients.
- Dec 16, 2015
- 2,806
- 6,088
@Tsontar: I won't claim to know whether Tom is right or wrong about this - I think absolute statements (or opinions) on such a matter can be refuted by reality.
I think he's right about the following (re: a POW change) but it's kind of obvious:
I think he's right about the following (re: a POW change) but it's kind of obvious:
Certainly I share your view that both chains *could* be viable, and that a non-elective hard fork would need to emerge with far less value.
This takes work to ensure. A naive hard fork could suffer from problems in this regard, at least for all transactions that only involve pre-fork inputs.
The real issue here is the Power. Someone said it perfectly: Power is the ability to affect people, the more people you can affect, the larger that power. Currently core have that power since they have time and first mover advantage on their side, this power is invisible but quite strong especially to people who don't understand bitcoin and many late comers after 2013. So the only chance that other implementation would gain ground is their implementation failed. But the problem is that when their implementation failed, there might not be a chance for bitcoin to success anymore, since you can't reverse transactions on blockchain, once you are transacting in segwit, there is no way back.
For example, segwit went online and result in a total failure, then how do we fix it? Because by then blockchain is contaminated by many "anyonecanspend" transactions, you have to rebuild the blockchain from an old block that does not have segwit transaction yet, but that means all the transactions since segwit activation will be reversed, equal to a double spending in the new chain
As a result, now I don't think making a fork is really going to help (might be interesting to make a private bitcoin fork as hobby). If bitcoin is really corrupted, then it means the idea of dencentralization is utopian from the beginning: It will be centralized sooner or later, just a matter of time. If so, why not pick a coin that is much better centrally managed, for example Ethereum? And quietly watch how this corrupted bitcoin fails
For example, segwit went online and result in a total failure, then how do we fix it? Because by then blockchain is contaminated by many "anyonecanspend" transactions, you have to rebuild the blockchain from an old block that does not have segwit transaction yet, but that means all the transactions since segwit activation will be reversed, equal to a double spending in the new chain
As a result, now I don't think making a fork is really going to help (might be interesting to make a private bitcoin fork as hobby). If bitcoin is really corrupted, then it means the idea of dencentralization is utopian from the beginning: It will be centralized sooner or later, just a matter of time. If so, why not pick a coin that is much better centrally managed, for example Ethereum? And quietly watch how this corrupted bitcoin fails
Last edited:
- Dec 16, 2015
- 2,806
- 6,088
Cross-posting a comment of mine from the GCBU thread because it will be submerged there quickly:
What would be really helpful is if some experienced eyes could take a close look at @rocks' scrypt hash code and compare to other sources, provide some review.
The changes are mainly in the added files in src/crypto/ and the modified src/hash.* :
https://github.com/satoshisbitcoin/satoshisbitcoin/commit/e9af835faa79ab416a41ae6fa0c9d5aee08d22c5
I also need to gather more seed node addresses for public testing (primarily static IPs at first, but even better if you can run a DNS seed). For seeds I will only accept trusted contacts that I've met and got to know on this forum or others I trust, so direct message me on here if you think you can help with running a node during tests.
In terms of static seeds, I have some IPv4's, but it would be best to get some IPv6's and onion addresses configured in.
It will still be a while before we can start public testing, unfortunately, since there is still a bunch of private testing and work I have to do around clean transaction separation, difficulty algo tuning and then the POW code integration and testing. I will make more announcements when the public testing phase kicks off. Expect early public testers might have to compile their own builds.
Not only on board, but very much swayed in favor of preferring a POW fork now that there is little to no reliable "friendly hashpower". But still committed to producing a non-POW fork at roughly the same time.Hm. KNC out of business is bad news.
[...]
Apart from that, all this still screams for a PoW fork, ready asap. With @rocks mysteriously disappeared, anybody still on board?
What would be really helpful is if some experienced eyes could take a close look at @rocks' scrypt hash code and compare to other sources, provide some review.
The changes are mainly in the added files in src/crypto/ and the modified src/hash.* :
https://github.com/satoshisbitcoin/satoshisbitcoin/commit/e9af835faa79ab416a41ae6fa0c9d5aee08d22c5
I also need to gather more seed node addresses for public testing (primarily static IPs at first, but even better if you can run a DNS seed). For seeds I will only accept trusted contacts that I've met and got to know on this forum or others I trust, so direct message me on here if you think you can help with running a node during tests.
In terms of static seeds, I have some IPv4's, but it would be best to get some IPv6's and onion addresses configured in.
It will still be a while before we can start public testing, unfortunately, since there is still a bunch of private testing and work I have to do around clean transaction separation, difficulty algo tuning and then the POW code integration and testing. I will make more announcements when the public testing phase kicks off. Expect early public testers might have to compile their own builds.
@freetrader
Tom Zander and generally almost all the Bitcoin devs, Core or otherwise, seem to treat an actual split into multiple persistent copies of the ledger as out of the range of discussion. Either because they think it's a non-starter or because they have just never thought about it or assume we always have to confine the discussion to a single persistent chain. It's kind of beyond the scope of a dev's work so in some ways we shouldn't expect an answer. It's more down to what investors value. If they want a split, meaning there are a lot of investors who value one fork and a lot who value the other one, then it can happen and should be able to work with a PoW change.
The way you'd know beforehand how much hashing power you would have is that you'd already have a prediction market predicting the price, via fork futures trading on the Bitcoin exchanges. If people know the new fork with a new PoW will have a non-zero price, they will be gearing up to mine it. If they know there's a good chance it will have an even higher price than the SHA256 chain, they will sure as hell be gearing up to mine it.
Tom Zander and generally almost all the Bitcoin devs, Core or otherwise, seem to treat an actual split into multiple persistent copies of the ledger as out of the range of discussion. Either because they think it's a non-starter or because they have just never thought about it or assume we always have to confine the discussion to a single persistent chain. It's kind of beyond the scope of a dev's work so in some ways we shouldn't expect an answer. It's more down to what investors value. If they want a split, meaning there are a lot of investors who value one fork and a lot who value the other one, then it can happen and should be able to work with a PoW change.
The way you'd know beforehand how much hashing power you would have is that you'd already have a prediction market predicting the price, via fork futures trading on the Bitcoin exchanges. If people know the new fork with a new PoW will have a non-zero price, they will be gearing up to mine it. If they know there's a good chance it will have an even higher price than the SHA256 chain, they will sure as hell be gearing up to mine it.
- Dec 16, 2015
- 2,806
- 6,088
@Zangelbert Bingledack :
I understand why Bitcoin devs associated to non-Core projects show great reservation when discussing the forking subject. I don't know of a cryptocurrency that has undergone a market-decided hard fork over such an issue. I think Bitcoin would be the first to achieve this and it would set a healthy precedent (Bitcoin's rules are indeed hard to change, but it's possible). I accept there is a not-insignificant element of risk that the market may also react in an unfavorable way to news of a spin-off.
Specifically w.r.t. the Classic project, I think that the confidence of the developers in the chances of their hard fork being very clean (once it reaches activation) is reasonable and borne out by its design.
I consider the 75% + 28 days grace design to be safe, having seen no substantial counterarguments by industry. And it makes sense for them to "stay the course" on a minimal-change fork that brings home the central part of the scaling debate.
What encourages me is that project devs, esp. among Classic/XT/BU, are generally very open to collaborating when it comes to improvements. I hope that they will contribute to any spin-offs by critically reviewing the code and methods to ensure that any such spin-off does not hurt any of Bitcoin's fundamental properties or unfairly favors anyone. Beyond that peer review process, I think project credibility requires each effort to stand on its own.
A prediction market like you describe could be very useful - I wish an exchange would make that happen.
I don't know enough about the dynamics of such things to say what their effect would be, but exchanges are certainly vital - without options to trade against other cryptocurrencies on a level playing field, I have no doubt that any spin-off would face major difficulties.
I understand why Bitcoin devs associated to non-Core projects show great reservation when discussing the forking subject. I don't know of a cryptocurrency that has undergone a market-decided hard fork over such an issue. I think Bitcoin would be the first to achieve this and it would set a healthy precedent (Bitcoin's rules are indeed hard to change, but it's possible). I accept there is a not-insignificant element of risk that the market may also react in an unfavorable way to news of a spin-off.
Specifically w.r.t. the Classic project, I think that the confidence of the developers in the chances of their hard fork being very clean (once it reaches activation) is reasonable and borne out by its design.
I consider the 75% + 28 days grace design to be safe, having seen no substantial counterarguments by industry. And it makes sense for them to "stay the course" on a minimal-change fork that brings home the central part of the scaling debate.
What encourages me is that project devs, esp. among Classic/XT/BU, are generally very open to collaborating when it comes to improvements. I hope that they will contribute to any spin-offs by critically reviewing the code and methods to ensure that any such spin-off does not hurt any of Bitcoin's fundamental properties or unfairly favors anyone. Beyond that peer review process, I think project credibility requires each effort to stand on its own.
A prediction market like you describe could be very useful - I wish an exchange would make that happen.
I don't know enough about the dynamics of such things to say what their effect would be, but exchanges are certainly vital - without options to trade against other cryptocurrencies on a level playing field, I have no doubt that any spin-off would face major difficulties.
Last edited:
@freetrader
I feel like spinoffs will be a continual thing in the future. There might be weekly spinoffs, almost all of them ignored and seeing only a tiny bit of trading by arbitrageurs ready to take money from each deadend spinoff's supporters. Of course whenever there is an actual need for a spinoff, the sellers have a chance to lose their shirts. There is no real harm in having tons of spinoffs as we are approaching a governance challenge. They will just be ignored until needed, like freeway offramps. When needed, I think everything said about spinoffs in the past will suddenly be forgotten and people will see them as the way forward.
So if a spinoff faces difficulties, it will generally just be bypassed until the next weekly batch of spinoffs, or whatever the timescale is.
The effect once the system is mature should be thus: Bitcoin can and will change however it needs to, whenever it needs to, but will only do this if there is sufficient investor support - a high bar to reach. Also, there is a possibility that "winner does NOT take all" and we end up with a split into two persistent chains, which start out updating the very same ledger. Those cases, too, would only happen when the market deems a split to be the most value-enhancing.
Futures markets should provide a very powerful preview (as powerful as the legendary accuracy of prediction markets) of how a spinoff will fare, making it easy to know whether to take a spinoff seriously, and to know this well in advance so that mining and infrastructure can be put in place and so that real debate of an urgent pitch can happen in case there are any issues.
I feel like spinoffs will be a continual thing in the future. There might be weekly spinoffs, almost all of them ignored and seeing only a tiny bit of trading by arbitrageurs ready to take money from each deadend spinoff's supporters. Of course whenever there is an actual need for a spinoff, the sellers have a chance to lose their shirts. There is no real harm in having tons of spinoffs as we are approaching a governance challenge. They will just be ignored until needed, like freeway offramps. When needed, I think everything said about spinoffs in the past will suddenly be forgotten and people will see them as the way forward.
So if a spinoff faces difficulties, it will generally just be bypassed until the next weekly batch of spinoffs, or whatever the timescale is.
The effect once the system is mature should be thus: Bitcoin can and will change however it needs to, whenever it needs to, but will only do this if there is sufficient investor support - a high bar to reach. Also, there is a possibility that "winner does NOT take all" and we end up with a split into two persistent chains, which start out updating the very same ledger. Those cases, too, would only happen when the market deems a split to be the most value-enhancing.
Futures markets should provide a very powerful preview (as powerful as the legendary accuracy of prediction markets) of how a spinoff will fare, making it easy to know whether to take a spinoff seriously, and to know this well in advance so that mining and infrastructure can be put in place and so that real debate of an urgent pitch can happen in case there are any issues.
I always like to note that it isn't really about giving Bitcoin the "just right" amount of conservatism toward change, but rather about letting the market of investors determine the change. Bitcoin investors have a fundamental conservatism because its value derives from its function as sound money, but they would be quite willing to change when it is clearly necessary. Rather than just falling somewhere on the spectrum between liberal and conservative, with spinoffs moving the system toward liberal, I think they in fact move the system toward "intelligent." Conservative about change on matters where it's warranted, liberal about change on matters where it isn't. It's the wisdom of crowds channeled properly, through market, and this is what I've always thought of Bitcoin as anyway. It's not the wisdom of Satoshi, he just got it on a decent-enough footing (see the Forkology series 101 to 501 here if you haven't yet; I think you may find it quite interesting).
Last edited:
- Dec 16, 2015
- 2,806
- 6,088
A little update. Sorry it took so long.
I'm happy to report that my fork (non-POW up to now) has mined its first two consecutive > 1 MB blocks in an automated regtest (a rudimentary adaptation of Classic's bigblocks.py test).
It took quite some work to get to this result, as I found a number of things apparently missing or overlooked in the released Bitpay code. These things seem to be needed in the real world (e.g. not having various instantiations of the same global variables - aaarg!)
Being not-so-familiar with the innards, I opened the patient up and rummaged around the inner organs. It's more alive than dead now, but a lot of cleaning up and refactoring will need to be done after the mess I created. However, overall it looks encouraging for testnet trials soonish. Still a number of things I'd like to do first though:
1. Use a variation on @bitcartel 's BUIP018 - I might not use the bitnodes API but I like being able to specify DNS seeds in configuration / as command line arguments. Ideally I would like to rip out the static DNS seeds completely and have them in a configuration file. If anyone's seen another client that does this, drop me a hint, if I can I'd like to save time re-inventing wheels.
2. Transaction separation (making it impossible to get txs mixed up between old/new chain after the fork). Not sure yet how much work this will turn out to be, but it's crucial.
3. Create a separate experimental branch for the POW. Can't go fancy with UTXO set hashing or other grand ideas some have suggested. I'll stick to @rocks ' scrypt-based POW in the first iteration (we can always change the POW again later ;-)
4. I've tested the Classic port of Xtreme Thinblocks, which seems work alright on Classic 0.12.0.
It should be trivial to port that to my fork, since it uses Classic 0.12.0 as a base. I would definitely like to incorporate xthinblocks from day zero. What's the point of a bigger-blocks fork without the fastest proven decentralized block propagation technology?
I realize some of you may have further specific questions. PM me if you do, I'll tell you what I can (not all things are known to me yet...)
I'm happy to report that my fork (non-POW up to now) has mined its first two consecutive > 1 MB blocks in an automated regtest (a rudimentary adaptation of Classic's bigblocks.py test).
It took quite some work to get to this result, as I found a number of things apparently missing or overlooked in the released Bitpay code. These things seem to be needed in the real world (e.g. not having various instantiations of the same global variables - aaarg!)
Being not-so-familiar with the innards, I opened the patient up and rummaged around the inner organs. It's more alive than dead now, but a lot of cleaning up and refactoring will need to be done after the mess I created. However, overall it looks encouraging for testnet trials soonish. Still a number of things I'd like to do first though:
1. Use a variation on @bitcartel 's BUIP018 - I might not use the bitnodes API but I like being able to specify DNS seeds in configuration / as command line arguments. Ideally I would like to rip out the static DNS seeds completely and have them in a configuration file. If anyone's seen another client that does this, drop me a hint, if I can I'd like to save time re-inventing wheels.
2. Transaction separation (making it impossible to get txs mixed up between old/new chain after the fork). Not sure yet how much work this will turn out to be, but it's crucial.
3. Create a separate experimental branch for the POW. Can't go fancy with UTXO set hashing or other grand ideas some have suggested. I'll stick to @rocks ' scrypt-based POW in the first iteration (we can always change the POW again later ;-)
4. I've tested the Classic port of Xtreme Thinblocks, which seems work alright on Classic 0.12.0.
It should be trivial to port that to my fork, since it uses Classic 0.12.0 as a base. I would definitely like to incorporate xthinblocks from day zero. What's the point of a bigger-blocks fork without the fastest proven decentralized block propagation technology?
I realize some of you may have further specific questions. PM me if you do, I'll tell you what I can (not all things are known to me yet...)
Last edited:
- Dec 16, 2015
- 2,806
- 6,088
@Richy_T : hope you don't mind that I answer your question from the GCBU thread here:
Once private testing has reached a state where I have confidence to release, I will first move to public tests like Satoshisbitcoin did (testnet/mainnet).
I don't know how much bugfixing time will be needed, but I'd anticipate a few trials over a few weeks to iron things out. In that time we'll prepare for a public information campaign. Once preparations are complete, the code will be released WITHOUT the finalized trigger heights.
We will give the public a defined timespan to absorb the information, somewhere between 2-4 weeks is my current thinking. After that, finalized source code (incl. the trigger heights) and official signed binaries should be released together, and folks who want to mine will have a relatively short time from there to get ready, which should be ok since they'll already have had a few weeks prior to check it out, plan and prepare.
A firm goal is to maintain the highest degree of fairness possible and avoid any conditions that might enable unfair "premining" or similar.
I am always open to opinions on the process in general, and specific suggestions on how to safeguard the fairness.
No, this is not decided yet. Here's what I envisage happening:
Once private testing has reached a state where I have confidence to release, I will first move to public tests like Satoshisbitcoin did (testnet/mainnet).
I don't know how much bugfixing time will be needed, but I'd anticipate a few trials over a few weeks to iron things out. In that time we'll prepare for a public information campaign. Once preparations are complete, the code will be released WITHOUT the finalized trigger heights.
We will give the public a defined timespan to absorb the information, somewhere between 2-4 weeks is my current thinking. After that, finalized source code (incl. the trigger heights) and official signed binaries should be released together, and folks who want to mine will have a relatively short time from there to get ready, which should be ok since they'll already have had a few weeks prior to check it out, plan and prepare.
A firm goal is to maintain the highest degree of fairness possible and avoid any conditions that might enable unfair "premining" or similar.
I am always open to opinions on the process in general, and specific suggestions on how to safeguard the fairness.
Last edited:
- Dec 16, 2015
- 2,806
- 6,088
I've said this before two posts up:
One discussion I've found (context was initial block sync though):
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011065.html
However, on the POW fork I may entertain this kind of idea if someone can point me to a working implementation (on some kind of coin), or even a reviewed paper with experimental results on this topic. Obviously we can't risk introducing a POW mechanism into Bitcoin which might fail even in the slightest corner case, so this would lengthen the testing time for a fork which includes this. I also don't want to spend time trying to implement something in a subject field with which I'm too unfamiliar to tread confidently at this stage.
One discussion I've found (context was initial block sync though):
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011065.html
Last edited:
Tsontar
New Member
- Apr 9, 2016
- 24
- 79
@freetrader on the one hand social covenants don't actually hold water in crypto; nevertheless I urge you to publish a manifesto or covenant of values with regards to the fork and its code. For example if the purpose of UTXO set hashing is to ensure "all miners are fullnodes" then state that publicly. Maybe even reference that in the code.
It's one thing to write some code believing that it encodes certain properties or values. If the emergent system does not actually produce said values, it's good to be able to know if our values are wrong, or maybe the code simply should be improved.
Oh if only Satoshi had done this with the block size limit.
It's one thing to write some code believing that it encodes certain properties or values. If the emergent system does not actually produce said values, it's good to be able to know if our values are wrong, or maybe the code simply should be improved.
Oh if only Satoshi had done this with the block size limit.
- Dec 16, 2015
- 2,806
- 6,088
@Tsontar: A manifesto was the first thing I produced. It will be updated and revised, but only released together with the initial public information release.
Please understand that the release of the manifesto would directly reveal the project name, which is a detail that I don't want to reveal at this point to protect infrastructure and the momentum of other projects. About the nature of the fork, I feel this forum offers a good place for advance discussion.
If I can summarize the fundamental tenets of this fork:
PRESERVE THE FUNDAMENTAL QUALITIES OF BITCOIN:
- preserve the 21M coin limit
- preserve the existing ledger (spin off, same genesis block and history up to trigger height)
- preserve the Nakamoto consensus (longest valid chain)
- preserve the 10 minute block period
- preserve the halving schedule (no change to halving algorithm)
- preserve the P2P qualities of the protocol
- (non-POW fork) preserve the SHA256 POW
The POW fork will change to an ASIC-resistent, memory-hard POW function, most probably @rocks' scrypt-based algorithm.
Both forks will use a modified difficulty algorithm, details of which I will not disclose right now, except to say it will be used to re-target at every block.
Both forks will use a modified version of BitPay's adaptive algorithm (the median calculation remains the same, but the soft limit scaling is modified). The lower/upper limits of the dynamic cap might also be adjusted - I am currently considering a 4MB upper limit and a 2MB lower limit.
The forks shall be clean - transactions after the fork trigger shall be incompatible with transactions on the old chain (and the POW/non-POW fork transactions shall also be mutually incompatible).
I wish to include Xthinblock support right from the start.
The code will be released under the same MIT license, on a publicly accessible repository.
W.r.t. UTXO set hashing, I am calling for more information right now, but I am skeptical that sufficient clarity can be reached on this point. It would certainly be a major change with repercussions as you mentioned, and I don't want to put any declarations related to that in a manifesto until it's clear that there is strong community support for it and it is feasible.
Please understand that the release of the manifesto would directly reveal the project name, which is a detail that I don't want to reveal at this point to protect infrastructure and the momentum of other projects. About the nature of the fork, I feel this forum offers a good place for advance discussion.
If I can summarize the fundamental tenets of this fork:
PRESERVE THE FUNDAMENTAL QUALITIES OF BITCOIN:
- preserve the 21M coin limit
- preserve the existing ledger (spin off, same genesis block and history up to trigger height)
- preserve the Nakamoto consensus (longest valid chain)
- preserve the 10 minute block period
- preserve the halving schedule (no change to halving algorithm)
- preserve the P2P qualities of the protocol
- (non-POW fork) preserve the SHA256 POW
The POW fork will change to an ASIC-resistent, memory-hard POW function, most probably @rocks' scrypt-based algorithm.
Both forks will use a modified difficulty algorithm, details of which I will not disclose right now, except to say it will be used to re-target at every block.
Both forks will use a modified version of BitPay's adaptive algorithm (the median calculation remains the same, but the soft limit scaling is modified). The lower/upper limits of the dynamic cap might also be adjusted - I am currently considering a 4MB upper limit and a 2MB lower limit.
The forks shall be clean - transactions after the fork trigger shall be incompatible with transactions on the old chain (and the POW/non-POW fork transactions shall also be mutually incompatible).
I wish to include Xthinblock support right from the start.
The code will be released under the same MIT license, on a publicly accessible repository.
W.r.t. UTXO set hashing, I am calling for more information right now, but I am skeptical that sufficient clarity can be reached on this point. It would certainly be a major change with repercussions as you mentioned, and I don't want to put any declarations related to that in a manifesto until it's clear that there is strong community support for it and it is feasible.
Last edited:
- Dec 16, 2015
- 2,806
- 6,088
Largely merged @rocks' modified scrypt hash, and have run the POW fork and the non-POW fork against each other. Can confirm they hate each other once the fork triggers ;-)
Lots more work to do though.
My dev machine seems slow - a scrypt hash that should take 1 sec according to original code comments takes a couple of seconds. More testing and a thorough look at the scrypt code is definitely needed.
Didn't get any reviewers for @rocks' scrypt code at my last request - any takers?
The modified scrypt code still attributes Colin Percival [1] (at least partly), but I haven't had a look at where exactly it was ripped out of (Litecoin perhaps? or somewhere closer to the source).
It's a pity @rocks isn't around to ask...
[1] http://www.tarsnap.com/scrypt.html
Lots more work to do though.
My dev machine seems slow - a scrypt hash that should take 1 sec according to original code comments takes a couple of seconds. More testing and a thorough look at the scrypt code is definitely needed.
Didn't get any reviewers for @rocks' scrypt code at my last request - any takers?
The modified scrypt code still attributes Colin Percival [1] (at least partly), but I haven't had a look at where exactly it was ripped out of (Litecoin perhaps? or somewhere closer to the source).
It's a pity @rocks isn't around to ask...
[1] http://www.tarsnap.com/scrypt.html
Last edited:
- Dec 16, 2015
- 2,806
- 6,088
Folks, help me weigh the risk:
If we release a hard fork version for public testing which is not yet "clean" in terms of transactions separation (i.e. selling some pre-fork coins on the fork chain has a risk of resulting in those coins being sold on the current Bitcoin chain) ...
... is this risk too high to take?
Reason I am asking is because on the one hand, I feel that starting public testing ASAP would be appropriate (and possible), but I don't want it to be unsafe and some poor sod accidentally selling his non-fork coins.
Opinions?
If we release a hard fork version for public testing which is not yet "clean" in terms of transactions separation (i.e. selling some pre-fork coins on the fork chain has a risk of resulting in those coins being sold on the current Bitcoin chain) ...
... is this risk too high to take?
Reason I am asking is because on the one hand, I feel that starting public testing ASAP would be appropriate (and possible), but I don't want it to be unsafe and some poor sod accidentally selling his non-fork coins.
Opinions?
- Dec 16, 2015
- 2,806
- 6,088
Thanks @jl777, those are some good tips in that thread. I opened another thread on this forum recently:
https://bitco.in/forum/threads/staying-safe-while-forking-hard.1219/
to which the link you posted would be a nice contribution.
What I was thinking that because it would only be a public trial (probably one of several before final release), it would come with big fat disclaimers that people should definitely not run it with their existing wallets, or treat it as any sort of real money.
I guess with a bit of tinkering I could make a testnet-only release which won't run on mainnet at all, but I'm kind of not so keen to invest that extra effort for temporary gain.
https://bitco.in/forum/threads/staying-safe-while-forking-hard.1219/
to which the link you posted would be a nice contribution.
What I was thinking that because it would only be a public trial (probably one of several before final release), it would come with big fat disclaimers that people should definitely not run it with their existing wallets, or treat it as any sort of real money.
I guess with a bit of tinkering I could make a testnet-only release which won't run on mainnet at all, but I'm kind of not so keen to invest that extra effort for temporary gain.
Last edited: