Distributed Ledger Block Chain and traditional ACID

[Richard Maher]

Not strictly VMS but I was reading this: -
https://www.perthnow.com.au/business/markets/asx-operator-plans-bitcoin-inspired-tech-ng-s-1806851

and I realized I have no idea how it works. Anyone got a simple guide
explanation?

I am a huge fan of DECdtm and TIP and Rdb, Oracle etc but how can DLT work?

No Atomicity
No Consistency
No Isolation
Ok Durability

Surely it's possible to see a $100 transfer half reflected in only one
account?

[Kerry Main]

I think this extract from the article sums up the value of this strategy:
"It means you can trust in technology rather than trusting in organisations."

Now that is a very scary statement.

To your questions, I would also add In the what if scenario where one site is up and running but loses network connectivity to one or all of the other sites. The age old "split brain" scenario.

Or in more simple terms to your point about atomicity - if an update succeeds at one site, succeeds at 2 second site, but fails at third site (HW issue)?

Imho, those in zero RPO scenario's who how fail to learn the age old lessons of ACID are eventually going to be burned.

Note - recent article I read stated a new distributed DB term I had never heard before - "eventual consistency"

😊


Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[Richard Maher]

On 08-Dec-17 10:17 AM, Kerry Main wrote:
>> -----Original Message----- From: Info-vax
>> [mailto:info-vax...@rbnsn.com] On Behalf Of Richard Maher via
>> Info-vax Sent: December 7, 2017 8:51 PM To: info...@rbnsn.com Cc:
>> Richard Maher <maher_rj...@hotmail.com> Subject: [Info-vax]
>> Distributed Ledger Block Chain and traditional ACID
>>
>> Not strictly VMS but I was reading this: -
>> https://www.perthnow.com.au/business/markets/asx-operator-plans-
>> bitcoin-inspired-tech-ng-s-1806851
>>
>> and I realized I have no idea how it works. Anyone got a simple
>> guide explanation?
>>
>> I am a huge fan of DECdtm and TIP and Rdb, Oracle etc but how can
>> DLT work?
>>
>> No Atomicity No Consistency No Isolation Ok Durability
>>
>> Surely it's possible to see a $100 transfer half reflected in only
>> one account?
>>
>
> I think this extract from the article sums up the value of this
> strategy: "It means you can trust in technology rather than trusting
> in organisations."
>
> Now that is a very scary statement.

Agreed. Who is the source(s) of truth? No right of veto???

What the hell do these "miners" do?

>
> To your questions, I would also add In the what if scenario where one
> site is up and running but loses network connectivity to one or all
> of the other sites. The age old "split brain" scenario.

Well without Isolation no one seems to care about locking anything?

>
> Or in more simple terms to your point about atomicity - if an update
> succeeds at one site, succeeds at 2 second site, but fails at third
> site (HW issue)?
>
> Imho, those in zero RPO scenario's who how fail to learn the age old
> lessons of ACID are eventually going to be burned.
>
> Note - recent article I read stated a new distributed DB term I had
> never heard before - "eventual consistency"
>
> 😊
>

Ah yes, half-pregnant.

[Paul Sture]

On 2017-12-08, Kerry Main <kemain...@gmail.com> wrote:
>
> Note - recent article I read stated a new distributed DB term I had
> never heard before - "eventual consistency"
>

Eventual consistency has been around for quite a while. Look for
discussions involving NoSQL, eventual consistency and the CAP Theorem.

I first came across it in the context of CouchDB and mobile devices
which needed to be synced with another database once back at base
(though nowadays "back at base" might mean "found an internet access
point").

--
Everybody has a testing environment. Some people are lucky enough to
have a totally separate environment to run production in.

[phow...@gmail.com]

The same ASX that featured in this youtube ?
https://www.youtube.com/watch?v=DNeVZkf-s6A
and still mentions vms in position descriptions ?
http://www.asx.com.au/documents/careers/ServerSpecialistSept2017.pdf
The Australian on Friday has an article by David Swan in the business section
titled Blockchain technology: an explainer - The Australian
but I don't have a subscription so can't show you more.
Phil

[Richard Maher]

On 09-Dec-17 9:51 AM, phow...@gmail.com wrote:
> but I don't have a subscription so can't show you more.

Spewin' :-(

[IanD]

I'm spewing, I had a detailed reply typed up and it got lost

The blockchain ate my post?

For those wanting a simple explanation of the blockchain, how it works, take the time to watch this simple demo

https://youtu.be/_160oMzblY8

The latter part shows how distributed consensus wins the day when different lines compute the hashing lines

This would have to be one of the simplest, most straight forward, easy to understand explanations of the blockchain I have ever seen

[Richard Maher]

Really, really useful. Thanks.

Not sure how you discover who has a copy of a block chain and does the
search for truth in his "democracy" stop once you have just two matching
final hashes but I get the idea.

Who creates a block chain? Residual Coinbase?

[Stephen Hoffman]

On 2017-12-15 05:48:22 +0000, IanD said:

> For those wanting a simple explanation of the blockchain, how it works...

https://hackernoon.com/learn-blockchains-by-building-one-117428612f46
https://freedom-to-tinker.com/2017/08/17/when-the-cookie-meets-the-blockchain/
https://github.com/openblockchains/awesome-blockchains
https://medium.com/@lhartikk/a-blockchain-in-200-lines-of-code-963cc1cc0e54

Blockchain performance is comparatively poor against other sorts of
common centralized and distributed databases. Distributed consensus is
a comparatively expensive operation. What most easily makes blockchain
transactions process faster is to consolidate or to centralize the
blockchain and to move to larger blocks, too.
https://medium.com/@preethikasireddy/fundamental-challenges-with-public-blockchains-253c800e9428

https://hackernoon.com/dont-use-a-blockchain-unless-you-need-to-bc063d0f9a80

For those looking at security around blockchains and particularly
around security and breaches involving cryptocurrencies...
https://magoo.github.io/Blockchain-Graveyard/

For those looking at some of the applications:
https://github.com/storj

While distributed ledgers are interesting and there are certainly a
number of interesting existing and new applications of the algorithms,
there's also more than a little hype. And legal and regulatory systems
will undoubtedly catch up with at least some of the hype around and
some of the uses of cryptocurrencies, too.




--
Pure Personal Opinion | HoffmanLabs LLC

[IanD]

I'm no expert at all, far from it

I believe it's referred to as probabilistic consensus?

The more hashed chains, the greater the confidence

From what I remember seeing, at 6 hashed blocks, it's deemed almost impossible that your transaction is not 'committed'

I have no idea nor do I have the mathematical knowledge to know this for myself. I'm just following what I have read :-(

The transaction rates for blockchain is quite slow. Too slow for large scale DB's for example. There is work going on to try and improve this but there's a fair amount of squabbling going on in the blockchain camp over it

As to your other questions, I'm glad you asked because I didn't actually know and I had to go and find out for myself :-)

I found this which is a brief and covers most of what you asked

https://www.multichain.com/developers/creating-connecting/

While the future might be blockchain, there's performance issues starting to cause people to look into optimisation and other avenues

For bitcoin, there are some serious questions (beyond the bubble talk) around the total cost of electricity needed to mine the coins in the future. At some point, there will be no further coins created, so who will bother mining because there will be no reward of part bitcoin for doing so

Here's something I found in my searching around that I found extremely interesting. There's a lot of talk starting to grow about this as a possible way forward beyond blockchain or at least, how blockchain is transacted

The new system apparently solves the byzantine generals problem too!

https://hashgraph.com/

https://en.wikipedia.org/wiki/Byzantine_fault_tolerance

They claim transaction rates of 300K per second. It's a private blockchain though and there are 3 software patents on it.

OpenVMS Clusters could use this :-)

[Neil Rieck]

As I understand it, the block-chain is an internet resource shared by all the computers involved in supporting, then verifying, cryptocurrency transactions. A block of transactions appears to them to be not much different than a very large encrypted certificate (hard to fiddle with in real time). A group of computers need to agree that each transaction is legitimate, and the action of individual computers supporting this activity is given the inaccurate label of "mining". The reward for supporting this financial activity is that "one of the computers" involved will be rewarded one BITCOIN. The winning computer cannot just declare itself so, it needs to negotiate this transaction with other computers who are currently verifying the block chain.

Comment: some people have likened cryptocurrency transaction verification to the solving of the "shared secret" puzzle which occurs at the start of diffie-hellman key exchange ( https://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange ) except that DH occurs between two computers and MINING occurs between many. IMHO this example should only be thought of as a metaphor.

But there are problems. For example, Western Union might process 750 traditional financial transfers per second between trusted financials hosts but BITCOIN was built with a "no trust" philosophy so each transaction today (2017-12-28) might require 10 minutes. On top of that, verifying a single BITCOIN transaction requires many multiple computers which requires lots of electrical energy.

This makes prospective miners look at how much energy is required to mine one BITCOIN. I saw an article online in September claiming that the number was 275-kwh per BITCOIN. Not sure if this is for CPU-only miners because many have switched over to graphic cards which can increase throughput by 1000 times while reducing electrical energy (by not 1000 times)

An alternate cryptocurrency called Ethereum was designed with "some builtin trust". This is done by putting some money (say $500) in an escrow account which you would loose if you were caught doing something fraudulent on their network. Some people worry that big banks may get involved and that bigger escrow accounts (say $5 million) would make them more trustworthy thus crowding out the little guys.

Okay, now there are so many people involved in this activity that it is almost impossible to mine a BITCOIN. So many small fry are joining consortium where if anyone in your group mines a BITCOIN then all the members would share it. This activity is also run through the block-chain to ensure honesty.

Anyone considering this activity should read these articles:

https://spectrum.ieee.org/energy/policy/the-ridiculous-amount-of-energy-it-takes-to-run-bitcoin

https://spectrum.ieee.org/computing/networks/why-the-biggest-bitcoin-mines-are-in-china

https://powercompare.co.uk/bitcoin/

Neil Rieck
Waterloo, Ontario, Canada.
http://neilrieck.net

[Stephen Hoffman]

On 2017-12-28 13:16:12 +0000, IanD said:

> Here's something I found in my searching around that I found extremely
> interesting. There's a lot of talk starting to grow about this as a
> possible way forward beyond blockchain or at least, how blockchain is
> transacted

> ...

AFAICR, all of what's been proposed around blockchains is all app-level
and outside of traditional clustering, maybe involving DECdtm. OpenVMS
itself doesn't use DECdtm. The key transaction in a cluster — the
cluster state transition — routinely requires more than a few seconds,
and I don't particularly see how a blockchain really helps with any of
that. Not short of radically rearchitecting how a cluster works, and
that's headed toward reimplementing Hadoop, and related pieces such as
Zookeeper. And the app rework and updates that an
eventual-consistency clustering and storage environment would almost
certainly entail. Few folks support NFSv4.1/NFSv4.2 and its locking,
either. Reducing the cluster transition time is nice, but it's not
now and never will be a headline feature. VSI has mentioned Hadoop as
being a potential future work item to be named later. The majority of
the OpenVMS cluster activities run at the speed of the I/O stack, and —
outside of potential usage of DECdtm, and the socket API usage —
doesn't particularly involve OpenVMS components.

VSI has a shedload of work ahead with what needs to be done beyond the
port and better supporting hosted installs and re-installations and
remote management (e.g. "cloud", ssh console out-of-the-box, etc),
getting SMB3 client and server support working, and a whole host of
other fundamental development work on the tools and frameworks and the
rest. Leave blockchain support and implementations to the apps that
really need a distributed ledger. Unless there's some really obvious
benefit to blockchain APIs in OpenVMS and one that isn't readily
apparent to me. If there is, haul over an open-source library for the
apps that need a distributed ledger. Marketing OpenVMS as providing
"distributed high-security blockchain clustering" is just going to
allow somebody to win at buzz-phrase bingo.

https://tonyarcieri.com/on-the-dangers-of-a-blockchain-monoculture

[IanD]

There's a number of benefits using a blockchain

Log / audit files that cannot be tempered with or falsified (Clinton email *cough*) ;-)

I saw some work a while ago on a network protocol that used the blockchain for verification that a packet was authentic (obviously not useful in a large public blockchain but perhaps doeable in VMS cluster that are a closed network shop).
If VMS is going to claim to be the bee's knee's in security then it might want to start to look at making itself one step ahead of the general riff raff.

With a blockchain, you can get each device that deals with the packet to register it's interaction. The recipient can then query the blockchain to ensure the packet passed through only sanctioned equipment/pathways.
Might not be fast enough for general network operations but could be ok for file transfers or email or...(VPN is end to end, it cannot verify that the intermediary isn't copying / capturing packets for later decryption attempts)

Put VMS reference files on a blockchain maybe? In a closed system such as a VMS cluster running a private blockchain, you could distribute a software upgrade and know that it's authentic. The average VMS shop might not be interested but perhaps the military might pay for such a level of security?

Blockchain your network configuration maybe. Each device contributes some characteristic to the hash and the nodes accept or reject any changes. Could be a way to sell extra levels of VMS security? No sneaky injecting additional network devices into an unsuspecting network to spy with

No ones is saying the blockchain is the silver bullet but it does fix a number of trust issues around having to blindly trust a central authority as the store of and authenticator of transactions

The comment I made about using the blockchain for VMS clusters was more pointed at Hashgraph, which does not have any of the performance issues that blockchain does. In fact, it's not blockchain technically

- Hashgraph is being used by some large financial institutions today
- 300K / second transaction rates (Formal performance testing is underway at present to verify this claim)
- Closed network (good for VMS Clusters)
- 1000 node limit (can be expanded is sharding is used)

Having a limitation of 96 nodes (that is the limit now isn't it?) in a VMS cluster might make VMS look antiquated against it's Linux rivals who are claiming 100's of thousands (yes yes yes, I know those Linux clusters are BS but that doesn't matter, it's what the world believes)

Hashgraph technology might be a simple way of licensing a technology that exists today that might help VMS get beyond it's current cluster node limit and do so in a fashion that the VSI folk (no disrespect intended) might never achieve themselves revamping existing VMS clustering code

Hashgraph
https://www.youtube.com/watch?time_continue=33&v=ZrFrXFdRW4k

The video does a good job of explaining why the blockchain has limitations in terms of performance and how Hashgraph can overcome this

On Friday, December 29, 2017 at 1:44:13 AM UTC+11, Neil Rieck wrote:

<snip>

>
> But there are problems. For example, Western Union might process 750 traditional financial transfers per second between trusted financials hosts but BITCOIN was built with a "no trust" philosophy so each transaction today (2017-12-28) might require 10 minutes.

Yes, 10 mins is the set time that is used to allow the miners time to hash and verify. It's a deliberate time. It can be made faster but the confidence levels start to drop (or so my light reading tells me)

> On top of that, verifying a single BITCOIN transaction requires many multiple computers which requires lots of electrical energy.
>
> This makes prospective miners look at how much energy is required to mine one BITCOIN. I saw an article online in September claiming that the number was 275-kwh per BITCOIN. Not sure if this is for CPU-only miners because many have switched over to graphic cards which can increase throughput by 1000 times while reducing electrical energy (by not 1000 times)
>

The amount of energy required is going to be unsustainable - this is an issue that needs to be solved going forward

The puzzle to solve gets harder as more coins are created. I think we are at about 16.7 million coins already

Already large scale mining has moved to countries where electricity is cheap

> An alternate cryptocurrency called Ethereum was designed with "some builtin trust". This is done by putting some money (say $500) in an escrow account which you would loose if you were caught doing something fraudulent on their network. Some people worry that big banks may get involved and that bigger escrow accounts (say $5 million) would make them more trustworthy thus crowding out the little guys.
>

Etherium's fame to claim is the ability to support smart contracts. Timed events (and other triggers too) tied to a transaction that trigger when certain conditions are met. This is my crypto technology of choice. I think it holds great potential

Payment on delivery of a service for example. Adding penalty clauses to a contract that both parties cannot dispute and that trigger automatically when conditions are met. Lawyers should be worried ha ha ha, this has the potential to rid them of a lot of work!

> Okay, now there are so many people involved in this activity that it is almost impossible to mine a BITCOIN. So many small fry are joining consortium where if anyone in your group mines a BITCOIN then all the members would share it. This activity is also run through the block-chain to ensure honesty.
>
> Anyone considering this activity should read these articles:
>
> https://spectrum.ieee.org/energy/policy/the-ridiculous-amount-of-energy-it-takes-to-run-bitcoin
>
> https://spectrum.ieee.org/computing/networks/why-the-biggest-bitcoin-mines-are-in-china
>
> https://powercompare.co.uk/bitcoin/
>
> Neil Rieck
> Waterloo, Ontario, Canada.
> http://neilrieck.net

People are forming mining pools. You can join a pool and together function are a large miner

You can buy ready made hardware that's packed full of gpu's that you can run at home to perform the mining on

Where I live, the cost of electricity is far too high to bother with mining anymore. I think there's a Facebook virus running around that uses the compute power of all those phone users to perform mining on behalf of others

Like all technologies, there's lots of hype but there's a huge amount of potential too

My bet is on Hashgraph long term, although there's a ton of work still being done on the blockchain to speed it up. Let's see how long it takes the open source community to work a free version of Hashgraph

[Stephen Hoffman]

Yeah; I've posted on that. Think about it, though. There's no need
to use a blockchain for that, when embedding a checksum in a log file —
what's variously called hash chaining and linked time-stamping — works
just fine. But given that logging on a compromised system is entirely
suspect (what gets logged, what lots are still present, what gets
deleted, etc), and anybody that needs higher assurance either sends the
logging messages to remote logging servers — whole lot tougher to forge
that traffic, as multiple systems and network security have to be
compromised, and the checksums can be included in the messages should
that be deemed necessary — or uses a local WORM device, or a
combination.

Put another way, how many folks need this level of logging integrity?
Sure. Some will. And how far up (or down) the OpenVMS development
priority list might this requirement be? I'd rather have syslog-ng or
analogous distributed logging support long before having to wade into
setting up and troubleshooting a host-specific distributed ledger
implementation, too. If there are a couple of standards for
distributed ledgers available in a few years — Ethereum or whatever —
maybe look at adding support then?

And this assumes that the distributed ledger logging implementation is
fast enough. Some of the observed cryptocurrency transaction rates
are way below the rates that even smaller systems and smaller apps can
generate logging messages. Hopefully that observed under-performance
is addressed, too.

> I saw some work a while ago on a network protocol that used the
> blockchain for verification that a packet was authentic (obviously not
> useful in a large public blockchain but perhaps doeable in VMS cluster

> that are a closed network shop).If VMS is going to claim to be the

> bee's knee's in security then it might want to start to look at making
> itself one step ahead of the general riff raff.

Could you elaborate on the connection between hash chaining or linked
timestamps or blockchains, and clustering? Because I really don't see
a firm link there; not anything that's at all specific to clustering.

Even positing that it'd be nice to have forensic-grade logging, major
parts of OpenVMS logging and operator communications are unfortunately
largely stuck in the 1970s, more than a little of it is disjoint at
best, and all that'll best be brought forward first. There's a lot of
other work here.

> With a blockchain, you can get each device that deals with the packet
> to register it's interaction. The recipient can then query the
> blockchain to ensure the packet passed through only sanctioned
> equipment/pathways.
> Might not be fast enough for general network operations but could be ok
> for file transfers or email or...(VPN is end to end, it cannot verify
> that the intermediary isn't copying / capturing packets for later
> decryption attempts)
>
> Put VMS reference files on a blockchain maybe? In a closed system such
> as a VMS cluster running a private blockchain, you could distribute a
> software upgrade and know that it's authentic. The average VMS shop
> might not be interested but perhaps the military might pay for such a
> level of security?

I'd much rather have an IDE integrated with the compilers and the
debugger and distantly feature-comparable to Xcode or VS, an SMB3
server and an SMB3 client, integrated and always-present IP networking,
integrated web services, actual LDAP support past password
authentication, a framework that abstracts networking and TLS and
authentication and easing upgrades, a framework that makes it feasible
to design and develop and operate apps in a cluster without rolling
your own everything from first principals, multiple- and cross-cluster
support for job scheduling and process control, support for current
standards among the compilers for the major languages, modern patch
management tools, integrated Python support, overhauled remote
management, online price lists and online purchasing of OpenVMS
licenses, a completely overhauled PAK system, TLS and DTLS 1.3 and
preferably kernel support, IPv6 support, encrypted disks, full IPv6
support, json/yaml/xml support, a mail server at least approaching
Postfix and Dovecot, sandboxes and support for isolating containers,
ASLR/KASLR/no-execute, GUIDs replacing facility prefixes and other
coordinated magic values, preferences storage frameworks so that we're
not all writing our own, integrated certificate management, PostgreSQL
and SQLite in the base distro, the removal of CDSA and the retirement
of SYSUAF et al (for LDAP), maybe MQTT or CoAP support, clustering via
TLS/DTLS, maybe OO API support, support for consistent backups of open
RMS files, etc., .etc., etc., ... before I get really interested in
adding blockchains in logging, and that's all only after the OpenVMS
x86-64 port is available and stable and layered products and
third-party packages are becoming available. And maybe not even then.
I'm presently wrestling with a major programming language that isn't
working right on OpenVMS. And it should. Blockchain support isn't at
the top of my list, nor I'd suspect near that of most folks.

There are applications for blockchains. Definitely. And for
cryptocurrencies. Cryptocurrency wallets are pretty good intrusion
canaries, for instance. But blockchains? In OpenVMS? Unless
somebody can better elaborate the case for adding blockchains for
clustering or logging or other purposes, that's seemingly just so far
down the priority list that anybody that needs a blockchain in an app
can use some of the available open source. Have a look at
https://www.ethereum.org or otherwise. There are enough half-baked
grafted-on giblets on OpenVMS — digital certificate management comes to
mind, here — that adding blockchain "support" could certainly comprise
a checkbox feature, and some marketeering fodder.

In all seriousness, do please convince me that there are bigger
applications for integrating distributed ledger support into OpenVMS
here, past a adding a framework or two. Reasons ahead of getting a
whole lot of other work, as nobody around here has infinite staff and
schedule. I'm certainly interested in hearing about those cases and
those applications, too. And also hearing how VSI is also going to
sell more OpenVMS licenses to existing and/or to new customers with
those blockchain features, too.

[Neil Rieck]

Even if the cryptocurrency thing fails (some are convinced it will; some are convinced it will not; I have no opinion either way), there are many people who think that block-chain might be a realistic way of setting democracies back on track by protecting the voting system.

Why place your trust in the maker of a voting machine from some corporation that may, or may not, have ties to political interests? And since the block-chain is considered tamper-proof (at least for now) then any voter should be able to query his encrypted vote after the fact to prove that it has been properly registered.

Just food for thought

[Bill Gunshannon]

On 12/30/2017 11:08 AM, Neil Rieck wrote:
> Even if the cryptocurrency thing fails (some are convinced it will; some are convinced it will not; I have no opinion either way), there are many people who think that block-chain might be a realistic way of setting democracies back on track by protecting the voting system.
>
> Why place your trust in the maker of a voting machine from some corporation that may, or may not, have ties to political interests? And since the block-chain is considered tamper-proof (at least for now) then any voter should be able to query his encrypted vote after the fact to prove that it has been properly registered.

Which, of course, doesn't guarantee it was counted where the voter
wanted it counted or even at all.

>
> Just food for thought

We are back to the trust issue. I am amazed at how many people play
"table games" against a computer dealer. Why would you play cards
with a dealer who not only knows all the cards you are holding but
can deal any card next because there really is no deck.

Computerized voting is no different. They can hand you all the proof
you want. Easy to generate on demand. But, more importantly, if the
system can tell you how you voted what is to stop it from telling
anyone else? So much for secret ballots.

bill

[Neil Rieck]

This just hit my INBOX and it may help some people here:

Bitcoin: How Cryptocurrencies Work
https://www.youtube.com/watch?v=kubGCSj5y3k

[Neil Rieck]

Uh, it wasn't my idea. I've seen the idea mentioned many times. This is the last article I personally stumbled onto.

https://www.newscientist.com/article/mg23531424-500-bitcoin-tech-to-put-political-power-in-the-hands-of-voters/

It was "hanging chads" and other things seen in the US Presidential election of 2000 that caused some Americans to wonder about an alternative. IMHO, just seeing long lineups in some US counties in Nov-2016 where an insufficient number of voting machines were available made me think that the ballot paradigm had outlived its usefulness.

Now for block-chain voting, each person would need to access the internet in some way. Not everyone owns computers so could this happen at a bank or ATM? I have no idea. But the ability to prove that my vote was not tampered with is intriguing.

[John Reagan]

Another good link for learning block chain

https://twit.tv/shows/security-now/episodes/643

[Phillip Helbig (undress to reply)]

In article <c74f6fc1-103d-4c7b...@googlegroups.com>, Neil
Rieck <n.r...@sympatico.ca> writes:

> Even if the cryptocurrency thing fails (some are convinced it will; some ar=
> e convinced it will not; I have no opinion either way), there are many peop=
> le who think that block-chain might be a realistic way of setting democraci=
> es back on track by protecting the voting system.=20
> =20
> Why place your trust in the maker of a voting machine from some corporation=
> that may, or may not, have ties to political interests? And since the bloc=
> k-chain is considered tamper-proof (at least for now) then any voter should=
> be able to query his encrypted vote after the fact to prove that it has be=
> en properly registered.

Any sensible democracy has paper ballots and public counting.