ottosch

> If the current parser accepts them, then we can switch to emitting them right away. I think it should... AFAIK bitcoin core nodes don't relay transactions that use 0x0101...

There it is: https://gist.github.com/ottosch/f699ec13d598efb8a27e30197d9c517f (Disclaimer: I'm not a python programmer) It's pretty silly. Can be called like: `bitcoin-cli getrawtransaction 946f23e7b858e0f5739f363cebb5493f6eb7b9dacd09a609ad325aa5b93d189b | ./otto-parser.py` or `./otto-parser.py `. It's already prepared for 0x0101...

Done. ``` usage: otto-parser.py [-h] [-du] [-o OUTPUT] tx_file Parse and output the ordinal inscription inside transaction positional arguments: tx_file input raw transaction file options: -h, --help show this help...

I have this same issue. Restored a wallet and got: > unexpected output descriptors Core wallet has 4 descriptors (2 internal, 2 external). Sadly Core has no commands to delete...

I was able to workaround this by creating a new Core wallet and importing both descriptors (receive and change).

Can it be related to having 2 wallets named "ord" in different networks? I had this issue after I ran ord on regtest.

@Codonyat the easiest way I found is to import the seed in Sparrow to discover the correct descriptors (they are 2: 1 for receive addresses and 1 for change addresses)....

Bro, you have increased the UTXO set with a (likely) unspendable output: ``` $ bitcoin-cli gettxout c1e0db6368a43f5589352ed44aa1ff9af33410e4a9fd9be0f6ac42d9e4117151 0 { "bestblock": "00000000000000000003df2c062bba629e2881e8c96ce604fcedc56b0f197370", "confirmations": 97, "value": 0.00000000, "scriptPubKey": { "asm": "0 d0829aa329e5716e71b10cb17a6a33df8caf72a3",...

I think you guys made like 99.99% of it, but here we go ¯\\_(ツ)_/¯ npub10tt00tt07exx7mgf9td0026mx454hq6dyl9vwm72aeyf0tljf8msjs3z28 PM8TJgutCtE1GK1Lf6WUTRLzVNcBvNRXjKueKgpQ36dc6Dry3w5oCYz5NEVk7GvNpXAMdrioi6DVytk1P4RBGjXpLw1VFfTm2dNrdtTUWQCQtcjDwPVm

I am participating too. Would be nice if you could add support for Silent Payments for BTC too.