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

[ginko-B]

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!
 

+1, agree

[PhantomPhreak]

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?

I'm fine with this, of course, but it doesn't really address the issue at hand. We'd still need multi-sig for some things.

[freedomfighter]

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.

This is plain outrageous. Luke JR. I heard there is an opening for an IRS programmer. maybe you are a better fit there.  

I hope that there are more mature individuals within the BTC core dev team that can put this little kid in his place. Otherwise, with people like this in key roles in the BTC value chain, there are many troubles ahead.

[jl777]

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.

luke-jr's reasonable looking proposal actually seems to be the start his defensive countermeasure!
The reality is that it will get stuck somewhere in the process. Change the battle from open discussion of ideas to a BIP process. Seems like moving the venue to homefield?

[CryptoFinanceUK]

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.

This is quite horrifying. Correct me if I'm wrong, Luke. But it sounds like you'd be quite happy to see the death of Counterparty at this point. Are the lines of communication now closed between yourself and the Counterparty developers? Is there even a part of you that sees value in what we're trying to achieve here?

A fork can always happen, but my hunch is that the vast majority of us will stick with PP, CG and the original project.

We're very fond of our devs around here.

[LightedLamp]

http://www.reddit.com/r/circlejerk/

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

This is quite horrifying. Correct me if I'm wrong, Luke. But it sounds like you'd be quite happy to see the death of Counterparty at this point. Are the lines of communication now closed between yourself and the Counterparty developers? Is there even a part of you that sees value in what we're trying to achieve here?

A Counterparty dev has closed lines of communication.

Even if Counterparty dies, the Freimarket folks will be providing a replacement (if not an upgrade).
I also hold no Counterparty assets myself.
So no, I see no value to Counterparty specifically, just the functionality - which is already being worked on independently.
It's the Counterparty users who will lose out, unfortunately, unless someone steps up to move it forward.

[bitwhizz]

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.

This is quite horrifying. Correct me if I'm wrong, Luke. But it sounds like you'd be quite happy to see the death of Counterparty at this point. Are the lines of communication now closed between yourself and the Counterparty developers? Is there even a part of you that sees value in what we're trying to achieve here?

A Counterparty dev has closed lines of communication.

Even if Counterparty dies, the Freimarket folks will be providing a replacement (if not an upgrade).
I also hold no Counterparty assets myself.
So no, I see no value to Counterparty specifically, just the functionality - which is already being worked on independently.
It's the Counterparty users who will lose out, unfortunately, unless someone steps up to move it forward.

i can;t believe what i am reading

[Peter Todd]

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.

Actually that's incorrect, Gavin Andresen did in commit a206a23980c15cacf39d267c509bd70c23c94bfa

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

I think this really says it all: You view of Bitcoin is one where you expect miners to heavily police "abuse" of it according to a politically-determined view of what Bitcoin is for. I don't agree, and I don't think the people here agree either.

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

And again, you're advice to Counterparty is basically "play our political game and if you're nice and we like you you won't get killed off by the powerful centralized miners". This game is one where about a half dozen people decide what is or is not "harmful" and chose winners and losers based on their views of what is or is not good technology.

Hey, it's your pool, you do what you want. But it only makes sense for Counterparty and other systems like it to do what they can to avoid blacklists through technological means. Fortunately for us these technological means are available, much like how Tor has all sorts of tricks up it's sleeve to bypass censorship and get data flowing over ISP's networks against their consent. Yes, Tor is forcing those ISP's to provide a service they don't want to, and just as equally Counterparty can force miners to mine transactions they didn't want to. If you don't like that, tough.

[Anotheranonlol]

Even if Counterparty dies, the Freimarket folks will be providing a replacement (if not an upgrade).
I also hold no Counterparty assets myself.
So no, I see no value to Counterparty specifically, just the functionality - which is already being worked on independently.
It's the Counterparty users who will lose out, unfortunately, unless someone steps up to move it forward.

as far as public is concerned freimarkets is another whitepaper in a sea of whitepapers and endless proposals constantly 'being worked on' and hypothesized
there's been a lot over the years. counterparty is here and now, the devs stepped up to the plate, stopped talking and wrote working code and for that they will have a following

[PhantomPhreak]

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.

This is quite horrifying. Correct me if I'm wrong, Luke. But it sounds like you'd be quite happy to see the death of Counterparty at this point. Are the lines of communication now closed between yourself and the Counterparty developers? Is there even a part of you that sees value in what we're trying to achieve here?

A Counterparty dev has closed lines of communication.

Even if Counterparty dies, the Freimarket folks will be providing a replacement (if not an upgrade).
I also hold no Counterparty assets myself.
So no, I see no value to Counterparty specifically, just the functionality - which is already being worked on independently.
It's the Counterparty users who will lose out, unfortunately, unless someone steps up to move it forward.

None of the Counterparty devs has 'closed lines of communication' to you, and talking about Counterparty 'dying' is ridiculous.

[l4p7]

Luke Jr. is getting so much offense here (justified or not)... How would you react?
Everyone think about how you communicate things!
 

[zjtwohaha]

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.

This is quite horrifying. Correct me if I'm wrong, Luke. But it sounds like you'd be quite happy to see the death of Counterparty at this point. Are the lines of communication now closed between yourself and the Counterparty developers? Is there even a part of you that sees value in what we're trying to achieve here?

A Counterparty dev has closed lines of communication.

Even if Counterparty dies, the Freimarket folks will be providing a replacement (if not an upgrade).
I also hold no Counterparty assets myself.
So no, I see no value to Counterparty specifically, just the functionality - which is already being worked on independently.
It's the Counterparty users who will lose out, unfortunately, unless someone steps up to move it forward.

fool

[kdrop22]

Quote from the Mastercoin forums:

Any comments from developers about Mastercoin and OP_RETURN changes? Can you fix mastercoin code working perfectly without that and how long it takes?

Neither with 80 nor 40 byte OP_RETURN was useful to store MSC data because of it's limited length. The Bitcoin core devs were furthermore discussing to drop multisig transactions in their current form as standard transaction type. The MSC devs are acting proactive and are working on a new encoding scheme right now. I see it very positive, because this will yield something even more sophisticated.

[joann]

just be here to show my support

[jl777]

I am confused about multisig and its future.
Is bitcoin really going to make the (currently limited) 3 signer multisig non-standard?
Wouldnt that effectively make multisig unusable?

[Luke-Jr]

I am confused about multisig and its future.
Is bitcoin really going to make the (currently limited) 3 signer multisig non-standard?
Wouldnt that effectively make multisig unusable?

Bare multisig is already unusable. Filtering out abuses would be possible without filtering all bare multisig anyway.
P2SH multisig (which actually has potential use) will continue to work in any case.

[jl777]

I am confused about multisig and its future.
Is bitcoin really going to make the (currently limited) 3 signer multisig non-standard?
Wouldnt that effectively make multisig unusable?

Bare multisig is already unusable. Filtering out abuses would be possible without filtering all bare multisig anyway.
P2SH multisig (which actually has potential use) will continue to work in any case.

OK, good!

Also, if I have a transaction with two inputs, each from a 2 of 3 multisig acct, would it be a standard transaction:
a) if both inputs have the same signers (maybe same addr maybe different addr)
b) if both inputs use different signers

I never understood what exactly the limits were

Thanks

[perizzites]

and to directly attack altcoins purely out of spite

A bright side for you - I think the admitted 51% attack dooms his long-term participation. Stuff like that (either the 51% itself or the misuse of resources entrusted him) will probably be explicitly criminalized within the decade, and while if he's US or many places there can't be a retroactive law, having that crime in the past will make serious businesspeople reluctant to work with him.

[Luke-Jr]

You guys sure love to lie, eh?