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

[led_lcd]

Luke-Jr what is your opinion regarding the pull request offered by Peter Todd?

He has 5 pull requests open, none of which seem relevant to this discussion.

Miners could still still make their decision on whether they wish to include such transactions in a block and Counterparty would use pruneable blockchain space.

Blockchain space is never prunable. Only UTXO space.

I don't know if it has been created yet. Please see:

https://bitcointalk.org/index.php?topic=395761.msg5845721#msg5845721

[1715148822]

1715148822

[1715148822]

1715148822

[1715148822]

1715148822

[1715148822]

1715148822

[1715148822]

1715148822

[Bountyful]

It's not enough to have a couple of pools mine our transactions. We need to keep the block time as close to ten minutes as possible.

Then contact more than a couple of pools. This statement sounds like you wish to force miners to include your transactions; surely you didn't mean it that way?
If you can provide a patch that identifies transactional-only Counterparty OP_RETURN transactions uniquely from 80-byte abuse, I will discuss whitelisting it on Eligius with wizkid057.
This is with the understanding that Counterparty will seek to migrate to a more acceptable solution long-term.

This is helpful and not the first time Eligius mining pool has offered to help Counterparty. Remember the burn period?
https://bitcointalk.org/index.php?topic=395761.msg4318549#msg4318549

Nice to see us exploring another opportunity to work together with Eligius, once again.

This is very helpful progress and looks like it can combine with some of the other proposals put forward. I dare say the solutions presented are even working out faster than a BIP proposal review!

[Luke-Jr]

Luke-Jr what is your opinion regarding the pull request offered by Peter Todd?

He has 5 pull requests open, none of which seem relevant to this discussion.

Miners could still still make their decision on whether they wish to include such transactions in a block and Counterparty would use pruneable blockchain space.

Blockchain space is never prunable. Only UTXO space.

I don't know if it has been created yet. Please see:

https://bitcointalk.org/index.php?topic=395761.msg5845721#msg5845721

Ignoring petertodd's slanderous lie there, I will reiterate why his idea is based on a false assertion:

Reminder: transaction fees do not pay for transactions, merely attempt to deter/rate limit flooding. To cover the cost of transactions, transaction fees would need to be much higher and somehow distributed across all full nodes (not merely miners).

[samperi649]

Luke-Jr what is your opinion regarding the pull request offered by Peter Todd?

He has 5 pull requests open, none of which seem relevant to this discussion.

Miners could still still make their decision on whether they wish to include such transactions in a block and Counterparty would use pruneable blockchain space.

Blockchain space is never prunable. Only UTXO space.

I don't know if it has been created yet. Please see:

https://bitcointalk.org/index.php?topic=395761.msg5845721#msg5845721

Ignoring petertodd's slanderous lie there, I will reiterate why his idea is based on a false assertion:

Reminder: transaction fees do not pay for transactions, merely attempt to deter/rate limit flooding. To cover the cost of transactions, transaction fees would need to be much higher and somehow distributed across all full nodes (not merely miners).

Wait for Zerocoin to boot BTC out.

[Luke-Jr]

Wait for Zerocoin to boot BTC out.

You prefer an altcoin that requires centralised trust, over a decentralised Bitcoin?
Anyhow, hopefully the Zerocash folks will be just another Bitcoin side chain.

[porqupine]

Wait for Zerocoin to boot BTC out.

You prefer an altcoin that requires centralised trust, over a decentralised Bitcoin?
Anyhow, hopefully the Zerocash folks will be just another Bitcoin side chain.

I was under the impression Zerocoin was supposed to merged on top of bitcoin originally - I haven't read their white paper in detail though.
Real-world utility is essential to the value and success of a crypto-currency, therefore most of the alt projects just seem like moot (especially at the stage where even bitcoin lacks wide-spread adoptation). On the other hand blanket opposition to any kind of innovation on the bitcoin blockchain seems just as counter-productive.

[Luke-Jr]

Wait for Zerocoin to boot BTC out.

You prefer an altcoin that requires centralised trust, over a decentralised Bitcoin?
Anyhow, hopefully the Zerocash folks will be just another Bitcoin side chain.

I was under the impression Zerocoin was supposed to merged on top of bitcoin originally - I haven't read their white paper in detail though.

Originally. But the original concept was completely impractical (and still had the centralised trust issue).

Real-world utility is essential to the value and success of a crypto-currency, therefore most of the alt projects just seem like moot (especially at the stage where even bitcoin lacks wide-spread adoptation). On the other hand blanket opposition to any kind of innovation on the bitcoin blockchain seems just as counter-productive.

The idea behind side-chains is that you will be able to simply move bitcoins across multiple blockchains, with different properties of their own, and back again.
This makes them real-world usable, and free to do almost any kind of innovation.

[samperi649]

Wait for Zerocoin to boot BTC out.

You prefer an altcoin that requires centralised trust, over a decentralised Bitcoin?
Anyhow, hopefully the Zerocash folks will be just another Bitcoin side chain.

I was under the impression Zerocoin was supposed to merged on top of bitcoin originally - I haven't read their white paper in detail though.

Originally. But the original concept was completely impractical (and still had the centralised trust issue).

Real-world utility is essential to the value and success of a crypto-currency, therefore most of the alt projects just seem like moot (especially at the stage where even bitcoin lacks wide-spread adoptation). On the other hand blanket opposition to any kind of innovation on the bitcoin blockchain seems just as counter-productive.

The idea behind side-chains is that you will be able to simply move bitcoins across multiple blockchains, with different properties of their own, and back again.
This makes them real-world usable, and free to do almost any kind of innovation.

Oh Really?!! You and your co-mates harassed Matt Green to the core that he wanted Zerocoin to be a true decentralised cryptocurrency. Dude! its not an altcoin. Its Zerocoin.

[samperi649]

Wait for Zerocoin to boot BTC out.

You prefer an altcoin that requires centralised trust, over a decentralised Bitcoin?
Anyhow, hopefully the Zerocash folks will be just another Bitcoin side chain.

Look who is talking about decentralisation

[led_lcd]

Luke-Jr what is your opinion regarding the pull request offered by Peter Todd?

He has 5 pull requests open, none of which seem relevant to this discussion.

Miners could still still make their decision on whether they wish to include such transactions in a block and Counterparty would use pruneable blockchain space.

Blockchain space is never prunable. Only UTXO space.

I don't know if it has been created yet. Please see:

https://bitcointalk.org/index.php?topic=395761.msg5845721#msg5845721

Ignoring petertodd's slanderous lie there, I will reiterate why his idea is based on a false assertion:

Reminder: transaction fees do not pay for transactions, merely attempt to deter/rate limit flooding. To cover the cost of transactions, transaction fees would need to be much higher and somehow distributed across all full nodes (not merely miners).

I agree with what you said. Is it correct that we are not at the stage where the fee can be distributed across the network? At the moment those fees we are talking about would be taken by the miners but there is nothing to stop those fees disbursed across the network in the future.

Am I correct to say that we don't disagree that:
1) Counterparty messages are financial transactions
2) There is scope to include Counterparty messages in the blockchain as long as :
  a) It doesn't cause undue burden on the network
  b) It doesn't open the door for other abuses of data storage in the blockchain

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?

[Peter Todd]

Ignoring petertodd's slanderous lie there, I will reiterate why his idea is based on a false assertion:

Reminder: transaction fees do not pay for transactions, merely attempt to deter/rate limit flooding. To cover the cost of transactions, transaction fees would need to be much higher and somehow distributed across all full nodes (not merely miners).

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

21:48 < petertodd> Luke-Jr: you should clarify exactly what you disagree with with regard to my statement on coiledcoin
21:58 < Luke-Jr> petertodd: don't play dumb
21:59 < petertodd> Luke-Jr: no I'm quite serious.
22:07 < petertodd> Luke-Jr: in particular, what exactly are you saying you did here and how does that differ from my statement? https://bitcointalk.org/index.php?topic=56675.msg678006#msg678006

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.

[Luke-Jr]

I agree with what you said. Is it correct that we are not at the stage where the fee can be distributed across the network? At the moment those fees we are talking about would be taken by the miners but there is nothing to stop those fees disbursed across the network in the future.

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

Am I correct to say that we don't disagree that:
1) Counterparty messages are financial transactions
2) There is scope to include Counterparty messages in the blockchain as long as :
  a) It doesn't cause undue burden on the network
  b) It doesn't open the door for other abuses of data storage in the blockchain

This seems fair.

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.

[samperi649]

Wait for Zerocoin to boot BTC out.

You prefer an altcoin that requires centralised trust, over a decentralised Bitcoin?
Anyhow, hopefully the Zerocash folks will be just another Bitcoin side chain.

I was under the impression Zerocoin was supposed to merged on top of bitcoin originally - I haven't read their white paper in detail though.

Originally. But the original concept was completely impractical (and still had the centralised trust issue).

Real-world utility is essential to the value and success of a crypto-currency, therefore most of the alt projects just seem like moot (especially at the stage where even bitcoin lacks wide-spread adoptation). On the other hand blanket opposition to any kind of innovation on the bitcoin blockchain seems just as counter-productive.

The idea behind side-chains is that you will be able to simply move bitcoins across multiple blockchains, with different properties of their own, and back again.
This makes them real-world usable, and free to do almost any kind of innovation.

You deleted my posts because I keep telling the truth

[Peter Todd]

I was under the impression Zerocoin was supposed to merged on top of bitcoin originally - I haven't read their white paper in detail though.
Real-world utility is essential to the value and success of a crypto-currency, therefore most of the alt projects just seem like moot (especially at the stage where even bitcoin lacks wide-spread adoptation). On the other hand blanket opposition to any kind of innovation on the bitcoin blockchain seems just as counter-productive.

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.

[porqupine]

You deleted my posts because I keep telling the truth

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

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

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.

[Luke-Jr]

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.

[zjtwohaha]

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?

[led_lcd]

I agree with what you said. Is it correct that we are not at the stage where the fee can be distributed across the network? At the moment those fees we are talking about would be taken by the miners but there is nothing to stop those fees disbursed across the network in the future.

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

Am I correct to say that we don't disagree that:
1) Counterparty messages are financial transactions
2) There is scope to include Counterparty messages in the blockchain as long as :
  a) It doesn't cause undue burden on the network
  b) It doesn't open the door for other abuses of data storage in the blockchain

This seems fair.

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.

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.

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

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.