Validation of the protocol rules by miners, such that confirmations are a meaningful statement about the validity of transactions.

And then Freicoin eliminates the rent entirely. We have wandered very off topic however.

No, that is not a universally held view. Innovation can bring productivity gains which bring profit for the innovators without necessitating any rent collection. Personally I'm am of the opinion that rents are evil, and I've pretty much dedicated all of my bitcoin efforts towards destroying rent seeking industries.

There are alternative models out there which work much better.

In my mind, the only valid currencies are those which are distinct from each other in terms of their economic model, and which possess the most free, fair, and wide distribution of their class. For store of value currencies, that is Bitcoin. For demurrage / transactional currencies, the only contender so far is Freicoin. I honestly don't see any other actively developed currencies out there that are trying anything with a different economic model than these two.

Freicoin's 80% issuance through non-profits is a side issue I'd be happy to discuss with you in some other context as its very off topic for this thread.

2-way pegging means that value may be transferred at a pegged (fixed) rate in either direction. The "2-way" is in contrast to one-way pegging, which is for example how Counterparty was issued. Unlike proof-of-burn, 2-way pegging involves sending coins to a special form of output which identifies the destination chain and recipient on the other side. At this stage it is similar to proof-of-burn: you have provably made the currency unspendable to you, and in doing so you gain the right to claim an equal number of coins at the destination side chain.

What's new is the return peg: to move those side chain coins back onto bitcoin, you perform the same operation again. First you send the side-chain coins to a special output naming the bitcoin chain and yourself as recipient. On the bitcoin side you take one of those previous burn-like outputs which sent coins into the side chain, and present your proof of having "burnt" sidecoins in order to claim an equal number of real bitcoins.

This special form output is a script which is able to understand an embedded proof-of-spend from another chain, which validates the accounting rules (you need to spend X bitcoins to claim X sidecoins, and vice versa), and which makes sure that claimed coins go to the indicated recipient.


This sortof-is and sortof-isn't fixed exchange rates. If you are coming from an economic background you know the problems of fixed exchange rates, but those problems don't really apply here. The problem with a fixed exchange rate over national currencies is that the two are not in fact equivalent -- you have two issuers that are separately backing each currency. In the case of 2-way pegging however, the two currencies are equivalent. You only ever get sidecoins by making bitcoins inaccessible, and vice versa. It isn't about fixing exchange rates between two currencies, rather it is about using the same exact currency on two different networks: sidecoins are bitcoins, and bitcoins are sidecoins.


Regarding innovation, monetary reward from speculative asset issuance is a failed model. Any innovation that occurs could be cloned on a side chain using bitcoins, freicoins, or some other already issued coin as the native currency. In a free market there is absolutely no reason to prefer the non-pegged alternative.

Parasitic is a technical word that describes precisely what it is; those other terms do not. It is not meant to be derogatory.

To the second matter, depending on how the pegging is constructed there might be some automated mechanism by which it shuts off (e.g. if the hash rate falls below some proportional threshold of bitcoin's). In that case of course the market value would diverge. But so long as the pegging mechanism is in place, any significant deviation of market price would be equalized by market makers moving coin in our out of the side chain.

The side-chain currency is bitcoins. It's not meant to be detached from the original BTC reserve amount at all! Asking "how is the value of any unit of that currency going to increase?" is kinda silly. It's value goes up or down exactly as bitcoin does, as the two are instances of the same thing: a single, unified cross-chain currency. Indeed one of the primary points is to prevent this scammy every-alt-has-its-own-floating-currency nonsense.


We'll have to differ on this opinion. As I've stated multiple times in this thread, and to various counterparty and mastercoin people in person, there are significant advantages to doing asset issuance and distributed markets on a validated, merged-mined side chain. This is solving the same problem in a way that is better for the ecosystem. Although we're getting some press now, two-way pegging as a implementable idea has existed since at least December of last year, and distributed p2p markets over side chains was fleshed out in the Freimarkets paper six months prior to that. These ideas pre-date Counterparty and yes, they are frankly better than the unvalidated parasitic model. I will stop evangelizing, but I will be happy to answer specific questions.

Sorry, but no it's not immediately clear this 2-way pegging mechanism has any application to parasitic, unverified systems like Counterparty and Mastercoin. Certainly not without some changes to these systems. The pegging system itself depends on SPV mode of operation for public chains (which parasitic chains do not support), or the existence of auditor commitments for private accounting servers. Counterparty natively supports neither.

As I've advocated earlier, asset issuance and exchange transactions would be done on a merged mined side chain, with all the benefits that come from having the protocol rules validated by miners. One of those benefits is the ability to do pegging transactions with other chains.

@porqupine, first of all we're talking about 2-way pegs. Bitcoin and type-B bitcoins are for practical purposes the same asset because you can freely exchange between them. I was not and never was talking about one-way issued assets.

Regarding hash rate, your calculation doesn't make any sense. The side chain would be merged mined so there would be approximately zero cost. Those 0.05852852 BTC would be money left on the table by any miner who choses not to merge mine the side chain. So long as the fees are sufficient to cover the bandwidth costs of miner's full node, or demurrage or some other construction is used to enact a perpetual reward, one should expect very hash rate adoption.

There is no commercialization of bitcoin core development going on here. Adam and Austin are seeking to employ core developers as a way of supporting work on bitcoin core. There are some developers who are working with them as contractors or early employees. There are also some developers and community members who are working with them in an unpaid capacity because we see what they are doing as beneficial to the future of bitcoin. From my vantage point this is more along the lines of core developers influencing the direction of this company than the other way around.

Speaking personally, I highly value my independence as an open source developer and my involvement was conditional on that remaining the case. It is vitally important that there are some core developers who are free to work on aspects of bitcoin that are vital yet may not immediately affect the bottom line of their employers, just as it is important to have developers making decisions which are in the interests of users not industry. It is my understanding that Adam and Austin are working on a non-profit aspect of this endeavor as well, sortof like the Mozilla foundation, which would be strictly independent from the for-profit apparatus. I'm sure details of that will emerge in time.

There are no changes to bitcoin required for nearly all of what we are working to accomplish, although a few aspects would be greatly enhanced by some bitcoin core changes (e.g. support for the return peg). These changes will be proposed and reviewed like any other and not given any special treatment. Part of why you are starting to see some PR about this company is that we want to start the conversation now about the nature of these changes and the necessity for their adoption.

Regarding your third question, these public side-chains are 100% decentralized and uncontrolled by any single party. There is also a concept of "private accounting servers" which is a high-volume centrally managed transaction server that naturally would have operator fees involved. However the code for running and/or auditing either of these would be 100% free, fair, open-source, unrestricted and unencumbered. The day this stops being the case is the day I quit.


That's probably all I can say about the company itself. I'd be happy to entertain any questions about 2-way pegging, side-chains, in-chain user assets, distributed exchanges, and private accounting servers. (Some details of which I already posted to this thread previously).

I am one of the unnamed core developers working with Adam Back on this project. (Though as a part-time consultant - most of my time is still spent on self-directed projects paid for by community donations.)


They absolutely can. We just think that unless there is an economic difference from bitcoin and other existing p2p issued coins, there's absolutely no justification for doing so.


You realize that bitcoin has the same problem, once the subsidy drops to a negligible amount?

Transaction fees are one solution, or you can have the coins demurrage in the side chain allowing for a perpetual reward. (Demurrage with pegged currencies is possible, as the pegging mechanism provides friction). There are other mechanisms being considered as well.


Approximately the same incentives as Counterparty, which also forgoes the scummy currency issuance model.

The asset issuance and smart property contracts layer is free infrastructure that is difficult if not impossible to monetize directly, yes. But there are an infinitum of profitable services that can be built on such a layer.

You might find this helpful:

http://en.wikipedia.org/wiki/SHA-2

@e4xit, the probability of successfully performing an attack when you are less than 50% of the network hash rate decays exponentially with the number of confirmations.

And let me reiterate -- dropping the block interval has real measurable negative effects on bandwidth usage of mobile / lite clients. So yes, lets cripple the vast majority of users so you don't have to wait a few more minutes.

Decreasing the blockchain linearly increases the load on mobile clients which sync block headers. Off-chain solutions are required to get down to the ideal time of <1sec.

That is what I'm talking about. How do you know if your view of the network is being constrained? By comparing with the most recent prices on the chain. Of course this is defense in depth as you'd also be using network-attack resistant networks like a bitmessage over tor and a proof-of-publication side chain for distributing orders.


What does that matter? You've proved that the data on the chain is a hash, not arbitrary data. At this point I think we're talking past each other...

He can only "own" the market of his own block. There are a variety of filters that could be used to remove the "noise" of an attacker - signal analysis is a field in itself. For the purpose of explanation, I will give a simple unsophisticated filter: take the median of the last N blocks. That is to say, for each block determine what the average price is of the market you are interested in, and then take the median of those values over the last N blocks. The attacker or cartel of attackers needs >50% of the hashrate in order to reliably affect the median value. Observe that an "attacking" block is one whose inferred pricing deviates substantially from the actual order book known by other miners due to wash trades, and that difference would be observable.

You can also think of this as a machine learning problem: you use unsupervised learning to group blocks into labeled buckets representing the underlying order book, and then choose the bucket which represents the most work over the last N blocks. You then compare that price structure with the orders you are seeing in the order-publication medium (p2p network, bitmessage, whatever) and decide whether you are being cheated or not.

No, only the intermediate hash.

Pay attention to the bolded words.

As I said in the text you quoted, a filtered average over previous block solves this. Unless you are assuming the attacker has majority hashrate, in which case you're screwed anyway.


Yes, and that would be a decent basis for a proof of publication system for orders. You could even shard based on market pairing so that people only have to validate what they're interested in. But validation of of the trades themselves should be separate, to achieve better scaling properties.

Peter, I don't think that's fair or accurate. Anyone observing the chain gets proof of publication of matched orders, and a filtered average over the last N blocks gives you a relatively good idea of the current price in a secure way which you can compare with what you're seeing on the wire. Additionally, such a setup does not rule out the possibility of other proof-of-publication systems being used for distributing the orders. It simply recognizes that consensus over matched trades and consensus over open orders are logically distinct, and data from one need not clog up the other.