Topic: Blockchain-Free Cryptocurrencies: Framework for Truly Decentralised Fast Txns (Read 7078 times)

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?

---

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:

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.

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

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

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).

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.

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".

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.

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.


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.

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.

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.

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

TY

• 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.

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.


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.

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

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.

XOR huh? That's the torrent (DHT) distance function too and interesting features arise......

The distance function is not related to the Merkle or DAG which means that if a node with a remote random ID (as defined by the DHT spec) , is required to cache data in its routing table, AND the decision of which data it should cache is also defined as the distance between its NodeID and the hash. Then the closest nodes to another randomly generated node ID will effectively be a pseudo random sampling of the block chain/CAST (or whatever ledger technology is used).

This means that random samples of the ledger or ledger state can be stored throughout the network and assembled just-in-time as needed. Since some blocks are cached locally by the node (as a function of their Merkle/DAG distance from the Node ID). The cached blocks act as random checkpoints to reconstitute the chain or tree. As the node fills in the data between the hashes for its own benefit, it will be sourcing from multiple and disparate nodes thus filling in the missing pieces requiring a sybil attack to have node IDs near each (random) checkpoint in the hope they get chosen over other "close" nodes. Once all data has been filled between two checkpoints, the confidence that the correct data has been received is extremely high to the point where data connecting one or two checkpoints would allow safe transactions to begin (faster bootstrap) while continuing to fill in the others until the entire chain/tree has been verified and the cached blocks become verified checkpoints. Subsequent bootstraps can start from the last verified checkpoint to the head and a periodic churn of checkpoints can be used over time.

Assuming a significant number of nodes (a reasonable assumption due the necessity of mining and the removal of large storage on a single device), the resistance to a sybil attack is extremely high and attempts detectable.

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.

Fuserleer, you should check out IOTA (iotatoken.com). It would be interesting to hear your opinion about it.