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

      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