Author

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

sr. member
Activity: 262
Merit: 250
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://bitcointalksearch.org/topic/m.5845721
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?
member
Activity: 61
Merit: 10
Wait for Zerocoin to boot BTC out.
You prefer an altcoin that requires centralised trust, over a decentralised Bitcoin? Smiley
Anyhow, hopefully the Zerocash folks will be just another Bitcoin side chain.

Look who is talking about decentralisation
member
Activity: 61
Merit: 10
Wait for Zerocoin to boot BTC out.
You prefer an altcoin that requires centralised trust, over a decentralised Bitcoin? Smiley
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.
legendary
Activity: 2576
Merit: 1186
Wait for Zerocoin to boot BTC out.
You prefer an altcoin that requires centralised trust, over a decentralised Bitcoin? Smiley
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.
full member
Activity: 214
Merit: 101
Wait for Zerocoin to boot BTC out.
You prefer an altcoin that requires centralised trust, over a decentralised Bitcoin? Smiley
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.
legendary
Activity: 2576
Merit: 1186
Wait for Zerocoin to boot BTC out.
You prefer an altcoin that requires centralised trust, over a decentralised Bitcoin? Smiley
Anyhow, hopefully the Zerocash folks will be just another Bitcoin side chain.
member
Activity: 61
Merit: 10
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://bitcointalksearch.org/topic/m.5845721
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.
legendary
Activity: 2576
Merit: 1186
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://bitcointalksearch.org/topic/m.5845721
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).
newbie
Activity: 45
Merit: 0
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://bitcointalksearch.org/topic/m.4318549

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!
sr. member
Activity: 262
Merit: 250
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://bitcointalksearch.org/topic/m.5845721
legendary
Activity: 2576
Merit: 1186
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.
sr. member
Activity: 262
Merit: 250
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.
Counterparty can't default to constructing transactions that are not relayed by default by the official, vanilla Bitcoin Core software.
Sure it can. Just setup a few nodes dedicated to Counterparty and have your client relay to them by default.

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

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.
sr. member
Activity: 476
Merit: 300
Counterparty Chief Scientist and Co-Founder
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.
Counterparty can't default to constructing transactions that are not relayed by default by the official, vanilla Bitcoin Core software.
Sure it can. Just setup a few nodes dedicated to Counterparty and have your client relay to them by default.

I don't mean that it's technically impossible.
legendary
Activity: 2576
Merit: 1186
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.
Counterparty can't default to constructing transactions that are not relayed by default by the official, vanilla Bitcoin Core software.
Sure it can. Just setup a few nodes dedicated to Counterparty and have your client relay to them by default.
legendary
Activity: 1666
Merit: 1010
he who has the gold makes the rules
Few (I didn't say none) of those arguments pass the smell test.

  • OP_RETURN and 40 vs 80 bytes:  If the miners agree with you, you don't have to care what the network relays.  Has Counterparty directly approached miners, to get them to mine 80-byte OP_RETURN transactions?  What was the response?  If the miners agree, great, let's do it.  If the miners don't agree, there is no point supporting it in Bitcoin Core software.
  • "core devs are censoring and killing innovation!"   Counterparty is very clearly misusing a feature intended for ECDSA public keys, in a manner that very clearly results in harm to the overall network, short and long term.  Other people/companies/projects are extending the bitcoin protocol and not meeting the same resistance.
  • To repeat earlier posts, my criticism is not about counterparty in general, just this ONE CheckMultiSig flaw.  Fix that, and my criticism is gone.
  • As Peter Todd has noted, CheckMultiSig has other problems also.  It may go away regardless.

Please do not paint all Counterparty criticism with a broad brush.  My opinions are my own, and in particular I do not agree with all of Luke-Jr's points or point of view.

There are plenty of ways to innovate and extend the bitcoin protocol.  People are doing this every day.

It is always a mistake to base an entire engineering system on a subtle technical quirk that "just happens to work."  Counterparty is stuffing its own data where ECDSA public key data is supposed to go.  That is clearly not the intended use.



I think from a strategic level one must ask why are some projects unable to communicate intention and influence development, rather than getting into tactical details such as this.

It is quite clear to everyone that p2p systems can be used for all sorts of transactions that make up contracts.  If the inability to communicate and resolve needs is causing friction one must ask how the overall system should evolve to mitigate long term harm, while maximizing long term capabilities depth of the network.
full member
Activity: 214
Merit: 101
Freicoin is 80% premined.
sr. member
Activity: 476
Merit: 300
Counterparty Chief Scientist and Co-Founder
Let's stop arguing about the technicalities for just a moment; Let's talk about "where do we go from here," with this innovative project ? Can we work together to come up with a solution ?
After having read the Counterparty document, I would personally suggest using 80-byte OP_RETURN transactions as a temporary solution, and collaborating with the Freimarket developers to move forward, ideally providing a clean upgrade where XCP assets become Freimarket assets.

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.


We'd be glad to collaborate with Freimarkets to achieve our common goals. Freimarkets is a great idea, and the more our protocols can be compatible, the better.

It's not a question of forcing anyone to do anything, of course. Counterparty can't default to constructing transactions that are not relayed by default by the official, vanilla Bitcoin Core software.
legendary
Activity: 861
Merit: 1010
Moving on antoher blockchain would be disatrous, please don't do that.

legendary
Activity: 1008
Merit: 1000
Is Mastercoin having the same issue?
full member
Activity: 214
Merit: 101
It seems like the argumentation in this thread is becoming circular. Would very much like to see a response to these two posts:


Edit: To be clear, all this discussion about moving things like Counterparty to different independently or merge-mined blockchains as a "solution" to the "problem" of adding data to the blockchain is either mistaken or downright deceptive. Fact is these systems all get much better security by being embedded rather than independent. Decentralized consensus system security is a game of strength in numbers, and you want to be making use of the largest system you can afford. Merge-mining looks like a nice way to achieve that, but in reality just leaves you vulnerable to zero-marginal-cost attacks until you get the support of a large % of the total hashing power. A real world example of this is how Luke-Jr used Eligius to attack the merge-mined alt Coiledcoin. That leaves us with embedded consensus systems, and fortunately with Bitcoin only explicit blacklists have any hope of censoring their transactions rather than just making them a bit more expensive. (perhaps the even stronger requirement for explicit whitelists if my timelock crypto scheme can be made practical)

As I see it, the best solution is to keep the OP_RETURN size at 40 bytes, for simplicity and compatibility, but to allow multiple OP_RETURN outputs per transaction. There's no reason that 40 bytes of misc. data per transaction is better for Bitcoin than 80, or 120 bytes.
[snip]

Actually what should be done that would - in theory - please both sides of the issue would be to do a patch that makes embedding data in OP_RETURN transactions as expensive as doing so by creating unspendable outputs. Basically what the OP_RETURN payload is just made unlimited (up to the max size of a transaction) but you bump the min fee by the same amount that would have been simply burned in the unspendable output. I'd further recommend that the cost be set slightly less than that amount, to always incentivize using prunable blockchain space rather than unprunable UTXO space. (a legit concern in the current design, although my TXO commitments scheme probably reduces the problem greatly)

I'll do up a pull-req for this.
Jump to: