Topic: BIP Draft - Instant Partial Confirmation - page 3. (Read 4506 times)

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.


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.


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

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

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.


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.


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.

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.

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

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.

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.

Oh, duh.  Thanks guys.

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.

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.

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?

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.

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.