`createpsbt` RPC call doesn’t provide PSBT inputs & outputs

I’m attempting to create a PSBT using RPC:

bitcoin-cli createpsbt [[{"txid": "1d76879500aecafde541770b5d44ccec5955b4c1a455fae446bf1df7b5ea43e9", "vout": 0}, {"txid": "e5a8dfa9459ac154fe62652e1d43049dae13f11815da36cc32881e27917a0dff", "vout": 1}], [{"bcrt1qnv3tl3z9cll9faqf79ppfn3rrp7pn9wwmq04p5gqgqtxg55xfxuslkyk94": "0.20000000"}, {"bcrt1qa4h6amsgyc878k094grqh6ktmgvp97dt6et9cy5hjmyxlgd9q63q3p6hch": "1.79900000"}], 0, true]

This is the PSBT I receive in return:

cHNidP8BALICAAAAAulD6rX3Hb9G5PpVpMG0VVnszERdC3dB5f3KrgCVh3YdAAAAAAD9/////w16kSceiDLMNtoVGPETrp0EQx0uZWL+VMGaRanfqOUBAAAAAP3///8CAC0xAQAAAAAiACCbIr/ERcf+VPQJ8UIUziMYfBmVztgfUNEAQBZkUoZJuWAOuQoAAAAAIgAg7W+u7ggmD+PZ5aoGC+rL2hgS+avWVlwSl5bIb6GlBqIAAAAAAAAAAAA=

When decoded, the inputs and outputs sections of the PSBT are empty. Why is this? Bitcoin Core should know everything necessary to fill these sections out. Why doesn’t it?

bitcoin-cli -regtest decode <psbt>
{'inputs': [{}, {}],
 'outputs': [{}, {}],
 'tx': {'hash': 'fd88b50ec52948dcf04b0d802000b325f960f3333cff8bf7a274273c9d7e2ed7',
        'locktime': 0,
        'size': 178,
        'txid': 'fd88b50ec52948dcf04b0d802000b325f960f3333cff8bf7a274273c9d7e2ed7',
        'version': 2,
        'vin': [{'scriptSig': {'asm': '', 'hex': ''},
                 'sequence': 4294967293,
                 'txid': '1d76879500aecafde541770b5d44ccec5955b4c1a455fae446bf1df7b5ea43e9',
                 'vout': 0},
                {'scriptSig': {'asm': '', 'hex': ''},
                 'sequence': 4294967293,
                 'txid': 'e5a8dfa9459ac154fe62652e1d43049dae13f11815da36cc32881e27917a0dff',
                 'vout': 1}],
        'vout': [{'n': 0,
                  'scriptPubKey': {'addresses': ['bcrt1qnv3tl3z9cll9faqf79ppfn3rrp7pn9wwmq04p5gqgqtxg55xfxuslkyk94'],
                                   'asm': '0 '
                                          '9b22bfc445c7fe54f409f14214ce23187c1995ced81f50d100401664528649b9',
                                   'hex': '00209b22bfc445c7fe54f409f14214ce23187c1995ced81f50d100401664528649b9',
                                   'reqSigs': 1,
                                   'type': 'witness_v0_scripthash'},
                  'value': Decimal('0.20000000')},
                 {'n': 1,
                  'scriptPubKey': {'addresses': ['bcrt1qa4h6amsgyc878k094grqh6ktmgvp97dt6et9cy5hjmyxlgd9q63q3p6hch'],
                                   'asm': '0 '
                                          'ed6faeee08260fe3d9e5aa060beacbda1812f9abd6565c129796c86fa1a506a2',
                                   'hex': '0020ed6faeee08260fe3d9e5aa060beacbda1812f9abd6565c129796c86fa1a506a2',
                                   'reqSigs': 1,
                                   'type': 'witness_v0_scripthash'},
                  'value': Decimal('1.79900000')}],
        'vsize': 178,
        'weight': 712},
 'unknown': {}}

Is the electrum android private key secure?

I have used electrum for many years on my desktop pc, and have alway felt very secure in doing so because of my ability to use a very strong password to encrypt my seed phrase with. However I just started using the android version and have some concerns.

The android version requires me to select a PIN but it is only 6 digits long? How does the android version of electrum ensure that this tiny keyspace (1 million) stays secure?

Why do we need revocation in both the offered/received HTLC outputs and HTLC timeout/success outputs?

The witness script for the output in the HTLC success/timeout transaction is:

OP_IF
    # Penalty transaction
    <revocationpubkey>
OP_ELSE
    `to_self_delay`
    OP_CHECKSEQUENCEVERIFY
    OP_DROP
    <local_delayedpubkey>
OP_ENDIF
OP_CHECKSIG

Which already exists a penalty transaction. While in the offered HTLC and received HTLC outputs in the commitment transaction, we have,

# To remote node with revocation key
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
...

Why don’t we put the revocation in the HTLC-Timeout/Success outputs only?

How to start using signrawtransactionwithkey instead of signrawtransaction

I am following this tutorial, which says to use signrawtransaction. However, I get:

error code: -32
error message:
signrawtransaction was removed in v0.18.
Clients should transition to using signrawtransactionwithkey and signrawtransactionwithwallet

The API call in the tutorial shows this:

$ signedtx2=$(bitcoin-cli -named signrawtransaction hexstring=$rawtxhex2 | jq -r '.hex')

How do I do that same thing using the new signrawtransactionwithkey API? I started by generating a 256-bit private key:

https://gist.github.com/rietta/3640002

Now I’m not sure what to do. I guess I am to do something like this, but not sure exactly how to define it using CLI variables and such to make sure it’s going to work.

signrawtransactionwithkey  "0200000001cfe62b9f1c52bc2998f9a0e6d6ee35430c93ec653d5691935178147a43090fee0000000000ffffffff01f0afd320766191d4c5c088ac00000000" "[\"cSXHtKRXWnCLWhuie8WC13cKF3qdnKL8vG3BiRpxgCXZkK2CHe9u\"]"  "[{\"txid\":\"ee0f09437a1478519391563d65ec930c4335eed6e6a0f99829bc521c9f2be6cf\",\"vout\":0,\"scriptPubKey\":\"a914111111111111111111111111111111111111111187\",\"redeemScript\":\"5221033d9aecbced8e776c03d283f6c0d64c6a301ad142d74d500fe8860c9b362fa4932102a4df3cb4e5286e180b7c68e323c778e32350a604d4f4a74c290d1c60c721687a52ae\"}]"

Looking further, I need to base58 encode the key.

Electrumx protocol

The description states:

A script hash is the hash of the binary bytes of the locking script (ScriptPubKey), expressed as a hexadecimal string. The hash function to use is given by the “hash_function” member of server.features() (currently sha256() only). Like for block and transaction hashes, when converting the big-endian binary hash to a hexadecimal string the least-significant byte appears first, and the most-significant byte last.

For example, the legacy Bitcoin address from the genesis block:

1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
has P2PKH script:

76a91462e907b15cbf27d5425399ebf6f0fb50ebb88f1888ac
with SHA256 hash:

6191c3b590bfcfa0475e877c302da1e323497acf3b42c08d8fa28e364edf018b
which is sent to the server reversed as:

8b01df4e368ea28f8dc0423bcf7a4923e3a12d307c875e47a0cfbf90b5c39161
By subscribing to this hash you can find P2PKH payments to that address.

Can anybody explain what these numbers are:

6191c3b590bfcfa0475e877c302da1e323497acf3b42c08d8fa28e364edf018b

8b01df4e368ea28f8dc0423bcf7a4923e3a12d307c875e47a0cfbf90b5c39161

and how to get them?

How can someone lose funds in Lightning Network?

In Bitcoin once you own a private key associated with an address that has bitcoins on it, your funds are theoretically safe forever.
But on the Lightning Network, I see that once you send bitcoin to an address there, your funds can somehow disappear. What is the difference with Bitcoin and who or what owns the Bitcoin once they are there?

Flatpak bitcoin-core not generating .cookie file

I’m using the version of Bitcoin-Qt 0.18.1 that comes with Flatpak. I’ve looked in the Bitcoin datadir, which is in ~/.var/app/org.bitcoincore.bitcoin-qt/data/ and there isn’t any .cookie file there. This is preventing me from running Electrum Personal Server.

My Linux distro is MX Linux.

My bitcoin.conf is empty.

Longest unconfirmed transaction?

I recently tried to make a transaction with coinbase. In a hurry I put no fee though. It’s still unconfirmed and blockchain.info doesn’t recognize my hash. But my btc qt wallet is debited. My question is what is the longest unconfirmed transaction you’ve heard of? Mine is going on 16 days. I’m curious because I would still like the transaction to still go through.