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

[bitwhizz]

You can't censor our speculation, just becouse you don;t like what you are hearing,

Thats something the bitcoin devs probably would do

i deleted my first post, as i felt this was an inappropiate section for my buy offer, other than that, there sould be no censorship,
thanks

[Spratan]

Is the technical case over ?

I hope so because, in the last posts, Bitcoin Core devs were strictly like US Regulators, and XCP Community was the BTC one, pushing revolution and innovation ahead. I am not sure BTC representatives would deserve to gain cause with regulators in the near future, if they have same methods when in similar positions !!

[Bellebite2014]

Well, investment wise, the price should be alot lower,
due to recent news
i'm a believer which is why i am willing to pay for a large amount,
however i wouldn;t go so far as to say that its not a rocky boat,
however its just speculation

and thats my buy offer,

Due to recent news ? No one knows about XCP, and only a handful of people are reading this thread. This is not like the China hoax for banning BTC a few days ago. You know, fake news with REAL impact...

Welcome to the real world. The world would be a better place without vultures like you though...

[bitwhizz]

just looking to buy some XCP,at the price i am looking for,
noone has to sell to me, the offers always their though
the fact that people get so offended by an offer which is still 2.75 x return in two months, means i am infact not the vulture here,
I am a big believer of counter party, and i think the devs are doing a great job,
that is my buy in point though for bulk

[nakaone]

it is totally fine that some people are taking the opportunity to buy cheap now, so he can offer whatever he like as long as he finds a seller . anyway this is probably the wrong thread for buy/sell

[led_lcd]

I'm replying to myself since no one is taking up a positive nor negative sentiment to my last post. It is included below.

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.

I've described in prior posts what I consider to be relevant business cases why Counterparty is relevant to Bitcoin.

I am asking the people present in the thread to enable the continued development of Counterparty in a way which doesn't hobble the usability of Counterparty. As others and myself point out, it is our opinion and the opinion of the users of Counterparty and Bitcoin that it is worth the short term inconvenience for the upside potential to Bitcoin.

Luke, there are some points we have come to agreement upon. Can't we take these points in good faith and come up with a smart solution that allows Counterparty to operate

Peter, I appreciate that you had volunteered to create a pull-request that will help Counterparty out in the short term. Agreed that I think Counterparty will need to and will have to prove it's utility and evolve to stay within the blockchain. If Counterparty fails, prune it out. Do you see other ways in which we can build a solution based upon the common ground we have found so far?

 

[Anotheranonlol]

Luke's suggestion seems reasonable. However, the second step in the immediate plan is quite difficult, if not impossible. How can we persuade the operators of BtcGuild, GHash.IO, and Discus Fish to accept the patch? Moreover, there are around 30% of the hashing power belong to 'Unknown'. Who to contact for these miners?   Most likely the Eligius is only one can apply the patch since it is run by Luke himself, but Eligius only have around 14% of the shares. (according to http://blockchain.info/pools)

More practical way is
1. Write Bitcoin Core patch to whitelist 80-byte OP_RETURN-based Counterparty transactions.
2. contact major mining pools and request them to apply this patch, and open merge request with mainline Bitcoin Core.
3. Use OP_RETURN for data <= 40 bytes. Keep using CheckMultiSig for data > 40 bytes, until more than 60% (GHash.IO + BTCGuild + Eligius + Discus Fish) of hashing rate accepts that patch, and then use addnode to get it relayed to miners. Otherwise, just wait until the new core with the counterparty patch is out (Personally I think the latter, although difficult, has higher chance to be successful).

I believe the main operators are as reluctant to take the counterparty patch as they will take other patches to filter CheckMultiSig. Therefore, everything will be fine if the official core accepts the counterparty patch before accepting the filtering CheckMultiSig patch.

A friend had asked the owner of Discus Fish (the pool control ~13% of btc), if he is willing to implement patch. he noted it but is busy with other projects, by the way their pool should soon comfortably have >50% of LTC, so you can see alt-chain is not so safe. I don't think that Ghash will be receptive, judging by there previous behaviour

Many pool operators are already comfortably making profits. They don't have a direct incentivization to add any new features
or introduce any extra work to themselves, with patch upon patch unless they see a direct benefit to their wallets. They want to know if it either generates a profit for them or protects them from losing profit otherwise it's business as usual.

These  projects are incredibly useful to bitcoin ecosystem.
A trust-less decentralized solution to  trading assets!. hundreds of millions of dollars lost, stolen, hacked by 'trusting' your funds on centralized exchanges, many exchanges randomly offline. Bitcoin private keys should be in your possession. How did we even get to the stage where it's normal to hand over your private keys and trust somebody elses integrity or competence not to dissapear with funds.?  The damage that caused to the public perception of bitcoin is huge, and will take a long time to repair or forget. Perhaps it's already too late. It's hard into a serious discussion with some normal members of public. ie not geeks without them bringing up some of the more well-known cases-.  I cannot understand for the life of me how projects like this are being suppressed, innovation like this is best for everyone and stifling it would seem to naturally result in a migration onto a project that encourages it.

[jgarzik]

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.

[bitwhizz]

How is mastercoin getting around this, did you say?

[UncleBobs]

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.

If that is what your argument boils down to, it seems to be completely inadequate to explain your insistence on this issue.

[bitexch]

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.

If that is what your argument boils down to, it seems to be completely inadequate to explain your insistence on this issue.

+1. Completely absurd.

[l4p7]

I read the last couple of pages here and I really have to say: Be FRIENDLY to each other. The obvious was pointed out before: Bitcoin and Counterparty benefit from each other and are not competitors. So with the mutual benefit in mind please be constructive and differentiated. If someone is personally attacked it is less easy for him to move without the LOSS OF FACE. This is not the place to lift up your EGO by blaming others personally!
 

[UncleBobs]

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.

In what way is the array of benefits Counterparty provides to Bitcoin an abuse? Spam is an abuse. Inserting religious messages is an abuse.  Counterparty is a *use*.

Because you and Luke do not accept what Counterparty is doing does not make it 'unaceptable'.  The two of you may be big wheels around here, but that can change fast if you act in ways that a majority see as counterproductive to Bitcoin, and in this case I think it is clear that you are.

Please spell out here, in detail, with numbers, how you *hypothesize* that Counterparty is impacting the network to its detriment.  

If you can put a clearly defined cost on its use then perhaps that can be weighed against its obvious benefits.

[PhantomPhreak]

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.

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

I think it's a ludicrous idea.

Basically Luke-Jr is saying we should have a model of explicit whitelisting where people ask permission first to use Bitcoin. Right now that wouldn't be one patch, it'd be two patches: Counterparty and Mastercoin. Very soon it'll be three patches as Colored Coins adds decentralized exchange functionality, and probably soon after that four patches when Zerocoin is deployed, five once the guys doing secure multiparty computation with Bitcoin release their software, six for... You get the idea. On top of that from technical perspective writing a general purpose patch to distinguish even just Counterparty transactions from "spam" is impossible without having access to the Counterparty consensus state. Sorry guys, but Luke is either foolish or trolling you.

There's a bigger issue too: You know, one of my criticisms of Mastercoin and Counterparty is that because they don't have a scripting system adding new functionality requires the co-operation from core developers to deploy as an upgrade. Yet here, we see Luke wanting the exact same model for Bitcoin in perpetuity.

Anyway, as I've said before, getting OP_RETURN deployed makes Counterparty and Mastercoin transactions a bit cheaper. That's it. This isn't a "sky is falling" scenario, this is a "better get the umbrellas out" scenario.

This is exactly correct.

[Ola]

I think this conversation should be viewed as the most bullish indicator for the future of fast-blockchain altcoins.  If Bitcoin devs don't want platforms like MSC and XCP build on their protocol, they're not the only game in town and the market is hungry for anything willing to differentiate itself.   Until a few days ago I did not see any future value for something like Litecoin, but with a 5x faster blocktime resulting in 5x faster action execution, there are already tangible advantages of being on a faster blockchain.

Add to that things like Florincoin where they already have a 160 arbitrary message field and a 40 second block time, and Bitcoins security headstart gets a little less compelling.  Given the option, I bet a lot of Scrypt miners drop everything to mine the coin that powers the most responsive, cheapest DEX and asset platform.  I know I'll be interested in it.

Hi Adam! You may want to re-consider NXT as a platform..I saw your video and your only objection was that its expensive to issue an Asset on the nxt platform, the fees are currently being worked on. You already know nxt is very fast and have you tried out the new asset exchange? there are hardly any bugs and its been running live on the testnet for weeks, scheduled for release in a few days / week

You can play on the testnet if you haven't already. Just click here: http://nxtra.org/nxt-client/

The client is simple and intuitive. You can pick it up in 5 minutes.

[metacoin]

I think this conversation should be viewed as the most bullish indicator for the future of fast-blockchain altcoins.  If Bitcoin devs don't want platforms like MSC and XCP build on their protocol, they're not the only game in town and the market is hungry for anything willing to differentiate itself.   Until a few days ago I did not see any future value for something like Litecoin, but with a 5x faster blocktime resulting in 5x faster action execution, there are already tangible advantages of being on a faster blockchain.

Add to that things like Florincoin where they already have a 160 arbitrary message field and a 40 second block time, and Bitcoins security headstart gets a little less compelling.  Given the option, I bet a lot of Scrypt miners drop everything to mine the coin that powers the most responsive, cheapest DEX and asset platform.  I know I'll be interested in it.

Florincoin now supports 528 bytes of data.

The idea of Florincoin is to use the transaction metadata field for purposes like this. You will not find any resistance from our development team upon attempting to implement such a protocol atop our blockchain.

In fact, we would work with you to accomplish this goal.

[BitcoinTangibleTrust]

I think it's a ludicrous idea.

Basically Luke-Jr is saying we should have a model of explicit whitelisting where people ask permission first to use Bitcoin. Right now that wouldn't be one patch, it'd be two patches: Counterparty and Mastercoin. Very soon it'll be three patches as Colored Coins adds decentralized exchange functionality, and probably soon after that four patches when Zerocoin is deployed, five once the guys doing secure multiparty computation with Bitcoin release their software, six for... You get the idea. On top of that from technical perspective writing a general purpose patch to distinguish even just Counterparty transactions from "spam" is impossible without having access to the Counterparty consensus state. Sorry guys, but Luke is either foolish or trolling you.

There's a bigger issue too: You know, one of my criticisms of Mastercoin and Counterparty is that because they don't have a scripting system adding new functionality requires the co-operation from core developers to deploy as an upgrade. Yet here, we see Luke wanting the exact same model for Bitcoin in perpetuity.

Anyway, as I've said before, getting OP_RETURN deployed makes Counterparty and Mastercoin transactions a bit cheaper. That's it. This isn't a "sky is falling" scenario, this is a "better get the umbrellas out" scenario.

Peter,  I admire you immensely and I enjoy you work and respect your passion. However, I'm disappointed that your response (as a paid Counterparty representative) seems equally mixed with personal anger against Luke-Jr and insightful comments on how to resolve our issues. Your post above accusing Luke-Jr of trolling and calling the proposal "ludicrous" was unnecessary to help us move forward and may have set us back.

Neither jgarzick nor Luke-Jr have made any personal attacks on anyone in the Counterparty team during this exchange. If we wish to continue to make progress together on this issue, I must ask that you refrain from making personal attacks against other bitcoin core devs, particularly as you officially represent Counterparty.

Yes, we have our differences and we may not like each other that much, but I would ask that we keep our focus on the commenting on the merits of the solutions proposed. If I recall, it was you who said we must stay in the herd with the greatest numbers for the greatest security. I agree with you and hope that you'll agree with me to keep our exchanges professional so we can stick together.

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.

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

In what way is the array of benefits Counterparty provides to Bitcoin an abuse? Spam is an abuse. Inserting religious messages is an abuse.  Counterparty is a *use*.

Because you and Luke do not accept what Counterparty is doing does not make it 'unaceptable'.  The two of you may be big wheels around here, but that can change fast if you act in ways that a majority see as counterproductive to Bitcoin, and in this case I think it is clear that you are.

Please spell out here, in detail, with numbers, how you *hypothesize* that Counterparty is impacting the network to its detriment.  

If you can put a clearly defined cost on its use then perhaps that can be weighed against its obvious benefits.

There are two different points that keep getting conflated: Counterparty as it is currently functioning and Counterparty as it was meant to function. The former is with bare multi-sig outputs, and the latter is with 80 byte OP_RETURN outputs. Whenever anyone asks how Counterparty is hurting the Bitcoin network, Jeff and Luke refer to the problems that come with bare multi-sig outputs, and gloss over the fact that, if not for an arbitrary, last minute decision to reduce OP_RETURN to 40 bytes, Counterparty wouldn't be "harming" Bitcoin in the way it currently is.

The questions should rather be asked: If Counterparty used OP_RETURN, how would it harm the Bitcoin network?

[PhantomPhreak]

I think it's a ludicrous idea.

Basically Luke-Jr is saying we should have a model of explicit whitelisting where people ask permission first to use Bitcoin. Right now that wouldn't be one patch, it'd be two patches: Counterparty and Mastercoin. Very soon it'll be three patches as Colored Coins adds decentralized exchange functionality, and probably soon after that four patches when Zerocoin is deployed, five once the guys doing secure multiparty computation with Bitcoin release their software, six for... You get the idea. On top of that from technical perspective writing a general purpose patch to distinguish even just Counterparty transactions from "spam" is impossible without having access to the Counterparty consensus state. Sorry guys, but Luke is either foolish or trolling you.

There's a bigger issue too: You know, one of my criticisms of Mastercoin and Counterparty is that because they don't have a scripting system adding new functionality requires the co-operation from core developers to deploy as an upgrade. Yet here, we see Luke wanting the exact same model for Bitcoin in perpetuity.

Anyway, as I've said before, getting OP_RETURN deployed makes Counterparty and Mastercoin transactions a bit cheaper. That's it. This isn't a "sky is falling" scenario, this is a "better get the umbrellas out" scenario.

Peter,  I admire you immensely and I enjoy you work and respect your passion. However, I'm disappointed that your response (as a paid Counterparty representative) seems equally mixed with personal anger against Luke-Jr and insightful comments on how to resolve our issues. Your post above accusing Luke-Jr of trolling and calling the proposal "ludicrous" was unnecessary to help us move forward and may have set us back.

Neither jgarzick nor Luke-Jr have made any personal attacks on anyone in the Counterparty team during this exchange. If we wish to continue to make progress together on this issue, I must ask that you refrain from making personal attacks against other bitcoin core devs, particularly as you officially represent Counterparty.

Yes, we have our differences and we may not like each other that much, but I would ask that we keep our focus on the commenting on the merits of the solutions proposed. If I recall, it was you who said we must stay in the herd with the greatest numbers for the greatest security. I agree with you and hope that you'll agree with me to keep our exchanges professional so we can stick together.

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.

Absolutely not. Luke-Jr (and jgarzik) are being completely unreasonable, and they need to be called out for it. Luke-Jr's most recent 'proposal' is indeed ludicrous, and yes, he's doing nothing but trolling (intentionally or not).

No one officially represents Counterparty, but if Peter did, then he'd be doing an admirable job of it, IMO.

[td services]

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.

This discussion has shown some serious problems with Bitcoin, a high degree of consolidation of centralized control, which needs to be addressed. Proof of work mining was the main turn-off as a gross waste of resources and energy when I first learned about Bitcoin. It would be good if Counterparty and Mastercoin could migrate away from Bitcoin, preferably to a PoS or proof of contribution blockchain.