They surely do, I posted my opinions on twitter and on my homepage.

But but they have their own brains and won't care about my opinion anyway.  It is a safe bet that some of them are involved in crypto, possibly creating their own altcoins. 

This past semester I got assigned a lab course where all the students were supposed to develop one project collaboratively.   On the first day I suggested a few possible projects, including an online exchange platform that could be used for stocks, currencies -- or bitcoin.  But they opted for a twitter-like system instead.  And only 6 students signed up for the class (perhaps because they knew that I would expect each one of them to actually write some code).

Was this posted here already? (Sorry if it was.)
Butterfly Labs Ruined: Bitcoin Fans Deal with an Incompetent Company
https://www.youtube.com/watch?v=jdSuTQjM-gg

SecondMarket BIT fund is not letting clients liquidate (withdraw) "because of SEC":
https://bitcointalk.org/index.php?topic=337486.msg9983332#msg9983332

There were those machines in shopping malls, where the kid puts in a coin and gets to "mine" a stuffed animal with a robot claw.  Would that qualify as a beanie ATM + mining rig, all in one?

(Rushing to the patent office with the design of a coin-operated bitcoins-mined-while-you-wait machine.)

Ah, but that problem will be solved by Sidebeanies pegged 1:100000 to actual Beanies!

Ah, thanks!

Interesting. From what others have written, I understand that "sell from the BIT" means "liquidating their shares", correct?

That reads like Stage 1 in the Karpelès Scale.

Would you believe that, again, it was an accidental block posting collision, not a malicious selfish mining questioning attempt?

Bitcoin chain is corrupted! SELL!
https://hashtalk.org/topic/26495/paybase-12-30-2014-8pm-eastern

(NOTE: -------->  )

In other words, the Bitcoin protocol will not ensure that the SideCoins are pegged to the bitcoins that were transferred.  The SideCoin protocol can do with SideCoins anything its designers choose to do.  Correct?

Will it be possible to create SideCoins after transferring 0 BTC to the sidechain? Or just 1 satoshi?

I understand that the two-way peg ensures that no extra bitcoins can be created on the main chain by going through a side chain.  But will the Bitcoin Network ensure that no extra SideCoins are generated on the side chain, before they are brought back?  That is, can one implement MtGOX on a sidechain?

EDIT: I see that someone partially answered this question above.

Would you believe that modern-looking terracotta dice -- cubic, with the spots and all -- were found in the ruins of Harappa and Mohenjo-Daro,  dating from some 5000 years before Christ?

Can you read?


The BCI buggy code was posted for a few hours and affected both private keys and k (R) values generated during that interval.  It was first discovered by someone who was monitoring the blockchain for repeated R values.  These repeated Rs exposed some keys that were generated before the bug.  Once the problem was diagnosed, people reproduced the buggy RNG and recovered private keys that were either generated during the interval or used as inputs in transactions during that interval.  Most, but not all, of the compromised keys were of the latter type.


It is the sad problem with all security mechanisms, not just computer security.  

Two years ago the Brazilian Election Board held a public challenge to demonstrate the security of their ridiculous electronic voting machine.  They stacked the rules as much as they could: entrants could only look at the code (~1 million lines of C) for a few hours during 2 days, could not copy it, had a few more hours to describe their attack and its goals, etc..  Even so, a young prof from my dept took the challenge, more for the fun than with the hope of succeding.  

At the end of each election, the machine prints a scrambled list of all the votes cast (don't ask why).  The permutation was randomly chosen so that the votes could not be associated to voters.  My colleague noticed that, while the scrambling itself was properly done, it used an old RNG from the Linux library that the manpage itself said was deprecated.  The sequence of numbers generated by that RNG had only 16 bits of entropy (the seed), so my colleague quickly wrote a program that just enumerated the 65k possible seeds, reproduced the scrambling, and used some redundancy of the list to check them.  The hardest part was typing the 400+ items of the scrambled list.  Once the correct seed was identified, he could recover the original order of the votes and hence the precise time at which each vote was cast.  

At that point he still had some time left, so he looked again at the code, and found that the seed was actually the timestamp of the moment when the machine was booted -- which the machine printed at the top of the report.

Moral: that P formula is very important, because it takes into account the stupidity and arrogance of the security experts who implement those ultra-cally-hyper-secure cryptographic methods, and of the users who trust any code that they downloaded from the net since it was vouched for by Antonopoulos or Roger Ver.

As long as they don't use the Purse.io model... (get real money/btc from customer, pay merchant with stolen credit card).

Claims that two other cloud-mining outfits, presumed ponzis, closed almost at the same time:
http://qntra.net/2014/12/while-some-ponzi-schemes-implode-other-fraudsters-double-down/

Thanks for the link and the compliment!

As I understood it, those Hyena guys claim that many wallet tools use PSRNGs that generate less than the required 2^160 bits of entropy.  They claim that the entropy is low enough that the chance of a collision is not negligible; and they have set up a lot of disk and computing power to catch for such collisions.

I doubt whether good PSRNGs, correctly implemented and used, have such a low entropy.  However, the probability of coding errors makes the project more plausible.  In conditional probability notation:

P(security broken) =
  P(software is correct) * P(security broken IF software is correct) +
  P(software is buggy) * P(security broken IF software is buggy)

A strong cryptographic method only ensures that the factor P(security broken IF software is correct) in the first term is astronomically small.  However, the factors P(software is buggy) and P(security broken IF software is buggy) are large enough to matter.  For bitcoin, empirically, the second term may be on the order of 1 in 10'000 or more, and is unlikely to decrease. (As time passes, the best implementations may get somewhat more secure; but the number of implementations will grow, so there will be fewer competent eyes checking each of them, and reports of coin theft will get less attention.)  Thus, P(security broken) should be large enough to notice, and will not be improved by switching to 512 bit keys or whatever.

Well, yes, if the private key was not generated at random, it is possible to crack it.

This is in fact what happened earller this month to customers of Blockchain.info (BCI) web wallet.  That service gives you javascript code that is supposed to generate random private keys, which remain in your computer so they are supposedly safe.  One day their Chief Blunder Officer tried to improve the random number generator, but instead broke it quite thoroughly.  As a result, some clients who generated private keys with the broken javascript got some keys that were easy to guess (so much so that the same key was given to different clients, it seems).  Also, any transactions that were signed with that buggy code contained enough information to allow guessing of the private keys of the input addresses.  

Fortunately, a "white hat" hacker was monitoring the blockchain for the latter weakness, promptly warned BCI, and the bad javascript was pulled from their site a few hours later.  Even so, about a thousand addresses with about a thousand BTC total had their contents swept by hackers who broke the private keys -- fortunately, most of them by that "white hacker", who returned them to BCI.   Those keys were so weak that they could be cracked by an ordinary PC.   There were similar incidents in the past but this may have been the worst one so far.

However, I suppose that old addresses do not have this kind of weakness, since there were fewer wallet programs available and those were written by competent programmers.  But who knows.  Perhaps Satoshi was still using some lousy random number generator when he generated his private keys...

This is a also method that a hacker could use to steal bitcoins.  He gets people to use malicious wallet software, that generates intentionally weak keys, and/or transaction signatures that reveal the private keys.  Unlike the BCI accident, these weaknesses can be masked so that they cannot be detected by looking at the keys and signatures.  The hacker then needs only monitor the blockchain until he sees enough BTC in those compromised address.  This attack would work even if the victim generates the keys and/or signs the transactions in a computer that is not connected to the internet.

Not that we know of. Even if all the network's computing power could be devoted to the task, it would take bazillion years to find the private key of one address by trial and error.

In theory, there may exist some magic algorithm that allows one to do that in a viable amount of time.  That would not only break bitcoin but also a lot of e-commerce and e-banking systems.  But no one has published such an algorithm, and apparently no one knows how to even start looking for it.  

[ ... ] I can not imagine many holding-water hypotheses for explaining the craziness of mining race. An attempt to crack the wallets (and I assume that for doing the trick a large pool would be needed too) would explain the completely irrational hash-rate increase.
[/quote]

The bitcoin protocol gives about 3600 BTC (about 1.2 million USD) every day to the miners, no matter what.  The fraction that one miner gets from that bonanza is the same as the fraction of the total hash power than he controls.  Therefore, each miner who is making profit will want to have as much hashing power as he can, to maximize his profits.  That is the reason for the mining race.

I have no idea of what you mean, but I still would like to know why Autumn Radtke died.

The first statement is not correct.  Not long ago someone jokingly posted a "list of Fortune 500 companies that still do not accept bitcoin (hint: there are 500 of them)". 

Now that Microsoft has decided to accept dollars from the sale of bitcoins, there must be only 499 of them.

As for the second statement, the price may seem stable compared to other months, but it is still totally wild by the standards of national currencies.