Author

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

hero member
Activity: 588
Merit: 504
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
legendary
Activity: 1120
Merit: 1160
1. What do you have to say to Peter's criticism of your proposal: https://bitcointalksearch.org/topic/m.5853114?
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.
legendary
Activity: 910
Merit: 1000
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
legendary
Activity: 2576
Merit: 1186
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.
newbie
Activity: 39
Merit: 0
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.
legendary
Activity: 1176
Merit: 1134
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?
full member
Activity: 210
Merit: 100
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.
sr. member
Activity: 476
Merit: 300
Counterparty Chief Scientist and Co-Founder
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.
member
Activity: 82
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!
 

+1, agree
legendary
Activity: 2576
Merit: 1186
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.
Rather than making thinly veiled threats, perhaps you can respond to the relevant points that have been brought up.
Irrelevant agenda-serving, more like...
And responding to these doesn't really bring anything forward.
Since the existing Counterparty developer(s?) outright refuse to move forward, the only other practical option for Counterparty is someone else doing it.

1. What do you have to say to Peter's criticism of your proposal: https://bitcointalksearch.org/topic/m.5853114?
He knows what he's saying here is wrong.
Satoshi himself added the IsStandard restriction concept.
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).

2. What do you have to say of Peter's criticism of merged mining (ignoring any accusation against you): https://bitcointalksearch.org/topic/m.5824434?
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).

3. Finally, what do you think of Peter's proposal: https://bitcointalksearch.org/topic/m.5827080?
It doesn't solve anything, since fees don't cover transaction costs.
newbie
Activity: 5
Merit: 0
This kind of attack highlights a serious problem that goes far beyond the consequences for XCP and MSC.
The whole community should be involved to protect Bitcoin of such conduct.

The deGoxing (maturation, removal of ideologues and amateurs incapable or unwilling to act like pros, and installation serious people) of BTC is not yet complete. The serious money isn't going to stand for nonsense.
full member
Activity: 221
Merit: 100
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.

wow! so much for believing in the spirit of bitcoin! Undecided
newbie
Activity: 17
Merit: 0
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?

By the way, thanks both to my mysterious benefactor and to whoever thinks I'm Satoshi. I'm not sure my previous comment merits either of those compliments, but I appreciate them. My SX stealth address is SghSgpVgk7yAFx91DxwfE84Dm6r2hwSpMWcFJbR9wQTAv7pgq61Nx3dNsn if anyone is interested - and if they are, I'm sure they can send me a nonce without too much trouble  Smiley
member
Activity: 70
Merit: 10
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.

Rather than making thinly veiled threats, perhaps you can respond to the relevant points that have been brought up.

1. What do you have to say to Peter's criticism of your proposal: https://bitcointalksearch.org/topic/m.5853114?

2. What do you have to say of Peter's criticism of merged mining (ignoring any accusation against you): https://bitcointalksearch.org/topic/m.5824434?

3. Finally, what do you think of Peter's proposal: https://bitcointalksearch.org/topic/m.5827080?
legendary
Activity: 2576
Merit: 1186
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.
newbie
Activity: 39
Merit: 0
On a sidenote, the counterparty video is coming along ! Get excited ! Trailer is coming tomorrow or Tuesday Smiley

Great stuff, looking forward to seeing what you've created!
full member
Activity: 221
Merit: 100
On a sidenote, the counterparty video is coming along ! Get excited ! Trailer is coming tomorrow or Tuesday Smiley


very excited to see it Smiley
full member
Activity: 224
Merit: 100
CabTrader v2 | crypto-folio.com
On a sidenote, the counterparty video is coming along ! Get excited ! Trailer is coming tomorrow or Tuesday Smiley
+1

All this uncertainty and the price goes up go figure

Dear Matt and Halfcab: There is no uncertainty, as assured by the devs including Bitcoin's JG. this will get solved one way or the other. The price movement to 0.005 or 6 or 4 or even 0.02 really means nothing. hang in there and see where we are a year from now. dont think days. think long term.  I know that you are.

Almost surely a multi billion dollar market in the making. No sweat here.

To my untrained eye it appears that the recent buy order volumes are impressive. Lots of folks tend to forget that price means NOTHING without that precious volume.
full member
Activity: 210
Merit: 100
On a sidenote, the counterparty video is coming along ! Get excited ! Trailer is coming tomorrow or Tuesday Smiley
+1

All this uncertainty and the price goes up go figure

Dear Halfcab: There is no uncertainty, as assured by the devs including Bitcoin's JG. this will get solved one way or the other. The price movement to 0.005 or 6 or 4 or even 0.02 really means nothing. hang in there and see where we are a year from now. dont think days. think long term.  I know that you are.
Jump to: