Hi forrestv,
There is a lot of interest in partial confirmations of transactions and p2pool has been proposed as a reasonable solution (see
here). Specifically, the p2pool sharechain could guarantee that it will include a given txn in its next block (barring a conflicting transaction sneaking into the blockchain). Could you please comment on the feasibility of implementing such functionality into p2pool? What about the benefit? Does p2pool guaranteeing the inclusion of a txn provide any real benefit over sending your txn to the network and waiting for the majority of nodes to get it?
Thanks!
Are you talking about something like regular unconfirmed transactions floating around the bitcoin network, waiting for inclusion into the next block?
So you would like to have p2pool say "we got this tx, will include it soon!"?
I don't see the advantage..
You can already see these [bitcoin] tx in your bitcoind (no idea if possible in a stock bitcoind) or on one of the pages, blockexplorer or the like. android bitcoin wallet shows tx too.
Now, seeing that tx there, or having additionally p2pool say to include it, makes no difference: as soon as someone else creates a conflicting tx, like a doublespend, and his tx gets included into the chain first (higher fees, quicker propagation, luck, he mined the next block himself), your original tx is down the toilet anyway.
p2pool is relatively small, so even if p2pool says "yep, will include your tx" as well as "..and we'll drop any future conflicting tx", it would only work if no other pool/miner finds the next block first and includes the unwanted conflicting tx.
So, what is your aim?
Ente
Thank you for the comments. First a small aside: regarding a competing tx getting into the blockchain before the first due to a higher tx fee, I don't believe this is the case. Ie if you broadcast send 10BTC from A->B with .005BTC fee and, 10 mins later, broadcast a tx from A->C with 1btc fee, I believe the latter is rejected. Otherwise I believe "race attacks" (is that the right name?) would be stupendously easy to implement.
I believe the hope is to reduce the trust you need in a pool that they will include your txn. If a centralized pool says, "yep, we got tx0, we're working on it!" you have to trust them. OTOH, if p2pool says, "consensus agrees that we got tx0, and the sharechain now requires we included it (if it matches eligibility criteria)!" you can believe this more likely to be true. Is this wrong?
Finally, AFAIK, you are correct about this doing nothing for many double spending attacks. Perhaps the benefit doesn't outweigh the cost.
This would centralize control of p2pool, and would destroy it. People mine on p2pool because it allows them to control the blocks that they create. We will reject any proposal to force us to include transactions that do not meet our own local policy.
Sorry I wasn't clear enough. This additionally functionality, as I interpret it, would allow a p2pool node to check the sharechain to see if a tx is going to be included or not, and know with certainty that if p2pool finds the next block, it WILL be included (if another pool finds the next block with a competing tx, then obviously all bets are off). If a tx doesn't meet p2pool criteria, it won't be added to the "include list" and it's inclusion won't be forced on p2pool by any means.
