i understand how multisig works. thats not the confusing part. its the idea of people honouring each others obligations and doing multisig. when i think of federating i think of people honouring each others agreements but then clearing their balances with each other periodically. so like if you and i federated and we issued 10 silver bars each. and then all 20 bars were redeemed through my gateway. you would owe me 10 silver bars. you would send the bars and then the balances would be cleared. we were able to federate because i trusted you.
oooh i get it now. i see why the wires were getting crossed. if you did a multisig account you wouldn’t be federating you would be incorporating!
Can we get a balance where the federation of the gateways ensures the integrity of the transaction without becoming liable for the asset?
What I tried to get across in my reply to James a few pages back (which you kindly responded to) was the transaction is a contracts between the buyer and the seller and gateways cooperate to enforce the escrow / atomicity of the transaction and asset being transferred for which the gateways get a fee.
Firstly for this to work each maybe you need gateway relationship to be verified bi-laterally, i.e. a gateway to gateway trust relationship is pre-established, I am not sure this exists in the Ripple model which is why I think there is a problem - is this what you mean by federation.
Each buyer and seller legitimise the asset with each gateway involved e.g. deposit asset in escrow or reserve somehow.
The buyer sends the transaction request to the sellers gateway to buy the asset (with the relevant buy/sell asset ids from each gateway)
The sellers gateway initiates a transaction on the block chain which is seen by buyers gateway and this is validated by forging as legitimate (e.g. 10 confirms?)
The buyers gateway then confirms the transaction by re-submitting again to be validated by forging to confirm the buyer honours the contract.
The two gateways can then release the escrow asset to the buyer and seller respectively.
The transaction ledger could be the NXT blockchain, once the transaction is validated by forging the seller gateway releases the asset to the buyer and the buyer gateway releases the asset to the seller.
The buyer/seller gateways would get their fees from the buyer/seller respectively
There is a NXT fee for each of the transactions involved.
What I am trying to achieve is the gateways are acting to ensure the safe transfer of an asset between two parties but maybe this is too hard complicated?
For widespread adoption there needed to be trust in the integrity of the transaction and that should be down to whether Anon, Bob or Sally tokens have a different trust level.
Without some level of transaction legitimacy validated by NXT itself I fear we would have a massive dispute resolution problem with scam buyers as much of a problem as scam sellers.
I think you are overcomplicating. The ONLY function of the gateway is to accept deposit and process withdrawal of an asset. I am only dealing with crypto gateways here, more specifically cryptos with multisig support like BTC.
All the gateways in the federation would agree to run the same software, or at least software that makes the same business decisions. All the transactions are on the BTC blockchain or NXT blockchain. For deposits, all gateways accept it and put it into shared multisig deposit acct and issue their asset. For user simplicity, I suggest all gateway specific BTC be exchanged automatically to a federation BTC. [maybe federation is the wrong word?] Then users would just trade the federation BTC Asset as much as they want. NXT AE makes sure everyone ends up with the right amount of federation BTC.
Finally, when the user wants to withdraw actual BTC, he needs to select a gateway, which triggers the automated multisig process. We need to protect the withdrawal process. All of the asset issuance and deposits will be monitored in realtime by all the different gateways. The withdrawal process is validated by multisig from all gateways (minus 1) and the user gets BTC in his wallet.
The moment a gateway accepts a deposit and doesnt issue a matched amount of Asset, or just issues unbacked Assets, they will be caught redhanded by all the other gateways. Also, to do this, they would have to change the automated gateway software and replace it with an Evil one. There are ways to ensure this doesnt happen!
I think the overall plan is decent, but it is still young and definitely needs to be gone over with a fine tooth comb to fine any possible ways Evil bob can circumvent things and abscond with BTC
