Reserve/unreserve/fundpsbt #3825

rustyrussell · 2020-07-08T07:25:52Z

~~(Note: this fails due to libwally failing to marshal 0-output psbts, but should otherwise be complete).~~ -- Fixed in master by @niftynei !

Based on #3821

This changes the (newly-introduced!) reserveinputs and unreserveinputs to be far more primitive, and adds fundpsbt which is a low-level psbt creator. Unfortunately, the rework I had planned which migrates everything else on top of these will not be finished before the release.

Nonetheless, it's better to ship with these APIs now, so progress can continue: shortly after 0.9.0 I will complete the rewrite which makes txprepare/txdiscard/txcancel a plugin on top of these, and @ZmnSCPxj can do the same for multiwithdraw and multifundchannel!

Closes: #3789
Fixes: #3415

ZmnSCPxj · 2020-07-08T07:35:29Z

wallet/reservation.c

 	struct bitcoin_tx *tx;

 	if (!param(cmd, buffer, params,
 		   p_req("satoshi", param_sat_or_all, &amount),
 		   p_req("feerate", param_feerate_val, &feerate_per_kw),
 		   p_opt_def("minconf", param_number, &minconf, 1),
+		   p_opt_def("reserve", param_bool, &reserve, true),


ZmnSCPxj · 2020-07-08T07:38:57Z

wallet/reservation.c

+	tx = tx_spending_utxos(cmd, chainparams, utxos,
+			       cmd->ld->wallet->bip32_base,
+			       false, 0, locktime,
+			       BITCOIN_TX_RBF_SEQUENCE);


Why RBF-flagged? Am I able to actually RBF now?? How does RBF work?

Yes, we can RBF once everyone uses this...

Okay, let me see if my understanding is correct.

To implement RBF, I would have to go all the way up to signpsbt, but I would have to independently extract the transaction and broadcast it, such as by the bcli sendrawtransaction method. Then if I decide to RBF, I would mutate the PSBT directly, then call signpsbt again with the RBFed PSBT, then sendrawtransaction again.

(we cannot call sendpsbt more than once, since it marks consumed coins as spent, with an assertion that the consumed coin must currently be reserved)

Then, if any of the transactions get confirmed onchain, this automatically marks the consumed inputs as spent. Does that happen?

Looking at lightningd/chaintopology.c it seems we have the rough framework to do so, but while it calls into wallet_outpoint_spend, that function does not update the status of UTXOs. It also calls into wallet_extract_owned_outputs, which will get any unknown outputs, but not what a transaction spends.

wallet_update_update_output_status is otherwise only called from within wallet/wallet.c, or from dev-rescan-outputs.

I don't see any changes in wallet/wallet.c that would allow the above flow to be used.

And then there is the issue where one version of the transaction is seen by one miner, the other version is seen by the other miner, then we see the block created by the first, but ultimately the second miner gets a second block, so now we have to rewind our chaintopology and destroy UTXOs in that chaintopology and recreate it as we go to the winning branch. Do we have code that handles that? What happens to PSBTs that were spending UTXOs from the losing branch? RBF is hard, so I am wary of signaling it until our codebase can handle all the little problems.

(Indeed, since RBF is signaled if any input signals it, we should also refuse to sign if any input is RBF-signalled, else the transaction is still RBF).

(granted the above problem already exists with incoming transactions that might be RBFed as well, but marking our own transactions RBF seems to me to make that even more likely)

ZmnSCPxj · 2020-07-08T07:48:35Z

Does this effectively fix #3415 ? The underlying issue in #3415 is that we want to have an atomic reservation of funds all the way to sign+broadcast without using the current discard+re-prepare trick in fundchannel. My understanding is that it does, in which case this should be tagged "fixes #3415"?

rustyrussell · 2020-07-08T23:41:17Z

Does this effectively fix #3415 ? The underlying issue in #3415 is that we want to have an atomic reservation of funds all the way to sign+broadcast without using the current discard+re-prepare trick in fundchannel. My understanding is that it does, in which case this should be tagged "fixes #3415"?

Yes, good point.

niftynei

ACK cd65293

niftynei · 2020-07-09T05:01:38Z

wallet/reservation.c

+	 * - less distinguishable transactions (with this we create
+	 *   general-purpose transactions which looks like bitcoind:
+	 *   native segwit, nlocktime set to tip, and sequence set to
+	 *   0xFFFFFFFE by default. Other wallets are likely to implement


nota bene: we set the sequence to 0xFFFFFFFD below

niftynei · 2020-07-09T05:15:48Z

wallet/walletrpc.c

@@ -1248,8 +1248,12 @@ static struct command_result *match_psbt_inputs_to_utxos(struct command *cmd,
 		wally_tx_input_get_txid(&psbt->tx->inputs[i], &txid);
 		utxo = wallet_utxo_get(*utxos, cmd->ld->wallet,
 				       &txid, psbt->tx->inputs[i].index);
-		if (!utxo)
+		if (!utxo) {
+			log_debug(cmd->ld->log, "utxo %zu DNE", i);


these seem extraneous?

rustyrussell · 2020-07-09T23:58:11Z

@ZmnSCPxj for some reason I can't quote you on mobile...

Yes, it also requires the change to reserve, rather than mark spent, utxos when we sendpsbt. (This is the Right Thing anyway, in case the tx never confirms).

This is also good, since reserving them twice means we'll extend the reservation, which makes sense.

ZmnSCPxj · 2020-07-10T02:53:55Z

@rustyrussell Okay but does spending a utxo we own without passing the spend through wallet/walletrpc.c interfaces work?

One way to implement #475 would be to keep the PSBT around until some transaction confirms. That means keeping the reservation around until the target transaction confirms.

For another matter, suppose we are building a transaction that spends coins owned by multiple parties (e.g. a CoinJoin). So we signpsbt because we happen to have drawn the short straw and must be the one to sign first, send the PSBT off to the next participant, and then we get disconnected from the Internet because gremlins exist, and then the rest of the participants complete the PSBT signing and they all send the completed PSBT to each other and broadcast, but because we have no Internet because gremlins, we cannot receive the completed PSBT (and thus cannot sendpsbt the tx). We only learn about the successful spend later when we see the tx onchain. So maybe signpsbt should extend reservations as well.

ZmnSCPxj · 2020-07-11T15:44:04Z

doc/lightning-fundpsbt.7.md

+string "all" meaning use all unreserved inputs).  If a value, it can
+be a whole number, a whole number ending in *sat*, a whole number
+ending in *000msat*, or a number with 1 to 8 decimal places ending in
+*btc*.


We should probably mention that:

fundpsbt factors in the fees needed for each input it proposes to add.

the given satoshi value should include the fee for the outputs, plus the fee for the common parts (nLockTime, nVersion etc) of the transaction.

The latter point implies that plugins need access to the fee estimates. While plugins can call the bcli estimatefees directly, I think it is best if lightningd/chaintopology also exposes the actual feerates it would use, especially since estimatefees is allowed to return null and chaintopology, to my understanding, papers over that case. (I think? @darosior )

Alternately, since e.g. Liquid apparently has explicit fee outputs, maybe we can add another parameter, outputs, which is an array of strings or nulls:

An entry can be an address, in which case fundpsbt allocates fees enough for an output going to that address.

An entry can be any of the following strings, indicating fundpsbt allocates fees enough for an output going to that kind of address:

p2pkh

p2pk - or not who uses this nowadays

p2sh

p2wpkh

p2wsh

op-return-# where # is a number from 0 to 64 (or whatever the OP_RETURN max is).

An entry can be null, in which case fundpsbt will allocate fees for the largest known valid address type scriptPubKey..

Then fundpsbt can consider whether there is some excess and see if it is large enough to (1) pay for its existence as a change output and (2) remains large enough to keep itself above the dust limit. If not, it adds the excess to fees (which it adds as an explicit output for Liquid txes).

With this outputs parameter we can also have fundpsbt consider the common parts of the transaction (nLockTime and friends). This removes any remaining reasons that a robust plugin would want to loop around fundpsbt.

The latter point implies that plugins need access to the fee estimates. While plugins can call the bcli estimatefees directly, I think it is best if lightningd/chaintopology also exposes the actual feerates it would use, especially since estimatefees is allowed to return null and chaintopology, to my understanding, papers over that case. (I think? @darosior )

Right, better to use the feerate command which returns a human error in case of estimation failure and smoothed estimation otherwise.

estimatefees could fail (and we allow it to), while feerates would still return a result based on our cached history (if we have one, ie not startup).

Ah, right, feerates. Will go document it for now.

We should probably mention that:

* `fundpsbt` factors in the fees needed for each input it proposes to add. * the given `satoshi` value should include the fee for the outputs, plus the fee for the common parts (`nLockTime`, `nVersion` etc) of the transaction.

The next paragraph does exactly this:

You calculate the value by starting with the amount you want to pay
and adding the fee which will be needed to pay for the base of the
transaction plus that output, and any other outputs and inputs you
will add to the final transaction.

With this outputs parameter we can also have fundpsbt consider the common parts of the transaction (nLockTime and friends). This removes any remaining reasons that a robust plugin would want to loop around fundpsbt.

Indeed. My draft txprepare-as-plugin patch does exactly this, and it's pretty simple (now we have the helpers in place!).

Indeed. My draft txprepare-as-plugin patch does exactly this, and it's pretty simple (now we have the helpers in place!).

Is the code in txprepare or in fundpsbt? I cannot find txprepare-as-plugin branch in your repo or in the ElementsProject repo. My concern is that I believe you mentioned deprecation of txprepare, and in any case fundchannel/multifundchannel will want to move away from txprepare anyway. So a command which wraps fundpsbt and handles as well the common and output weight fees would be quite convenient; if txprepare will be deprecated later, it would be useful for both withdraw and fundchannel (and their multi versions) to use that rather than the existing base fundpsbt.

rustyrussell · 2020-07-13T02:12:11Z

OK, addressed minor feedback from @niftynei and rebased onto master now libwally is fixed...

cdecker

I'm not exactly clear how all and the bumping of reservations interact. If I have a wallet with unreserved UTXOs a, b, and c, then I reserve a, will a call to fundpsbt bump the previous a reservation, or will it skip a?

I'd expect the latter (a is already reserved for another purpose, and I just want to gather all other UTXOs), but I could not convince myself that that's the case.

cdecker · 2020-07-13T18:40:26Z

wallet/wallet.c

@@ -418,6 +421,84 @@ void wallet_confirm_utxos(struct wallet *w, const struct utxo **utxos)
 	}
 }

+static void db_set_utxo(struct db *db, const struct utxo *utxo)


Nit: All functions in here have the prefix wallet_.

Yes, but that's silly. Particularly for an internal function which literally hits the db. Note that many of these functions are going to be removed once the users are gone (i.e. once fundchannel, withdraw and txprepare are reworked on top of fundpsbt/reservepbst/unreservepsbt).

It helps when naming functions and structs to prepend them with a convenient namespace, even if internal. I get annoyed that we have multiple contradictory struct channels, for example, and I have to do extra digging to figure out which one is being used in a particular piece of code.

wallet/wallet.c

doc/lightning-reserveinputs.7.md

wallet/reservation.c

doc/lightning-fundpsbt.7.md

rustyrussell · 2020-07-13T19:54:11Z

I'm not exactly clear how all and the bumping of reservations interact. If I have a wallet with unreserved UTXOs a, b, and c, then I reserve a, will a call to fundpsbt bump the previous a reservation, or will it skip a?

I'd expect the latter (a is already reserved for another purpose, and I just want to gather all other UTXOs), but I could not convince myself that that's the case.

The UTXO selection only considers unreserved UTXOs, so it will skip a.

rustyrussell · 2020-07-14T06:10:53Z

OK, fixups pushed for those issues (force push because I cleaned up a commit msg too)

cdecker · 2020-07-14T12:45:54Z

ACK 01672a9

cdecker · 2020-07-14T12:48:19Z

Rebased on master, no content changes

cdecker · 2020-07-14T13:20:22Z

Sqashed the fixups, had to manually merge a couple since they were conflicting, but the end-to-end diff is identical now.

~~ACK 095f4e6~~

cdecker · 2020-07-14T14:22:43Z

Sadly the rebase seems to have broken something somewhere. I'm now getting these errors:

       # Join and add an output
        joint_psbt = bitcoind.rpc.joinpsbts([l1_funding['psbt'], l2_funding['psbt'],
>                                            output_pbst])
tests/test_wallet.py:644: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
contrib/pyln-testing/pyln/testing/utils.py:311: in f
    return proxy._call(name, *args)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
self = <bitcoin.rpc.RawProxy object at 0x7fd9948c7b90>
service_name = 'joinpsbts'
args = (['cHNidP8BAAsCAAAAAAAAaAAAAAA=', 'cHNidP8BAK4CAAAABI3tfktaNA4PBnGH8ZPYfNsRFTjclLsA41ICPDFzo2HOAQAAAAD9////ri3g6ZylJh2...tWBzibHhwEEFgAUoyPCgqmhl/wRjsCc2vIcorsbiHIA', 'cHNidP8BACkCAAAAAAHAxi0AAAAAABYAFMkJbUP0COpSYCAmLM2tfIUWuSqBAAAAAAAA'],)
postdata = '{"version": "1.1", "method": "joinpsbts", "params": [["cHNidP8BAAsCAAAAAAAAaAAAAAA=", "cHNidP8BAK4CAAAABI3tfktaNA4PBn...EFgAUoyPCgqmhl/wRjsCc2vIcorsbiHIA", "cHNidP8BACkCAAAAAAHAxi0AAAAAABYAFMkJbUP0COpSYCAmLM2tfIUWuSqBAAAAAAAA"]], "id": 1}'
headers = {'Authorization': b'Basic cnBjdXNlcjpycGNwYXNz', 'Content-type': 'application/json', 'Host': 'localhost', 'User-Agent': 'AuthServiceProxy/0.1'}
response = {'error': {'code': -22, 'message': 'TX decode failed Size of value was not the stated size: iostream error'}, 'id': 1, 'result': None}
    def _call(self, service_name, *args):
        [...snip...]
        response = self._get_response()
        if response['error'] is not None:
>           raise JSONRPCError(response['error'])
E           bitcoin.rpc.JSONRPCError: {'code': -22, 'message': 'TX decode failed Size of value was not the stated size: iostream error'}

Any ideas what this might be @rustyrussell ?

niftynei · 2020-07-14T14:30:31Z

That’s s PSBT decode error, are you running the test on regtest?

…

On Tue, Jul 14, 2020 at 09:23 Christian Decker ***@***.***> wrote: Sadly the rebase seems to have broken something somewhere. I'm now getting these errors: # Join and add an output joint_psbt = bitcoind.rpc.joinpsbts([l1_funding['psbt'], l2_funding['psbt'], > output_pbst]) tests/test_wallet.py:644: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ contrib/pyln-testing/pyln/testing/utils.py:311: in f return proxy._call(name, *args) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <bitcoin.rpc.RawProxy object at 0x7fd9948c7b90> service_name = 'joinpsbts' args = (['cHNidP8BAAsCAAAAAAAAaAAAAAA=', 'cHNidP8BAK4CAAAABI3tfktaNA4PBnGH8ZPYfNsRFTjclLsA41ICPDFzo2HOAQAAAAD9////ri3g6ZylJh2...tWBzibHhwEEFgAUoyPCgqmhl/wRjsCc2vIcorsbiHIA', 'cHNidP8BACkCAAAAAAHAxi0AAAAAABYAFMkJbUP0COpSYCAmLM2tfIUWuSqBAAAAAAAA'],) postdata = '{"version": "1.1", "method": "joinpsbts", "params": [["cHNidP8BAAsCAAAAAAAAaAAAAAA=", "cHNidP8BAK4CAAAABI3tfktaNA4PBn...EFgAUoyPCgqmhl/wRjsCc2vIcorsbiHIA", "cHNidP8BACkCAAAAAAHAxi0AAAAAABYAFMkJbUP0COpSYCAmLM2tfIUWuSqBAAAAAAAA"]], "id": 1}' headers = {'Authorization': b'Basic cnBjdXNlcjpycGNwYXNz', 'Content-type': 'application/json', 'Host': 'localhost', 'User-Agent': 'AuthServiceProxy/0.1'} response = {'error': {'code': -22, 'message': 'TX decode failed Size of value was not the stated size: iostream error'}, 'id': 1, 'result': None} def _call(self, service_name, *args): [...snip...] response = self._get_response() if response['error'] is not None: > raise JSONRPCError(response['error']) E bitcoin.rpc.JSONRPCError: {'code': -22, 'message': 'TX decode failed Size of value was not the stated size: iostream error'} Any ideas what this might be @rustyrussell <https://github.com/rustyrussell> ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3825 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIMAKOJ5PN5SSXVADKQCYLR3RS4HANCNFSM4OUISABA> .

cdecker · 2020-07-14T14:32:56Z

This is directly from travis here with the configuration as follows:

$ export VALGRIND=1
$ export ARCH=64
$ export DEVELOPER=1
$ export COMPILER=gcc
$ export TEST_GROUP=12
$ export TEST_GROUP_COUNT=12
$ export SOURCE_CHECK_ONLY=false

Allow a utxo to be reserved until explicitly unreserved or until a timer runs out. Currently unused. We explicitly do not unreserve these at startup.

niftynei · 2020-07-14T20:13:18Z

tests/test_wallet.py


    # Add some of our own PSBT inputs to it
-    l1_reserved = l1.rpc.reserveinputs(outputs=[{addr: Millisatoshi(3 * amount * 1000)}])
-    joint_psbt = bitcoind.rpc.joinpsbts([l1_reserved['psbt'], l2_reserved['psbt']])
+    l1_funding = l1.rpc.fundpsbt(satoshi=Millisatoshi(0),


Is this intended to be a zero msat fund call? the PSBT that it's returning is invalid.

cHNidP8BAAsCAAAAAAAAZgAAAAA=

Oops, that was me. Weird, here's the fix I'm applying:

diff --git a/tests/test_wallet.py b/tests/test_wallet.py index 5afbb518b..8fabd83b0 100644 --- a/tests/test_wallet.py +++ b/tests/test_wallet.py @@ -636,7 +636,7 @@ def test_sign_and_send_psbt(node_factory, bitcoind, chainparams): l1.rpc.signpsbt(l2_funding['psbt']) # Add some of our own PSBT inputs to it - l1_funding = l1.rpc.fundpsbt(satoshi=Millisatoshi(0), + l1_funding = l1.rpc.fundpsbt(satoshi=Millisatoshi(3 * amount * 1000), feerate=7500, reserve=True) @@ -696,8 +696,11 @@ def test_sign_and_send_psbt(node_factory, bitcoind, chainparams): {'type': 'chain_mvt', 'credit': 0, 'debit': 3000000000, 'tag': 'withdrawal'}, {'type': 'chain_mvt', 'credit': 0, 'debit': 1000000000, 'tag': 'chain_fees'}, {'type': 'chain_mvt', 'credit': 0, 'debit': 0, 'tag': 'spend_track'}, - {'type': 'chain_mvt', 'credit': 0, 'debit': 1000000000, 'tag': 'withdrawal'}, - {'type': 'chain_mvt', 'credit': 0, 'debit': 0, 'tag': 'chain_fees'}, + {'type': 'chain_mvt', 'credit': 0, 'debit': 0, 'tag': 'spend_track'}, + {'type': 'chain_mvt', 'credit': 0, 'debit': 0, 'tag': 'spend_track'}, + {'type': 'chain_mvt', 'credit': 0, 'debit': 0, 'tag': 'spend_track'}, + {'type': 'chain_mvt', 'credit': 0, 'debit': 3000000000, 'tag': 'withdrawal'}, + {'type': 'chain_mvt', 'credit': 0, 'debit': 1000000000, 'tag': 'chain_fees'}, ] check_coin_moves(l1, 'wallet', wallet_coin_mvts, chainparams)

These keep the struct utxo in sync with the database, explicitly: these will be the only places where utxo->status is set. The old routines will be removed at the end. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

This is a new fundamental routine to obtain UTXOs from the database. It's not the most efficient approach, as it returns a single UTXO at a time, but it can consolidate all our UTXO handling (becoming more complex by the reservation timeout logic). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

reserveinputs marks UTXOs reserved for 12 hours, so we won't select them for spending: unreserveinputs marks them available again. Exposes param_psbt() for wider use. Disabled the test_sign_and_send_psbt since we're altering the API; the final patch restores it. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

This is the normal case: you only want to reserve inputs which are not already reserved. This saves you iterating through the results and unreserving some if you weren't exclusive. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Technically, they could do this themselves, but it's much nicer to have one place to do it (and it makes sure we get the required information into the PSBT, which is actually not entirely accessible through listfunds, as that doesn't want to consult with the HSM for close outputs). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Changelog-Added: JSON RPC: new low-level coin selection `fundpsbt` routine.

It's easier for us to call it atomically than have the user loop and retry! Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

It uses reservations heavily, and assumed we generated change, etc. It's now a simpler test, in many ways. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

We're actually going to deprecate this, so don't add new features! Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Changelog-Added: ***REMOVE*** JSON-API: `txprepare` returns a psbt version of the created transaction

rustyrussell · 2020-07-15T09:18:54Z

Ack d162739

following ElementsProject/lightning#3825

rustyrussell added this to the v0.9.0 milestone Jul 8, 2020

rustyrussell requested a review from cdecker as a code owner July 8, 2020 07:25

rustyrussell requested a review from niftynei July 8, 2020 07:26

ZmnSCPxj reviewed Jul 8, 2020

View reviewed changes

niftynei reviewed Jul 9, 2020

View reviewed changes

niftynei mentioned this pull request Jul 10, 2020

libwally-core blessed branch (PSETs and other fixes) #3827

Merged

ZmnSCPxj reviewed Jul 11, 2020

View reviewed changes

rustyrussell force-pushed the reserve-unreserve-fundpsbt branch 4 times, most recently from 9b40fa9 to a732f7c Compare July 13, 2020 05:48

cdecker reviewed Jul 13, 2020

View reviewed changes

rustyrussell force-pushed the reserve-unreserve-fundpsbt branch from 34aed2a to 01672a9 Compare July 14, 2020 06:11

cdecker force-pushed the reserve-unreserve-fundpsbt branch from 01672a9 to 1270c3f Compare July 14, 2020 12:47

cdecker force-pushed the reserve-unreserve-fundpsbt branch 2 times, most recently from b83f83a to 095f4e6 Compare July 14, 2020 13:17

cdecker force-pushed the reserve-unreserve-fundpsbt branch from 095f4e6 to b38e07c Compare July 14, 2020 16:26

cdecker force-pushed the reserve-unreserve-fundpsbt branch from b38e07c to 095f4e6 Compare July 14, 2020 16:27

utxos: add a 'reserved_til' marker for utxos

9e7c0d9

Allow a utxo to be reserved until explicitly unreserved or until a timer runs out. Currently unused. We explicitly do not unreserve these at startup.

niftynei reviewed Jul 14, 2020

View reviewed changes

rustyrussell added 11 commits July 15, 2020 15:10

wallet: explicit routines to reserve/unreserve a UTXO.

9c7a374

These keep the struct utxo in sync with the database, explicitly: these will be the only places where utxo->status is set. The old routines will be removed at the end. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

reserveinputs: add exclusive flag.

ba86cdc

This is the normal case: you only want to reserve inputs which are not already reserved. This saves you iterating through the results and unreserving some if you weren't exclusive. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

pytest: test reserve and unreserve.

1056eba

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

fundpsbt: add reserve arg.

32c7dbb

It's easier for us to call it atomically than have the user loop and retry! Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

doc: document fundpsbt.

42d6013

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

pytest: test fundpsbt.

1ce1209

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

pytest: restore test_sign_and_send_psbt.

5a93794

It uses reservations heavily, and assumed we generated change, etc. It's now a simpler test, in many ways. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

txprepare: revert 1fb9a07 (psbt field)

d162739

We're actually going to deprecate this, so don't add new features! Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Changelog-Added: ***REMOVE*** JSON-API: `txprepare` returns a psbt version of the created transaction

rustyrussell force-pushed the reserve-unreserve-fundpsbt branch from 1342db1 to d162739 Compare July 15, 2020 05:40

rustyrussell merged commit 371cabf into ElementsProject:master Jul 15, 2020

cdecker mentioned this pull request Jul 22, 2020

Potential memory leak in wallet_clean_utxos #3780

Closed

fiatjaf pushed a commit to fiatjaf/mcldsp that referenced this pull request Aug 4, 2020

add column outputs.reserved_til.

18b94e6

following ElementsProject/lightning#3825

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Reserve/unreserve/fundpsbt #3825

Reserve/unreserve/fundpsbt #3825

rustyrussell commented Jul 8, 2020 •

edited

Loading

ZmnSCPxj Jul 8, 2020

ZmnSCPxj Jul 8, 2020

rustyrussell Jul 8, 2020

ZmnSCPxj Jul 9, 2020

ZmnSCPxj Jul 9, 2020 •

edited

Loading

ZmnSCPxj commented Jul 8, 2020

rustyrussell commented Jul 8, 2020

niftynei left a comment

niftynei Jul 9, 2020

niftynei Jul 9, 2020

rustyrussell commented Jul 9, 2020

ZmnSCPxj commented Jul 10, 2020 •

edited

Loading

ZmnSCPxj Jul 11, 2020 •

edited

Loading

darosior Jul 11, 2020 •

edited

Loading

ZmnSCPxj Jul 12, 2020

rustyrussell Jul 13, 2020

ZmnSCPxj Jul 13, 2020

rustyrussell commented Jul 13, 2020

cdecker left a comment

cdecker Jul 13, 2020

rustyrussell Jul 13, 2020

ZmnSCPxj Jul 14, 2020 •

edited

Loading

rustyrussell commented Jul 13, 2020

rustyrussell commented Jul 14, 2020 •

edited

Loading

cdecker commented Jul 14, 2020

cdecker commented Jul 14, 2020 •

edited

Loading

cdecker commented Jul 14, 2020 •

edited

Loading

cdecker commented Jul 14, 2020

niftynei commented Jul 14, 2020 via email

cdecker commented Jul 14, 2020

niftynei Jul 14, 2020 •

edited

Loading

rustyrussell Jul 15, 2020

rustyrussell commented Jul 15, 2020

Reserve/unreserve/fundpsbt #3825

Reserve/unreserve/fundpsbt #3825

Conversation

rustyrussell commented Jul 8, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ZmnSCPxj Jul 9, 2020 • edited Loading

Choose a reason for hiding this comment

ZmnSCPxj commented Jul 8, 2020

rustyrussell commented Jul 8, 2020

niftynei left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rustyrussell commented Jul 9, 2020

ZmnSCPxj commented Jul 10, 2020 • edited Loading

ZmnSCPxj Jul 11, 2020 • edited Loading

Choose a reason for hiding this comment

darosior Jul 11, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rustyrussell commented Jul 13, 2020

cdecker left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ZmnSCPxj Jul 14, 2020 • edited Loading

Choose a reason for hiding this comment

rustyrussell commented Jul 13, 2020

rustyrussell commented Jul 14, 2020 • edited Loading

cdecker commented Jul 14, 2020

cdecker commented Jul 14, 2020 • edited Loading

cdecker commented Jul 14, 2020 • edited Loading

cdecker commented Jul 14, 2020

niftynei commented Jul 14, 2020 via email

cdecker commented Jul 14, 2020

niftynei Jul 14, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rustyrussell commented Jul 15, 2020

rustyrussell commented Jul 8, 2020 •

edited

Loading

ZmnSCPxj Jul 9, 2020 •

edited

Loading

ZmnSCPxj commented Jul 10, 2020 •

edited

Loading

ZmnSCPxj Jul 11, 2020 •

edited

Loading

darosior Jul 11, 2020 •

edited

Loading

ZmnSCPxj Jul 14, 2020 •

edited

Loading

rustyrussell commented Jul 14, 2020 •

edited

Loading

cdecker commented Jul 14, 2020 •

edited

Loading

cdecker commented Jul 14, 2020 •

edited

Loading

niftynei Jul 14, 2020 •

edited

Loading