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

[bitexch]

My understanding is that Counterparty is functioning, right now, using Bitcoin as a transport layer.  In order to do so, it must be using existing, accepted features of Bitcoin.

It is abusing a bitcoin feature in an unintended, unaccepted way that obviously impacts the network to its detriment.

How is it abuse? The dev's included the feature in Bitcoin to add 80 bytes of data. People can use that feature however they want if its their. And Counterparty & Mastercoin do not intend to abuse it.

Now you want to remove 80 bytes, why did you introduce the feature at all? Reading your posts, seems like you have been hostile towards Counterparty from the start.

You ARE restricting innovation on the Bitcoin blockchain, and this is going to push these innovations onto competing blockchains instead of promoting different use cases of the Bitcoin blockchain.

If there are problems underlying abuse cases, you should handle that, but not by restricting access to the blockchain for projects trying to add more functionality into Bitcoin.

I would like to know your opinion Jeff, what is your ideal solution for Counterparty to use the Bitcoin blockchain? vs 80 bytes of OP_RETURN

+1

Jeff has already made a few proposals, all of which have been addressed and argued against by Peter, and Jeff has failed to respond to Peter's arguments.

[1714868756]

1714868756

[sparta_cuss]

Eventually, they worked it out.

[xnova]

The other issue I see here is that, much like the Internet as a whole, Bitcoin has its own 'network neutrality' concerns. Any conversation of explicitly "white-lableing" or "filtering" specific content, beyond being an untenable political situation, leads down a slippery slope as -- much like ISPs filtering an prioritizing traffic based on the nature of the content or 'ransom money' paid -- the result is a centralization of power and an inconsistent, inferior experience for the end user. Isn't Bitcoin supposed to be about the opposite?

Just as Satoshi's original quote mentioned, miners vote with their CPU cycles (or, more appropriately today, the cycles of their pool participants). If an individual miner wishes to take this kind of action for their own reasons, then there is and should be nothing stopping him or her. However, suggesting institutionalizing and/or operating in this discriminating manner at a higher, more organizational level is dangerous and -- as Satoshi's quote made clear -- something that goes against the principles that Bitcoin was founded upon. Pooled mining PoW has already produced an alarmingly centralized situation for Bitcoin is it stands. Why add more fuel to the fire there?

In my opinion, the better plan is that we continue to utilize bare multisig (at least for our larger transactions) until 80-byte OP_RETURN is hopefully made available in the next minor update of the core client (what, 2-5 months?), and then move to that. This would, of course depend on bare multisig sticking around during that time period, but it being removed from the core client would imply a patch update, where 80 byte OP_RETURN could be re-enabled. I'd hope that bare multisig would be phased out in a release after OP_RETURN was added, but if it is a "flash cut" where both are done in the same release, we have options. OP_RETURN could persist in this 80-byte state until a more elegant fee-for-data structure was fully vetted and folded into the core client.

[reader31]

Just finished reading through the past 8 pages of this thread. Thx for both the bitcoin devs and counterparty team for engaging in this open discussions, very insightful. The fact is both teams do a tremendous job at their respective projects and have incentives for innovation to thrive within the bitcoin community. Its great to see this open discussion, we have to remind ourselves that our incentives are still very much aligned. There might be some differences on implementation details, but great to see it being worked on.

my only personal quip after reading through the discussion is seeing counterparty being judged harshly for not following the 'rules'. Bitcoin being the ultimate maverick project itself, isn't it reasonable to expect that there will be other maverick projects(some of them unforeseen, like counterparty) that will tend to blossom under the shelter of bitcoin from time to time.

In those instances, ofcourse there will be ample valid reasons to throw the book at them and there are going to be more than one 'right' way that the project could be implemented(here again there can be more than one valid argument). For a project like counterparty, that has so much in common with the founding spirit of bitcoin itself. Wouldn't it be best aligned for the whole community to err towards making decisions that will facilitate smooth progression of the project?

I guess the philosophical question would boil down to, are innovations going to be 'encouraged' or 'guided' ?

I personally think that the desicion does sent a strong message to the community as a whole.


Just my two cents.

[halfcab123]

I still don't see what mastercoin is doing about this ....

[BitcoinTangibleTrust]

I still don't see what mastercoin is doing about this ....

Mastercoin needs more than 80bytes in OP_RETURN for asset issuance. Theirs seems to be a different problem.

[halfcab123]

I still don't see what mastercoin is doing about this ....

Mastercoin needs more than 80bytes in OP_RETURN for asset issuance. Theirs seems to be a different problem.

Sounds worse

[JahPowerBit]

EDIT: I will also that ask that you and Luke-Jr discuss the Coiledcoin 51% attack accusations separately from this thread, if that's okay.

No, I believe the Coiledcoin attack should be a part of this discussion. I would never have known about it if it hadn't been brought up, so I investigated what happened. What Luke-jr did to Coiledcoin was similar to a bully on the beach coming along and kicking apart a sand castle some kids were in the middle of building, saying it was in the way of people walking on the beach as justification. He used computing resources which did not belong to him, but were entrusted to his care, to sabotage another project.

I agree with that. There are a lot of similarities between the Coiledcoin attack, and the reduction from 80 bytes to 40.
No member of the core dev, gave any rational arguments to justify this reduction.
There is no other choice than to see this decision as an attack directly against XCP and MSC.

This kind of attack highlights a serious problem that goes far beyond the consequences for XCP and MSC.
The whole community should be involved to protect Bitcoin of such conduct.

[halfcab123]

On a sidenote, the counterparty video is coming along ! Get excited ! Trailer is coming tomorrow or Tuesday

[halfcab123]

On a sidenote, the counterparty video is coming along ! Get excited ! Trailer is coming tomorrow or Tuesday

+1

All this uncertainty and the price goes up go figure

[freedomfighter]

On a sidenote, the counterparty video is coming along ! Get excited ! Trailer is coming tomorrow or Tuesday

+1

All this uncertainty and the price goes up go figure

Dear Halfcab: There is no uncertainty, as assured by the devs including Bitcoin's JG. this will get solved one way or the other. The price movement to 0.005 or 6 or 4 or even 0.02 really means nothing. hang in there and see where we are a year from now. dont think days. think long term.  I know that you are.

[halfcab123]

On a sidenote, the counterparty video is coming along ! Get excited ! Trailer is coming tomorrow or Tuesday

+1

All this uncertainty and the price goes up go figure

Dear Matt and Halfcab: There is no uncertainty, as assured by the devs including Bitcoin's JG. this will get solved one way or the other. The price movement to 0.005 or 6 or 4 or even 0.02 really means nothing. hang in there and see where we are a year from now. dont think days. think long term.  I know that you are.

Almost surely a multi billion dollar market in the making. No sweat here.

To my untrained eye it appears that the recent buy order volumes are impressive. Lots of folks tend to forget that price means NOTHING without that precious volume.

[reader31]

On a sidenote, the counterparty video is coming along ! Get excited ! Trailer is coming tomorrow or Tuesday

very excited to see it

[CryptoFinanceUK]

On a sidenote, the counterparty video is coming along ! Get excited ! Trailer is coming tomorrow or Tuesday

Great stuff, looking forward to seeing what you've created!

[Luke-Jr]

FWIW, if there are any developers interested in keeping Counterparty going once multisig abuse filters are in place, there is no reason the recommended plan cannot work with a fork of Counterparty instead of the original developers.

[bitexch]

FWIW, if there are any developers interested in keeping Counterparty going once multisig abuse filters are in place, there is no reason the recommended plan cannot work with a fork of Counterparty instead of the original developers.

Rather than making thinly veiled threats, perhaps you can respond to the relevant points that have been brought up.

1. What do you have to say to Peter's criticism of your proposal: https://bitcointalk.org/index.php?topic=395761.msg5853114#msg5853114?

2. What do you have to say of Peter's criticism of merged mining (ignoring any accusation against you): https://bitcointalk.org/index.php?topic=395761.msg5824434#msg5824434?

3. Finally, what do you think of Peter's proposal: https://bitcointalk.org/index.php?topic=395761.msg5827080#msg5827080?

[topynate]

I still don't see what mastercoin is doing about this ....

Mastercoin needs more than 80bytes in OP_RETURN for asset issuance. Theirs seems to be a different problem.

On the other hand, a regular mastercoin send only takes about 30-35 bytes. Maybe Counterparty could consider selectively sending common, small transactions with OP_RETURN, and using multi-sig only for relatively unusual transaction types?

By the way, thanks both to my mysterious benefactor and to whoever thinks I'm Satoshi. I'm not sure my previous comment merits either of those compliments, but I appreciate them. My SX stealth address is SghSgpVgk7yAFx91DxwfE84Dm6r2hwSpMWcFJbR9wQTAv7pgq61Nx3dNsn if anyone is interested - and if they are, I'm sure they can send me a nonce without too much trouble 

[reader31]

FWIW, if there are any developers interested in keeping Counterparty going once multisig abuse filters are in place, there is no reason the recommended plan cannot work with a fork of Counterparty instead of the original developers.

wow! so much for believing in the spirit of bitcoin!

[perizzites]

This kind of attack highlights a serious problem that goes far beyond the consequences for XCP and MSC.
The whole community should be involved to protect Bitcoin of such conduct.

The deGoxing (maturation, removal of ideologues and amateurs incapable or unwilling to act like pros, and installation serious people) of BTC is not yet complete. The serious money isn't going to stand for nonsense.

[Luke-Jr]

FWIW, if there are any developers interested in keeping Counterparty going once multisig abuse filters are in place, there is no reason the recommended plan cannot work with a fork of Counterparty instead of the original developers.

Rather than making thinly veiled threats, perhaps you can respond to the relevant points that have been brought up.

Irrelevant agenda-serving, more like...
And responding to these doesn't really bring anything forward.
Since the existing Counterparty developer(s?) outright refuse to move forward, the only other practical option for Counterparty is someone else doing it.

1. What do you have to say to Peter's criticism of your proposal: https://bitcointalk.org/index.php?topic=395761.msg5853114#msg5853114?

He knows what he's saying here is wrong.
Satoshi himself added the IsStandard restriction concept.
I have long since been opposed to using such restrictions when unnecessary: notice how Eligius is the only pool which allows non-standard transactions, and it has allowed them since nearly when I started it.
The problem here, why whitelisting is needed for mining on Eligius, is because of Counterparty's unique position (I am ignoring Mastercoin in this thread) where it is currently indistinguishable from spam, which needs to be blacklisted due to abuse.
Every other miner and relay node would require whitelisting no matter how it's done (other than abusing multisig, which will soon not work either).

2. What do you have to say of Peter's criticism of merged mining (ignoring any accusation against you): https://bitcointalk.org/index.php?topic=395761.msg5824434#msg5824434?

It is true that forcing miners to provide you with security will result in better security than giving them a choice, because it is inevitable that some miners will opt not to provide the service.
And yes, it is also true that blockchain-based decentralised systems are always at risk of 51% attacks by design.
However, it is pure FUD to try to scare everyone away from doing the right thing by implying it is a given they will be attacked.
If you're providing a service with your altchain, it's in miners' interest to support you, not attack you, unless you are doing something harmful.
Sure, there will perhaps always be exceptions, but as long as you have a majority of miners assisting you, you'll be fine.
This is also part of why Eligius goes out of the way to support legitimate altchains which support merged mining, even if they aren't necessarily useful to the pool (for example, we helped ChronoKings/HunterCoin test their blockchain-based game).

3. Finally, what do you think of Peter's proposal: https://bitcointalk.org/index.php?topic=395761.msg5827080#msg5827080?

It doesn't solve anything, since fees don't cover transaction costs.