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

zerodrama

AND WE ARE GO!. We can debate details of the design here: [url=http://forum.feathercoin.com/index.php/topic,6185.0.html]http://forum.feathercoin.com/index.php/topic,6185.0.html[/url]. Kickstart will be announced next week. Likely, Kevlar will do initial code to ensure it works properly in Link, but once I understand how to code it correctly, I am going be spewing applications and extensions of Link / FLUX left and right.
I own both peermarket.net (FLUX inputs) and baconplaza.com (all sorts of fun stuff). Once this is done I am also building flightriskgame.com.

ALRIGHTY THEN!

We’re going to begin the examples with probably the most important rule: Exchanges must occur in pairs.

Also this is the first proposal. As patterns emerge it will become significantly simpler.

zerodrama

[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 |

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]

zerodrama

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.

Tuck Fheman

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

You had me @ 42.

mnstrcck

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

zerodrama

[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…

zerodrama

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.

Kevlar

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.

zerodrama

[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.

zerodrama

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.

lizhi

Can it embedded client or a website API ?

zerodrama

[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.

chrisj

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