Except that the offer doesn't have to be published on-chain until the trade occurs. You could simply publish the bid and the ask at the same time to get single-step (from the chain's perspective) trades, and use some external mechanism such as the p2p network or bitmessage to move orders. This is what Freimarkets does.

There are two problems with that.

First, the system adopted by Counterparty is hugely inefficient. It won't scale. That's why we're making all these complaints about node validation and SPV mode - because these are what lets bitcoin scale even to the level it is currently at. And Counterparty as implemented lacks this capability entirely - and in such a way that it cannot be retrofitted in later.

Second, Counterparty should be working as Bitcoin developers and using existing Bitcoin code and infrastructure. Writing this sort of consensus code is the same difficulty whether you are doing it as a fork or improvement to bitcoin, or doing it as soem sort of embedded/parasitic system. Really, it doesn't make a difference: you still have to deal with the same sorts of issues in either case. The analogy about code encapsulation is cute but doesn't apply: here there are gains to be made from symbiosis. By choosing to make a separate system Counterparty developers are hurting both Bitcoin and themselves.


I participated in those developer discussions, so let's get something clear: I was not, and I don't think any of the other developers were aware of Counterparty's intention to use OP_RETURN + 80 bytes. If so, there would have at least been better communication about the change. OP_RETURN should only ever be utilized in user transactions as a last resort, and even then as a temporary measure until some other infrastructure could be built, and certainly only for financial data relating to transaction processing. Examples would be 256-bit scalars or compressed public keys and a few bits of prefix data for stealth addresses. It was pointed out that under no circumstances would this exceed 40 bytes, so the rather arbitrarily chosen 80 byte limit was twice as big as it needed to be.

There is not and never has been an adversarial relationship between bitcoin developers and Counterparty developers. If we appear antagonistic, it is because we are being critical of the design of Counterparty, which is flawed and needlessly detrimental to Bitcoin.

Except... it's not built on bitcoin. That's exactly the gripe of myself, jtimon, and others I'm sure. Counterparty does not interoperate with bitcoin scripting. You cannot have bidirectional transactions between the two. Counterparty rules are not validated by bitcoin nodes. Lightweight clients can't rely on most-work as an indicator of validity. Counterparty is built separate from bitcoin. If I take a bible and start scribbling in the margins, do I get to go on a pulpit and claim a biblical foundation for my scribbled theories? No, it has no relevance.

Counterparty transactions are scribbled in the margins of validated bitcoin transactional data. So what? Bitcoin does gain from this. Counteryparty doesn't gain from this, any more than they would from a fully merged-mined datachain or any other equivalently powerful proof-of-publication sytem. And Counterparty could be doing much better by having miners which validate its transactional data.

Didn't know that quote was from you Peter. I would reserve the phrase "side-chain" for things that actually involve chains other than bitcoin at the very least. Anyway the complaint was that the quote had nothing to do with the concept of a side-chain jtimon was talking about.

LightedLamp, I don't think that person you are quoting understands what we mean by "side-chain." There would be no storing of hashes via OP_RETURN, and no referencing of external transactions. A side-chain is just another block chain, but one which allows transfer of value back and forth between itself and the bitcoin chain (and other chains too). So you can move coins onto the side-chain, do whatever fancy transactions you want (e.g. distributed markets), and then move back when you are done.

Why wouldn't I default every time it's in my favor?

@solex, I don't know if it's ever been articulated. That and the fact that the coins haven't moved was basically my gripe, not a specific jab at @nanobit (although, this is open-source software developed by volunteers: asking for time estimates is bad form).

ZeroNominal, I would argue that demurrage is more fair.i Maybe this is getting off-topic, but hey it's your thread. When you are using inflation, sticky prices mean that you end up favoring those close to the source of inflation, e.g. investment banks in the fiat economy, miners in the inflatacoin economy. Demurrage on the other hand is felt equally and instantaneously by everybody, pro-rata to their holdings.

Okay, if it's not too hard then please reduce this down to practice and show us a detailed design of how this would work.

But there aren't any meaningful stats you can extract out of the block chain. The fact that the block chain exposes who paid how much to whom is a bug, not a feature, and that source of data will be eliminated in the near future. The question will become: how do you control the nominal interest rate without any econometric data whatsoever?

There's a reason Freicoin's demurrage rate is flat: it's not out of laziness or ignorance. It's the best you can do! The only other real option is to track by means of a synthetic asset or prediction market, but that leaves the entire economy vulnerable to collusion and manipulation. But having a fixed demurrage rate doesn't make Freicoin broken - instead of the real nominal interest rate varying between 4-6%, it'll vary between -1% and 1%. This is an improvement. And, sadly, the best that can be done without sacrificing user privacy and/or decentralized control.

can someone kindly give a status update when we will havemoney distributed to developers to work on a free and fair and decentralized coin join?

Peter, I'm not sure what DHT and OP_RETURN have to do with side chains.

Cryddit, except that (1) collusion with a miner nullifies those assumptions, (2) when you have the ability to make bets (options) based on the interest rate you've monetized manipulating it, (3) technologies being worked on now like committed transactions and Zerocash encrypt the value amounts so you don't even know how much currency is moving.

We've been looking at this problem since 2010, and I'm confident to say there is no decentralized solution

ZeroNominal, have you seen Freicoin?

http://freico.in/

I'd like a unicorn too, please.

@atweiden: Bitcoin Core will never, ever compete resource-wise with Electrum. This is because an electrum client has no clue whatsoever about the state of the bitcoin blockchain and relies 100% on the servers it connects to. The server could be lying to you and you wouldn't know it.

That said, the UTXO hash-tree commitments if/when it makes it into Bitcoin Core will let you run a stripped down client like Electrum by connecting directly to any random peer exposing the UTXO query interface. It also makes it possible to express compact fraud proofs demonstrating that one particular node is lying to you, at least once that fraud has been detected by a full node. These all benefit you greatly, raising you to a security level beyond Electrum or Android Wallet. However it is not and never will be the same as fetching the entire block chain and validating it.

In the shortest summary possible, the goal of the UTXO commitment project is to raise the security of the cheapest clients to an acceptable minimum bar - they can work by peering directly to nodes on the bitcoin p2p network, and can understand an exchange fraud proofs, but has little more drain on resources (for them) than Electrum does today.

However yes, it does require substantially more work for full nodes, potentially pushing out more full node operators and making the entire situation worse. If ever it doesn't make it into Bitcoin Core, it will be for this reason and that concern. But that's not to say that I haven't thought about the issue. Unlike Thomas's tree used in Electrum, the one I'm advocating on the mailing list and writing an implementation for can be used for stateless mining and validation - requiring only 32 bytes of validator state to be kept by any full node by attaching the necessary proofs to the transactions themselves. This could pave the way to sharded validation and open-source bitcoin full-node appliances, for example. But exactly what the end-game is here is still unclear at this time.

@Fernandez. Yup. Bitcoin hangs by a thread. If you have a miner, point it at p2pool and do your own transaction selection. You'll make more money anyways (p2pool has a lower stale rate than any of the pools).

Every release since 0.7 has included performance improvements as a key feature, starting with the very important merging of Pieter Wuille's ultraprune branch. Remember that this time last year we were ridiculing Peter Todd's "keep bitcoin free" campaign to enshrine the 1MB block limit. Even Peter Todd has switched positions on that one, so I think I can generalize to say that we all see the need for bitcoin to scale to higher traffic levels, and identify many outstanding problems to be solved between here and there. But beyond that I don't feel comfortable commenting on the specific positions of individual developers other than myself.

What's wrong with charging a fee for data use is that it does absolutely nothing to solve the problem. Fees go to miners, not full nodes. You don't collect a single Satoshi for running a full node. And until that incentive problem is fixed (it's not clear it can be), scaling bitcoin up means centralization and degradation of the peer-to-peer network, to the point of becoming compromised or unusable.

Let me start with the good. There is a reason we (developer hat on) are generally up in arms about "abusive" data-on-blockchain proposals: it is because we see the potential of this tech! We know that issued assets and smart property contracts could grow to eclipse bitcoin traffic entirely. Some of us are even convinced this could happen quickly.

Why is this bad? Because despite bitcoin being in the process of going mainstream and getting all sorts of attention from everybody, everywhere, the number of full nodes is declining. As mentioned by others this is in large part due to the rise of SatoshiDice. Now I don't object to gambling services on bitcoin, nor do I know any other developers who do. What you do with your money is your business. The issue is that SD gave a trivial amount of satoshi's back to indicate a lost bet, which effectively was an uneconomical-to-spend data message similar in size to a class A Mastercoin transaction which Counterparty is sadly now adopting. That drain on the resources of the network from this extra data processing is causing people to turn off their full nodes and switch to SPV clients.

I don't want to cause undue fear and panic as with time and effort and education and innovation this situation is correctable. But if left to run its course this trend would mean the death of bitcoin. And parasitic[1] systems like mastercoin and counterparty make the situation worse. It's like adding bad weather, stormy seas, and sharks while we're treading water trying to find a solution.

Furthermore, it's simply not necessary. You can accomplish all of Counterparty's goals via off-chain solutions the same or similar security guarantees. There has been a lot of mis-information out there about this! That's why I pointed to the Freimarkets paper I co-authored with jtimon. It's not because I want to claim credit for the idea (it is as old as bitcoin), but to show there are worked out counter-proposals that could be implemented today.

We tried to make very clear from the beginning that OP_RETURN was never meant to be used. Enabling small data commitments is like cooperating with a mugger: losing your pride is preferable to losing your life. Likewise, if you insist on abusing the block chain than please at least don't do something so recklessly stupid and hurtful as a class A mastercoin transaction. Put a hash of the data in the block chain instead. OP_RETURN was only ever meant to contain a hash - 32 bytes.

But ultimately what you *should* be doing is running your own network and have a low-volume mechanism for transferring coins between the two. That helps bitcoin scale and gives you added capabilities like SPV support, pre-signed offers, and scripting extensions.

Our objection from the start has not been "we don't want to see this" but rather "we don't want to see it done in this particular way" because it externalizes costs and makes the situation worse than it already is.

[1] "Parasitic" has a well defined technical meaning and is not meant as a derogatory term here.

@Matt: Hi, it was good to meet you at CoinSummit!

Just the root hash and an opaque proof of computation that asserts the audit code ran on the full (hidden) data.

They don't have to! Verified computation allows you to reduce it down to a binary yes/no result without revealing the entire balance.