How can you build a secure, pre-digital distributed ledger?

up vote
5
down vote

favorite

A distributed ledger is a 'database' without a central administrator or central storage. Instead, each copy of the database replicates and saves an identical copy of the data and updates itself independently. A distributed ledger must:

Have a mechanism for pushing updates from one node to all nodes

Have a mechanism for ensuring that the only remote updates it accepts are 'encrypted' or 'secured' somehow

When there is a time delay between ledger updates, there must be a mechanism for determining a consensus 'correct' ledger status between ledgers

These mechanisms must be driven algorithmically, not by human subjective thinking.

The inspiration for this question is the book The House of Rothschild about he spread of the Rothschild banking empire in the first half of the 19th century. The five Rothschild brothers each opened a 'branch' of the family bank in London, Paris, Vienna, Naples, and Frankfurt.

However, in real life, political tensions quickly pulled the banks apart into separate entities. But, what if the family tried to keep the bank together. Perhaps with some algorithmic way to distribute and verify transactions, they could have maintained one banking entity up until the digital age?

How could a multi-national bank implement a distributed ledger to track its operations across an area the size of Western Europe?

The technology period for implementing this ledge could be anywhere from 1850-1950. For the sake of this question, ignore the political issues facing a multinational bank and focuses on the technology. Assume this takes place on an alternate-Earth where there are no World Wars or Protocols of the Elders of Zion.

edited yesterday

asked yesterday

kingledion

70.3k24235408

1

The title ask "can ...?", the text ask "how..?" Which of the two is it?
– L.Dutch♦
yesterday

Does the Hawala network qualify?
– Ash
yesterday

I'm afraid that you need to specify the required functionality of the distributed ledger. As the question stands now it can be answered simply that yes, obviously, a distributed ledger can be maintained with ink, quills and paper: all the bank needs to do is to post a diligent and incorruptible clerk at each branch office, tasked with sending and receiving copies of the ledger. (And this apparently simplistic method was actually used successfully in the from the 16th century onwards by banks with offices in multiple countries.)
– AlexP
yesterday

I'm not sure they do they way you mean, I'm making a research suggestion not attempting to answer the question, this is the comments section.
– Ash
yesterday

1

"Have a mechanism for pushing updates from one node to all nodes": what's wrong with the postal system or couriers? "Have a mechanism for ensuring that the only remote updates it accepts are 'encrypted' or 'secured' somehow": signatures and stamps worked just fine for this purpose. "When there is a time delay between ledger updates, there must be a mechanism for determining a consensus 'correct' ledger status between ledgers:" the central office sends periodically the true ledger as of the 1st day of the previous month. Again, this has actually been done in this way for centuries.
– AlexP
yesterday

|
show 9 more comments

up vote
5
down vote

favorite

Have a mechanism for pushing updates from one node to all nodes

Have a mechanism for ensuring that the only remote updates it accepts are 'encrypted' or 'secured' somehow

When there is a time delay between ledger updates, there must be a mechanism for determining a consensus 'correct' ledger status between ledgers

These mechanisms must be driven algorithmically, not by human subjective thinking.

How could a multi-national bank implement a distributed ledger to track its operations across an area the size of Western Europe?

edited yesterday

asked yesterday

kingledion

70.3k24235408

1

The title ask "can ...?", the text ask "how..?" Which of the two is it?
– L.Dutch♦
yesterday

Does the Hawala network qualify?
– Ash
yesterday

I'm afraid that you need to specify the required functionality of the distributed ledger. As the question stands now it can be answered simply that yes, obviously, a distributed ledger can be maintained with ink, quills and paper: all the bank needs to do is to post a diligent and incorruptible clerk at each branch office, tasked with sending and receiving copies of the ledger. (And this apparently simplistic method was actually used successfully in the from the 16th century onwards by banks with offices in multiple countries.)
– AlexP
yesterday

I'm not sure they do they way you mean, I'm making a research suggestion not attempting to answer the question, this is the comments section.
– Ash
yesterday

1

"Have a mechanism for pushing updates from one node to all nodes": what's wrong with the postal system or couriers? "Have a mechanism for ensuring that the only remote updates it accepts are 'encrypted' or 'secured' somehow": signatures and stamps worked just fine for this purpose. "When there is a time delay between ledger updates, there must be a mechanism for determining a consensus 'correct' ledger status between ledgers:" the central office sends periodically the true ledger as of the 1st day of the previous month. Again, this has actually been done in this way for centuries.
– AlexP
yesterday

|
show 9 more comments

up vote
5
down vote

favorite

Have a mechanism for pushing updates from one node to all nodes

Have a mechanism for ensuring that the only remote updates it accepts are 'encrypted' or 'secured' somehow

When there is a time delay between ledger updates, there must be a mechanism for determining a consensus 'correct' ledger status between ledgers

These mechanisms must be driven algorithmically, not by human subjective thinking.

How could a multi-national bank implement a distributed ledger to track its operations across an area the size of Western Europe?

edited yesterday

asked yesterday

kingledion

70.3k24235408

Have a mechanism for pushing updates from one node to all nodes

Have a mechanism for ensuring that the only remote updates it accepts are 'encrypted' or 'secured' somehow

When there is a time delay between ledger updates, there must be a mechanism for determining a consensus 'correct' ledger status between ledgers

These mechanisms must be driven algorithmically, not by human subjective thinking.

How could a multi-national bank implement a distributed ledger to track its operations across an area the size of Western Europe?

technology economy industrial-age

edited yesterday

asked yesterday

kingledion

70.3k24235408

edited yesterday

asked yesterday

kingledion

70.3k24235408

edited yesterday

asked yesterday

kingledion

70.3k24235408

asked yesterday

kingledion

70.3k24235408

asked yesterday

kingledion

70.3k24235408

1

The title ask "can ...?", the text ask "how..?" Which of the two is it?
– L.Dutch♦
yesterday

Does the Hawala network qualify?
– Ash
yesterday

I'm afraid that you need to specify the required functionality of the distributed ledger. As the question stands now it can be answered simply that yes, obviously, a distributed ledger can be maintained with ink, quills and paper: all the bank needs to do is to post a diligent and incorruptible clerk at each branch office, tasked with sending and receiving copies of the ledger. (And this apparently simplistic method was actually used successfully in the from the 16th century onwards by banks with offices in multiple countries.)
– AlexP
yesterday

I'm not sure they do they way you mean, I'm making a research suggestion not attempting to answer the question, this is the comments section.
– Ash
yesterday

1

"Have a mechanism for pushing updates from one node to all nodes": what's wrong with the postal system or couriers? "Have a mechanism for ensuring that the only remote updates it accepts are 'encrypted' or 'secured' somehow": signatures and stamps worked just fine for this purpose. "When there is a time delay between ledger updates, there must be a mechanism for determining a consensus 'correct' ledger status between ledgers:" the central office sends periodically the true ledger as of the 1st day of the previous month. Again, this has actually been done in this way for centuries.
– AlexP
yesterday

|
show 9 more comments

1

The title ask "can ...?", the text ask "how..?" Which of the two is it?
– L.Dutch♦
yesterday

Does the Hawala network qualify?
– Ash
yesterday

I'm afraid that you need to specify the required functionality of the distributed ledger. As the question stands now it can be answered simply that yes, obviously, a distributed ledger can be maintained with ink, quills and paper: all the bank needs to do is to post a diligent and incorruptible clerk at each branch office, tasked with sending and receiving copies of the ledger. (And this apparently simplistic method was actually used successfully in the from the 16th century onwards by banks with offices in multiple countries.)
– AlexP
yesterday

I'm not sure they do they way you mean, I'm making a research suggestion not attempting to answer the question, this is the comments section.
– Ash
yesterday

1

"Have a mechanism for pushing updates from one node to all nodes": what's wrong with the postal system or couriers? "Have a mechanism for ensuring that the only remote updates it accepts are 'encrypted' or 'secured' somehow": signatures and stamps worked just fine for this purpose. "When there is a time delay between ledger updates, there must be a mechanism for determining a consensus 'correct' ledger status between ledgers:" the central office sends periodically the true ledger as of the 1st day of the previous month. Again, this has actually been done in this way for centuries.
– AlexP
yesterday

The title ask "can ...?", the text ask "how..?" Which of the two is it?
– L.Dutch♦
yesterday

Does the Hawala network qualify?
– Ash
yesterday

I'm afraid that you need to specify the required functionality of the distributed ledger. As the question stands now it can be answered simply that yes, obviously, a distributed ledger can be maintained with ink, quills and paper: all the bank needs to do is to post a diligent and incorruptible clerk at each branch office, tasked with sending and receiving copies of the ledger. (And this apparently simplistic method was actually used successfully in the from the 16th century onwards by banks with offices in multiple countries.)
– AlexP
yesterday

I'm not sure they do they way you mean, I'm making a research suggestion not attempting to answer the question, this is the comments section.
– Ash
yesterday

"Have a mechanism for pushing updates from one node to all nodes": what's wrong with the postal system or couriers? "Have a mechanism for ensuring that the only remote updates it accepts are 'encrypted' or 'secured' somehow": signatures and stamps worked just fine for this purpose. "When there is a time delay between ledger updates, there must be a mechanism for determining a consensus 'correct' ledger status between ledgers:" the central office sends periodically the true ledger as of the 1st day of the previous month. Again, this has actually been done in this way for centuries.
– AlexP
yesterday

|
show 9 more comments

6 Answers
6

active

oldest

votes

up vote
12
down vote

Trust

Maintaining a distributed ledger is not difficult in general. What is indeed difficult, and the problem the modern blockchain technology attempts to solve, is maintaining a distributed ledger when the nodes do not trust each other.

A bank with several distributed offices did not (and still does not) have the problem of lack of trust. If the central and branch offices of a bank do not trust each other they have much bigger problems than maintaining a correct distributed ledger, because no distributed ledger can guarantee the veracity of the actual transactions, only that the transactions are correctly replicated.

If we can assume that the nodes do trust each other then maintaining a distributed ledger reduces to sending copies of the local transactions to a central node, and updating the local copy when the central node sends the consolidated truth valid at a given date in the past. There will always be a delay between a local transaction and its reflection in the consolidated ledger; but this was deemed perfectly acceptable in a world where people did not expect instant gratification.

"Have a mechanism for pushing updates from one node to all nodes": in a limited geographical area, such as Western Europe, they used couriers. When the technology advanced and the telegraph made possible timely correspondence over longer distances, they used the telegraph. Then TELEX came along and delays became much shorter.

"Have a mechanism for ensuring that the only remote updates it accepts are 'encrypted' or 'secured' somehow": signatures and stamps worked just fine for this purpose, as long as the central and branch offices trust each other.

"When there is a time delay between ledger updates, there must be a mechanism for determining a consensus 'correct' ledger status between ledgers:" the central office consolidates and sends out periodically the true ledger as of the 1st day of the previous month.

In practice, banks solved the problem of delays by setting limits on the transactions which could be made without confirmation from the central office.

This left only the problem of securing the communications in transit; trusted couriers served fine for a limited area, and various codebooks and ciphers for longer distances. For example, the famous Enigma machine was initially developed and marketed as a means of securing commercial messages sent by telegraph.

P.S. Remember that before the first world war they actually had to move large quantities of physical precious metal between the offices...

edited yesterday

answered yesterday

AlexP

33.8k777128

I've got a comment in questioning this, but I think you've done a great job of showing the difference between how a bank operates and how a distributed currency like bitcoin operates. Trust is everything. If you have trust, it is trivial to distribute. Dutch bookkeeping qualifies. If you have to permit untrusted invididuals to log purchases, that's antoher story.
– Cort Ammon
yesterday

add a comment |

up vote
10
down vote

Maybe once the telegraph comes into use in the 1800s, before that the signal lag will kill you. The Hawala network of money lenders would seem to qualify but it relies on the honour system rather than having any widespread concrete record of transactions. Distributing records in a secure way across the distances involved is doable, the Catholic Church spanned the globe at even lower travel speeds. So you can certainly send out data to update the various individual ledgers along existing trade routes and eventually get all of them updated. Unfortunately eventually means "over the next couple of weeks" from somewhere central and "in the next month or two" if you're talking between border posts. That wouldn't be an issue if you could have your third requirement:

"When there is a time delay between ledger updates, there must be a mechanism for determining a consensus 'correct' ledger status between ledgers"

But in reality the only ledger status that people (by which I mean customers more than necessarily well trained clerks) will take seriously is the one that is in front of them in black and white. This being the case those few weeks of delay needed to cover the whole geographical range of the bank would invariably occasionally end up with the bank holding the bag on large debts, both intentional and accidental, due to unexpected costs or overdue cargoes or outright fraud.

edited yesterday

answered yesterday

Ash

25.9k465144

2

As long as the information could move faster than the people & their distributed interactions with the network, latency would be tolerable.
– theRiley
yesterday

2

@theRiley The problem comes from "near simultaneous" (read inside the latency period) individual transactions at the far edges of the network that interact with each other catastrophically when the totals are finally reviewed.
– Ash
yesterday

1

@theRiley Yup that's what I meant by the bank being left holding the bag on intentional debts, two, or possibly more, parties at the edges of the network deliberately absconding with a balance they have a right to draw on only once.
– Ash
yesterday

3

@Ash: I would note that the issue of fraud can be solved by distributing not only the ledger, but also the money. Think of it as each entity having one account per branch; they should feel free to shuffle their money from one branch-account to another, however each branch-account must maintain a positive balance at any time.
– Matthieu M.
yesterday

1

You could possibly avoid latency-related fraud by requiring withdrawals to post to and be confirmed by all copies of the ledger before releasing the funds (i.e., waiting for the check to clear). Whether or not your customers can tolerate waiting that long to get their money out is a different story...
– bta
yesterday

|
show 4 more comments

up vote
6
down vote

Not exactly - at least not anything akin to modern electronic distributed systems.

You are expecting each branch of the bank to be holding a full copy of the ledgers. When a transaction occurs, a copy of the record of the transaction is sent to each branch, who tentatively applies it to their copy of the ledger, and as an error correcting measure sends back the new total on the account. If every total matches there were no errors in recording the transaction and every branch is informed of the success and has the new total on that account.

This is all done by hand. Copied out by hand, calculated by hand, encrypted by hand, and the paper records sent by courier to each branch where it is again decrypted by hand, the account calculated by hand, the new total generated by hand, the response encrypted by hand, and sent back by courier to the originating branch to decrypt by hand and verify the numbers. If the totals didn't match somewhere (fairly likely due to human error at any one of the many steps by any of the individuals involved at all of the branches), then they do it all again.

This is a slow process of keeping a full copy of everything at every branch. It could take considerable amounts of time to verify information from a different branch and to physically carry the messages between them. This is why in the recent past it could take weeks for transactions to 'clear' - and that is without having the extensive overhead of attempting full copies at all branches but only processing the transactions where money moves between banks.

The cost of attempting to keep a distributed ledger like this would be astounding.
The only reason it is plausible in the modern age is that electronic communications cuts the time to perform each step to practically nothing. Doing it all by hand would be an astounding amount of labor and would necessitate weeks between transactions (sorry - no more banking on this account as it is still processing the last transaction - try again next month).

A far more likely scenario would be one where each branch operates pseudo-independently. When someone needs to make a transaction through a different location than their primary branch messages are sent between branches to tell the other branch to make the money available. Old systems of giving letters of credit or of simply maintaining separate balances at each branch (with transfers between accounts comparatively fast - just an encrypted note to make $X available with confirmation not needed in a timely manner) is far more plausible. Perhaps a policy akin to extending credit at each of the branches, equal to roughly half the known balance, with a rule in place that one can only withdraw half the balance of the account without prior notice so it has time to notify the other branches that you are emptying the account and to not extend you credit. A copy of the total balance on all accounts can be shipped to each branch on a regular basis (monthly), but a fast courier could be used for anything more pressing.

Always keep in mind the timescales required and the manpower of physically processing everything by hand (pen on paper records and maybe an abacus to help with the math).

answered yesterday

pluckedkiwi

3,664925

add a comment |

up vote
0
down vote

It is actually pretty easy.

Every bank writes down their transactions and puts a copy in their filing cabinet. Copies of the day's (or week's) transactions are sent to the other banks by postal mail or messenger and their ledgers are updated to include the data from the other banks.

That is how this was done, and it worked. People used to accommodate for the time delay in data transmission in the same way that modern computer networks have to accomodate for the time delay when data is sent around the planet or over a satellite relay, though on a scale of days or weeks instead of microseconds.

answered yesterday

user57423

1466

New contributor

add a comment |

up vote
0
down vote

So this question is a little self contradictory because you are looking for an algorithic process in an entirely human managed information system. Not to mention even todays systems arent fully automated.

Todays systems rely on low latency communications to algorithmically resolve most discrepencies. However not all discrepencies are resolved, this is where the system raises all kinds of warning bells that humans must then sort out, law enforcement usually comes in here.

Anyways the first 2 requirements are moot. The first is an information relay system which can be mail or telephones. Such systems were fairly abstracted away from any decision making, with obvious human error factoring in. The second is cryptography which has existed long before computers and whose many methods you can google. This too has imperfections but then so does modern solutions which tie back to the opening paragraph.

Now the last one is the real trick because time delays are inevitable in the old systems. This one topic alone has a whole book on banking law, policy, and procedures. I will do my best to sum the broad problems:

Taking advantage of geographical seperation to withdraw money from the same account at 2 different locations. This was common and part of checking fraud depicted in "catch me if you can". This is largely aided by bad policy decisions driven by the marketability of convienece. If banks simply required all promissory notes to be registed in the localities of their issue and refuse to allocate funds until the ledger certified funds then this wouldnt be an issue. Moreover this would resolve overdrafts. It would also deal a huge blow to international transaction speeds capping them to whatever the ledger refresh is.

You know i was going to try and sum this but its way to big. Now i am just going to say your algorithm is based on your banks customers, policy, and geographic laws. Lots of accounting and auditing.

answered yesterday

anon

10.3k1357

add a comment |

up vote
0
down vote

artifical light, heliography & data compression techniques.

security is relative.

a photoreactive substance, light excluding tunnel, signal towers and 'bar codes' could achieve significant data transmission rates, be bidirectional, relatively secure, operated by laymen and make the operators incredibly wealthy by carrying diplomatic and high value correspondence at many times the rate of sea or horse travel.

not to mention that towers don't sink in storms.

of course, then radio patents would of been bought up by the rothschilds and never see the light of day, but we can't have everything. =)

answered yesterday

Giu Piete

111

New contributor

add a comment |

Your Answer

StackExchange.ifUsing("editor", function () {
return StackExchange.using("mathjaxEditing", function () {
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\$","\$"]]);
});
});
}, "mathjax-editing");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "579"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworldbuilding.stackexchange.com%2fquestions%2f130734%2fhow-can-you-build-a-secure-pre-digital-distributed-ledger%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

6 Answers
6

active

oldest

votes

6 Answers
6

active

oldest

votes

up vote
12
down vote

Trust

"Have a mechanism for pushing updates from one node to all nodes": in a limited geographical area, such as Western Europe, they used couriers. When the technology advanced and the telegraph made possible timely correspondence over longer distances, they used the telegraph. Then TELEX came along and delays became much shorter.

"Have a mechanism for ensuring that the only remote updates it accepts are 'encrypted' or 'secured' somehow": signatures and stamps worked just fine for this purpose, as long as the central and branch offices trust each other.

"When there is a time delay between ledger updates, there must be a mechanism for determining a consensus 'correct' ledger status between ledgers:" the central office consolidates and sends out periodically the true ledger as of the 1st day of the previous month.

In practice, banks solved the problem of delays by setting limits on the transactions which could be made without confirmation from the central office.

P.S. Remember that before the first world war they actually had to move large quantities of physical precious metal between the offices...

edited yesterday

answered yesterday

AlexP

33.8k777128

I've got a comment in questioning this, but I think you've done a great job of showing the difference between how a bank operates and how a distributed currency like bitcoin operates. Trust is everything. If you have trust, it is trivial to distribute. Dutch bookkeeping qualifies. If you have to permit untrusted invididuals to log purchases, that's antoher story.
– Cort Ammon
yesterday

add a comment |

up vote
12
down vote

Trust

"Have a mechanism for pushing updates from one node to all nodes": in a limited geographical area, such as Western Europe, they used couriers. When the technology advanced and the telegraph made possible timely correspondence over longer distances, they used the telegraph. Then TELEX came along and delays became much shorter.

"Have a mechanism for ensuring that the only remote updates it accepts are 'encrypted' or 'secured' somehow": signatures and stamps worked just fine for this purpose, as long as the central and branch offices trust each other.

"When there is a time delay between ledger updates, there must be a mechanism for determining a consensus 'correct' ledger status between ledgers:" the central office consolidates and sends out periodically the true ledger as of the 1st day of the previous month.

In practice, banks solved the problem of delays by setting limits on the transactions which could be made without confirmation from the central office.

P.S. Remember that before the first world war they actually had to move large quantities of physical precious metal between the offices...

edited yesterday

answered yesterday

AlexP

33.8k777128

I've got a comment in questioning this, but I think you've done a great job of showing the difference between how a bank operates and how a distributed currency like bitcoin operates. Trust is everything. If you have trust, it is trivial to distribute. Dutch bookkeeping qualifies. If you have to permit untrusted invididuals to log purchases, that's antoher story.
– Cort Ammon
yesterday

add a comment |

up vote
12
down vote

Trust

"Have a mechanism for pushing updates from one node to all nodes": in a limited geographical area, such as Western Europe, they used couriers. When the technology advanced and the telegraph made possible timely correspondence over longer distances, they used the telegraph. Then TELEX came along and delays became much shorter.

"Have a mechanism for ensuring that the only remote updates it accepts are 'encrypted' or 'secured' somehow": signatures and stamps worked just fine for this purpose, as long as the central and branch offices trust each other.

"When there is a time delay between ledger updates, there must be a mechanism for determining a consensus 'correct' ledger status between ledgers:" the central office consolidates and sends out periodically the true ledger as of the 1st day of the previous month.

In practice, banks solved the problem of delays by setting limits on the transactions which could be made without confirmation from the central office.

P.S. Remember that before the first world war they actually had to move large quantities of physical precious metal between the offices...

edited yesterday

answered yesterday

AlexP

33.8k777128

Trust

"Have a mechanism for pushing updates from one node to all nodes": in a limited geographical area, such as Western Europe, they used couriers. When the technology advanced and the telegraph made possible timely correspondence over longer distances, they used the telegraph. Then TELEX came along and delays became much shorter.

"Have a mechanism for ensuring that the only remote updates it accepts are 'encrypted' or 'secured' somehow": signatures and stamps worked just fine for this purpose, as long as the central and branch offices trust each other.

"When there is a time delay between ledger updates, there must be a mechanism for determining a consensus 'correct' ledger status between ledgers:" the central office consolidates and sends out periodically the true ledger as of the 1st day of the previous month.

In practice, banks solved the problem of delays by setting limits on the transactions which could be made without confirmation from the central office.

P.S. Remember that before the first world war they actually had to move large quantities of physical precious metal between the offices...

edited yesterday

answered yesterday

AlexP

33.8k777128

edited yesterday

answered yesterday

AlexP

33.8k777128

answered yesterday

AlexP

33.8k777128

answered yesterday

AlexP

33.8k777128

I've got a comment in questioning this, but I think you've done a great job of showing the difference between how a bank operates and how a distributed currency like bitcoin operates. Trust is everything. If you have trust, it is trivial to distribute. Dutch bookkeeping qualifies. If you have to permit untrusted invididuals to log purchases, that's antoher story.
– Cort Ammon
yesterday

add a comment |

I've got a comment in questioning this, but I think you've done a great job of showing the difference between how a bank operates and how a distributed currency like bitcoin operates. Trust is everything. If you have trust, it is trivial to distribute. Dutch bookkeeping qualifies. If you have to permit untrusted invididuals to log purchases, that's antoher story.
– Cort Ammon
yesterday

I've got a comment in questioning this, but I think you've done a great job of showing the difference between how a bank operates and how a distributed currency like bitcoin operates. Trust is everything. If you have trust, it is trivial to distribute. Dutch bookkeeping qualifies. If you have to permit untrusted invididuals to log purchases, that's antoher story.
– Cort Ammon
yesterday

add a comment |

up vote
10
down vote

"When there is a time delay between ledger updates, there must be a mechanism for determining a consensus 'correct' ledger status between ledgers"

edited yesterday

answered yesterday

Ash

25.9k465144

2

As long as the information could move faster than the people & their distributed interactions with the network, latency would be tolerable.
– theRiley
yesterday

2

@theRiley The problem comes from "near simultaneous" (read inside the latency period) individual transactions at the far edges of the network that interact with each other catastrophically when the totals are finally reviewed.
– Ash
yesterday

1

@theRiley Yup that's what I meant by the bank being left holding the bag on intentional debts, two, or possibly more, parties at the edges of the network deliberately absconding with a balance they have a right to draw on only once.
– Ash
yesterday

3

@Ash: I would note that the issue of fraud can be solved by distributing not only the ledger, but also the money. Think of it as each entity having one account per branch; they should feel free to shuffle their money from one branch-account to another, however each branch-account must maintain a positive balance at any time.
– Matthieu M.
yesterday

1

You could possibly avoid latency-related fraud by requiring withdrawals to post to and be confirmed by all copies of the ledger before releasing the funds (i.e., waiting for the check to clear). Whether or not your customers can tolerate waiting that long to get their money out is a different story...
– bta
yesterday

|
show 4 more comments

up vote
10
down vote

"When there is a time delay between ledger updates, there must be a mechanism for determining a consensus 'correct' ledger status between ledgers"

edited yesterday

answered yesterday

Ash

25.9k465144

2

As long as the information could move faster than the people & their distributed interactions with the network, latency would be tolerable.
– theRiley
yesterday

2

@theRiley The problem comes from "near simultaneous" (read inside the latency period) individual transactions at the far edges of the network that interact with each other catastrophically when the totals are finally reviewed.
– Ash
yesterday

1

@theRiley Yup that's what I meant by the bank being left holding the bag on intentional debts, two, or possibly more, parties at the edges of the network deliberately absconding with a balance they have a right to draw on only once.
– Ash
yesterday

3

@Ash: I would note that the issue of fraud can be solved by distributing not only the ledger, but also the money. Think of it as each entity having one account per branch; they should feel free to shuffle their money from one branch-account to another, however each branch-account must maintain a positive balance at any time.
– Matthieu M.
yesterday

1

You could possibly avoid latency-related fraud by requiring withdrawals to post to and be confirmed by all copies of the ledger before releasing the funds (i.e., waiting for the check to clear). Whether or not your customers can tolerate waiting that long to get their money out is a different story...
– bta
yesterday

|
show 4 more comments

up vote
10
down vote

"When there is a time delay between ledger updates, there must be a mechanism for determining a consensus 'correct' ledger status between ledgers"

edited yesterday

answered yesterday

Ash

25.9k465144

"When there is a time delay between ledger updates, there must be a mechanism for determining a consensus 'correct' ledger status between ledgers"

edited yesterday

answered yesterday

Ash

25.9k465144

edited yesterday

answered yesterday

Ash

25.9k465144

answered yesterday

Ash

25.9k465144

answered yesterday

Ash

25.9k465144

2

As long as the information could move faster than the people & their distributed interactions with the network, latency would be tolerable.
– theRiley
yesterday

2

@theRiley The problem comes from "near simultaneous" (read inside the latency period) individual transactions at the far edges of the network that interact with each other catastrophically when the totals are finally reviewed.
– Ash
yesterday

1

@theRiley Yup that's what I meant by the bank being left holding the bag on intentional debts, two, or possibly more, parties at the edges of the network deliberately absconding with a balance they have a right to draw on only once.
– Ash
yesterday

3

@Ash: I would note that the issue of fraud can be solved by distributing not only the ledger, but also the money. Think of it as each entity having one account per branch; they should feel free to shuffle their money from one branch-account to another, however each branch-account must maintain a positive balance at any time.
– Matthieu M.
yesterday

1

You could possibly avoid latency-related fraud by requiring withdrawals to post to and be confirmed by all copies of the ledger before releasing the funds (i.e., waiting for the check to clear). Whether or not your customers can tolerate waiting that long to get their money out is a different story...
– bta
yesterday

|
show 4 more comments

2

As long as the information could move faster than the people & their distributed interactions with the network, latency would be tolerable.
– theRiley
yesterday

2

@theRiley The problem comes from "near simultaneous" (read inside the latency period) individual transactions at the far edges of the network that interact with each other catastrophically when the totals are finally reviewed.
– Ash
yesterday

1

@theRiley Yup that's what I meant by the bank being left holding the bag on intentional debts, two, or possibly more, parties at the edges of the network deliberately absconding with a balance they have a right to draw on only once.
– Ash
yesterday

3

@Ash: I would note that the issue of fraud can be solved by distributing not only the ledger, but also the money. Think of it as each entity having one account per branch; they should feel free to shuffle their money from one branch-account to another, however each branch-account must maintain a positive balance at any time.
– Matthieu M.
yesterday

1

You could possibly avoid latency-related fraud by requiring withdrawals to post to and be confirmed by all copies of the ledger before releasing the funds (i.e., waiting for the check to clear). Whether or not your customers can tolerate waiting that long to get their money out is a different story...
– bta
yesterday

As long as the information could move faster than the people & their distributed interactions with the network, latency would be tolerable.
– theRiley
yesterday

@theRiley The problem comes from "near simultaneous" (read inside the latency period) individual transactions at the far edges of the network that interact with each other catastrophically when the totals are finally reviewed.
– Ash
yesterday

@theRiley Yup that's what I meant by the bank being left holding the bag on intentional debts, two, or possibly more, parties at the edges of the network deliberately absconding with a balance they have a right to draw on only once.
– Ash
yesterday

@Ash: I would note that the issue of fraud can be solved by distributing not only the ledger, but also the money. Think of it as each entity having one account per branch; they should feel free to shuffle their money from one branch-account to another, however each branch-account must maintain a positive balance at any time.
– Matthieu M.
yesterday

You could possibly avoid latency-related fraud by requiring withdrawals to post to and be confirmed by all copies of the ledger before releasing the funds (i.e., waiting for the check to clear). Whether or not your customers can tolerate waiting that long to get their money out is a different story...
– bta
yesterday

|
show 4 more comments

up vote
6
down vote

Not exactly - at least not anything akin to modern electronic distributed systems.

Always keep in mind the timescales required and the manpower of physically processing everything by hand (pen on paper records and maybe an abacus to help with the math).

answered yesterday

pluckedkiwi

3,664925

add a comment |

up vote
6
down vote

Not exactly - at least not anything akin to modern electronic distributed systems.

Always keep in mind the timescales required and the manpower of physically processing everything by hand (pen on paper records and maybe an abacus to help with the math).

answered yesterday

pluckedkiwi

3,664925

add a comment |

up vote
6
down vote

Not exactly - at least not anything akin to modern electronic distributed systems.

Always keep in mind the timescales required and the manpower of physically processing everything by hand (pen on paper records and maybe an abacus to help with the math).

answered yesterday

pluckedkiwi

3,664925

Not exactly - at least not anything akin to modern electronic distributed systems.

Always keep in mind the timescales required and the manpower of physically processing everything by hand (pen on paper records and maybe an abacus to help with the math).

answered yesterday

pluckedkiwi

3,664925

answered yesterday

pluckedkiwi

3,664925

answered yesterday

pluckedkiwi

3,664925

answered yesterday

pluckedkiwi

3,664925

add a comment |

up vote
0
down vote

It is actually pretty easy.

answered yesterday

user57423

1466

New contributor

add a comment |

up vote
0
down vote

It is actually pretty easy.

answered yesterday

user57423

1466

New contributor

add a comment |

up vote
0
down vote

It is actually pretty easy.

answered yesterday

user57423

1466

New contributor

It is actually pretty easy.

answered yesterday

user57423

1466

New contributor

answered yesterday

user57423

1466

New contributor

answered yesterday

user57423

1466

answered yesterday

user57423

1466

New contributor

user57423 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

add a comment |

up vote
0
down vote

You know i was going to try and sum this but its way to big. Now i am just going to say your algorithm is based on your banks customers, policy, and geographic laws. Lots of accounting and auditing.

answered yesterday

anon

10.3k1357

add a comment |

up vote
0
down vote

You know i was going to try and sum this but its way to big. Now i am just going to say your algorithm is based on your banks customers, policy, and geographic laws. Lots of accounting and auditing.

answered yesterday

anon

10.3k1357

add a comment |

up vote
0
down vote

You know i was going to try and sum this but its way to big. Now i am just going to say your algorithm is based on your banks customers, policy, and geographic laws. Lots of accounting and auditing.

answered yesterday

anon

10.3k1357

You know i was going to try and sum this but its way to big. Now i am just going to say your algorithm is based on your banks customers, policy, and geographic laws. Lots of accounting and auditing.

answered yesterday

anon

10.3k1357

answered yesterday

anon

10.3k1357

answered yesterday

anon

10.3k1357

answered yesterday

anon

10.3k1357

add a comment |

up vote
0
down vote

artifical light, heliography & data compression techniques.

security is relative.

not to mention that towers don't sink in storms.

of course, then radio patents would of been bought up by the rothschilds and never see the light of day, but we can't have everything. =)

answered yesterday

Giu Piete

111

New contributor

add a comment |

up vote
0
down vote

artifical light, heliography & data compression techniques.

security is relative.

not to mention that towers don't sink in storms.

of course, then radio patents would of been bought up by the rothschilds and never see the light of day, but we can't have everything. =)

answered yesterday

Giu Piete

111

New contributor

add a comment |

up vote
0
down vote

artifical light, heliography & data compression techniques.

security is relative.

not to mention that towers don't sink in storms.

of course, then radio patents would of been bought up by the rothschilds and never see the light of day, but we can't have everything. =)

answered yesterday

Giu Piete

111

New contributor

artifical light, heliography & data compression techniques.

security is relative.

not to mention that towers don't sink in storms.

of course, then radio patents would of been bought up by the rothschilds and never see the light of day, but we can't have everything. =)

answered yesterday

Giu Piete

111

New contributor

answered yesterday

Giu Piete

111

New contributor

answered yesterday

Giu Piete

111

answered yesterday

Giu Piete

111

New contributor

Giu Piete is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

add a comment |

draft saved

draft discarded

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

Search This Blog

Ufyukyu