[137800] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: Bitcoin P2P e-cash paper

daemon@ATHENA.MIT.EDU (James A. Donald)
Mon Nov 17 12:06:26 2008

Date: Sun, 16 Nov 2008 10:00:04 +1000
From: "James A. Donald" <jamesd@echeque.com>
To: satoshi@vistomail.com
CC: hal@finney.org, cryptography@metzdowd.com
In-Reply-To: <CHILKAT-MID-41a4bab8-9538-d1ea-d079-b843b2667bec@server123>

Satoshi Nakamoto wrote:
 > Fortunately, it's only necessary to keep a
 > pending-transaction pool for the current best branch.

This requires that we know, that is to say an honest
well behaved peer whose communications and data storage
is working well knows, what the current best branch is -
but of course, the problem is that we are trying to
discover, trying to converge upon, a best branch, which
is not easy at the best of times, and becomes harder
when another peer is lying about its connectivity and
capabilities, and yet another peer has just had a major
disk drive failure obfuscated by a software crash, and
the international fibers connecting yet a third peer
have been attacked by terrorists.

 >  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

Which presupposes the branches exist, that they are
fully specified and complete.  If they exist as complete
works, rather than works in progress, then the problem
is already solved, for the problem is making progress.

 > Broadcasts will probably be almost completely
 > reliable.

There is a trade off between timeliness and reliability.
One can make a broadcast arbitrarily reliable if time is
of no consequence.  However, when one is talking of
distributed data, time is always of consequence, because
it is all about synchronization (that peers need to have
corresponding views at corresponding times) so when one
does distributed data processing, broadcasts are always
highly unreliable Attempts to ensure that each
message arrives at least once result in increased timing
variation. Thus one has to make a protocol that is
either UDP or somewhat UDP like, in that messages are
small, failure of messages to arrive is common, messages
can arrive in different order to the order in which they
were sent, and the same message may arrive multiple
times.  Either we have UDP, or we need to accommodate
the same problems as UDP has on top of TCP connections.

Rather than assuming that each message arrives at least
once, we have to make a mechanism such that the
information arrives even though conveyed by messages
that frequently fail to arrive.

 > TCP transmissions are rarely ever dropped these days

People always load connections near maximum.  When a
connection is near maximum, TCP connections suffer
frequent unreasonably long delays, and connections
simply fail a lot - your favorite web cartoon somehow
shows it is loading forever, and you try again, or it
comes up with a little x in place of a picture, and you
try again

Further very long connections - for example ftp
downloads of huge files,  seldom complete. If you try to
ftp a movie, you are unlikely to get anywhere unless
both client and server have a resume mechanism so that
they can talk about partially downloaded files.

UDP connections, for example Skype video calls, also
suffer frequent picture freezes, loss of quality, and so
forth, and have to have mechanisms to keep going

 > It's very attractive to the libertarian viewpoint if
 > we can explain it properly.  I'm better with code than
 > with words though.

No, it is very attractive to the libertarian if we can
design a mechanism that will scale to the point of
providing the benefits of rapidly irreversible payment,
immune to political interference, over the internet,
to very large numbers of people. 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 really should provide a fleshed out version of your
proposal, rather than nagging you to fill out the blind

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

home help back first fref pref prev next nref lref last post