Author Topic: Vitalik on stable currencies and POS  (Read 28374 times)

0 Members and 1 Guest are viewing this topic.

Offline Rune

  • Hero Member
  • *****
  • Posts: 1120
    • View Profile
If the block producers of all bitshares sidechains are paid in BTS and voted in with BTS on the primary bitshares blockchain

So, there are fragility risks that you have to keep in mind here. Particularly, if you allow anyone to apply to specifically become a delegate of any blockchain, then an attacker can take over 80 delegates on sidechain #173, then repeatedly move BTS from that sidechain to other sidechains and double-spend themselves, all before getting voted out.

Additionally, there's the issue that after the fact the only way to tell which history actually came first after the fact is by looking at centralized providers (blockchain.info, etc), so you're actually implicitly moving back to a fully subjective Ripple consensus model. Of course, your ideology may be that Ripple-level subjectivity (which is much greater than traditional PoS weak subjectivity) is fine, but you should be aware of this.

Now, if you require people to apply only to be a delegate generally, and then randomly assign delegates to sidechains, and add cross-channels between individual sidechains so that cross-sidechain transactions don't need to all go through the master chain, then you've actually basically reinvented https://blog.ethereum.org/2014/10/21/scalability-part-2-hypercubes/

My side change approach has exactly 101 delegates that handle ALL chains.   You only have one set of trusted individuals that come to a common consensus.  The only purpose of side chains is to allow parallel processing of transactions which cannot possible invalidate each other.

Right so I dislike that because it requires there to be 101 nodes that process all transactions, and that leads to rather high levels of centralization and eventually croaks if the blockchain architecture gets popular enough that you simply can't do everything that people want to do on a single server or data center. Also note that if a new delegate gets elected, downloading the database is going to take them a long time. That's why I strongly prefer, as Dominic Williams puts it, "scaling out, not up".

It wouldn't all have to run on one machine.  The technology can scale.   The time to sync-up is a "ONE TIME COST".   Users don't ever have to download the full chain.

My concern with this is that it means that even if it can scale architecturally, you're exposing yourself to a lot of political centralization. Particularly, I predict that if delegates get anywhere near as large as you are suggesting, you'll see the equivalent of "delegate pools": 3-5 large entities that actually maintain and update the state, and then individual delegates that simply point to those entities and that are there basically only as a way of voting on who the revenue should go to. It's possible to set up such a delegate pool that is anonymous to connect to, so delegates would have the incentive to secretly repoint themselves to that pool as they can easily avoid being caught. And if you manage to stop this from happening, then you're creating a large barrier to entry to the delegate industry, to the point where they're not much more decentralized than modern corporations.

Unlike with PoW, stakeholders can actually prevent pools from forming. One of the clearest trends you'll see at the moment is that everyone are very careful with supporting only delegates that are clearly individual people and hosting their delegates seperately (with riverhead I think being the only exception). There will always be more than enough money ready to compensate a delegate whatever amount they need to cover their hosting costs and then some. It's not supposed to become an industry like mining, it's more like the top nodes in a big web of trust. You only ever need to replace delegates if they lose their reputation in the web of trust (which for instance could be by doing something stupid that centralises the network).

Offline vbuterin

  • Jr. Member
  • **
  • Posts: 32
    • View Profile
If the block producers of all bitshares sidechains are paid in BTS and voted in with BTS on the primary bitshares blockchain

So, there are fragility risks that you have to keep in mind here. Particularly, if you allow anyone to apply to specifically become a delegate of any blockchain, then an attacker can take over 80 delegates on sidechain #173, then repeatedly move BTS from that sidechain to other sidechains and double-spend themselves, all before getting voted out.

Additionally, there's the issue that after the fact the only way to tell which history actually came first after the fact is by looking at centralized providers (blockchain.info, etc), so you're actually implicitly moving back to a fully subjective Ripple consensus model. Of course, your ideology may be that Ripple-level subjectivity (which is much greater than traditional PoS weak subjectivity) is fine, but you should be aware of this.

Now, if you require people to apply only to be a delegate generally, and then randomly assign delegates to sidechains, and add cross-channels between individual sidechains so that cross-sidechain transactions don't need to all go through the master chain, then you've actually basically reinvented https://blog.ethereum.org/2014/10/21/scalability-part-2-hypercubes/

My side change approach has exactly 101 delegates that handle ALL chains.   You only have one set of trusted individuals that come to a common consensus.  The only purpose of side chains is to allow parallel processing of transactions which cannot possible invalidate each other.

Right so I dislike that because it requires there to be 101 nodes that process all transactions, and that leads to rather high levels of centralization and eventually croaks if the blockchain architecture gets popular enough that you simply can't do everything that people want to do on a single server or data center. Also note that if a new delegate gets elected, downloading the database is going to take them a long time. That's why I strongly prefer, as Dominic Williams puts it, "scaling out, not up".

It wouldn't all have to run on one machine.  The technology can scale.   The time to sync-up is a "ONE TIME COST".   Users don't ever have to download the full chain.

My concern with this is that it means that even if it can scale architecturally, you're exposing yourself to a lot of political centralization. Particularly, I predict that if delegates get anywhere near as large as you are suggesting, you'll see the equivalent of "delegate pools": 3-5 large entities that actually maintain and update the state, and then individual delegates that simply point to those entities and that are there basically only as a way of voting on who the revenue should go to. It's possible to set up such a delegate pool that is anonymous to connect to, so delegates would have the incentive to secretly repoint themselves to that pool as they can easily avoid being caught. And if you manage to stop this from happening, then you're creating a large barrier to entry to the delegate industry, to the point where they're not much more decentralized than modern corporations.

Offline bytemaster

If the block producers of all bitshares sidechains are paid in BTS and voted in with BTS on the primary bitshares blockchain

So, there are fragility risks that you have to keep in mind here. Particularly, if you allow anyone to apply to specifically become a delegate of any blockchain, then an attacker can take over 80 delegates on sidechain #173, then repeatedly move BTS from that sidechain to other sidechains and double-spend themselves, all before getting voted out.

Additionally, there's the issue that after the fact the only way to tell which history actually came first after the fact is by looking at centralized providers (blockchain.info, etc), so you're actually implicitly moving back to a fully subjective Ripple consensus model. Of course, your ideology may be that Ripple-level subjectivity (which is much greater than traditional PoS weak subjectivity) is fine, but you should be aware of this.

Now, if you require people to apply only to be a delegate generally, and then randomly assign delegates to sidechains, and add cross-channels between individual sidechains so that cross-sidechain transactions don't need to all go through the master chain, then you've actually basically reinvented https://blog.ethereum.org/2014/10/21/scalability-part-2-hypercubes/

My side change approach has exactly 101 delegates that handle ALL chains.   You only have one set of trusted individuals that come to a common consensus.  The only purpose of side chains is to allow parallel processing of transactions which cannot possible invalidate each other.

Right so I dislike that because it requires there to be 101 nodes that process all transactions, and that leads to rather high levels of centralization and eventually croaks if the blockchain architecture gets popular enough that you simply can't do everything that people want to do on a single server or data center. Also note that if a new delegate gets elected, downloading the database is going to take them a long time. That's why I strongly prefer, as Dominic Williams puts it, "scaling out, not up".

It wouldn't all have to run on one machine.  The technology can scale.   The time to sync-up is a "ONE TIME COST".   Users don't ever have to download the full chain.   

For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline vbuterin

  • Jr. Member
  • **
  • Posts: 32
    • View Profile
If the block producers of all bitshares sidechains are paid in BTS and voted in with BTS on the primary bitshares blockchain

So, there are fragility risks that you have to keep in mind here. Particularly, if you allow anyone to apply to specifically become a delegate of any blockchain, then an attacker can take over 80 delegates on sidechain #173, then repeatedly move BTS from that sidechain to other sidechains and double-spend themselves, all before getting voted out.

Additionally, there's the issue that after the fact the only way to tell which history actually came first after the fact is by looking at centralized providers (blockchain.info, etc), so you're actually implicitly moving back to a fully subjective Ripple consensus model. Of course, your ideology may be that Ripple-level subjectivity (which is much greater than traditional PoS weak subjectivity) is fine, but you should be aware of this.

Now, if you require people to apply only to be a delegate generally, and then randomly assign delegates to sidechains, and add cross-channels between individual sidechains so that cross-sidechain transactions don't need to all go through the master chain, then you've actually basically reinvented https://blog.ethereum.org/2014/10/21/scalability-part-2-hypercubes/

My side change approach has exactly 101 delegates that handle ALL chains.   You only have one set of trusted individuals that come to a common consensus.  The only purpose of side chains is to allow parallel processing of transactions which cannot possible invalidate each other.

Right so I dislike that because it requires there to be 101 nodes that process all transactions, and that leads to rather high levels of centralization and eventually croaks if the blockchain architecture gets popular enough that you simply can't do everything that people want to do on a single server or data center. Also note that if a new delegate gets elected, downloading the database is going to take them a long time. That's why I strongly prefer, as Dominic Williams puts it, "scaling out, not up".

Offline bytemaster

If the block producers of all bitshares sidechains are paid in BTS and voted in with BTS on the primary bitshares blockchain

So, there are fragility risks that you have to keep in mind here. Particularly, if you allow anyone to apply to specifically become a delegate of any blockchain, then an attacker can take over 80 delegates on sidechain #173, then repeatedly move BTS from that sidechain to other sidechains and double-spend themselves, all before getting voted out.

Additionally, there's the issue that after the fact the only way to tell which history actually came first after the fact is by looking at centralized providers (blockchain.info, etc), so you're actually implicitly moving back to a fully subjective Ripple consensus model. Of course, your ideology may be that Ripple-level subjectivity (which is much greater than traditional PoS weak subjectivity) is fine, but you should be aware of this.

Now, if you require people to apply only to be a delegate generally, and then randomly assign delegates to sidechains, and add cross-channels between individual sidechains so that cross-sidechain transactions don't need to all go through the master chain, then you've actually basically reinvented https://blog.ethereum.org/2014/10/21/scalability-part-2-hypercubes/

My side change approach has exactly 101 delegates that handle ALL chains.   You only have one set of trusted individuals that come to a common consensus.  The only purpose of side chains is to allow parallel processing of transactions which cannot possible invalidate each other. 

For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline vbuterin

  • Jr. Member
  • **
  • Posts: 32
    • View Profile
If the block producers of all bitshares sidechains are paid in BTS and voted in with BTS on the primary bitshares blockchain

So, there are fragility risks that you have to keep in mind here. Particularly, if you allow anyone to apply to specifically become a delegate of any blockchain, then an attacker can take over 80 delegates on sidechain #173, then repeatedly move BTS from that sidechain to other sidechains and double-spend themselves, all before getting voted out.

Additionally, there's the issue that after the fact the only way to tell which history actually came first after the fact is by looking at centralized providers (blockchain.info, etc), so you're actually implicitly moving back to a fully subjective Ripple consensus model. Of course, your ideology may be that Ripple-level subjectivity (which is much greater than traditional PoS weak subjectivity) is fine, but you should be aware of this.

Now, if you require people to apply only to be a delegate generally, and then randomly assign delegates to sidechains, and add cross-channels between individual sidechains so that cross-sidechain transactions don't need to all go through the master chain, then you've actually basically reinvented https://blog.ethereum.org/2014/10/21/scalability-part-2-hypercubes/

Offline fluxer555

  • Hero Member
  • *****
  • Posts: 749
    • View Profile
I'd like to point out arhag's DPOS side-chain solution here, since it's lost in the deep 'Proposals' section of the 'BitShares' section...

https://bitsharestalk.org/index.php?topic=11349.0

Offline Rune

  • Hero Member
  • *****
  • Posts: 1120
    • View Profile
Quote
Name registries for one. Tracking ownership of smart property devices as well.

But these kind of things require a lot of trust in the system. The best way to evaluate trust in a blockchain will always be to look at its market cap. People wouldn't register their names or put their car on litecoin if they could the same thing on bitcoin.

I agree with your token vs blockchain premise. I guess the real question is, which token is used to designate and pay the salary of block producers? If the block producers of all bitshares sidechains are paid in BTS and voted in with BTS on the primary bitshares blockchain, then you can always trust all sidechains maintained by them as much as you can trust the primary blockchain (I think...).

Offline monsterer

You should read up on my research on endogenous estimators here: https://blog.ethereum.org/2014/11/11/search-stable-cryptocurrency/

It's actually quite a fun topic.

Thanks - I've just taken a glance at it.

I would like to see an analysis from the POV of the profit motivated market manipulator in systems such as seignorage shares (and indeed bitshares). Particularly, I'd like to see a thorough analysis of the way each system responds to manipulation attacks in the presence of an idealised attacker (one who knows the nuances of each system and is motivated by profit alone).
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline vbuterin

  • Jr. Member
  • **
  • Posts: 32
    • View Profile
Quote
Sidechains also solve higher fees. You can have more centralized and highly liquid sidechains with low fees, and highly decentralized chains with high fees. This can still all be done with the same basic token.

I think you're making the same type-theory error that just about every Bitcoin maximalist does: conflating blockchains and currencies. The questions of:

1. Should all crypto be done on one blockchain?
2. Should all crypto be done on one currency?

are completely separable. Sidechains are a way of using one currency but using multiple blockchains; hence if we go the BTS/ETH/whatever sidechain route then we are still going the multi-blockchain route, just not a multi-token route. Metacoins, and some versions of Ethereum contracts, are a way of using many currencies but still being on one blockchain.

Sidechains by themselves are not magically secure. If a sidechain as currently described is only used by a few people, then it will be easy to double-spend. The challenge of scalability is not how to split up the applications - that's easy - it's how to split things up while maintaining a high degree of security for each piece. Sidechains do nothing in advancing this frontier, because they are a currency innovation and not a blockchain innovation.

Quote
Why would someone run a non-financial service on a decentralized computer? Seems highly inefficient for everything that doesn't require absolute security and trust.

Name registries for one. Tracking ownership of smart property devices as well. If they become really cheap, we could even start talking about decentralized forums and the like. People already write such software in python, which is a >1000x efficiency hit over assembly, so it's not at all unreasonable that people will value decentralization enough to take a ~200x hit in efficiency for them, particularly since the blockchain only needs to store a small business-logic core.

Offline Rune

  • Hero Member
  • *****
  • Posts: 1120
    • View Profile
Quote
Now, our recent research has led us to conclude that scalable multichain/sharding mechanisms exist that allow all blockchains to share security to a high degree (at least for full clients; light client security is a bit more complicated) with a high degree of interop, so the only tradeoff that remains is between network effect and fees.

Sidechains also solve higher fees. You can have more centralized and highly liquid sidechains with low fees, and highly decentralized chains with high fees. This can still all be done with the same basic token.

Quote
(As another point, at ethereum we generally don't see blockchains as being financial tools exclusively; they're more like decentralized computers that people run services on, and those services probably use tokens in a lot of places but that should not necessarily be an assumption everywhere; hence, "liquidity" is only one kind of network effect, and IMO even one of the less important ones).

Why would someone run a non-financial service on a decentralized computer? Seems highly inefficient for everything that doesn't require absolute security and trust. Anyway, as I see it price is the single most important and reliable signal in a market, and will be what everything else follows. Bitcoin mindshare also peaked at the ATH. If a company decided to integrate their services onto a blockchain (risking their business and thus their money), they'll always be a lot more comfortable with a blockchain that they can easily see a lot of other people have been willing to risk their money with (indicated by high price and high liquidity).

Offline vbuterin

  • Jr. Member
  • **
  • Posts: 32
    • View Profile
So I went through "A Note on Cryptocurrency Stabilisation: Seigniorage Shares".   There is a place for these kinds of papers for sure, but there is so much irrelevant information in the paper that it is hard to get a summary of the basic approach.

You can find a summary of the basic approach here: https://blog.ethereum.org/2014/11/11/search-stable-cryptocurrency/

Quote
As far as I can tell the paper is close to worthless on useful ideas for stabilizing prices.  And has inspired a new blog topic on the "fallacy of price stability"

Be careful here. A lot of Austrian economists (eg. Mises back when I was reading Human Action) like to make the point that the very concept of price stability is somehow philosophically invalid, which is an absolutely absurd position; even if you cannot use pure logical theory to determine that there is one particular price benchmark that is "correct" and all others are wrong, it is very clear that you can intuitively say that product prices in general go up and down much more when measured in some currencies than in others. But that's not the point you were planning to try to make, looking forward to hearing it.

Offline bytemaster

Quote
(As another point, at ethereum we generally don't see blockchains as being financial tools exclusively; they're more like decentralized computers that people run services on, and those services probably use tokens in a lot of places but that should not necessarily be an assumption everywhere; hence, "liquidity" is only one kind of network effect, and IMO even one of the less important ones).

This is how I understand them too.   
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline vbuterin

  • Jr. Member
  • **
  • Posts: 32
    • View Profile
What is interesting to me is the idea of measuring hashing power in a POW scheme (or transaction fees in POS) and using that as an internal measure of the value of the coin, thereby allowing a coin to attain its own, self contained price stability. Looking into a post fiat world, this has the potential to be quite important.

Still, as BM points out both the above idea and with an infinite printing press driving the price stability system, market manipulation might be a big problem.

You should read up on my research on endogenous estimators here: https://blog.ethereum.org/2014/11/11/search-stable-cryptocurrency/

It's actually quite a fun topic.

Offline bytemaster

So I went through "A Note on Cryptocurrency Stabilisation: Seigniorage Shares".   There is a place for these kinds of papers for sure, but there is so much irrelevant information in the paper that it is hard to get a summary of the basic approach.

As far as I can tell the paper is close to worthless on useful ideas for stabilizing prices.  And has inspired a new blog topic on the "fallacy of price stability"
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.