Topic: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread - page 368. (Read 1276826 times)

The answer is stealth addresses, which fit nicely in 40 bytes, are completely random by design (so are incompatible with semantic filtering) and add significant value to the network. I'd like to know why you are so engaged in this conversation, when you don't know about probably the most talked about use-case for the feature under discussion? In fact, why are you trying so hard to influence default relay policy, which has no direct effect on 'blockchain spam', when your aims would be better served by convincing other miners that you're right?

Then you give us no choice but to add better filters to keep out the abuse.

Personally, I think we can evaluate the possibility to compress our most transactions to 40 bytes now. If it is possible, it's better to do it now cause no real OP- RETURN has been used in main net yet and no need to worry about backward compatibility.

I agree that to force it to fit 40 bytes introduces a lot of unnecessary work, but anyway reducing the block chain size is beneficial to the bitcoin in the long term.

A tx = flag + asset id + amount + price + expire + fee ... I think it's doable to encode them in a space efficient way.

We're not going to regress from relaying our transactions through the main Bitcoin network to relaying them, through central points of failure, directly to some subset of mining pools that have specifically whitelisted us with a patch. We won't depend on any feature not supported by vanilla Bitcoin Core, even if it means storing the message data in unprunable, (or even unspendable!) outputs for the time being.

I'm not suggesting trying to shrink it to 40 bytes.
I'm suggesting keeping the current 80-byte OP_RETURN implementation in the short-term, and building an upgrade for the long-term using a side-chain (ideally collaborative with Freimarkets, since they seem to be doing the same thing).

40-byte OP_RETURN is potentially unavoidable for some things (no, I don't know any examples).
Once there is a patch that relays Counterparty transactions (and not spam), you're certainly free to open a merge request for mainline as well.
You might have better success, if the patch is also able to understand Counterparty protocol and not relay invalid Counterparty transactions.

Redesigning the protocol to make it better is one thing. Trying to shoehorn it into a completely arbitrary 40-byte space is not. 40 bytes is probably just too little for what we want to do anyway---for what we are already doing. In the short-term, CheckMultiSig works just fine for us. It's much easier, better, cleaner and safer to switch encoding mechanisms (which there are also a million of) than to shrink every message in the protocol in a backwards-incompatible fashion... (again) for no reason.

We're not talking about forcing anyone to do anything. We're talking about the default relay policy for Bitcoin Core. If it were a matter of forcing anyone to do anything, why would a 40-byte OP_RETURN OK and not an 80-byte OP_RETURN (again, the original, publicly-announced, merged-into-the-codebase plan)?

Nobody is forcing you to run the reference client.
Fork it. Please.

And no, the Counterparty writeup is not an "existing Bitcoin specification".
For that claim, the developers should collaborate with the existing Bitcoin development community to formally define a BIP.

Since OP_Return was reduced to 40 bytes right before the release of .9, Counterparty is currently using Multi-sig (which was supposed to be deprecated) which is undesirable for reasons aforementioned by Peter Todd. On the other hand I do not think I've seen anyone present a line of technical reasoning as to why OP_Return 40 is alright while OP_Return 80 is undesirable.

Decentralized Bitcoin, which requires getting the permission of ~15 powerful individuals in order to have transactions confirmed; transactions which fully comply with the existing Bitcoin specifications and implementations?

So what would happen to XCP if 40 bytes limit is imposed?

No, not at all.

Unfortunately, if Counterparty transactions were relayed only as nonstandard transactions, it creates a large nonfunctional issue where the time between Counterparty transactions would become unnecessarily large. Perhaps this would be negated if other miners were to agree to then but then we end up with a suboptimal solution been widely accepted.

I'd like to see a solution which meets the requirements we are asking and also gives the miners the choice if they were to include the transaction in the block.

So don't u mean if bitcoin core devs insist on 40 bytes, XCP will be gradually dead?

Expect to have to change the protocol at some point.
No offence intended (this is expected in ordinary development), but the current one is at best a "first draft".

If you mean the predefined relays, yes, it is a bit hackish. As is the current protocol generally.
But it will work in the short-term, while a better protocol for upgrading to can be designed.

Forcing others to provide services is not justified by the "need" for it.

We need at least 80 bytes because that's the limit the Counterparty protocol was designed around.

The solution you proposed is hackish and political, and needlessly so. We need a simple, robust and standard way of relaying our transactions through the normal and fully decentralised Bitcoin network. We need for our system to have as few points of failure as possible.

I would guess it's because you are using yet another alt to post scrap.

There's a lot of options for Zerocoin - most recently they've been talking about doing it as an alt-currency, however I was talking to their Ian Miers at the Financial Cryptography 2014 conference a few weeks ago about how Zerocoin could be implemented as an embedded consensus system within Bitcoin. The big advantage there is increasing security. Of course, there's the obvious resistance to 51% attacks that being embedded as opposed to independent provides. But a more subtle advantage is that Zerocoin does require a trusted setup phase. During that phase secret keys are generated, if the keys are not deleted they can be used in the future to produce fake proofs and thus create fake zerocoins. By making Zerocoin be an embedded consensus system, rather than an independent one, it becomes much easier for mutliple Zerocoin's to be setup, each initialized by different, independent, parties. The security of each version is the same - the security of the underlying Bitcoin blockchain - yet you get the advantage of being able to pick and choose who you trust to do the setup phase honestly. I guess we'll see what the team chooses to go with in the end, but in any case if they do not go with the embedded route I'd certainly consider forking the project and releasing a version under that model myself.

You deleted my posts because I keep telling the truth

It's possible. Whether it's practical, is another more complicated issue

This seems fair.

I don't think those requirements are reasonable.
Why does it matter how much data XCP can use, or how the transactions are relayed?
What should matter is that people can use it for A, B, and C goals.
The technical side is just a matter of implementation, not requirement.

I asked you on IRC last night to please clarify what exactly you consider to be a "slanderous lie":


You did not respond. Please do so here we can understand what exactly is your side of the story with regard to Coiledcoin being 51% attacked.