{"type":"rich","version":"1.0","author_name":"npub1ac86vemj7ce5z8jyxt39rna3tvwql6xd30ha3vxcd6esysp23d9qrlswfj","author_url":"https://nostr.ae/npub1ac86vemj7ce5z8jyxt39rna3tvwql6xd30ha3vxcd6esysp23d9qrlswfj","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-12-14\n📝 Original message:I think someone, maybe Pieter, commented on this relay issue that it\nwould be likely very transitory, as a lot of stuff would be fairly\nquickly upgraded in practice from previous deployment experience, and\nI think anyway there is a huge excess connectivity and capacity in the\np2p network vs having a connected network of various versions, and\nsupporting SPV client load (SPV load is quite low relative to\ncapacity, even one respectable node can support a large number of SPV\nclients).\n\n(Ie so two classes of network node and connectivity wouldnt be a\nproblem in practice even if it did persist; also the higher capacity\nbetter run nodes are more likely to upgrade due to having more clued\nin power user, miner, pool or company operators).\n\nMaybe someone more detailed knowledge could clarify further.\n\nAdam\n\nOn 14 December 2015 at 19:21, Jonathan Toomim via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e This means that a server supporting SW might only hear of the tx data and\n\u003e not get the signature data for some transactions, depending on how the relay\n\u003e rules worked (e.g. if the SW peers had higher minrelaytxfee settings than\n\u003e the legacy peers). This would complicate fast block relay code like IBLTs,\n\u003e since we now have to check to see that the recipient has both the tx data\n\u003e and the witness/sig data.\n\u003e\n\u003e The same issue might happen with block relay if we do SW as a soft fork. A\n\u003e SW node might see a block inv from a legacy node first, and might start\n\u003e downloading the block from that node. This block would then be marked as\n\u003e in-flight, and the witness data might not get downloaded. This shouldn't be\n\u003e too hard to fix by creating an inv for the witness data as a separate\n\u003e object, so that a node could download the block from e.g. Peer 1 and the\n\u003e segwit data from Peer 2.\n\u003e\n\u003e Of course, the code would be simpler if we did this as a hard fork and we\n\u003e could rely on everyone on the segwit fork supporting the segwit data.\n\u003e Although maybe we want to write the interfaces in a way that supports some\n\u003e nodes not downloading the segwit data anyway, just because not every node\n\u003e will want that data.\n\u003e\n\u003e I haven't had time to read sipa's code yet. I apologize for talking out of a\n\u003e position of ignorance. For anyone who has, do you feel like sharing how it\n\u003e deals with these network relay issues?\n\u003e\n\u003e By the way, since this thread is really about SegWit and not about any other\n\u003e mechanism for increasing Bitcoin capacity, perhaps we should rename it\n\u003e accordingly?\n\u003e\n\u003e\n\u003e On Dec 12, 2015, at 11:18 PM, Mark Friedenbach via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e A segwit supporting server would be required to support relaying segwit\n\u003e transactions, although a non-segwit server could at least inform a wallet of\n\u003e segwit txns observed, even if it doesn't relay all information necessary to\n\u003e validate.\n\u003e\n\u003e Non segwit servers and wallets would continue operations as if nothing had\n\u003e occurred.\n\u003e\n\u003e If this means essentially that a soft fork deployment of SegWit will require\n\u003e SPV wallet servers to change their logic (or risk not being able to send\n\u003e payments) then it does seem to me that a hard fork to deploy this non\n\u003e controversial change is not only cleaner (on the data structure side) but\n\u003e safer in terms of the potential to affect the user experience.\n\u003e\n\u003e\n\u003e — Regards,\n\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e"}