twister-core
twister-core copied to clipboard
miguelfreitas
Important idea: How-to reduce block chain size in future / old username clean up
I love twister for many cool thing and technologies, it solve many problems but we have 1 main problem if we could solve them - it would be great software.
Main problem of twister - permanent registration because we use bitcoin block chain.
But user can make mistake in login or user can forget her private key or company register her name in twister (microsoft for example) and they die
All of this - loss of bitcoin block chain space.
i have cool idea (maybe only i think that it cool but i try to describe it to you)
We can make block chain not permanent - temporary.
Every N block or every X days block chain freezes and don't accept new registration on all clients.
In that time, automatically creates new chain and all new users are try to register in the new chain.
All old users must regenerate POW and send username + PUB key for registration and sign it with private key.
If user already have registration in old chain - system, accept registration and grant access (add pub key to new chain) if not - deny
After 2 month (i think 2 month is good time for wait old users for migrating) old block chain delete on all client and only new block chain are exists.
After X blocks or N month all are start again.
What we get ?
- Remove spam account
- Remove unused account
- Remove cybersquatters
- Remove forgotten account
- Dramatically reduce chain (main goal)
Whats the problem ?
- Protocol must be rewritten i am not C/C++ coder - i don't know how is hard.
What all cool services get ? I think that this system may be new web 3.0 decentralized registration system (all people love login in with (Facebook,Twitter, etc) we could make perfect registration provider with avatar, and minimal user info)
If people support me i can try write full whitepaper for that.
It seems that such system will have account decay/expiry in an IRC-like manner. This may not be a good idea for authentication to third party entities via OpenID-like mechanisms, at least if you use the nick as a handle and not a unique value such as public key. In that case I could wait for somebody's nick to expire in the current and previous blockchain and, since the older blockchains are not stored anywhere, re-register their nick in the new blockchain and impersonate that person. This should not be an issue if you use public key as authentication handle though, but ain't that volatile?
And I'd prefer the re-registration time to be 1 year.
I think the issue of squatting would be solved by putting in place countermeasures and mitigations (i.e. no more than 1 registration per peer every 24 hours) and then having a one-off "big reset" of the chain simply by dropping a new client that will start from scratch. We would free both keychain space and squatted usernames -- the only risk being another "16/1" attack as complexity drops, but again this is being worked on and might be a solved problem by then. After all, this is alpha software, breaking compatibility is not a terrible thing. We might even have scripts to dump previous messages, so people could bulk-post them once they have a newly-registered username.
@toyg we don't know which node registered a user. the registration is forwarded from node to node until it reaches a miner. you can't say if a node is just forwarding or if the registration was generated by that node.
What about adding a machine-specific hash to the registration request? It doesn't have to be stored on the machine or be particularly meaningful, it could be a one-way hash of something calculated at registration time, hence maintaining overall anonymity.
But what prevents me from faking the machine-specific hash? like generating random bytes?
about "How-to reduce block chain size" see also: "light trees" which are very pruned merkle trees for verifying specific transactions with some security
https://groups.google.com/forum/#!topic/twister-users/cLbO1qHvUBA
what is "written" into the blockchain shall never be removed/removable once included in a block. This is what most people love about merkle tree based structures. An option for lightweight solutions (i.e. for mobile applications on smartphone/tablet): we can make a lightweight version which only requires the twister client to download only part of the blockchain. This lightweight version would work by connecting to full node-clients (which have the full blockchain) and then use bloom filter solutions to ensure that they only receive blockinformations which are necessary and relevant only to their profile.
This lightweight version would work by connecting to full node-clients (which have the full blockchain)
The main problem with this is trust. The naive solution makes lightweight clients completely trust the full-node clients, which defeats the point of having a blockchain in the first place. And nobody has published a non-naive solution yet, as far as I know.
Just a thinking out loud...
It might be possible to write a service that will response with public key for requested username (I would incorporate such a service into twister-seeder, but I'm not sure it may be done easily; alternative way is to make it in a way similar to currently implemented DHT relay).
In Twister full blockchain is necessary for following tasks:
- Choose few random usernames for swarm.
- Search users (when you start to type in twister-html's search box).
- Confirm validity of DHT messages. (As to messages in torrents: number of torrents are limited, so full blockchain is not necessary there).
In first two cases it's sufficient to have list of usernames only (without public keys). Public keys are necessary for 3, but unlikely user's node stores messages by all existing users, so a limited subset of public keys is necessary only.
So, a blockchain-replacer should include following features:
- Response with the list of all registered usernames. Most likely response should be compressed, but I'm not sure about methods, the simplest way is to use gzip, but there should be better alternatives for sorted lists with limited alphabet.
- Response with public key(s) for a given username(s).
- Maintain blockchain in actual state (with optional mining).
I think the twister non-naive solution is quite simple: you want to prove a given pubkey is part of blockchain, so i'd send both the partial merkle tree within the block and the sequence of hashes up to that block. Of course the sequence of hashes is something that grows linearly, but it is probably safe to assume it would be manageable even for lightweight clients.
I don't know if bitcoin has a different problem, but it puzzles me why nobody ever implement such thing. What exactly the lightweight client has to trust? If the client is trying to make sure a given transaction was accepted into the blockchain, something like above should work. However if the lightweight client wants to check for double-spending himself, then i'd guess he needs the whole blockchain.
