These instructions are somewhat dangerous— there is a reason the GUI doesn't expose the privkey stuff...

If the wallet had other funds in it those might be spent instead of the recently loaded key—  if there is any change left (e.g. the paper wallet's value wasn't sent exactly) that that change will go to another address not of the paper wallet. If the temporary wallet is then destroyed these funds will be lost forever.

At this time I'd recommend using armory for paper wallets.

Meh.

Any amount of algorithms will just be guesswork that could be wildly wrong— A small error in the exponent makes a big difference: If computer's ability to handle the blocks doubles in 18 months instead of 12 then ten years the size increase will be 1024 : 101— blocks 10x too big to handle.

And "median of blocks" basically amounts to "miner's choose"— if you're going to have miners choose, I'd rather have them insert a value in the coinbase and take the median of that... then at least they're not incentivized to bloat blocks just to up the cap, or forced to forgo fees to their competition just to speak their mind on making it lower.  But miners choose is ... not great because miners alignment with everyone else is imperfect— and right now the majority of the mining decision is basically controlled by just two people.

There are two major areas of concern from my perspective:  The burden on unpaid full nodes making Bitcoin not practically decentralized if it grows faster than technology, and a race to the bottom on fees and thus PoW difficulty making Bitcoin insecure (or dependent on centralized measures like bank-signed-blocks).  (and then there are then some secondary ones, like big pools using large blocks to force small miners out of business)

If all of the cost of being a miner is in the handling of terabyte blocks and none in the POW, an attacker who can just ignore the block validation can easily reorg the chain. We need robust fees— not just to cover the non-adaptive "true" costs of blocks, but to also cover the POW security which can adapt as low as miners allow it.

The criteria you have only speak to the first of these indirectly— we HOPE computing will follow some exponential curve— but we don't know the exponent.  It doesn't speak to the second at all unless you assume some pretty ugly mining cartel behavior to fix the fee by a majority orphaning valid blocks by a minority (which, even if not too ugly for you on its face would make people have to wait many blocks to be sure the consensus was settled).

If you were to use machine criteria, I'd add a third: It shouldn't grow faster than (some factor of) the difficulty change.  This directly measures the combination of computing efficiency and miner profitability.  Right now difficulty change looks silly, but once we're comfortably settled w/ asics on the latest silicon process it should actually reflect changes in computing... and should at least prevent the worst of the difficulty tends to 1 problem. (though it might not keep up with computing advances and we could still lose security).  Also, difficult as a limit means that miners actually have to _spend_ something to increase it— the median of size thing means that miners have to spend something (lost fees) to _decrease it_...  

Since one of my concerns is that miners might not make enough fees income and the security will drop, making it so miners have to give up more income to 'vote' for the size to go down... is very not good. Making it so that they have to burn more computing cycles to make it go up would, on the other hand, be good.

(the 100m number there is completely random, we'll have to see what things look like 8 months once the recent difficulty surge settles some, otherwise I could propose something more complicated than a constant there.)

Mind you— I don't think this is good by itself. But the difficulty based check improves it a lot. If you were to _then_ augment these three rules with a ConsentOfTheGoverned hard upper limit that could be reset periodically if people thought the rules were doing the right thing for the system and decentralization was being upheld...  well, I'd run out of things to complain about, I think. Having those other limits might make agreeing on a particular hard limit easier— e.g. I might be more comfortable with a higher one knowing that there are those other limits keeping it in check. And a upper boundary gives you something to test software against.

I'm generally more of a fan rule by consent— public decisions suck and they're painful, but they actually measure what we need to measure and not some dumb proxies that might create bad outcomes or weird motivations— there is some value which is uncontroversial, and it should go to that level. Above that might be technically okay but controversial, and it shouldn't go there.   If you say that a public set limit can't work— then you're basically saying you want the machine to set behavior against the will and without consent of the users of the system, and I don't think thats right.
 

There has been some experimentation with them— but not contract usage. Due to some attack usage we actually will not relay (or mempool) locked transactions at all right now.

Since the genesis block was generated with some external code it may well have been rolling the public key... Even with valid ones— though the output of block 0 is not spendable in any case.

I was aware of the suspiciously high difficulty... and when Bluematt last brought it up in #bitcoin-dev I suggested that perhaps he just left it running, saving the best result, while he did the final preparation for the release.

Greetings.

After the many scams here the first thing that almost everyone will ask is "What evidence do we have that your product is real?"

I know all these mining suppliers seem obvious to people here, but I see people on IRC all the time who are apparently finding them credible... considering how cheap setting up a website is its no wonder a lot of people try to scam.

The site shows a whole bunch of crazy spam transactions (e.g. tens of kilobytes, 1e-8 outputs only, no fees) which will never actually be confirmed, won't even be relayed, wouldn't be constructed by any unmodified software, and are probably a lame wristed DOS attack attempt. ... so the sheer count just isn't interesting.

Use P2Pool, and then you're an honest to god honest node.

Or really, if your motivation is primarily to secure Bitcoin— feel free to solo mine. Your expected return is as good or better, and if you're not in it for the income the fact that its a bit of a lottery shouldn't turn you off.

The rate was determined by Satoshi prior to the system's release. The rate cannot be increased unless 100% of the post-change surviving users agree to it.  Rules like anti-inflation are imposed by all the users of the system, mining has nothing to do with enforcing it.

This thread has been killed by a shortage of civility.

Bitcoin's checkpoints _never_ arbitrate the selection of the best chain. They protect against some silly DOS attacks that will be fixed when we get around to changing how the initial block download works.  In the mean time, I had some of my own blocks orphaned by the block at a time checkpoint placement in PPcoin (long before POS was active), this was what actually triggered me to stop mining ppcoin. 

Yes, it's centrally controlled "for your protection" ... ignore the man behind the curtain.    I can buy "launch"  but PPcoin has been around for a while now ("PPCoin is the only ALTcoin") and practically all mining on it is PoS mining, so the initial risk of it being massively overpowered should be gone now if it would ever be gone. I'm not arguing that it isn't needed: I'm arguing that with it, PPcoin is just a very inefficiently implemented centralized system, and that the need for it basically disproves that PPCoin currently achieves its goals.

>  I had against it have turned out to be baseless.

Uh.  What about the fact that its still centrally controlled by developer announced checkpoints, and that none one the layered complexity seems to address the fundamental issue with PoS that an optimal-rational PoS miner will concurrently mine all the chains he is able, because doing so maximizes his expected income... because nothing is at stake when mining a fork that ultimately fails?

(If you're sensing some frustration from me, it's because I think that "cryptocurrencies" which are just inefficiently implemented centralized systems distract people from working on real, viable, decentralized solutions)

There was a post on this subject on bitcoin-development last night, but it hasn't shown up in the archives yet.

Here was my response:

On Fri, Apr 5, 2013 at 2:30 AM, Melvin Carvalho
<melvincarvalho@gmail.com> wrote:
> There was some chat on IRC about a mining pool reaching 46%
> http://blockchain.info/pools

The estimates on there may be a bit lossy.

> What's the risk of a 51% attack.

The whole fixation on "51" as a magic number is a bit confused— I'll
say more below.

> I suggested that the pool itself is decentralized so you could not launch
> one

None of the pools listed there are meaningfully decentralized—  before
Luke whines, in theory the ones supporting GBT could be if used in a
way that no one actually uses them.  P2Pool is decentralized based on
the same technology as Bitcoin itself, but it's certainly not as point
and click easy as a centralized pool.

> On IRC people were saying that the pool owner gets to choose what goes in
> the block

That is correct.

Though I'd point out— the major pool ops all seem to be great folks
who care about the future of Bitcoin— and the continued success of
their very profitable businesses: a 50% mining pool with a 3% fee
rakes in 54 BTC per _day_.

The more likely threat isn't that pool owners do something bad: It's
that their stuff gets hacked (again) or that they're subjected to
coercion. ... and the attacker either wants to watch the (Bitcoin)
world burn, or after raiding the pool wallet can't exploit it further
except via blockchain attacks.

> Surely with random non colliding nonces, it would be almost impossible to
> coordinate a 51% even by the owner

That makes no sense. A centralized pool is the miner, the remote
workers are just doing whatever computation it tells them to do.
Certainly these remote workers might switch to another pool if they
knew something bad was happening... but evidence suggests that this
takes days even when the pool is overtly losing money.  Miners have
freely dumped all their hashpower on questionable parties (like the
infamous pirate40) with nary a question as to what it would be used
for when they were paid a premium for doing so.  It seems even those
with large hardware investments are not aware of or thinking carefully
about the risks.

> It would be great to know if this is a threat or a non issue

It's important to know exactly what kind of threat you're talking
about—  someone with a large amount of hash-power can replace
confirmed blocks with an alternative chain that contains different
transactions. This allows them to effectively reverse and respend
their own transactions— clawing back funds that perhaps had already
triggered irreversible actions.

This doesn't require some magic "51%"— its just that when a miner has
>50% the attack would always be successful if they kept it up long
enough (long enough might be years if you're talking really close to
50% and he gets unlucky). Likewise, someone with a sustained
supermajority could deny all other blocks— but that attack's damage
stops when they lose the supermajority or go away.

More interesting is this:  An attacker with only 40% of the hashpower
can reverse six confirmations with a success rate of ~50%. There is
source for computing this at the end of the Bitcoin paper.   I did a
quick and really lame conversion of his code JS so you can play with
it in a browser:

https://people.xiph.org/~greg/attack_success.html

I broke this off the BTC guild thread because its offtopic for there.

Separately, I don't think you address any of the concerns at all, you could still have enormous pools doing both of the POWs. Plus your scheme has embedded in it a bunch of central rich people. "Does not want".

I just tested and imported 20 keys in under 100ms from the command-line (including the time to fork) with bitcoind git from about a week ago.

I suspect you're providing the rescan flag as the label.

From the command-line the correct invocation is:

With the "" being the label.

Remuneration for your undue insults in the other thread are accepted at the address in my signature.

This only helps when people use the system in a poor way that screws up the privacy design... and the opcodes and such are unnecessary: a pair of nodes can community however they agree to communicate— deflate encoding if they like— and whatever alternative transport you want could compress things.

We'd be unlikely to merge anything in the reference that improve efficiency only for cases where users give up privacy. Privacy is an essential part of any financial transaction system, and the privacy of Bitcoin users is unusually fragile.

uh. Testnet didn't prevent the hardforking we created in Bitcoin 0.8 even though we believe that the relevant cases were tested already. (there were already super large blocks there).

It does not, however, use it to skip the validation entirely. A chain cannot inflate the supply of coin regardless of what the checkpoints are set as. Checkpoints have absolutely no place in a Bitcoin specification, and as of right now they way they are used do not simplify the enforcement of the protocol rules.

Once we have header first syncing we will possibly eliminate checkpoints for any speed purpose.  (though may maintain a single one for a rewrite-doomsday security blanket).

Even the minimal sane behavior is surprisingly complex. But beyond that, "lock old _invalid_ blocks in with checkpoints" is really pretty hideous. You'd still have to distribute code to validate them because part of the point of the system is that none of it depends on some magic values being trustworthy. Though perhaps its preferable to relegate the legacy support to a validation tool.

At the same time, there is really not that much legacy stuff that is really worth fixing.  Making some of the byte order more consistent— or what have you— is not worth the risk of a hardfork to get it.  A lot of the other complexity in the system rules is simply necessary...  a lot of things which are easy to specify when you don't need absolutely identical bit exact behavior become difficult when you do... and the nature of what we're doing implies bit exact behavior for almost everything that reads from the blockchain.

Because that would be pointless for actual money laundering. The purpose of money laundering isn't so much to break the connections— thats easily done— but to give the funds a "legitimate" origin, that you can report, pay taxes on, and spend without triggering any unwanted investigations.