Feedback on double spend specification.

[monsterbitar]

The dblspndproof command

Is the command name shortening useful? why not have a more readable name?

If a transaction that matches a recorded outpoint is relayed to the node, request dbspendproof from previous recorded peer.

In case of miners, should the possible offending transaction be temporarily removed from the mempool for some time while you request the proof, such that it does not get mined? The miner does have an indicator of an issue here and has a choice it can do, if it wants to.

Broadcast the transaction if it has not been broadcast already, in the case of direct connection.

Please allow for an evaluation of the transaction before broadcasting. We shouldn't be shouting out unsuitable/insufficient TX's to the network just to check for a doublespend proof - if the TX isn't what we want, and it's not broadcasted already - don't broadcast it.

[imaginaryusername]

1. It's a sounds suggestion - might actually shorten it to just dsproof. The name was there from the beginning and just didn't get changed.

2. Not sure if this can/should be a bitcoind issue; isn't it more on the side of pool software? One thing that can be done though, is to recommend the client place such suspicious transactions at very low priority.

3. Good point.

[cpacia]

Is the command name shortening useful?

There is a limit on the size of the command defined by the protocol..

[cpacia]

signature of the double-SHA256 of tx_dig1, extracted from tx1

I think we want this to be the full scriptSig and not just the signature right? The reason is that while the preimage contains the prevScriptPubkey.. a lite client wouldn't know the pubkey that generated the pkScript and couldn't validate the signature. If we include the full scriptSig they can validation the signature.

A transaction that has its inputs all being from P2PKH outputs, follow prevailing standardness rules and signed with SIGHASH_ALL without the ANYONECANPAY flag is hereby referred as "protected transactions".

What's the rationale for limiting this to p2pkh transactions? I realize doing this for other types might be more complicated but not impossible right?

Afaict if we use my suggestion above of using the full scriptSig then it will contain a redeemScript which will allow a client to fully validate the script. I realize not all possible scripts can serve as proof of double spend but we could at least to it for standard (and p2sh) multisig right?

[imaginaryusername]

What's the rationale for limiting this to p2pkh transactions

It was primarily for third party malleability concerns; that, and I want to stay as conservative as possible while addressing the most common usecase. If we can demonstrate that this can be expanded to other cases safely (i.e. a proof cannot be forged, nor can a separate transaction be constructed that makes proofing impossible) then it can be expanded.

might be more complicated but not impossible right?

I'll be really happy if someone else can work out those cases; they might be beyond my expertise. =]

[imaginaryusername]

I think we want this to be the full scriptSig and not just the signature right? The reason is that while the preimage contains the prevScriptPubkey.. a lite client wouldn't know the pubkey that generated the pkScript and couldn't validate the signature. If we include the full scriptSig they can validation the signature.

Considering that we're making sure all clients who relay/accept the proof already have one valid tx associated with it (even lite clients), will that not be sufficient to provide the pubkey?

[cpacia]

Considering that we're making sure all clients who relay/accept the proof already have one valid tx associated with it (even lite clients), will that not be sufficient to provide the pubkey?

Yeah I guess you're right.

[cpacia]

If we can demonstrate that this can be expanded to other cases safely (i.e. a proof cannot be forged, nor can a separate transaction be constructed that makes proofing impossible) then it can be expanded.

Maybe someone else can chime in but I think something like this would work:

func IsProtected(scriptPubkey, redeemScript []byte) bool {
	class := GetScriptClass(scriptPubkey)
	switch class {
        case Pubkey:
                return true
	case PubkeyHash:
		return true
	case Multisig:
		return true
	case ScriptHash:
		class := GetScriptClass(redeemScript)
		switch class {
                case Pubkey:
                         return true
		case PubkeyHash:
			return true
		case Multisig:
			return true
		default:
			return false
		}
	default:
		return false
	}
}

I don't think that would be third party malleable. Only first party by one of the signatories.

[cpacia]

Another thing to think about is how a neutrino wallet would use these db proofs without blowing privacy.

My initial thought is every time it matches an unconfirmed tx, it downloads any unconfirmed dependencies. To mask the txs it's interested in it could periodically pick random txs that come over the wire and download their dependencies as well. That would consume more bandwidth but it would most likely just be single round trip (getdata/notfound) for each one it requests. The downside is that would seem to shrink the anonymity set some.

[imaginaryusername]

re: Neutrino, does it not already download all unconfirmed tx whenever it's listening? It seem to not be a huge leap to download all associated dsproof as well, unless I'm mistaken and there is some filtering going on.

[markblundeberg]

Depending on how implementation goes, it might be worthwhile to restrict to only P2PKH and P2SH-multisig (not protect P2PK, raw multisig etc.). It's of course just as possible to allow DS proofs for the other types, but each type requires its own special handling to extract relevant pubkeys, etc... stuff like P2PK and raw multisig are so rare that support should be dropped if they are any barrier to implementation.

[markblundeberg]

BTW regarding how can one support multisig DS proofs, that's a whole can of worms in itself --> see #4.

[cpacia]

re: Neutrino, does it not already download all unconfirmed tx whenever it's listening?

It's not as straight forward. We only keep the hash in memory not the full tx. And that's just so we don't download each tx more than once. We'd need to start keeping full txs in memory.

Also, the way we expect people to use the wallet is to open it, receive a tx, close it. So it will never have a full view of the mempool. It also doesn't know which txs were mined so it clears the full list of downloaded txids each time a header comes in.

[imaginaryusername]

Made an attempt at multisig incorporation, please poke holes: 34b344f