AI Coin Development Diary

[SlipperySlope]

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:

• 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.

[1714057312]

1714057312

[1714057312]

1714057312

[SlipperySlope]

The Hard Fork

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?

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.

[SlipperySlope]

The Whitepaper Final Draft

Bitcoin Cooperative Proof-of-Stake

[SlipperySlope]

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.

[Vitalik Buterin]

One problem I have started to think about a lot about PoS in general is long-range attacks: what if you try to 51% attack a PoS blockchain straight from (or very close to) the genesis block?

To explain this, consider the following. First, suppose that 90% of all coin owners suddenly disappear. Will it be possible at all to generate any more blocks? Suppose yes. Then, an attacker with 10% stake will be able to fork the blockchain at some point 3 years ago, and then let it develop inside a virtual server. After generating a few million cost-free blocks, the attacker now publishes this new chain. How does a new node differentiate between the legitimate chain and the offending fork?

The second problem is long-range nothing-at-stake. Slasher fixes the short-range nothing-at-stake problem, but if a fork does start 50000 blocks ago, then there still is no incentive not to mine on both in parallel. Even with transactions-as-proof-of-stake, transaction senders have the incentive to send conflicting transactions into the other chain in order to double spend themselves. But maybe this issue will turn out to be not that important in practice.

[TwinWinNerD]

intresting. will take a close look

[hashman]

Very interesting paper!  Thank you for discussion here. 

Two comments:

"In contrast, incumbent credit/debit card payment systems are faster [3] and more certain for consumers. Incumbent bank wire transfer, e.g. Swiftnet [4], is faster and more certain for business-to-business users. Incumbent payment transfer systems have data security policies that Bitcoin lacks [5] with regard to protecting host computers and customer data, e.g. private keys."

I disagree with these statements.  Incumbent systems do have advantages but they are not necessarily faster or more certain (can be reversed up to months later).  As for security policies the incumbent systems are all way behind (pull system, no triple accounting, etc).

Second comment:

Why?  There is no reason to use proof of stake.  Saying that miners use too much energy is simply saying miners are not smart, not that there is a problem with proof of work.  Miners are free to use as much energy as they like.  Proof of stake looks to me like a solution in search of a problem.     

[SlipperySlope]

One problem I have started to think about a lot about PoS in general is long-range attacks: what if you try to 51% attack a PoS blockchain straight from (or very close to) the genesis block?

To explain this, consider the following. First, suppose that 90% of all coin owners suddenly disappear. Will it be possible at all to generate any more blocks? Suppose yes. Then, an attacker with 10% stake will be able to fork the blockchain at some point 3 years ago, and then let it develop inside a virtual server. After generating a few million cost-free blocks, the attacker now publishes this new chain. How does a new node differentiate between the legitimate chain and the offending fork?

The second problem is long-range nothing-at-stake. Slasher fixes the short-range nothing-at-stake problem, but if a fork does start 50000 blocks ago, then there still is no incentive not to mine on both in parallel. Even with transactions-as-proof-of-stake, transaction senders have the incentive to send conflicting transactions into the other chain in order to double spend themselves. But maybe this issue will turn out to be not that important in practice.

Yes this is a problem that this design does not handle directly. Rather I consider it the sort of catastrophe that is best dealt with by a network operations center. In the case of current Bitcoin, the lead core developers can issue an alert, and mobilize the community to download a new software version. In constrast, enterprise data networks, especially the incumbent financial data networks have network operations centers that rehearse detection of, and recovery from such faults.

This design provides funding for such a center, run in a decentralized manner by autonomous trustless agents to the greatest possible extent.

[SlipperySlope]

Very interesting paper!  Thank you for discussion here. 
"In contrast, incumbent credit/debit card payment systems are faster [3] and more certain for consumers. Incumbent bank wire transfer, e.g. Swiftnet [4], is faster and more certain for business-to-business users. Incumbent payment transfer systems have data security policies that Bitcoin lacks [5] with regard to protecting host computers and customer data, e.g. private keys."

I disagree with these statements.  Incumbent systems do have advantages but they are not necessarily faster or more certain (can be reversed up to months later).  As for security policies the incumbent systems are all way behind (pull system, no triple accounting, etc).

When I say faster, I mean the typical customer check-out experience at point-of-sale. You verify the payment account at a terminal, swipe a card, and collect the receipt. When I say more certain, I mean to cover the odd case where a bitcoin transaction makes into a block after a certain delay, or the less likely, but worse case when the transaction never gets into a block. The bitcoin network forwards transactions on a best effort basis. There are no guarantees that the transaction will be recorded into the blockchain.

Why?  There is no reason to use proof of stake.  Saying that miners use too much energy is simply saying miners are not smart, not that there is a problem with proof of work.  Miners are free to use as much energy as they like.  Proof of stake looks to me like a solution in search of a problem.     

Proof-of-stake was immediately recognized as a very attractive idea when first proposed back in 2011. It is the main reason why PeerCoin has the 4th highest market cap. Satoshi admitted that his design would eventually force miners to congregate in locations with the least expensive power, as math shows that competing miners will use all the block reward to support their efforts.

[drawingthesun]

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

Why Java?

Almost all CryptoCoin's and their associated programs are written in either C, C++ or Python.

Java isn't really seen in a good light in the CryptoCoin community.

[SlipperySlope]

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

Why Java?

Almost all CryptoCoin's and their associated programs are written in either C, C++ or Python.

Java isn't really seen in a good light in the CryptoCoin community.

Sorry - that statement is no longer operative. I love Java but after a month of study I realize your point entirely. Everything related to bitcoin core will be C++. There will be no reference pool software, because there are no mining pools in the final design. I will use python to needed testing tools, beyond what has been already contributed to bitcoin at GitHub.

[andytoshi]

Hi SlipperySlope,


I see you've updated your whitepaper today (May 20), and I think also every day before that. I have a few comments, though I've got a lot of reading to do so I can't promise I'll follow up on them in a timely fashion.


1. You spend a bunch of the first part of your paper claiming that Bitcoin's proof-of-work system is wasteful and that hashing is "single-purpose". (This is a common meme on here and Reddit, I understand — in general, I'd advise you when learning about Bitcoin to not pick up ideas from this website unless they originate with somebody who is a known expert on Bitcoin.) I recently had a discussion with fenn on ##hplusroadmap about the "single-purpose" claim as well as the "zero-sum" game. Notice that there is no known way to achieve distributed consensus without proof-of-work, so these claims that the entropy production is unnecessary are extraordinary and require significant evidence.

2014-05-11 12:20:10     fenn    it's a zero sum game
2014-05-11 12:20:32     fenn    except for the value of the network of course
2014-05-11 12:20:55     fenn    network value is independent of number of hashes being performed
2014-05-11 12:21:36     kanzure do you know what the hashes are for?
2014-05-11 12:27:58     fenn    "Any block that is created by a malicious user that does not follow this rule (or any other rules) will be rejected by everyone else."
2014-05-11 12:29:18     fenn    "Each block memorializes what took place immediately before it was created."
2014-05-11 12:29:49     fenn    New blocks can't be submitted to the network without the correct answer - the process of "Mining" is essentially the process of competing to be the next to find the answer that "solves" the current block.
2014-05-11 12:30:24     fenn    each hash is a "guess" at the answer
2014-05-11 12:30:59     andytoshi       fenn: you are totally missing the forest for the trees
2014-05-11 12:31:11     andytoshi       like if you said aerobic respiration was a process for binding carbon to oxygen
2014-05-11 12:31:33     fenn    he said "do you know what the hashes are for" and i answered, what do you want
2014-05-11 12:31:40     andytoshi       and when asked what it's for, you started talking about valence electrons and how respiration gets you the right reconfiguration
2014-05-11 12:32:13     andytoshi       fenn: the hashes give a way to translate computational resources into something cryptographically verifiable
2014-05-11 12:32:21     andytoshi       that's what "proof of work" refers to
2014-05-11 12:32:35     fenn    it has nothing to do with computational resources
2014-05-11 12:32:48     andytoshi       it lets you /define/ the system mathematically so that it is hard to rewrite history
2014-05-11 12:33:08     andytoshi       fenn: the correct answer to kanzure's question was "no"
2014-05-11 12:33:24     fenn    it's just the ability to do this particular cryptographic algorithm, which happens to be implemented on something resembling a computer
2014-05-11 12:33:52     -->     drewbug1 (~Adium@c-71-207-76-172.hsd1.pa.comcast.net) has joined ##hplusroadmap
2014-05-11 12:35:21     fenn    you can take all the bitcoin asics in the world and the won't be able to add 2+2
2014-05-11 12:35:52     chris_99        heh
2014-05-11 12:36:14     <--     drewbug (~Adium@fsf/member/drewbug) has quit (Ping timeout: 240 seconds)
2014-05-11 12:36:30     andytoshi       yeah, and you can take all the aerobic biomass in the world and they won't be able to either
2014-05-11 12:36:54     andytoshi       and yet here we are huffing and puffing as we type frantically
2014-05-11 12:37:01     fenn    the difference is you say one is "computational resources" and the other isn't?
2014-05-11 12:38:09     andytoshi       ?? the difference is that respiration is used to provide useful energy to the organism while bitcoin hashing is used to translate a fact of physics to a fact of mathematics
2014-05-11 12:38:22     andytoshi       they are more alike than they are different at the level we are talking
2014-05-11 12:38:42     andytoshi       in both cases they are a mechanism for taking resources from the environment and translating them into a form that the system can use
2014-05-11 12:38:44     fenn    but cells are more general purpose than bitcoin asics
2014-05-11 12:39:06     fenn    even "specialized" cells can do a large number of things
2014-05-11 12:39:16     andytoshi       i'd like a citation that DNA is more expressive than bitcoin script..


You later suggest that checkpoints are an improvement on consensus. This is not true. Checkpoints have nothing to do with consensus. Nada. This has been beaten to death by myself and several others, and is another example of a bitcointroll meme infecting your thought. Above you say that proof-of-stake is the reason that Peercoin is so popular. But Peercoin has been centralized from the start, and has no plan for ever being decentralized. Of course a centralized consensus system is able to be more efficient than a trustless one.

You compare Bitcoin confirmation times to CC transaction approval times. This is nonsense. There is no amount of time after which CC transactions are really irreversible in the sense of Bitcoin, but even the amount of time to eliminate the trivial "call the CC company and dispute the charge" method of reversal is several months. So you should be comparing hours (for Bitcoin) to months (for CC companies). If all you care about is transaction "approval" this is limited only by the speed of the network, just like with CC's, except that the Bitcoin network is more distributed and anyone can verify transactions, so the uptime is better. Again, this has been beaten to death here.

You say that Primecoin is an example of a "useful PoW". But there is no known use for Cunningham chains, and Primecoin has an awful awful "proof" of work which fails pretty-much every point laid out in my ASIC FAQ.

You repeatedly describe the adversarial nature of the Bitcoin network as something Satoshi made up. But adversariality is a fact about the world and not something you can model away when designing a decentralized cryptosystem.


2. I haven't look into your tamper-resistant logs but I worry about how efficient these can be regarding both CPU time and bandwidth, since you have every transaction producing a bunch of these, in some cases from cell-phones or other transaction-producing devices. It looks like at every time you have a single mint who gets to decide what order transactions occur in and which ones are valid or invalid. It's not clear what happens if the node approves conflicting transactions (I guess he gets banned when the next block is produced, but then how do you decide which one was the "correct" one? This does not seem to achieve the "instantly confirmed transaction" scenario I think you are going for.)

Also, don't use Bitcoin addresses for authentication. They can be used to authenticate against "the owner of coins sent to this address" but pretty-much nothing else. Addresses are payment identifiers and confusing this purpose with that of signing keys is only going to cause user error.


3. As we discussed in Austin, this nomadic business makes historic consensus tricky. Suppose the superpeers wind up in being in Vancouver for the summer. After some time they move on to London, so I have an opportunity to buy all the old superpeers' hardware from them for cheap prices. I use them to rewrite some history sufficient that they now pass off to a system in Austin which I control. From there on I'm able to do the usual stake-grinding or whatever tricks to maintain possession of the entire superpeer network forever, just sending it to my hubs around the world. If I were andyfastow rather than andytoshi I'd even set up a bunch of shell corps to disguise that I was doing this.

The point is that if you want to prevent rewriting history, you need to trust everyone with an ability to manipulate history, forever, even long after their incentives to help the network have gone. You need to prevent old hardware from winding up in unsecured dumps, from being stolen, from being hacked, etc., etc. I'd wager most TPM chips out there will expose their keys to (at least one of) the Chinese or Americans.


4. When you talk about trusted computing, what is the actual trust model behind this? I assume you need an authenticated channel to the TPM to verify the machines' software, but when you are only talking to a node through a network it is unclear to me how you can trust that you're talking to a real TPM which is really installed in the system that you're communicating with.


Andrew

[SlipperySlope]

Thanks Andrew for your thoughtful comments. I will keep them in mind as I devise the system test plan, that in turn guides the code to be written.

I will attempt to orchestrate public test scenarios that include the bad things you describe, and show whether the system works or not. If the system works, then indeed proof-of-work will be shown to be a wasteful Bitcoin design. If the system handles various byzantine faults and misbehavior, then the algorithm's adopted from Nick Szabo and others I reference will manifestly demonstrate a solution to what up to now has not been solved in Bitcoin.

As the tests proceed next year, I hope first that the simple tests work, and second that you and others propose more difficult challenges.

[SlipperySlope]

Comments from the Bitcoin core developers mail list . . .

• Referring to the subsidy for miners as "wasting it on miners" isn't going to garner you much favor.

I subsequently removed the word "waste" from the paper and substituted "effort" where needed.

[drawingthesun]

Comments from the Bitcoin core developers mail list . . .

• Referring to the subsidy for miners as "wasting it on miners" isn't going to garner you much favor.

The transactions are moved across the world by the nodes, and then kept secure essentially by the miners.

So it's not wasted! But certainly half wasted!

Nodes are so important and if the transaction volume picks up, eventually the security of the network will be in few hands because only a few people will have the chain.

Even miners do not need the chain anymore. The chain keepers (nodes) have no incentives.

[digitalindustry]

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.

I don' think you are getting it, but this is possibly a political nativity, they are saying they will do the hard sell to other chumps to get them to take this road.

---

I have one question and its of an economic nature, here it is:

If i'm X with 1000 BTC now I have a "Stake" in Bitcoin, agreed?

To get this stake i had to either:

A: Mine it using PoW
 
or

B: Purchase it with fiat money or good or services (essentially packaged energy)
  
of course i might have realized a large profit up until this point (transfered energy) , but>

now to further my Stake, I need to expend more work in some way, (so let me give you an example.)

*lets exclude transfer for the now as its irrelevant to the conversation directly, but lets come back to it.

I might need to buy hardware to mine more PoW currency as per the equilibrium of difficulty.

or

I can directly expend (packaged energy) fiat or goods and services to gain more "stake"


So in summary i can conclude that , Proof of stake is basically a shell game that gives and owner of the stake(energy) an increasing reward(energy) thus centralizing the network and breaking a bunch of fundamental laws of economics.

having said all of that , my question is simple - does more "stake" give more "votes" as per the "one cpu one vote" principal?



** i still believe that you could be able to implement this don't get me wrong, we know the human race is fundamentally docile, however where it will fail is in the execution, you should read over some of my theories on decentralized economics.

This system would fail for the same reasons the current banking system is failing and its centralized media outlets, basically the theory of decentralized multidimensional information flow and how that effects competition.

i will give them to you once i have refined them a little.

sorry for the rant the simple question again:


does more "stake" give more "votes" as per the "one cpu one vote" principal?

if your answer is yes,  that's a "double spend"  of  "packaged energy" think about it.

well when i say its a "double spend" it had to come from somewhere, so let me think on this, its transfered from the decentralized network. oh, of course its an implosion.

wow.

[digitalindustry]

a discerning reader could come back to me right now and say "but the equilibrium of difficulty is broken"

difficulty rises but the price has not, well, this comes down to a few aspects , some natural market and others relate to the flaws in the "one cpu one vote"; that; implementation outside of the white paper has proven.

the market is correcting that right now, but unfortunately some will be blinded by the "light" that is "Bitcoin" the brand and not the protocol.

CPoW or whatever you want to call it has gone some way too that , but there will no doubt be further improvements.

people come back and say "there will always be hardware specialization" , and I've always told people "software innovation can easily out-pace hardware specialization".

 

[digitalindustry]

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.

I don' think you are getting it, but this is possibly a political nativity, they are saying they will do the hard sell to other chumps to get them to take this road.

---

I have one question and its of an economic nature, here it is:

If i'm X with 1000 BTC now I have a "Stake" in Bitcoin, agreed?

To get this stake i had to either:

A: Mine it using PoW
 
or

B: Purchase it with fiat money or good or services (essentially packaged energy)
  
of course i might have realized a large profit up until this point (transfered energy) , but>

now to further my Stake, I need to expend more work in some way, (so let me give you an example.)

*lets exclude transfer for the now as its irrelevant to the conversation directly, but lets come back to it.

I might need to buy hardware to mine more PoW currency as per the equilibrium of difficulty.

or

I can directly expend (packaged energy) fiat or goods and services to gain more "stake"


So in summary i can conclude that , Proof of stake is basically a shell game that gives and owner of the stake(energy) an increasing reward(energy) thus centralizing the network and breaking a bunch of fundamental laws of economics.

having said all of that , my question is simple - does more "stake" give more "votes" as per the "one cpu one vote" principal?



** i still believe that you could be able to implement this don't get me wrong, we know the human race is fundamentally docile, however where it will fail is in the execution, you should read over some of my theories on decentralized economics.

This system would fail for the same reasons the current banking system is failing and its centralized media outlets, basically the theory of decentralized multidimensional information flow and how that effects competition.

i will give them to you once i have refined them a little.

sorry for the rant the simple question again:


does more "stake" give more "votes" as per the "one cpu one vote" principal?

if your answer is yes,  that's a "double spend"  of  "packaged energy" think about it.

well when i say its a "double spend" it had to come from somewhere, so let me think on this, its transfered from the decentralized network. oh, of course its an implosion.

wow.

ha ha thinking on this more is that why your tag is "SlipperySlope" ha  : D

[SlipperySlope]

does more "stake" give more "votes" as per the "one cpu one vote" principal?

if your answer is yes,  that's a "double spend"  of  "packaged energy" think about it.

well when i say its a "double spend" it had to come from somewhere, so let me think on this, its transfered from the decentralized network. oh, of course its an implosion.

wow.

The answer is Yes. But I do not follow your argument. A better response from me will have to await the availability of code to test.

[cryptomad]

Thanks for the info Good read