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

 

Didn't someone just say that there was a proposal to remove multisig

False. There is no protocol change being proposed.

I guess technically no one has to choose to upgrade right ?

Whether you think there are better implementations than the current one is not the problem, but rather that you are making a protocol change for something that miners are, by design, supposed to decide for themselves, and acting autocratically over Bitcoin.

+1

If anything I hope I've given the impression that I think all these "Blockchain 2.0" projects probably have terrible flaws in them right now. But flaws can be fixed, either by upgrades or starting over; what I care about is that something worthwhile is bound to emerge in the end. In the meantime I can bring value to these projects - that is earn my pay - by being independent and objective enough to give good advice and do good research. Which incidentally I think the Bitcoin developers are currently failing at themselves because they're too focused on their narrow use-case for Bitcoin as cheap transactions - take this advice to just resort to insecure centralization and/or easily attacked DHT's:


Or for that matter the discussion around my post on Decentralized digital asset exchange with honest pricing and market depth.

Edit: To be clear, all this discussion about moving things like Counterparty to different independently or merge-mined blockchains as a "solution" to the "problem" of adding data to the blockchain is either mistaken or downright deceptive. Fact is these systems all get much better security by being embedded rather than independent. Decentralized consensus system security is a game of strength in numbers, and you want to be making use of the largest system you can afford. Merge-mining looks like a nice way to achieve that, but in reality just leaves you vulnerable to zero-marginal-cost attacks until you get the support of a large % of the total hashing power. A real world example of this is how Luke-Jr used Eligius to attack the merge-mined alt Coiledcoin. That leaves us with embedded consensus systems, and fortunately with Bitcoin only explicit blacklists have any hope of censoring their transactions rather than just making them a bit more expensive. (perhaps the even stronger requirement for explicit whitelists if my timelock crypto scheme can be made practical)

P2SH multisig can replace bare multisig, by moving the data stored in outputs to the inputs.

This also avoids bloating the UTXO database, the key database that is queried multiple times per second by all full nodes on the network.

Solutions have existed for years.  UTXO database is not the place for data storage.  It impacts everyone, network-wide.  It impacts the real-time performance of the network.

This is the point right here. *Of course* Bitcoin was never intended to store and transmit Counterparty tx data. Counterparty hadn't been invented yet! That's what makes all great technology so amazing: when people take it and use it for things you never even dreamed of.

You realize I also work for Counterparty. You also know I CC'd them on my email where I proposed getting rid of bare CHECKMULTISIG to the bitcoin-security mailing list with regard to the sigop vulnerability I responsibly disclosed. (which I note that Gavin and others disclosed publicly on IRC a few hours later rather than responsibly fixing it) I notified Counterparty specifically to make sure they got the heads up that this may be an issue for them so they could upgrade their protocol. This is easily done - they might find my recent post on Embedded consensus system upgrade procedures useful. More generally re: blocking they might be interested in my research, such as Censorship-resistance via timelock crypto for embedded consensus systems and Mastercoin's way of embedding data in what looks to be valid pubkeys, among other things. FWIW my usual way of communicating to the Mastercoin developers has been to write up a public document so that everyone gets access to the results of my work; my agreement with everyone I work for is that for all IP both parties have the right to use the IP however they see fit, including public release.

My position with regard to competitors in the decentralized finance space is as follows:

http://mastercointalk.org/index.php?topic=155.msg466#msg466

thanks for clearing that up 

I don't get Jeff's point here. Even assuming that this is the case, any product of this would have to become public knowledge in the form of source code at some point, to be actually used. At that point, Mastercoin (as an open source project) would have lost their advantage here.

Also, this assertion is questionable as we are working with Peter as well. I don't want to speak for him (and he can correct me if I am wrong here), but he has communicated to us that in the end, his desires lie in moving the technology itself forward over allegiances to any specific implementations of it (for Counterparty OR Mastercoin).

If we ever absolutely had to move to a different blockchain, the protocol would just freeze, save and then transfer balances over. The currencies of Counterparty, i.e. the balances, are independent of the protocol's transport layer.

https://i.imgur.com/KZAZNzv.jpg

I just had an hypothetical  idea in an aplocalyptic situation if XCP needed to relocate, if XCP was to move to a new database, it would need to create a completely new currency, meaning more units of value would need to burned (if using proof of burn), that would be unfair to everyone holding XCP and burned/traded . I think the best thing to do would be a 'proof of swap'  (hope i coin this term), in which the XCP can be swapped for the new currency which doesn;t rely on multi sig on this database, and thats the proof issuance,

If the desire is for these projects to use OP_RETURN, as it seems you are stating here, then why personally introduce a pull request (https://github.com/bitcoin/bitcoin/pull/3737) to reduce its size down to 40 bytes, which makes it that much less useful to the projects that were to be some of its biggest users in the first place? And then, for justification of the change, provide reasons that have nothing to do with how these projects are actually storing data (i.e. we don't use hashes and side-chains for reasons we explained earlier).

The blockchain itself would be most benefited by the use of OP_RETURN here, but it seems to me at least that there is a disconnect in the logic of why the size was halved among some, pointing to theoretical reasons as justification on why that would be a good idea instead of the *actual real world current uses*. While the optimal solution in your mind for Counterparty and others may be to move to their own side chains and store hashes in the Bitcoin blockchain using OP_RETURN, you have to understand that doing so is highly complex, rife with potential security issues, and that the only evidence supporting this is (as far as I know) essentially a theoretical-type thread on the Bitcoin developers mailing list. This would be a bit like me telling the Bitcoin devs that Bitcoin should move to using GHOST (https://eprint.iacr.org/2013/881.pdf) immediately as it's technically the optimal solution over the longer block times today. While the latter could be argued to be the case, it is a proposal that has not been fully vetted in the real world, and would introduce major protocol-level changes that could cause potential security and usability problems.

Jeff, our intentions are be good stewards of the blockchain, while accomplishing our goals of adding valuable financial functionality to Bitcoin in a stable, scalable and secure manner. This whole OP_RETURN thing is like saying you have a great feature that would solve a need, but that no one should actually use it.

Thanks Jeff. This is very helpful data. I was not aware of Peter's proposal and I have emailed him and asked him to respond here. It appears that Peter is also employed by Counterparty so he may be able to share some further insights about his proposal and how Counterparty may participate and add to the interests of both the bitcoin developer and bitcoin mining communities. It's in our interest to support proposals that everyone finds agreeable.

I believe the post Jeff is referring to is this one: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth

However, anyone please correct me if that's the wrong thread?

EDIT: Peter's follow-up reply is here: https://bitcointalksearch.org/topic/m.5824079

Isn't Peter Todd also employed by Counterparty? https://www.counterparty.co/sergio-lerner-peter-todd/

Maybe the devs at Counterparty should learn Peter's proposal and we explore how we might participate to benefit alongside Mastercoin?

+1.00000000