> > 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 <natanae...@gmail.com> wrote: > Den 8 jan 2015 11:54 skrev "realcr" <rea...@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. >
_______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
