Re: BCH Open-source Pulse : Vol #3. Double Spend Proofs.
Tom Zander
Hey guys,
little update on double spend proofs.
But first, thanks fly to satoshicoffeehouse (you know who you are!) for putting these out. You rock!
DSPs... I finished working on the branch, which is auto tested. All the indications are there that both the concept as well as the implementation works.
I'll work on the spec next.
The current implementation only works for p2pkh (but the spec should allow for other types without modification), and I'm really wondering if there are really usecases for wanting to have double spend proofs for other payment types.
I mean, sure, people use p2sh etc. But is it really useful / relevant to request a payment to a p2sh address if you know you can't get DSProofs for it?
I personally can't find any usecase for non-p2pkh double-spend-proofs and I personally also see p2sh usage go down as we improve payment protocols.
Would love to know what others think.
Will get back in touch when the spec is more in line with the code.
On 2019-08-06 04:16, satoshiscoffeehouse wrote:
# Tom Zander## Flowee
Working on
* Doublespend proofs
https://gitlab.com/FloweeTheHub/thehub/merge_requests/10
Future work
* Proof of concept for double-spend proofs
imaginary.username
TomZ: Current spec on my repo was specifically modified to allow
for P2SH-multisig, which is quite an important usecase. Their use
can increase if more sophisticated UX for personal multisig setups
emerge.
--
BitcoinCash.org
---
You received this message because you are subscribed to the Google Groups "BCH Ecosystem Dev Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bch-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bch-dev/4b1ca76d6e9b65682bfcaaa18eeffeed%40freedommail.ch.
Tom Zander
Can you share the usecases you referred to in your comment, please?
A bit of background of P2SH and why I think its losing its importance.
P2SH is unique in the scripts because it withholds the actual script. and that makes proofs harder (or, at least, noisier).
The usecase for p2sh is that when a payment is made to one or more people, the receiver only needs to give one hash to the sender. While in the original design the entire script would be included in the sending tx. This means that payment protocols that use QR codes to communicate only the hash can be used. With the cost that the spender needs to remember the entire script until spending time.
This has always been a kludge and with BIP70 (payment protocol) we made a good first step towards making it easier for everyone by giving the sender and receiver a bigger communications channel. And suddenly the entire usecase for p2sh is obsolete[1]. You no longer have to limit yourself to just a hash since you can trivially send an unfunded transaction to the sender to finish, for instance. Including the entire script that should be in the output. This avoids you needing to remember the redeem script, since it gets mined in the funding tx.
As a bit higher-level, then, P2SH has downsides for wallets (has to remember redeem script) and therefore double so for merchants. We, as technical leaders, have the opportunity to bypass p2sh and its downsides and provide a better UX by again moving to P2MS and generic scripts.
Now, I'm reasonably positive that the structure I put in the double-spend-proofs supports p2sh (it includes a list of byte-arrays, just like any input does).
The question is still if its worth it to spend time on this. I don't see the usecase for DSPs outside of P2PKH.
1. the secondary reason its obsolete is because of there being no big fees.
On 2019-08-07 01:16, imaginary.username wrote:
TomZ: Current spec on my repo was specifically modified to allow for P2SH-multisig, which is quite an important usecase. Their use can increase if more sophisticated UX for personal multisig setups emerge.
On 8/6/19 2:40 PM, 'Tom Zander' via BCH Ecosystem Dev Discussion Group wrote:Hey guys,
little update on double spend proofs.
But first, thanks fly to satoshicoffeehouse (you know who you are!) for putting these out. You rock!
DSPs... I finished working on the branch, which is auto tested. All the indications are there that both the concept as well as the implementation works.
I'll work on the spec next.
The current implementation only works for p2pkh (but the spec should allow for other types without modification), and I'm really wondering if there are really usecases for wanting to have double spend proofs for other payment types.
I mean, sure, people use p2sh etc. But is it really useful / relevant to request a payment to a p2sh address if you know you can't get DSProofs for it?I personally can't find any usecase for non-p2pkh double-spend-proofs and I personally also see p2sh usage go down as we improve payment protocols.
Would love to know what others think.
Will get back in touch when the spec is more in line with the code.
On 2019-08-06 04:16, satoshiscoffeehouse wrote:
# Tom Zander## Flowee
Working on
* Doublespend proofs
https://gitlab.com/FloweeTheHub/thehub/merge_requests/10
Future work
* Proof of concept for double-spend proofs
im_uname
>BIP70 (payment protocol) we made a good first step towards making it easier for everyone by giving the sender and receiver a bigger communications channel. And suddenly the entire usecase for p2sh is obsolete
This is false: BIP70 requires interaction, which immediate removes large swaths of use from consideration.
>This avoids you needing to remember the redeem script
As Gavin pointed out in the original BIP, wallets already have to
remember private keys, it's not a jump to remember script as well,
and in fact multisig wallets today handles it just fine. I don't
actually see where P2MS provides "better UX" over P2SH-multisig
anywhere other than for some developers who can't be arsed to make
room for script in their wallet, but strangely has storage for
keys.
The only place where P2MS is theoretically better is where you want the sender to inspect the output; but as seen in Openbazaar, these usecases require interaction anyway (sender has to provide pubkey), so the script is trivially exchanged over the same channels, so really it just saves developer hassle. Which is not insignificant, but hardly a reason to push for a reversion to an ancient practice with its own drawbacks, that nobody uses anymore, at great effort.
---
With that said, on DSproof: Even an implementation on P2PKH is
quite an achievement, good job! I can see how people will start
demanding P2SH-multisig solutions down the line, and there's spec
that accommodates it.
Gotta look into moving my flowee setup onto a beefier SSD machine
soon.
--
BitcoinCash.org
---
You received this message because you are subscribed to the Google Groups "BCH Ecosystem Dev Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bch-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bch-dev/e0411a05898462b1cd2d7681e8edbd30%40freedommail.ch.
Tom Zander
The spec that matches the implementation supports p2sh too, and anything else.
The spec that you put on github assumes preimages which I thought was a good idea 6 months ago, but turns out they are really not gaining much and giving a lot of complexity. The spec I put in a PR to your repo also avoids different message formats, which is also a big gain against complexity. Please do take a look, I think it came out pretty nice.
We can have a chat on another medium where maybe you can explain the spec you have. Especially the multisig stuff is a bit unclear to me.
For now the "people will demand it" is unfortunately not a good enough reason for _me_ to spend time on coding it.
PR; https://github.com/imaginaryusername/specs_n_stuff/pull/6