BIP Draft - Instant Partial Confirmation

[casascius]

I wanted to throw out a draft proposal titled Instant Partial Confirmation, and solicit comments.

https://en.bitcoin.it/wiki/BIP_Draft_-_Instant_Partial_Confirmation

This (draft) BIP proposes a scheme to enable parties to a transaction to receive a reliable confirmation of their transaction from miners in a deterministic predictable timeframe, and compensates miners financially for providing this service.

With the service described by this (draft) BIP, instead of waiting an average of 10 minutes for 1 confirmation, a transactor could potentially receive 0.51 or more confirmations within 10 seconds of issuing it (representing 51% of the mining power on the network), and have a much higher level of confidence that the transaction will be confirmed as compared to a zero-confirmation transaction.

VERY BRIEF SUMMARY:

It describes miners putting "calling cards" (IP:PORTs) in their coinbases.  Connection to the miners is done via UDP datagrams, not TCP.

Transactors interested in instant partial confirmations must pay an elevated market-based transaction fee in order to receive the service.  These transaction fees are paid the same way transaction fees are paid today - awarded to any miner who includes the transaction in a block.  They are not payments/outputs payable to any individual miner.

Assuming their fee is high enough, the sender and receiver of the funds is welcome to blast out UDP packets to all miners within the last 2016 blocks, asking them to confirm the transaction.  The miners may send back a confirmation that the transaction was not a doublespend.  That confirmation is considered a "partial confirmation".

The partial confirmations are informal but signed, typically by coinbase keys.  They are also returned via UDP.  Clients can figure out how much of the hashing power each partial confirmation represents - for example, if a partial confirmation can be determined to come from the same miner who mined 20% of the last 2016 blocks, the transaction essentially has 0.2 confirmations.

tl;dr: The core benefit is it provides a solution for those who want higher confidence in zero-confirmation transactions, as well as providing an opportunity to raise transaction fee revenue for the mining community as a whole.

[1713980723]

1713980723

[1713980723]

1713980723

[1713980723]

1713980723

[Revalin]

Related: https://bitcointalk.org/index.php?topic=62137.0;all

tl;dr: instead of trying to connect to every miner everywhere, you simply send your transaction over the network with a generous fee.  Miners include a pubkey with each block, and if they consider your fee sufficient, they use that key to pre-confirm your transaction, and flood that signature.  Pro: simpler and faster; con: more p2p traffic.

[notme]

Couldn't the attacker just wait 10 seconds to send the other transaction that double spends.  Is there a way for miners to revoke their confirmation?

[casascius]

Related: https://bitcointalk.org/index.php?topic=62137.0;all

tl;dr: instead of trying to connect to every miner everywhere, you simply send your transaction over the network with a generous fee.  Miners include a pubkey with each block, and if they consider your fee sufficient, they use that key to pre-confirm your transaction, and flood that signature.  Pro: simpler and faster; con: more p2p traffic.

By sending your transaction directly to the miners, you can typically have a response in under 1 second.  Time is of the essence, and UDP traffic is tiny, as fast as a ping, and well suited to being blasted to a thousand simultaneous peers, some of whom might not be listening or available.  There is no sense in burdening the P2P bandwidth (a limited resource) on a wide-open internet when the message can be communicated directly and quickly via UDP.  Peers sending direct UDP messages to other peers is still peer-to-peer!

EDIT: This would also rip to shreds Microsoft's silly whitepaper assertion that Bitcoin will "fail" when peers stop relaying traffic due to lack of incentive.  Blast your traffic to thousands of miners yourself, and never worry that "no one" will hear your transaction due to greedy relays wanting your fee for themselves.

[mb300sd]

Couldn't the attacker just wait 10 seconds to send the other transaction that double spends.  Is there a way for miners to revoke their confirmation?

I believe that bitcoind will not accept a conflicting transaction into its memory pool, so once the first reaches a miner, the double spend will not replace it.

[notme]

Oh, duh.  Thanks guys.

[nibor]

Obviously you have to be careful with how much faith you put in the results.

Even if you got confirmation from 100% of the miners who mined the last 2016 blocks, you are still vulnerable to a Finney attack where the block has already been mined by someone else.

Also you are still vulnerable to corrupt mining pools who say one thing and do another!

Would be interesting to know SatoshiDice input on this as they are the more experienced by factors of 1000's than anyone else with the issue.

But as you say it increases the size of transaction that is safe to accept based on zeros confirms.

[Sergio_Demian_Lerner]

It's very interesting, though I have several questions:

Issue 1:

In your BIP you say: "CONFIRMED: The miner considers the transaction valid and commits to include it in the next block. "

How miners are forced to include such transaction? What happens if they don't ?

Issue 2:

What happens in this situation:

- A transaction has two receivers (outpoints) user1 and user2.
- Two transaction (a double-spend) are publishes t1 and t2 (both with very high fees)
- User1 asks the miners to sign the pre-confirmation or t1. All miners send confirmation of t1.
- User2 asks the miners to sign the pre-confirmation or t2. All miners send confirmation of t2, thus violating the commitment on t1.

Miners will always win, since they can choose t1 or t2, an always get a high fee, so they have no incentive to help either User1 or User2.

To avoid this situation, the protocol could me modified in this way:

- User B wants partial confirmations on transaction t1 (from A to B). The first output (B.output[0]) is the one that goes to himself.

- The user B creates a new transaction tn with a single input t1.outpoint[0] that pays a high fee and sends the change to a B back again (one input, two outputs).

- B sends this transaction to all miners directly by UDP. This transaction will ONLY be valid if t1 is published, since t1.outpoint[0] is only available in that scenario. Transaction tn cannot be send via the p2p network since it has an unconfirmed input.

Now miners do have an incentive to include t1. If they do so, they also receive the fees for transaction tn.

Was the explanation clear?

Issue 3:

In your BIP you say: "...The message shall contain the entire transaction to be partially confirmed, a return path (IP and UDP port) for the response, and proof that the requester is a party to the transaction. ".

But this way you could specify a IP/Port different than yours. It would be preferable to send the response to the same IP where the UDP packet has came.


Good work casascius and best regards,
 Sergio.

[jgarzik]

EDIT: This would also rip to shreds Microsoft's silly whitepaper assertion that Bitcoin will "fail" when peers stop relaying traffic due to lack of incentive.  Blast your traffic to thousands of miners yourself, and never worry that "no one" will hear your transaction due to greedy relays wanting your fee for themselves.

(emphasis mine)

Relaying nodes do not receive any fees for relaying.  And there are more than sufficient nodes on the network to prevent an attacker or miner from preventing a transaction from being relayed to others in 99% of the cases.

[gmaxwell]

It describes miners putting "calling cards" (IP:PORTs) in their coinbases.  Connection to the miners is done via UDP datagrams, not TCP.

This appears to have scalability and security problems. From a scalability perspective unless mining is highly centralized you must communicate with many parties or process many signatures.  From a security perspective a miner signing saying they'll mine a transaction doesn't actually prove that they're even trying to do so or force them to continue trying (e.g. if a higher fee comes along).

Instead, I point out that P2Pool's sharechain approach already solves this.  Right now the included txn in p2pool shares can change freely, but in order to enable 10 second soft confirmations it would be perfectly possible for p2pool (or a similar system) to commit to some transactions (e.g. ones with sufficient fees) which can't be removed without making their shares get ignored.

This has the property that the proof of confirmation is actually also proof of really trying... and it doesn't have the same scale problem in the case of decenteralized miners where there are many possible ones. It could be done by existing pools for the pure confirmation purpose but there would be no incentive to participate other than providing faster confirmations and then defection is easy. When the shares are used for payout, however, there is a good incentive not to defect.

Although with finny attacks being cheap thanks to gpumax and getting cheaper, I don't know that any of this matters: One confirmation isn't enough for most things where zero isn't enough.

[casascius]

It's very interesting, though I have several questions:

Issue 1:

In your BIP you say: "CONFIRMED: The miner considers the transaction valid and commits to include it in the next block. "

How miners are forced to include such transaction? What happens if they don't ?

They're not, the same way nothing forces them to include transactions in blocks at all yet most do it anyway.  Practically, most miners aren't going to go out of their way to disrupt the integrity of the network.  By and large, there is no benefit to doing so.

Issue 2:

What happens in this situation:

- A transaction has two receivers (outpoints) user1 and user2.
- Two transaction (a double-spend) are publishes t1 and t2 (both with very high fees)
- User1 asks the miners to sign the pre-confirmation or t1. All miners send confirmation of t1.
- User2 asks the miners to sign the pre-confirmation or t2. All miners send confirmation of t2, thus violating the commitment on t1.

Miners will always win, since they can choose t1 or t2, an always get a high fee, so they have no incentive to help either User1 or User2.

Per the proposal, step 4 won't happen at the hands of the honest majority of miners.  They will not confirm T2 if they have already seen T1.  Most of them will send a REJECT message alerting the client to a likely double spend.

If transactions are sent at the same time, some will confirm t1 and others will confirm t2.  However, both will never simultaneously have a majority, and the flood of REJECT messages (which ought to be counted as "negative confirmations") will definitely make the transaction stand out.

Issue 3:

In your BIP you say: "...The message shall contain the entire transaction to be partially confirmed, a return path (IP and UDP port) for the response, and proof that the requester is a party to the transaction. ".

But this way you could specify a IP/Port different than yours. It would be preferable to send the response to the same IP where the UDP packet has came.

Sure, of course - the same way I could order a magazine subscription, but put my neighbor's address as the delivery address, and then I will never get what I paid for.  But I have no rational incentive to do so.

Whether IP/Port should be included is up for discussion.  It may very well be that the most sensible solution is to reply to the source address and port contained in the datagram, so that the reply won't have any trouble traversing NAT etc.

[Gavin Andresen]

Although with finny attacks being cheap thanks to gpumax and getting cheaper, I don't know that any of this matters: One confirmation isn't enough for most things where zero isn't enough.

+1

+1 to Sergio's points, too.  Casascius: I think you need to think more like an attacker; if they can cheaply mount an attack, then they will.

[casascius]

It describes miners putting "calling cards" (IP:PORTs) in their coinbases.  Connection to the miners is done via UDP datagrams, not TCP.

This appears to have scalability and security problems. From a scalability perspective unless mining is highly centralized you must communicate with many parties or process many signatures.  From a security perspective a miner signing saying they'll mine a transaction doesn't actually prove that they're even trying to do so or force them to continue trying (e.g. if a higher fee comes along).

In each case, you must communicate with up to 2016 parties via a datagram, independent of the network size or transaction volume.  Datagrams are small and cheap.  You could blow out 2016 2kb datagrams at the same resource cost as blowing out a 4-megabyte jpeg to facebook.

Whenever there are far more than 2016 miners, you're still likely to get a statistically meaningful representative sample of the active miners out there.  More resolution offers little practical benefit (n/2016 is already accurate to 3 decimal places, what would somebody do with more?)

Indeed, one might need to process up to 2016 signatures to have full confidence in the results.  But if you're a retail POS terminal with a single user and an idle CPU 99% of the time, this shouldn't be a big problem.

Instead, I point out that P2Pool's sharechain approach already solves this.  Right now the included txn in p2pool shares can change freely, but in order to enable 10 second soft confirmations it would be perfectly possible for p2pool (or a similar system) to commit to some transactions (e.g. ones with sufficient fees) which can't be removed without making their shares get ignored.

This has the property that the proof of confirmation is actually also proof of really trying...

Just so I understand, how does p2pool collectively commit to anything?  Include the commitment in a sharechain block?

What about traditional centralized mining pools?  I agree that having proof of trying is a desirable benefit.

Although with finny attacks being cheap thanks to gpumax and getting cheaper, I don't know that any of this matters: One confirmation isn't enough for most things where zero isn't enough.

Unrelated, a calling card scheme might allow the miners to detect Finney attacks and coordinate the rejection of the block containing it.

As an example, upon receiving a block that invalidates a confirmation, an IPC-participating miner could broadcast a message to the other (up to) 2016 miners saying "Hey! I don't like block X because it forces me to fail on a commitment, and I propose attacking it."  If the majority of miners send that message, they could follow it up with another message: "It looks to me like a majority of the mining power doesn't like block X, so I am attacking/ignoring it."

[notme]

What happens if there are 8064 miners all with equal hashing power?  Even a partial confirmation from all 2016 of the last blocks' miners would only account for 25% of the network.

[casascius]

What happens if there are 8064 miners all with equal hashing power?  Even a partial confirmation from all 2016 of the last blocks' miners would only account for 25% of the network.

This might be a concern if Bitcoin were mined chiefly by solo miners.  The higher the difficulty gets, the less likely that will ever be the case.  Most mining is done by pools (traditional and P2Pool).

Let's consider traditional pools for a moment.  As long as they exist and have the majority of the hashing power, they will always be represented in the last 2016 blocks.

Now let's consider P2Pool.  Admittedly, I did not consider much about how P2Pool would interact until gmaxwell said something.  But P2Pool could collectively commit to a transaction simply by including that commitment in one of its sharechain blocks, as he seemed to suggest.  All other P2Pool workers would be required to honor the commitment if they honor the sharechain block.  If it worked that way, then all that needs to happen for all of P2Pool to collectively commit, would be for any P2Pool miner to solve a sharechain block after having heard about the transaction, which would result in it being shared across P2Pool's p2p entire network.

[notme]

What happens if there are 8064 miners all with equal hashing power?  Even a partial confirmation from all 2016 of the last blocks' miners would only account for 25% of the network.

This might be a concern if Bitcoin were mined chiefly by solo miners.  The higher the difficulty gets, the less likely that will ever be the case.  Most mining is done by pools (traditional and P2Pool).

Let's consider traditional pools for a moment.  As long as they exist and have the majority of the hashing power, they will always be represented in the last 2016 blocks.

Now let's consider P2Pool.  Admittedly, I did not consider much about how P2Pool would interact until gmaxwell said something.  But P2Pool could collectively commit to a transaction simply by including that commitment in one of its sharechain blocks, as he seemed to suggest.  All other P2Pool workers would be required to honor the commitment if they honor the sharechain block.  If it worked that way, then all that needs to happen for all of P2Pool to collectively commit, would be for any P2Pool miner to solve a sharechain block after having heard about the transaction, which would result in it being shared across P2Pool's p2p entire network.

What if bitcoin grows to the point there are 8064 pools?  That's only 8 million miners with 1000 miners per pool.  Doesn't sound too unreasonable given that is only 0.11% of the worlds population.  Also the same problem exists with 4032 since you're only representing half.  In addition, many pools are smaller than 1000 users.

Sure, that's a distant possibility, but we shouldn't add scalability problems.  I suppose we could bump up the number of block later (and only the pools would need to upgrade), but we may run into a problem with transient miners.  It may not be possible to get confirmations from half if say mining is only done in the winter by most people due to the heat production involved.

[casascius]

What if bitcoin grows to the point there are 8064 pools?

I am not considering this as a concern, because I believe the number of traditional pools will tend more to zero, not infinity, as P2Pool evolves to satisfy the needs that currently drive people to traditional pools (a lot of which I believe is just that - "tradition" - they set themselves up to use some other pool at some point in the past and it works so why mess with it.  Or they consider setting up to mine on a traditional pool to be easier than setting up P2Pool - something that can change)

[notme]

What if bitcoin grows to the point there are 8064 pools?

I am not considering this as a concern, because I believe the number of traditional pools will tend more to zero, not infinity, as P2Pool evolves to satisfy the needs that currently drive people to traditional pools (a lot of which I believe is just that - "tradition" - they set themselves up to use some other pool at some point in the past and it works so why mess with it.  Or they consider setting up to mine on a traditional pool to be easier than setting up P2Pool - something that can change)

That's arguable since p2pool mining requires a blockchain and regular pool mining can be done on a computer with just a livecd.

Also, I consider it a concern because there are no rules in the system preventing it.  Sorry, but your guess as to what will happen just doesn't satisfy me.

[Sergio_Demian_Lerner]

Unrelated, a calling card scheme might allow the miners to detect Finney attacks and coordinate the rejection of the block containing it.

As an example, upon receiving a block that invalidates a confirmation, an IPC-participating miner could broadcast a message to the other (up to) 2016 miners saying "Hey! I don't like block X because it forces me to fail on a commitment, and I propose attacking it."  If the majority of miners send that message, they could follow it up with another message: "It looks to me like a majority of the mining power doesn't like block X, so I am attacking/ignoring it."

Two problems with your proposal to punish rough miners:

1. You can ask miners not to follow certain longer block branch, but the have the opposite incentive.

2. You can't tell nodes or miners to invalidate transactions even if you have a proof of dishonest behavior, because that will give you a tool to invalidate blocks in the past. And that would give you a tool to revert millions of other (unrelated) transactions!

Now you have created a new type of double-spend attack by a rough miner that includes a (previously rejected) transaction on purpose.

[casascius]

That's arguable since p2pool mining requires a blockchain and regular pool mining can be done on a computer with just a livecd.

That's how it is today, but that is almost certainly not how it will be the day 8064 discrete mining pools ever come into existence.

Also, I consider it a concern because there are no rules in the system preventing it.  Sorry, but your guess as to what will happen just doesn't satisfy me.

There are no rules preventing me from repetitiously slamming my own head on the sidewalk, but it can be safely said it is unlikely to happen because there is no incentive to do such a thing.  As difficulty tends to infinity, the likelihood of someone solving a block by themselves in their own lifetime approaches zero, and so it's a pretty safe bet it's not going to be very popular as time goes on.