{"type":"rich","version":"1.0","author_name":"npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","author_url":"https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2013-12-01\n📝 Original message:Lately I was pondering how to make floating fees and SPV wallets work well\ntogether.\n\nI propose the following plan:\n\n1) 0.9 ships with something dead simple, like a command to query what a\nnode estimates and then clients just take the average, or cross-check a\ncentralised estimate against the P2P network. It's fast to implement and\nsimple, but not very secure or decentralised. However it will allow the\nfeature to launch on some kind of reasonable timeframe.\n\n2) We bump the protocol version and the tx message now gets an optional\nprotobuf buffer stuck on the end. The first thing put in this protobuf is a\nlist of the values of the inputs. Using this data, the fee paid by a\ntransaction can be calculated. In step 2 the data is unauthenticated.\n\n3) Some SPV wallets already set themselves up so that they sync with the\nnetwork in the background, e.g. the Android wallet syncs at least every 24\nhours. This should become more common, using scheduler capabilities built\ninto most operating systems. When the wallet syncs with the network, it\nsets a deliberately very noisy Bloom filter on its peers and waits around\nfor 30-60 seconds or so. The wallet observes some of the broadcasts taking\nplace and records the hashes and associated fees that were paid to disk.\nNext time it syncs, it includes the observed hashes into the Bloom filter\nused to download the chain, and thus learns how quickly they confirmed. It\ncan calculate its own fee estimate from that.\n\n4) Finally, when we next hard fork, we make v2 transactions include the\noutput value in the signature, same as the output script (this proposal has\nbeen on the forums for a while now). That allows the fee data added in step\n2 to be cross-checked against the signatures on the inputs, thus\nauthenticating it.\n\n\nI think this is a small and easy set of steps that would make it quite hard\nto attack - malicious nodes could make it appear that some transactions\nnever confirmed thus seeming to force the price up, but it's easy to simply\nexclude transactions which never confirm at all from the calculations. Plus\nof course you can cross-check nodes against each other to try and catch\nnodes that are failing to match transactions properly.\n\nOne obvious concern is what to do if nodes don't converge on very similar\nestimates. Wallets will always want to pay the lowest fee possible, so that\nmeans they'll always be riding the very edge of what's acceptable, opening\nup tx propagation to random flaky failures if fee estimates change whilst a\ntransaction is in progress, or if some nodes don't calculate the same\nestimates as others.\n\nIf a wallet gets a reject message for a tx that has a fee that are by its\nown estimates acceptable, what should it do? What if only some nodes report\nthat and others don't?\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131201/d06702fb/attachment.html\u003e"}