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

[TheMightyX]

You're asking them to do something that isn't trasmitted on the normal bitcoin infrastructure.  To this point the blockchain has been agnostic, so this is abnormal.  How is that statement bitcoin-hostile?

Bitcoin doesn't have Counterparty support. I'm asking them to use a temporary side-channel in addition to normal relaying-to-random-nodes until the Bitcoin network has upgraded to support Counterparty.

This is quite the opposite of antagonistic and seems almost optimistic.
Luke some times your comments are hard to follow.

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.
So... you will do it, just not until it is convenient for you and the other bitcoin developers?

[perizzites]

About 12 miners? Ain't that about how many people run the Federal Reserve?

Be careful what you wish for about "go fork bitcoin core and see if anyone wants your fork coins." The real money is coming online to BTC, they will outmine you, outfork you, and outregulate you - brute force - if you get in their way.

[TheMightyX]

I'd like to echo the previous sentiments about not making personal attacks against other users, regardless of what side of the debate they are on.
This is a touchy subject that deserves our diplomacy.

Fundamentalist or not, Luke-Jr is entitled to his decisions and it is up to us to convince him why they have more to gain than lose by working with us.

Edit:

Imagine what would happen if bitcoin officially endorsed counterparty?
You would have a strong currency with distributed exchange and financial instrument capabilities.
Counterparty is the fairest if not the fairest distribution imaginable. Completely trust-free via proof-of-burn.

What's better for bitcoin? To evolve and grow or to stagnate and die?
You've got 100 other cryptocurrencies hot on your tail. Currencies with faster transactions, more secure algorithms and more features. How will bitcoin hope to compete against ethereum?

Your early-start seniority and notoriety will only get you so far.
Look at mt.gox.
First out doesn't necessarily make you a winner.

[Luke-Jr]

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.

[TheMightyX]

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.

This is downright optimistic  
I edited my last post btw.
But I would also like to add that just because we are pro-counterparty does not mean we are anti-bitcoin.
We all want bitcoin to succeed as it represents a revolutionary change to a corrupt system that negatively affects our lives in seemingless ways.

Edit: I gotta stop editing my posts after the fact 

[ripplebtc]

I'd like to echo the previous sentiments about not making personal attacks against other users, regardless of what side of the debate they are on.
This is a touchy subject that deserves our diplomacy.

Fundamentalist or not, Luke-Jr is entitled to his decisions and it is up to us to convince him why they have more to gain than lose by working with us.

Edit:

Imagine what would happen if bitcoin officially endorsed counterparty?
You would have a strong currency with distributed exchange and financial instrument capabilities.
Counterparty is the fairest if not the fairest distribution imaginable. Completely trust-free via proof-of-burn.

What's better for bitcoin? To evolve and grow or to stagnate and die?
You've got 100 other cryptocurrencies hot on your tail. Currencies with faster transactions, more secure algorithms and more features. How will bitcoin hope to compete against ethereum?

Your early-start seniority and notoriety will only get you so far.
Look at mt.gox.
First out doesn't necessarily make you a winner.

Agree. Bitcoin and Counterparty are not competitors, they are collaborators. Ethereum, Bitshares, Peershare, NXT will be competitors of Bitcoin. Luke and other Bitcoin Core Devs, please rethink your decision of OP_RETURN, thanks!

[freedomfighter]

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

[baddw]

...(snip)....
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.
...(snip)....
Hopefully that clarifies my position.

Wow, that almost seems like a complete reversal of your previous statements.  But whatever brought it about, thank you!  This seems like a good plan, and I'm sure something that we XCP supporters can live with!

[Peter Todd]

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.

[BitThink]

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.

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.

However, I still think try to encode the transactions in a more efficient way is still the best option now. I believe that, most transactions, if not all, can be encoded with 40 bytes.

[TheMightyX]

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.

[bitexch]

i am willing to pay 2.75 x over burn

10,000 XCP at 0.00275

so 0.00275 is the price i am looking for and i will purchase up to 10 000XCP

 exchange misrepresents the situation, and you won;t be able to dump 10k without crashing the price anyways

Big risk holding XCP atm
 
Get out while your ahead

PM me

Can PhantomPhreak please remove this and any other FUD that aims to lower the price so that individuals can buy cheap XCP?

For anyone who understands the situation, it is quite clear that Counterparty is in no "danger"  (PhantomPhreak himself said so); this all sounds much scarier than it is.

Of course, PhantomPhreak should delete my quotation of this post, as well.

[bitwhizz]

i deleted myself, i will take it to the buyer/seller section

[TheMightyX]

i am willing to pay 2.75 x over burn

10,000 XCP at 0.00275

so 0.00275 is the price i am looking for and i will purchase up to 10 000XCP

 exchange misrepresents the situation, and you won;t be able to dump 10k without crashing the price anyways

1.counterwallet release means dumping of XCP by lazy burners who don't want to use counterpartyd
2.XCP are fighting a losing battle in staying within the bitcoin network

Big risk holding XCP atm
 
Get out while your ahead

PM me

Stop trying to profit off of the conflict going on.
Counterparty is in no danger of folding.
Big risk holding XCP my ass ><
This coin has one of the brightest futures of any protocol out there.

[bitwhizz]

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,

[TheMightyX]

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.

[bitexch]

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.

[TheMightyX]

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.

[bitexch]

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.

[TheMightyX]

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.