Blockchain

Generali

Hi Bitcoin lovers and others that are interested in such things.:iloveyou:

A question regarding the blockchain.

Lots of banks like to net payments between themselves off against each other: if I owe you £10 and you owe me £7 then risk is reduced if I simply agree to pay you £3. If you go bust I remain in the same position I was always in as I've paid you what I owed. If I go bust you're in a great position as you've lost £3 rather than £17 (being the £7 you've just paid me gross plus the £10 that you haven't had from me).

As I understand the blockchain, each ledger entry has to be resolved separately and effectively anonymously. Would net payments of the type I described still be possible? I don't see how with the way things are currently configured.

I know I've been anti-Bitcoin/blockchain in the past but I am now genuinely trying to understand its good and bad points.

Can a distributed ledger really deal with net settlement without duplication of liabilities? I can't see how but perhaps that's because I don't understand properly.

mwpt

Netting is not a construct of the current fiat system, it is a construct on top of it. In your example there is nothing inbuilt into the fiat system that says you can net +£10 and -£7 and the result is £3 of fiat. It is simply that the two parties in the transaction agree to a higher level construct called a netted settlement and then fiat gets involved and £3 fiat is moved between parties.

If we take bitcoin as an example, to replicate this same functionality is obviously trivial. You and the counterparty agree to a netting deal, record it as such in a higher level construct, and then execute the £3 transaction in the bitcoin ledger. Bitcoin knows nothing about the netting. I'm sure you know this obviously and so that isn't what you're asking.

I cannot answer your immediate question because I don't know if bitcoin or any other blockchain currency or system has netting built in at the moment, but I assume somewhere that one of them does, almost certainly. A distributed ledger can do anything you code it to do. Someone just has to make the relevant code changes and bingo, netting will be possible as a construct of the system itself rather than a higher level construct outside of the system.

Generali

mwpt wrote: »

Netting is not a construct of the current fiat system, it is a construct on top of it. In your example there is nothing inbuilt into the fiat system that says you can net +£10 and -£7 and the result is £3 of fiat. It is simply that the two parties in the transaction agree to a higher level construct called a netted settlement and then fiat gets involved and £3 fiat is moved between parties.

If we take bitcoin as an example, to replicate this same functionality is obviously trivial. You and the counterparty agree to a netting deal, record it as such in a higher level construct, and then execute the £3 transaction in the bitcoin ledger. Bitcoin knows nothing about the netting. I'm sure you know this obviously and so that isn't what you're asking.

I cannot answer your immediate question because I don't know if bitcoin or any other blockchain currency or system has netting built in at the moment, but I assume somewhere that one of them does, almost certainly. A distributed ledger can do anything you code it to do. Someone just has to make the relevant code changes and bingo, netting will be possible as a construct of the system itself rather than a higher level construct outside of the system.

This isn't aimed at you so much as building upon your answers:

1. How do the counterparties instruct the blockchain to net previous instructions? I suppose that could be interpreted as a new ledger entry rather than an amendment to a previous one so maybe that's all good.
2. Who makes the coding change and who makes sure it's all good?

Jonbvn

Gen,

AFAIK, net transactions are not built into the blockchain. Each discrete transaction must be present in the blockchain. BTW, I understand that the whole BTC blockchain is a bit of a monster now.

Generali

Jonbvn wrote: »

Gen,

AFAIK, net transactions are not built into the blockchain. Each discrete transaction must be present in the blockchain. BTW, I understand that the whole BTC blockchain is a bit of a monster now.

That's my thought.

I'm trying to understand exactly how the blockchain works and what its advantages and disadvantages are.

I hope that the advantages of net settlement are clear: risk is reduced. Having said that there are risks associated with net settlement in that liquidity can be reduced. For example, if I owe you £10 and want to lend £7 then under a net settlement system I will be more inclined to lend to you than into the open market. That reduces the stock of borrowed funds available to not-you.

In FX markets they try to get around this by using multi-party netting. Instead of me trading with you we each give up our trades to 'the market'. If I owe you £5 and you owe Davo £5 then I simply pay Davo £5 and all our liabilities are satisfied. I can't see how multi-party netting could work in a blockchain.

mwpt

Generali wrote: »

This isn't aimed at you so much as building upon your answers:

1. How do the counterparties instruct the blockchain to net previous instructions? I suppose that could be interpreted as a new ledger entry rather than an amendment to a previous one so maybe that's all good.
2. Who makes the coding change and who makes sure it's all good?

1.
I'm not sure what you mean by previous instructions. I may not have enough knowledge of the netting process (I'm front office, not back office) to understand how it works in detail, but my outside understanding has always been that all transactions are recorded in the back office systems, and if you have the correct agreements with your counterparty, a netting system simply calculates the final balances owed. The netted fiat amounts are transferred (settled) and the systems check that everything looks ok and both parties agree with the amounts. But at the higher level, all the transactions are recorded as entries in some database or other persisted storage somewhere.

On a blockchain level, the way I might approach it (keep in mind I have practically zero knowledge of the actually blockchain code), is transactional. Two parties construct a transaction for the amounts owed. A transaction is an atomic bit of work that either succeeds entirely or fails entirely. The transaction records that one party is paying £10 to the other and the other party is paying £7 to the other. Both transactions are recorded and the ledger updated. This eliminates the need for netting because in coding terms the entire transaction must complete, there is no intermediate risk. It has the down side that two sets of crypto calculations must be done to verify each transaction (I assume this to be true). So there may be a possibility of building in a slightly higher level construct into blockchain that takes two transactions, nets them, and then only does the verification work for the single one direction netted transfer. The advantage is fewer calculations required but introducing a new higher level layer introduces complexity to the system. Coders hate increasing complexity.

But as I say, I do not understand what you mean by "previous transactions"

2. Ok, so this is an interesting question. I will try to be brief. Blockchain works by distributed agreement. The outcome of transactions must be agreed by > 50% of nodes on the network for them to be valid. Now, remember, blockchain is the technology, bitcoin is just one use case of the technology. So if we take bitcoins case, literally anyone can obtain the bitcoin code, modify it as they wish on their own computer and run it to join the network. But, it won't do much useful unless > 50% of the rest of the network is running the same code and agrees with the version you're running. The bitcoin code base is I believe maintained by five core developers who allow changes as they deem fit. So I might make a great change and request the changes be used, and the maintainers agree and modify the main codebase. Anyone who wants can now get my changes and it will propagate across the network till it's greater than 50% of the nodes. However, not everyone has to download it. What if 50% of people don't like it and won't run it. I'm simplifying the situation greatly (I'm sure the tulip guy will let me know this), but doing so to make a point.

Ok, so bitcoin isn't the only blockchain currency around. There are many others that run different code to bitcoin and behave slightly differently. And there are other technology uses, like settlement systems you mention, which aren't meant to be currencies. In each case, the same sort of thing applies though, the people running the code that maintains the ledger (the ledger is the 'database' of transactions - again a simplification) must run the same version of the code. So in the case of financial institutions or anyone who wants to interact, they can run any sort of blockchain code they like. I might be sitting at home right now writing a blockchain based clearing system which my company will maintain. I will own the code base and I will make the changes. The companies who use it trust my company to maintain it and make any changes they want (and agree on).

Ugh, that was a lot longer than I intended and undoubtably some of it is incorrect, since I am not an expert. But this is my understanding at present.

Generali

Previous instructions

I enter into a forward contract with you to buy £1,000,000 for AU$2,000,000 for settlement on the next quarter day. That is then entered into the blockchain.

2 days prior to the quarter day I want to enter into a contract to sell £1,000,000 vs AUD in order to close out my position and realise my PnL. I enter my trade and so that becomes a second entry in the blockchain.

Then I want to net 1 vs 2. I don't see how I can do that without either putting a duplicate net entry into the blockchain or erasing the previous entries from the blockchain and replacing them with a new net entry.

The former involves making two claims on one amount of money, the latter involves making changes to the blockchain which is at best difficult AIUI. In the latter case, how can I show that I am cancelling two entries into the blockchain that involve the same parties? I could be fraudulently be cancelling someone else's entry.

Q2

I am very specifically interested in blockchain rather than Bitcoin. Who decides the tech that rules the blockchain? Quis custodiet ipsos custodes?

mwpt

Generali wrote: »

Q2

I am very specifically interested in blockchain rather than Bitcoin. Who decides the tech that rules the blockchain? Quis custodiet ipsos custodes?

Just answering this one quickly while I muse on the other. Blockchain is a protocol or methodology. It doesn't exist in any real sense, it is just an idea, an algorithm or rather a meta-algorithm. Some guy (or possibly more) invented this methodology and made it public. So now anyone can come along, study the methodology and write some real code that uses the blockchain methodology.

Perhaps in a way you could think of it as the design for a catapult. Someone comes up with the engineering behind it, publishes this and then people can go and physically build catapults using the ideas. The catapult idea can morph over time, and people can build their own variations of it to accomplish their own needs.

I do not believe the blockchain methodology has been patented in any way, that would go against the very idea of it intended by the original author. So no one owns the blockchain idea and anyone can come along and code their own blockchain system (catapult).

I may not be the best explanataror [sic] around, feel free to prod me further.

Generali

mwpt wrote: »

Just answering this one quickly while I muse on the other. Blockchain is a protocol or methodology. It doesn't exist in any real sense, it is just an idea, an algorithm or rather a meta-algorithm. Some guy (or possibly more) invented this methodology and made it public. So now anyone can come along, study the methodology and write some real code that uses the blockchain methodology.

Perhaps in a way you could think of it as the design for a catapult. Someone comes up with the engineering behind it, publishes this and then people can go and physically build catapults using the ideas. The catapult idea can morph over time, and people can build their own variations of it to accomplish their own needs.

I do not believe the blockchain methodology has been patented in any way, that would go against the very idea of it intended by the original author. So no one owns the blockchain idea and anyone can come along and code their own blockchain system (catapult).

I may not be the best explanataror [sic] around, feel free to prod me further.

Cheers mwpt.

If my wages are going to be paid into a system then I would quite like to understand how I can turn those wages into food, shelter, paying tax and other liabilities and perhaps hold some of the ledger entries as savings for an uncertain future.

If there is nobody keeping the ledger or at least setting the rules underlying the ledger then how can I be sure that the ledger is legit?

mwpt

Generali wrote: »

Previous instructions

I enter into a forward contract with you to buy £1,000,000 for AU$2,000,000 for settlement on the next quarter day. That is then entered into the blockchain.

2 days prior to the quarter day I want to enter into a contract to sell £1,000,000 vs AUD in order to close out my position and realise my PnL. I enter my trade and so that becomes a second entry in the blockchain.

Then I want to net 1 vs 2. I don't see how I can do that without either putting a duplicate net entry into the blockchain or erasing the previous entries from the blockchain and replacing them with a new net entry.

The former involves making two claims on one amount of money, the latter involves making changes to the blockchain which is at best difficult AIUI. In the latter case, how can I show that I am cancelling two entries into the blockchain that involve the same parties? I could be fraudulently be cancelling someone else's entry.

Ok that is a little clearer but I'm afraid that there are still a lot of open questions in what you're asking. These future contracts are not real transfers, they only materialise at a future date, so traditional blockchain doesn't handle that. Algorithms can be made to accomplish almost anything (except a general solution for the halting problem) so it could and maybe has been done, to have varying types blockchain transactions, such as futures and immediates, and so forth.

Blockchain has a lot of hype because it is a really interesting technology but things like this become overhyped and people try to force them to solve problems they may not be suitable for.

But if we really wanted to try and force blockchain to solve your problem here is what we might do:

Regular non netted chain
Time 1: Entry for forward contract A recorded in ledger - type is a promise entry, not a real transfer
..
..
Time 2: Settlement point for contract A - Entry (2) into ledger recording settlement - type is real transfer

Netted settlement chain
Time 1: Entry (1) for forward contract A recorded in ledger - type is a promise entry, not a real transfer
..
..
Time 2: Entry (2) for new immediate execution contract in ledger - references entry (1) and type is recorded as a net against (1). Invalidates any future execution of (1)
Time 2: Entry (3) in the ledger for difference of (1) and (2) - type is a real transfer and references entries (1) and (2) for auditing

These last two entries are performed in a single transaction, it either completes and writes to the ledger entirely or does not complete at all and entry (1) is still valid, to be executed at forward date.

I'd have to know a lot more to say whether blockchain is truly helpful for this requirement or not.

Generali

mwpt wrote: »

I'd have to know a lot more to say whether blockchain is truly helpful for this requirement or not.

TBH that's not a specific requirement I have in mind, just a rabbit hole I've gone down.

One of the limits of blockchain I can see is uncertain outcomes, how it can record contingent liabilities.