Mailinglist Collection Satoshi Nakamoto

Mailinglist Collection Satoshi Nakamoto
Mailinglist Collection Satoshi Nakamoto

Collection of MaillingList Satoshi Nakamoto – The Beginning of Bitcoin Introduced

MailingList Collection Satoshi Nakamoto . The first time Bitcoin was introduced, Satoshi Nakamoto was involved in the cryptographic maillinglist group In this mailinglist community was the beginning of Satoshi Nakamoto introducing Bitcoin. Started by publishing his paper entitled “Bitcoin: A Peer-to-Peer Electronic Cash System” .

The paper was first published in this cryptographic mailinglist group on November 1, 2008. Many of the responses and also the post-paper questions were published. And Satoshi explains the questions about Bitcoin.

Bitcoin Education then translated this collection of Satoshi Nakamoto mailinglist, which came from . Collection of Mailinglist inipun also stored neatly on the site . Here’s a collection of Satoshi Nakamoto’s Mailinglist:

Collection Mailinglist Satoshi Nakamoto – Part I

Bitcoin P2P e-cash paper 2008-11-01 19:16:33 UTC

I’ve created an electronic payment system, which fully uses peer-to-peer networks, without any third party roles.

Paper can be obtained at:

Primary Property:
Double-spending can be prevented by peer-to-peer networks.
There is no mint (coin maker) or any third party.
Participants can be anonymous
New coins are made from a hashcash proof-of-work pattern.
Proof-of-work for the creation of this new coin can also support the network to prevent double-spending.

Bitcoin: A Peer-to-Peer Electronic Cash System (Bitcoin: A Peer-to-peer Electronic Payment System)

Abstract . A pure peer-to-peer electronic currency, will enable making online payments directly. From one party to another. Without having to burden through financial institutions.

Digital signature becomes the solution in some parts, but its main function is to prevent double-spending. We propose solutions to this double-spending problem using peer-to-peer networks. Transaction timestamps on the network are accomplished by the transaction hashing process into a sustainable chain, from a proof-of-work hash. Then record it, so it can not be changed without repeating the proof-of-work. The longest chain not only serves as evidence witnessing the sequence of events, but also as evidence that it comes from a large pool on CPU power. As long as the honest node controls most CPU power within the network, they can generate long chains, and keep them away from any attack. The network itself requires minimal structure. The message is broadcast to be the basis of the best effort. Nodes can go and rejoin the network, receiving the longest proof-of-work chain as proof of what happens when they are not in the network.

Complete Paper at:

Satoshi Nakamoto

The Cryptography Mailing List
Unsubscribe by sending “unsubscribe cryptography” to [EMAIL PROTECTED]

Collection of Mailinglist Satoshi Nakamoto – Part II

Re: Bitcoin P2P e-cash paper 2008-11-02 20:56:27 UTC

> Satoshi Nakamoto writes:
>> I have created an electronic payment system, which is entirely
>> use peer-to-peer network, without any role from third party.
>> Paper can be found at:
> We really need this kind of system, but I understand from your proposal,
> it does not seem to cover the required size scale.
> In order for a proof-of-work token to be transferred it has a value, must have
> monetary value. To be able to have a monetary value, they must be transferred through
> a very large network – for example on trading networks files that are similar to
> bittorrent.
> To be able to detect and refuse double spending at the right time, one
> must have the earliest transaction of the current transaction. If
> hundreds or millions of people make transactions, it will require
> large bandwidth – each participant must know all this, or most of them.

Long before the network will be as large as mentioned, it will be quite safe for users to use Simplified Payment Verification (section 8) to check for double spending, which requires block headers in the block chain, or about 12Kb per day. Only people who make new coins will need them to run nodes on the network. The first time, most users will run the node.When the network goes beyond a certain developmental point, it will be more, and more will leave it, to a special hardware in a server farm . server farm only needs one node in the network, the rest can connect to the LAN connection on that node.

Bandwidth is unlikely to be a barrier as you think. A transaction generally ranges around 400byte (ECC has been well compacted). Every transaction must be aired twice. Say 1Kb per transaction. Visas can process 37 billion transactions in FY2008, or an average of 100 million transactions per day. The considerable deal will require 100 GB of bandwidth, or approximately 12 DVDs, or 2 HD-quality Movies, or approximately $ 18 in current bandwidth prices.

It takes several years, the new network will be that big. At that time, sending 2 HD movies over the internet is not a big problem later on.

Satoshi Nakamoto

The Cryptography Mailing List
Unsubscribe by sending “unsubscribe cryptography” to [EMAIL PROTECTED]

Collection Mailinglist Satoshi Nakamoto – Part III

Re: Bitcoin P2P e-cash paper 2008-11-03 14:45:58 UTC

>> As long as the honest node controls most CPU power inside the network,
>> they can generate long chains, and keep them away from any attack.
> But they do not. Bad people can regularly control 100,000 zombie farms machines
> or even more. People I know run blakclist spam
> says that he often sees millions of new zombies in a day.
> For this reason hashcash can not work on the internet today.
> – Good people have fewer number of computing weapons than
> bad guys.

Thank you for pointing out this issue.

I do not really make that statement to my capacity. What is needed is that a good person collectively will have more CPU power than an attacker.

There will be many small zombie farms that are not big enough to match the network, they can still make money by creating a new Bitcoin. Then the little farm would be an “honest node” (I need a good term rather than an “honest” word). The more small farms that make new bitcoins, the higher is also the bar to master the network, so they can also create new bitcoins. Based on the theory of “long tail”, small, medium, and large should be combined into one to be able to increase the number of larger, rather than the largest zombie farm .

Even though the bad guy can match the network, it will not make him rich instantly and quickly. All he can do is take his own money back, like bounching a check . To exploit, he must buy something from the merchant, wait until sent, then master the network and try to take the money back. I do not think he will make much money from carding scheme like that, because he can earn money by making a new bitcoin. With a zombie farm of that size, he can actually produce more Bitcoin than a mix of other people.

The Bitcoin network may actually reduce spam, by diverting zombie farms , into attempts to create new bitcoins.

Satoshi Nakamoto

The Cryptography Mailing List
Unsubscribe by sending “unsubscribe cryptography” to [EMAIL PROTECTED]

Collection of Mailinglist Satoshi Nakamoto – Part IV

Re: Bitcoin P2P e-cash paper 2008-11-07 12:30:36 UTC

> [Extension of vulnerability exposure of a system is also due to use-of-force monopoly.]>
> You will not find solutions to political problems in cryptography.

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

The government would quite easily cut off the head of a centralized network system like Nepster, but pure P2P networks like Gnutella and Tor seemed to be in control of their own.


The Cryptography Mailing List
Unsubscribe by sending “unsubscribe cryptography” to [EMAIL PROTECTED]

Collection Mailinglist Satoshi Nakamoto – Part V

Re: Bitcoin P2P e-cash paper 2008-11-08 16:38:26 UTC

Ray Dillinger:
> “Currency” can cause inflation around 35%
> Because of that, how much can be earned per year from a fast computer
> … of an almost guaranteed 35% inflation rate
> by technology

Increased hardware speeds can be addressed: “To compensate for the increased hardware speed and interest in running nodes that change over time, the proof-of-work difficulty level is determined by the targeted average movement of the number of blocks per hour. If they can be produced in too soon, then the difficulty level will increase. “

Because computers with faster computing power will increase the production of bitcoin, the difficulty increases proportionately in order to maintain a fixed amount of new production.That way, it will be known in advance how many new Bitcoins can be made each year in the future.

The fact that a new coin is created means raising some money supply that has been planned, but this does not always lead to inflation. If the money supply increases at the same level of the number of people using it also increases, the price remains stable. If it does not increase as fast as its demand, there will be deflation, and the initial holders of money will see its value increase.

Coins should be distributed anyway, and this constant rate seems to be the best formula.
Satoshi Nakamoto

The Cryptography Mailing List
Unsubscribe by sending “unsubscribe cryptography” to [EMAIL PROTECTED]

Mailinglist Collection Satoshi Nakamoto – Part VI

Re: Bitcoin P2P e-cash paper 2008-11-09 14:13:34 UTC

Finney writes :
> mentioned that a broadcast transaction does not reach all nodes,
> no problem, because it will go into chain block. How could this happen –
> what if the node makes “next block” (first node to
> looking for hashcash collision ) did not hear the transaction,
> then a few more blocks are also inserted by the node that is also not heard
> about the transaction? Are all the nodes that hear it maintain
> the transaction, hoping to fit into the block after they succeed
> and lucky to be the one who managed to find the next collision?

Yes, nodes keep the transaction on their work set until they can get inside the block. If a transaction can cover 90% of the nodes, then every new block is found, the transaction has a 90% chance of getting inside the newly discovered block.

> Or for example, what if a node keeps two or more
> wait to see which grows fastest, and a block comes in chain A
> which will include double spend of a coin in chain B? What is that
> checked or not? (This can happen if someone does a double-spend and two
> sets the difference it is heard by the node, about two different transactions
> on the same coin.)

It does not need to be checked. Transactions on any branch will always culminate into a valid one, and others invalid. If someone tries to double spend like that, there is only one and only one that always becomes valid, the other invalid.

Transaction recipients normally will normally need to hold transactions for about an hour or more to allow time and possibilities to be resolved. They can still spend their coins, but it’s best to wait before taking steps such as delivering goods.

> I also do not understand exactly how to double-spend , or cancel
> transaction, can be an attacker who is able to collect
> computing power is greater than all honest participants. I see that he can
> create a new block and add it to create the longest chain, but how
> he deleted or added an old transaction into the chain? As the attacker sends
> new block it, there is no consistent check that can be done by honest node,
> to ensure that nothing was successfully deleted? A deeper explanation of
> this attack will help a lot, to assess the benefits that can be taken by the attacker
> of this, than just using computing power to make new coins honestly.

Attacker does not add block until end. He must return and repeat the inserted transaction block, as well as the entire block thereafter. Because every new block in the network should continue to be added to the end if it does that. He’s trying to rewrite history. After the branch block becomes a long branch, it becomes valid.

This touches a key point. Even though everyone present attends this scenario, there is no way to take advantage of this.

It is necessary that the longest chain is always considered valid. The present node may remember that one of the branches must be replaced by another, but there will be no way for them to convince the absent person in the network at the time. In a network can not have a sub-part of a node attached to one branch that they think is the first branch, another person sees the other first branch, and others who join then never see what happens.

Operating a CPU power proof-of-work voting must produce a final statement. The only way for everyone on the same page to be able to believe that the longest chain will only apply a valid one, no matter what else.

> As far as the expenditure of the transaction, what inspection the recipient did
> on the coin? Does she need her back to demanding the whole trip
> the history of the transaction, and ensure that every transaction is in it
> has indeed been connected to the block’s “timestamp”? Or he can only do
> on the last block?

The recipient will only verify again on the depth of the transaction far enough on the block chain, which most often will only require 2 transaction depth only. All transactions before that can be ignored.

> Whether the timestamp node will check the transaction, ensure that
> previous transactions on the coins in the chain, can enforce the rules
> that all previous transactions in that chain are valid?

Exactly. When a node receives a block, check whether the digital signature of each transaction is in it against the previous transaction on the block. Blocks can only contain transactions that depend on valid transactions in the previous block or the same block.Transaction C can depend on transaction B in the same block, and B depends on transaction A in the previous block.

> Sorry about all these questions, but as I said that this seems so
> quite promising and original idea, and I step forward to see
> how this concept can be developed further. It will be helpful to look further
> description of the process orientation of this idea, which is complete with concrete details of
> data structures for various objects (coins, blocks, transactions),
> The data included in the message, and the algorithmic description procedure
> to handle some of the events that will happen inside
> this system. You mentioned that you are working on an implementation,
> but I think more formal, text description of the system will be
> quite helpful in the next step.

I appreciate your inquiry. I have to really do this with a step back. I have to write all these codes before I can convince myself that I can solve every problem, then I do paper. I think I will be able to release code faster than detailing every detail of its specification. You are correct on most assumptions you leave empty.

Satoshi Nakamoto

The Cryptography Mailing List
Unsubscribe by sending “unsubscribe cryptography” to [EMAIL PROTECTED]

Mailinglist Collection Satoshi Nakamoto – Part VII

Re: Bitcoin P2P e-cash paper 2008-11-09 14:14:17 UTC

James A. Donald writes :
> The core concept is to contain many complete and fixed entities, as well as information
> who is consistent about who owns Bitcoin.
> But to keep the consistency complicated. This is not clear to me
> occurs when someone reports a transaction in one manager, and
> others bring other transactions to other managers.
> the transaction can not be known to apply until it has been entered
> into the overall global view of all past transactions, no one can
> know that the global view of all past transactions is global
> until some time has passed, and after many
> new transaction has arrived.
> do you explain how to do this, and it just comes to mind, or
> are you sure it can be done, and a little bit vague about the details?

Proof-of-work is the solution to the problem of synchronization, and to know what is a globally shared view without having to trust anyone.

Transactions will quickly spread across the network, so that if two versions of the same transaction are reported closer together at the same time, one with the head start has a big advantage in reaching more nodes in the first. Nodes will only accept the first one they see, then reject the second when it arrives, so the previous transaction will have more nodes, which work together to insert into the next proof-of-work. In effect, each node provides a view based on its perspective, where the transaction was first seen, and has included proof-of-work.

If the transaction comes at the same time, there is even spllit, will be based on the first proof-of-work, and decide which one is valid.

When a node finds a proof-of-work, a new block is propagated throughout the network, and everyone adds it to the chain, and starts working on the next block after that. Any node that has other transactions will stop attempting to insert in the block, as it now becomes invalid based on what has been received in the chain.

The proof-of-work chain itself has become a clear proof that it comes from a variety of views globally. Only a large portion of the network has sufficient CPU power to produce a tough proof-of-work. Every user who has received a proof-of-work chain can see what the majority agree on within the network. Once a transaction is in process with hashing being a link that claims back into the chain, and it is firmly etched into history globally.

Satoshi Nakamoto

The Cryptography Mailing List
Unsubscribe by sending “unsubscribe cryptography” to [EMAIL PROTECTED]

Mailinglist Collection Satoshi Nakamoto – Part VIII

Re: Bitcoin P2P e-cash paper 2008-11-09 14:17:24 UTC

James A. Donald writes :
> OK, suppose one node combines a group
> deals in proof-of-work, all of them honest
> legitimize one expense transaction, and another nod combine a
> different transaction groups and their proof-of-work,
> all of them are equally honest and legitimize one
> legitimate expenditure, both generated from proof-of-work in time
> the same.
> then what happened?

They Both will broadcast their blocks. All nodes accept and maintain both, but will work on the first received one. Say half accept the first, and the other half receive the other.

Within a short time, all transactions will be finished broadcasting so that everyone can have the complete set. The nodes working on each side will try to add the lost transactions from their side. When the next proof-of-work is found, the block previously worked on the node, becomes a long branch and the bond is disconnected. On the other hand, the new block will contain half the other transactions. So in both cases, the branch will contain all the transactions. There can be no rupture twice in a row, both sides in seconds will contain the full set of all transactions, however.

It does not matter if the transaction has to wait for one or more additional cycles for the transaction to fit into the block.

Satoshi Nakamoto

The Cryptography Mailing List
Unsubscribe by sending “unsubscribe cryptography” to [EMAIL PROTECTED]

Mailinglist Collection Satoshi Nakamoto – Part IX

Re: Bitcoin P2P e-cash paper 2008-11-10 14:09:26 UTC

James A. Donald writes :
> Further, it can not work, like on
> make a system proposal for tracking who will have a coin
> to be paid to the coinmaker, as it requires inflation.

If you are having trouble with inflation issues, it is easy to add tweaks to transaction costs.Simply put it this way: let the output value of any transaction be 1 percent less than the input value. Software on the client will automatically write 1 more penny that as the value of payment, or can get out of the side of the payee. The incentive value works when the node finds a proof-of-work on a block that can be the total transaction cost on the block.

Satoshi Nakamoto

The Cryptography Mailing List
Unsubscribe by sending “unsubscribe cryptography” to [EMAIL PROTECTED]

Mailinglist Collection Satoshi Nakamoto – Part X

Re: Bitcoin P2P e-cash paper 2008-11-11 09:30:22 UTC

James A. Donald wrote:
> Then what happens to the missing coin in the race entering the transaction in the block?
> … it will be a bit hard on people who come in second moment
> maybe he will lose his coin.

When there are multiple versions of double-spent on the same transaction, there will only be one that becomes valid.

The payee must wait an hour or so before he / she believes the transaction is valid. The network will then resolve any possibility if there is a double-spend at that time.

The person receiving the double-spend becomes invalid, never thinking that he will be in the first place. The software will show the transaction from “unconfirmed” to “invalid”. If necessary, UI can be made to hide the transaction, until they can enter the block chain.

> Next, you describe a restriction
> at the time the coins are generated – that’s across the network
> will generate new coins more than the time required for
> broadcast the new coin in the network

Sorry if I did not give a clear explanation. The target time between blocks may be approximately 10 minutes.

Each block includes its creation time. If the active time is approximately 36 hours, another node will not work on that block. If the time period exceeds 6 * 24 * 30, the block may be less than 15 days, the block will be generated too soon and the proof-of-work difficulty level will be duplicated. Everyone does the same calculations on the same chain. So they all produce good results in that chain link.

> we want to make sure that the sender can make sure
> the transaction is valid at the time he transacted
> then flooded the transaction broadcast in the network, not at the time on the branch
> which needs to be resolved.

Instantly non-repudiability is not an option, but it is still much faster than the existing system. A paper check can be thawed in the next week or two. Credit cards can be claimed within the next 60 to 80 days. Bitcoin transactions only take an hour or two.

> if one node ignores all transaction expenses and does not care
> will the transaction, can lead to losses.

With an incentive system on the transaction costs I post earlier, the node will have an incentive by covering all the transaction costs they will receive.

Satoshi Nakamoto

The Cryptography Mailing List
Unsubscribe by sending “unsubscribe cryptography” to [EMAIL PROTECTED]

Collection of Satoshi Nakamoto Mailinglist – Part XI

Re: Bitcoin P2P e-cash paper 2008-11-13 22:34:25 UTC

James A. Donald writes:
> It is not enough that everyone knows X. We too
> wants everyone to know that everyone knows X, and that
> everyone knows that everyone knows that everyone knows X
> – this is, like the Byzantine Generals problem, which it is
> the classic weight problem in the data distribution process.

The Proof-of-work chain becomes the Byzantine Generals Problem solution . I will try to repeat the word in a context.

A number of general Byzantines each had a computer and wanted to attack the King’s wifi by performing a brute force pasword, which they had learned through a certain number of characters. Once they can stimulate the network to generate an information packet, they must crack the password within a limited time and then delete the log. If they can not, then they will get into trouble. They only have enough CPU power to solve it if the majority of the attacks are done at the same time.

They will not be too concerned about the attack, because they will all agree. It has been decided that everyone who feels this will announce a time, and this time even if the first hearing will be a timepiece of his official attack. The problem is that the network is not instantaneous, if two generals announce the time difference of the adjacent attack, some will hear the first one, the other will hear the other first attack in the hearing.

The proof-of-work function can solve this problem. After each receives whatever is heard first, the general will set his computer to solve a complicated proof-of-work, hopefully they can work together and solve within 10 minutes before anyone else finds it.

Once one of the generals finds a proof-of-work, then broadcasts it into the network, everyone will change its proof-of-work computing, by putting proof-of-work into the hash it is working on. If everyone is working on a different time attack, they will move on to this one, because the proof-of-work on the chain is long.

After the next two hours, a single attack must be in hashing with a branch chain that has 12 proof-of-work. Each general, can only verify the difficulty level of the proof-of-work chain, it can be estimated how much CPU power per hour should be spent on it. And see that it will take the majority of computers to produce as much proof-of-work in a given time. They should all see it as proof that they have actually completed the proof-of-work. If CPU power is viewed in a proof-of-work chain to be sufficient and can break passwords, they can safely strike at an agreed time.

The proof-of-work chain is how everything can be synchronized, the distribution of databases, and the globally problematic views you ask can be solved.

The Cryptography Mailing List
Unsubscribe by sending “unsubscribe cryptography” to [EMAIL PROTECTED]

Mailinglist Collection Satoshi Nakamoto – Part XII

Re: Bitcoin P2P e-cash paper 2008-11-14 17:29:22 UTC

Finney writes :
> I think it is necessary to node save it separately
> on pending transactions associated with each next chain candidate
> … one might ask also … how many chains candidates should be
> given a node to keep track of it at a time, on average?

Fortunately, it only takes a pool to keep the pending transactions on a particular branch.When the new block comes from the best branch, the connected block deletes the transaction residing in the pending transaction pool. If a different branch becomes longer, disconnect the block in the main branch for the next fork. Return to the block transactions in the pool, then connect again the blocks in the new branch, on any transactions that are in both branches. Expected to be reorganized again, it becomes rare and also shallow.

With this optimization, the prospective branch of the block is not really burdened with anything. They just sit still on the disc, and do not need attention unless they’ve been the main chain.

> Or as James said before, if the network broadcast
> reliably, but depending on potential flooding delays
algorithm , how will this affect its performance?

Transaction broadcasts will probably be completely reliable. TCP transmissions are rare and almost never come down today, broadcast protocols have a repetition mechanism that can retrieve data from other nodes after a while. If broadcast broadcasting is slower than expected, inter block targets will increase to avoid wastage. We want the block to propagate in a relatively longer time than it takes to process it, otherwise the node will spend a lot of time working on the outdated block.

I plan to run tests automatically with a random payment to each other, and randomly also will put the packet.

> 3. The bitcoin system is useful and socially valuable, so
> node operators feel they will make a profit by making a contribution
> to the world with its efforts (similar to various computing projects “@Home”
> where people volunteer to compute the source for a good cause).
> In this case comes to my mind a simple altruism that can guard
> the network goes well.

This is very interesting for the libertarian point of view if we can explain it appropriately. I better explain it with code than with words though.

Satoshi Nakamoto

The Cryptography Mailing List
Unsubscribe by sending “unsubscribe cryptography” to [EMAIL PROTECTED]

Mailinglist Collection Satoshi Nakamoto – Part XIII

Re: Bitcoin P2P e-cash paper 2008-11-17 12:04:47 UTC

I will try quickly and release the sourcecode as much as possible as a reference in helping all the questions tekait with the implementation.

Ray Dillinger (Bear) writes :
> when coins are spent, buyers and sellers sign (blind signature)
> transaction notes.

Only the signature of the buyer, and no blind signature.

> if someone does double-spend , then the transaction is recorded
> can reveal the identity of the fraudsters.

Identity is not used, and there is no dependence on this. These are all precautions.

> This is done quite simply by standard algorithm
cut-and-choose when the buyer responds to some challenges
> with secret shares .

There are no challenges or secret shares. The basic transaction is what you see in the section in number 2. The digital signature of the buyer will explain the public key in the previous transaction, and the new public key of the seller must be able to explain the expense transaction later.

> They can also accept the chain as long as one of them seeks to
> extend their work, where the last “link” is a link
> and not * not * generally with the chains they are working on.
> This is what they ignore.

Indeed, if it is the same length, the bond is disconnected by storing the first received.

> if it contains double spend , they can make a “transaction”
> where the proof of double spending, added to pool A,
> broadcast, then re-spell it.

There is no need to report such a “proof of double spending”. If on the same branch has double-spend, it will be invalid and rejected.

Similarly, if a block does not have enough proof-of-work. The block is invalid and rejected, and there is no need to broadcast a report about it. Each node can see and reject it before it’s in the relay.

If there are two competing chains, each containing a different version of the same transaction, one tries to give money to one person, and the other tries to give the same money to someone else, completes what spawning becomes valid, is to be all about this proof-of-work chain.

We are not too “wary” .will double-spend it to be able to sound the alarm and then catch the culprit. We only judge it on one of the only valid transaction expenses. The recipient of the transaction must wait for several blocks to ensure the settlement. If the perpetrators of cheating try to repeatedly double-spend what they want, of them, one is valid, and the other becomes invalid. The next double-spend will be directly rejected as there is already an expenditure transaction in the main chain.

Although the first expenditure has not been included in the chain, it is already in the transaction node pool, and then the second expenditure will be rejected altogether by the node that already has the first transaction expenditure.

> if a new chain branch is received, then they give up and add
link , dump all transactions in pool L, back to pool
> A (along with the transactions they have received since the first time
> working on), holding transaction records from pool A
> that has become part of the new branch chain, and start working
> again by trying to extend the new branch.

Right. They also refresh every time a new deal arrives, so L contains enough of everything in A for the whole time.

> Intelligent digital signature algorithm for CPU
> signed a chain included on the new block L.

This is a SHA-256 proof-of-work hashcash model, not a signature.

> Is there a mechanics that can ensure that “chain” is not composed
> from the link that was added by 3 or 4 fastest nodes? That cause
> broadcasting transaction records becomes easily lost by 3 or 4 nodes
> if so, that node will continue to dominate the chain
> transactions may never be added.

If you think that as a digital intensive signing of the CPU, then you might think of a race to complete a long operation and the fastest always be the winner.

Proof-of-work is a SHA-256 hashcash model that tries to find collisions . A momory reading process where you will do millions of hashing in one second, with little chance of being able to find each time. 3 or 4 of the fastest nodes will dominate will only be proportional to their share of their total CPU power. Anyone has the opportunity to search every solution every time, in proportion to their CPU power.

There will be transaction fees, so nodes will also have an incentive to receive and cover all transactions they can make. The nodes will eventually be compensated for transaction costs when the total coins are made in accordance with the specified ceiling.

> also, on the job requirements to add links to the chain should be
> varies (exponentially) with the number of links added on
> the previous chain, causing the rate of generation of coins
> (and that’s because of inflation) that has been tightly controlled.


> You need to coin aggregation as a scale for this. Will be required for
> a “proof” transaction when someone leaves ten single coins
> then create a new coin with ten denominations, etc.

Every transaction is one part of this. In section 9, Combining and Splitting Value.

Satoshi Nakamoto

The Cryptography Mailing List
Unsubscribe by sending “unsubscribe cryptography” to [EMAIL PROTECTED]

Collection Mailinglist Satoshi Nakamoto – Part XIV

Re: Bitcoin P2P e-cash paper 2008-11-17 12:06:02 UTC

Ray Dillinger writes :
> one way to do this is
> have the person who will receive the coin result from asymmetrically generated
> pair of keys, then have half of it and published with
> transaction. To spend the coins, he then had to
> shows the other half of the asymmetric partitions
> a pair of keys, to be able to sign the key provided by
> new seller.

Yes, this is an ECC digital signature. A new pair of keys is used for each transaction.

This is not pseudonymous in the sense nyms identify a person, but at least this small pseudonym becomes the next action on a coin that can be identified as the owner of the coin.

> Mmmmm. I do not know if I am comfortable with the hall. What you say
> no attempt to identify and not include nodes that are not
> cooperate? I suspect it will cause DOS difficulties and potential
> attacks.

There is no dependence to identify anyone. As you say, it’s useless and so trivial with the doll on socks.

What matters is to set someone as real for their ability to supply CPU power.

> to …. to what? How anyone knows when a transaction
> be irrevocable? Are the “blocks” three blocks? Thirty?
> a hundred? Does not that depend on the number of nodes? Is logarithmic
> or linear from the number of nodes?

Section 11 calculates the worst case in case of an attack. Generally 5 or 10 blocks is enough for that. If you sell something inappropriate on a network scale attack to steal it, in practice it can cut it closer.

> But in the absence of identity, there is no harm to them
> if it is spent unlawfully, if they have already received
> goods from double-spent to (access the website, download,
> or whatever). The traders were left holding the bag with
> “invalid” coins, unless they wait miraculously about “several blocks”
> (how can they know how much?) before treating the sender
> has been paid.
> Consumers do not do this if they spend their coins and are needed
> one hour to complete before they spend their coins
> merchants will not do it if there is no way to replenish
> customers when they find that their coins are invalid because
> The customer has double-spend.

This is a problem with version 2 which I believe can be resolved quite satisfactorily in most applications.

The race is to spread transactions on the network first. Think about 6 degrees about freedom – spreading exponentially. The process will take only 2 minutes for the transaction to spread widely that competitors begin to have less chance of reaching multiple nodes before the first overtakes the entire network. For 2 minutes, merchant nodes can watch double-spend transactions. Double-spend actors will not be able to blow an alternative transaction out of the world without the merchant knowing it, so he has to wait before starting it.

If the real transaction reaches 90% and double-spent reaches 10%, the chance of the perpetrator does not pay only 10%, and 90% chance can take the money that has been issued. For most things, it would not be feasible for a scammer .

Information based on website access, download, is not correct. No one wants to do it by stealing access to a website or downloading a file. They can look it up on a network share to steal it. Most products that have instant access do not have a large incentive to steal.

If the merchant has a problem with theft, they can ask the customer to wait for 2 minutes.Or wait for something from the email, as they do a lot. If they want to really get optimized, and that is a great fille download, they can cancel the download in the middle if the transaction comes with a double-spent. If it is a website access, it will not usually be a big deal to let customers have access for less than 5 minutes, then cut off access if it’s rejected, besides many sites have free trial.

Satoshi Nakamoto

The Cryptography Mailing List
Unsubscribe by sending “unsubscribe cryptography” to [EMAIL PROTECTED]

Collection of Satoshi Nakamoto Mailinglist – Section XV

Re: Bitcoin P2P e-cash paper 2008-11-17 16:33:04 UTC

James A. Donald writes:
>> Fortunately, it is only needed
>> a pool to keep the pending transactions on a particular branch.
> This will require what we know, as an honest person
> well-behaved colleagues who communicate and store data
> work well it we know, what is currently the best branch is –

I mean the node only requires pool for pending transactions in the best branch owned. The branch currently thought to be the best branch. That branch will be a block that needs a pool.

>> Broadcasts may be almost as full
>> reliable.
> rather than assuming that every message arrives at least
> once, we have to create a mechanism, so
> information conveyed even though the message
> often fail to come.

I think I have a broadcast mechanism that can handle it.

Each node sends to its partner listed in the lis of the new block on the transaction. His colleague asked for some items he did not already have. If the item never comes before or after the timeout , they ask from another colleague who owns it. Since all or most colleagues end up having to have every item, or even if one misses, can be obtained from others, try one by one.

This scheme of data inventory requests has few latent conditions, but can ultimately help speed by keeping additional block data transmitted in the transmission queue and saving bandwidth.

> you have an outline
> and proposals from such designs, which is a big step
> fore, but there is a demon in small details.

I believe I have worked in all the details detail over the past year, and half again to encode it, and there are many of them. Functional details are not included in the paper, but source code is coming soon. I will send you the main file.
(available on request at this time, full release coming soon)

Satoshi Nakamoto

The Cryptography Mailing List
Unsubscribe by sending “unsubscribe cryptography” to [EMAIL PROTECTED]

Mailinglist Collection Satoshi Nakamoto – Part XVI

Bitcoin v0.1 released 2009-01-09 20:05:49 UTC

Announced the first release of Bitcoin, an electronic cash payment system that uses peer-to-peer networks to prevent double-spending . Fully decentralized without server or central authority.

Look at for the screenshots.

Download Link:

Currently only available for Windows. Also included is the C ++ source code

  • Extract files in one directory
  • It will automatically connect to other nodes

If you run that node by accepting incoming connections, you will really help the network.Port 8333 on your firewall must be open to accept incoming connections.

This software is still alpha and experimental. There is no guarantee the system does not require a restart process on some points required, even though I’ve done everything I can and built the extension and version.

You can get a coin from someone who will send some to you, or press Options-> Generate Coins to run a node and generate blocks. I’ve made the difficulty level easy at the start of the moment, so for the time being most PCs will be able to generate coins in just a few hours. Furthermore it will be much more difficult when the competition will adjust the level of difficulty that increases. The resulting coins must wait for 120 blocks to mature before they can be spent.

There are two ways to send money. If the recipient is online, you can enter that IP address and they will connect, then get the new public key and send the transaction with the comment. If the recipient is not online, it can be sent with their bitcoin address, which is a hash of their public key that has been notified to you. They will accept the transaction when they connect and get the block. This method has the disadvantage that no transaction information has been sent, and a bit of privacy will be lost if the address is used multiple times, but this is a useful alternative if both users can not get online at the same time or the recipient can not accept incoming connections.

Total circulation will reach 21,000,000 coins. These will be distributed to network nodes when they create blocks, and the number will be half-shot every 4 years.

The first 4 years: 10,500,000 coins
Next 4 years: 5.250.000 coins
Next 4 years: 2,625,000 coins
Next 4 years: 1,312,500 coins
Etc …

When it runs out, the system can support in the presence of transaction costs if needed. It is based on open market competition, and there will always be the possibility that nodes will process transactions for free.

Satoshi Nakamoto

The Cryptography Mailing List
Unsubscribe by sending “unsubscribe cryptography” to majord…

Mailinglist Collection Satoshi Nakamoto – Part XVII

Re: Bitcoin v0.1 released 2009-01-17 09:58:44 UTC

Dustin D. Trammell writes :
>> Satoshi Nakamoto writes :
>> You know, I think there are more people who are interested in the 90s,
>> but after a decade more so the failure of a third party trust-based system.
>> (Digicash, etc.), they see as the lost cause. I hope they see
>> the difference that this is the first time that I know that we are trying
>> a non-trust based system.
> yes, that is the main feature I capture. The real trick
> will get people to really appreciate Bitcoin so it can be
> currency.

I would be very surprised if 10 years from now, we no longer use electronic currency in some way, now we know a way to do it. It is not certain whether the third party will look stupid if his feet become frozen.

It can get started on a niche like reward points, token donations, currency for games, or micropayment for adult sites. It can initially be used for proof-of-work applications on services that are almost completely free, but that’s not enough.

It can be used for e-mail pay-to-send. Sent button can be resized so that it can send a long message though and will be directly sent when connected. The recipient can read the entire message by double-tapping the transaction. If that person is a well-known person who gets a lot of messages from being able to read, there is still a way to get in touch with their fans; they just set the bitcoin and give it an IP address on the site. “Submit X Bitcoin to the hotline priority in this IP and I will read the message in private.”

Subscription sites can add some proof-of-work in a free trial so there’s no need to remove customers if they can pull the bitcoin on the free trial .

It might make sense if there are some cases that can make it easy to understand. If there are enough people to think the same way, it will be self-fulfilling. Once it’s turned on, there will be so many easy applications and can make payments with just a few sent to a site as easy as dropping a coin on a vending machine.

Satoshi Nakamoto

The Cryptography Mailing List
Unsubscribe by sending “unsubscribe cryptography” to majord…

Mailinglist Collection Satoshi Nakamoto – Part XVIII

Re: Bitcoin v0.1 released 2009-01-25 11:34:34 UTC

Finney writes:
>> * Botnet Spammers can burn through emaill filters like pey-per-send
>> Trivial
> if the POW token becomes useful, especially if they become money,
> The machine is no longer sitting silent. Users expect their computers to be
> to earn income (assuming got the money at the cost for
> operate it). A computer whose income is stolen by a botnet will
> more visible to the owner than it is now, maybe we are
> hoping in that world, users will work harder to maintain
> their computers and clean up from botnets.

Another factor that will reduce spam if the POW token has a value: there will be a profit motive for people to massively set up fake email accounts to be able to harvest POW tokens from spam. Basically they will reverse it with an automated mailbox that will collect their POWs, without reading the message. The fake mailbox ratio for real people is too high for spam as an effective expense.

This process has the potential to build the POW token value in the first place, because spammers do not have botnets to buy tokens from harvesters. When the buyer returns while letting the spam pass, it will only speed up the self-defeating cycle that will lead to the number of harvests exploiting spammers.

Interestingly, one of the e-gold system already has a form of spam called “dusting”.Spammers send a small amount of gold dust in order to include spam messages in the transaction comment. If the system allows the user to configure the minimal cost received, or at least the minimum amount that can include the message in it, the user can set how much will be paid if the recipient receives spam.

Satoshi Nakamoto

The Cryptography Mailing List
Unsubscribe by sending “unsubscribe cryptography” to majord…

Cloud Faucet Net

Cloud Faucet Net

Cloud Faucet Net is an online medium for sharing knowledge and information about Bitcoin and cryptocurrency. It was first established in March 2017. Hopefully, it can be used as a source of information as well as a reference to the addition of useful knowledge, related to Bitcoin and the technology that surrounds it.

Leave a Reply

Your email address will not be published. Required fields are marked *