> Is there a way of constructing a digital signature so
> that the signature proves that at least m possessors of
> secret keys corresponding to n public keys signed, for n
> a dozen or less, without revealing how many more than m,
> or which ones signed?
Yes there are a number of ways. Usually t
James A. Donald wrote:
>OK, suppose one node incorporates a bunch of
>transactions in its proof of work, all of them honest
>legitimate single spends and another node incorporates a
>different bunch of transactions in its proof of
>work, all of them equally honest legitimate single
>spends, and bot
Satoshi Nakamoto wrote:
> 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
Is there a way of constructing a digital signature so
that the signature proves that at least m possessors of
secret keys corresponding to n public keys signed, for n
a dozen or less, without revealing how many more than m,
or which ones signed?
---
--
Satoshi Nakamoto wrote:
> 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 transacti
Satoshi Nakamoto wrote:
> 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
James A. Donald wrote:
> The core concept is that lots of entities keep complete and consistent
> information as to who owns which bitcoins.
>
> But maintaining consistency is tricky. It is not clear to me what
> happens when someone reports one transaction to one maintainer, and
> someone else tra
Hal Finney wrote:
> it is mentioned that if a broadcast transaction does not reach all nodes,
> it is OK, as it will get into the block chain before long. How does this
> happen - what if the node that creates the "next" block (the first node
> to find the hashcash collision) did not hear about the