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

I hope you can appreciate that this is a bit if a chicken and egg situation. It's not like Counterparty intended to use multisig in perpetuity. Much older responses in the thread will show how eagerly we waited for 0.9 so that OP_RETURN can be used. So you can understand the disappointment when we come to know that it does not provide enough space for our needs. It also means that our current implementation will have to continue for the foreseeable future.

More disturbing is Peter Todd's identification of a problem with CHECKMULTISIG, if the proposal is indeed accepted, a more viable solution needs to be found not just for Counterparty but for all other such projects that depend on the blockchain as a transport layer.

To this end, I think the Bitcoin core developers must decide if these innovations are of any benefit to bitcoin itself and if the answer is yes then help us find a way for make this work while addressing all your concerns.

I also know that your response to this perhaps will be that Counterparty store transactions off the blockchain and only store the reference hash in OP_RETURN. It helps keep the size of the blockchain to the absolute minimum.

The alternate proposal is that the size of data stored in OP_RETURN should result in increased mining fees. The more space you use the more pay for that transaction. (At least that's what I understood from the thread). Can you please give the thread your opinion on such a solution?

Incorrect.  Re-read the quoted bullet point #1.  Additionally, one post in this thread contained a sentence listing 4+ specific technical solutions.

But I shouldn't have to spoon-feed solutions, to get someone else to fix their system.

Engage the community and miners, listen to feedback and Counterparty can get what it wants.  There is plenty of innovation going on right now in the bitcoin space and it is ludicrous to suggest otherwise.  The bitcoin protocol is easily extensible.  You do not have to abuse a feature meant for ECDSA public keys to do what needs to be done.

Re-read the quoted post...  "Right, the exchange rate between domains and bitcoins would float. ... A longer interval than 10 minutes would be appropriate for BitDNS."

That implies a separate chain, a la namecoin, because "longer..than 10 minutes" would be a hard-fork protocol change for bitcoin.  And then of course

"It will be much easier if you can freely use all the space you need without worrying about paying fees for expensive space in Bitcoin's chain"

Which is clearly referring to using space not in Bitcoin's chain.

But we still haven't heard any suggestions from you all on how we might do it properly.

Few (I didn't say none) of those arguments pass the smell test.

• OP_RETURN and 40 vs 80 bytes:  If the miners agree with you, you don't have to care what the network relays.  Has Counterparty directly approached miners, to get them to mine 80-byte OP_RETURN transactions?  What was the response?  If the miners agree, great, let's do it.  If the miners don't agree, there is no point supporting it in Bitcoin Core software.
• "core devs are censoring and killing innovation!"   Counterparty is very clearly misusing a feature intended for ECDSA public keys, in a manner that very clearly results in harm to the overall network, short and long term.  Other people/companies/projects are extending the bitcoin protocol and not meeting the same resistance.
• To repeat earlier posts, my criticism is not about counterparty in general, just this ONE CheckMultiSig flaw.  Fix that, and my criticism is gone.
• As Peter Todd has noted, CheckMultiSig has other problems also.  It may go away regardless.

Please do not paint all Counterparty criticism with a broad brush.  My opinions are my own, and in particular I do not agree with all of Luke-Jr's points or point of view.

There are plenty of ways to innovate and extend the bitcoin protocol.  People are doing this every day.

It is always a mistake to base an entire engineering system on a subtle technical quirk that "just happens to work."  Counterparty is stuffing its own data where ECDSA public key data is supposed to go.  That is clearly not the intended use.

Actually, did you know that Satoshi had plans for a decentralized marketplace from day 1, built right into bitcoin.exe (when it was still windows only)? Evidence is in v0.1 of the Bitcoin source code.

as far as i concern;

we shall build our own blockchain and distribute "shares" in terms of XCP hold by all xcpers at certain time. by PoS i mean.

we will feel much more comfortable than any other chains.

JL777 had mentioned some revolutionary codec he might be working on but I guess we need to see what btc devs have to say about compromising here

is possible to take advantage  fuzzy logic or approximate string matching client side or some other mechanism for reducing space which counterparty tx could cram into the 40byte OP_RETURN alone or is it simply not feasible?  I'm guessing the latter otherwise devs would have already looked into it and either done it and dismissed it, just from outsider perspective would be interested in newbie friendly explanation of limitations of the 40byte reduction

Yup as evidenced by satoshis quote I posted

Wow, the attitude of the Bitcoin core developers is the polar opposite of what I would have expected to see here.

Gents, I wonder which of the following responses Satoshi would have been ~most likely~ to give upon learning about the Counterparty project.

Would he have -

A) responded with excitement, and honored that others are building upon his work, done all he could to support the shared goals of both projects? Or would he have -

B) said "this is not what Bitcoin is for, you free-riding parasites!" or "I don't recall seeing a BIP for this, you intellectually lazy mofos!" and thrown the project under a bus?

I wonder if a little of the founding ethos may been lost here.

I think CityGlut noted that Litecoin did not have the metadata space required by Counterparty, correct me if I'm wrong, but we would have to petition the devs to add this functionality. It's really a shame that the Bitcoin Core Devs won't work with us.

Hi. Did you burn 1BTC ? Are you frustrated by having to learn the CLI ? Want to sell me your XCP ? I'll personally give you 4.5BTC per 1,000. or (0.00425BTC/XCP) for anything over 5,000 XCP. Don't know how to send ? Don't worry, I"ll buy your private key from you Will use trusted escrow only. PM ASAP

How like litecoin? I think if bitcoin will go this way and litecoin choose other way and come more friendly for new innovations they can have really good possibility come number one some day. Hope satoshi wake up from dead and come write one liner because todays looks like core dev team think they are gods 

Yes, the first point is a good one. I would still be concerned that the merge mined chain would fall out of favor (a side effect of the low market cap).

I'm not sure about the second point. I'd also have to divert the question to someone who could answer it.

It's funny you and others should say this.

I've been asked by many different people on many different occasions about the longevity of bitcoin (apparently I am the resident bitcoin guy  ).
If you had asked me a year ago I would have said bitcoin was the way of the future. Now I have to honestly tell people, "I'm not so sure if bitcoin will be the defacto crypto currency of the future". There is still the possibility, but not with the current generation of bitcoin developers it seems.

I've found myself repeating to them the fact that the current generation of bitcoin developers seem very conservative and close minded. People find this confusing since they view bitcoin itself as such an innovative concept.
These bitcoin developers treat any proposed change to the "original vision" of bitcoin as an attack on bitcoin itself.
The counterparty devs should have known this before even asking the bitcoin devs to change anything.


Maybe what these devs don't understand is that when you stop growing and innovating you start losing (microsoft vs apple anyone?).

As I understand it XCP is in no danger. They will just continue on with the method they are using now (regardless of how ideal or efficient it may be). The devs certainly won't risk changing their precious original concept just to thwart Counterparty. And if something is changed, we will adapt. Etherium plans to use their own block chain, why can't we? yes its extreme, but the option is there. It would certainly make downloading the blockchain a lot less painful.

Robust because of the hashrate of the network which provides the security. That is most certainly something that can be recreated in time.

No as mentioned before, counter party needs a robust system like bitcoin to operate

There is always the option to create our own protocol (coin,) to build on. One that meets the specific needs of Counterparty improving greatly on Bitcoin, and then allowing 3 - 6 months for the difficulty to get to a point where, security is feasible enough to start running counterpartyd on it; perhaps Counterparty could run on top of XCP, which would be a clone of some other coin that meets our needs or possibly a modded version.

.. the ability to move offchain at will?.. If the company and chain are as one, there is no conflict.