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.
|
|
|
|
Great post! Very interesting.
What are your thoughts on closed group consensus and datachains aka the maidsafe solution?
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. |
|
|
|
|
RBS back end services, here we come.
The beginning of the end of bitcoin transactions for normal people.
|
|
|
|
I already put a link to this draft of mine in one similar thread here: https://arxiv.org/abs/1603.07926 . Going to polish it soon to announce then widely. PoW has ben changed(to solve incentives problem as well), so Bitcoin can't go this way definitely. There is no will to resolve this issue. indeed. It is being actively resisted because....money. It seems that many of those that are worried about it are only interested because it is the last thing they might be able to monetise because mining is now out of their reach. Only people trying to create new coins would need to run
network nodes. At first, most users would run network nodes, but as the
network grows beyond a certain point, it would be left more and more to
specialists with server farms of specialized hardware. A server farm would
only need to have one node on the network and the rest of the LAN connects with
that one node.
Satoshi Nakamoto |
|
|
|
It is possible to set up "spanned" volumes which would probably do something similar to what you are trying to achieve. It would just look like a single partition to the OS (and therefore the software) and one can span up to 32 disks. |
|
|
|
Bitcoin was designed with the advancement of technology in mind. The whole difficulty adjustment thing is to ensure that, even as CPUs get faster, we continue to get blocks that are 10 minutes apart on average. If you feel that expecting technology to continue to advance is wrong then you should find some other hobby. Forget about bitcoin.
Condescending much? It's like arguing with creationists!  It's not a case of forgetting about bitcoin. It's about preventing it becoming purely a back end service for VISA, Paypal and Western Union. |
|
|
|
20 years ago the average person didn't need more than 100 GB of storage. File sizes have been getting progressively larger. Just because something is that way now doesn't mean it won't change in the future.
Sigh!  Yet still the full nodes keep diminishing. |
|
|
|
Hard drive capacity will continue to increase, and it will most certainly outpace the growth of the blockchain. Disk space gets cheaper by the day.
You've been excellent at answering many questions on many threads then you come out with this tired trope. Please don't disseminate this rubbish. It's not, and has never been, a solution. It is the bitcoin equivalent of "Have faith that God shall provide". |
|
|
|
Soft forks make previously valid things invalid, hard forks make
previously invalid things valid. This is probably the most succinct and understandable explanation that has never been stated about bitcoin. |
|
|
|
If you had it high, it would confirm.
A.K.A. Pay to win. I dislike this model for bitcoin, orders of magnitude than than I do for games. |
|
|
|
a collision is when while(1) {
for (a = 0 to 2^160) {
adr1 = ripemd160(sha256(pubkey(a)))
adr2 = ripemd160(sha256(pubkey(rand(2^256-2^160)+2^160)))
if (adr1 == adr2) {
print "We got ourselves a collision!\n";
}
}
}
I think you mean: adr1 = ripemd160(sha256(pubkey(rand(2^256-2^160)+2^160)))
for (a = 0 to 2^160) {
adr2 = ripemd160(sha256(pubkey(a)))
if (adr1 == adr2) {
print "We got ourselves a collision!\n";
}
}
|
|
|
|
|
Whilst everyone is banging on about how big these numbers are and coming up with all sorts of eloquent calculations and analogies to demonstrate. No one seems to have factored in to those calculations that for a collision, the general probability is over Sqrt(keyspace) and the keyspace diminishes as keys are discovered.
Magnitude of the entire keyspace is a poor proof.
|
|
|
|
Can you imagine, IoT requires a more lightweight algorithms base.
I already have an Internet of Things that need internet. Turns out there aren't that many and those that do have lots of processing power because they need to defend themselves from the internet. |
|
|
|
but as I look at it, the public->private key system is 1 directional
This is a flaw in your assumptions. It is not one directional. The private and public keys are two parts of a puzzle. The puzzle is easy to make but so hard to solve that it is effectively impossible. However there is one exception. There is a shortcut that makes the solving very fast and easy. There is a secret "trap door" that enables bypassing of the impossibly hard route and to open it you need the right [private] key. So one gives the public key to anyone that wishes to make a puzzle. Once created only the person that knows the key to the "trap door" can solve it. This is why they are termed "key pairs" since a private and public key are related by the "trap door". This is the premise behind most cryptography that is based on a "trap door function" and includes Elliptic Curve, RSA and DSA to name the more common ones. Hopefully you can see that to tell everyone how to open the secret trap door is, in general, not a good idea. |
|
|
|
What do you think of my idea?
I think you don't know much about cryptography, you don't understand why the bitcoin protocol does the things it does, you don't understand the concept of decentralized and trustless, and your idea has too many holes in it to give much consideration to. Arrogance and intolerance like this is what will kill bitcoin eventually so please adjust your attitude or say nothing at all. There is nothing of merit that can be learned from this type of response and as a Legendary member it is an atrocious example to set. |
|
|
|
- Publicly accessible
- Impossible to tamper with.
- Replicated among several nodes with the ability for external nodes to join without manually reconfiguring the system
- No central authority (no “main” node, or authorization server)
- Free and efficient (no mining, no native currency)
. If one uses a quad instead of a triple then the block can be stored in the routing table. The sorting algorithm needs slight tweaking since it favours persistent nodes rather than persistent data. There is also the possibility of bootstrapping and transacting before the full chain has been downloaded and verified (with high a very confidence) and if one uses the distance function to link the merkle hashes to the node ID then the cached blocks act as pre-verified checkpoints. Each node would probably only need about 1G of persistent data (size is dependent on hash and K bins). |
|
|
|
Block header should be transmitted by http protocol. Block data can be transmitted with IPFS.
Only miner can create valid block header and write valid block data.
If you are using IPFS why do you need HTTP at all? What failing of IPFS is HTTP addressing in this use case? How do you enforce that only a Miner can create (and delete/modify) a block. There is no mechanism in IPFS to ascertain who is and isn't a Miner. It's a file system with permissions just like a network share except the data is distributed. |
|
|
|
|
Problem.......Who has write permissions on the blocks?
A modified S/Kademlia solution is viable though.
|
|
|
|
|
Yes it is possible. There are some considerations, though.
Currently to sync to the network, 10s of GB (80?) of disk space is required for a full node (soon to be >100 GB). I will not discuss SPVs here since they are a poor solution relying on trusted 3rd parties.
The actual space consumed is not so much of an issue (I'm not talking about Moores Law that the hard of thinking espouse, either) but the 10s of GBs do still need to be downloaded even if not stored. Many mobile packages (99% in my country) limit the bandwidth to a couple of GB per month so it becomes almost impossible to sync. Unlimited bandwidth mobile packages are required and these are like rocking horse droppings and far from cheap.
Assuming that one has already synchronised, then things become easier. A block is created approximately every 10 minutes and is about 1MB. That's about 144MB per day (~4.3 GB per month). Still. These plans are quite expensive and if one is also an avid Youtube watcher then you will have problems. If the block size is increased then the required bandwidth will also increase accordingly so uncapped, "always on" connections are a requisite.
Battery consumption is also a consideration but most people have been conditioned to accept poor battery life so it may be a non-issue. This could be alleviated to some extent by slight behavioural changes to the mempool or smart burst management when not charging while fully engaging when charging. This aspect is not well understood at present since the community is dismissive of mobile platforms and I know of very little research in this direction. The worst case scenario is that you have to keep the mobile device plugged in permanently although I expect several hours of untethered operation is more than achievable with careful app management and changes to the core software.
So the hard limitation is the mobile bandwidth of the packages. If one has an uncapped, "always-on" mobile package then there is no reason a mobile platform cannot be used but some of the current operating aspects would need to change to make is usable by Joe Public.
|
|
|
|
|
Show Posts
