OP_RETURN can be used to store references to external resources, say for example very long meta transactions that don't fit into 40 byte, an asset contract or whatever. The storage pointed to could be a website which lists something like <hash_used_in_op_return_tx><very_long_message> (for the sake of an example), a side chain or a P2P structure like a DHT. To my knowledge this was discussed several times, but never tested on a broader scale.
You know, an interesting question to ask yourself is if it's totally ok to just embed a hash of the actual data in the blockchain, and rely on the data itself being made available by some DHT or something, why can't Bitcoin itself do that to make blocks smaller and improve scalability? Remember that Bitcoin would work just fine if miners didn't validate transactions if clients implemented client-side validation, as is done in Mastercoin and Counterparty, and to a lesser extent, Colored Coins. What's so special about actually putting those tx's in the block? +1000 awesome point. No, it's not, it's a silly point. Bitcoin includes transactions because it validates the data inside them. Bitcoin clearly does not validate Counterparty data. I am free to include Counterparty data in my own transactions at any time. I am free to spend Counterparty coins to myself at any time, etc. Bitcoin doesn't care. The level of validation performed by the bitcoin network is the same, whether full counterparty data or a simple hash is in the blockchain. |
|
|
|
$730 shipping to north america... Come on...
Agree that is incredibly expensive -- and it's also probably accurate for X-day shipping from Israel to N.A. For perspective, it cost me over $800 to ship two Avalon miners from Atlanta, GA to Portland, OR, via UPS 2-day air. Fuel and other surcharges really make shipping heavy stuff like miners insanely expensive these days. |
|
|
|
|
My demo SP10 Dawson was switched from "silent" to "normal" mode.
New numbers @ 110V: 1395 Watts, 11.56 Amps, 1461.15 GH/s
Amusingly, the noise level did not change much.
|
|
|
|
Yeah, it is pretty darn loud, even in silent mode  It produces more noise in silent mode than my hashfast, knc, avalon and bfl miners. |
|
|
|
|
My SP10 Dawson demo miner just arrived. Will blog and post photos and screenshots tomorrow or so.
Due to power limitations at my personal residence, the miner is running in "silent" mode, reducing power usage and hash performance.
On my US 110V 20A circuit, I see 1165 Watts, 9.7 Amps, 1368.225 Gh/s in silent mode.
Watts/Amps numbers produced via Kill-A-Watt.
|
|
|
|
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/2738I 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_ProposalsIt 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. |
|
|
|
My understanding is that Counterparty is functioning, right now, using Bitcoin as a transport layer. In order to do so, it must be using existing, accepted features of Bitcoin.
It is abusing a bitcoin feature in an unintended, unaccepted way that obviously impacts the network to its detriment. |
|
|
|
Also Jeff, You have seen my attempts at swapping out the OpenSSL dependency in favour of PolarSSL to facilitate having picocoin run on low powered and embedded devices. PolarSSL developers have indicated that they plan on releasing a new update early next week: https://github.com/polarssl/polarssl/issues/71This new release should mean that PolarSSL now implements all bitcoin requirements. The PolarSSL guys have been most helpful on this. Yep, looking forward to it. |
|
|
|
Just pushed out a commit that implements this. |
|
|
|
|
The definition of a miner is someone who collects bitcoin transactions into a block, and attempts to produce a nonce value that seals the block into the blockchain.
According to BFL_Josh's off-the-cuff estimate, we have about 12 miners in bitcoin.
|
|
|
|
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? What pool do you run? I'm talking about miners -- the people who collect transactions into a block -- not the people who contribute computing services to a mining pool, yet have zero impact over how the network is run. |
|
|
|
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. |
|
|
|
[...]
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. |
|
|
|
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 a good start. The main bug there is that 'pubkeys' is plural. You have to parse multiple entities out of the script to match a single "OP_PUBKEYS" That requires a bit more reworking of the script parser, which fundamentally assumes there is a 1:1 ratio between opcodes and script data items. With "OP_PUBKEYS", that assumption fails. (I was looking at this last night ) |
|
|
|
|
Added two new utilities, "txmod" and "blkstats"
Added some P2SH scripting ability, also.
|
|
|
|
|
Nobody is "killing innovation." There is plenty of room to extend bitcoin's protocol, if that is what people want to do.
There is just one particular method, CheckMultiSig, that has multiple disadvantages.
|
|
|
|
|
Show Posts
