rich1.0npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2njumphttps://nostr.ae📅 Original date posted:2015-06-17 📝 Original message:On Mon, Jun 15, 2015 at 09:00:19PM -0700, Aaron Voisine wrote: > Thanks Alex, the work you've pointed out is helpful. Limiting mempool size > should at least prevent nodes from crashing. When I looked a few days ago I > only found a few old PRs that seemed to have fallen by the wayside, so this > new one is encouraging. BTW it's worth working out how many $ in fees you need for a given amount of MB worth of mempool. At the current 10uBTC/KB minimim relay fee 1MB of txs requires just $2.5 worth of fees - kinda ridiculous when a block earns a miner $6250 in revenue. Pretty much all txs pay significantly higher rates - more like 100uBTC/KB, or $25/MB. At that rate the 288MB max mempool size proposed by Patrick Strateman's pull-req requires at least $7.2k worth of BTC to fill to pay the fees, and in practice will probably quickly get higher. https://github.com/bitcoin/bitcoin/pull/6281 > I can respond in the PR comments if it's more appropriate there, but I > believe ejecting tx from mempools rather than preemptively refusing them > according to standard network wide propagation rules will result in spotty, > inconsistent tx propagation, and possibly a large increase in tx > re-broadcasts, so if those haven't been addressed they will need to be. It > would also be prudent to run some simulations to see what other issues are > going to pop-up. See above - filling the mempool like that will be both a slow process, and require lots of funds. Equally, once full, the sensible thing to do is raise the minimum relay fee appropriately, so those transactions that pay too low a fee will simply be rejected. It'd be reasonable to tell peers that, and what the minimum fee needed for acceptance would be for that particular node. > We're currently using CPFP already in breadwallet when spending unconfirmed > non-change inputs. A small percentage of hashing power is using it, but > enough to get a transaction unstuck assuming breadwallet's fee calculation > is better than the sender's. > The problem with RBF is that there's currently no way to tell if your tx > has been picked up by miners or not in order to know if you need to replace > it. Miners broadcasting partial block solutions would be helpful in this > regard, but only for tx in the currently-being-worked-on block, not for tx > that won't be picked up until the block after. If miners were to eject tx > that were previously being worked on in favor of higher fee tx, then that > causes another set of problems for wallets that thought their tx was going > to get in but then it doesn't. The other problem with RBF is that users > don't know up front what fee they're actually going to pay which is a big > blow to real world usability. Also mobile wallets will have to sign lots of > tx up front and rely on a service to replace as necessary. And this is all > just on the send side. For an interactive, mobile wallet, the best thing to do is estimate the fee correctly the first time, using RBF as a follow up mechanism only if needed. For other users - e.g. exchanges handling customer withdrawals - using RBF more agressively to get the minimum possible fee may make sense. > On the receive side it's much worse since you can't > rely on the sender to do the replacing. The real problem seems to be the > fact that RBF is an interactive iterative process rather than a > send-and-forget one. In any case, the *existance* of RBF makes no difference to any of these problems; RBF does make solving the easier. You can always choose to not use it after all, resulting in the same "send-and-forget" process. Having it available allows mistakes to be fixed after the fact, always an improved user experience over not being able to re-bid for block space. Incidentally, if my FSS-RBF bug bounty isn't collected in the next week or two, we'll likely have a major double-digits % of hashing power mining FSS-RBF soon after. http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08122.html > What you really need is some way to tell up-front, is a transaction going > to get mined with a high probability? That problem seems really difficult > to solve with fixed-size blocks that are full. Have you looked at the fee estimation code in Bitcoin Core? I have no reason to think it doesn't basically speaking work. Of course, SPV wallets will need a semi-trusted third party to securely get that data, but this seems to be a fundemental problem in a decentralized network - the purpose of the blockchain itself is to prove that some data was published to some audience, an analogous problem to proving to the SPV wallet that their transaction actually reached miners and they actually are considering it for inclusion. Guaranteed reliable transaction processing is only possible in centralized environments that can make service guarantees. > If the goal is simply to > reduce or limit the growth of the blockchain, then there are much simpler > solutions, which is why I've advocated for the blocksize increase, followed > by tx selection and propagation rule changes to create fee pressure. Few if any of those mechanisms can be deployed in a consensus-critical way that is resistant to attack; the blocksize limit is needed to - among other things - resist attacks by one miner on another to reduce the competitors profitability. Without an explicit limit tx selection and propagation rule changes can be gamed. -- 'peter'[:-1]@petertodd.org 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 650 bytes Desc: Digital signature URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150617/46d63a0f/attachment.sig>