{"type":"rich","version":"1.0","author_name":"npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuyn","author_url":"https://nostr.ae/npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuyn","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2011-12-17\n🗒️ Summary of this message: A proposed idea to structure the network in a hypercube and use prefixes to address different parts of the network, reducing the need for broadcasts.\n📝 Original message:A while back I had proposed a similar idea to the DHT, although my main\ngoal was to reduce the need for broadcasts.\n\nMy idea was to structure the network in a hypercube and use prefixes to\naddress different parts of the network, and use those prefixes also to find\nthe location where an item (transaction, block, ...) should be stored. Each\nvertex in the hypercube is a small, highly connected, cluster of nodes. The\nstorage would be distributed, messages are routed on behalf of others,\nwhich makes finding the origin of the query hard to find (think Tor), each\nnode would have to store only O(log(p)) items, with p being the prefix\nlength, maximum number of hops is equal to the dimension of the hypercube\nO(log(n)).\n\nNewly created transaction will be sent directly to the location they'll be\nstored and miners retrieve new transactions at regular intervals. It might\nincrease delays to the confirmations, but it reduces the number of\nbroadcasts and storage requirements on nodes greatly.\n\nRegards,\nChris\n\n\nOn Sat, Dec 17, 2011 at 2:13 PM, Michael Grønager \u003cgronager at ceptacle.com\u003ewrote:\n\n\u003e Hey Eric,\n\u003e\n\u003e Two comments.\n\u003e\n\u003e 1.\n\u003e The ability to query for transactions belonging to pubkeys or bitcoin\n\u003e addresses is supported today by several implementations:\n\u003e * blockexplorer.com\n\u003e * bitcoin-js\n\u003e * my own libBTC (will more on this soon)\n\u003e\n\u003e To query for transactions you need to use json-rpc and not the bitcoin\n\u003e protocol, however. But still the purpose is the same: to be able to build\n\u003e thin clients that can rely on a server for storing the blockchain and\n\u003e keeping connected on the p2p network.\n\u003e\n\u003e The reason for not having these queries part of the standard protocol (I\n\u003e think) are as they breaks anonymity, and that you would actually encourage\n\u003e people to participate in the p2p.\n\u003e\n\u003e 2. The second part you mention, to some how move the storage of the\n\u003e blockchain into a DHT based storage would be quite nice. The benefit of\n\u003e this is that it could be a way to integrate the smaller clients into the\n\u003e network without breaking the anonymity. But it should be thought out quite\n\u003e carefully. Further, if each client only store a fraction of the blockchain\n\u003e we should work out what fraction that need to be in order to ensure a\n\u003e similar service level. I would be happy to work with you on this.\n\u003e\n\u003e Cheers,\n\u003e\n\u003e Michael\n\u003e\n\u003e On 17/12/2011, at 08:41, Eric Lombrozo wrote:\n\u003e\n\u003e \u003e Hey, guys.\n\u003e \u003e\n\u003e \u003e I haven't posted here before so I'll introduce myself. My name's Eric,\n\u003e \u003e I've been developing cryptocurrency-related\n\u003e \u003e software for several months now, I've implemented some libraries for\n\u003e \u003e dealing with core bitcoin datastructures, made\n\u003e \u003e some custom builds of bitcoind and interfaced it with a few apps I've\n\u003e written.\n\u003e \u003e\n\u003e \u003e In doing so, I've come to appreciate just how little of the potential\n\u003e \u003e for the bitcoin protocol is being exploited right now...\n\u003e \u003e not only in terms of the script features but in terms of the potential\n\u003e \u003e commands and node types that could exist.\n\u003e \u003e\n\u003e \u003e For instance, the protocol spec at\n\u003e \u003e https://en.bitcoin.it/wiki/Protocol_specification only has 16 commands\n\u003e \u003e listed and\n\u003e \u003e only one service type...despite having a full 12 bytes for a command\n\u003e \u003e code and a full eight bytes for a services\n\u003e \u003e type.\n\u003e \u003e\n\u003e \u003e The fact that only one node service type is specified is probably due\n\u003e \u003e to the fact that the satoshi client was written\n\u003e \u003e to be a standalone monolithic app that took care of all the essential\n\u003e \u003e needs for a network of peers.\n\u003e \u003e i.e. block chain storage/management, transaction signing/verification,\n\u003e \u003e key generation/wallet management, block mining, etc...\n\u003e \u003e However, I think there's an urgent need for breaking up all these\n\u003e \u003e different tasks into separate components that can run as independent\n\u003e \u003e services on different types of devices.\n\u003e \u003e\n\u003e \u003e One of the big issues I'm dealing with now pertains to block chain\n\u003e \u003e storage. As of right now, it is implemented as sequential\n\u003e \u003e disk files using Berkeley DB in the satoshi client. Then you have\n\u003e \u003e other projects that have been using SQL tables, etc...\n\u003e \u003e But I believe the direction this really needs to move towards is some\n\u003e \u003e sort of distributed hash table...and the database queries\n\u003e \u003e should be performed using the bitcoin protocol itself. Perhaps adding\n\u003e \u003e a few more commands. As things stand right now,\n\u003e \u003e the only way to query for transactions or blocks is by their hash. And\n\u003e \u003e once a transaction gets incorporated into a block and\n\u003e \u003e removed from the transaction pool, one can no longer query it by the\n\u003e \u003e transaction hash without stepping outside the bitcoin protocol.\n\u003e \u003e We need access to the disk file that stores the blocks whether it be\n\u003e \u003e via Berkeley DB or SQL or whatever.\n\u003e \u003e\n\u003e \u003e I propose an extension to the bitcoin protocol to provide methods for\n\u003e \u003e performing more sophisticated queries, such as \"Give me\n\u003e \u003e an inventory of transactions involving this particular public key\" or\n\u003e \u003e \"Give me an inventory all transactions in the last n blocks with\n\u003e \u003e unredeemed outputs.\" This could be done by adding a few more commands.\n\u003e \u003e\n\u003e \u003e Furthermore, I propose a new network services type for nodes that\n\u003e \u003e serve as block chain/transaction pool storage.\n\u003e \u003e\n\u003e \u003e Of couse, any peer that wishes to verify the integrity of the block\n\u003e \u003e chain would still have to download at the very least\n\u003e \u003e all the block headers...and to be completely sure, also all the blocks\n\u003e \u003e themselves...and verify everything. But it would be\n\u003e \u003e very nice to be able to run thin services that can rely on other\n\u003e \u003e network peers to do this work. It is still possible to attain\n\u003e \u003e a high level of confidence in the integrity by querying multiple peers\n\u003e \u003e for similar objects and comparing. It is also possible\n\u003e \u003e to run your own dedicated block chain storage servers which you trust.\n\u003e \u003e\n\u003e \u003e There are other ideas I have for other types of services, too.\n\u003e \u003e\n\u003e \u003e Anyhow, I'm just throwing this out there...if anyone's interested I'd\n\u003e \u003e love to develop these ideas further and help put together some\n\u003e \u003e specs.\n\u003e \u003e\n\u003e \u003e -Eric Lombrozo\n\u003e \u003e\n\u003e \u003e\n\u003e ------------------------------------------------------------------------------\n\u003e \u003e Learn Windows Azure Live!  Tuesday, Dec 13, 2011\n\u003e \u003e Microsoft is holding a special Learn Windows Azure training event for\n\u003e \u003e developers. It will provide a great way to learn Windows Azure and what\n\u003e it\n\u003e \u003e provides. You can attend the event by watching it streamed LIVE online.\n\u003e \u003e Learn more at http://p.sf.net/sfu/ms-windowsazure\n\u003e \u003e _______________________________________________\n\u003e \u003e Bitcoin-development mailing list\n\u003e \u003e Bitcoin-development at lists.sourceforge.net\n\u003e \u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Learn Windows Azure Live!  Tuesday, Dec 13, 2011\n\u003e Microsoft is holding a special Learn Windows Azure training event for\n\u003e developers. It will provide a great way to learn Windows Azure and what it\n\u003e provides. You can attend the event by watching it streamed LIVE online.\n\u003e Learn more at http://p.sf.net/sfu/ms-windowsazure\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111217/000eef2b/attachment.html\u003e"}