Author

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

sr. member
Activity: 476
Merit: 300
Counterparty Chief Scientist and Co-Founder
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.
member
Activity: 103
Merit: 10
It From Bit
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.

member
Activity: 70
Merit: 10
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!
 
member
Activity: 70
Merit: 10
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.
member
Activity: 103
Merit: 10
It From Bit
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.

legendary
Activity: 910
Merit: 1000

How is mastercoin getting around this, did you say?
legendary
Activity: 1596
Merit: 1100
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.

hero member
Activity: 588
Merit: 504
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.

sr. member
Activity: 262
Merit: 250
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?

 
hero member
Activity: 742
Merit: 500
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 Smiley . anyway this is probably the wrong thread for buy/sell
legendary
Activity: 910
Merit: 1000
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
newbie
Activity: 56
Merit: 0
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...

hero member
Activity: 689
Merit: 507
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 !!
legendary
Activity: 910
Merit: 1000
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

sr. member
Activity: 350
Merit: 250
Vires in Numeris
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,


I will request that PhantomPhreak delete this post, too, as it's another attempt at market manipulation, even with the caveat that it's just his speculation.

For those who are interested in Counterparty *as a project*, remember that not only PhantomPhreak, but also JGarzik said that none of what is being discussed here endangers Counterparty.

That should be posted in the sigs of every comment regarding this issue.
member
Activity: 70
Merit: 10
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,


I will request that PhantomPhreak delete this post, too, as it's another attempt at market manipulation, even with the caveat that it's just his speculation.

For those who are interested in Counterparty *as a project*, remember that not only PhantomPhreak, but also JGarzik said that none of what is being discussed here endangers Counterparty.
sr. member
Activity: 350
Merit: 250
Vires in Numeris
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,


Really?

The price for a revolutionary new protocol that opens up countless opportunities in the world of business and finance should be a lot lower?

Are you delusional or are you just trying to get cheap XCP?

The only reason the price has gone down is because the market is so small any one person selling their original stake of one bitcoin is enough to drop the price down.
It doesn't mean the price is actually down.
member
Activity: 70
Merit: 10
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.

I am not in a position to say what is possible or not possible regarding identifying counterparty transactions, but I would caution against even using the word "impossible".
The foot is never more easily inserted into the mouth then when we claim absolutes.

The only absolute we can claim is that nothing is absolute.

Obviously having one 80 byte transaction is more ideal than having two linked 40 byte transactions due to costs but also it is more efficient for both bitcoin and counterparty. I would also think it makes backwards compatibility simpler in case drastic measures must be taken in the future, no? Regardless, cheaper transactions mean wider adoption.

From Luke-Jrs recent post I gathered that the patch idea was a quick workaround for now until a BIPS could be implemented (we all know how long that could take), not a permanent solution.

Now what you are saying is the patch itself would be worthless because other than a pre-emptive statement attached to the transaction ("Hey I'm a counterparty transaction!"), there is no way to differentiate counterparty transactions from spam?

Basically any spam could just copy the header information or whatever identifies counterparty transactions and if included could piggyback on our whitelist.
That kind of defeats the whole purpose doesn't it.

Don't forget, Luke-Jr is requesting that PhantomPhreak make a BIP for a feature for which there was no BIP to begin with! It seems that when PhantomPhreak brought that up, Luke did not think it was worth replying. The whole thing stinks of the most absurd and blatant hierarchy.

Nor did Luke think it was worth replying when Peter brought up why merged mining will not work ("slanderous remark" or not, there is still a theoretical question that may have real life consequences if Peter is right).

Also, Peter's points quoted here are entirely correct.
sr. member
Activity: 350
Merit: 250
Vires in Numeris
On an unrelated note, I've created a new theme for the Counterparty GUI. Some users said the other ones  were too flashy and nice so they wanted something more plain and boring. Ok I'm paraphrasing but here it is:




The themes are pretty much done but JahPowerBit is a bit swamped this week so he doesn't have time to finalize (optimize) my code.
Still working away though.
The theme selection system is working great. Everything else is finished.
Fixed all the bugs I could find.
legendary
Activity: 910
Merit: 1000
Well, 'risk' as in investment wise, and which way the price is heading, the price should probably 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,
Jump to: