Good. I'll definitely look into that.
|
|
|
+1 for i2p. Tor services are so-o-o slow!
They are not. There is a bootstrapping stage which can take about a minute, but after that it's ok. Also, one advantage of TOR is that it is extremely easy to install. Basically one "apt-get install tor" on debian.
|
|
|
Well, one thing about a bitcoin exchange plateform is that you can easily get your bitcoins back, right?
Right now I'm in the process of funding my MtGox account for the first time. Hopefully I'll be able to get my bitcoins as soon as I buy them right?
However, I remember having heard about a 45 days delay. Does it still exist? I hope not. Moreover, if I recall correctly, this delay was due to paypal reversal possibility, and I founded my account with a bank wire. So I guess there is no reason why there should be a delay for me.
|
|
|
http://premier-samedi.org/Je me demande si ça ne peut pas être une occasion d'organiser des échanges de bitcoins contre cash. Personnellement pour ce mois-ci je suis acheteur de bitcoins pour 100 euros. Faites moi une offre pour cette somme, je vendrai au plus offrant. PS. Nan à la réflexion c'est pas une bonne idée de faire ça à la cité des sciences pendant cette install-party. Ce n'est pas un endroit approprié pour faire du traffic de bitcoins. Ma proposition reste cependant valable pour le dimanche 6 mars, dans un parc à Paris.
|
|
|
Cool, c'est exactement l'idée qui m'a traversé l'esprit lorsque je rédigeais la fin du dernier message. Je pensais au début que l'on pourrait distribuer tous les bitcoins de manière équitable quelque soit l'investissement en termes de ressources. Puis je me réorientais vers un système qui distribuerait les bitcoins de manière aléatoire, comme au loto.
Mais finalement cela reviendrait au même,...
D'ailleurs, la loterie est une bonne analogie. En gros c'est comme ça que fonctionne bitcoin. Chaque block est un ticket de loterie. Le but du jeu est de trouver le numéro (le nonce) qui permet de créer le block suivant.
|
|
|
Dommage qu'on n'a pas trouvé de meilleure solution, sans gaspillage.
C'est pas un gaspillage puisque ça permet de remplir une fonction (décentraliser et anonymiser un réseau). Et franchement y'a pire en termes de consommation d'énergie. Par ailleurs encore une fois, c'est pas pire que le chauffage électrique.
|
|
|
Bon je vais faire l'effort quand même.
Tu ne peux pas avoir un système à la fois décentralisé et anonyme, sans faire intervenir à un moment ou un autre ta puissance de calcul.
Imagine que tu dises: "on va donner un bitcoin à chaque nouvel entrant sur le réseau, et on diminuera progressivement cette valeur afin qu'au final le nombre total soit constant".
Bon, ben si le système est anonyme, rien n'empêche un nouvel entrant de se faire passer pour un nouveau plusieurs fois, et ainsi de s'attribuer autant de bitcoins possibles. Un peu comme avec le "bitcoin faucet".
Dans cette optique, tous les "tricheurs" vont s'affronter les uns les autres. En gros celui qui arrivera à créer le plus de fausses nouvelles connexions à la seconde s'attribuera le plus de bitcoin. Et cette capacité sera forcément liée à la puissance CPU.
C'est presque un théorème, qui reste à démontrer mais qui est assez intuitif quand on y réfléchit amha:
"la distribution initiale de toute monnaie électronique décentralisée et anonyme doit être basée sur la puissance CPU des participants."
|
|
|
Le thème du prétendu gaspillage des ressources est un thème maintes fois abordé et personnellement j'en ai un peu marre d'expliquer toujours les mêmes choses. Effectivement ça devrait être dans la FAQ. J'ai des idées que j'aimerais discuter mais ne sachant pas comment le système est conçu, j'ai encore une question: qui crée les blocs ? Est-ce que c'est
- uniquement l'ordinateur qui a trouvé le hash qui convient - ou est-ce que ce sont plusieurs ordinateurs à la fois qui créent un bloc de manière collaborative ?
Dans l'absolu celui qui génère le bloc c'est le processus qui fait tourner le logiciel bitcoin. Que ce soit un ordinateur ou une ferme de calcul importe peu. In fine les bitcoins générés appartiennent à celui qui a le privilège d'accès en lecture au fichier wallet associé.
|
|
|
Peut-être que cela pourrait compléter la faq?
1 à qui sont payées liées "transaction fees"? 2 lorsque le mining sera terminé (plus de création de bitcoins), il ne sera plus nécessaire de dépenser inutilement les ressources processeur pour créer de nouveaux blocs? à qui reviendront alors les "transaction fees"? 3 le fait de perdre des ressources processeur pour créer des blocks me semble être une faille du système, c'est du gaspillage énergétique 4 et les bénéfices ne seront pas équitables (ceux qui ont le plus de puissance, des ressources matérielles, s'enrichissent sur le dos des autres qui font des transferts) 5 de l'argent sera perdu au fil du temps : (perte des données, crash de disque dur, oubli de mot de passe truecrypt, etc…) puisque les bitcoins sont limités à 21 million, comment faire face à la perte constante de la monnaie ?
1. Aux personnes qui génèrent les blocks. Ces frais obéissent à une loi de l'offre et de la demande. Vous pouvez choisir une limite sur les frais que vous êtes disposés à payer. Votre transaction ne sera alors traitée que par les générateurs de blocks compatible. Par conséquent, le fait d'accepter des frais permet d'accélérer le traitement d'une transaction. Notez qu'à l'heure actuelle, les frais sont globalement nuls. Ils ne seront la rémunération principale de générateurs que dans quelques dizaines d'années. 2. Lorsque tous les bitcoins auront été créés, on ne cessera pas la création de blocs pour autant. Les blocs ne sont pas générés pour créer des bitcoins. Ils le sont pour éviter le double paiement. Il est possible que la difficulté, et donc la puissance de calcul, diminue avec le temps, mais à vrai dire personne n'en est certain. Cela dépend beaucoup plus de considérations économiques et psychologiques que techniques. 3. La création de blocs est ce qui permet la décentralisation du système. Elle n'est donc pas inutile et n'est donc pas à proprement parler un gaspillage. Elle n'est, quoi qu'il en soit, pas plus un gaspillage énergétique que ne peut l'être le chauffage électrique, du moins en hiver hors des zones tropicales. 4. Les bénéfices sont équitables dans le sens où rien n'empêche personne de se mettre à générer des blocs. Et il n'y a rien d'anormal à ce que ceux qui mettent plus de moyens pour le faire obtiennent de meilleurs résultats. Tout comme une mine d'or qui possède plus de moyens techniques extraiera plus d'or. Par ailleurs, il y a par définition une limite intrinsèque à la quantité de bitcoins que pourront produire les générateurs de blocs. Quant aux frais de transferts, ils obéissent à la loi du marché, et vous n'êtes donc pas obligés de les payer (il existera probablement toujours quelques mineurs qui accepteront de miner gratuitement) si vous accepter d'attendre un peu plus longtemps pour vos transactions. 5. Il n'existe aucun moyen de faire face à la perte de bitcoins. Tout comme on ne peut pas empêcher quelqu'un de jeter de l'or dans la mer. Par ailleurs, si vraiment un jour la quantité de bitcoins devait diminuer au point de rendre la monnaie inutilisable, alors une nouvelle chaine serait créée par ceux qui le désirent.
|
|
|
I agree about the scripting part. To me this is kind of huge mystery.
|
|
|
most shops won't care at all. their machine tells them 'signature required' they ask for a signature. that's the entire thought process.
Still, I wouldn't feel comfortable trying. Especially since it is written "electronic use only" on the card. I wonder why by the way, since the User Agreement document clearly states that the card could be used in an ATM and shops. I'll try, but only if I have some cash aside in case it doesn't work.
|
|
|
Block 111111 was generated at 11 am, Pacific time. In the year 2011. And the nonce was beginning with 111
|
|
|
That procedure should work. Though obviously you will want to switch back to the new wallet at the end of it.
Well, I would not try it on a healthy wallet though. But I'll keep it in mind just in case...
|
|
|
How about { bigEndianHex2littleEndianHex <<<"$a" | xxd -p -r ; bigEndianHex2littleEndianHex <<<"$b" | xxd -p -r ; } \ | openssl dgst -sha256 -binary \ | openssl dgst -sha256 -hex \ | bigEndianHex2littleEndianHex
That would give the third hash, wouldn't it? It does indeed! But you have to get rid of the annoying 'std(...)= ': I didn't know that there were actually 2 sha256 passes, just like for the hash of the block itself. { bigEndianHex2littleEndianHex <<<"$a" | xxd -p -r ; bigEndianHex2littleEndianHex <<<"$b" | xxd -p -r ; } | openssl dgst -sha256 -binary | openssl dgst -sha256 -hex | sed 's/.* //' | bigEndianHex2littleEndianHex
(also, you can use '|' at the end of line without using '\') Now how to deal with blocks with a number of transactions that are not a power of 2?
|
|
|
Yes in theory, no in practice. The client pregenerates batches of addresses so that you don't have to back up your wallet as often.
Ok, what about that then? # get balance balance=$(bitcoind getbalance)
# stop bitcoin bitcoind stop
# rename corrupted wallet mv .bitcoin/wallet.dat{,-CORRUPTED}
# restart bitcoin (thus creating a new wallet) bitcoind
# generate a new address addr=$(bitcoind getnewaddress)
# stop bitcoin bitcoind stop
# backup new wallet mv .bitcoin/wallet.dat{,-BRANDNEW}
# put the corrupted wallet back mv .bitcoin/wallet.dat{-CORRUPTED,}
# start bitcoin bitcoind
# send all bitcoins to addr bitcoind sendtoaddress $addr $balance
|
|
|
You are aware that the bashism <<< appends a LF (ASCII 10) to its argument, right? $ sha256sum </dev/null e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 - $ sha256sum <<< '' 01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b - $ printf '\n' | sha256sum 01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b - $ hexdump -C <<< a 00000000 61 0a |a.| 00000002 $
In the same vein: perhaps bigEndianHex2littleEndianHex() should use echo -n or printf instead of just echo… I'm pretty sure it doesn't matter, since xxd -p -r does only read hexadecimal characters. echo "A 1" |xxd -p -r |xxd -p a1 echo -n "A 1" |xxd -p -r |xxd -p a1
|
|
|
If you knew your wallet had been compromised it would be a race to get the coins out to another location.
Interesting situation. Would it be fine to just run something like: bitcoind sendtoaddress $(bitcoind getnewaddress) $(bitcoind getbalance) which means: create a new address, and send all my bitcoins to it?
|
|
|
Ok now, let's try to make the Merkle tree. The first block with more than one transaction is the block 170. It has two transactions and its Merkle tree is: { "b1fea52486ce0c62bb442b530a3f0132b826c74e473d1f2c220bfa78111c5082", "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", "7dac2c5666815c17a3b36427de37bb9d2e2c5ccec3f8633eb91a4205cb4c10ff" } The third is the Merkle root. My first attempt is this code: { bigEndianHex2littleEndianHex <<<"$a" |xxd -p -r ; bigEndianHex2littleEndianHex <<<"$b" |xxd -p -r ; } |openssl dgst -sha256 -hex
Needless to say, the version without bigEndianHex2littleEndianHex didn't work either.
|
|
|
I was looking at the "old" bitcoins: those of blocks 0, 1, 2.... I can't find any of them which has been redeemed. So here are a simple question: what is the oldest non-generation transaction? PS. Ok, found it using a small script: http://blockexplorer.com/b/170This means that Satoshi has been running his computer during 17 hours before he tried to make a transaction. I guess he was testing the difficulty adjustment.
|
|
|
Gold is getting closer to its record high guys! I suck at maths, but I'm pretty sure that 205 BTC is not a very high bid!
|
|
|
|