Forum Home
    • Register
    • Login
    • Search
    • Recent
    • Tags
    • Popular

    [PROTOCOL] FLUX Examples (from barter to mass network exchange)

    Technical Development
    7
    14
    4055
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • zerodrama
      zerodrama Regular Member last edited by

      [font=courier][b]RULES
      EXCHANGES MUST OCCUR IN PAIRS[/b]
      [b]ONLY MARKED ITEMS ARE VALID[/b]

      Example: Multiple stage barter on one blockchain, no interchain exchange
      User opcodes are 20-27. Miner opcodes are 28-2E. Miners may also output user opcodes. Users may not output miner opcodes.
      DESCRIPTION | OPCODE | FUNCTION | PARAMETERS | NOTES |

      START SEQUENCE
      Initial (once)
      1. Load FLUX module into slot 2 | 2F | Load module | FLUX Ver 0.0.1:MAIN:00 | Special func F is Load module in slots 2-E. Module, ver:MAIN collection:Default config. |

      Announcements (multiple)
      2. Post partial exchange order | 20 | Announce | Bacon:Blank:User Key A | User posts for bacon, await response. Give public key A for partial order. |
      3. Respond to partial order | 20 | Announce | Eggs:Bacon:U Key B | Responding about bacon, waiting for official match. Public key B for response. |

      Miners match, confirm (multiple)
      4. Miner matches orders | 28 | Match | Part:Resp:Miner key C | Miner declares it has found a match and lists the addresses of the announcements. |
      5. Miner confirms match | 29 | Confirm | Match:Conf num:M key D | Miner confirms match. Begins or increments confirmation counter. |
      6. Miner marks match | 2A | Mark | Confirm:Match:M key E | Miner sees minimum number confirms is reached. Last confirm address, match address. |

      Announce accept (multiple)
      7. Accept a trade | 21 | Accept | Resp:Mark:Sign A | We accept the response address for marked match. Sign acceptance with private key A. |

      Miners replace blanks (multiple)
      8. Miner replaces part announce | 2B | Replace | Mark:Resp addr:M key F | Miner tells link system to replace blank in partial announcement for accepted trade. |

      Acknowledgements (multiple)
      [/font][font=courier]9. Acknowledge acceptance | 22 | Acknowledge | Resp:Mark:Sign B | User acknowledges accepted trade. |

      LINK BARTER AND START OFFERS
      Miners link, confirm (multiple)
      10. Miner links indirect trades | 2C | Link | Ann A: B: C:M key G | Announcements A, B linked via C. Bacon for potatoes via eggs. |
      11. Miner confirms link | 28 | Confirm | Link:Conf num:M key H | Miner confirms link. Begins or increments confirmation counter. |
      12. Miner marks link | 29 | Mark | Confirm:Link:M key I | Miner sees minimum number confirms is reached. Last confirm address, link address. |

      Select trade, quantity (multiple)
      13. Select trade offer quantity | 23 | Offer | Mark:Quantity:U Key J | Select marked item, offer quantity for already accepted trade. Mark address, quantity. |
      14. Respond to offer quantity | 23 | Offer | Offer:Quantity:U Key K | Respond to offer for quantity for an already accepted trade. Offer address, quantity. |

      Miners match, confirm (multiple)
      16. Miner matches offers | 28 | Match | Ann:Offer:M key L | Miner declares it has found a match and lists the addresses of the announcements. |
      17. Miner confirms match | 29 | Confirm | Match:Conf num:M key M | Miner confirms match. Begins or increments confirmation counter. |
      18. Miner marks match | 2A | Mark | Confirm:Match:M key N | Miner sees minimum number confirms is reached. Last confirm address, match address. |

      Users counter offer (multiple)
      19. Counter offer | 23 | Offer | Resp Offer:Qty:Sign J | Counter offer with signature. Response to offer address, quantity. |

      [/font][font=courier]Miners match, confirm (multiple)
      20. Miner matches counter offer | 28 | Match | Ann:Offer:M key O | Miner declares it has found a match and lists the addresses of the announcements. |
      21. Miner confirms match | 29 | Confirm | Match:Conf num:M key P | Miner confirms match. Begins or increments confirmation counter. |
      22. Miner marks match | 2A | Mark | Confirm:Match:M key Q | Miner sees minimum number confirms is reached. Last confirm address, match address. |

      Users accept, ack offers (multiple)
      23. Accept counter offers | 21 | Accept | Offer:Mark:Sign J | We accept counter offer address for marked match. Sign acceptance with private key C. |
      [/font][font=courier]24. Acknowledge acceptance | 22 | Acknowledge | Offer:Mark:Sign K | User acknowledges accepted counter offer. |

      VALUE DISCOVERY
      Miners follow links, get values (multiple)
      [/font][font=courier]25. Miner calculates values | 2D | Value | Mark:Low:High:M key R | Announce high, low relative values for items for each possible exchange including links. |
      26. Miner confirms values | 29 | Confirm | Value:Conf num:M key S | Miner confirms value. Begins or increments confirmation counter. |
      27. Miner marks values | 2A | Mark | Confirm:Value:M key T | Miner sees minimum number confirms is reached. Last confirm address, value address. |

      [/font][font=courier]Select trade, quantity (multiple)
      28. Select trade offer new qty | 23 | Offer | Mark:New Qty:U Key U | Select marked item, offer new qty for already accepted trade. Mark address, new qty. |
      29. Respond to offer of new qty | 23 | Offer | Offer:New Qty:U Key V | Respond to offer for new qty for an already accepted trade. Offer address, new qty. |

      Miners match, confirm (multiple)
      30. Miner matches new offers | 28 | Match | Ann:New Offer:M key W | Miner declares it has found a match and lists the addresses of the announcements. |
      31. Miner confirms match | 29 | Confirm | Match:Conf num:M key X | Miner confirms match. Begins or increments confirmation counter. |
      32. Miner marks match | 2A | Mark | Confirm:Match:M key Y | Miner sees minimum number confirms is reached. Last confirm address, match address. |

      Users counter offer (multiple)
      33. New counter offer | 23 | Offer | Resp Offer:Qty:Sign U | New counter offer with signature. Response to offer address, quantity. |

      Miners match, confirm (multiple)
      34. Miner matches counter offer | 28 | Match | Ann:Offer:M key Z | Miner declares it has found a match and lists the addresses of the announcements. |
      35. Miner confirms match | 29 | Confirm | Match:Conf num:M key AA| Miner confirms match. Begins or increments confirmation counter. |
      36. Miner marks match | 2A | Mark | Confirm:Match:M key AB | Miner sees minimum number confirms is reached. Last confirm address, match address. |

      Users accept, ack offers (multiple)
      37. Accept counter offers | 21 | Accept | Offer:Mark:Sign U | We accept counter offer address for marked match. Sign acceptance with private key C. |
      38. Acknowledge acceptance | 22 | Acknowledge | Offer:Mark:Sign V | User acknowledges accepted counter offer. |

      SELECTION
      Users lock in offers, confirm delivery (multiple)
      39. Lock | 24 | Lock | Mark:Signature AC | Locked in mark address. |
      40. Confirm send | 25 | Send | Mark:Proof:Sign AC | Confirm sending with proof. |
      41. Confirm receiving | 26 | Receive | Send:Proof:Sign AD | Confirm delivery with proof. |

      Miners get paid and close offers(multiple)
      42. Pay miner and close offer | 2E | Pay | Mark:Miner key:Sign | Request payment for all work done (from starting mark) and if delivered close offers. |

      OPCODES NOT USED
      00. Retract entry | 27 | Retract | Address:User key:Sign | Retract entry by user and have miners remove/redo dependent entries/calculations. |

      Now this might seem a bit much for barter, but it allows multiple barter stages, matches trades, and discovers values. Also note cascading dependencies in matching, confirming, and marking. One other thing: accepting doesn’t mean you will buy. It means you think the offers are reasonable. Finally, some of these opcodes instruct the miners to generate lower level Link opcodes, such as for closing the orders.

      42!
      [/font]

      1 Reply Last reply Reply Quote 0
      • zerodrama
        zerodrama Regular Member last edited by

        Well that’s one example done.

        I will do more soon:

        Link: Filesharing, Custom structure domain names, Patent busting.

        FLUX: Barter, Interpool loan, Decentralized exchange, Collateralized purchases.

        1 Reply Last reply Reply Quote 0
        • T
          Tuck Fheman last edited by

          [quote name=“zerodrama” post=“47819” timestamp=“1388154180”]
          42!
          [/quote]

          You had me @ 42.

          1 Reply Last reply Reply Quote 0
          • M
            mnstrcck last edited by

            FYI, apparently there’s a 300 BTC bounty for a decentralized exchange.

            1 Reply Last reply Reply Quote 0
            • zerodrama
              zerodrama Regular Member last edited by

              [quote name=“mnstrcck” post=“47926” timestamp=“1388184803”]
              FYI, apparently there’s a 300 BTC bounty for a decentralized exchange.
              [/quote]

              Guess we better get on with this.

              1 Reply Last reply Reply Quote 0
              • ?
                A Former User last edited by

                Talk about been on the frontline of leaps and bounds… Far, out…

                1 Reply Last reply Reply Quote 0
                • zerodrama
                  zerodrama Regular Member last edited by

                  So this thing is supposed to be more or less asynchronous. I’m going to show another view of the same thing only with the interactions rather than the codes. Also some of these don’t necessarily need opcodes since blockchain already does that.

                  1 Reply Last reply Reply Quote 0
                  • K
                    Kevlar Spammer last edited by

                    This is a really good step in the right direction. I’m having trouble following who does what though.

                    I need this same sequence but with an additional field: Who did it.

                    Is each row a different spend in the blockchain? I would assume it would have to be since this is asynchronous.

                    1 Reply Last reply Reply Quote 0
                    • zerodrama
                      zerodrama Regular Member last edited by

                      [quote name=“Kevlar” post=“48112” timestamp=“1388267210”]
                      This is a really good step in the right direction. I’m having trouble following who does what though.

                      I need this same sequence but with an additional field: Who did it.

                      Is each row a different spend in the blockchain? I would assume it would have to be since this is asynchronous.
                      [/quote]

                      Yes each row is a spend. I am trying to compress it a bit. Obvly, some of these actions can be performed by the host chain.

                      To follow along:
                      Keep in mind, 2F is a special function all slots have.
                      20-27 are user opcodes.
                      28-2E are miner opcodes.
                      Miners will also output user opcodes (when we do the heavy work like decentralized exchange).
                      The spender can be found via the addresses or the keys in the parameters (FLUX [b]Link Unit[/b] eXchange).
                      From the example:
                      [font=courier]4. Miner matches orders | 28 | Match | Part:Resp:Miner key C | Miner declares it has found a match and lists the addresses of the announcements. |
                      5. Miner confirms match | 29 | Confirm | Match:Conf num:M key D | Miner confirms match. Begins or increments confirmation counter. |
                      6. Miner marks match | 2A | Mark | Confirm:Match:M key E | Miner sees minimum number confirms is reached. Last confirm address, match address. |
                      [/font]
                      4 reads like this: 28 | Partial announcement address, Response announcement address, Miner C’s public key for future signatures (like getting paid)
                      This will produce a match address.

                      5 reads like this: 29 | Match address from 4, Confirmations so far, Miner D’s public key for future signatures
                      This will produce a confirmation address.

                      6 reads like this: 2A | Last confirmation address (when we reach the minimum 6 or 10 or whatever), Original match address, Miner E’s public key for future signatures
                      This will produce a mark address.

                      There is nothing special about the match, confirm, or mark address. That’s just a convention to help us keep track. The real power here is that this is just an example, the opcodes are more meta than this. Any address may be used and in the future the functions won’t be named match, confirm, or mark, they will have more general names. They may even be reduced to just one or two opcodes. The parameter schema are the same for all but the confirm one, which requires a quantity, so they could be done with one opcode, but that would be much harder to read. Also the confirm function may be done by the blockchain itself, in which case, the mark function would use the last confirm tx id. But that might tie it too much to a blockchain. Maybe in the future blockchains won’t use tx ids or they will use multiple tx ids. So for now I think three opcodes is clearest. Two minimum at least.

                      Now most of these will happen multiple times as miners discover partial announcements and try to match them to responses and so on. The mark address is important. Until an interaction is marked, it cannot be used in any calculation or negotiation. Essentially, what I’m doing is using snapshots (like a decentralized checkpointing system) to build up to where we can do the decentralized exchange. Each stage of verification is like separating low risk template space from high risk code space. In the exchange, when it’s done, low risk negotiations will be done with rewards for failed hashes (FLUX tokens), and once those pathways for the exchanges are agreed to, the real transfers will have to follow that prerecorded exchange history or they will be invalid.

                      NO EXODUS ADDRESS NEEDED.

                      So basically to follow the asynchronous process, unless it says it’s a quantity, the parameters are address references to previous spends or either keys or signatures.

                      1 Reply Last reply Reply Quote 0
                      • zerodrama
                        zerodrama Regular Member last edited by

                        I just want to emphasize: It’s FLUX [b]Link Unit[/b] eXchange. FLUX exchanges Link entries. Anything Link can store, FLUX can exchange.

                        Which brings me to future possibility: Miniature Magic the Gathering type game to demonstrate Link and FLUX possibilities.

                        1 Reply Last reply Reply Quote 0
                        • lizhi
                          lizhi last edited by

                          Can it embedded client or a website API ?

                          1 Reply Last reply Reply Quote 0
                          • zerodrama
                            zerodrama Regular Member last edited by

                            [quote name=“lizhi” post=“48657” timestamp=“1388499469”]
                            Can it embedded client or a website API ?
                            [/quote]

                            People will code custom bots with their own negotiation rules for conducting the exchanges.

                            1 Reply Last reply Reply Quote 0
                            • C
                              chrisj Regular Member last edited by

                              Can someone give me an ELI5 on this plz? Sounds super cool and I like the energy.

                              1 Reply Last reply Reply Quote 0
                              • First post
                                Last post