The Cryptography Mailing List. (2008)

/0 Comentarios/en , , /por

The Cryptography Mailing List

https://www.metzdowd.com/pipermail/cryptography/

 

Ésta es la Lista de Correos de Criptografía, donde Satoshi Nakamoto publica por primeva vez el White Paper de Bitcoin el día 31 de octubre del 2008, por favor NO confundir con la Lista de Correos Cypherpunk, Cypherpunks Mailing List o The cypherpunks Archives https://lists.cpunks.org/pipermail/cypherpunks/, en esta lista de correos, el 31 Octubre del 2008 NO se publicó el WP,  se REENVIÓ una copia de la publicación de Satoshi, el día 1 de nov del 2008 (Fwd: Bitcoin P2P e-cash paper   R.A. Hettinga)

 

Bitcoin P2P e-cash paper

https://www.metzdowd.com/pipermail/cryptography/2008-October/014810.html

Satoshi Nakamoto satoshi at vistomail.com
Fri Oct 31 14:10:00 EDT 2008

I've been working on a new electronic cash system that's fully
peer-to-peer, with no trusted third party.

The paper is available at:
http://www.bitcoin.org/bitcoin.pdf

The main properties:
 Double-spending is prevented with a peer-to-peer network.
 No mint or other trusted parties.
 Participants can be anonymous.
 New coins are made from Hashcash style proof-of-work.
 The proof-of-work for new coin generation also powers the
    network to prevent double-spending.

Bitcoin: A Peer-to-Peer Electronic Cash System

Abstract.  A purely peer-to-peer version of electronic cash would
allow online payments to be sent directly from one party to another
without the burdens of going through a financial institution.
Digital signatures provide part of the solution, but the main
benefits are lost if a trusted party is still required to prevent
double-spending.  We propose a solution to the double-spending
problem using a peer-to-peer network.  The network timestamps
transactions by hashing them into an ongoing chain of hash-based
proof-of-work, forming a record that cannot be changed without
redoing the proof-of-work.  The longest chain not only serves as
proof of the sequence of events witnessed, but proof that it came
from the largest pool of CPU power.  As long as honest nodes control
the most CPU power on the network, they can generate the longest
chain and outpace any attackers.  The network itself requires
minimal structure.  Messages are broadcasted on a best effort basis,
and nodes can leave and rejoin the network at will, accepting the
longest proof-of-work chain as proof of what happened while they
were gone.

Full paper at:
http://www.bitcoin.org/bitcoin.pdf

Satoshi Nakamoto

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

El Libro Blanco de Bitcoin, de Satoshi Nakamoto –

The BitCoin White Paper

El Libro Blanco de Bitcoin, de Satoshi Nakamoto – BitCoin White Paper

The Cryptography Mailing List

The cryptography Archives

https://www.metzdowd.com/pipermail/cryptography/

You can get more information about this list.

November 2009: [ Thread ] [ Subject ] [ Author ] [ Date ] [ Gzip’d Text 83 KB ]
October 2009: [ Thread ] [ Subject ] [ Author ] [ Date ] [ Gzip’d Text 52 KB ]

November 2008 Archives by date

https://www.metzdowd.com/pipermail/cryptography/2008-November/date.html

Las 14 referencias directas de Satoshi en The Cryptography Mailing List, en noviembre de 2008.

https://www.metzdowd.com/pipermail/cryptography/

 

1-Nov 2 20:37 Simplified Payment Verification (section 8)

https://www.metzdowd.com/pipermail/cryptography/2008-November/014815.html

Mensaje de referencia previo:

«Long before the network gets anywhere near as large as that, it would be safe for users to use Simplified Payment Verification (section 8) to check for double spending, which only requires having the chain of block headers, or about 12KB per day. Only people trying to create new coins would need to run network nodes. At first, most users would run network nodes, but as the network grows beyond a certain point, it would be left more and more to specialists with server farms of specialized hardware. A server farm would only need to have one node on the network and the rest of the LAN connects with that one node.

The bandwidth might not be as prohibitive as you think. A typical transaction would be about 400 bytes (ECC is nicely compact). Each transaction has to be broadcast twice, so lets say 1KB per transaction. Visa processed 37 billion transactions in FY2008, or an average of 100 million transactions per day. That many transactions would take 100GB of bandwidth, or the size of 12 DVD or 2 HD quality movies, or about $18 worth of bandwidth at current prices.

If the network were to get that big, it would take several years, and by then, sending 2 HD movies over the Internet would probably not seem like a big deal».

Satoshi Nakamoto

2- Nov 3 11:23 2008  Thanks for bringing up that point.
https://www.metzdowd.com/pipermail/cryptography/2008-November/014818.html

Mensaje de referencia anterior 

Correo de Satoshi REENVIADO A la Lista de Correos Cypherpunk, Cypherpunks Mailing List

https://lists.cpunks.org/pipermail/cypherpunks-legacy/2008-November/155261.html

«There would be many smaller zombie farms that are not big enough to overpower the network, and they could still make money by generating bitcoins. The smaller farms are then the «honest nodes». (I need a better term than «honest») The more smaller farms resort to generating bitcoins, the higher the bar gets to overpower the network, making larger farms also too small to overpower it so that they may as well generate bitcoins too. According to the «long tail» theory, the small, medium and merely large farms put together should add up to a lot more than the biggest zombie farm.

Even if a bad guy does overpower the network, it’s not like he’s instantly rich. All he can accomplish is to take back money he himself spent, like bouncing a check. To exploit it, he would have to buy something from a merchant, wait till it ships, then overpower the network and try to take his money back. I don’t think he could make as much money trying to pull a carding scheme like that as he could by generating bitcoins. With a zombie farm that big, he could generate more bitcoins than everyone else combined.

The Bitcoin network might actually reduce spam by diverting zombie farms to generating bitcoins instead.»

Satoshi Nakamoto

3-  Nov 6 15:15  2008 battle in the arms race

https://www.metzdowd.com/pipermail/cryptography/2008-November/014823.html

«Yes, but we can win a major battle in the arms race and gain a new territory of freedom for several years.

Governments are good at cutting off the heads of a centrally controlled networks like Napster, but pure P2P networks like Gnutella and Tor seem to be holding their own.»

Satoshi

«Sí, pero podemos ganar una batalla importante en la carrera armamentista y ganar un nuevo territorio de libertad durante varios años.

Los gobiernos son buenos cortando «las cabezas» de las redes controladas centralizadamente como Napster, sin embargo, las redes P2P puras como Gnutella y Tor parecen mantenerse firmes «.

Satoshi

4- Nov 8 13:54:38 EST 2008   Ray Dillinger
https://www.metzdowd.com/pipermail/cryptography/2008-November/014831.html

«Increasing hardware speed is handled: «To compensate for increasing hardware speed and varying interest in running nodes over time, the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour. If they’re generated too fast, the difficulty increases.«

As computers get faster and the total computing power applied to creating bitcoins increases, the difficulty increases proportionally to keep the total new production constant. Thus, it is known in advance how many new bitcoins will be created every year in the future.

The fact that new coins are produced means the money supply increases by a planned amount, but this does not necessarily result in inflation. If the supply of money increases at the same rate that the number of people using it increases, prices remain stable. If it does not increase as fast as demand, there will be deflation and early holders of money will see its value increase.

Coins have to get initially distributed somehow, and a constant rate seems like the best formula.»

Satoshi Nakamoto

Bitcoin Halving & Subsidy        https://ramonquesada.com/english/bitcoin-halving/

5- Nov 8 13:54:38 EST 2008  Hal Finney
https://www.metzdowd.com/pipermail/cryptography/2008-November/014832.html

«The attacker isn’t adding blocks to the end. He has to go back and redo the block his transaction is in and all the blocks after it, as well as any new blocks the network keeps adding to the end while he’s doing that. He’s rewriting history. Once his branch is longer, it becomes the new valid one.

This touches on a key point. Even though everyone present may see the shenanigans going on, there’s no way to take advantage of that fact.

It is strictly necessary that the longest chain is always considered the valid one. Nodes that were present may remember that one branch was there first and got replaced by another, but there would be no way for them to convince those who were not present of this. We can’t have subfactions of nodes that cling to one branch that they think was first, others that saw another branch first, and others that joined later and never saw what happened. The CPU power proof-of-work vote must have the final say. The only way for everyone to stay on the same page is to believe that the longest chain is always the valid one, no matter what».

I appreciate your questions.  (Hal Finney) I actually did this kind of backwards. I had to write all the code before I could convince myself that I could solve every problem, then I wrote the paper. I think I will be able to release the code sooner than I could write a detailed spec. You’re already right about most of your assumptions where you filled in the blanks». 

Satoshi Nakamoto

«Agradezco tus preguntas. (Hal Finney)  De hecho, hice esto al revés. Tuve que escribir todo el código antes de poder convencerme de que podía resolver todos los problemas, luego escribí el White Paper. Creo que podré publicar el código antes de lo que tardaría en escribir una especificación detallada. Ya tiene razón sobre la mayoría de sus suposiciones, con  las que completó los espacios en blanco.»

Satoshi Nakamoto

 

6- Nov 8 22:09 James A Donald  – The proof-of-work chain
https://www.metzdowd.com/pipermail/cryptography/2008-November/014833.html

«The proof-of-work chain is the solution to the synchronisation problem, and to knowing what the globally shared view is without having to trust anyone.

A transaction will quickly propagate throughout the network, so if two versions of the same transaction were reported at close to the same time, the one with the head start would have a big advantage in reaching many more nodes first. Nodes will only accept the first one they see, refusing the second one to arrive, so the earlier transaction would have many more nodes working on incorporating it into the next proof-of-work. In effect, each node votes for its viewpoint of which transaction it saw first by including it in its proof-of-work effort.

If the transactions did come at exactly the same time and there was an even split, it’s a toss up based on which gets into a proof-of-work first, and that decides which is valid.

When a node finds a proof-of-work, the new block is propagated throughout the network and everyone adds it to the chain and starts working on the next block after it. Any nodes that had the other transaction will stop trying to include it in a block, since it’s now invalid according to the accepted chain.

The proof-of-work chain is itself self-evident proof that it came from the globally shared view. Only the majority of the network together has enough CPU power to generate such a difficult chain of proof-of-work. Any user, upon receiving the proof-of-work chain, can see what the majority of the network has approved. Once a transaction is hashed into a link that’s a few links back in the chain, it is firmly etched into the global history».

Satoshi Nakamoto

7- Nov 9 11:31 James A Donald – They both broadcast
https://www.metzdowd.com/pipermail/cryptography/2008-November/014838.html

«They both broadcast their blocks. All nodes receive them and keep both, but only work on the one they received first. We’ll suppose exactly half received one first, half the other.

In a short time, all the transactions will finish propagating so that everyone has the full set. The nodes working on each side will be trying to add the transactions that are missing from their side. When the next proof-of-work is found, whichever previous block that node was working on, that branch becomes longer and the tie is broken. Whichever side it is, the new block will contain the other half of the transactions, so in either case, the branch will contain all transactions. Even in the unlikely event that a split happened twice in a row, both sides of the second split would contain the full set of transactions anyway.

It’s not a problem if transactions have to wait one or a few extra cycles to get into a block».

Satoshi Nakamoto

8- Nov 9 21:14 James A Donald  – If you’re having trouble
https://www.metzdowd.com/pipermail/cryptography/2008-November/014842.html

«If you’re having trouble with the inflation issue, it’s easy to tweak it for transaction fees instead. It’s as simple as this: let the output value from any transaction be 1 cent less than the input value. Either the client software automatically writes transactions for 1 cent more than the intended payment value, or it could come out of the payee’s side. The incentive value when a node finds a proof-of-work for a block could be the total of the fees in the block».

Satoshi Nakamoto

«El incentivo para el nodo minero, cuando cierre un bloque, podría ser el total de las tarifas (todas las fees de todas las transacciones) del bloque».

Satoshi Nakamoto

9- Nov 10 17:18:20 EST 2008  James A Donald  – When there are multiple
https://www.metzdowd.com/pipermail/cryptography/2008-November/014843.html

«When there are multiple double-spent versions of the same transaction, one and only one will become valid.

The receiver of a payment must wait an hour or so before believing that it’s valid. The network will resolve any possible double-spend races by then.

The guy who received the double-spend that became invalid never thought he had it in the first place. His software would have shown the transaction go from «unconfirmed» to «invalid». If necessary, the UI can be made to hide transactions until they’re sufficiently deep in the block chain».

Sorry if I didn’t make that clear. The target time between blocks will probably be 10 minutes.

Every block includes its creation time. If the time is off by more than 36 hours, other nodes won’t work on it. If the timespan over the last 6*24*30 blocks is less than 15 days, blocks are being generated too fast and the proof-of-work difficulty doubles. Everyone does the same calculation with the same chain data, so they all get the same result at the same link in the chain.

Instantant non-repudiability is not a feature, but it’s still much faster than existing systems. Paper cheques can bounce up to a week or two later. Credit card transactions can be contested up to 60 to 180 days later. Bitcoin transactions can be sufficiently irreversible in an hour or two.

With the transaction fee based incentive system I recently posted, nodes would have an incentive to include all the paying transactions they receive».

Satoshi Nakamoto

Con el sistema de incentivos basado en tarifas de transacción (todas las fees del bloque cerrado), que publiqué recientemente, los nodos tendrían un incentivo para incluir todas las transacciones de pago que reciben.

Satoshi Nakamoto

10- Nov 13 17:56  James A Donald   – The proof-of-work chain
https://www.metzdowd.com/pipermail/cryptography/2008-November/014849.html

«The proof-of-work chain is a solution to the Byzantine Generals’ Problem. I’ll try to rephrase it in that context.

A number of Byzantine Generals each have a computer and want to attack the King’s wi-fi by brute forcing the password, which they’ve learned is a certain number of characters in length. Once they stimulate the network to generate a packet, they must crack the password within a limited time to break in and erase the logs, otherwise they will be discovered and get in trouble. They only have enough CPU power to crack it fast enough if a majority of them attack at the same time.

They don’t particularly care when the attack will be, just that they all agree. It has been decided that anyone who feels like it will announce a time, and whatever time is heard first will be the official attack time. The problem is that the network is not instantaneous, and if two generals announce different attack times at close to the same time, some may hear one first and others hear the other first.

They use a proof-of-work chain to solve the problem. Once each general receives whatever attack time he hears first, he sets his computer to solve an extremely difficult proof-of-work problem that includes the attack time in its hash. The proof-of-work is so difficult, it’s expected to take 10 minutes of them all working at once before one of them finds a solution. Once one of the generals finds a proof-of-work, he broadcasts it to the network, and everyone changes their current proof-of-work computation to include that proof-of-work in the hash they’re working on. If anyone was working on a different attack time, they switch to this one, because its proof-of-work chain is now longer.

After two hours, one attack time should be hashed by a chain of 12 proofs-of-work. Every general, just by verifying the difficulty of the proof-of-work chain, can estimate how much parallel CPU power per hour was expended on it and see that it must have required the majority of the computers to produce that much proof-of-work in the allotted time. They had to all have seen it because the proof-of-work is proof that they worked on it. If the CPU power exhibited by the proof-of-work chain is sufficient to crack the password, they can safely attack at the agreed time.

The proof-of-work chain is how all the synchronisation, distributed database and global view problems you’ve asked about are solved.»

 

11- Nov 14 13:55 Hal Finney – Fortunately,
https://www.metzdowd.com/pipermail/cryptography/2008-November/014853.html

«Fortunately, it’s only necessary to keep a pending-transaction pool for the current best branch. When a new block arrives for the best branch, ConnectBlock removes the block’s transactions from the pending-tx pool. If a different branch becomes longer, it calls DisconnectBlock on the main branch down to the fork, returning the block transactions to the pending-tx pool, and calls ConnectBlock on the new branch, sopping back up any transactions that were in both branches. It’s expected that reorgs like this would be rare and shallow.

With this optimisation, candidate branches are not really any burden. They just sit on the disk and don’t require attention unless they ever become the main chain.

—
Broadcasts will probably be almost completely reliable. TCP transmissions are rarely ever dropped these days, and the broadcast protocol has a retry mechanism to get the data from other nodes after a while. If broadcasts turn out to be slower in practice than expected, the target time between blocks may have to be increased to avoid wasting resources. We want blocks to usually propagate in much less time than it takes to generate them, otherwise nodes would spend too much time working on obsolete blocks.

I’m planning to run an automated test with computers randomly sending payments to each other and randomly dropping packets.

—-
It’s very attractive to the libertarian viewpoint if we can explain it properly. I’m better with code than with words though».

Satoshi Nakamoto

«Es muy atractivo desde el punto de vista Libertario si podemos explicarlo correctamente. Sin embargo, soy mejor con el código que con las palabras.»

Satoshi Nakamoto

12- Nov 14 23:43 Ray Dillinger – Only the buyer signs
https://www.metzdowd.com/pipermail/cryptography/2008-November/014858.html

«I’ll try and hurry up and release the sourcecode as soon as possible to serve as a reference to help clear up all these implementation questions».

Ray Dillinger (Bear) wrote:
> When a coin is spent, the buyer and seller digitally sign a (blinded)
> transaction record.

Only the buyer signs, and there’s no blinding.

> If someone double spends, then the transaction record
> can be unblinded revealing the identity of the cheater.

Identities are not used, and there’s no reliance on recourse. It’s all prevention.

> This is done via a fairly standard cut-and-choose
> algorithm where the buyer responds to several challenges
> with secret shares

No challenges or secret shares. A basic transaction is just what you see in the figure in section 2. A signature (of the buyer) satisfying the public key of the previous transaction, and a new public key (of the seller) that must be satisfied to spend it the next time.

> They may also receive chains as long as the one they’re trying to
> extend while they work, in which the last few «links» are links
> that are *not* in common with the chain on which they’re working.
> These they ignore.

Right, if it’s equal in length, ties are broken by keeping the earliest one received.

> If it contains a double spend, then they create a «transaction»
> which is a proof of double spending, add it to their pool A,
> broadcast it, and continue work.

There’s no need for reporting of «proof of double spending» like that. If the same chain contains both spends, then the block is invalid and rejected.

Same if a block didn’t have enough proof-of-work. That block is invalid and rejected. There’s no need to circulate a report about it. Every node could see that and reject it before relaying it.

If there are two competing chains, each containing a different version of the same transaction, with one trying to give money to one person and the other trying to give the same money to someone else, resolving which of the spends is valid is what the whole proof-of-work chain is about.

We’re not «on the lookout» for double spends to sound the alarm and catch the cheater. We merely adjudicate which one of the spends is valid. Receivers of transactions must wait a few blocks to make sure that resolution has had time to complete. Would be cheaters can try and simultaneously double-spend all they want, and all they accomplish is that within a few blocks, one of the spends becomes valid and the others become invalid. Any later double-spends are immediately rejected once there’s already a spend in the main chain.

Even if an earlier spend wasn’t in the chain yet, if it was already in all the nodes’ pools, then the second spend would be turned away by all those nodes that already have the first spend.

> If the new chain is accepted, then they give up on adding their
> current link, dump all the transactions from pool L back into pool
> A (along with transactions they’ve received or created since
> starting work), eliminate from pool A those transaction records
> which are already part of a link in the new chain, and start work
> again trying to extend the new chain.

Right. They also refresh whenever a new transaction comes in, so L pretty much contains everything in A all the time.

> CPU-intensive digital signature algorithm to
> sign the chain including the new block L.

It’s a Hashcash style SHA-256 proof-of-work (partial pre-image of zero), not a signature.

> Is there a mechanism to make sure that the «chain» does not consist
> solely of links added by just the 3 or 4 fastest nodes? ‘Cause a
> broadcast transaction record could easily miss those 3 or 4 nodes
> and if it does, and those nodes continue to dominate the chain, the
> transaction might never get added.

If you’re thinking of it as a CPU-intensive digital signing, then you may be thinking of a race to finish a long operation first and the fastest always winning.

The proof-of-work is a Hashcash style SHA-256 collision finding. It’s a memoryless process where you do millions of hashes a second, with a small chance of finding one each time. The 3 or 4 fastest nodes’ dominance would only be proportional to their share of the total CPU power. Anyone’s chance of finding a solution at any time is proportional to their CPU power.

There will be transaction fees, so nodes will have an incentive to receive and include all the transactions they can. Nodes will eventually be compensated by transaction fees alone when the total coins created hits the pre-determined ceiling.

> Also, the work requirement for adding a link to the chain should
> vary (again exponentially) with the number of links added to that
> chain in the previous week, causing the rate of coin generation
> (and therefore inflation) to be strictly controlled.

Right.

> You need coin aggregation for this to scale. There needs to be
> a «provable» transaction where someone retires ten single coins
> and creates a new coin with denomination ten, etc.

Every transaction is one of these. Section 9, Combining and Splitting Value».

Satoshi Nakamoto

«Habrá tarifas de transacción, por lo que los nodos tendrán un incentivo para recibir e incluir todas las transacciones que puedan. Los nodos eventualmente serán compensados solo por las tarifas de transacción (fees) cuando el total de monedas creadas alcance el límite predeterminado«.

Satoshi Nakamoto

13- Nov 15 13:02  Ray Dillinger  – Right, it’s ECC  double-spent transaction
https://www.metzdowd.com/pipermail/cryptography/2008-November/014860.html

Mensaje previo aludido: Ray Dillinger

«Right, it’s ECC digital signatures. A new key pair is used for every transaction.

It’s not pseudonymous in the sense of nyms identifying people, but it is at least a little pseudonymous in that the next action on a coin can be identified as being from the owner of that coin.

—
This is a version 2 problem that I believe can be solved fairly satisfactorily for most applications.

The race is to spread your transaction on the network first. Think 6 degrees of freedom — it spreads exponentially. It would only take something like 2 minutes for a transaction to spread widely enough that a competitor starting late would have little chance of grabbing very many nodes before the first one is overtaking the whole network.
During those 2 minutes, the merchant’s nodes can be watching for a double-spent transaction. The double-spender would not be able to blast his alternate transaction out to the world without the merchant getting it, so he has to wait before starting.

If the real transaction reaches 90% and the double-spent tx reaches 10%, the double-spender only gets a 10% chance of not paying, and 90% chance his money gets spent. For almost any type of goods, that’s not going to be worth it for the scammer.

Information based goods like access to website or downloads are non-fencible. Nobody is going to be able to make a living off stealing access to websites or downloads. They can go to the file sharing networks to steal that. Most instant-access products aren’t going to have a huge incentive to steal.

If a merchant actually has a problem with theft, they can make the customer wait 2 minutes, or wait for something in e-mail, which many already do. If they really want to optimize, and it’s a large download, they could cancel the download in the middle if the transaction comes back double-spent. If it’s website access, typically it wouldn’t be a big deal to let the customer have access for 5 minutes and then cut off access if it’s rejected. Many such sites have a free trial anyway».

Satoshi Nakamoto

14- Nov 17 12:24 James A Donald  – I mean a node
https://www.metzdowd.com/pipermail/cryptography/2008-November/014863.html

«I think I’ve got the peer networking broadcast mechanism covered.

Each node sends its neighbours an inventory list of hashes of the new blocks and transactions it has. The neighbours request the items they don’t have yet. If the item never comes through after a timeout, they request it from another neighbour that had it. Since all or most of the neighbours should eventually have each item,
even if the coms get fumbled up with one, they can get it from any of the others, trying one at a time.

The inventory-request-data scheme introduces a little latency, but it ultimately helps speed more by keeping extra data blocks off the transmit queues and conserving bandwidth.

> You have an outline
> and proposal for such a design, which is a big step
> forward, but the devil is in the little details.

I believe I’ve worked through all those little details over the last year and a half while coding it, and there were a lot of them. The functional details are not covered in the paper, but the sourcecode is coming soon. I sent you the main files. (available by request at the moment, full release soon)».

Satoshi Nakamoto

«Creo que he trabajado en todos esos pequeños detalles en el año y medio pasado, mientras hacía el codigo, y había muchos detalles. Los detalles funcionales no se tratan en el documento (WP), pero el código fuente lo publicaré pronto. Te envié los archivos principales. (disponible a pedido en este momento, lanzamiento completo pronto)».

Satoshi Nakamoto

 

———————————————————————————————————————————–

Satoshi se hizo un perfil en la plataforma SourceForge el 9 de Nov, 2008 y La mailing list la inauguró el 10 Dic del 2008

The old forum can still be reached here:
http://bitcoin.sourceforge.net/boards/index.php

I’ll repost some selected threads here and add updated answers to questions where I can.

FAQ
http://bitcoin.sourceforge.net/wiki/index.php?page=FAQ

Download
http://sourceforge.net/projects/bitcoin/files/

Canales de Telegram: En orden alfabético.

Telegram channels – Names in alphabetical order:

Adam Back 1997 Hashcash Cypher  – 13 Members

David Chaum 1983 eCash – Firma ciega Cypher – 16 Members

Hal Finney (1956 – 2014) 2004 RPOW – Reusable Proofs of Work – 12 Members

Ian Grigg 1998 Financial Cryptography Cypher – 24 Members

James A Donald Cypher – 12 Members

Jeff Garzik Early CORE BTC – 8 Members

Joseph Vaughn Perling New Liberty Dollar Cypher  – 10 Members

Laszlo Hanyecz  (2 Pizzas 10k btc) Cypher – 4 Members

Martti Malmi Early CORE BTC – 11 Members

Nick Szabo 2005 Bit Gold Cypher  – 16 Members

Perry Metzger  The Mailing List Cypher  – 4 Members

Pieter Wuille CORE BTC – 5 Members

Ray Dillinger Bear Cypher – 20 Members

Scott Stornetta 1991 Cypher – 6 Members

Tim May 1951 – 2018 Cypher  – 8 Members

Theymos – Michael Marquardt aka Theymos. – 4 Members

Wei Dai 1998 B-Money Cypher  – 9 Members

 

Satoshi Nakamoto’s  quotes

Topics in alphabetical order:

Anarchy Philosophy-Ideology – 5 Members

BIP Bitcoin Improvement Proposal Tec News – 6 Members

Blacknet – Metanet – 20 Members

Byzantine Generals problem Tec News – 4 Members

Cryptology – 4 Members

Cypherpunk Movement Cypher 1992 – 6 Members

DigiCash 1989- David Chaum Cypher Project – 3 Members

ECDSA Elliptic Curve Digital Signature Algorithm Tec News – 7 Members

EFF Electronic Frontier Foundation   – 4 members

eGold  1996 – 2009 Project – 4 Members

Free software LEGAL Debate – 6 Members

Game theory Tec Debate – 4 Members

GPL General Public Licence LEGAL – 3 Members

Liberty Dollar 1998 Project – 7 Members

Liberty Reserve – Costa Rica 2006 – 2013 Project – 10 Members

Mandala Network Philosophy Debate – 9 Members

Mt Gox  – 5 Members

P2SH Tec News – 3 Members

Patent LEGAL – 15 Members

PGP = Pretty Good Privacy Tec Anonymous – 6 Members

PoW – Proof of Work PoW Tec Consensus – 5 Members

Property – Onership – 6 Members

RSA (Rivest–Shamir–Adleman) 1978 encrypt data Cypher – 4 Members

 

Schnorr Signatures Tec News – 9 Members

Shamir’s Secret Sharing Algorithm Tec News – 9 Members

Traceability – 4 Members

White Paper– News Tec News – 17 Members

 

 

 

 

 

0 comentarios

Dejar un comentario

¿Quieres unirte a la conversación?
Siéntete libre de contribuir!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *