{"type":"rich","version":"1.0","author_name":"npub15fmnxm546tg2sv0l7elusrvqsgezdzdg3m0flpml5fr2qf3f5slskxlq6h","author_url":"https://nostr.ae/npub15fmnxm546tg2sv0l7elusrvqsgezdzdg3m0flpml5fr2qf3f5slskxlq6h","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2011-12-21\n🗒️ Summary of this message: Supernodes may emerge for validating transactions, but to maintain a real peer-to-peer setup and enable scalability, a proposed path should be followed. The risk of a new attack vector is not alarming, and it would be difficult to cheat with the proposed scheme. The hash space should not be divided more finely than the ability to find eight different nodes at all times.\n📝 Original message:I find it likely that we will at some point have supernodes. If we have browser based wallets then the server for these automatically becomes supernodes. Further, if we move along that direction, it becomes much simpler to use both the scheme I proposed or to use a a lot of other schemes for sharing the validation work on a farm constituting the supernode.\n\nHowever, if we want to keep bitcoin in a real p2p setup and enable scalability in terms of ensuring both thin and fat client to connect then we need to go along the path I propose.\n\nActually, after thinking a bit more about the possible new attack vector I don't find it that alarming - if you still require 7 confirmations of any bigger transaction before you, as receiver accepts the transaction as payed you will not risk anything. The question is then if it is sufficiently easy to fake small transaction to e.g. gain access to micropayment based web services. I would again say no - the requirement that you have ok from e.g. 8 different A.B nodes will make it extremely difficult to cheat, and that would even require you to gain some level of control over the network that the service you want to cheat is connected through.\n\nThis means that you should not divide the hash space more finely than you would at all times be able to find 8 different A.B nodes. As the number of clients grows you can then divide the hash space further. (with 100000 nodes today and a division into 512 parts you would have approx 200 nodes to choose from).\n\nCheers,\n\nM\n\n\n\nOn 21/12/2011, at 12:42, Eric Lombrozo wrote:\n\n\u003e Is it just me or does it seem inevitable that at some point supernodes\n\u003e will emerge that other nodes trust to validate transactions for them?\n\u003e Supernodes needn't even store the entire block chain and transaction\n\u003e pool...it would be sufficient that they keep lists of IP addresses of\n\u003e other trustworthy nodes and partition them into a hashspace.\n\u003e \n\u003e Anonymous peers have no reputation to defend...but a trusted supernode\n\u003e would, which could provide just enough incentive for the supernode to\n\u003e do its best to ensure the nodes it vouches for are indeed legit. Of\n\u003e course, unless the supernode is validating the entire block chain and\n\u003e transaction pool itself, it could only assess the trustworthiness of\n\u003e other nodes by performing random sampling.\n\u003e \n\u003e Michael, I really like your ideas and the clarity you bring to the\n\u003e issue. Regarding the potential attack vector you mention, would it be\n\u003e possible to partition the hashspace to minimize the risk that an\n\u003e attacker can manage to disproportionately gain control over a part of\n\u003e the hashspace?\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"}