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

[johnybyo]

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 

[halfcab123]

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

[halfcab123]

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 

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.

[ScruffySyrian]

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.

[halfcab123]

Yup as evidenced by satoshis quote I posted

[Anotheranonlol]

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

[halfcab123]

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 reduced 40byte OP_RETURN alone or is it simply not feasible?

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

[dotcoin.info]

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.

[RoxxR]

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.

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.

[jgarzik]

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.

[halfcab123]

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.

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

[jgarzik]

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

The core devs' views seem at odds with the founder's — Opposite ends of the spectrum even. Not only was Satoshi advocating the use of Bitcoin's blockchain to store data, he wanted it cheaper! How about them apples ?

(Quote in reference to BitDNS.)

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.

[jgarzik]

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

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.

[lonsharim]

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.

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?

[miscreanity]

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.

As a miner I fully support exploring any functionality which adds value to Bitcoin, the only request being that introducing it be done in a controlled manner. The risk of increasing OP_RETURN to 80 bytes does not seem to outweigh the potential benefits, especially when multisig might not be prunable.

Of course a lone miner's opinion is unlikely to sway the argument, so what would the dev criteria be -- a major pool supporting the change, Gigavps getting onboard, a certain number of signatures obtained for a petition, etc?

[PhantomPhreak]

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.

It's not enough to have a couple of pools mine our transactions. We need to keep the block time as close to ten minutes as possible.

There are myriad ways of imbedding data in the Bitcoin blockchain. We support two already. We based the architecture of Counterparty on that.

Again, Counterparty was originally designed to use OP_RETURN exclusively, which is obviously the technically superior option. You're 'killing innovation' by supporting arbitrary, very low limits on the amount of data that can be stored in the blockchain properly---i.e. with OP_RETURN. If the limit on the size of OP_RETURN is raised back to 80 bytes, then we'll have no need to use CheckMultiSig outputs the way we are doing now.

[IamNotSure]

As I see it, the best solution is to keep the OP_RETURN size at 40 bytes, for simplicity and compatibility, but to allow multiple OP_RETURN outputs per transaction. There's no reason that 40 bytes of misc. data per transaction is better for Bitcoin than 80, or 120 bytes.
[snip]

Actually what should be done that would - in theory - please both sides of the issue would be to do a patch that makes embedding data in OP_RETURN transactions as expensive as doing so by creating unspendable outputs. Basically what the OP_RETURN payload is just made unlimited (up to the max size of a transaction) but you bump the min fee by the same amount that would have been simply burned in the unspendable output. I'd further recommend that the cost be set slightly less than that amount, to always incentivize using prunable blockchain space rather than unprunable UTXO space. (a legit concern in the current design, although my TXO commitments scheme probably reduces the problem greatly)

I'll do up a pull-req for this.

Wouldn't this solution please everybody ?

[supersuber]

Assets name why can not start with "A"?

[Bellebite2014]

Assets name why can not start with "A"?

You might want to get a dictionary, or learn how to make a proper full sentence first before posting, thanks.

[sparta_cuss]

Assets name why can not start with "A"?

You might want to get a dictionary, or learn how to make a proper full sentence first before posting, thanks.

Don't be a provincial ass, Bellebite. (How's that for a complete, grammatically correct sentence?) Not everyone on this forum is a native English speaker, but their input is significant and valuable.