pull down to refresh
Satoshi Nakamoto
https://www.metzdowd.com/pipermail/cryptography/2008-November/014858.html
satoshi at vistomail.com
Fri Nov 14 23:43:00 EST 2008
Previous message: Bitcoin P2P e-cash paper
Next message: Bitcoin P2P e-cash paper
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
reply
Ray Dillinger
https://www.metzdowd.com/pipermail/cryptography/2008-November/014859.html
bear at sonic.net
Sat Nov 15 02:04:21 EST 2008
Previous message: Bitcoin P2P e-cash paper
Next message: Bitcoin P2P e-cash paper
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Sat, 2008-11-15 at 12:43 +0800, Satoshi Nakamoto wrote:
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.
Okay, that's surprising. If you're not using buyer/seller
identities, then you are not checking that a spend is being made
by someone who actually is the owner of (on record as having
recieved) the coin being spent.
There are three categories of identity that are useful to
think about. Category one: public. Real-world identities
are a matter of record and attached to every transaction.
Category two: Pseudonymous. There are persistent "identities" within the system and people can see if something was done by the same nym that did something else, but there's not necessarily any way of linking the nyms with real-world identities. Category three: unlinkably anonymous. There is no concept of identity, persistent or otherwise. No one can say or prove whether the agents involved in any transaction are the same agents as involved in any other transaction.
Category two: Pseudonymous. There are persistent "identities" within the system and people can see if something was done by the same nym that did something else, but there's not necessarily any way of linking the nyms with real-world identities. Category three: unlinkably anonymous. There is no concept of identity, persistent or otherwise. No one can say or prove whether the agents involved in any transaction are the same agents as involved in any other transaction.
Are you claiming category 3 as you seem to be, or category 2?
Lots of people don't distinguish between anonymous and
pseudonymous protocols, so it's worth asking exactly what
you mean here.
Anyway: I'll proceed on the assumption that you meant very
nearly (as nearly as I can imagine, anyway) what you said,
unlinkably anonymous. That means that instead of an "identity",
a spender has to demonstrate knowledge of a secret known only
to the real owner of the coin. One way to do this would be
to have the person recieving the coin generate an asymmetric
key pair, and then have half of it published with the
transaction. In order to spend the coin later, s/he must
demonstrate posession of the other half of the asymmetric
key pair, probably by using it to sign the key provided by
the new seller. So we cannot prove anything about "identity",
but we can prove that the spender of the coin is someone who
knows a secret that the person who recieved the coin knows.
And what you say next seems to confirm this:
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.
Note, even though this doesn't involve identity per se, it still
makes the agent doing the spend linkable to the agent who
earlier recieved the coin, so these transactions are linkable.
In order to counteract this, the owner of the coin needs to make a transaction, indistinguishable to others from any normal transaction, in which he creates a new key pair and transfers the coin to its posessor (ie, has one sock puppet "spend" it to another). No change in real-world identity of the owner, but the transaction "linkable" to the agent who spent the coin is unlinked. For category-three unlinkability, this has to be done a random number of times - maybe one to six times?
In order to counteract this, the owner of the coin needs to make a transaction, indistinguishable to others from any normal transaction, in which he creates a new key pair and transfers the coin to its posessor (ie, has one sock puppet "spend" it to another). No change in real-world identity of the owner, but the transaction "linkable" to the agent who spent the coin is unlinked. For category-three unlinkability, this has to be done a random number of times - maybe one to six times?
BTW, could you please learn to use carriage returns?? Your
lines are scrolling stupidly off to the right and I have to
scroll to see what the heck you're saying, then edit to add
carriage returns before I respond.
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.
Mmmm. I don't know if I'm comfortable with that. You're saying
there's no effort to identify and exclude nodes that don't
cooperate? I suspect this will lead to trouble and possible DOS
attacks.
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.
Okay, when you say "same" transaction, and you're talking about
transactions that are obviously different, you mean a double
spend, right? Two transactions signed with the same key?
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.
Until.... until what? How does anybody know when a transaction
has become irrevocable? Is "a few" blocks three? Thirty? A
hundred? Does it depend on the number of nodes? Is it logarithmic
or linear in number of nodes?
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.
But in the absence of identity, there's no downside to them
if spends become invalid, if they've already recieved the
goods they double-spent for (access to website, download,
whatever). The merchants are left holding the bag with
"invalid" coins, unless they wait that magical "few blocks"
(and how can they know how many?) before treating the spender
as having paid.
The consumers won't do this if they spend their coin and it takes
an hour to clear before they can do what they spent their coin on.
The merchants won't do it if there's no way to charge back a
customer when they find the that their coin is invalid because
the customer has doublespent.
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.
So there's a possibility of an early catch when the broadcasts of
the initial simultaneous spends interfere with each other. I assume
here that the broadcasts are done by the sellers, since the buyer
has a possible disincentive to broadly disseminate spends.
If the new chain is accepted, then they give up on adding their current link ... 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.
Okay, that's a big difference between a proof of work that takes
a huge set number of CPU cycles and a proof of work that takes a
tiny number of CPU cycles but has a tiny chance of success. You
can change the data set while working, and it doesn't mean you
need to start over. This is good in this case, as it means nobody
has to hold recently recieved transactions out of the link they're
working on.
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?
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.
Right. That was the misconception I was working with. Again, the
difference between a proof taking a huge set number of CPU cycles
and a proof that takes a tiny number of CPU cycles but has a tiny
chance of success.
Anyone's chance of finding a solution at any time is proportional to their CPU power.
It's like a random variation in the work factor; in this way it works
in your favor.
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.
I don't understand how "transaction fees" would work, and how the money
would find its way from the agents doing transactions to those running
the network. But the economic effect is the same (albeit somewhat
randomized) if adding a link to the chain allows the node to create
a coin, so I would stick with that.
Also, be aware that the compute power of different nodes can be
expected to vary by two orders of magnitude at any given moment in
history.
Bear
reply
Satoshi Nakamoto
https://www.metzdowd.com/pipermail/cryptography/2008-November/014860.html
satoshi at vistomail.com
Sat Nov 15 13:02:00 EST 2008
Previous message: Bitcoin P2P e-cash paper
Next message: Bitcoin P2P e-cash paper
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ray Dillinger wrote:
One way to do this would be to have the person recieving the coin generate an asymmetric key pair, and then have half of it published with the transaction. In order to spend the coin later, s/he must demonstrate posession of the other half of the asymmetric key pair, probably by using it to sign the key provided by the new seller.
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.
Mmmm. I don't know if I'm comfortable with that. You're saying there's no effort to identify and exclude nodes that don't cooperate? I suspect this will lead to trouble and possible DOS attacks.
There is no reliance on identifying anyone. As you've said, it's
futile and can be trivially defeated with sock puppets.
The credential that establishes someone as real is the ability to
supply CPU power.
Until.... until what? How does anybody know when a transaction has become irrevocable? Is "a few" blocks three? Thirty? A hundred? Does it depend on the number of nodes? Is it logarithmic or linear in number of nodes?
Section 11 calculates the worst case under attack. Typically, 5 or
10 blocks is enough for that. If you're selling something that
doesn't merit a network-scale attack to steal it, in practice you
could cut it closer.
But in the absence of identity, there's no downside to them if spends become invalid, if they've already received the goods they double-spent for (access to website, download, whatever). The merchants are left holding the bag with "invalid" coins, unless they wait that magical "few blocks" (and how can they know how many?) before treating the spender as having paid.The consumers won't do this if they spend their coin and it takes an hour to clear before they can do what they spent their coin on. The merchants won't do it if there's no way to charge back a customer when they find the that their coin is invalid because the customer has doublespent.
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
reply
Nicolas Williams
https://www.metzdowd.com/pipermail/cryptography/2008-November/014864.html
Nicolas.Williams at sun.com
Mon Nov 17 16:54:28 EST 2008
Previous message: Bitcoin P2P e-cash paper
Next message: Bitcoin P2P e-cash paper
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Fri, Nov 14, 2008 at 11:04:21PM -0800, Ray Dillinger wrote:
On Sat, 2008-11-15 at 12:43 +0800, Satoshi Nakamoto wrote: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.Okay, that's surprising. If you're not using buyer/seller identities, then you are not checking that a spend is being made by someone who actually is the owner of (on record as having recieved) the coin being spent.
How do identities help? It's supposed to be anonymous cash, right? And
say you identify a double spender after the fact, then what? Perhaps
you're looking at a disposable ID. Or perhaps you can't chase them
down.
Double spend detection needs to be real-time or near real-time.
Nico
reply
James A. Donald
https://www.metzdowd.com/pipermail/cryptography/2008-November/014866.html
jamesd at echeque.com
Mon Nov 17 20:26:31 EST 2008
Previous message: Bitcoin P2P e-cash paper
Next message: ADMIN: end of bitcoin discussion for now
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Nicolas Williams wrote:
How do identities help? It's supposed to be anonymous cash, right?
Actually no. It is however supposed to be pseudonymous,
so dinging someone's reputation still does not help
much.
And say you identify a double spender after the fact, then what? Perhaps you're looking at a disposable ID. Or perhaps you can't chase them down.Double spend detection needs to be real-time or near real-time.
Near real time means we have to use UDP or equivalent,
rather than TCP or equivalent, and we have to establish
an approximate consensus, not necessarily the final
consensus, not necessarily exact agreement, but close to
it, in a reasonably small number of round trips.
reply
James A. Donald
https://www.metzdowd.com/pipermail/cryptography/2008-November/014865.html
jamesd at echeque.com
Mon Nov 17 18:57:39 EST 2008
Previous message: Bitcoin P2P e-cash paper
Next message: unintended?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ray Dillinger wrote:
Okay.... I'm going to summarize this protocol as I understand it.I'm filling in some operational details that aren't in the paper by supplementing what you wrote with what my own "design sense" tells me are critical missing bits or "obvious" methodologies for use.
There are a number of significantly different ways this
could be implemented. I have been working on my own
version based on Patricia hash trees, (not yet ready to
post, will post in a week or so) with the consensus
generation being a generalization of file sharing using
Merkle hash trees. Patricia hash trees where the high
order part of the Patricia key represents the high order
part of the time can be used to share data that evolves
in time. The algorithm, if implemented by honest
correctly functioning peers, regularly generates
consensus hashes of the recent past - thereby addressing
the problem I have been complaining about - that we have
a mechanism to protect against consensus distortion by
dishonest or malfunctioning peers, which is useless
absent a definition of consensus generation by honest
and correctly functioning peers.
First, people spend computer power creating a pool of coins to use as money. Each coin is a proof-of-work meeting whatever criteria were in effect for money at the time it was created. The time of creation (and therefore the criteria) is checkable later because people can see the emergence of this particular coin in the transaction chain and track it through all its "consensus view" spends. (more later on coin creation tied to adding a link).When a coin is spent, the buyer and seller digitally sign a (blinded) transaction record, and broadcast it to a bunch of nodes whose purpose is keeping track of consensus regarding coin ownership.
I don't think your blinding works.
If there is a public record of who owns what coin, we
have to generate a public diff on changes in that
record, so the record will show that a coin belonged to
X, and soon thereafter belonged to Y. I don't think
blinding can be made to work. We can blind the
transaction details easily enough, by only making hashes
of the details public, (X paid Y for
49vR7xmwYcKXt9zwPJ943h9bHKC2pG68m) but that X paid Y is
going to be fairly obvious.
If when Joe spends a coin to me, then I have to have the
ability to ask "Does Joe rightfully own this coin", then
it is difficult to see how this can be implemented in a
distributed protocol without giving people the ability
to trawl through data detecting that Joe paid me.
To maintain a consensus on who owns what coins, who owns
what coins has to be public.
We can build a privacy layer on top of this - account
money and chaumian money based on bitgold coins, much as
the pre 1915 US banking system layered account money and
bank notes on top of gold coins, and indeed we have to
build a layer on top to bring the transaction cost down
to the level that supports agents performing micro
transactions, as needed for bandwidth control, file
sharing, and charging non white listed people to send us
communications.
So the entities on the public record are entities
functioning like pre 1915 banks - let us call them
binks, for post 1934 banks no longer function like that.
But if they recieve a longer chain while working, they immediately check all the transactions in the new links to make sure it contains no double spends and that the "work factors" of all new links are appropriate.
I am troubled that this involves frequent
retransmissions of data that is already mostly known.
Consensus and widely distributed beliefs about bitgold
ownership already involves significant cost. Further,
each transmission of data is subject to data loss, which
can result in thrashing, with the risk that the
generation of consensus may slow below the rate of new
transactions. We already have problems getting the cost
down to levels that support micro transactions by
software agents, which is the big unserved market -
bandwidth control, file sharing, and charging non white
listed people to send us communications.
To work as useful project, has to be as efficient as it
can be - hence my plan to use a Patricia hash tree
because it identifies and locate small discrepancies
between peers that are mostly in agreement already,
without them needing to transmit their complete data.
We also want to avoid very long hash chains that have to
be frequently checked in order to validate things. Any
time a hash chain can potentially become enormously long
over time, we need to ensure that no one ever has to
rewalk the full length. Chains that need to be
re-walked can only be permitted to grow as the log of
the total number of transactions - if they grow as the
log of the transactions in any one time period plus the
total number of time periods, we have a problem.
Biggest Technical Problem: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.To remedy this, you need to either ensure provable propagation of transactions, or vary the work factor for a node depending on how many links have been added since that node's most recent link.Unfortunately, both measures can be defeated by sock puppets. This is probably the worst problem with your protocol as it stands right now; you need some central point to control the identities (keys) of the nodes and prevent people from making new sock puppets.
We need a protocol wherein to be a money tracking peer
(an entity that validates spends) you have to be
accepted by at least two existing peers who agree to
synchronize data with you - presumably through human
intervention by the owners of existing peers, and these
two human approved synchronization paths indirectly
connect you to the other peers in the network through
at least one graph cycle.
If peer X is only connected to the rest of the network
by one existing peer, peer Y, perhaps because X's
directly connecting peer has dropped out, then X is
demoted to a client, not a peer - any transactions X
submits are relabeled by Y as submitted to Y, not X, and
the time of submission (which forms part of the Patricia
key) is the time X submitted them to Y, not the time
they were submitted to X.
The algorithm must be able swiftly detect malfunctioning
peers, and automatically exclude them from the consensus
temporarily - which means that transactions submitted
through malfunctioning peers do not get included in the
consensus, therefore have to be resubmitted, and peers
may find themselves temporarily demoted to clients,
because one of the peers through which they were
formerly connected to the network has been dropped by
the consensus.
If a peer gets a lot of automatic temporary exclusions,
there may be human intervention by the owners of those
peers to which it exchanges data directly to permanently
drop them.
Since peers get accepted by human invite, they have
reputation to lose, therefore we can make the null
hypothesis (the primary Bayesian prior) honest intent,
valid data, but unreliable data transmission - trust
with infrequent random verification. Designing the
system on this basis considerably reduces processing
costs.
Recall that SET died on its ass in large part because
every transaction involved innumerable public key
operations. Similarly, we have huge security flaws in
https because it has so many redundant public key
operations that web site designers try to minimize the
use of https to cover only those areas that truly need
it - and they always get the decision as to what truly
needs it subtly wrong.
Efficiency is critical, particularly as the part of the
market not yet served is the market for very low cost
transactions.
If we solve the sock-puppet issue, or accept that there's a central point controlling the generation of new keys,
A central point will invite attack, will be attacked.
The problem with computer networked money is that the
past can so easily be revised, so nodes come under
pressure to adjust the past - "I did not pay that"
swiftly becomes "I should not have paid that", which
requires arbitration, which is costly, and introduces
uncertainty, which is costly, and invites government
regulation, which is apt to be utterly ruinous and
wholly devastating.
For many purposes, reversal and arbitration is highly
desirable, but there is no way anyone can compete with
the arbitration provided by Visa and Mastercard, for
they have network effects on their side, and they do a
really good job of arbitration, at which they have vast
experience, accumulated skills, wisdom, and good repute.
So any new networked transaction system has to target
the demand for final and irreversible transactions.
The idea of a distributed network consensus is that one
has a lot of peers in a lot of jurisdictions, and once a
transaction has entered into the consensus, undoing it
is damn near impossible - one would have to pressure
most of the peers in most of the jurisdictions to agree,
and many of them don't even talk your language, and
those that do, will probably pretend that they do not.
So people will not even try.
To avoid pressure, the network has to avoid any central
point at which pressure can be applied. Recall Nero's
wish that Rome had a single throat that he could cut. If
we provide them with such a throat, it will be cut.
reply
If one of the "new" links has an inappropriate work factor (ie, someone didn't put enough CPU into it for it to be "licit" according to the rules) a new "transaction" which is a proof of the protocol violation by the link-creating node is created, broadcast, and added to pool A, and the chain is rejected. In the case of no double spends and appropriate work factors for all links not yet seen, they accept the new chain as consensus.
This is probably the worst problem with your protocol as it stands right now; you need some central point to control the identities (keys) of the nodes and prevent people from making new sock puppets.