[cryptography] The Wandering Music Band

realcr realcr at gmail.com
Thu Jan 8 07:00:55 EST 2015


>
> You still don't get any meaningful security if old band members are
> assumed to be untrusted and you don't use a public checkpointing mechanism.
> Transfer of the title of being the real group must be a one-time only thing
> for each version of the group, and must be impossible to backtrack from.
> Bitcoin enforces this by design.


If you are worried about Synchronization issues within the band itself: I
don't need Bitcoin to solve it. The Band is small, and it has a majority of
correct members.
Therefore I can use some secure multiparty computation to take decisions
within the band, and also remove and add members securely.

I think you overestimate the impact of using Bitcoin.


My problem was that the naive solution makes every band keep a linear
amount of signatures with respect to time, which is too much.
As a solution you proposed Bitcoin, where all the network participants will
remember everything from the beginning of time. That's the opposite of what
I'm trying to do.

I made sure that every operation in the network result in no more than
O(polylog(n)) operations. I am definitely not going to use Bitcoin on it,
where every transaction costs O(n) network complexity.
(Not mentioning the proof of work calculations). It doesn't make sense to
me.

It isn't all our nothing as not all members need to be full nodes, in fact
> none of them have to be.
>

What if everyone did that?  Bitcoin will stop working properly. (Or it will
become central, and that is what Bitcoin tries to avoid from the first
place.)

The Bitcoin developers is constantly working on scalability, and the
> network is meant to one day be able to handle thousands of transactions per
> second
>

I It might be true, but it is still O(n) network complexity per
transaction, and lots of proof of work calculations.
The naive solution proposed in my first message will still outperform the
most efficient Bitcoin based solution. (Because it is O(log(n)) network
complexity).




On Thu, Jan 8, 2015 at 1:12 PM, Natanael <natanael.l at gmail.com> wrote:

> Den 8 jan 2015 11:54 skrev "realcr" <realcr at gmail.com>:
> >
> > Hey, thanks again for the reply.
> >>
> >> The only notable difference is that in my version you are checkpointing
> the change in th blockchain.
> >>
> >> You still have the very same form of signing, but you sign a slightly
> different message (transfer of a colored coin, one Satoshi worth of
> Bitcoin, to a new address) instead of "group members XYZ are now the
> official group instead of ABC".
> >
> >
> > I disagree with you, or maybe I have misunderstood you idea. I think
> that Bitcoin is not related here.
> >
> > Bitcoin is all or nothing. If I want to use it, all the participants of
> the network have to be part of it.
> > That means that all the participants of the network have to compute
> hashes all the time.
> > In addition, every Bitcoin transaction involves all the participants of
> the network.
>
> I think you overestimate the impact of using Bitcoin. It isn't all our
> nothing as not all members need to be full nodes, in fact none of them have
> to be. While it is true that all full nodes must store all the
> transactions, and that it gets forwarded in the network among most online
> nodes as it gets published, only the latest one would need to be kept in
> their index of the unspent outputs (UTXO set) from the blockchain. The
> Bitcoin developers is constantly working on scalability, and the network is
> meant to one day be able to handle thousands of transactions per second
> (this is years off, though). The blockchain can easily be stored on MicroSD
> cards!
>
> Verifying the headers alone for decades worth of hashes takes at most
> minutes on smartphones. And that's a one-time job per header hash, per
> device. Each new header takes much less than a second to process.
> Publishing and verifying the colored coin transactions is trivial too.
>
> > Secrecy is not required. I meant to say that the band has the
> responsibility of keeping the signatures and show them on demand.
>
> You still don't get any meaningful security if old band members are
> assumed to be untrusted and you don't use a public checkpointing mechanism.
> Transfer of the title of being the real group must be a one-time only thing
> for each version of the group, and must be impossible to backtrack from.
> Bitcoin enforces this by design.
>
> Other standard public checkpointing mechanisms don't verify if there's
> conflicting messages or not, so then ALL messages that has been
> checkpointed must be stored.
>
> There are cryptocurrencies with similar functionality (doublespend
> protection, conflicting assignments not allowed) and other trust models (no
> proof-of-work for chain selection). As an example, Ripple is federated, a
> set of trusted nodes agree on the order of transactions. This removes most
> of your performance related issues. But I don't trust it if security is
> important, it seems too ad-hoc. Then there's proof-of-stake which is very
> problematic for a million different reasons (no guarantee there will be
> concensus), but the network performance issues from Bitcoin remains here.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20150108/12b81523/attachment-0001.html>


More information about the cryptography mailing list