Bitcoin Forum
June 16, 2024, 12:05:04 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 [243] 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 »
4841  Local / Mercado y Economía / Re: ! on: April 04, 2013, 05:56:12 PM
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:

Code:
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.
4842  Local / Español (Spanish) / Re: WALLET EN PAPEL on: April 04, 2013, 05:33:46 PM
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.
4843  Local / Hardware y Minería / Re: Bitcoin Dirección. Ayuda ? on: April 04, 2013, 02:56:14 PM
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.
4844  Local / Español (Spanish) / Re: Que sospechoso, no? on: April 04, 2013, 01:50:46 PM
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í.
4845  Local / Español (Spanish) / Re: Comisión de MtGox on: April 04, 2013, 10:25:04 AM
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… Tongue.
4846  Local / Español (Spanish) / Re: Comisión de MtGox on: April 04, 2013, 08:50:18 AM
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 Cheesy Cheesy (eso sí, diré que la transfe la hice a las 6 de la mañana).
4847  Bitcoin / Development & Technical Discussion / Re: My own coin control utility on: April 04, 2013, 08:01:05 AM
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).
4848  Bitcoin / Development & Technical Discussion / My own coin control utility on: April 03, 2013, 09:50:44 PM
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:

Code:
$ 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 Wink).

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.

Code:
#!/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'; }


4849  Bitcoin / Development & Technical Discussion / Re: Only 2 keys/sec added with importprivkey ? on: April 03, 2013, 09:03:40 PM
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.
4850  Local / Español (Spanish) / Re: Que sospechoso, no? on: April 03, 2013, 08:07:51 PM
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?
4851  Local / Mercado y Economía / Re: Dudas MTGOX on: April 03, 2013, 05:19:36 PM
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.
4852  Local / Español (Spanish) / Re: Bitcoin se me muere al hacer un getblock de los bloques 1 al 59571 on: April 03, 2013, 11:49:01 AM
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:

Code:
$ bitcoind getblock $(bitcoind getblockhash 59572)
{
    "hash" : "4d9862b15cdc472aa7c0837287b01cd58f230dc18360f81d36ba1e47cbf7300b",
    "confirmations" : 0,
    "size" : 215,
    "height" : 59572,
    "version" : 0,
[...]

Los valores de hash, confirmations y version son incorrectos.
4853  Local / Trading y especulación / Re: Boletín de Análisis Técnico on: April 03, 2013, 10:00:44 AM
Bien, bien  Roll Eyes  ¿Has visto la profundidad? http://mtgoxlive.com/orders

Sí, hace un rato no había nada entre $130 y $137. Bastante hueco el asunto, ciertamente…
4854  Local / Español (Spanish) / Re: Dirección pública y privada, dudas on: April 03, 2013, 09:57:34 AM
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 Tongue).

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 Wink. 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?
4855  Bitcoin / Bitcoin Discussion / Re: What are the biggest mistakes you've done with Bitcoin? on: April 03, 2013, 09:01:46 AM
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.
4856  Bitcoin / Bitcoin Discussion / Re: I am pretty confident we are the new wealthy elite, gentlemen. on: April 03, 2013, 08:38:30 AM
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! Cheesy
4857  Local / Trading y especulación / Re: Boletín de Análisis Técnico on: April 03, 2013, 07:17:19 AM
Madre mía, 105€… estoy por pedir un adelanto de sueldo Cheesy.
4858  Local / Mercado y Economía / Re: Bitcoin T-Shirts - Now Available on: April 02, 2013, 10:19:48 PM
¿Hay más diseños disponibles? / Any additional designs available?
4859  Economy / Gambling / Re: FlipSide - Prizes almost 5 million times your bet! on: April 02, 2013, 10:17:49 PM
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!
4860  Economy / Gambling / Re: FlipSide - Prizes almost 5 million times your bet! on: April 02, 2013, 09:22:46 PM
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.
Pages: « 1 ... 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 [243] 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!