Bitcoin Forum
September 18, 2018, 02:36:49 PM *
News: Latest stable version of Bitcoin Core: 0.16.2  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: [request] MEMpool information broadcast by Bitcoin Core.  (Read 64 times)
Meuh6879
Legendary
*
Offline Offline

Activity: 1512
Merit: 1000



View Profile
December 30, 2017, 12:13:49 PM
 #1

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.  Cool
1537281409
Hero Member
*
Offline Offline

Posts: 1537281409

View Profile Personal Message (Offline)

Ignore
1537281409
Reply with quote  #2

1537281409
Report to moderator
1537281409
Hero Member
*
Offline Offline

Posts: 1537281409

View Profile Personal Message (Offline)

Ignore
1537281409
Reply with quote  #2

1537281409
Report to moderator
1537281409
Hero Member
*
Offline Offline

Posts: 1537281409

View Profile Personal Message (Offline)

Ignore
1537281409
Reply with quote  #2

1537281409
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1537281409
Hero Member
*
Offline Offline

Posts: 1537281409

View Profile Personal Message (Offline)

Ignore
1537281409
Reply with quote  #2

1537281409
Report to moderator
DooMAD
Legendary
*
Offline Offline

Activity: 1736
Merit: 1143


Leave no FUD unchallenged


View Profile WWW
December 31, 2017, 03:54:24 PM
 #2

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?

Anti-Cen
Member
**
Offline Offline

Activity: 196
Merit: 25

High fees = low BTC price


View Profile
December 31, 2017, 08:24:55 PM
 #3

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  Roll Eyes


Mining is CPU-wars and Intel, AMD like it nearly as much as big oil likes miners wasting electricity. Is this what mankind has come too.
Meuh6879
Legendary
*
Offline Offline

Activity: 1512
Merit: 1000



View Profile
December 31, 2017, 11:47:21 PM
 #4

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.
DooMAD
Legendary
*
Offline Offline

Activity: 1736
Merit: 1143


Leave no FUD unchallenged


View Profile WWW
January 01, 2018, 12:13:45 PM
 #5

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, 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.

achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 1526
Merit: 1624


3F1Y9yquzvY6RWvKbw2n2zeo9V5mvBhADU


View Profile WWW
January 01, 2018, 08:40:02 PM
 #6

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.

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.
You can use the mempool message to get a list of all of the txids in a node's mempool.

It is unlikely that a new protocol message will be created which contains just statistical information.

Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!