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

[utopianfuture]

People are looking at the situation as saying "Bitcoin will always be big because it already won" but what isn't appreciated is that in open source, the competition never ends because there is no lock-in.

That's where our views differ.

I have no doubt Bitcoin will become really massive no matter the attitude of BTC core developpers. Network effect and infrastructure is everything, you can't beat Winklevoss and Silbert ETF, hardware wallet and 40 petahash with just useful new features. And even if that put BTC developper in a lamentable power position, it's still a good thing because if BTC is one day overcome by an altcoin, then the whole concept of digital scarity would be fuck up.

Also Open transaction will enable a lot of stuff that will add Counterparty-like feature on top of Bitcoin, no matter the amount of energy Bitcoin developper put into screwing Satoshi's vision.

It's sad but I think the truth is Counterparty have a lot more to lose than Bitcoin if there would be a schism between XCP and BTC.

Bitcoin capitalization is tiny compared to the vast potential of this industry and Winklevoss and Silbert are basically nothing in the hierarchy of the financial world. Many real sharks in the world of finance are looking for possible alternatives in decentralized solution industries and I doubt they would be willingly come in to the position where Winklevoss brother could happily dump upon their heads. Make something worthwhile and differentiate yourself enough from the army of clones, you will see how receptive other big guys are to you. Etherum is a good example.

There is very litter lock-in effect with Bitcoin compared to things like Facebook, Whatsapp, Twitter etc. Users could easily move from one crypto to another if they want to. Many people idolize Bitcoin when comparing Bitcoin to Internet which imo is gravely mistaken. Bictoin protocol is not the Internet protocol, blockchain tech protocol is and Bitcoin just happens to be the first application of the protocol. Don't idolize Bitcoin and mistake it with blockchain protocol which is the essence of decentralized movement while Bitcoin is not. XCP should move on and grow where its tech can prosper the most.      

[1714840507]

1714840507

[1714840507]

1714840507

[1714840507]

1714840507

[1714840507]

1714840507

[1714840507]

1714840507

[1714840507]

1714840507

[zbx]

Hey, there are a lot of threads over on the Bitcoin Subreddit talking/lamenting about recent and ongoing failures of centralized exchanges... Would people here help me watch the Subreddit and mention Counterparty where it's appropriate? Just to point people in the right direction. I'm sure that a lot of the readers there don't know about Counterparty and they'd be interested to learn that there's another real option to MtGox, Vircurex, and so on. We're obviously really close to the release of Counterwallet on Mainnet, and when that happens, Counterparty's distributed exchange will be really easy to use. Anyone will be able to trade BTC, XCP, USD vouchers, etc. without any risk of the trading platform suddenly going under, freezing withdrawals, running away with their money, or whatever.

[Matt Y]

^^ I've found a couple threads and commented where appropriate. More technically savvy people will have more luck, though.

This is the most relevant: http://www.reddit.com/r/Bitcoin/comments/216d8e/coin_secrets_op_return_metadata_in_the_bitcoin/

And here: http://www.reddit.com/r/Bitcoin/comments/216ajq/this_is_fucking_ridiculous/

[buaichiyuwh]

maybe we can just use pos

[nakaone]

a solution within the bitcoin protocol would be much better, the charme of xcp and msc is the network security and that you do not need to move your bitcoins on any exchange to get them

[Matt Y]

Why Counterparty used proof-of-burn to initially distribute XCP

https://www.counterparty.co/why-proof-of-burn/

There seems to be a lot of confusion about this outside of the Counterparty community. This blog post should help clear up any confusion by providing us with an easy place to direct people who have questions related to proof-of-burn.

[jgarzik]

Do not paint all criticism with a broad brush. Not all critics have the same experience or point of view.

I was the original author of the 80-byte OP_RETURN: https://github.com/bitcoin/bitcoin/pull/2738

I have been working in this space for years, and have already created in-blockchain software, and directly observed problems in the field from in-chain solutions, years ago. See https://github.com/jgarzik/pybond and https://github.com/jgarzik/smartcoin.

The Bitcoin Improvement Proposal process has also been around for years, and new proposals are added frequently: https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposals

It is not my job to hold everyone's hand, be your nanny, and fix everybody's software.  If you like decentralized development, you should know that.

There is a demonstrable engineering flaw.  CheckMultiSig() is built for ECDSA public keys.  Counterparty is not storing ECDSA public keys there.  When you use a system outside its design specifications, there are bound to be negative side effects.

From this we may conclude, contra to the hyperventilating on this thread,

• I'm a supporter of 80-byte OP_RETURN -- I wrote the damn thing
• I'm well versed in in-chain data projects -- I wrote some myself
• Counterparty went outside the bitcoin design specification in their use of CheckMultiSig
• This feature may be going away anyway, for other reasons
• Plenty of innovation is going on in the bitcoin space.  It is not "censorship" to point out all the parties who are innovating, while managing to not exploit bitcoin design quirks

To repeat (admittedly it is getting tiresome), do not paint all criticism with a broad brush, and not all critics have the same experience or point of view.

[qtgwith]

I'm soliciting feedback on a forthcoming paper wallet design for Counterparty. Functionality will be identical to my Bitcoin paper wallet design of course: BIP38, provide your own random data (roll dice, etc.) plus ability to scan QR codes with your wallet and such.


You can print out this draft design here:


https://bitcoinpaperwallet.com/bitcoinpaperwallet/generate-wallet.html?design=counterparty

https://forums.counterparty.co/index.php?topic=199.msg1559;topicseen#msg1559

I call this a draft because until the more or less "official" Counterparty logo/branding is announced, I need to keep the logos / colors flexible. However at this point I'm very interested to hear what anyone thinks about how a Counterparty paper wallet should be *different* from a Bitcoin paper wallet. For example, maybe the reverse side instructions should be significantly different. Maybe the reverse side "register" shouldn't just list amount/date, but also "asset" and "description"?


Or I wonder if it makes more sense to leave the look and feel of a Counterparty wallet essentially identical to a Bitcoin paper wallet, only adding a "XCP" logo or something to indicate that XCP are stored in this wallet as well?

Very good!Cool!

Cooperation please between BTC and XCP!

[PhantomPhreak]

Do not paint all criticism with a broad brush. Not all critics have the same experience or point of view.

I was the original author of the 80-byte OP_RETURN: https://github.com/bitcoin/bitcoin/pull/2738

I have been working in this space for years, and have already created in-blockchain software, and directly observed problems in the field from in-chain solutions, years ago. See https://github.com/jgarzik/pybond and https://github.com/jgarzik/smartcoin.

The Bitcoin Improvement Proposal process has also been around for years, and new proposals are added frequently: https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposals

It is not my job to hold everyone's hand, be your nanny, and fix everybody's software.  If you like decentralized development, you should know that.

There is a demonstrable engineering flaw.  CheckMultiSig() is built for ECDSA public keys.  Counterparty is not storing ECDSA public keys there.  When you use a system outside its design specifications, there are bound to be negative side effects.

From this we may conclude, contra to the hyperventilating on this thread,

• I'm a supporter of 80-byte OP_RETURN -- I wrote the damn thing
• I'm well versed in in-chain data projects -- I wrote some myself
• Counterparty went outside the bitcoin design specification in their use of CheckMultiSig
• This feature may be going away anyway, for other reasons
• Plenty of innovation is going on in the bitcoin space.  It is not "censorship" to point out all the parties who are innovating, while managing to not exploit bitcoin design quirks

To repeat (admittedly it is getting tiresome), do not paint all criticism with a broad brush, and not all critics have the same experience or point of view.

Thank you for making this post. I agree with everything in it.

What do you suggest that we do going forward? Unfortunately, I don't think that using a side-chain (with hashes of Counterparty messages in Bitcoin), or a chain with merged mining, is really an option for us, because of the security issues and the implementation-complexity involved. I also don't think that approaching miners individually is a viable option. It's too important to this project that it be built upon standard, default settings of Bitcoind. We can't let the relaying of Counterparty transactions depend on promises that particular mining pools will apply a certain patch to their copies of Bitcoind regularly. None of those options is at all worth the risk.

Counterparty was designed wholly around 80-byte OP_RETURN, not CheckMultiSig, which we started using only as a temporary measure and which we'd be glad to stop using completely. Would you support raising the size limit on OP_RETURN back to 80 bytes, so that we may do so directly? And would you support allowing an OP_RETURN output of arbitrary size, with an appropriate fee structure? (See this post.) I'm sure that the latter option is best for both Bitcoin and Counterparty in the long run.

[BitThink]

Do not paint all criticism with a broad brush. Not all critics have the same experience or point of view.

I was the original author of the 80-byte OP_RETURN: https://github.com/bitcoin/bitcoin/pull/2738

I have been working in this space for years, and have already created in-blockchain software, and directly observed problems in the field from in-chain solutions, years ago. See https://github.com/jgarzik/pybond and https://github.com/jgarzik/smartcoin.

The Bitcoin Improvement Proposal process has also been around for years, and new proposals are added frequently: https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposals

It is not my job to hold everyone's hand, be your nanny, and fix everybody's software.  If you like decentralized development, you should know that.

There is a demonstrable engineering flaw.  CheckMultiSig() is built for ECDSA public keys.  Counterparty is not storing ECDSA public keys there.  When you use a system outside its design specifications, there are bound to be negative side effects.

From this we may conclude, contra to the hyperventilating on this thread,

• I'm a supporter of 80-byte OP_RETURN -- I wrote the damn thing
• I'm well versed in in-chain data projects -- I wrote some myself
• Counterparty went outside the bitcoin design specification in their use of CheckMultiSig
• This feature may be going away anyway, for other reasons
• Plenty of innovation is going on in the bitcoin space.  It is not "censorship" to point out all the parties who are innovating, while managing to not exploit bitcoin design quirks

To repeat (admittedly it is getting tiresome), do not paint all criticism with a broad brush, and not all critics have the same experience or point of view.

Thanks a lot for the opinion from another Core Dev of Bitcoin.

To be fair, Counterparty plans to use OP_RETURN from the beginning, and using CheckMultiSig is just a workaround added just before the official release because nobody knew when the core 9.0 would be out and whether OP_RETURN will be added.

Now imagine Counterparty did not add CheckMultiSig and kept waiting for OP_RETURN added in this core and now suddenly find that OP_RETURN has been reduced to 40 bytes at the last minute.

If we calm down and it will not be difficult to understand that the devs of Counterparty don't want to use CheckMultiSig at all. They and all the community are looking forward to removing CheckMultiSig and using OP_RETURN for the good of bitcoin and, to be honest, also reducing the trading fees caused by CheckMultiSig.

Nobody is arguing that Counterparty has to use checkmultisig. Current situation is that, the functionalities are designed for 80 bytes OP_RETURN. With only 40 bytes OP_RETURN, counterparty are forced to keep using checkmultisig against the benefit of both communities.

[reader31]

I'm soliciting feedback on a forthcoming paper wallet design for Counterparty. Functionality will be identical to my Bitcoin paper wallet design of course: BIP38, provide your own random data (roll dice, etc.) plus ability to scan QR codes with your wallet and such.


You can print out this draft design here:


https://bitcoinpaperwallet.com/bitcoinpaperwallet/generate-wallet.html?design=counterparty


I call this a draft because until the more or less "official" Counterparty logo/branding is announced, I need to keep the logos / colors flexible. However at this point I'm very interested to hear what anyone thinks about how a Counterparty paper wallet should be *different* from a Bitcoin paper wallet. For example, maybe the reverse side instructions should be significantly different. Maybe the reverse side "register" shouldn't just list amount/date, but also "asset" and "description"?


Or I wonder if it makes more sense to leave the look and feel of a Counterparty wallet essentially identical to a Bitcoin paper wallet, only adding a "XCP" logo or something to indicate that XCP are stored in this wallet as well?

Very good!Cool!

Cooperation please between BTC and XCP!

Great Job! Love where this is going

[sherlock421]

i suggest burn LTC once again,then XCP team can burn more ltc,you can sell this buring for R & D funding，and if bitcoin have problem,then can use LTC block chain for Reduce risk

[freedomfighter]

People are looking at the situation as saying "Bitcoin will always be big because it already won" but what isn't appreciated is that in open source, the competition never ends because there is no lock-in.

That's where our views differ.

I have no doubt Bitcoin will become really massive no matter the attitude of BTC core developpers. Network effect and infrastructure are everything, you can't beat Winklevoss and Silbert ETF, hardware wallet and 40 petahash with just useful new features. And even if that put BTC developper in a very despicable position of power, it's still a good thing because would BTC one day be overcomed by an altcoin, then the whole concept of digital scarity would be fuck up.

Also Open Transaction will enable a lot of stuff that will add Counterparty-like features on top of Bitcoin, that will happen no matter the amount of energy Bitcoin developpers put into screwing Satoshi's vision.

It's sad but I think the truth is Counterparty have a lot more to lose than Bitcoin if there would be a schism between XCP and BTC.

+1 to the above.

+1 to JG's post. no one should be painting the BTC core dev's in a wide brush. I was very sad to see some of JR's posts but am not taking him to represent the entire BTC community from which I and all of you are also part (even if one has 1 10 or 10000 btc's).

I have been around 100 companies and valuations in the VC arena for 20 years, assisting them at various stages from pre-seed to IPOs and 2nd offerings.

Based on my experience: At this juncture it is actually the first mover advantage and its benefits mainly in network security and in being proven through endless attacks that gives BTC the best chance to be the biggest and brightest not only now but in the future (not to say that there won't be more alternatives). Smart money is now building the BTC eco-system and is bringing numerous applications that will drive adaptation and penetration better. Smart money will feel much safer building around the "monster"(in positive sense) of the space and only engage in new project in limited scopes at this juncture. This is meaningful in my humbled opinion.

While it is true that market capitalization @ $7Bilion is a fraction of the potential for the entire space, BTC was and in my opinion will be the arrowhead in years to come and in bringing the space to the TRILLIONS.

NXT and ETH and others have long ways to go and unfortunately many attacks to overcome. I wish them all the best success but they will take time.  

This is why I am a firm believer in 1) CP being on top of the BTC blockchain 2) in it adding a great value to BTC and contributing to its penetration 3) that the core devs from both projects must find the common ground above and behind the wild kid jr's attitude. "

4) Peter todd's wise words in one of the posts above said it the best: "but remember our real competition isn't each other, it's enormously larger field of centralized finance. I strongly believe that we have far more to gain by working with each other and growing the tiny field of decentralized finance in general then we have to gain by pointless in-fighting.

BTW: I have no doubt that creative solutions will be found for reducing the TPS issue with BTC in the future. In fact, I have seen a presentation in one of the conferences proposing a 50% increase in speed (above my head how) by credible PHDs and researchers. It will come.

[sherlock421]

http://www.zjcad.com.cn/images/post1.jpghow about this ,it was used

[IamNotSure]

About the OP_RETURN 40 vs 80. Pardon me if this proposal is noobish, but what about using 2 (or more) parallel transactions (broadcasted at the same time) each within the current 40 limit with different payloads. Then the CP parser would combine them afterwards.

[halfcab123]

About the OP_RETURN 40 vs 80. Pardon me if this proposal is noobish, but what about using 2 (or more) parallel transactions (broadcasted at the same time) each within the current 40 limit with different payloads. Then the CP parser would combine them afterwards.

Double the transactions fees ? No guarantee they are confirmed at the same time or even the same block ?

[dexX7]

Hey guys,

so to my understanding the reason for the idea of making multisig transactions non-standard was the high amount of unspent outputs that were created by data-storage transactions. I want to put this into some perspective:



(https://i.imgur.com/c9mpd8h.png)

I did not evaluate how many unspent outputs were created by all multisig outputs, because I'm unable to do so efficiently, but here are some observations nevertheless:

Out of 35.508.561 multisig outputs ever seen on the blockchain XCP and MSC account for 5.192 multisig outputs. That's about 0.000146 %.
Out of 9.819.223 unspent outputs at the very moment (RPC: gettxoutsetinfo) the amount of unspent XCP and MSC multisig outputs is 3.226. That's about 0.000329 %.

In the case one wants to run some tests on this data: multisig-usage.rar (format: "txid vout rawtxhex" -- file size is about 8 MB, but be aware that multisig-all-full.txt is over 1.4 GB unpacked!)


Please don't get me wrong, I do not say that we don't contribute to a higher utxo set and a general statement about the usage of multisig transactions is more difficult to make, because I have no idea how to evaluate the other 99.999%. My above used criteria were: "has an standard output to Exodus address and multisig output" and "has an multisig output with XCP magic bytes". If you have any idea, go ahead.

[Peter Todd]

Please don't get me wrong, I do not say that we don't contribute to a higher utxo set and a general statement about the usage of multisig transactions is more difficult to make, because I have no idea how to evaluate the other 99.999%. My above used criteria were: "has an standard output to Exodus address and multisig output" and "has an multisig output with XCP magic bytes". If you have any idea, go ahead.

Even with multisig neither Counterparty or Mastecoin need to be contributing to the UTXO set: just have one of the pubkeys be valid, with a secret key known to the user, and have their wallet software spend that txout the next time it needs to spend some money.

You're transactions will be cheaper overall too. Again, this is another reason why you want to do an arbitrary encoding strategy. I'm rather solidly booked for the next two weeks, but we can talk about implementing that later as an upgrade.

[dexX7]

Even with multisig neither Counterparty or Mastecoin need to be contributing to the UTXO set: just have one of the pubkeys be valid, with a secret key known to the user, and have their wallet software spend that txout the next time it needs to spend some money.

Well yes. That's why I don't understand the "utxo bloat" argument - at least not completely. Assuming each multisig recipient is counted as utxo and say for each redeemed XCP/MSC transaction a new one is spawned, then one could say the total amount of utxo is indeed increased due to the one or two additional multisig recipients. But a) is this the case? (I assume yes) and b) is this the case, if pubkeys are created in a way that they do not form a valid ECDSA point? Anything with a length between 33 and 65 byte seems to be accepted as recipient.

Redeeming multisig outputs is fun, by the way!

[amincd]

Whitelisting particular upper layer protocols is ridiculous. Bitcoin should be a proper protocol, not a committee run closed network that you need to file an application with to get access to. Bitcoin the protocol should be absolutely neutral, and no group of developers, no matter how important and respected, should be in a position to determine which transaction types are permitted.

The real problem here is that Bitcoin is still unfinished, and needs to change, and the only way that we know of to change a protocol is to centralize around a group of developers, who can make serious mistakes like backtracking on their stated intention to standardize 80 byte OP_RETURN transactions.

Until we find a solution to this problem of centralized development, we need to do whatever we can to steer the core developers to supporting upper layer protocols like Counterparty and Mastercoin. ULPs are the future of Bitcoin. The greatest potential of bitcoin, as a unit of currency, is to be the currency used to pay transaction fees for the world's peer-to-peer digital transactions, and that can only happen if ULPs are built on top of BTC.