Topic: SPV + P2SH support in one bitcoin library? (Read 1552 times)

I was replying to the following:


I can see how you could have interpreted it differently than me, so just make it clear that you're talking about the practice of wrapping a pay-to-scripthash in P2SH - direct conversion - rather than the logical equivalent version that I meant.


You weren't the target audience there, the OP was. Multiple people, including myself, have discussed bitcoinj P2SH support with you politely before and find your stance on it exasperating, something the OP should consider when picking a library for a new project.

Wallets don't get given pubkeys by users, do they? They are given addresses. Thus you would need to do P2SH to a pay-to-address output, which would be less efficient. The question was about why wallets don't check for P2SH for regular addresses and I explained why that would be pointless; my answer was correct.

I've got an idea Peter: in 2014, why don't you try re-reading your posts after you finish writing them, and take out any snarkyness, personal attacks or the other kinds of things I strongly associate with your writing. If you find yourself calling how other people choose to prioritise their coding time "obnoxious", try rewriting it to be less offensive. If you find yourself giving people commands, try a polite request or question instead. You'd be much more effective for it.

Agreed.

It's interesting how the usage pattern of all escrow services, for instance bitrated and the drug marketplace I linked, is identical in terms of the blockchain data if addresses aren't re-used; from what I can see looking at the P2SH transactions in the blockchain no-one is re-using addresses. Unfortunately the usage patterns do differ from n-of-m protected wallets because of how funds get released from the escrow in a single txin, single txout transaction. Adding CoinJoin to that mix would help, although right now the only n-of-m protected wallet implementation out there, BitGo, uses static addresses.

As for replacing pay-to-pubkey-hash with P2SH-pay-to-pubkey they are of course distinguishable when the txout is spent and the inner script is revealed, although if everyone did it there'd probably still be a weak anti-censorship advantage. Note how oracle transactions using the privkey reveal scheme I came up with for alp use P2SH to prevent the oracle from knowing what txouts are associated with statements the oracle might be asked to make.

As you know P2SH has identical overall efficiency to regular addresses for a single pubkey.

Correct your post.

In the future it could be considered beneficial if outputs to regular addresses are not distinguishable from outputs to contracts.

No, but it would be pointless. P2SH to a regular address is strictly less efficient than a normal payment, which is why no wallets create such transactions. The code would never find a match.

You can use P2SH outputs by adding them as watched scripts, that would load them into the wallet. Ability to watch arbitrary scripts is a new feature in git master added recently. They'd be ignored by the wallet for the purposes of crafting ordinary spends. Then you would dig them out of the wallet object via getTransactions() and create the spends yourself. Because that can be kind of fiddly we probably want to refactor the code a bit so the completion process (which includes adding a change output, fee adjustments, etc) can be done without signing, but again, you probably want some app specific logic at that point.

Look at the micropayments code to see how to work with contracts: the relevant APIs are not very complicated.

I think bitcoinj has probably the best support for writing contracts apps of any codebase right now, in that there's documentation and an actual implementation of an actual contract protocol (micropayments). P2SH currently fills a particular niche, which is sending money into a contract when the wallet app doesn't have any knowledge or support for that kind of contract. So for multi-signature offline wallets and things like that. If you look at the Contracts wiki page, most of the protocols there are multi-step and are supposed to be implemented in the way TMP has done it, via integration with a wallet app (or a dedicated specialised app).

Would it be that hard to check the P2SH version of every regular address it's already using?

P2SH is unnecessary for the dispute mediation use case, so it would make no difference. Besides, as I said, in git master there is some support for P2SH.

Interesting: http://www.reddit.com/r/Bitcoin/comments/1uaywv/first_live_bitcoin_multi_sig_implementation/

A online drug marketplace has implemented multisig escrow for all transactions. Ironic in a way - it's probably a good thing that all the bitcoinj-derived wallets don't support P2SH given that's an application where the total lack of privacy inherent in how those wallets have a fixed set of addresses would be a disaster. Not that existing wallets are all that much better, but every order of magnitude helps...

Keep in mind that Electrum is a SPV wallet these days, it just uses a different mechanism for getting transaction data than Bloom-filter using wallets. They both have similar security properties and both verify transactions against the blockchain headers, proven by multiple peers.


Yeah, bitcoinj's foot-dragging on P2SH is kinda obnoxious; there aren't even concrete plans for how exactly users are supposed to get funds into their multisig-protected wallets without P2SH addresses. Maybe in theory there will be concrete solutions at some point in the future that don't involve addresses, but that's a long way off. For now, supporting P2SH is the only reasonable solution.

FWIW there's other players in the P2SH-using app space right now, Bitrated implements secure escrow with P2SH multisig, and BitGo implements a multi-factor wallet based on Gavin Andresen's one-time-password protected wallet idea. Both use client-side Javacsript libraries, although I don't think either has any specific SPV code. The BitGo is getting some serious usage from the looks of it - there were a few six figure value P2SH-protected txouts characteristic of them last I looked, and the number of P2SH-using transactions has gone way up lately.

Anyway, I assume by "app" you mean Android app specifically right?

The wallet still ignores P2SH transactions, the new support in git master is for sending to P2SH addresses. For the wallet to accept transactions with P2SH outputs, it'd have to know how to spend those outputs, and that would require it to know how to find the other keys and signatures which is highly app specific and usually relies on other protocols. This is why in practice no wallet does this - it's the wrong way to solve the problem.

I admit I didn't really understand your proposed application. What do you mean by notarized transaction in this context?

But, I think the right way to implement an app like that is to write regular multisig transactions and pass the spending tx around outside the P2P network using a custom protocol. If you look at bitcoinj git master, you can find code that does this (for micropayments, using 2-of-2 checkmultisig) in the protocols.channels package. Look at the PaymentChannelClientState/PaymentChannelServerState objects to see how multisig transactions are used or read this page:

https://code.google.com/p/bitcoinj/wiki/WorkingWithContracts

to read some documentation on it.

In master you will also find an app called "Wallet Template". It's designed for writing simple, app-specific wallets and is intended to be copy/pasted. It gives you (out of the box) a GUI that shows balance, a clickable address with qrcodes/copy-paste buttons, network sync progress bar, ability to empty the wallet out to a given address, some nice visual effects etc. It requires you to grab a Java 8 preview release. You can see an app built on top of all of this here:

https://github.com/mikehearn/PayFile
www.youtube.com/watch?v=r0BXnWlnIi4&feature=youtu.be

So as you can see a user can easily load some money into the app and then "do stuff" with it, which in both the PayFile case and your case involves connecting to a server and passing around some transactions and signatures and things.

Does that help? I don't think any other wallet/API will make this easier. P2SH is just an alternative way to write transactions, it's not a particularly important feature for most contracts apps.

My plan is to develop a mini-wallet that can be used for the sole purpose of notarized transactions. The idea is that buyer, seller and notary would use this mini-wallet to create three new public private key pairs. Then they would use some feature of this wallet to securely exchange their public keys. The risk here is that somebody tries to be an impostor (seller faking being the notary as well...etc). The buyer would then create a multi signature address and transfer the bitcoins into it. The transaction would then be broadcast to the network. The seller and notary could then verify that there is indeed a multisigaddress with the correct redeemScript. Finally two of the three will decide to release the funds into some random address. Either of the three will get their mini-wallet populated with the original amount of funds and if they are wise they would put those funds into a more secure wallet.

My problem is that for this wallet to make sense it should not require a local blockchain. So it would either work like Electrum or it would have SPV functionality like bitcoinj.

I was actually giving a look at bitcoinj but this tidbit under Limitations put me off:

P2SH (pay to script hash) is not supported by the wallet. Such transactions will be ignored. Use regular outputs if you want your payments to be noticed by bitcoinj wallets. P2SH is processed correctly by full verification mode.

I would like to know if my vision is possible using bitcoinj from the man himself if you please.

bitcoinj in git master supports P2SH (at least for most usages you would be interested in). What exactly do you want to do?

Is there such a thing if that is at all possible?