|
Armory depende de bitcoind. El procesador seguramente tiene caña porque bitcoind está validando transacciones durante la sincronización.
|
|
|
|
Mi análisis mega-técnico. Los fines de semana suelen ser moviditos muchas veces. Hoy es viernes y mañana sábado. Este finde toca corrección. Me lo han dicho las velas. Las que le he puesto a San Cristobal  Pues parece que tu lectura de velas esta siendo correcta. A estas horas ya no tanto  . |
|
|
|
That is a flawed understanding of the fee rules. High priority txs have no required fee, none. As in 0 satsohis. This applies regardless if a block is 1MB in size.
The min mandatory fees FOR LOW PRIORITY TXS are designed as a denial of service prevention mechanism. They are only enforced at the client level. Even if miners follow those they have absolutely no effect on high priority txs.
I don't think this is correct. Under the Satoshi client's fee rules (which as I understand are enforced by most, but certainly not all, miners), high priority transactions with no fees will only be included in the first 27 kB of a block (this limit can be changed with the blockprioritysize option). Once the block hits this limit, only fee-paying transactions will be included, regardless of priority. FWIW all my transactions are high priority ones and I've observed a steep increase in confirmation times, going up to nine hours in some cases, when their priority reaches several thousand million. |
|
|
|
o un canal irc en español?
#bitcoin-es en freenode. |
|
|
|
Would this path work:
1. Only one localbtc to buy coins.
2. Send from localbtc to bc.info Wallets A and B
3. b.info Wallet A sends to Electrum A
4. b.info Wallet B sends to Electrum B
Would electrum A and B still have linkage due to the original localbtc wallet?
Yes, albeit a weaker one since there's an intermediate transaction in between. |
|
|
|
Y sobre eso ya escribí antes: Por mi parte no me produce mayor inquietud la posibilidad de que la BF acuerde con el gobierno estadounidense algún tipo de modificación en la esencia y prinicipios básicos del Bitcoin. Lo que generarían sería una nueva moneda, un fork más a los ya existentes y que ya no podría seguir denominándose Bitcoin. ¿Dónde está el problema?
Está en que el rebaño y la gente con pasta irían donde el gobierno les dice que vayan. |
|
|
|
Tengo gente en Atenas. Depende de lo que se trate, les puedo decir algo. Bueno, y en Chile también, pero para eso tengo 2 grados de separación . |
|
|
|
El próximo lunes voy a lanzar otra compra, esta vez la haré por OpenBank, a ver que tal.
En este caso díselo porque el traspaso será inmediato y si él está pendiente, completáis la operación en cuestión de minutos. Como debe ser  . |
|
|
|
i got inside info>>> CHUCK NORRIS IS BUYING IN@450!!!!
So why aren't we at 9000 already? |
|
|
|
Una forma de evitar el marcado de coins y la separación de coins "buenas" y "malas" es convertir a todas en malas, por ejemplo mezclándolas compulsivamente. De esta forma no quedarían coins "buenas" en la cadena de bloques y cualquier intento de separarlas sería inútil. Quiero animaros a contribuir a la implementación de CoinJoin, una forma de realizar transacciones en la que varias personas se ponen de acuerdo para mezclar sus coins entre sí, e idealmente nadie sabría cómo se corresponden las salidas con las entradas. Tener esto implementado en los clientes sería una forma técnicamente viable de frustrar cualquier intento de marcar coins. El mezclado incluso podría ocurrir de forma automática, sin que uno tenga que preocuparse de ello. La dirección para contribuir a este proyecto es 3M8XGFBKwkf7miBzpkU3x2DoWwAVrD1mhk. Es una multisig 2-de-3, generada a partir de claves públicas de gmaxwell, theymos y sipa. Theymos ha mencionado, además, que donará otra vez cualquier cosa que pase de 16.21 BTC (el importe que había en la dirección cuando él publicó eso) con un máximo de 5 BTC, de forma que lo que donemos los demás será en efecto el doble. Ya hay 17 BTC en el bote. Cada céntimo cuenta! |
|
|
|
|
Pero esto es lo que salió hace una semana o dos, no?
|
|
|
|
Debido a eso, si todo mi saldo se encuentra en direcciones que nunca han sido origen de pagos podré dormir más tranquilo, ya que estoy protegido por la seguridad criptográfica de tres operaciones: 1/ la generación aleatoria de la clave privada, 2/ el cálculo de clave pública mediante el algoritmo ECDSA y 3/ el cálculo de dirección mediante dos rondas de SHA-256. Quienes reutilizan direcciones pierden este tercer nivel de seguridad. Esto sería fatal si un día alguien rompiera el algoritmo ECDSA encontrando un algoritmo inverso para pasar de la clave pública a la privada.
Y es más: quien realiza pagos repetidos usando la misma clave privada para firmar, publica no solo la clave pública (la misma, varias veces) sino varias firmas hechas con la misma clave privada. Esto va reduciendo poco a poco el esfuerzo que hay que hacer para averiguar la clave privada a partir de las firmas conocidas. Los usuarios de android lo saben bien… De acuerdo que la reducción en ese esfuerzo no es significativa hoy en día (excepto bugs gordos como el que ya hemos visto) pero dentro de X meses o años puede descubrirse una vulnerabilidad en ECDSA así en plan "con 8 firmas te averiguo la clave privada en una semana". Y no debemos olvidar que la NSA está en el ajo. En fin, que no reutilicéis direcciones. Yo por mi parte he quitado el "Firstbits: 12345" que tenía ahí debajo de kitty, y en mi perfil he editado el campo "Your bitcoin address". |
|
|
|
Me preguntaba que hacíais la mayoría de vosotros con los bitcoins que comprais en las paginas como Bitstamp, mtgox y btc-e, los dejáis en el saldo de la web o los transferís a vuestro monederos donde están 100% seguros y si la página cierra pues no tienes problemas de que tu pasta vuele.
Eso depende de lo que haga cada uno. Yo especulo a corto plazo con parte de los fondos, por lo que eso tiene que estar forzosamente en el mercado. La otra parte está a buen recaudo fuera de internet. Otros tendrán otras estrategias. |
|
|
|
When I open an electrum wallet, several receiving addresses are generated. Are these linked to each other in some way? For example, I designate one address for receiving from Bob and a different address for receiving from Joe, will Bob and Joe's transactions be linked? They may be linked in the future when you spend those coins. If you go through bc.info, then the buys will be linked when you transfer all funds from bc.info to your wallet. |
|
|
|
Tendré que usar más la opción de previsualizar.[/size][/i]
Yo me acostumbré a usar esto en otro foro donde se recomendaba de vez en cuando. Tanto en aquel sitio como aquí he llegado a previsualizar hasta 8 veces antes de publicar . Edito  : y es que en aquel foro no solamente se recomendaba, sino que la primera vez que escribías el mensaje no tenías la opción de publicar, sólo la de previsualilzar. Sólo después de previsualizar una vez ya te salía el botoncito de "Post". |
|
|
|
Esta incertidumbre me mata  ... Pienso que vamos para arriba. Voto por rallie lateral... ¿Esto es técnico o chamánico? |
|
|
|
Otros clientes, como Electrum que ya mencionaron, permiten desactivar esta función.
Lo cual es una mala idea. Las direcciones deben usarse una única vez, por seguridad y por privacidad. Bitcoin está diseñado con este principio, quien lo diseñó no hizo que hubiera 2^160 direcciones posibles por gusto, lo hizo para que nunca nos fueran a faltar. |
|
|
|
CoinJoin needs to be nicely implemented in Bitcoin-Qt before any of these ridiculous blacklist proposals take off. So for the next 30 days, I will match donations to the CoinJoin bounty fund (3M8XGFBKwkf7miBzpkU3x2DoWwAVrD1mhk), up to a maximum of 5 BTC.
Way to go! I'm upping my offer from 0.50 to 0.75 but please tell Pieter to sign his pubkey in the second message of this thread. Thank you! |
|
|
|
Key from Pieter (pgp signature to be provided later):
0292782efcb08d621c360d055f407c8e75ffbbd06f6b7009c1432ca9eaa6732592 Oops, seems that a signature was forgotten . I'll donate half a coin to this as soon as the sig is in place! Please everyone consider donating. |
|
|
|
|
Show Posts
