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

I never said I didn't want the Bitcoin protocol to change.
On the contrary, I support extending it to do what Counterparty wants.
But such extensions are slow-moving right now, and take time to implement properly.
I also understand Counterparty wants a solution "today".
I agree the 80-byte OP_RETURN is a good short-term way to do this.
Deploying a whitelist to miners, to accept these Counterparty transactions can be done within a few weeks.
But deploying a default relay policy change requires months (releasing a new version of Bitcoin Core, and the slowest part: waiting for all the users to upgrade).
Thankfully, there is an immediately available workaround to not having the default relay policy "on your side":
Just have Counterparty participants relay their transactions to nodes running the updated relay policy.

So, recommended course of action:
Immediate-term:
1. Write Bitcoin Core patch to whitelist 80-byte OP_RETURN-based Counterparty transactions.
2. Deploy patch to major mining pools, and open merge request with mainline Bitcoin Core.
3. Begin using OP_RETURN Counterparty immediately; use addnode to get it relayed to miners.
Short-term:
4. After discussion, patch is merged to Bitcoin Core.
5. Bitcoin Core 0.10 is released with a default relay policy accepting Counterparty transactions, and addnode is no longer needed.
Long-term:
6. Counterparty developers discuss future plans with Freimarkets developers and others interested in this kind of functionality.
7. Interested developers figure out the best way to do everything, probably including using merged-mining, side-chains, and other things that are impractical today.
8. Interested developers implement new system, and write a BIP documenting it.
9. BIP gets reviewed.
10. Counterparty users upgrade to new version based on BIP.
11. Everyone gets a break.

Hopefully that clarifies my position.

+1.

I believe that this is (finally) very positive and reasonable. this is the attitude. the rest is in the details that can be reasonably solved. no need for hostile interactions from all parties.

I'd like to see the response from the CP team to this. progress no?
----------------
I believe that we ALL want the same thing: the advancement of the space through the real and positive paradigm shift that will ultimately benefit mankind (yes.... mankind, unbanked or banked alike...3rd world and 1st world alike).

...(snip)....
On the contrary, I support extending it to do what Counterparty wants.
But such extensions are slow-moving right now, and take time to implement properly.
I also understand Counterparty wants a solution "today".
I agree the 80-byte OP_RETURN is a good short-term way to do this.
...(snip)....
Hopefully that clarifies my position.

I never said I didn't want the Bitcoin protocol to change.
On the contrary, I support extending it to do what Counterparty wants.
But such extensions are slow-moving right now, and take time to implement properly.
I also understand Counterparty wants a solution "today".
I agree the 80-byte OP_RETURN is a good short-term way to do this.
Deploying a whitelist to miners, to accept these Counterparty transactions can be done within a few weeks.
But deploying a default relay policy change requires months (releasing a new version of Bitcoin Core, and the slowest part: waiting for all the users to upgrade).
Thankfully, there is an immediately available workaround to not having the default relay policy "on your side":
Just have Counterparty participants relay their transactions to nodes running the updated relay policy.

So, recommended course of action:
Immediate-term:
1. Write Bitcoin Core patch to whitelist 80-byte OP_RETURN-based Counterparty transactions.
2. Deploy patch to major mining pools, and open merge request with mainline Bitcoin Core.
3. Begin using OP_RETURN Counterparty immediately; use addnode to get it relayed to miners.
Short-term:
4. After discussion, patch is merged to Bitcoin Core.
5. Bitcoin Core 0.10 is released with a default relay policy accepting Counterparty transactions, and addnode is no longer needed.
Long-term:
6. Counterparty developers discuss future plans with Freimarkets developers and others interested in this kind of functionality.
7. Interested developers figure out the best way to do everything, probably including using merged-mining, side-chains, and other things that are impractical today.
8. Interested developers implement new system, and write a BIP documenting it.
9. BIP gets reviewed.
10. Counterparty users upgrade to new version based on BIP.
11. Everyone gets a break.

Hopefully that clarifies my position.

I never said I didn't want the Bitcoin protocol to change.
On the contrary, I support extending it to do what Counterparty wants.
But such extensions are slow-moving right now, and take time to implement properly.
I also understand Counterparty wants a solution "today".
I agree the 80-byte OP_RETURN is a good short-term way to do this.
Deploying a whitelist to miners, to accept these Counterparty transactions can be done within a few weeks.
But deploying a default relay policy change requires months (releasing a new version of Bitcoin Core, and the slowest part: waiting for all the users to upgrade).
Thankfully, there is an immediately available workaround to not having the default relay policy "on your side":
Just have Counterparty participants relay their transactions to nodes running the updated relay policy.

So, recommended course of action:
Immediate-term:
1. Write Bitcoin Core patch to whitelist 80-byte OP_RETURN-based Counterparty transactions.
2. Deploy patch to major mining pools, and open merge request with mainline Bitcoin Core.
3. Begin using OP_RETURN Counterparty immediately; use addnode to get it relayed to miners.
Short-term:
4. After discussion, patch is merged to Bitcoin Core.
5. Bitcoin Core 0.10 is released with a default relay policy accepting Counterparty transactions, and addnode is no longer needed.
Long-term:
6. Counterparty developers discuss future plans with Freimarkets developers and others interested in this kind of functionality.
7. Interested developers figure out the best way to do everything, probably including using merged-mining, side-chains, and other things that are impractical today.
8. Interested developers implement new system, and write a BIP documenting it.
9. BIP gets reviewed.
10. Counterparty users upgrade to new version based on BIP.
11. Everyone gets a break.

Hopefully that clarifies my position.

You don't want the bitcoin protocol to change to allow counterparty to operate in a more beneficial way, and then you say that it will change in the future. It will upgrade to allow that support in the future.

Bitcoin doesn't have Counterparty support. I'm asking them to use a temporary side-channel in addition to normal relaying-to-random-nodes until the Bitcoin network has upgraded to support Counterparty.

Jesus Christ, what a troll!

Take your goatee and go away please?

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.

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.

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

Bitcoin doesn't have Counterparty support. I'm asking them to use a temporary side-channel in addition to normal relaying-to-random-nodes until the Bitcoin network has upgraded to support Counterparty.

PhantomPhreak is saying that he will NOT do something that depends on enlisting a small subset of mining pools, precisely because he wants to be a team player and build only on "vanilla Bitcoin Core."

PhantomPhreak is one of the two listed, and has expressed that he is only willing to do things under certain Bitcoin-hostile terms.

You're asking them to do something that isn't trasmitted on the normal bitcoin infrastructure.  To this point the blockchain has been agnostic, so this is abnormal.  How is that statement bitcoin-hostile?

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.

Participant 10:   You mentioned [Inaudible 00:27:10] property for the Zerocash system? Do you need them to be honest all the time or just one person being honest at one time and destroy the hidden parameter he had?  

Matt:     That’s a great question. One person being honest at one time take the computer they used, set it on fire, and you’ll never have to think about this again. It’s not an online partner who has to trust to do this.

Participant 10: I hope that we live in a world where one person can be honest one time.

Matt:    I agree..

You're asking them to do something that isn't trasmitted on the normal bitcoin infrastructure.  To this point the blockchain has been agnostic, so this is abnormal.  How is that statement bitcoin-hostile?

PhantomPhreak is one of the two listed, and has expressed that he is only willing to do things under certain Bitcoin-hostile terms.