|
Title: [request] MEMpool information broadcast by Bitcoin Core. Post by: Meuh6879 on December 30, 2017, 12:13:49 PM Hello,
I have a request for the developpers of Bitcoin Core : can you add a broadcasted information of all proximity nodes connected to my Bitcoin Core ... that include the MEMpool (Mb & Number of transaction) ? It permit to build algorythm for calculate fees on SPV wallet and Full node. Not based on block creation included fees. SPV wallet can access to this information when they retrieve merkel trees (instead of use the block included fees) because they are connected to full or puned node that are, in majority, Bitcoin Core base. Thanks. 8) Title: Re: [request] MEMpool information broadcast by Bitcoin Core. Post by: DooMAD on December 31, 2017, 03:54:24 PM I'm not sure if it's the way you've worded it, but it sounds wasteful in the amount of information that would be duplicated. If your node sends out a list of mempools from all the nodes connected to you, while all the other nodes are doing the same, surely that's fair amount of information to broadcast and much of it would be repeated unnecessarily. Also, how often is this broadcast sent? I was under the impression that non-mining full nodes were under enough heavy burden of bandwidth requirements as it is already?
Title: Re: [request] MEMpool information broadcast by Bitcoin Core. Post by: Anti-Cen on December 31, 2017, 08:24:55 PM heavy burden of bandwidth requirements as it is already? Well if they are breaking into a sweat just doing 7 transactions a second between 20,000 nodes then whats going to happen if Joe public ever arrives en-mass on BTC ? You don't suppose that something is a little bit wrong with the design do you ::) Title: Re: [request] MEMpool information broadcast by Bitcoin Core. Post by: Meuh6879 on December 31, 2017, 11:47:21 PM If your node sends out a list of mempools from all the nodes connected to you, while all the other nodes are doing the same, surely that's fair amount of information to broadcast and much of it would be repeated unnecessarily. If node send MEMpool stats (size, number of transactions), the listener can use the 8-25 connexions to build an average size & number of transactions. With this, it can recalculate the fees if MEMpool is satured (Blockchain.info store 2Gb ... but malority of nodes store 300Mb, right ?). An SPV wallet can use this average info with her 4-6 connexions. Title: Re: [request] MEMpool information broadcast by Bitcoin Core. Post by: DooMAD on January 01, 2018, 12:13:45 PM If your node sends out a list of mempools from all the nodes connected to you, while all the other nodes are doing the same, surely that's fair amount of information to broadcast and much of it would be repeated unnecessarily. If node send MEMpool stats (size, number of transactions), the listener can use the 8-25 connexions to build an average size & number of transactions. With this, it can recalculate the fees if MEMpool is satured (Blockchain.info store 2Gb ... but malority of nodes store 300Mb, right ?). An SPV wallet can use this average info with her 4-6 connexions. Okay, so each node would only send its own mempool, not a combined list of the mempools from all the nodes connected to it? That would be more efficient and would probably make refreshing the details and having to rebroadcast them again trivial in terms of resource consumption. However, it seems there are still some limitations (https://bitcointechtalk.com/an-introduction-to-bitcoin-core-fee-estimation-27920880ad0), even if sourcing from multiple mempools: Quote Fee Estimation based on current mempool A naive fee estimation algorithm would look at your mempool and set your transaction fee at a level that puts it in the highest-paying 2MB of transactions. You might expect that strategy to get your transaction confirmed in the next block. Unfortunately, it’s not quite as simple as that for a number of reasons: Very recent transactions may not make it into the next block. Miners are already working on the next block when you submit your transaction. Depending on how they refresh the block as they work on it, they may not include your transaction. Whatever time you send your transaction into the mempool, the expected time you’ll have to wait for the next block is 10 minutes. This is a fundamental (and often misunderstood) property of the Poisson distribution that block discovery follows. If you place your transaction into the mempool 8 minutes after the previous block, the expected time you’ll need to wait isn’t 2 minutes — it’s another 10 minutes. Therefore you’re not just competing against what’s in the mempool now, you’re competing against what’s going to appear in the mempool over the next (probably) 10 minutes. Looking at a snapshot of the mempool doesn’t take into account the fact that there will be lucky runs of blocks and slow runs of blocks in the future. It might give you some information about how much fee you need for your transaction to be included in the next block or two, but can’t tell you anything about how much fee you need if you want your transaction included in the next 100 or 200 blocks. There's always going to be some guesswork involved, as the goalposts are constantly moving. Title: Re: [request] MEMpool information broadcast by Bitcoin Core. Post by: achow101 on January 01, 2018, 08:40:02 PM Well if they are breaking into a sweat just doing 7 transactions a second between 20,000 nodes No, they're not. It isn't 7 unconfirmed transactions per second that are being broadcast between nodes. That number has to do with blocks. Nodes are handling much larger numbers than that in unconfirmed transactions.If node send MEMpool stats (size, number of transactions), the listener can use the 8-25 connexions to build an average size & number of transactions. You can use the mempool message to get a list of all of the txids in a node's mempool.With this, it can recalculate the fees if MEMpool is satured (Blockchain.info store 2Gb ... but malority of nodes store 300Mb, right ?). An SPV wallet can use this average info with her 4-6 connexions. It is unlikely that a new protocol message will be created which contains just statistical information. |