[PROTOCOL] FLUX Examples (from barter to mass network exchange)
-
[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] -
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.
-
[quote name=“zerodrama” post=“47819” timestamp=“1388154180”]
42!
[/quote]You had me @ 42.
-
FYI, apparently there’s a 300 BTC bounty for a decentralized exchange.
-
[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.
-
Talk about been on the frontline of leaps and bounds… Far, out…
-
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.
-
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 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.
-
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.
-
Can it embedded client or a website API ?
-
[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.
-
Can someone give me an ELI5 on this plz? Sounds super cool and I like the energy.