The whitepaper is in its final draft. There is no working code yet so the ideas are half-baked so to speak. I want to code everything minimally by year end 2014. I am used to Java and enterprise style regression tests, automated builds and continuous integration servers. I have forked the GitHub repository for Bitcoin and will keep my branch up to date with the main branch.
I like NetBeans for Java, and will first experiment with getting C++ installed there. My development box is Ubuntu and I also run a local Ubuntu server.
Topic: AI Coin Development Diary - page 14. (Read 49308 times)
The Hard Fork
Copied from the poll thread . . .
The Bitcoin brand is not an enforced trademark and the core developers have a policy of neutrality with regard to controversy. My project, to be deployed at the beginning of 2016 after a year of public testing and scrutiny, will use the then-current blockchain as the initial distribution. The new version will exchange transactions with the old version on the existing network. Both versions will reject any transactions tainted by rewards created by the other version after the hard-fork date.
I need at least a three to one advantage with regard to peer full nodes on my version. For proof-of-stake to work I need the cooperation of the largest holders. I need the cooperation of transactors such as third-party wallet providers, hosted wallet providers, and nearly all the major exchanges. One or more transitional SHA-256 multipools will provide untainted bitcoin for its participating ASIC miners. During the year of testing, the project open source will be provided to at least one altcoin already in circulation.
There will be three prices for bitcoin after the hard-fork. The main price will be for untainted coins mined before the hard-fork. The second price will be for coins tainted by proof-of-work rewards issued after the hard-fork. The third price will be for coins tainted by proof-of-stake rewards issued after the hard-fork. I expect selling pressure on the tainted proof-of-work coins as ASIC miners necessarily must sell to buy equipment and purchase power.
The new version will be have the features, to attract the needed majority . . .
The consensus of users, as designed by Satoshi, will pick the winner. Unless the odds beforehand are very much in this project's favor, the hard-fork will not occur as fragmentation of the system hurts us all. Yet the wastefulness of the current system compels a timely solution.
Copied from the poll thread . . .
I got a question here.
Can bitcoin really switch to PoS? Wouldn't it just create a hard fork and create a new altcoin?
Can bitcoin really switch to PoS? Wouldn't it just create a hard fork and create a new altcoin?
The Bitcoin brand is not an enforced trademark and the core developers have a policy of neutrality with regard to controversy. My project, to be deployed at the beginning of 2016 after a year of public testing and scrutiny, will use the then-current blockchain as the initial distribution. The new version will exchange transactions with the old version on the existing network. Both versions will reject any transactions tainted by rewards created by the other version after the hard-fork date.
I need at least a three to one advantage with regard to peer full nodes on my version. For proof-of-stake to work I need the cooperation of the largest holders. I need the cooperation of transactors such as third-party wallet providers, hosted wallet providers, and nearly all the major exchanges. One or more transitional SHA-256 multipools will provide untainted bitcoin for its participating ASIC miners. During the year of testing, the project open source will be provided to at least one altcoin already in circulation.
There will be three prices for bitcoin after the hard-fork. The main price will be for untainted coins mined before the hard-fork. The second price will be for coins tainted by proof-of-work rewards issued after the hard-fork. The third price will be for coins tainted by proof-of-stake rewards issued after the hard-fork. I expect selling pressure on the tainted proof-of-work coins as ASIC miners necessarily must sell to buy equipment and purchase power.
The new version will be have the features, to attract the needed majority . . .
- immediate transaction acknowledgment for incorporation into the blockchain, which is checkpointed every 10 minutes following the new block
- mining rewards distributed via pools in proportion to provided stakes
- transactions will be included that have lower fees than present and no-fee transactions will be much more likely to be accepted
- only one version of the blockchain exists, has broad consensus approval and is widely replicated
- network cryptographic audit trail
The consensus of users, as designed by Satoshi, will pick the winner. Unless the odds beforehand are very much in this project's favor, the hard-fork will not occur as fragmentation of the system hurts us all. Yet the wastefulness of the current system compels a timely solution.
The Satoshi Social Contract
Bitcoin core developers speak of the Satoshi Social Contract as those features of Bitcoin that have been promised by Satoshi, and upon which the integrity of Bitcoin rests. For example, releasing a new version of the Bitcoin Core client that increases the upper limit of mined coins breaks the social contract between the core developers and bitcoin using public.
In this project, proof-of-work will be replaced by proof-of-stake, and a pure decentralized peer-to-peer asynchronous mesh network will be replaced by a hierarchical peer-to-peer synchronous network.
To what degree of severity, does this project break Satoshi's promises, and can the result be called Bitcoin despite claimed advantages?
---------------------------------------------------------------------------------------
Here are the notable promises extracted from the defining whitepaper Bitcoin: A Peer-to-Peer Electronic Cash System by Satoshi Nakamoto.
From the Abstract . . .
* Bitcoin is a purely peer-to-peer version of electronic cash that allows online payments to be sent directly from one party to another without going through a financial institution. Retained as-is.
* The Bitcoin network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The data structure is retained with a zero-difficulty proof-of-work.
* Bitcoin messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone. Bitcoin messages are routed along fault-tolerant paths from the originating peer to a certain peer having the role of temporary mint, which echos each received transaction back to the network as instant acknowledgment that it will be included according to order received in the ongoing record chain.
From section 1. Introduction . . .
* Bitcoin is an electronic payment system based upon cryptographic proof instead of trust, allowing any two willing parties to transact directly with each other without the need for a trusted third party.Retained as-is.
* Transactions that are computationally impractical to reverse would protect sellers from fraud, and routine escrow mechanisms protect buyers. Mechanism changed - to be explained.
* Bitcoin is a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions. Retained as-is.
* The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes. Mechanism changed - to be explained.
From section 2. Transactions . . .
* Bitcoin defines an electronic coin as a chain of digital signatures. A payee can verify the signature of a received transaction by computing the transaction payer's digital signature and the payer's public key. Retained as-is.
* [Because the private key is required by the payer to sign the transaction, if the private key is lost, then the transaction cannot be performed.] Retained as-is.
* Bitcoin transactions are publicly announced. Retained as-is.
* In the event of multiple transactions from the same address, the earliest issued transactions counts, and subsequent others are dropped. Retained as-is.
* Bitcoin is a system whereby the participants agree on a single history of the order in which transactions were received. Retained as-is.
* The payee has proof that at the time of each transaction, the majority of nodes agreed it was the first received. Retained as-is.
From section 3. Timestamp Server . . .
* Transaction are gathered into blocks. Retained as-is.
* The blockchain consists of timestamped blocks whose embedded hash includes the hash of the previous timestamped block, forming a chain. Retained as-is.
From section 4. Proof-of-Work . . .
* The block contains a SHA-256 hash having a certain number of leading binary zeros, determined by increment a number-used-once until a value is found that gives the block's hash the required zero bits. Retained as-is for backwards compatibility, but the zero-difficulty means the effort is trivial.
* Proof-of-work difficulty is determined by a moving average targeting an average number blocks per hour. Changed - the difficulty is always one, which is the lowest value.
From section 5. Network . . . Changed - to be explained.
* The steps to run the network are as follows:
* Nodes always consider the longest chain to be the correct one.
* Nodes receiving two different version of the next block, work on the first version received, but abandon that branch if a longer chain is received from any peer node.
* Transactions reaching many nodes have a high probability of being included in a block.
* Nodes missing a broadcast block may subsequently know to ask for it by number when the next block is received the gap recognized.
From section 6. Incentive . . .
* The first transaction in a block is a special transaction that starts a new coin owned by the creator of the block. Retained as-is.
* The new coin awarded to the block creator is the only way to initially distribute coins into circulation. Retained as-is.
* The transaction fee is equal to the transaction's input value minus its output value and is added to the block reward received by the block creator. Retained as-is.
* The incentive may help encourage nodes to stay honest. Retained as-is.
From section 7. Reclaiming Disk Space . . .
* Transactions are stored within the block in the configuration of a Merkle Tree, with only the root included in the block's hash. Retained as-is.
* Once the latest transactions in a coin is buried under enough blocks, the spent transactions before it can be discarded to save disk space. Retained as-is.
From section 8. Simplified Payment Verification . . .
* It is possible to verify payments without running a full node. Retained as-is.
* Verification is performed by querying network full nodes until the SPV node probably has the longest chain of block headers. The transaction timestamp indicates which chronologically ordered block must contain the transaction. The SPV node requests that block's Merkle branch and determines the presence of the transaction to be verified. Retained as-is.
* The number of following blocks is a measure of confidence that the chain will not be reverted back to before the transaction was accepted into its block. Changed - to be explained.
* A SPV node is more vulnerable to attack as it depends upon the honesty of its connected full nodes. Retained as-is.
From section 9. Combining and Splitting Value . . .
* To allow value to split and combined, transactions contain multiple inputs and outputs. Retained as-is.
* [The inputs must be unspent to create a valid transaction. When the transaction is accepted by the network, its inputs are regarded as spent, and its outputs are regarded as unspent in the absence of a subsequent transaction having that coin as an input.] Retained as-is.
* Despite the recursive chain of dependency on a transaction's inputs, there is never the need to extract a complete standalone copy of a transaction's history. Retained as-is.
From section 10. Privacy . . .
* Privacy can be maintained by keeping public keys anonymous. Retained as-is.
* New public / private key pairs may be used by the receiver of each transaction to keep them from being linked to common owner. Retained as-is.
* Multiple inputs to transactions indicate common ownership of the inputs due to the necessity of the owner signing each of them with private key corresponding to the input's contained public key. Retained as-is.
From section 11. Calculations . . .
* Honest nodes do not accept an invalid transaction as payment. Retained as-is.
* Honest nodes do not accept a block containing an invalid transaction. Retained as-is.
* An attack is possible in which the attacker changes one of his own transactions to take back the money he recently spent. Changed - to be explained.
* In order for the double spend attack to work, the attacker must control a majority of the full node connections, i.e. the 51% attack. Changed - to be explained.
From section 12. Conclusions . . .
* Nodes work all at once with little coordination. Changed - to be explained.
* Nodes do not need to be identified, since messages are not routed to any particular place and only need to be delivered on a best-effort basis. Changed - to be explained.
* Generating full Nodes vote with their hashing power expressing their acceptance of valid blocks by working on them at will, and rejecting invalid blocks by refusing to work on them. Changed - to be explained.
* Any needed rules and incentives can be enforced with this consensus mechanism. Retained as-is.
From the released Bitcoin Core program, as described by Wiki: Controlled supply . . .
* The rate of block creation is approximately constant over time: 6 per hour. Retained as-is.
* The number of Bitcoins generated per block is set to decrease geometrically, with a 50% reduction every 4 years. Retained as-is.
* the number of Bitcoins in existence will never exceed 21 million. Retained as-is.
From Satoshi's comment in Bitcoin 0.3.2 released
* There are checkpoints to prevent very probably needless verification of the oldest portions of the blockchain. Changed - to be explained.
Bitcoin core developers speak of the Satoshi Social Contract as those features of Bitcoin that have been promised by Satoshi, and upon which the integrity of Bitcoin rests. For example, releasing a new version of the Bitcoin Core client that increases the upper limit of mined coins breaks the social contract between the core developers and bitcoin using public.
In this project, proof-of-work will be replaced by proof-of-stake, and a pure decentralized peer-to-peer asynchronous mesh network will be replaced by a hierarchical peer-to-peer synchronous network.
To what degree of severity, does this project break Satoshi's promises, and can the result be called Bitcoin despite claimed advantages?
---------------------------------------------------------------------------------------
Here are the notable promises extracted from the defining whitepaper Bitcoin: A Peer-to-Peer Electronic Cash System by Satoshi Nakamoto.
From the Abstract . . .
* Bitcoin is a purely peer-to-peer version of electronic cash that allows online payments to be sent directly from one party to another without going through a financial institution. Retained as-is.
* The Bitcoin network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The data structure is retained with a zero-difficulty proof-of-work.
* Bitcoin messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone. Bitcoin messages are routed along fault-tolerant paths from the originating peer to a certain peer having the role of temporary mint, which echos each received transaction back to the network as instant acknowledgment that it will be included according to order received in the ongoing record chain.
From section 1. Introduction . . .
* Bitcoin is an electronic payment system based upon cryptographic proof instead of trust, allowing any two willing parties to transact directly with each other without the need for a trusted third party.Retained as-is.
* Transactions that are computationally impractical to reverse would protect sellers from fraud, and routine escrow mechanisms protect buyers. Mechanism changed - to be explained.
* Bitcoin is a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions. Retained as-is.
* The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes. Mechanism changed - to be explained.
From section 2. Transactions . . .
* Bitcoin defines an electronic coin as a chain of digital signatures. A payee can verify the signature of a received transaction by computing the transaction payer's digital signature and the payer's public key. Retained as-is.
* [Because the private key is required by the payer to sign the transaction, if the private key is lost, then the transaction cannot be performed.] Retained as-is.
* Bitcoin transactions are publicly announced. Retained as-is.
* In the event of multiple transactions from the same address, the earliest issued transactions counts, and subsequent others are dropped. Retained as-is.
* Bitcoin is a system whereby the participants agree on a single history of the order in which transactions were received. Retained as-is.
* The payee has proof that at the time of each transaction, the majority of nodes agreed it was the first received. Retained as-is.
From section 3. Timestamp Server . . .
* Transaction are gathered into blocks. Retained as-is.
* The blockchain consists of timestamped blocks whose embedded hash includes the hash of the previous timestamped block, forming a chain. Retained as-is.
From section 4. Proof-of-Work . . .
* The block contains a SHA-256 hash having a certain number of leading binary zeros, determined by increment a number-used-once until a value is found that gives the block's hash the required zero bits. Retained as-is for backwards compatibility, but the zero-difficulty means the effort is trivial.
* Proof-of-work difficulty is determined by a moving average targeting an average number blocks per hour. Changed - the difficulty is always one, which is the lowest value.
From section 5. Network . . . Changed - to be explained.
* The steps to run the network are as follows:
- New transactions are broadcast to all nodes.
- Each node collects new transactions into a block.
- Each node works on finding a proof-of-work [with specified difficulty] for its block
- When a node finds a proof, it broadcasts the block to all nodes.
- Nodes accept the block only if all transactions in are valid and not already spent.
- Nodes express their acceptance of the block by working on creating the next block in the chain using hash of the accepted block as the previous hash.
* Nodes always consider the longest chain to be the correct one.
* Nodes receiving two different version of the next block, work on the first version received, but abandon that branch if a longer chain is received from any peer node.
* Transactions reaching many nodes have a high probability of being included in a block.
* Nodes missing a broadcast block may subsequently know to ask for it by number when the next block is received the gap recognized.
From section 6. Incentive . . .
* The first transaction in a block is a special transaction that starts a new coin owned by the creator of the block. Retained as-is.
* The new coin awarded to the block creator is the only way to initially distribute coins into circulation. Retained as-is.
* The transaction fee is equal to the transaction's input value minus its output value and is added to the block reward received by the block creator. Retained as-is.
* The incentive may help encourage nodes to stay honest. Retained as-is.
From section 7. Reclaiming Disk Space . . .
* Transactions are stored within the block in the configuration of a Merkle Tree, with only the root included in the block's hash. Retained as-is.
* Once the latest transactions in a coin is buried under enough blocks, the spent transactions before it can be discarded to save disk space. Retained as-is.
From section 8. Simplified Payment Verification . . .
* It is possible to verify payments without running a full node. Retained as-is.
* Verification is performed by querying network full nodes until the SPV node probably has the longest chain of block headers. The transaction timestamp indicates which chronologically ordered block must contain the transaction. The SPV node requests that block's Merkle branch and determines the presence of the transaction to be verified. Retained as-is.
* The number of following blocks is a measure of confidence that the chain will not be reverted back to before the transaction was accepted into its block. Changed - to be explained.
* A SPV node is more vulnerable to attack as it depends upon the honesty of its connected full nodes. Retained as-is.
From section 9. Combining and Splitting Value . . .
* To allow value to split and combined, transactions contain multiple inputs and outputs. Retained as-is.
* [The inputs must be unspent to create a valid transaction. When the transaction is accepted by the network, its inputs are regarded as spent, and its outputs are regarded as unspent in the absence of a subsequent transaction having that coin as an input.] Retained as-is.
* Despite the recursive chain of dependency on a transaction's inputs, there is never the need to extract a complete standalone copy of a transaction's history. Retained as-is.
From section 10. Privacy . . .
* Privacy can be maintained by keeping public keys anonymous. Retained as-is.
* New public / private key pairs may be used by the receiver of each transaction to keep them from being linked to common owner. Retained as-is.
* Multiple inputs to transactions indicate common ownership of the inputs due to the necessity of the owner signing each of them with private key corresponding to the input's contained public key. Retained as-is.
From section 11. Calculations . . .
* Honest nodes do not accept an invalid transaction as payment. Retained as-is.
* Honest nodes do not accept a block containing an invalid transaction. Retained as-is.
* An attack is possible in which the attacker changes one of his own transactions to take back the money he recently spent. Changed - to be explained.
* In order for the double spend attack to work, the attacker must control a majority of the full node connections, i.e. the 51% attack. Changed - to be explained.
From section 12. Conclusions . . .
* Nodes work all at once with little coordination. Changed - to be explained.
* Nodes do not need to be identified, since messages are not routed to any particular place and only need to be delivered on a best-effort basis. Changed - to be explained.
* Generating full Nodes vote with their hashing power expressing their acceptance of valid blocks by working on them at will, and rejecting invalid blocks by refusing to work on them. Changed - to be explained.
* Any needed rules and incentives can be enforced with this consensus mechanism. Retained as-is.
From the released Bitcoin Core program, as described by Wiki: Controlled supply . . .
* The rate of block creation is approximately constant over time: 6 per hour. Retained as-is.
* The number of Bitcoins generated per block is set to decrease geometrically, with a 50% reduction every 4 years. Retained as-is.
* the number of Bitcoins in existence will never exceed 21 million. Retained as-is.
From Satoshi's comment in Bitcoin 0.3.2 released
* There are checkpoints to prevent very probably needless verification of the oldest portions of the blockchain. Changed - to be explained.
Transitional SHA-256 Mining Multipool
Thanks for the idea about hashing power.
This project will create, or otherwise facilitate, a transitional SHA-256 multipool which pays its participating SHA-256 ASIC hashers in bitcoins free from the taint of inputs dependent upon rewards created by ASIC miners after the fork.
At launch of this project, the Bitcoin Network will regrettably split to some degree as bitcoins mined by the new proof-of-stake version cannot be spent by proof-of-work clients and vice versa. A condition of the launch is that the number of full nodes in the proof-of-stake version greatly outnumber their counterparts in the proof-of-work version, in particular that the major bitcoin exchanges and online wallets support the proof-of-stake version. The ASIC miners who continue to operate their rigs can obtain new-version bitcoins by joining this new multipool, which in addition to mining proof-of-work version Bitcoin, will also mine altcoins sharing the SHA-256 algorithm.
What you're trying to do is similar to asking 100 mulit-millionaires to donate all their wealth to charity. it's physically possible, but economically impossible. this is the whole genius of the system. if 51% of the hashing power stays honest, the system works. the reason why people don't destroy the network out of self-interest, is that they can't profitable do so. to move to another algorithm would destroy the system. if you believe it's possible you shouldn't support Bitcoin in the first place - collusion would be possible to the detriment of all coin holders.
Thanks for the idea about hashing power.
This project will create, or otherwise facilitate, a transitional SHA-256 multipool which pays its participating SHA-256 ASIC hashers in bitcoins free from the taint of inputs dependent upon rewards created by ASIC miners after the fork.
At launch of this project, the Bitcoin Network will regrettably split to some degree as bitcoins mined by the new proof-of-stake version cannot be spent by proof-of-work clients and vice versa. A condition of the launch is that the number of full nodes in the proof-of-stake version greatly outnumber their counterparts in the proof-of-work version, in particular that the major bitcoin exchanges and online wallets support the proof-of-stake version. The ASIC miners who continue to operate their rigs can obtain new-version bitcoins by joining this new multipool, which in addition to mining proof-of-work version Bitcoin, will also mine altcoins sharing the SHA-256 algorithm.
I believe that these development should be explored. Bitcoin was born as a disruptive innovation, and now/soon it maybe time to consolidate the gains by making incremental improvements.
It is like the earliest automobile was an invention over buggy, but religious sticking to its parameters would seem funny from the perspective of us who use quite different vehicles these days. Similarly I can only lament the fact that any real progress in human transportation ended with jet engine, because of the selfsame religious sticking to certain concepts and stifling of competition of innovation.
I am of the opinion that PoS is inherently fiat, and inherently non-coin, unimplementable, unworkable and undesirable. But I am open to change my opinion if new facts surface. Unwillingness to change opinions with facts is a trait not fitting for a Bitcoin user.
It is like the earliest automobile was an invention over buggy, but religious sticking to its parameters would seem funny from the perspective of us who use quite different vehicles these days. Similarly I can only lament the fact that any real progress in human transportation ended with jet engine, because of the selfsame religious sticking to certain concepts and stifling of competition of innovation.
I am of the opinion that PoS is inherently fiat, and inherently non-coin, unimplementable, unworkable and undesirable. But I am open to change my opinion if new facts surface. Unwillingness to change opinions with facts is a trait not fitting for a Bitcoin user.
A controversy over the future of Bitcoin can only hurt its price and utility.
All further actions of this project must be non-confrontational to the maximum degree.
All further actions of this project must be non-confrontational to the maximum degree.
What you're trying to do is similar to asking 100 mulit-millionaires to donate all their wealth to charity. it's physically possible, but economically impossible. this is the whole genius of the system. if 51% of the hashing power stays honest, the system works. the reason why people don't destroy the network out of self-interest, is that they can't profitable do so. to move to another algorithm would destroy the system. if you believe it's possible you shouldn't support Bitcoin in the first place - collusion would be possible to the detriment of all coin holders.
POS is popular for now. Some days later , new feature will come out for most people.
If you are so interested in these kinds of things, you should study the problem first. You seem to overlook some basics of Bitcoin. The current stakeholders, i.e. ASIC owners, have no interest in giving up their money printing press. To make changes to Bitcoin you need the consensus of those who have mining power and developers ("community consensus"). That community consensus is very clear.
I am studying Satoshi's paper in order to extract the terms of the social contract. Then I will author a project whitepaper to describe Bitcoin Proof-of-Stake in an academic format suitable for review. What I have thought about so far assumes well-behaving and bug-free agents operating in an ideal network - abstracted from the real network used by Bitcoin today. The whitepaper must allow for misbehaving and buggy agents operating in a possibly broken network. The new system must be shown to work without any trusted agents. The more convincing math that is in the paper - the better. The developer consensus can be moved by logic and math.
Bitcoin will never move to PoS.
The year 2016 is the last year for awarding 1,314,000 block reward bitcoins, then the block reward halves for the subsequent four years. I would tentatively set January 1, 2016 as the project launch date, because the reallocation of the block rewards is the enticement for switching transactors and holders over to the new version. I will revise a small portion of the Bitcoin Core C++ source code, and create a reference pool Java software program before the end of 2014, and then use all of 2015 for public testing in a sandboxed Bitcoin testnet. At least one altcoin, e.g. bytecoin, could be forked by others to test proof-of-stake in the wild in 2015.
A controversy over the future of Bitcoin can only hurt its price and utility.
All further actions of this project must be non-confrontational to the maximum degree.
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
didnt mastercoin promise that?
I agree - the market of Alt-Coins will be a kind of meta-consensus system. You vote with your wallet, which network you support. So side-chains, coin issuance within another network and migration are not needed. The market can price the different coins. What is missing is a more fluid exchange, so that payment in BTC and other coins are almost the same.
Seems that we have the same understanding of the situation.
In the end, the individual users of the currency have the final say, because if many of them decide to migrate, the previous currency network loses value and punishes those who still trust in it. Both PoW and PoS consensuses are helpless if people just abandon the currency en masse.
In the end, the individual users of the currency have the final say, because if many of them decide to migrate, the previous currency network loses value and punishes those who still trust in it. Both PoW and PoS consensuses are helpless if people just abandon the currency en masse.
Nope. A cool part of the crypto universe is that anyone can fork the coin (considering he has the majority of the shares/consensus AFTER the fork against hostile groups) to do whatever, and the markets decide if the fork has any value.
I don't believe miners and core developers would like to support such a change, but unless they have the majority of stake in the fork, they don't count. You can decide the parameters of the fork such that they actively suppress the position of devs and miners. Just like you would be designing an altcoin.
I don't believe miners and core developers would like to support such a change, but unless they have the majority of stake in the fork, they don't count. You can decide the parameters of the fork such that they actively suppress the position of devs and miners. Just like you would be designing an altcoin.
Yes, you can create a new coin, but this has nothing to do with the consensus in Bitcoin. The difference between a fork and a new chain is that all wealth gets wiped out. Bitcoins don't have value in a new chain. So what OP is talking about is just nonsense - he is explicitly referring to migrating Bitcoin. The people who hold the 5 billion dollars in wealth have no interest in destroying their wealth. The ASIC miners have no interest in moving to another system. The Bitcoin chain is secured by the hashing power. Which means the wealth can't be destroyed by random judgements of people. This economic calculation is the very reason why Bitcoin works in the first place. Essentially those nodes who would want to change the system would be malicious actors in the network. All of this is really required if you want to understand the system, because otherwise bitcoins would be worthless. The value of bitcoins crucially depends on the self-interest of miners and the tie to the hashing-power. Which is not to say there can be better systems. One might imagine a currency where users actually have a say in development, but Bitcoin is not such a system. Any new algorithm will be an Altcoin, not Bitcoin 2.0.
The miners are not the only stakeholders. What really matters is whether the users want to own the new coins or the old.
Nope. The consensus is very clearly defined. Users of coins have absolutely nothing to decide in this decision making process. If you want to understand how Bitcoin works I would suggest to study the whitepaper. If a switch to another algorithm would be possible, bitcoins would be worthless bits. The most important feature of the network is that some elements can't change, first and foremost the money supply and proof-of-work. You can ask some of the miners and core developers how likely such a switch is.
Nope. A cool part of the crypto universe is that anyone can fork the coin (considering he has the majority of the shares/consensus AFTER the fork against hostile groups) to do whatever, and the markets decide if the fork has any value.
I don't believe miners and core developers would like to support such a change, but unless they have the majority of stake in the fork, they don't count. You can decide the parameters of the fork such that they actively suppress the position of devs and miners. Just like you would be designing an altcoin.
The miners are not the only stakeholders. What really matters is whether the users want to own the new coins or the old.
Nope. The consensus is very clearly defined. Users of coins have absolutely nothing to decide in this decision making process. If you want to understand how Bitcoin works I would suggest to study the whitepaper. If a switch to another algorithm would be possible, bitcoins would be worthless bits. The most important feature of the network is that some elements can't change, first and foremost the money supply and proof-of-work. You can ask some of the miners and core developers how likely such a switch is.
What really matters is whether the users want to own the new coins or the old...It's also important that the new coin is a fork of the old, because basing it on a snapshot of Bitcoin's block-chain means the value of users' holdings in Bitcoin is preserved in the new coin.
Whether you create a fork or a spin-off, the end result is the same in this respect: in both cases you have bitcoin (PoW) and bitshares (PoS) running side by side. If you want bitshares to supersede bitcoin, then you need to legitimize it somehow and the market needs to agree.
We should also agree on the definition of a "fork" and a "spin-off". Here are my thoughts:
FORK:
====
A fork preserves the complete chain of digital signatures in the bitcoin blockchain back to the Satoshi genesis block with no missing details. Bitshares implemented as a fork would mean that new PoS blocks are built forking out from some pre-defined block #X and that client nodes would likely download all new bitshares blocks plus the entire bitcoin blockchain up to the forking point.
SPIN-OFF:
======
A spin-off preserves the wealth distribution (provable via ECDSA private keys) as specified by the unspent outputs in block #X but does not necessarily preserve the complete chain of digital signatures back to the Satoshi genesis block. Bitshares implemented as a spin-off would mean that new PoS blocks are built on top of some "nucleus" that represents a snapshot of the blockchain's unspent outputs at block #X. Client nodes would likely download only the bitshares blocks if the nucleus was hard-coded (the unspent outputs require vastly less disk space than the blockchain transaction history).
By this definition, this project is intended to be a fork, indeed what bitcoin core developers call a hard fork.
If this is done and working on a testnet i would be happy to fork bytecoin with your changes.
Deal. And thank you so much.
If this is done and working on a testnet i would be happy to fork bytecoin with your changes.
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
A core belief here is that PoS is simply better, and will carry the day on merit.
I'm not convinced of that necessarily. And I am not on board
with this delegation scheme for reasons I've stated.
Provided that distributed consensus can be achieved with PoS, and provided
that it has better defenses against a 51% attack than PoW does,
I would say it MIGHT be superior to PoW if introduced at the
right time, which I think would be premature right now for Bitcoin.
What really matters is whether the users want to own the new coins or the old...It's also important that the new coin is a fork of the old, because basing it on a snapshot of Bitcoin's block-chain means the value of users' holdings in Bitcoin is preserved in the new coin.
Whether you create a fork or a spin-off, the end result is the same in this respect: in both cases you have bitcoin (PoW) and bitshares (PoS) running side by side. If you want bitshares to supersede bitcoin, then you need to legitimize it somehow and the market needs to agree.
We should also agree on the definition of a "fork" and a "spin-off". Here are my thoughts:
FORK:
====
A fork preserves the complete chain of digital signatures in the bitcoin blockchain back to the Satoshi genesis block with no missing details. Bitshares implemented as a fork would mean that new PoS blocks are built forking out from some pre-defined block #X and that client nodes would likely download all new bitshares blocks plus the entire bitcoin blockchain up to the forking point.
SPIN-OFF:
======
A spin-off preserves the wealth distribution (provable via ECDSA private keys) as specified by the unspent outputs in block #X but does not necessarily preserve the complete chain of digital signatures back to the Satoshi genesis block. Bitshares implemented as a spin-off would mean that new PoS blocks are built on top of some "nucleus" that represents a snapshot of the blockchain's unspent outputs at block #X. Client nodes would likely download only the bitshares blocks if the nucleus was hard-coded (the unspent outputs require vastly less disk space than the blockchain transaction history).
Jump to: