[ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread

[samperi649]

Counterparty requirements
1) 80 bytes of data
2) Counterparty transactions are relayed through the network as normal transactions

Do you think it is possible to reach an agreement from your side on how we can achieve these requirements? If so can you think how this could be possible?

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.

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.

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

No, not at all.

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

[baddw]

Wait for Zerocoin to boot BTC out.

You prefer an altcoin that requires centralised trust, over a decentralised Bitcoin?

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?

[porqupine]

Wait for Zerocoin to boot BTC out.

You prefer an altcoin that requires centralised trust, over a decentralised Bitcoin?

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?

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.

[Luke-Jr]

Wait for Zerocoin to boot BTC out.

You prefer an altcoin that requires centralised trust, over a decentralised Bitcoin?

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?

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.

[PhantomPhreak]

Counterparty requirements
1) 80 bytes of data
2) Counterparty transactions are relayed through the network as normal transactions

Do you think it is possible to reach an agreement from your side on how we can achieve these requirements? If so can you think how this could be possible?

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.

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

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".

The solution you proposed is hackish and political, and needlessly so.

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.

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.

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

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)?

[Luke-Jr]

Redesigning the protocol to make it better is one thing. Trying to shoehorn it into a completely arbitrary 40-byte space is not.

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).

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)?

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.

[PhantomPhreak]

Redesigning the protocol to make it better is one thing. Trying to shoehorn it into a completely arbitrary 40-byte space is not.

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).

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)?

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.

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.

[BitThink]

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.

[Luke-Jr]

Redesigning the protocol to make it better is one thing. Trying to shoehorn it into a completely arbitrary 40-byte space is not.

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).

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)?

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.

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.

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

[topynate]

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)?

40-byte OP_RETURN is potentially unavoidable for some things (no, I don't know any examples).

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?

[halfcab123]

I'm thinking collusion.

[PhantomPhreak]

Redesigning the protocol to make it better is one thing. Trying to shoehorn it into a completely arbitrary 40-byte space is not.

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).

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)?

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.

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.

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

I'm sorry, what's the problem with changing the limit in IsStandard() back to 80 bytes? I have yet to see any argument for why 40 is better than 80, and using the latter value would benefit everyone involved immediately.

[Luke-Jr]

I'm sorry, what's the problem with changing the limit in IsStandard() back to 80 bytes? I have yet to see any argument for why 40 is better than 80, and using the latter value would benefit everyone involved immediately.

For relay, probably no immediate problem.
For mining, it encourages spam.
For long-term, it's unnecessary.

Edit: Except that relaying transactions which will never be mined is currently exploitable. So either that would need to be fixed first, or the relay needs to be more intelligent and only relay Counterparty transactions the same way miners would mine them.

[led_lcd]

I'm sorry, what's the problem with changing the limit in IsStandard() back to 80 bytes? I have yet to see any argument for why 40 is better than 80, and using the latter value would benefit everyone involved immediately.

For relay, probably no immediate problem.
For mining, it encourages spam.
For long-term, it's unnecessary.

Edit: Except that relaying transactions which will never be mined is currently exploitable. So either that would need to be fixed first, or the relay needs to be more intelligent and only relay Counterparty transactions the same way miners would mine them.

If the issue is spam control, then wouldn't that be negated a variable fee based upon based upon the level of risk that spam may be contained within the transaction? Such a variable fee in this case is non-linear to the amount of 'risky' data attached. It would remove the arbitrary nature of 40 or 80 bytes.

It is difficult to predict what is necessary or unnecessary in the future. What if I wish to publish into the ledger the the daily fixings of the history of a 500 million dollar notional interest rate swap. Perhaps at that juncture in the future we would decide it was inappropriate to be stored in the blockchain. However, if it was appropriate I would certainly be willing to pay a larger premium to place it into the ledger.

[Luke-Jr]

I'm sorry, what's the problem with changing the limit in IsStandard() back to 80 bytes? I have yet to see any argument for why 40 is better than 80, and using the latter value would benefit everyone involved immediately.

For relay, probably no immediate problem.
For mining, it encourages spam.
For long-term, it's unnecessary.

Edit: Except that relaying transactions which will never be mined is currently exploitable. So either that would need to be fixed first, or the relay needs to be more intelligent and only relay Counterparty transactions the same way miners would mine them.

If the issue is spam control, then wouldn't that be negated a variable fee based upon based upon the level of risk that spam may be contained within the transaction? Such a variable fee in this case is non-linear to the amount of 'risky' data attached. It would remove the arbitrary nature of 40 or 80 bytes.

It is difficult to predict what is necessary or unnecessary in the future. What if I wish to publish into the ledger the the daily fixings of the history of a 500 million dollar notional interest rate swap. Perhaps at that juncture in the future we would decide it was inappropriate to be stored in the blockchain. However, if it was appropriate I would certainly be willing to pay a larger premium to place it into the ledger.

It's never appropriate to use the blockchain as storage.
Even if you pay a fee*, there will almost certainly still be some Bitcoin user who doesn't want to provide you with the storage.
If you want to pay people to store data for you, there's Amazon.
If you need to timestamp the data, merge mine a timestamping service.

* the fee to compensate for storage in the blockchain would far exceed Amazon's storage costs, btw

[PhantomPhreak]

I'm sorry, what's the problem with changing the limit in IsStandard() back to 80 bytes? I have yet to see any argument for why 40 is better than 80, and using the latter value would benefit everyone involved immediately.

For relay, probably no immediate problem.
For mining, it encourages spam.
For long-term, it's unnecessary.

Edit: Except that relaying transactions which will never be mined is currently exploitable. So either that would need to be fixed first, or the relay needs to be more intelligent and only relay Counterparty transactions the same way miners would mine them.

What kind of spam can fit in 80 bytes and not in 40 bytes? What kind of spam cannot be easily split across two separate transactions? This is a small thing that we're asking, and it would help a lot of people. It's not necessary for Bitcoin, but it's very useful for lots of applications like ours (which, again, are purely financial). Don't the benefits outweigh the rather small costs? I firmly believe that Counterparty is very good for Bitcoin in the long term; it as-it-were extends its functionality while being entirely backwards-compatible.

[TheMightyX]

I'm thinking collusion.

Let's not get into speculation here.

[led_lcd]

I'm sorry, what's the problem with changing the limit in IsStandard() back to 80 bytes? I have yet to see any argument for why 40 is better than 80, and using the latter value would benefit everyone involved immediately.

For relay, probably no immediate problem.
For mining, it encourages spam.
For long-term, it's unnecessary.

Edit: Except that relaying transactions which will never be mined is currently exploitable. So either that would need to be fixed first, or the relay needs to be more intelligent and only relay Counterparty transactions the same way miners would mine them.

If the issue is spam control, then wouldn't that be negated a variable fee based upon based upon the level of risk that spam may be contained within the transaction? Such a variable fee in this case is non-linear to the amount of 'risky' data attached. It would remove the arbitrary nature of 40 or 80 bytes.

It is difficult to predict what is necessary or unnecessary in the future. What if I wish to publish into the ledger the the daily fixings of the history of a 500 million dollar notional interest rate swap. Perhaps at that juncture in the future we would decide it was inappropriate to be stored in the blockchain. However, if it was appropriate I would certainly be willing to pay a larger premium to place it into the ledger.

It's never appropriate to use the blockchain as storage.
Even if you pay a fee*, there will almost certainly still be some Bitcoin user who doesn't want to provide you with the storage.
If you want to pay people to store data for you, there's Amazon.
If you need to timestamp the data, merge mine a timestamping service.

* the fee to compensate for storage in the blockchain would far exceed Amazon's storage costs, btw

I agree that the blockchain isn't for general storage. I think there are use cases where the data is a) relevant and tied to the utility of Bitcoin and b) financial transactions. The 'cost' of storing such information should be structured in a way which is prohibitive to spam, encourages efficient usage of the blockchain and isn't arbitrary.

[topynate]

Let's have some figures, shall we? Tarsnap charges 300 picodollars / byte-month. Assume ten thousand full nodes with their own blockchain, that's 3 microdollars / byte-month, or 3*12*80 microdollars / year = 0.3 cents / year for 80 bytes. But of course the cost of storage falls exponentially, let's say a three year halving time; then the total lifetime cost for storing your 80 byte OP_RETURN on every full node in the Bitcoin network is given by the sum of a geometric series with first term 0.3 cents and common ratio 2^(-1/3).

That's a total cost of 1.5 cents. At current prices, and with the above generous assumptions made on behalf of miners and other full node operators, the correct maximum additional charge for a filled 80 byte OP_RETURN is 0.025 mBTC (it can be argued that the additional demand for Bitcoin created by permitting new uses is a driver of increased Bitcoin prices and thus should lead to a discount, but that's harder to quantify). So just set that as the default until floating mining fees are introduced in (hopefully) 0.10. Bitcoin users who don't want to "provide" that storage can go ahead and not run a full node.

The idea Luke-Jr raises occasionally of a social contract existing between Bitcoin node operators to store and process only financial transactions needs dealing with. Bear in mind that in his maximalist interpretation, absolute consensus between all node operators is morally required to change that contract. It falls through on several grounds, principally vagueness and lack of historical support. Vagueness we've seen in this thread: no-one is quite clear on what makes a transaction financial. Is a transaction transferring a currency other than Bitcoin part of the social contract? Is a transaction containing what is effectively routing data (c.f. stealth addresses) fully financial, or is the additional stuff an anonymity functionality not part of the social contract? And so on. As to historical support, allow me to quote from someone who would know:

The network is robust in its unstructured simplicity. Nodes work all at once with little coordination. They do not need to be identified, since messages are not routed to any particular place and only need to be delivered on a best effort basis. Nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone. They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism.

The thing is, Luke, that like it or not, Satoshi is/was a libertarian, and his creation embodied the 'take it or leave it' aspect of that political philosophy. Consensus means a consensus of mining power. Coordination means passing around proofs of work. If you feel that the amount of storage space the blockchain needs is too onerous to justify running your huge mining network, then by all means take your ball and go home, or for that matter start playing a different game - you have every right to reject whatever blocks you wish. Bitcoin will be just as pure as the majority of mining power wishes it to be.

[sparta_cuss]

...
...
...As to historical support, allow me to quote from someone who would know:

The network is robust in its unstructured simplicity. Nodes work all at once with little coordination. They do not need to be identified, since messages are not routed to any particular place and only need to be delivered on a best effort basis. Nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone. They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism.

The thing is, Luke, that like it or not, Satoshi is/was a libertarian, and his creation embodied the 'take it or leave it' aspect of that political philosophy. Consensus means a consensus of mining power. Coordination means passing around proofs of work. If you feel that the amount of storage space the blockchain needs is too onerous to justify running your huge mining network, then by all means take your ball and go home, or for that matter start playing a different game - you have every right to reject whatever blocks you wish. Bitcoin will be just as pure as the majority of mining power wishes it to be.

Damn, that's brilliant. Where you been, "Newbie" topynate?