feat: add fee rate and proper drain logic to full-wallet ex

[riverKanies]

No description provided.

[riverKanies]

@thunderbiscuit saw you merged the migration pr, rebased on that and this should be good to merge now aswell

[thunderbiscuit]

To me this one feels like it doesn't actually belong there. We want to document the drain feature on the builder, but the sidequest of getting folks to run the example twice, the second time with part of the code uncommented, feels like it just adds noise no? I'm not sure what we gain from it.

[riverKanies]

@thunderbiscuit uuh so you're saying to demonstrate drain logic in a separate example? My understanding was that it's good practice to always return test funds when your done. since we're requesting sats for this example it seemed reasonable to add the drain logic in here, otherwise bdk users might drain mutinynet...? maybe that doesn't really matter on signet.
the full wallet already has to be run twice do demonstrate functionality, so this is actually a third run

the other part of this pr is the feerate which you requested after the original full wallet example

[riverKanies]

I could put the transaction and drain logic in a conditional that checks a DRAIN flag constant, that way they can just change a bool rather than comment/uncomment. does that seem good to you? (because you actually have to comment out the normal tx logic aswell). my original thinking was just to have the logic in their for completeness even if commented, but thinking about it a feature flag seems good for this

[thunderbiscuit]

Yeah giving the sats back is a good thing to do I agree.

The flag conditional idea would work but I feel like it's just adding complexity unrelated to the example we're trying to demonstrate.

Why not always just drain the wallet back to mutiny faucet instead? No need to comment/uncomment anything. First run errors out, second run drains back to the faucet. What do you think?

[riverKanies]

Well I want to demonstrate a normal tx and the drain tx. If you try to run both they conflict, bc they spend the same input… guess that’s just bc I’m not applying the update?

[thunderbiscuit]

Yeah I think the example could focus on only one of those. You could, indeed, create tx1, then sync, then create tx2 that drains the remaining sats. But again too much for this one page IMO; it's orthogonal to our goal of showcasing simple use of the TxBuilder in this case.

[riverKanies]

ok, my thinking was that any time we tell people to request sats we should also tell them how to drain. if we want to just focus on regular tx why not put that in a conditional, then link to another page that references the ex. like it doesn't hurt to have the drain logic in the code example imo, but doesn't need to be mentioned on that page necessarily

[riverKanies]

I guess I'm just not quite sure what specifically you're suggesting. sounds like we both want drain logic somewhere, seems good here to me (in some form) but idk, maybe another page that refs this ex? a whole sep ex seems exessive to me... i mean the main reason to mention it is that we tell them to request sats for the full-wallet, it's something you only use on testnet

[thunderbiscuit]

True, we could have a second, drain tx there in the code example but not on the book page directly. This would ensure that the wallet always drains all funds back to the faucet but not clog the docs page with this drain transaction.

I was initially thinking of cleaning up the example to build a drain transaction only, and remove the first 5000 sats transaction.

I'd merge either, feel free to pick your favourite:

1. The example builds only one transaction which drains all funds back to the faucet.
2. The example builds two transactions one after the other, with the second one draining remaining funds to the faucet but only the first one exposed in the docs page.

[riverKanies]

ok, 2 make sense to me

so then would we throw a link to a drain page at the end of the full-wallet ex in that case? like I want to go ahead and document the drain logic in this PR since it's there, so I'll make a drain page and put that under cookbook/transactions ? I want to link to the drain page on the full wallet pg since we're telling them to request sats there

[thunderbiscuit]

Building a drain transaction is a TxBuilder feature, and belongs on the TxBuilder page IMO.

In fact we already have a section on it! https://bookofbdk.com/cookbook/transactions/transaction-builder/#spend-all-funds

[riverKanies]

ok ok, just realized that was probably the case! perfect, I'll link to that

[riverKanies]

how does this look? tested it works. links to the existing drain section which now pulls code from the ex

[thunderbiscuit]

Awesome. Just one little thing I noticed: line 88 shadows the address variable defined on line 75 (the faucet address replaces the wallet address) but this is not super good practice. Let's name them differently just to make sure we are explicit.

Otherwise ready to go!

[thunderbiscuit]

ACK c4249c8.