Quote from: TheMightyX on March 23, 2014, 09:53:17 AM

Quote from: Peter Todd on March 23, 2014, 09:21:09 AM

Quote from: freedomfighter on March 23, 2014, 08:23:36 AM

Quote from: Luke-Jr on March 23, 2014, 08:02:25 AM

Quote from: TheMightyX on March 23, 2014, 07:38:21 AM

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.

bitexch

Posts

Merits