Timeline for Sweep Taproot and native Segwit v0 coins in a single transaction using Bitcoin Core wallet
Current License: CC BY-SA 4.0
24 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Jun 7, 2023 at 12:42 | comment | added | Greg Tonoski | There is the example of using the raw transaction RPC commands: https://bitcoin.stackexchange.com/a/117013/135945. | |
Jun 7, 2023 at 12:35 | comment | added | Greg Tonoski |
Wrong: "Further, you need to use PSBT RPCs; the old raw transacrion RPCs in general do not support taproot. – Pieter Wuille Jun 4 at 11:32" . As a matter of fact, Bitcoin Core v. 24 RPC commands like createrawtransaction and signrawtransactionwithwallet support Taproot (P2TR). Also, the goal could be acheived without using any PSBT-related RPC.
|
|
Jun 6, 2023 at 10:33 | history | edited | Antoine Poinsot | CC BY-SA 4.0 |
edited tags; edited title
|
Jun 6, 2023 at 10:31 | answer | added | Antoine Poinsot | timeline score: 2 | |
Jun 6, 2023 at 3:43 | history | edited | Michael Tidwell | CC BY-SA 4.0 |
added 55 characters in body
|
Jun 6, 2023 at 3:11 | comment | added | Michael Tidwell | @Murch thanks for the tip. I edited the original post with most up to date info. | |
Jun 6, 2023 at 3:10 | history | edited | Michael Tidwell | CC BY-SA 4.0 |
added 137 characters in body; edited title
|
Jun 6, 2023 at 2:38 | comment | added | Murch♦ | In the future, especially if you don’t have answers yet, please edit instead of opening a new question. | |
Jun 5, 2023 at 11:30 | comment | added | Pieter Wuille | Whatever you want to go in an OP_RETURN goes there. But again, please update your question with whatever your question has now evolved to be | |
Jun 5, 2023 at 3:45 | comment | added | Michael Tidwell |
Similarly for walletcreatefundedpsbt with the same json parameter. Not sure if 00 is ok. Or how to find out what to put for this.
|
|
Jun 5, 2023 at 3:37 | comment | added | Michael Tidwell |
so.. just working through this 1. bitcoin-cli createpsbt '[{"txid":"TX_ASSOCIATED_WITH_WIF","vout":INDEX}]' '[{"BTC_ADDRESS":AMOUNT},{ "data": "WHAT_IS_SUPPOSED_TO_GO_HERE?"}]' I've been putting 00 for data maybe that is incorrect?
|
|
Jun 5, 2023 at 3:27 | comment | added | Pieter Wuille |
listdescriptors will give descriptors without private key material (the "hex" you state is the public key); that's why it says hasprivatekeys false. But please update your question to reflect all information, with the commands you did, and the responses you get. It's very hard to discuss this via comments.
|
|
Jun 5, 2023 at 3:22 | comment | added | Michael Tidwell |
1. bitcoin-cli importdescriptors '[{"desc":"tr(WIF)", "timestamp":UNIXTIME}]' 2. bitcoin-cli listdescriptors > (grab the desc for the imported wif = "tr(hex)#CHECKSUM") 3. bitcoin-cli getdescriptorinfo "DESC"
|
|
Jun 5, 2023 at 3:11 | comment | added | Pieter Wuille | This is all impossible to say without knowing what your actual commands are. | |
Jun 5, 2023 at 2:56 | comment | added | Michael Tidwell |
When looking at the output of getdescriptorinfo why would solvable be true but hasprivatekeys be false . After doing a non ranged tr(wif) import? Shouldn't they both be true ?
|
|
Jun 5, 2023 at 0:40 | comment | added | Michael Tidwell | Let us continue this discussion in chat. | |
Jun 5, 2023 at 0:18 | comment | added | Pieter Wuille |
A tr(WIF) descriptor is not ranged, so that's clearly not what you're doing on regtest
|
|
Jun 5, 2023 at 0:12 | comment | added | Michael Tidwell |
Yeah, I'm trying to reproduce, I did find another discrepancy though, "isrange": false, on mainnet but true on regtest. What does this mean? I get this after running the getdescriptorinfo command
|
|
Jun 4, 2023 at 23:55 | comment | added | Pieter Wuille | It would seem that the way you import things on mainnet and on regtest differs then. | |
Jun 4, 2023 at 23:36 | comment | added | Michael Tidwell |
I tried to reproduce everything on regtest, but I keep getting "complete": true and no issues like what I'm seeing on mainnet. The main difference I see is when I do getaddressinfo on regtest it shows I'm using an hd key I believe via: "desc": "tr([e4b96d59/86'/1'/0'/0/0]d5de651411b49df50bc37a17620755ec019866332794cc3e73a6effbb766aa1c)#kh27dth2", on mainnet when I run getaddressinfo I see something similar minus the /86'/1'/0'/0/0 .
|
|
Jun 4, 2023 at 21:58 | comment | added | Pieter Wuille | It would be useful if you'd include the exact commands and output you're seeing in your question. If need be, you can try to recreate on regtest / signet / testnet. | |
Jun 4, 2023 at 21:51 | comment | added | Michael Tidwell |
I'm currently doing createpsbt then walletcreatefundedpsbt but not sure where to go from here. I've tried both walletprocesspsbt and finalizepsbt but they return the base64 encoding and "complete": false . I've tried utxoupdatepsbt but unsure what I would need to do since I've already successfully imported this into my wallet. What steps am I missing?
|
|
Jun 4, 2023 at 11:32 | comment | added | Pieter Wuille |
You need to use a descriptor wallet, and import the key as a taproot descriptor (if it's just a key path key, it would be tr(WIF) , but scripts can also be included there). Further, you need to use PSBT RPCs; the old raw transacrion RPCs in general do not support taproot.
|
|
Jun 4, 2023 at 5:26 | history | asked | Michael Tidwell | CC BY-SA 4.0 |