Hay algún matiz, De momento si te roban el movil con la wallet de Handcash 2.5 y sin tener copia de la seed, el dueño puede recuperar los fondos, aunque el ladrón no te devuelva el movil y suponiendo que el ladrón no puede desbloquear el movil, NI pueda acceder a la wallet.

Pero creo que la frase va un poco más allá, porque en realidad los ladrones no quieren devolver nada de lo robado, salvo que la Ley se lo imponga, y eso me hace pensar en otra cosa que no tiene precisamente que ver con Handcash, sino mas bien con lo que Craig ha dicho sobre congelar fondos cuando hay un litigio legal (Ejemplo denuncio la pérdida o que me han robado mis fondos y lo puedo demostrar), en ese caso si la justicia hace las comprobaciones necesarias para ver la legitimidad de los fondos, entonces se le pueden devolver a su legítimo dueño, trazando el movimiento de los fondos desde que se robaron, congelandolos y finalmente devolviendolos (el plomo vuelve a set oro)

"Forgot to add the good part about micropayments. While I don't think Bitcoin is practical for smaller micropayments right now, it will eventually be as storage and bandwidth costs continue to fall. If Bitcoin catches on on a big scale, it may already be the case by that time. Another way they can become more practical is if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms. Whatever size micropayments you need will eventually be practical. I think in 5 or 10 years, the bandwidth and storage will seem trivial".

satoshi
Founder
Sr. Member

226 Bitcoin / Bitcoin Discussion /
Re: Flood attack 0.00000001 BC
on: August 05, 2010

https://bitcointalk.org/index.php?action=profile;u=3;sa=showPosts;start=2

226 Bitcoin / Bitcoin Discussion /
Re: Flood attack 0.00000001 BC
on: August 05, 2010

Forgot to add the good part about micropayments. While I don't think Bitcoin is practical for smaller micropayments right now, it will eventually be as storage and bandwidth costs continue to fall. If Bitcoin catches on on a big scale, it may already be the case by that time. Another way they can become more practical is if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms. Whatever size micropayments you need will eventually be practical. I think in 5 or 10 years, the bandwidth and storage will seem trivial.

I am not claiming that the network is impervious to DoS attack. I think most P2P networks can be DoS attacked in numerous ways. (On a side note, I read that the record companies would like to DoS all the file sharing networks, but they don't want to break the anti-hacking/anti-abuse laws.)

If we started getting DoS attacked with loads of wasted transactions back and forth, you would need to start paying a 0.01 minimum transaction fee. 0.1.5 actually had an option to set that, but I took it out to reduce confusion. Free transactions are nice and we can keep it that way if people don't abuse them.

That brings up the question: if there was a minimum 0.01 fee for each transaction, should we automatically add the fee if it's just the minimum 0.01? It would be awfully annoying to ask each time. If you have 50.00 and send 10.00, the recipient would get 10.00 and you'd have 39.99 left. I think it should just add it automatically. It's trivial compared to the fees many other types of services add automatically.

satoshi
Founder
Sr. Member

https://bitcointalk.org/index.php?action=profile;u=3;sa=showPosts;start=220

257 Bitcoin / Development & Technical Discussion /
Re: Scalability and transaction rate
on: July 29, 2010, 02:00:38 AM

The current system where every user is a network node is not the intended configuration for large scale. That would be like every Usenet user runs their own NNTP server. The design supports letting users just be users. The more burden it is to run a node, the fewer nodes there will be. Those few nodes will be big server farms. The rest will be client nodes that only do transactions and don't generate.

Quote from: bytemaster on July 28, 2010, 08:59:42 PM
Besides, 10 minutes is too long to verify that payment is good. It needs to be as fast as swiping a credit card is today.

See the snack machine thread, I outline how a payment processor could verify payments well enough, actually really well (much lower fraud rate than credit cards), in something like 10 seconds or less. If you don't believe me or don't get it, I don't have time to try to convince you, sorry.
http://bitcointalk.org/index.php?topic=423.msg3819#msg3819

satoshi
Founder
Sr. Member
https://bitcointalk.org/index.php?action=profile;u=3;sa=showPosts;start=240

Bruce Wagner
https://t.me/joinchat/VyJU2cMWhxMJwC-q

10. Calculations and Conclusion - The Bitcoin White Paper - Dr. Craig S. Wright & Ryan X. Charles
28 dic 2020
https://www.youtube.com/watch?v=dSwu-9j1thY&feature=youtu.be

Parece que esto va a ser de lo que se va a hablar hoy
bitcoin:
Bitcoin Sets New All-Time High Above $28.5K; Bulls Back in the Driver’s Seat
https://www.coindesk.com/bitcoin-sets-new-all-time-high-of-28570-02-bulls-back-in-the-drivers-seat

Institutional investors are perceived to be driving this record-setting run.

"No queremos liderar con "anónimos". (He querido editar la página de inicio)

"Los desarrolladores esperan que esto resulte en una moneda estable con respecto a la energía fuera del alcance de cualquier gobierno". - Definitivamente no estoy haciendo tal burla o afirmación.

No es estable con respecto a la energía. Hubo una discusión sobre esto. No está ligado al costo de la energía. La estimación de NLS basada en la energía fue un buen punto de partida estimado, pero las fuerzas del mercado dominarán cada vez más.

Siento ser una manta mojada. Escribir una descripción de esto para el público en general es muy difícil. No hay nada con lo que relacionarlo".

satoshi
Fundador
Miembro Sr.

05 de julio de 2010
https://bitcointalk.org/index.php?action=profile;u=3;sa=showPosts;start=360

U°Today
🔥 BREAKING: Coinbase Sued Over "Illegal" XRP Sales https://u.today/breaking-coinbase-sued-over-illegal-xrp-sales
@

Espero que un amigo, me permita compartir sus pensamientos, porque realmente sé que lo ha dicho con el corazón en la mano y es todo un alegato al valor:

"Si te ataca alguien más fuerte, puedes morir defendiendo lo correcto, o vivir para luchar otro día...

y cuando llegue el lecho de muerte, daría todos los días desde hoy, hasta el fin de tus días, para volver aquí y luchar contra nuestros enemigos... podrán quitarnos la vida, podrán quitarnos los cuartos... pero jamás nos quitarán LA LIBERTAAAAAD".

Augusto.

La plataforma criptográfica Etoro se detiene en los Países Bajos, los usuarios tienen que vender

Cryptoplatform Etoro stopt in Nederland, gebruikers moeten verkopen | RTL Nieuws
https://www.rtlnieuws.nl/economie/bedrijven/artikel/5205908/cryptoplatform-etoro-stopt-dnb-registratie-crypto-bitcoin

"A second version would be a massive development and maintenance hassle for me. It's hard enough maintaining backward compatibility while upgrading the network without a second version locking things in. If the second version screwed up, the user experience would reflect badly on both, although it would at least reinforce to users the importance of staying with the official version. If someone was getting ready to fork a second version, I would have to air a lot of disclaimers about the risks of using a minority version. This is a design where the majority version wins if there's any disagreement, and that can be pretty ugly for the minority version and I'd rather not go into it, and I don't have to as long as there's only one version".


satoshi
Fundador
Miembro Sr.

Re: Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIG
on: June 18, 2010, 04:17:14 PM
https://bitcointalk.org/index.php?action=profile;u=3;sa=showPosts;start=400

417 Bitcoin / Development & Technical Discussion /
Re: Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIG
on: June 18, 2010, 04:17:14 PM

A second version would be a massive development and maintenance hassle for me. It's hard enough maintaining backward compatibility while upgrading the network without a second version locking things in. If the second version screwed up, the user experience would reflect badly on both, although it would at least reinforce to users the importance of staying with the official version. If someone was getting ready to fork a second version, I would have to air a lot of disclaimers about the risks of using a minority version. This is a design where the majority version wins if there's any disagreement, and that can be pretty ugly for the minority version and I'd rather not go into it, and I don't have to as long as there's only one version.

I know, most developers don't like their software forked, but I have real technical reasons in this case.

Quote from: gavinandresen on June 17, 2010, 07:58:14 PM
I admire the flexibility of the scripts-in-a-transaction scheme, but my evil little mind immediately starts to think of ways I might abuse it. I could encode all sorts of interesting information in the TxOut script, and if non-hacked clients validated-and-then-ignored those transactions it would be a useful covert broadcast communication channel.

That's a cool feature until it gets popular and somebody decides it would be fun to flood the payment network with millions of transactions to transfer the latest Lady Gaga video to all their friends...
That's one of the reasons for transaction fees. There are other things we can do if necessary.

Quote from: laszlo on June 17, 2010, 06:50:31 PM
How long have you been working on this design Satoshi? It seems very well thought out, not the kind of thing you just sit down and code up without doing a lot of brainstorming and discussion on it first. Everyone has the obvious questions looking for holes in it but it is holding up well Smiley
Since 2007. At some point I became convinced there was a way to do this without any trust required at all and couldn't resist to keep thinking about it. Much more of the work was designing than coding.

Fortunately, so far all the issues raised have been things I previously considered and planned for.



satoshi
Fundador
Miembro Sr.

https://bitcointalk.org/index.php?action=profile;u=3;sa=showPosts;start=400

Satoshi ya se guardó un As en la manga, por si alguien le hacia un fork de su cadena, y aun no hemos visto el As!!!!! "... If someone was getting ready to fork a second version, I would have to air a lot of disclaimers about the risks of using a minority version. This is a design where the majority version wins if there's any disagreement, and that can be pretty ugly for the minority version and I'd rather not go into it, and I don't have to as long as there's only one version".

satoshi
Fundador
Miembro Sr.
on: June 18, 2010

https://bitcointalk.org/index.php?action=profile;u=3;sa=showPosts;start=400