Qualcuno ha trovato esempi su come questo benedetto modulo RW andrebbe compilato, almeno per la casistica di bitcoin (o altro) depositati su exchange? Perché io nel 2017 ho riconvertito degli Ethereum Classic in Ethereum tramite exchange, e vorrei capire come segnarli. Non dovrei pagare tasse perché (sfortunatamente) la soglia dei 51k euro non l'ho mai vista tranne che con il binocolo (lo so, essere poveri è una colpa), però sembrerebbe che l'RW lo deva compilare.

Supponiamo che volessi aprire un sito di intermediazione di acquisto/vendita di btc (tipo mtgox, btc-e...), di che autorizzazioni avrei bisogno?
E da che tipologia di esperti "legali" dovrei andare? (commercialisti/avvocati esperti di )

Grazie!

I hope you where exaggerating. 128 bits encryption could be breaked "routinely" in 100 years. Armchair explanation: DES at 56 bits can be breaked "routinely" by NSA/CIA ecc. If Moore's Law is sustainable the number of transistors in a chip will double every 1.5 years. Let's say that every doubling in number of transistors double the speed (because, in the end, cracking a code is a highly parallelizable task, so doubling the number of processors WILL double the speed). So each 1.5 years the number of bits that can be cracked "routinely" is raised by 1 (double speed = +1 bits, because +1 bit doubles the keyspace)... So 72 * 1.5 = 108 years... But note that DES was cracked "routinely" some years ago.

(read for example here. http://en.wikipedia.org/wiki/EFF_DES_cracker , in 1998 EFF brute-force cracked DES in 56 hours for 250,000$. So if Moore Law is sustainable, in 2106 AES128 could be cracked in 56 hours, but note that some years before a resolute cracker with some million $ and a month of time could probably crack it)

They probably collect the transactions in a "best effort" way... But if 2 blocks are orphaned, perhaps you can't put all their transactions in a new block.

What happens if a block becomes orphan? Its transactions are readded to the transaction pool, so they could be changed by the sender... So you would only need to wait for a split in the network to double spend your money?

Bitcoin 0.4 began using BerkeleyDB 4.8 instead of 4.7. Can I ask why they didn't directly jump to 5.2? 4.8 is still quite "old" (it's two major releases from the newest: 5.0 and 5.2)

I have a single card, clocked 300/900 on Windows and Catalyst 11.5 (too lazy to install 11.6 and I've read that they don't change anything) and I'm using -w 256. Someone had a big difference on the other patch. I got only a 1%. Perhaps the trick is in the ratio of memory clock/process clock.

On my 5870 it jumped 16 mh from 385 to 401. I'm using the poclbm "old" kernel + the other +3% patch (that gives me only 1% of speedup :-( )

You don't connect the Android to the PC with a cable. You use Wi-Fi or Bluetooth. You don't keep the private key on the cellular because it can be easily stolen. Stealing the PC AND the cellular is more complex (you can easily hide the cellular when you don't need it). Yes, it's perhaps possible to hack a cellular through wi-fi, but it's quite complex, and it's model-by-model. There isn't a single-hack that works for everything. It isn't totally fool-proof but it raises the difficulty of an hack very much. Especially if you consider that economical Android cellulars will multiply in the next year or so.

The cheapest android device is 99€ here in italy. It can be used as a "close" system. You install a thin client, install the fat client on your PC and keep on your PC the encrypted private keys (AES encrypted). These keys are downloaded from the android and decrypted by the cell phone on demand (your phone have the AES key). The PC needs "rearming" if the AES key sent is wrong. The AES key on your phone is PIN protected. You can send from your PC to your cell phone the public keys of persons you want to pay. You want to pay someone? In some "sicure" way you send the public key of the person to your cell phone, use the key to decrypt, and send the signed transaction to your PC. You don't use the phone in any other way than a client of bitcoin. You don't put a sim in the phone. You don't browse internet. Done.

This would be a shitty security method that would protect you only from the most noob script kiddie.
Two ways to hack it:
* the simple: wait for the window asking the password to appear and take the password (keyloggers)
* the "a little harder": You know (by looking at the source, the client is open source, you know?) in which function the key is unencrypted, you wait for the exe of the client to be loaded (you are a trojan, you are resident in memory), put a breakpoint there and snoop the memory. Each time a new version of the client is created you lose half an hour to "expand" your library of possible breakpoints. Hackers do more complex things to games that are protected by latest generation protections. You think that an open source software that anyone can compile is more resistant? Encryption will only make the wallet.dat more resistant to "one shot" trojans that enter, steal and exit (or to trojans written by script kiddies that don't know assembly). This would steal one private key at a time, if the program is well written (but then, if you are already putting a bp in the code, you can directly steal the password).

The only "possible" way would be to make the program polymorphic, like the viruses, so it would be more difficult to put a breakpoint in memory, but it's quite complex... And it would protect only against the second method. And in the end the trojan would simply replace your exe with another one that would only ask you the password and send it to the hacker.

Even better then... I had trusted the comments on key.h . It's 56 "phonetic symbols" to codify 256 + 32 bits in base36.

Right. You can derive your public key from your private key with ECDSA. So it's 61 characters, and you can use 36 bits for CRC, or at least you could use a CRC-32 optimized for detecting errors, like the CRC-32C that is considered to be the best one.

Probably converting to Base36 and using the NATO phonetic alphabet would be better (alpha, bravo, charlie... one... zero). It's 5.16 bits/symbol, so only 0.7 bits/symbol less than Base58. Mmmmh secp256k1 is 279 + 65 bits. Base58 adds 32 bits for the crc (technically a truncated sha256) and I think 32 bits is the minimum we should add (but someone has noticed that sometimes you can change a single symbol and still the crc won't change, but if you save both private and public key this shouldn't be a problem... I think you can check if they are "connected" one to another so you could ignore the crc.), so it's 376 bits = 73 NATO "words" to save both public and private key together OR 352 = 69 NATO "words" without the "CRC". Made a test... Writing 4 "words" per row, 2 columns, on a Letter sheet with 0.5 inches of margin you can put 4 public/private "couples" at Arial 12 without any problem.

It seems to be something more funny than useful. These "words" don't add anything to simply using Base58 (and perhaps adding some huffman coding upon it to make it auto-error correcting). Two examples:

FEED and FEET. Their "distance" is one character (D and T) AND they have a similar sound (D and T are both dental consonants).
DIME and DINE. The only difference is a single segment. Are you sure an OCR will distinguish between them?

Another problem: the length of each "symbol" is variable (A, AD, ADA are three legal symbols), so the space is an important separator. ADADAD could be AD AD AD or ADA DAD.

My account has been verified... And the problem was fully mine! I hadn't pressed the button to verify the account :-) I had only added the proofs :-) I got help on irc by Tux. (ah... you are permitted to think (but only to think) that I'm quite stupid... I feel the same :-) )

Am I the only one with the account still locked?

Ok... Thanks! I wasn't imagining thing... But I was remembering quite badly :-) There are bits and pieces that are correct... There was a pull request (and not a full version) with the bug... And the money lost was 65 btc (but there was a reference to 10 btc)

It was a "single instance" bug... It happened to only a single person on only a single release. I'm quite sure of it.

I'm quite sure there was a beta version some weeks ago that had a bug that "ate" 10 btc to a person. There was a message about it. I'm trying to find the message and, if possible, the update revision in github (I'll add that, if I remember correctly, the bug was that the public key the money was to be sent was zeroed, so the 10 btc had been sent to someone with public key 0000......000000, but clearly there wasn't this public key.)

Thanks!