Why do you speak of it as decided that data storage in the Blockchain constitutes abuse? It's abuse because you're forcing others to download/store your data against their free choice. Every full node must download the full blockchain (prunable or not!). Every full node has consented to download and store financial transactions. NOT every full node has consented to store anything else. You need 100% consensus for this, not merely some subset (ie, not miners; not developers) or even a majority. Furthermore, everyone is free to store data that isn't in the blockchain. There is nothing to be gained by putting it in the blockchain except that you force it on those who don't want it. Explain how this is anything but abuse... First of all, Counterparty transactions are financial transactions. Second, every full node has consented to download and store the Bitcoin blockchain, no less. That is, transactions that accord to the Bitcoin protocol, which Counterparty transactions obviously do. Satoshi imbedded a political message in the Genesis Block, for Christ's sake... You have a much narrower view of the possible use cases for Bitcoin than do others. (See what Peter Todd wrote above.) CheckMultiSig is quite clearly intended for ECDSA public keys, not arbitrary data. It should be no surprise that using an operation for something other than its intended purpose has negative, perhaps unintended or unknown consequences. Counterparty transactions are not "according to the bitcoin protocol", they slip through because it never expected that the feature be used in that way. "It works by accident" or "it works because it is difficult to prevent" does not imply good design or the right way of doing things. By your reasoning, Bitcoin should never be used for anything new, ever.
No. It is quite easy to extend the bitcoin protocol. It has been done many times. See the BIP process. The community agrees and the protocol is updated. But that was apparently not the path chosen... counterparty clearly uses a feature (CheckMultiSig) in a fashion for which software was not designed. It is silly to pretend that full nodes "consented" to an unintended use. |
|
|
|
No, it is a lack of understanding how bitcoin works. Peter Todd's proposal suggests not relaying bare multisig transactions, and I wrote the code to do that: https://github.com/jgarzik/bitcoin/tree/bare-multisig"Non-standard" means "most nodes probably won't relay your transaction" but nothing more than that. No protocol change or fork. Miners are free to continue to put such transactions in blocks, assuming that they receive the transactions somehow. |
|
|
|
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, False. There is no protocol change being proposed. |
|
|
|
|
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.
|
|
|
|
Now, I am just a disinterested observer here (with investments in Bitcoin and all major 2.0 cryptos) so I don't speak for anybody but myself here; but it seems to me that Counterparty has Bitcoin over a barrel somewhat, especially with respect to the unspent outputs, which would be quite difficult to selectively block on the Bitcoin end. It would quickly turn into a cat and mouse game. Bitcoin could implement code to detect and block XCP transactions, but XCP changes a few parameters and re-launches a week later to get around it, which causes Bitcoin to respond, which causes a new change in XCP, etc. ad nauseum. I don't think that anybody wants that.
No, it is trivial to block 100% of them. A proposal to do just that appeared on the bitcoin-development mailing list yesterday from Peter Todd. This proposed change would relay zero transactions with multisig outputs. Most of the world is moving to P2SH for multisig, leaving the remaining "bare multisig" users mastercoin, counterparty, etc. Isn't Peter Todd working on Mastercoin? Why would he propose that? Think about it. Mastercoin is a competitor to Counterparty. Mastercoin is already aware of, and working on solving this storage-in-multisig problem.
Peter Todd's proposal simultaneously (a) benefits Mastercoin, (b) disadvantages Counterparty, and (c) presents a proposal that portions of the developer and mining community already find agreeable.
Edit: retracted, based on Peter's recent posting. |
|
|
|
From the perspective of counterparty and the overall bitcoin community, - The criticism is not against counterparty, but just One Flaw in the system
- There was zero consultation on the design with the wider community before the "on" switch was flipped
- This flaw --network-critical database used for raw data storage-- was well known before Counterparty began life. You could have avoided this problem with communication.
- Existing designs are known to be less abusive to the network, and do not store data in that key database
It is perfectly possible to run counterparty without this flaw. |
|
|
|
So the question becomes: Should we let people store data in multisig transactions or provide a cleaner way to do it?
A less abusive way was already provided. With OP_RETURN, the data is still in the blockchain, but at least it is not in the UTXO database of unspent outputs like Generation-1 mastercoin/counterparty designs. |
|
|
|
Now, I am just a disinterested observer here (with investments in Bitcoin and all major 2.0 cryptos) so I don't speak for anybody but myself here; but it seems to me that Counterparty has Bitcoin over a barrel somewhat, especially with respect to the unspent outputs, which would be quite difficult to selectively block on the Bitcoin end. It would quickly turn into a cat and mouse game. Bitcoin could implement code to detect and block XCP transactions, but XCP changes a few parameters and re-launches a week later to get around it, which causes Bitcoin to respond, which causes a new change in XCP, etc. ad nauseum. I don't think that anybody wants that.
No, it is trivial to block 100% of them. A proposal to do just that appeared on the bitcoin-development mailing list yesterday from Peter Todd. This proposed change would relay zero transactions with multisig outputs. Most of the world is moving to P2SH for multisig, leaving the remaining "bare multisig" users mastercoin, counterparty, etc. |
|
|
|
+1 for Common Sense
When you really think about it in a global way, storing data in a second blockchain is even more wasteful.
Imagine these two future cases:
Scenario 1: Bitcoin + Counterparty
Scenario 2: Bitcoin + BitcoinLikeSecondChain + Counterparty
Scenario #2 will always use up more data globally than #1 because we have to add in the second chain + its overheads.
Scenario #2 makes all parties (Bitcoin, BitcoindSecondChain, and Counterparty) a little less secured.
Why have Counterparty/metaprotocols running on top of a second chain when it's even simpler to integrate directly into the chain like some of the Bitcoin competitors? Why even have OP_RETURN? Why even have script if we really want to save every bit of space?
Counterparty is just tiny writings in the margins of the Bitcoin book. Reducing the margin to 40 bytes and advocating that all metaprotocols write to more books is just encouraging more wasted resources for everyone on the planet -- just so we might save up a few bytes in one book.
Allowing just enough room in OP_RETURN for a hash is like leaving enough room for Fermat to write down one last equation when that one equation could have led to another, and another in a chain of discoveries. It makes sense that a little more room for writing in the margin will make the Bitcoin book more valuable for everyone NOW before the new competitions come.
Please allow some room in the margins instead of encouraging metaprotocols to waste more trees by starting more useless books.
It is called a free ride. Given that the overwhelming majority -- >90% -- application for the bitcoin blockchain is currency use, using full nodes as dumb data storage terminals is simply abusing an all-volunteer network resource. The network replicates transaction data, so why not come along for a free ride? Rather than engage the existing community, mastercoin and counterparty simply flipped an "on" switch and started using bitcoin P2P nodes as unwanted data stores. An unspent transaction output was never meant to be used as arbitrary data storage. The fact that it can be abused as such does not make it right, or remotely efficient, or the best solution. The UTXO (unspent transaction output) database is the entire network's fast access database. Every single node needs that database to be as small as possible, for best processing of network transactions. Encoding arbitrary data into unspent outputs is network-wide abuse, plain and simple. The entire network bears the cost. |
|
|
|
|
The rough standard is an update every 3 months or so, out of an over-abundance of caution.
|
|
|
|
Does Bitcoin Core 0.9.0 support (recognize) newer bootstrap data, beyond 279000 blocks?
All bitcoin versions recognize any valid block. If you build your own bootstrap.dat, it can go beyond 279000 blocks, yes. |
|
|
|
To date, I've not seen a blockchain data dumping scheme that could not be securely replaced with a simple hash. You don't need to store data in the blockchain. That is purely intellectual laziness. Timestamping hash(data) is just as secure, while more efficient. Furthermore, a secondary chain can be provably pegged to bitcoin: http://sourceforge.net/p/bitcoin/mailman/message/32108143/ |
|
|
|
|
Yes, "moar please"! Seeding is very helpful on release day, of all days.
|
|
|
|
It's not built and multi-verified yet. You are just seeing a release tag. The release announcement will be posted after binaries are built by multiple parties (gitian), cross-verified, and tested. |
|
|
|
|
It seems like pasting from the OP confuses PGP.
|
|
|
|
As a feature request, it would be useful to have the ability to lock all outputs except for a given list of outputs. That would make it easy to send from a specific output bypassing the usual coin selection logic.
If you need to send from a specific output, easiest to use coin control or raw transaction API. |
|
|
|
This is a longstanding problem with bitcoin -- transactions hang out in limbo until confirmed, possibly forever. And just as longstanding is my proposal to fix it -- expire transactions out of the memory pool after 1-2 days. Clients are built to resend. They may choose to not resend at that point. There is now a pull req that accomplishes this: https://github.com/bitcoin/bitcoin/pull/3753 |
|
|
|
|
Show Posts
