adedc7f9c fix HelpExamplRPC port for liquidv1 vs bitcoin mainnet (Gregory Sanders)
d35bf0821 Fix sendtomainchain with pak when subtracting fee from output (Gregory Sanders)
Pull request description:
resolves https://github.com/ElementsProject/elements/issues/695
and also fixes RPC port in help
needs backport to 0.17/0.18
Tree-SHA512: fb5414264a3fc70320b2e25261435a60383c4bf7c2c7f2d6381a862a1c89b2a97f824da412d21cf2e827d02e40e54dde214de471aad9a54c7f3c06ec98d6d840
eef221938 fix config err (Chengcheng Zhang)
Pull request description:
I was confused to instructions in [Elements code tutorial](https://elementsproject.org/elements-code-tutorial/working-environment):
> `cp ~/elements/contrib/assets_tutorial/elements2.conf ~/elementsdir2/elements.conf`
But, in `~/elements/contrib/assets_tutorial/elements2.conf`, the network type is not specified at the beginning.
I got an error after `e2-cli`:
```
$ e2-cli getwalletinfo
error: Could not connect to the server 127.0.0.1:7041
Make sure the daemon server is running and that you are connecting to the correct RPC port.
```
because elements default network is liquid, the port is 7041, so if you don't point the correct chain, you wouldn't get correct info.
So I think the correct elements2.conf as below:
```
chain=elementsregtest
rpcuser=user2
rpcpassword=password2
elementsregtest.rpcport=18885
elementsregtest.port=18887
elementsregtest.connect=localhost:18886
daemon=1
listen=1
txindex=1
#fedpegscript=51<pubkey>51ae
#signblockscript=51<pubkey2>51ae
mainchainrpcport=18888
mainchainrpcuser=user3
mainchainrpcpassword=password3
validatepegin=1
initialfreecoins=2100000000000000
```
I got correct result:
```
$ e2-cli -getinfo
{
"version": 189900,
"protocolversion": 70015,
"walletversion": 169900,
"balance": {
"bitcoin": 21000000.00000000
},
"blocks": 0,
"timeoffset": 0,
"connections": 0,
"proxy": "",
"difficulty": null,
"testnet": false,
"keypoololdest": 1565173696,
"keypoolsize": 1000,
"paytxfee": 0.00000000,
"relayfee": 0.00001000,
"warnings": ""
}
```
Tree-SHA512: c49303328fe5dde6682a1a8cde88350f35af081bb54d0d1dd5072a4c92cb043ed0b84303956a692bc4bc58f5741eae5664f8ffbe9ca795ca7f632c98d43586dd
3127c6561 Add legacy help text for walletprocesspsbt suggesting to use new RPCs instead. (Glenn Willen)
d39925b08 Disable PSBT RPCs when not in g_con_elementsmode. (Glenn Willen)
2848b520b PSBT for Confidential Assets (Glenn Willen)
f87684a00 Add convenience method GetNonIssuanceBlindingData (Glenn Willen)
Pull request description:
This PR extends the PSBT format and RPCs to handle Confidential Assets transactions.
New fields in PSBT inputs: Unblinded value, Value blinder, Unblinded asset, Asset blinder.
New fields in PSBT outputs: Recipient blinding pubkey, Value commitment, Value blinder, Asset commitment, Asset blinder, Nonce commitment, Range proof, Surjection proof.
We preserve the existing invariant that the unsigned transaction inside a PSBT never changes during the process; all updates that need to be applied to produce the final signed transaction are accumulated in the PSBT fields listed above.
The process is as follows:
* Create a PSBT using `converttopsbt` [deprecated], `walletcreatefundedpsbt`, `createpsbt`
* At this point, the output pubkey fields will be filled, for any outputs to confidential addresses.
* Input fields may be filled, if the wallet was used; otherwise they will be filled in the next step.
* Incremental creation of the unsigned transaction itself is OUTSIDE the scope of this work. The unsigned transaction must be fully populated with inputs and outputs before the PSBT is created.
* Transactions with peg-in, issuance, or reissuance outputs are NOT supported at this time.
* If necessary, update the psbt with input data using `walletfillpsbtdata`.
* This is like the old `walletprocesspsbt` RPC [deprecated], which tried to both fill and sign the PSBT (which is not workable in the Confidential Assets setting.)
* Once all inputs have had necessary data updated, possibly using multiple wallets if necessary, any wallet can be used to blind the transaction using `blindpsbt`.
* This uses the input blinding data, along with the output blinding pubkeys, to compute the output blinding data.
* Incremental blinding is not supported. All input blinding data must be available when `blindpsbt` is called.
* Then, the blinded PSBT must be signed using `walletsignpsbt`. As with updating, this can be done by multiple wallets as necessary for the inputs being signed.
* Once all signatures are present, `finalizepsbt` is used to create the final transaction in the regular transaction format, as before.
* Then `sendrawtransaction` is used, which will check to make sure that blinding was performed properly before sending.
Tree-SHA512: 2844a1545383cdab6025b90791c9e66f280d988bd40e37354c831b309c4c41eead144ca6d69c956cac40e849978c3450d1a22910f51ca3c6245236b29c05faa8
d584b65 [test]decrese num of inputs on partial blind test (Akio Nakamura)
254b166 [rpc]blindrawtransaction accepts more commitments (Akio Nakamura)
Pull request description:
In #510 / #550 a requirement that the blinding commitments were equal in amount to the inputs was introduced. This requirement is correct for the final case, but not for partial transactions (e.g. where party 1 blinds their inputs before even handing the transaction over to party 2 to add theirs). In order to hide party 1's input amounts from party 2, blindrawtransaction must allow >= the inputs, since the commitments are shared beforehand (if not, the blinding fails; this may need further investigating).
This PR restores the functionality to allow blinding commitments more than or equal to the amount of inputs, which makes the confidential assets demo https://github.com/ElementsProject/confidential-assets-demo functional again.
Tree-SHA512: 11c7e1c648aea26be2f4cb47606cd8e9b40d9e0d736a7eeb1989d6fad10f8f06528fd90766cb95e304c9b2c371278b20d7ef61099cb8b6e18b281a260e5de92d
