el orderbook de mtgox es lo que se observa al pinchar en mtgox live graph verdad?
No me suena ese enlace. Yo suelo estar conectado a http://bitcoin.clarkmoody.com/, y el order book es el listado de abajo: Buying Selling Sum Size Bid Ask Size Sum 50.0 49.9827 128.52000 129.00000 5.7530 5.8 72.9 22.9517 128.51000 129.96974 9.9615 15.7 122.9 50.0000 128.22300 129.97074 0.2500 16.0 130.4 7.4877 128.00100 129.97075 0.2500 16.2 566.9 436.4643 128.00000 130.00000 10.8430 27.1 567.9 1.0097 127.99721 130.00120 0.2500 27.3 567.9 0.0200 127.98500 130.05470 1.0795 28.4 568.9 1.0000 127.98000 130.40294 1.7991 30.2 568.9 0.0279 127.97248 130.43000 64.5828 94.8 569.0 0.0200 127.94500 130.51400 43.8551 138.6 569.5 0.5050 127.92086 130.80000 2.0000 140.6 570.3 0.7817 127.92082 130.99000 41.3054 181.9 570.3 0.0200 127.90500 130.99999 1.0273 183.0 570.3 0.0200 127.86500 131.00000 24.9000 207.9 580.3 10.0000 127.84099 131.05362 0.5000 208.4 Las naranjas del ejemplo son la columna de selling. Hay 5.7530 a la venta al precio de 129 $/btc. A continuación hay 9.9615 a 129.96974 $/btc y así sucesivamente. La última columna es un acumulado de bitcoins (los 15.7 de la segunda fila equivalen a 5.7530 + 9.9615). Si tienes una cantidad suficiente de dólares y metes una compra limitada a $130, entonces liquidarías las 5 posiciones que hay hasta ese nivel, incluido, y acabarías con 27.1 BTC en la cesta. Te costaría 5.7530*129 + 9.9615*129.96974 + .... dólares. Vamos, lo mismo que la rayita de la derecha en mtgoxlive (que creo que es la azul, pero ahora no me carga). Y en fin, la columna de buying, pues es lo mismo pero si quieres vender coins. Fíjate que aquí el orden de precios es a la inversa, porque naturalmente si pones una venta grande a mercado, al ir liquidando las posiciones, vas moviendo el precio a la baja.
|
|
|
Ya, suena bien pero no saco mis bitcoins de una página web para luego fiarme de otra página web. No quiero depender de nadie, quien me dice a mi que esa página no se está quedando con todas las claves privadas y más adelante hacen el robo del siglo. No, gracias, prefiero sacarlos y guardarnos yo personalmente.
Buen criterio. Pero esa web puedes guardarla, enviarla a un sistema offline y usarla perfectamente en él. Todos los cálculos son código javascript, que se ejecuta en el navegador sin tocar internet.
|
|
|
Ok. Ahora comprendido ya he visto donde está la dirección.
Sólo una cosa mas... ¿Si creo yo una nueva dirección, tiene que ser forzosamente una cadena de caracteres como lo es la dirección de base ?. ¿Que sentido tiene la creación de nuevas direcciones?
Sí, todas tienen la misma pinta. Esa dirección "de base" no tiene nada de especial, es sólo una más. Uno se crea varias direcciones para que cuando otros examinan la cadena de bloques, no puedan saber cuántas coins están asociadas a cada persona. Si todos tuviéramos una única dirección, naturalmente tendríamos que compartirla para poder operar y todo el mundo sabría el dinero que tenemos y dónde lo hemos gastado. Usando varias direcciones sólo una vez cada una, este problema no existe.
|
|
|
Ya te digo, menuda panda. Además no sé por qué cuando hay mucha actividad, se tiene que caer la web principal. ¿Es que no saben poner el mercado aparte?
Han dicho que ya estan testeando el sistema alternativo pero que no quieren sacarlo antes de tiempo y que traiga problemas. Asi que en principio deberia solucionarse pronto. Acabo de leer "The system is in testing now, but Mt. Gox hopes to have it live by the end of the year" aquí.
|
|
|
Vaya, curioso: ni siquiera te han cobrado el eurito que solían cobrar?
No, pero ya es la segunda vez que no me cobran. Y lo de las 4 horas para una transferencia SEPA nunca lo había visto, a mi siempre me ha tardado un día si la transferencia la hacía a primera hora de la mañana, o hasta dos días si la hacía por la tarde.
Para mí también es la primera vez. Se da la circunstancia de que he cobrado el sueldo esta misma mañana, así que quién sabe, a lo mejor cogieron la unspent output de la transfe de mi empresa y la reasignaron directamente a mtgox… .
|
|
|
Esta mañana he transferido otros 800€. No sólo me llegaron los 800 íntegros, sino que ni siquiera he tenido que esperar a mañana, en 4 horas y media está la pasta en Polonia O_o. Estos están viendo lo que se les echa encima y están espabilando (eso sí, diré que la transfe la hice a las 6 de la mañana).
|
|
|
You might want to add extra safeguards when it comes to input/output selection, to make sure that a user does not accidentally create a transaction with 94 BTC in fees
The usage flow reaches a point where the user is asked for a change address. This step is required. When an address is given, the balance in the inputs is completely assigned to the outputs (ie no fee at this point). Later, the fee is calculated, suggested and then the user confirms/overrides it. Granted, I could still check that the user entered a sane value but I would tag that as paranoid (I'm not implying that it's bad).
|
|
|
I've decided to publish the program I use to create custom transactions, given the level of noise this subject is generating lately. It's in Perl, for Linux, uses the module JSON::RPC::Client (available in the ubuntu package libjson-rpc-perl) and assumes a bitcoin configuration in the current user's ~/.bitcoin/bitcoin.conf. Here's a sample session: $ mktx.pl idx amount address btcdays grp vout 0) 18.43147597 1A7y8jy7xxxxxxxxxxxxxxxxxxxxxxxxxx 29.44 8 9c26c17f780e9e9415a6b8a58fxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:0 1) 13.30826540 19GgbRa5xxxxxxxxxxxxxxxxxxxxxxxxxx 144.73 0 9d7ffe1562756e216c92935a71xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:0 2) 9.00000000 18NAfDsdxxxxxxxxxxxxxxxxxxxxxxxxxx 1192.31 10 0ba6400f87c554b7e41d0fe8b8xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:1 3) 3.58293316 15HK4cyhxxxxxxxxxxxxxxxxxxxxxxxxxx 14.18 12 a2dad2d0289449b80850d77b2dxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:2 4) 2.57453211 1KXoabe8xxxxxxxxxxxxxxxxxxxxxxxxxx 349.31 0 5f94d690d75bca1becdc91cacdxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:0 5) 2.29610578 1ydDG6nxxxxxxxxxxxxxxxxxxxxxxxxxx 9.09 2 a2dad2d0289449b80850d77b2dxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:0 6) 1.83458911 1EmHjWp7xxxxxxxxxxxxxxxxxxxxxxxxxx 7.29 11 df64fb188d1965a6607032b502xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:1 7) 0.80863146 1LMUtqtJxxxxxxxxxxxxxxxxxxxxxxxxxx 3.21 6 df64fb188d1965a6607032b502xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:0 8) 0.59664818 1HyZb7Psxxxxxxxxxxxxxxxxxxxxxxxxxx 2.36 1 16703bc4ce9f35bd75a64e07e5xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:1
Select inputs (separated by spaces): 0 1 4
Enter outputs: destination address and amount separated by a space (enter to finish) Enter output (34.31427348 available): 12XCzX7ogxxxxxxxxxxxxxxxxxxxxxxxxx 26.34859225 Enter output (7.96568123 available):
Debug: inputs total amount is '34.31427348', assigned '26.34859225'
Enter address where to send 7.96568123 as change: new
Change will go to '1BZoDTY3NGr65axxxxxxxxxxxxxxxxxxxx'
Debug: estimated transaction size: 614 bytes (fee required at 10000 bytes or more) Debug: transaction priority: 122770.67M (fee required at 57.6M or less)
Enter desired fee (default 0): Enter wallet passphrase (needed for signing the transaction): A list of unspent outputs is shown, sorted by amount. The column "grp" shows the same number for the coins that are known to be linked, so using them as inputs doesn't leak any privacy. There's also a column showing bitcoindays to aid in the coin selection. The "vout" column is there just because. Enter the outputs that you want to use as the inputs of the new transaction, then enter the destination addresses and their amounts. You can create as many outputs as you want. Enter an empty line to finish this step, then you'll be asked for an address for the change. Note that I've entered 'new', you can enter 'new' in the previous step too. After that, the required fee is calculated and you are given the option to use the suggested one or override it with your own (ie you can pay a fee even if it isn't needed, or not pay a fee when you really should—use at your own risk!). The fee is deducted from the change output. As a last step, the program asks for the wallet encryption key in order to sign the transaction, then spits out the resulting data structure and, at the bottom, the raw serialized transaction is printed, so you can manually feed it to the sendrawtransaction RPC command or paste it in blochain.info/pushtx. Inputs and outputs are shuffled to enhance privacy (I don't think it's needed on inputs but decided to play safe) (outputs are implicitly shuffled due to the nature of Perl hashes). The fact that this program doesn't send the transaction itself is a feature, not a bug. Interestingly, the sample session is from a real transaction, which took 3 blocks to confirm even when its priority seems to be quite high. Criticism welcome (preferably constructive ). Update 2013-05-03: new version, that accept the parameter --list (or -l) to list the unpent outputs and exit. Update 2013-05-06: was applying a fee per 10 Kb instead of per Kb. Ouch. #!/usr/bin/perl
## TODO: could add: if ($fee) { print "you're paying %d satoshis per kb", $fee*1e8 / ($tx_size/1000); }
use warnings; use strict; use File::Spec; use Scalar::Util qw/looks_like_number/; use List::Util qw/min sum shuffle/; use Getopt::Long; use JSON::RPC::Client; use Data::Dumper;
my $MIN_FEE = 0.0005; my $cfgfile = File::Spec->catfile ($ENV{'HOME'}, '.bitcoin', 'bitcoin.conf'); my ($rpcuser, $rpcpass);
sub get_rpc { -f $cfgfile or die "bitcoin configuration not found\n";
open my $fd, '<', $cfgfile or die "open: '$cfgfile': $!"; while (<$fd>) { if (/^rpcuser=(.*)/) { $rpcuser = $1; } if (/^rpcpassword=(.*)/) { $rpcpass = $1; } } close $fd;
if (!$rpcuser or !$rpcpass) { die "can't find RPC credentials in bitcoin configuration\n"; }
my $url = "http://$rpcuser:$rpcpass\@localhost:8332/"; my $rpc = JSON::RPC::Client->new; $rpc->prepare ($url, [ qw/ createrawtransaction decoderawtransaction getnewaddress getrawtransaction listaddressgroupings listunspent signrawtransaction validateaddress walletpassphrase / ]);
return $rpc; }
sub addr2grp { my ($rpc) = @_;
my $groupings = $rpc->listaddressgroupings; my %addr2grp; foreach my $group_idx (0 .. $#$groupings) { foreach my $entry (@{ $groupings->[$group_idx] }) { $addr2grp{ $entry->[0] } = $group_idx; } } return %addr2grp; }
sub vouts { my ($rpc) = @_;
my $unspent = $rpc->listunspent;
my $vouts; foreach my $u (@$unspent) { my $rawtx = $rpc->getrawtransaction ($u->{'txid'}); $rawtx = $rpc->decoderawtransaction ($rawtx); my $vout = $rawtx->{'vout'}[$u->{'vout'}];
next if 'pubkeyhash' ne $vout->{'scriptPubKey'}{'type'} and 'scripthash' ne $vout->{'scriptPubKey'}{'type'};
$u->{'address'} = $vout->{'scriptPubKey'}{'addresses'}[0]; $u->{'btcdays'} = $u->{'amount'} * $u->{'confirmations'} / 144;
push @$vouts, $u; }
return $vouts; }
sub get_selected_outs { my ($largest_out) = @_;
print "\n"; OUTER: { print 'Select inputs (separated by spaces): '; my $selected_ins = <>; chomp $selected_ins; my @selected_ins = split /\s+/, $selected_ins; foreach my $in (@selected_ins) { if ($in !~ /^\d+$/) { warn "Error: invalid input '$in'\n"; redo OUTER; } if ($in > $largest_out) { warn "Error: input '$in' too large\n"; redo OUTER; } } return @selected_ins; } }
sub get_dests { my ($rpc, $avail) = @_;
my %dests; print "\nEnter outputs: destination address and amount separated by a space (enter to finish)\n"; while (1) { print "Enter output ($avail available): "; my $dest = <>; chomp $dest; if (!length $dest) { last if %dests; warn "enter at least one destination\n"; redo; }
my ($dest_addr, $dest_amnt) = split /\s+/, $dest; if (!defined $dest_amnt) { print "error: enter destination address and amount separated by a space\n"; next; } if (!looks_like_number $dest_amnt) { warn "amount '$dest_amnt' isn't a number\n"; redo; } if ($dest_amnt <= 0) { warn "amount '$dest_amnt' isn't positive\n"; redo; } if ('new' eq $dest_addr) { $dest_addr = $rpc->getnewaddress; print "Using address '$dest_addr'\n"; } if (!$rpc->validateaddress ($dest_addr)->{'isvalid'}) { warn "address '$dest_addr' is invalid\n"; redo; } if (exists $dests{$dest_addr}) { warn "there's already an output to that address\n"; redo; } if ($dest_amnt > $avail) { warn "Error: not enough funds in the selected inputs\n"; redo; }
$dests{$dest_addr} = 0+$dest_amnt; $avail = 0+sprintf '%.8f', $avail - $dest_amnt; last unless $avail; } print "\n"; return %dests; }
sub fee { my ($selected, $dests, $change_addr) = @_;
my $tx_size = 10 + 180*@$selected + 32*keys %$dests; print " Debug: estimated transaction size: $tx_size bytes (fee required at 10000 bytes or more)\n"; my $tx_size_ok = $tx_size < 10000;
my $smallest_out = min values %$dests; my $out_amounts_ok = $smallest_out >= 0.01;
my $tx_prio = sum map { $_->{'amount'}*10e8 * $_->{'confirmations'} } @$selected; $tx_prio /= $tx_size; my $tx_prio_ok = $tx_prio > 57_600_000; printf " Debug: transaction priority: %.2fM (fee required at 57.6M or less)\n", $tx_prio/1e6;
my $sugg_fee = 0; if (!$tx_size_ok || !$out_amounts_ok) { if (!$tx_size_ok) { print " Transaction too big ($tx_size bytes), fee recommended\n"; } if (!$out_amounts_ok) { print " Some of the outputs is smaller than 0.01 BTC ($smallest_out), fee recommended\n"; } my $rounded_tx_size = int ($tx_size / 1000); $rounded_tx_size++; $sugg_fee = $MIN_FEE * $rounded_tx_size; } if (!$tx_prio_ok) { print " Transaction priority too low ($tx_prio), fee recommended\n"; $sugg_fee += $MIN_FEE; }
print " Warning: a fee is recommended but this transaction hasn't a change output from which substract the fee\n" if $sugg_fee && !$change_addr; print " Warning: suggested fee is greater than the change output\n" if $change_addr and $sugg_fee > $dests->{$change_addr}; print "\nEnter desired fee (default $sugg_fee): "; my $fee = <>; chomp $fee; $fee ||= $sugg_fee; if (!$fee) { print " Warning: a fee is recommended\n" if $sugg_fee; return; } die "Error: no change output from which substract the fee\n" if $fee && !$change_addr; die "Error: fee is greater than the change output\n" if $change_addr and $fee > $dests->{$change_addr}; if ($fee == $dests->{$change_addr}) { delete $dests->{$change_addr}; ## oops, this alters the tx size, therefore it potentially affects the fee itself } else { $dests->{$change_addr} -= $fee; } }
###################################################
GetOptions \my %opts, '--list' or die "getopt failed\n";
my $rpc = get_rpc; my %addr_to_group = addr2grp $rpc; my $vouts = vouts $rpc or do { print "No funds\n"; exit; };
printf qq/%3s %12s %35s %8s %3s %66s\n/, qw/idx amount address btcdays grp vout/; my $index = 0; @$vouts = reverse sort { $a->{'amount'} <=> $b->{'amount'} } @$vouts; foreach my $vout (@$vouts) { #my $amnt = $vout->{'amount'}; if ($amnt !~ /\./) { $amnt .= '.'; } $amnt .= '00000000'; $amnt =~ s/(\..{8}).*/$1/; my $amnt = sprintf '%.8f', $vout->{'amount'}; printf qq/%2s) %12s %35s %8.2f %3s %s:%s\n/, $index, $amnt, @$vout{qw/address btcdays/}, $addr_to_group{ $vout->{'address'} }, @$vout{qw/txid vout/}; $index++; }
exit if $opts{'list'};
my @selected_ins = get_selected_outs $#$vouts;
my @selected = @$vouts[@selected_ins]; my $available_amnt = sum map { $_->{'amount'} } @selected;
my %dests = get_dests $rpc, $available_amnt; my $txamnt = sum values %dests;
my $unassigned = sprintf '%.8f', $available_amnt - $txamnt; my $change_addr; if ($unassigned >= 1e-8) { ## $unassigned may have extra decimal places due to floating point issues, see if those decimals ## are already present in these variables or they appear in the substraction above print " Debug: inputs total amount is '$available_amnt', assigned '$txamnt'\n\n"; { print "Enter address where to send $unassigned as change: "; $change_addr = <>; chomp $change_addr; if ('new' eq $change_addr) { $change_addr = $rpc->getnewaddress; print "\n Change will go to '$change_addr'\n"; } if (!$rpc->validateaddress ($change_addr)->{'isvalid'}) { warn "address '$change_addr' is invalid\n"; redo; } if (exists $dests{$change_addr}) { warn "there's already an output to that address\n"; redo; } $dests{$change_addr} = 0+$unassigned; last; } print "\n"; }
fee \@selected, \%dests, $change_addr;
my $ins = [ shuffle map { { txid => $_->{'txid'}, vout => 0+$_->{'vout'} } } @selected ]; my $outs = \%dests; my $tx = $rpc->createrawtransaction ([ $ins, $outs ]);
print 'Enter wallet passphrase (needed for signing the transaction): '; system 'stty -echo' and die "fork/exec: $!"; ## this could be improved my $wpp = <>; chomp $wpp; print "\n"; system 'stty echo' and die "fork/exec: $!";
$rpc->walletpassphrase ($wpp, 1); my $signed_tx = $rpc->signrawtransaction ($tx)->{'hex'}; my $decoded = $rpc->decoderawtransaction ($signed_tx); print Data::Dumper->Dump (sub{\@_}->(\$decoded), ['Transaction']); print "Raw: $signed_tx\n";
END { system 'stty echo'; }
|
|
|
Set the third parameter of importprivkey to false to avoid the blockchain rescan, then the operation is very quick. Do the rescan only on the last privkey you want to import.
|
|
|
Por cierto, menudo lag en MtGox. Cada vez que hay lag el precio se vuelve loco. Sería lo suyo que lo arreglaran de una vez.
Ya te digo, menuda panda. Además no sé por qué cuando hay mucha actividad, se tiene que caer la web principal. ¿Es que no saben poner el mercado aparte?
|
|
|
Un mercado no es más que un montón de puestos de naranjas, cada uno de los cuales opera a su precio. Si tú entras al mercado con la intención de gastar 500€ ahora mismo y buscas el puesto de naranjas más barato, te encontrarás con que ahí sólo puedes gastar 120€ (y les dejas sin naranjas), entonces buscas el siguiente puesto más barato (que ahora es un poquito más caro que el otro) y gastas todo lo que puedas, luego buscas el siguiente y así sucesivamente hasta que consigues gastar los 500€. Eso se llama operar a precio de mercado; el mercado pone los precios y tú operas instantáneamente.
Por otro lado, con las órdenes limitadas tú pones el precio. Entras al mercado con 500€ y buscas puestos de naranjas donde las tengan a 1 €/kg (o más baratas). Si encuentras, les compras todas las naranjas. Si consigues gastar los 500€ ahí mismo, genial, fin del asunto. Si no tienen suficientes naranjas para gastar los 500€, entonces te quedas con algunas naranjas en la cesta y algunos euros en el bolsillo. No puedes gastar más euros porque no hay más puestos de naranjas a 1 €/kg. Te das un paseo y esperas hasta que a) aparece otro puesto de naranjas a ese precio, al cual acudes rápidamente para comprar más, o b) cada vez los puestos que aparecen van teniendo un precio más caro y te quedas sin poder comprar a 1 €/kg.
No se puede gastar todo el dinero instantáneamente al precio que uno quiera, excepto que haya un puesto de naranjas con suficientes existencias, pero uno no tiene control sobre eso.
Los distintos puestos de naranja, la cantidad de naranjas que tienen y el precio al que las venden, son el listado de ventas que aparece en los book orders de las webs. El otro listado es el de compras (para cuando uno va al mercado a vender naranjas, no a comprarlas) y funciona exactamente igual.
|
|
|
O sea, obtengo error entre los bloques 1 y 59571 inclusive (el 0 funciona, pero ese es especial).
Ocurre que mi blk00000.dat contiene el bloque 0 y a continuación un montón de preciosos ceritos hasta llegar a los 16 Mb, entonces a partir de ahí empieza a haber datos de nuevo. Si busco el siguiente bloque, está un poquito más abajo y, magia, resulta ser el 59573. Así que el 0 no tiene nada de especial, simplemente funciona porque está en el archivo. El 59572 chuta pero sólo parcialmente: $ bitcoind getblock $(bitcoind getblockhash 59572) { "hash" : "4d9862b15cdc472aa7c0837287b01cd58f230dc18360f81d36ba1e47cbf7300b", "confirmations" : 0, "size" : 215, "height" : 59572, "version" : 0, [...] Los valores de hash, confirmations y version son incorrectos.
|
|
|
Sí, hace un rato no había nada entre $130 y $137. Bastante hueco el asunto, ciertamente…
|
|
|
He leído un poco sobre el Bitcoin pero me surge una duda básica ¿cómo es posible que al crear la dirección privada sea única sin necesidad de conectarse a internet ni necesidad de IPs ni de servidores? no me cuadra. No tienes un 100% de certeza de que la clave privada no sea única, pero sí tienes un 99.99999999999999999999999999999999999999999% de certeza (no he contado los nueves, y probablemente me haya quedado corto ). Tampoco me cuadra que se pueda generar la dirección privada a partir de la pública y no se pueda hacer al revés, gracias.
Lo has dicho al revés . Se puede generar la pública a partir de la privada, no la privada a partir de la pública. Te voy a dar un ejemplo que tiene muy poquito que ver con este problema en concreto, pero que te puede servir para hacerte una idea de que sí es posible: acabo de sumar 7 números enteros entre 1 y 100 y el resultado es 257. ¿Sabrías decirme cuáles son los números que he sumado?
|
|
|
Not getting into the mining business in 2011. My motherboard is an old one, without PCI-E sockets, and I didn't want to renew the whole computer since it worked (and works) fine.
|
|
|
This thread doesn't work anymore.
I am pretty confident it will work again as soon as it dies and is re-discovered some months later when we hit $1000. So please let's keep it alive, who knows, maybe it's now working in the opposite direction!
|
|
|
Madre mía, 105€… estoy por pedir un adelanto de sueldo .
|
|
|
¿Hay más diseños disponibles? / Any additional designs available?
|
|
|
Later when the game is complete I would publish the seed
Ah, when the game is complete and the server secret is no longer valid, of course!
|
|
|
What's $MAX_CARDS? 6? So you're selecting the 50 cards from 6 decks of 32 cards?
Yes. Initially 32 cards were shown but at some later point I decided to make a better usage of the screen real state and upped it to 50. (And earlier than that, my original plan was to always show all cards between 7-clubs to ace-spaces once, like when using a real deck). The way this is usually done is to shuffle the decks using a seed derived by combining the site secret and the client secret (the block hash, in this case). So you can prove that you had no control over the selection of the 50 cards.
Thanks for this insight. The client secret could perfectly be the game ID (randomly generated but trivially editable by the user). The server side has to be the pre-generated secret I alluded to. Even if you pre-generate the sets of 50 cards, you still can't prove that they were fairly selected. You could still pick more 7's than Aces.
I can use a known PRNG (e.g. ISAAC, which has a readily available Perl implementation) with a given seed to generate the cards, and publish a hash of the seed. The seed would be created from the client and server secrets. Later when the game is complete I would publish the seed and give the details of the card generation.
|
|
|
|