Topic: Could virtual synchrony help bitcoin? (Read 632 times)

Bitcoin is not just a distributed network.  Its nodes also come to consensus by following the protocol rules but without necessarily trusting each other, but there are limitations to that as noted above.  Anyway, I don't think spread can provide this distributed consensus. Can it?

I found this from the Bitcoin Weakness wiki:

https://en.bitcoin.it/wiki/Weaknesses

Maybe stream a video with your transaction?

I dont know the toolkit but the names... the dev's must have a good sense of humor.


wouldnt want to mess those up

I don't think there is currently a use for synchronous or in-order messages. You could be the first to come up with one.

I may be wrong cause I'm not a bitcoin expert but I'll take a stab at this:

I think the answer would be no  bitcoin doesn't need this because all communications
are done over TCP, and bitcoin has it's own special system for distributed data that works
fine.

Greetings,


  I was wandering if anyone has looked at using virtual synchrony in bitcoin?
This allows for multiple programs to sent multicast messages to one another with
order guaranteed so that every process receives the message at the same time.

I have been using an excellent message oriented middle-ware for some of my projects at work over the past 10 years called the spread toolkit. There may be others, but this is the one I am familiar with, here is a quick overview:

http://www.spread.org/SpreadOverview.html


Here is an example of the kind of messaging control it provides:

RELIABLE_MESS:
    The message will arrive once at all members of its destination group, it may be arbitrarily, but finitely delayed before arriving, and may arrive out of order with regards to other reliable messages.

FIFO_MESS:
    The message will be reliably delivered once to all members of its destination groups, and it will be ordered with all other FIFO messages from the same source. Nothing is guaranteed about the ordering of FIFO messages from different sources.
   
CAUSAL_MESS:
    These messages have all the properties of FIFO messages and in addition are causally ordered (as defined by Lamport) with regards to all sources.

AGREED_MESS:
    These messages have all the properties of FIFO messages but will be delivered in a causal ordering which will be the same at all recipients, i.e. all the recipients will 'agree' on the order of delivery.

SAFE_MESS:
    These messages have all the properties of AGREED messages, but are not delivered until all daemons have received it and are ready to deliver it to the application. This guarantees that if any one application receives a SAFE message then all the applications in that group will also receive it unless the machine or program crashes.



The library implements a publisher/subscriber model were an application can create
a message group that other applications join. It operates like chat room where each message sent by one application is received by any application joined to the spread group.


I was wandering if such a toolkit would be helpful to bitcoin?