{"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-21\n🗒️ Summary of this message: Supernodes will verify transactions and be owned by miners. A hierarchical network will form with miners/supernodes at the top and lightweight clients at the bottom. DHTs may be used for block storage, but IP addresses should be used with caution. Broadcasting transactions may not be necessary, and caching could be used to reduce load on responsible nodes.\n📝 Original message:For the future evolution without considering DHTs:\nWhile I think we will sooner or later have supernodes, I don't think they\nwill need to be trusted too much.\nSupernodes will be those nodes that verify all transactions and make them\navailable to miners. Since miners will become more and more specialized\nthese supernodes are likely to be owned by the miners themself. To be a\nminer either you need to verify all the transactions you include (otherwise\nothers might be able to find an error in your block and thus drop it) or\nhave someone that verifies them for you. In the end I think we'll end up\nwith a hierarchical network, with the miners/supernodes tighly\ninterconnected at the top and the lightweight clients that simply verify\ntransactions (or their inputs to be precise) that are destined for them at\nthe bottom.\n\nAs for the DHT we had a few brainstorming sessions a while back on the\nforum http://bit.ly/sc2RLZ (gmaxwell didn't like it then either :D)\nForcing someone to participate in a fixed position in the block storage\nnetwork is a good way to reduce the risk of a sybil attack as Michael said.\nThe hash should include only information that cannot be changed by the\nuser, so IP can be used, but including the port is risky.\n\nBroadcasting the transactions would not need to be done, since miners fetch\nthem from their storage place, alternatively we could use the inv broadcast\nto notify peers about a new block/transaction and let it retrieve them from\nthe permanent storage (DHT or block storage network). If we route traffic\ninternally in the DHT we could even start caching at nodes leading to the\nreal location, since announcements would lead to flashcrowds, putting heavy\nload on the responsible nodes. Caching is not a risk since the hash of the\nobject to be retrieved is already known.\n\nRegards,\nChris\n\nOn Wed, Dec 21, 2011 at 1:41 PM, Michael Grønager \u003cgronager at ceptacle.com\u003ewrote:\n\n\u003e I find it likely that we will at some point have supernodes. If we have\n\u003e browser based wallets then the server for these automatically becomes\n\u003e supernodes. Further, if we move along that direction, it becomes much\n\u003e simpler to use both the scheme I proposed or to use a a lot of other\n\u003e schemes for sharing the validation work on a farm constituting the\n\u003e supernode.\n\u003e\n\u003e However, if we want to keep bitcoin in a real p2p setup and enable\n\u003e scalability in terms of ensuring both thin and fat client to connect then\n\u003e we need to go along the path I propose.\n\u003e\n\u003e Actually, after thinking a bit more about the possible new attack vector I\n\u003e don't find it that alarming - if you still require 7 confirmations of any\n\u003e bigger transaction before you, as receiver accepts the transaction as payed\n\u003e you will not risk anything. The question is then if it is sufficiently easy\n\u003e to fake small transaction to e.g. gain access to micropayment based web\n\u003e services. I would again say no - the requirement that you have ok from e.g.\n\u003e 8 different A.B nodes will make it extremely difficult to cheat, and that\n\u003e would even require you to gain some level of control over the network that\n\u003e the service you want to cheat is connected through.\n\u003e\n\u003e This means that you should not divide the hash space more finely than you\n\u003e would at all times be able to find 8 different A.B nodes. As the number of\n\u003e clients grows you can then divide the hash space further. (with 100000\n\u003e nodes today and a division into 512 parts you would have approx 200 nodes\n\u003e to choose from).\n\u003e\n\u003e Cheers,\n\u003e\n\u003e M\n\u003e\n\u003e\n\u003e\n\u003e On 21/12/2011, at 12:42, Eric Lombrozo wrote:\n\u003e\n\u003e \u003e Is it just me or does it seem inevitable that at some point supernodes\n\u003e \u003e will emerge that other nodes trust to validate transactions for them?\n\u003e \u003e Supernodes needn't even store the entire block chain and transaction\n\u003e \u003e pool...it would be sufficient that they keep lists of IP addresses of\n\u003e \u003e other trustworthy nodes and partition them into a hashspace.\n\u003e \u003e\n\u003e \u003e Anonymous peers have no reputation to defend...but a trusted supernode\n\u003e \u003e would, which could provide just enough incentive for the supernode to\n\u003e \u003e do its best to ensure the nodes it vouches for are indeed legit. Of\n\u003e \u003e course, unless the supernode is validating the entire block chain and\n\u003e \u003e transaction pool itself, it could only assess the trustworthiness of\n\u003e \u003e other nodes by performing random sampling.\n\u003e \u003e\n\u003e \u003e Michael, I really like your ideas and the clarity you bring to the\n\u003e \u003e issue. Regarding the potential attack vector you mention, would it be\n\u003e \u003e possible to partition the hashspace to minimize the risk that an\n\u003e \u003e attacker can manage to disproportionately gain control over a part of\n\u003e \u003e the hashspace?\n\u003e \u003e\n\u003e \u003e\n\u003e ------------------------------------------------------------------------------\n\u003e \u003e Write once. Port to many.\n\u003e \u003e Get the SDK and tools to simplify cross-platform app development. Create\n\u003e \u003e new or port existing apps to sell to consumers worldwide. Explore the\n\u003e \u003e Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join\n\u003e \u003e http://p.sf.net/sfu/intel-appdev\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\n\u003e ------------------------------------------------------------------------------\n\u003e Write once. Port to many.\n\u003e Get the SDK and tools to simplify cross-platform app development. Create\n\u003e new or port existing apps to sell to consumers worldwide. Explore the\n\u003e Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join\n\u003e http://p.sf.net/sfu/intel-appdev\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/20111221/c8347296/attachment.html\u003e"}