Offline-generated it good, but there's no difference between a "paper" wallet and a cold storage electronic wallet (e.g. Armory, Electrum, BIP32) with a paper backup, or is there? At some point, you have to hand your private keys over to a computing device (an offline computer or a hardware wallet) to do the EC math (unless you do it yourself on paper, good luck with that! )

When behavior like this is fixed via limits great care must be taken to make sure the limits are implemented absolutely consistently everywhere or the result is a consensus splitting risk. Alt full node implementers have repeatedly implemented the limits wrong— even when they're obvious in the code, called out in the comments, documented on the wiki, etc... even by just simply not implementing them (... coverage analysis and testing against the blockchain can't tell you about limits that you're just missing completely).

在localbitcoins在线求买比特币列表中，阿根廷用户长期占据前N位，这是有多饥渴啊！

There is a big difference between overflowing a numerical value and overflowing memory.

Say you have an 8bit unsigned int, then (200+100) would overflow because the highest value is 255.  The result is then (200+100-256)=44, with a carry bit, or overflow.  In that context, it just means that you passed the maximum numerical value which resets to zero.

Concatenation of strings coupled with duplication would causes the memory (not a number) to overflow, and it could look like this:
abc; OP_DUP;
abc abc; OP_CAT; abcabc; OP_DUP;
abcabc abcabc; OP_CAT; abcabcabcabc; OP_DUP;
abcabcabcabc abcabcabcabc; OP_CAT; abcabcabcabcabcabcabcabc; OP_DUP;
abcabcabcabcabcabcabcabc abcabcabcabcabcabcabcabc; OP_CAT; abcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabc; OP_DUP;
...and after so long, that would cause a memory overflow, which would result in a CPU fart.

You may read www.redefiningthesacred.com/math4.html which illustrates the power of exponential growth.

To complete the lesson, for those who never liked homework: With a 201 cycle limit, OP_CAT lets you use approximately 534,773,760 YiB memory, vs 102510 bytes without it.

And maybe you will realize why all these altcoins worry me so?  Or perhaps you've got cheaper sources of ram than I do?

They haven't posted their actual XBT holdings since April 30, is that correct? (They used to post about once a month before that.)

Well, I'm running


In all fairness, I see I've set alerts to be sent to the same address from both bitcoind and bitcoind running on testnet, and I see that the block exists on testnet:

http://blockexplorer.com/testnet/block/000000009cf297bc2a9610af823b49fc1d98e001239e99204c3c410e1ad3fe54

So case solved then. My fault. BTW, how could you see the difficulty level, could you see that directly from the block hash provided?

Just got this message from my bitcoin node:


Looking at this forum and reddit, I see no further information about it.

Is there anywhere I can get more detailed information about this event?

According to the e-mail I received it happened ca. 22 mins before this post.

Could we theoretically create an output that could only be spent after some proof-of-work?
stringtoconcatenate OP_CAT OP_SHA256 00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048 OP_LESSTHAN OP_VERIFY OP_DROP OP_DUP OP_HASH160 e6ee700d3b22c43b4ad5d4144ae16d35a0013bc0 OP_EQUALVERIFY OP_CHECKSIG

Our scriptsig would have first the signature and then the nonce.
The nonce and a string in the script - perhaps a recent headline, to prove work wasn't done prior to the transaction - would be concatenated (if OP_CAT wasn't disabled) and then we'd get the SHA-256 hash of the combined string. If that hash is less than a target, then yes, we can check the signature.

I think this could be useful (if not fun) for a trust fund, or proof-of-illiquidity, if our target has enough leading zeroes to make it (on average) take a few days to find a working nonce, and therefore make the output spendable. Perhaps the target could take years with a GPU farm.

Any comments? Would this be a good/bad idea? _{(assuming of course OP_CAT was enabled?)}

http://translate.google.co.uk/translate?hl=en&sl=zh-CN&u=http://www.360doc.com/relevant/212102353_more.shtml&prev=/search%3Fq%3D%25E4%25B8%25AD%25E5%259C%258B%25E9%259B%25BB%25E5%258A%259B%25E6%2588%2590%25E6%259C%25AC%26client%3Dfirefox-a%26hs%3Dzmj%26rls%3Dorg.mozilla:en-US:official%26channel%3Drcs

1.00 USD    =    6.14322 CNY

1 CNY = 0.16 cent

very low cost electricy in china is about 0.5 CNY (8 cent per KW/h)

even if the price of EQ is $2000 per TH and it the most effienet machine @ 0.7 watts per GH then it's still run at a loss and at current rates would never break even.  Even if the EQ was free, and it's the most efficient Asic available it would still only be making $12 a month by December (at current difficulty increase).   Similar conditions (only more extreme) than October last year.  BTC is very undervalued.


As for the authorities, finding such an operation I suspect the tax man might be interested, I doubt they would just walk away after finding a 1/4 of a billion $ setup.  

As there is a good chance many of the asics are already run at a loss.  

Maybe it's real but I don't buy it. Especailly as if "secret" in China, it would send out a massive heat signature and the authorities would think they are growing cannabis in those buildings.  

Mining is a renewal process, but I do not think it is Poisson, since even for single-function coins, the difficulty grows over time.  (In fact, it should be non-homogeneous Poisson: the block interval distribution should get lower and flatter as the difficulty gets higher, although it is still exponential.)

If the hashes are in a predetermined order, multi-hash-function (chained-PoW) mining block arrival times should also be exponential, since sums of Poisson processes are also Poisson processes.  (Assuming a fixed difficulty level, for the sake of discussion.)  However, choosing the hashes randomly results in an iterated (compound) Poisson process.  Here, the block intervals should have a more complicated distribution:

http://en.wikipedia.org/wiki/Compound_Poisson_process
http://arxiv.org/abs/1107.2876

If I remember right, Quark used randomly selected hashes.  I'm not sure about X11/13/others.  PoW schemes that include superblocks are also iterated Poisson processes, for the same reason.

You just re-invented options.

Ah, right.  That makes sense!  Kinda seems obvious, now that you've explained it  

Thanks very much for the explanation.

Follow-up thought:  To avoid forking, it seems like the "best" PoW scheme would be one where block-finding times are close to the mean (i.e., variance is low).  Since mining is essentially random, I guess the right mental model would be a renewal process -- almost Poisson, actually, but mining always gets more difficult over time.

Makes me think that the multi-hash-function algorithms popular in altcoins right now (X11, X13, etc.) are inherently more prone to forking, because of the extra among-hash-functions variance.  And, coins with random "superblocks" would be bad for the same reason.  Hmm.  I wonder if this is true empirically.

I have read several times that proof-of-work solves the Byzantine generals problem.  I am curious how it does so.  A bit of Googling turns up this page:

https://bitcointalk.org/oldSiteFiles/byzantine.html

As I understand it, the problem described on that page is that disagreements could arise among the generals due to network delay.  Each time the plan is broadcast, the likelihood of the same disagreement arising decreases.  (Exponentially, if the disagreements are due only to random chance.)

However, it is not clear to me what role proof-of-work plays in this scheme.  My understanding of proof-of-work is, essentially, that its purpose is to prevent sybil attacks, by making forgeries computationally prohibitively expensive, and of course I get that this is crucial for Bitcoin.  But, it seems to me this is sort of an auxiliary problem: now, in addition to network delay, the generals are also faced with an enemy who is trying to forge messages.

What I'm trying to figure out is, does proof-of work also address the problem of network delays?  It seems to me that the chaining the plan hashes together solves this problem -- at least, from a practical perspective -- without needing proof-of-work.