Blockchain-Free Cryptocurrencies: Framework for Truly Decentralised Fast Txns

[Jabbawa]

Great post! Very interesting.

What are your thoughts on close group consensus and datachains aka the maidsafe solution?

This above may not seem relevant to your post. But the "Close Groups" detailed in the Maidsafe only need to add the state data (CAST) or block headers/data (bitcoin) to their routing tables and therefore cache the data in the distributed network.

Thanks for the response. I'm not a developer myself so found it challenging to follow and I had to read it a few times to try to take it all in.   Can you just follow-up with the implications of the last sentence please? Just to make sure I've understood correctly, it would be helpful to have it spelled out for me.

[1714683250]

1714683250

[1714683250]

1714683250

[iamnotback]

EVEI consensus operates at a partition level, and the global state is simply a culmination of all partition level state consensus outcomes.  This functions reliably due to the fact that most nodes will operate more than a single partition and the variance of node partition configurations in the network will lead to an amount of overlap.  This overlap provides an auditable causality of the global state from current and past partition states.

How do you determine finality of consensus for cross-partition transactions in order to prevent a double-spend?

[iamnotback]

What are your thoughts on close group consensus and datachains aka the maidsafe solution?

I understand that this has all been theoretical and hard to investigate for the last couple of years, but as of last month things have become much clearer with progress made and dev tutorials etc.

IF (and I understand it is a fairly big 'if') they pull it off, SAFEcoin should scale positively, be instant/zero confirmation times, no mining or centralisation risks (proof of resource), no fees and it will be completely private/anonymous like real digital cash - not to mentioned backed by real computing resources so more tangible in value than even gold.

Sounds like I'm shilling I know, but really I just want to know how close a look you have taken at what they are doing in the last few months? Testsafecoin is due for release in January. I don't doubt it will be delayed further because everything always is, but do you not think that datachains hold the most promise?

https://blog.maidsafe.net/2015/01/29/consensus-without-a-blockchain/

I'm not saying that anyone should be 100% convinced they can pull it off even after 11 years on the job, but IF they do...?

MaidSafe has always been a steaming pile of BS.

I was the first one in this forums who proposed proof-of-storage (or proof-of-retrievability) in 2013 and quickly dismissed it because there is no way to prove that the nodes aren't sybil attacked and thus really stored redundantly. I have already refuted that various white papers that have come since that time, including Sia's developer and others such as some paper I think from IOHK.

For illustrative purposes, when Alice pays a coin to Bob via the client, she submits a payment request. The Transaction Managers check that Alice is the current owner of the coin by retrieving her public key and confirming that it has been signed by the correct and corresponding private key. The Transaction Managers will only accept a signed message from the existing owner. This proves beyond doubt that Alice is the owner of the coin and the ownership of that specific coin is then transferred to Bob and now only Bob is able to transfer that coin to another user. This sending of data (coins) between users is contrary to the Bitcoin protocol where bitcoins aren’t actually sent to another user, rather bitcoin clients send signed transaction data to the blockchain.

The lack of blockchain means that it is not possible to scrutinise all the transactions that have ever taken place or follow the journey of a specific coin.

Lol. Don't you understand that means you have to trust all the Transaction Managers and the blockchain can't prove a damn thing.

That is utter nonsense.

[TransaDox]

Thanks for the response. I'm not a developer myself so found it challenging to follow and I had to read it a few times to try to take it all in.   Can you just follow-up with the implications of the last sentence please? Just to make sure I've understood correctly, it would be helpful to have it spelled out for me.

• Full or not full node distinction becomes moot.
• Lower Footprint - Disk usage of <1GB regardless of block-chain size.
• Faster Synch  - A couple of hours of synchronizing to the network, from cold, before being able to make a transaction rather than days as it currently stands.
• Low risk - Works safely alongside the current distribution methods (both for full and SPV) and can be used as an accelerator (or not   ) during early adoption when there are few capable nodes.

[Jabbawa]

Thanks for the response. I'm not a developer myself so found it challenging to follow and I had to read it a few times to try to take it all in.   Can you just follow-up with the implications of the last sentence please? Just to make sure I've understood correctly, it would be helpful to have it spelled out for me.

• Full or not full node distinction becomes moot.
• Lower Footprint - Disk usage of <1GB regardless of block-chain size.
• Faster Synch  - A couple of hours of synchronizing to the network, from cold, before being able to make a transaction rather than days as it currently stands.
• Low risk - Works safely alongside the current distribution methods (both for full and SPV) and can be used as an accelerator (or not   ) during early adoption when there are few capable nodes.

TY

[iamnotback]

• Full or not full node distinction becomes moot.

Don't lie. The trust failures have not been incorporated into your lack of analysis of the game theory.

[TransaDox]

Don't lie. The trust failures have not been incorporated into your lack of analysis of the game theory.

Then you need to think harder about how one fills in the blocks between two checkpoints and what happens if a number of nodes feed you incorrect blocks.

Hint: Malicious nodes feeding blocks are no different than orphan blocks.

[iamnotback]

Don't lie. The trust failures have not been incorporated into your lack of analysis of the game theory.

Then you need to think harder about how one fills in the blocks between two checkpoints and what happens if a number of nodes feed you incorrect blocks.

Hint: Malicious nodes feeding blocks are no different than orphan blocks.

Write a white paper, otherwise you are just spewing incomprehensible babble. Invariably those who can't write it down in a whitepaper, are spewing incorrect babble.

Nodes can be Sybil attacked. Propagation ordering is not proof nor consensus. Write a whitepaper that explains the Byzantine fault tolerance in your design.

[TransaDox]

Write a white paper, otherwise you are just spewing incomprehensible babble. Invariable those who can't write it down in a whitepaper, are spewing incorrect babble.

No. I have a family to feed so the software that I work on is carefully chosen and purely academic papers to prove to game theorists that something has merit is not even on the radar. Add to that the vehement resistance to anything that changes the status quo away from centralisation and there is little incentive for me to do anything like that.

Bitcoin is heading towards being a credit card back end and I pretty much agree and feel the same as TPTB_need_war from one of the links in your previous posts.

We are not producing any fundamental breakthrough on the problem of decentralized electronic money. I do not like to work on things that I feel are misdirected and destined for failure in the end. I don't want to get rich by fooling other people (or fooling myself).

I'll throw a few ideas and software techniques in for others to run with but until I see that centralisation even being talked about as an issue then I have to spend time on software that feeds my family as I'm not independently wealthy nor part of the paid bitcoin industry. What does game theory have to say about altruism?

Nodes can be Sybil attacked. Propagation ordering is not proof nor consensus. Write a whitepaper that explains the Byzantine fault tolerance in your design.

Then you still haven't understood. It is the most unordered propagation you can get and not only from 8 connections, but hundreds. The block chain is still used as the proof-that doesn't change. I am merely talking about a delivery and storage mechanism for the block chain which can provide additional assurances to accelerate the distribution whilst still supplying the network with full node capabilities (without every single block on every disk).

However. Thanks for at least asking about it even if you can't be bothered to think it through. It gives me a little more hope that there are people in the community that are still thinking about technical improvements rather than get-rich-quick protocol schemes to directly monetise the blockchain.

[iamnotback]

Then you still haven't understood. It is the most unordered propagation you can get and not only from 8 connections, but hundreds. The block chain is still used as the proof-that doesn't change. I am merely talking about a delivery and storage mechanism for the block chain which can provide additional assurances to accelerate the distribution whilst still supplying the network with full node capabilities (without every single block on every disk).

Then you are not talking about a decentralized consensus on the finality of transactions, i.e. that can't result in a double-spend.

Dude I have a very deep understanding the of possibilities for Byzantine fault tolerance for the CAP theorem consistency, partition tolerance, and access (liveness) in consensus ordering systems. Putting unordered items into a distributed database has nothing to do with it.

[TransaDox]

Then you are not talking about a decentralized consensus on the finality of transactions, i.e. that can't result in a double-spend.

Dude I have a very deep understanding the of possibilities for Byzantine fault tolerance for the CAP theorem consistency, partition tolerance, and access (liveness) in consensus ordering systems. Putting unordered items into a distributed database has nothing to do with it.

Indeed. However I was responding to Jabbawa about the XOR distance function that Maidsafe uses and the interesting features that arise when applied to bitcoin as a DHT.

You then called me a liar "spewing incomprehensible babble".

[Jabbawa]

Then you are not talking about a decentralized consensus on the finality of transactions, i.e. that can't result in a double-spend.

Dude I have a very deep understanding the of possibilities for Byzantine fault tolerance for the CAP theorem consistency, partition tolerance, and access (liveness) in consensus ordering systems. Putting unordered items into a distributed database has nothing to do with it.

Indeed. However I was responding to Jabbawa about the XOR distance function that Maidsafe uses and the interesting features that arise when applied to bitcoin as a DHT.

You then called me a liar "spewing incomprehensible babble".

I appreciated the responses to my question TransaDox, I've learned a fair bit. The conversation is out of my pay grade, so I've had to do a lot of side-reading to make sense of it.

I'm not sure why you got attacked for it. Who knows if maidsafe will pull it off? It certainly feels like an esoteric challenge to understand it all. And far too complicated to be dismissed out of hand. It's several new layers of internet protocol after all, it doesn't play by the same rules and the deeper I look the more fascinated I become.

[TransaDox]

I appreciated the responses to my question TransaDox, I've learned a fair bit. The conversation is out of my pay grade, so I've had to do a lot of side-reading to make sense of it.

I'm not sure why you got attacked for it. Who knows if maidsafe will pull it off? It certainly feels like an esoteric challenge to understand it all. And far too complicated to be dismissed out of hand. It's several new layers of internet protocol after all, it doesn't play by the same rules and the deeper I look the more fascinated I become.

Domain experts tend to be very focused on their sphere of expertise to the exclusion of all else. Therefore the forum style of conversations where there are sporadic wanderings - akin to sidechains in bitcoin parlance - tend to get conflated and perceived as noise to their message.  Some are more tolerant than others of these interruptions and partake in the side conversations to entertain and explain to non-domain experts. At the other extreme; others lambaste as "you don't know what you are talking about" and deem it beneath them to explain, entertain or teach. This thread is somewhere in between.

I wouldn't get too bogged down in the Maidsafe implementation. It is a monetisation of the blockchain based on the work of IPFS. If one reads the well written IPFS document I linked to, it gives a better overview of the technology. Maidsafe has used an alt-coin as a method of account for the BitSwap Protocol (Section 3.4). I also suspect Kim Dotcoms new platform will be something similar to BitSwap (if not exactly).

[Jabbawa]

Many thanks, I'm making my way through that IPFS doc now and enjoying it.

[xizmax]

Many thanks, I'm making my way through that IPFS doc now and enjoying it.

Couldn't agree more.
TransaDox' characterization of forum parlance is also spot on

[iamnotback]

TransaDox' characterization of forum parlance is also spot on

In that respect his posts have the same flaw. He should post a well developed, peer reviewed whitepaper instead of referring to nonsense from MaidSafe as somehow being coherent.

Write a white paper, otherwise you are just spewing incomprehensible babble. Invariably those who can't write it down in a whitepaper, are spewing incorrect babble.

Nodes can be Sybil attacked. Propagation ordering is not proof nor consensus. Write a whitepaper that explains the Byzantine fault tolerance in your design.

[iamnotback]

My off-the-top-of-my-head quick list of issues with SPECTRE:

https://medium.com/@shelby_78386/quoting-from-the-whitepaper-29e9fbc0ebec#.f4n0rdaho

Please check my logic?

There are many cases where you might see conflicting transactions in the network that we're broadcast legitimately by honest users.

An obvious one that springs to mind is a company that has a number of nodes across the planet and is processing payments in some form.  If one (or more) of the nodes are subject to some lag, they might create and broadcast a payment that already exists via some smart-contract logic perhaps, yet the producing node is not aware of it being a duplicate due to lag (or any other reason).

That's not being dishonest and is a legitimate case that can, and will happen.

Good point. Their requirement is basically one of requiring external synchronization, but asynchrony is the norm on networks. Synchrony is generally impossible.

I added the following edit to my comment at Medium:

Edit: Fuserleer (eMunie developer) has pointed out that this requires external synchronization which is generally impossible on networks, e.g. wherein a company has multiple nodes across the network which issue transactions asynchronously. Thus employing the blockchain as the synchronization mechanism. If the company tried to employ their own blockchain for synchronization, then forwarded the transactions to your blockchain, then it requires one node to synchronize to do the forwarding, which is not resilient. In general, asynchrony can’t be avoided.