silent payments: add sending support (correction) - #68
Conversation
|
No problem, that's why we review. Also, @rustaceanrob, if I happen to do a review, would it be possible to hold of on merging until I've had a chance to see if the changes are good? I'll plan to look over these changes more tomorrow. It's getting late here and I don't think this is super urgent tonight? |
|
Needs rebase |
Sure. The PR cycles should slow down now that we have the basis for a silent payments wallet. Also, I figured you may want to put your own pull requests up in your areas of interest. For now I think we should move on to testing. |
Spending a received output needs its spend secret plus the tweak recorded when the coin was scanned. Store the spend secret in the even Y form the receiver derives against, so the secret plus the tweak reconstructs each coin key. Add build_transaction, which selects coins, builds the recipient and change outputs, and signs each input as a taproot key spend. Each signature is verified against the output it spends, so a faulty key reconstruction fails here rather than as a rejected broadcast. The recipient may be a silent payment or a normal bitcoin address, the locktime follows the chain tip to discourage fee sniping, and selected coins are reserved so a later spend cannot reuse them. Coin selection uses single random draw from bdk_coin_select, which needs no fee estimate. A more optimal selection algorithm can replace it once long term fee estimation exists.
58c1b05 to
37390e3
Compare
|
Also, see: #70 |
FYI it looks like BDK is now adding SRD algo here: bitcoindevkit/coin-select#50 |
|
Anyway, I think this can be closed in light of #77 |
Not sure if you and Rob still want this change, but it could be a separate PR and commit. |
3 participants
I had an intermittent network issue, and my last commits from #64 didn't get pushed up.
Restating this, but this commit should resolve the following from that PR: