[PROTOCOL] FLUX Examples (from barter to mass network exchange)
-
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.
