Pages:
Author

Topic: ion discussion - page 6. (Read 9675 times)

sr. member
Activity: 294
Merit: 260
September 09, 2015, 02:01:14 AM
#3
Following. Kudos to you for deciding to go forward with this after all, one way or another.
donator
Activity: 1722
Merit: 1036
September 09, 2015, 01:56:29 AM
#2
Following. I like the name!
newbie
Activity: 28
Merit: 0
September 08, 2015, 09:50:02 PM
#1
Recently I announced my rationale to develop my coin non-anonymously, with any anonymity features to be added by other developers later.

The proposed name of the coin is Ion with a capitalized first letter when it can be written with a serif font, e.g. Ion— otherwise ion instead of Ion. For me ion connotes a thing that can conduct a current and be zapped to a destination.

Formerly AnonyMint et al, I expended 2+ years thinking about anonymity designs and recently formalized an unreleased white paper which I think is the holy grail of on chain anonymity. This will be offloaded to other developers, so I can work non-anonymously on this coin.

The current focus of my development on this coin is to complete a novel consensus network design which has proposed the following fixes to flaws in Satoshi’s design while retaining proof-of-work as unbounded entropy[1]:

  • Censorship resistance even if mining is entirely centralized.
  • Attack-free instant zero confirmation instantaneous transactions.
  • Impervious to selfish mining and 51% attacks.
  • Transaction rates virtually unbounded by block chain bandwidth and size.
  • Resilient against network fragmentation.
  • Decentralization of pools and ASICs by making them uneconomic.
  • Non-heuristic Sybil and DoS resistance.

None of the above is a joke nor exaggeration. I am entirely serious. My programming background and expertise is documented in the archives of my prior usernames.

Currently unreleased white papers will not be published until this coin is nearer to release to insure these designs are released first in our coin. Thus for the time being I will not be providing more details on how the above features are accomplished.

I am using this thread to post updates about the coding progress. This thread will be pruned periodically so please don't get offended if your post was incorporated into the summary below.

[1] My position until I am convinced otherwise is that all non-proof-of-work consensus systems have a bounded entropy (e.g. the total stake and/or any initial seeds used for randomization) and thus their attributes (e.g. decentralization, censorship resistance, DoS resistance, Sybil attack resistance, impartiality) is subject to a game theory which is potentially undiscovered. Whereas, the entropy of proof-of-work is unbounded because it is externally added and the game theory is well defined.



Some readers wondered how my consensus network design can delegate without requiring trust whereas Satoshi's proof-of-work is trustless. I explained that if the function of these delegated nodes is verifiable truth, replaceable, non-discretionary, and not monopolizable, then using a twist on the security model and some epiphanies on delegation membership, Merkel encoding, Cuckoo hashing, Sybil, and DoS strategies, then it is possible to achieve that trustless delegation. I did not disclose further details and will not until implementation is nearer to completion (some months to go). Monsterer asked about how orphaned deleted actions would be handled and I responded that I had solved that issue but I wasn't revealing how at this time.

I familiarized myself again with Bitshares' Delegated Proof-of-Stake (DPoS) and concluded that is yet another design that sacrifices effective centralized control in order to scale transaction rates higher. Satoshi's design also suffers this same tradeoff.
Pages:
Jump to: