{"type":"rich","version":"1.0","author_name":"npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krq","author_url":"https://nostr.ae/npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krq","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2011-12-17\n🗒️ Summary of this message: Eric, a cryptocurrency developer, believes that the potential of the bitcoin protocol is not being fully exploited. He proposes breaking up tasks into separate components and adding more commands to perform sophisticated queries. He also suggests a new network services type for nodes that serve as block chain/transaction pool storage.\n📝 Original message:Hey, guys.\n\nI haven't posted here before so I'll introduce myself. My name's Eric,\nI've been developing cryptocurrency-related\nsoftware for several months now, I've implemented some libraries for\ndealing with core bitcoin datastructures, made\nsome custom builds of bitcoind and interfaced it with a few apps I've written.\n\nIn doing so, I've come to appreciate just how little of the potential\nfor the bitcoin protocol is being exploited right now...\nnot only in terms of the script features but in terms of the potential\ncommands and node types that could exist.\n\nFor instance, the protocol spec at\nhttps://en.bitcoin.it/wiki/Protocol_specification only has 16 commands\nlisted and\nonly one service type...despite having a full 12 bytes for a command\ncode and a full eight bytes for a services\ntype.\n\nThe fact that only one node service type is specified is probably due\nto the fact that the satoshi client was written\nto be a standalone monolithic app that took care of all the essential\nneeds for a network of peers.\ni.e. block chain storage/management, transaction signing/verification,\nkey generation/wallet management, block mining, etc...\nHowever, I think there's an urgent need for breaking up all these\ndifferent tasks into separate components that can run as independent\nservices on different types of devices.\n\nOne of the big issues I'm dealing with now pertains to block chain\nstorage. As of right now, it is implemented as sequential\ndisk files using Berkeley DB in the satoshi client. Then you have\nother projects that have been using SQL tables, etc...\nBut I believe the direction this really needs to move towards is some\nsort of distributed hash table...and the database queries\nshould be performed using the bitcoin protocol itself. Perhaps adding\na few more commands. As things stand right now,\nthe only way to query for transactions or blocks is by their hash. And\nonce a transaction gets incorporated into a block and\nremoved from the transaction pool, one can no longer query it by the\ntransaction hash without stepping outside the bitcoin protocol.\nWe need access to the disk file that stores the blocks whether it be\nvia Berkeley DB or SQL or whatever.\n\nI propose an extension to the bitcoin protocol to provide methods for\nperforming more sophisticated queries, such as \"Give me\nan inventory of transactions involving this particular public key\" or\n\"Give me an inventory all transactions in the last n blocks with\nunredeemed outputs.\" This could be done by adding a few more commands.\n\nFurthermore, I propose a new network services type for nodes that\nserve as block chain/transaction pool storage.\n\nOf couse, any peer that wishes to verify the integrity of the block\nchain would still have to download at the very least\nall the block headers...and to be completely sure, also all the blocks\nthemselves...and verify everything. But it would be\nvery nice to be able to run thin services that can rely on other\nnetwork peers to do this work. It is still possible to attain\na high level of confidence in the integrity by querying multiple peers\nfor similar objects and comparing. It is also possible\nto run your own dedicated block chain storage servers which you trust.\n\nThere are other ideas I have for other types of services, too.\n\nAnyhow, I'm just throwing this out there...if anyone's interested I'd\nlove to develop these ideas further and help put together some\nspecs.\n\n-Eric Lombrozo"}