|
The pragmatic solution is to support both GBT and stratum, in mining software.
Both are already deployed, and stratum seems to currently be winning the race for deployments.
GBT is supported in bitcoind and p2pool, and has gone through the BIP process and more review, so a choice seems valid. GBT is also more easily deployed in existing software, as it uses the more standard HTTP JSON-RPC that miners are familiar with.
|
|
|
|
|
Please do keep us posted on any experiments.
We need $A_Solution for timestamping data that does not involve storing new data records (transactions) in the main bitcoin block chain.
My mental analogy is to a steam boiler. Pressure is building from the community, to build all sorts of exciting digital notary / securely timestamped services. We need a release valve, otherwise the bitcoin blockchain will simply boil over into a very expensive, inefficient method of instant messaging.
|
|
|
|
|
If there is sufficient value attached, or potential for it, pool ops have been interested in the past.
Especially if a lot of well known developers were behind a data timestamping service standard.
|
|
|
|
What does that mean? I need to prefix my response with OP_PUSHDATA?
Yes. There are several push-data opcodes, the basic format looks like <size of random bytes to push><random bytes> There may be many different data segments, e.g. <size of data field 1><data field 1> <size of data field 2><data field 2> <size of data field 3><data field 3> When you create a scriptsig for the coinbase transaction. Is it any random bits? Or is it as jgarzik references?...
nVersion 1 blocks may have any random bytes (subject to the push-data rules above). nVersion 2 blocks must have the block height as the first pushed-data object. See https://github.com/bitcoin/bitcoin/blob/master/src/script.cpp source code or on the wiki https://en.bitcoin.it/wiki/Script#Constants for more details. |
|
|
|
|
Just import Gavin's key once, rather than once each time you run the script.
|
|
|
|
I'm also thinking in setting up a script which every hour will download and PGP verify the files, and send an alarm by email if see any problem. Do you think that procedure can be helpful ?
Absolutely. That is a perfect example of decentralized action at work... we need as many people as possible checking these things. |
|
|
|
Checking PGP signatures is fine, but I suspect this is not a procedure an average user will be doing.
Is not possible to setup a dedicated, hardened and fully audited server, only for bitcoin updates repository ?
A single server doesn't help much against DDoS, and bitcoin sites have often been DDoS victims in the past. Multiple servers + active admin team can do it... but at that point you've just reinvented SourceForge or CloudFlare. If you go through a DDoS hardened proxy, you are back to trusting SF/CF/... |
|
|
|
Sigh. Come on Erik. Most of the article is pretty good, but a few key bullet points are quite misleading. 1. Zero fee to transfer money
This is untrue, especially if they follow your lead with... 6. Any amount can be sent (perfect for microtransactions under a penny, for example)
which will require a fee, because microtransactions of low value will not otherwise be relayed. Why? Satoshi pointed this out in his original paper, that bitcoin is not so great for microtransactions. |
|
|
|
|
Who says they have to be a fed at all?
A lot of electronic intelligence action happens at private contractors, I wager.
|
|
|
|
I hope they round up every ponzi and "bank" on the forum. They are a cancer on bitcoin, and make us all look bad.
Yep. |
|
|
|
Thank CJ, I will expect your public apology when the ASICs ship. Or are we going to hear crickets from you, too, when the time comes and you slink back to your hole and hide?
There are very few people who are on my ignore list. He's one of them. That "ignore" button in the left column profile area comes in handy  |
|
|
|
Why does it matter?
Doesn't matter that much but it helps managing expectations and perceptions/perceived value. Something BFL could use some more  I still don't see why... as long as the chips meet the stated specs (gimp-binned or not), buyers should be satisfied. What is the practical difference between a "full working ASIC" chip and "dwarfing a chip down" if they both mine at 3.5 GH/s? Why do you care? One can be OC'd to the full 5GH/s for a single chip. The other cannot.  That is fine with the smileys and all... as long as you realize these expectations are unrealistic and far beyond what major chipmakers like AMD and Intel guarantee. |
|
|
|
We shouldn't add extra data into Bitcoin's blockchain. It grows very fast. Imagine how much data it'll be necessary to transmit when Bitcoin usage reach 100.000 transaction per day.
Adding extra data to the coinbase transaction found in every block is just fine. That is how merged mining is accomplished today, and it is a scalable method of adding unlimited amounts of data to each block. |
|
|
|
Zero-confirmation transactions are always going to be problematic. If you accept them in a situation where an attack can be prepared with a lot of time in advance then you had it coming. In any other situation and with most people simply not taking them this attack is never going to happen. Just the low chance of happening to mine a block exactly when you have the chance to try this is enough to make this a non-problem IMO.
If instant transfers are so demanded, there will be centralised services like vouchers from exchanges or account-to-account transfers.
Or green addresses. |
|
|
|
|
It should be in "troll - garbage".
|
|
|
|
I guess i was really leaning more towards the idea of "Could we 'unlock' the jally and bump it up to 5Ghs? Or 4Ghs?
And the answer is probably predictable (I'm guessing, no inside info): "yes, but you void your warranty, fry your hardware, and have to deal with lockups" |
|
|
|
40 gh/s divided by 8 asic chips is 5 gh/s per chip.
so the jally will be crippled to only run at 3.5 gh/s or worse?
BFL has been saying 3.5Ghs from the beginning, this is no surprise. How exactly they plan on doing this is a different tale... After big chip makers like AMD or Intel manufacture a chip, they run it through production quality control testing. A chip that is theoretically the same as another chip may exhibit different behaviors under stress. As a result, some chips in a batch may be binned and sold as 3 Ghz chips. Other chips in the same batch, that did not perform as well in testing, may be binned and sold as 1.5 Ghz chips. It is very realistic and following standard commercial practices that the same chips from the same batch might run at slightly different clock speeds, to avoid manufacturing imperfections or whatnot. So perhaps Jalapeno units are 5 Ghash/sec that did not pass quals at top speed, but do pass quals at lower speeds. Any sort of scenario like this is possible, standard for chip manufacturing, and not "cheating." |
|
|
|
It is positive for bitcoin as a whole, assuming the S.E.C. only targets those breaking existing laws, and not simply all bitcoin users. There are many legitimate, lawful uses of bitcoin and it can only be a good thing for that to be on the record. It was clear to anyone sane that Pirate's returns did not match anything in the known lawful universe. Or to quote Gavin, So-called high yield investments are (almost?) always dressed-up Ponzi schemes.
|
|
|
|
|
Show Posts
