Topic: [StableCoin] Welcome and Introduce Yourself... (Read 8211 times)

but when the exchange rate goes too strong how do you bring it back down to a good level while maintaining difficulty up? you want max difficulty with a stable xrate too.

I understand that you have to take into account multiple factors to create stability. Thats why I wouldnt mess with the bitcoin model much and just add whats needed to implement xrate targeting if possible

im not proposing a peg im proposing a targeting regime

Solve by inspection problem that you can't peg the value of a crypto coin to fiat using algorithms.  It simply does not work.

As a simple proof by contradiction, consider the case where NOBODY wants the coin.  How are you going to provide a liquid market where people can exchange their coins for that "stable" value?  Answer: YOU CAN'T.  Not unless you are willing to back that algorithm with a huge bank account that supports the fiat peg (i.e. the silly DGC bank idea where speculators for god knows what reason - perhaps they love losing money - would ensure that anyone holding DGC is guaranteed the price will never go down)

but most peers wont support an incorrect input (multiple incorrect inputs at same time would be equivalent to a 51% attack), also one incorrect input doesnt undermine the system because the xrate for coin release could be the average of 90 days for example, plus there is a maximum velocity or inflation.

The problem with tracking difficulty is that if you release coins according to difficulty you create an imblanced system where your encouraging more and more miners to mine without sufficient overall adoption of currency. I think there needs to be a balance between mining and broader use of the currency by non miners.

is there a way of entering the data in a secure way? manually or in some other way?

why would it be an attack vector if entered manually?

The coins can be exchanged at any rate anyone chooses, all I propose is that when the currency is too strong (as observed from a currency exchange for example) you expand the coin supply to target stability in the exchange rate. Avoid deflation and deflation by targeting stability.

the observed market price is what miners place into the blockchain, its not replacing a market price its conveying it into the network

like say the x rate is 1.50, cant the miners just put that in the blockchain? its not in their interest to report incorrect numbers as it will undermine the currency system in which they ar invested in

cant the miners just input an exchange rate as observed from somewhere? its in the interest of miners to report an accurate exchange rate.

Could the coin supply be adjusted in a decentralised manner according to an exchange rate sourced from an exchange like mt gox? Of course the exchange itself would be a point of centralisation but the average of a few exchanges could be used to source an exchange rate.

Hi brenzi, welcome to the [StableCoin] topic. As you mentioned Ripple I wanted to link you to another thread where I was analyzing Ripple from a [StableCoin] perspective.
https://bitcointalksearch.org/topic/m.2026191

I'd appreciate to see a stablecoin developed that is as free from speculation as possible. There are many get-rich coins, but I'm not sure if they will ever settle to a stable or at least slowly changing value.

The most obvious way to achieve a stable coin would be to peg it to a fiat coin. This way users (people wanting to use it as a currency and buy real stuff or services) know what they get.
Even more stable could be a weighted pegging to a selection of different fiat coins.

Now to the 1million$ question. How to get fiat exchange rates in a decentralized way, free of manipulation?
The only convincing approach to me has been implemented by ripple.
Even if people are speculating with the value of XRP, the more interesting feature is the use of IOU. As I understand, XRP are not meant to be a currency or a commodity. They're just there as an intermediate means of transfer. Value doesn't need to be stored in XRP. I hope the server will go open source soon.

What makes me hesitate is the reliability of IOU's. As they are dept, not value, they're prone to default. A 1$ IOU is worth 1$ minus the risk of default. Probably we'll need to observe ripple for a little longer to see how things work out.

Apart from ripple, I'm following etlase's decrits proposal. And PPC seems to be an interesting alternative to bitcoin as a playground for speculation. Free of the latter's energy hunger.

Variable rates of demurrage is something we discussed at FRC  for economic reasons, but no technical implementation has been presented yet.  My only though is that older periods of demurrage can be merged such that an aggregate rates can be found and tracked.  Say two periods with rates X and Y can be calculated to have had a cumulative rate of Z.  Then calculations can be done on these larger chunks of time if they are entirely within the holding period of the coin, a bit like how we drive across country by first doing down small streets and then along highways and once again down our neighborhood streets, its a tree traversal which should be fast and accurate enough for even a long span of time.


No more then current time-stamp falsification by nodes should have as it would fundamentally be using the same source data as current difficulty.  If Ripple is based on node consensus it seems you have to control more then half of all nodes to control the blocks, and as I've heard you have minimum balances this means it is a quasi proof of Stake system.

You are correct, I blew it on that one. I had a nagging suspicion I was forgetting something.


Sounds reasonable, I think it can still be subject to some manipulation, but it's fairly vague and requires a lot of investment to save money with a depreciating currency.

Thing is that our demurrage takes a very small fraction and raises it to a power of block since the coin last moved.  This needs a consistent rate of demurrage to compute correctly.

But the correct solution just struck me, we just separate the demurrage 'block height' from the underlying blocks.  Demurrage block height would just be a logical field on the block and after 10 minutes of block finding the next block increments that value.  Changes in the block finding rate can just be accommodated by changing how many real blocks it takes before the logical block field increments (and if blocks are taking longer then 10 minutes we can increment by 2 or more to maintain the real time rate).  And that number can be decided by the current time-stamp and difficulty code, but difficulty just represents a ratio between block finding rates and our arbitrary targeted 'logical' blocks.

This is very useful for any kind of futures market based layer put into a ripple type chain because it will allow rules and structure to be built that will be time accurate over the long term.

I don't see needing much trust in the time stamp. Just adjust the demurrage rate infrequently in the same vein as difficulty. You can't legitimately speed it up, because nodes won't accept blocks from the future. You can't legitimately slow it down, because honest miners will put an honest time. The attack vector is no worse than someone with a 51% hashrate stalling the network, and it will perform much more accurately when the network is honest.


[ad for decrits]
PS - Stable currency needs a stable network. Some new details.
[/ad for decrits]

Well their are two senses of using time, the block time stamps are used in a narrow sense to adjust difficulty in a PoW chain.  In Ripple you can dispense with this entirely cause you just want blocks ASAP.  Now FRC puts an additional requirement on they system that BTC doesn't, FRC wants to know that block generation rates really ARE on target over the long term (as in years), BTC doesn't need this and in fact the network for BTC has consistently run fast by noticeable amounts.  A little fast isn't too bad for FRC but my fear is a kind of quasi-velocity spiral in which slow block rates effectively lower demurrage which slows velocity and that feeds back into slower block rates etc etc.  We feel the system needs to have constant demurrage or be counter-cyclical in which demurrage goes down in a boom (canceling it) and up in a slump (again canceling it), the current demurrage setup we have is pro-cyclical if we assume hash rates speed up when the economy is heating up.

The simple alternative may be to just record the time interval of each block and have the system apply demurrage rates for that real time value rather then the block height, but this is a lot messier and we would be putting a lot of trust in the time stamp.

Thanks Red. I actually came across Sweft before that, in another thread ( https://bitcointalk.org/index.php?topic=187800.40 )
At that point he did not like idea of the fork, so I am not sure exactly what he wants.

It wouldn't and Ripple doesn't have consistent "ledger" time either. Simply the fastest transaction confirmation time possible. Block time tends to be bounded by time to reach consensus.

HOWEVER, what this does do is help synchronize peer clocks. With "peers" meaning those who validate and reach consensus on ledgers. In a perfect world, each ledger would have a time stamp after the previous and before the next. Ripple can enforce this much more tightly than a PoW block chain. Since every consensus build peer agrees what time the previous ledger was created. One of those peers can't put forward the proposition that they created the NEXT ledger at a clock time before they validated the PREVIOUS ledger. Think of ledger (block) creation times in Ripple as "notarization" times for the transactions they commit.

Note that BitCoin (and likely FreiCoin) relies on the block timestamps as well. It uses that information to adjust the difficulty rate. To do this reliably, BitCoin must presume that more than (X%) of the block creating nodes are not colluding to falsify block times. Ripple requires 80% to reach consensus.

Seems like having more consistent block time stamps would be a good thing for a demurrage currency. Right?

Did you see the gateway demurrage idea on the Ripple wiki?
https://ripple.com/wiki/Gateway_demurrage

Red:  I don't see how reducing block time to zero allows us to get a consistent block time over the long haul.  It seems you would get a block rate that is dependent on network latency and network size/interconnectedness.  While that may be consistent over short periods of time, it is certainly changing over the course of years.  It seems we would be forced to rely on time-stamp alone to get a long term hold on time as block rate has nothing that's regulating it.  For a conventional coin ware block rate is only meaningful for PoW mining rates this is fine as were presumably throwing out PoW mining all together (elegant ain't it).  But for demurrage (as implemented in FRC) we do need that block rate to be something predictable in the long term so we can apply the right rate, likewise lots of our stabilizing mechanism will want to know time to do their job.

In any case I'm now interested in seeing what Ripple tech we can incorporate into FRC and will bring this up with our developers.