text:
Generate P2WSH native
I want to create P2WSH native like https://en.bitcoin.it/wiki/BIP_0173.
I have already a script to generate P2WPKH and it works, thank the python part and re-arrange group byte works.
I read that witnessScript (scriptPubKey) is hash of SHA256 without RIPEMD160.
Below a little bit of my code.
PB=0279BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798

#REDEEM SCRIPT <Public Key> OP_CHECKSIG
SCRIPT=210279BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798AC

#SCRIPT HASH
$ printf $SCRIPT | xxd -r -p | openssl sha256| sed 's/^.* //'
1863143c14c5166804bd19203356da136c985678cd4d27a1b8c6329604903262

Convert scripthash to base 2

11000 01100 01100 01010 00011 11000 00101 00110 00101 00010 11001 10100 00000 01001 01111 01000 11001 00100 00000 11001 10101 01101
  10110 10000 10011 01101 10010 01100 00101 01100 11110 00110 01101
  01001 10100 10011 11010 00011 01110 00110 00110 00110 01010 01011
  00000 01001 00100 00001 10010 01100 010

I need to add two zero at the beginning in order to Re-arrange those bits into groups of 5

00110 00011 00011 00010 10000 11110 00001 01001 10001 01000 10110
  01101 00000 00010 01011 11010 00110 01001 00000 00110 01101 01011
  01101 10100 00100 11011 01100 10011 00001 01011 00111 10001 10011
  01010 01101 00100 11110 10000 11011 10001 10001 10001 10010 10010
  11000 00010 01001 00000 01100 10011 00010

Add witness program

00000 00110 00011 00011 00010 10000 11110 00001 01001 10001 01000 10110
  01101 00000 00010 01011 11010 00110 01001 00000 00110 01101 01011
  01101 10100 00100 11011 01100 10011 00001 01011 00111 10001 10011
  01010 01101 00100 11110 10000 11011 10001 10001 10001 10010 10010
  11000 00010 01001 00000 01100 10011 00010

Convert each bits to base10
0, 6, 3, 3, 2, 16, 30, 1, 9, 17, 8, 22, 13, 0, 2, 11, 26, 6, 9, 0, 6, 13, 11, 13, 20, 4, 27, 12, 19, 1, 11, 7, 17, 19, 10, 13, 4, 30, 16, 27, 17, 17, 17, 18, 18, 24, 2, 9, 0, 12, 19, 2

Create the checksum with python code
15
29
21
28
10
6

my result is:
tb1qxrrzs7pf3gkdqzt6xfqxdtd5ymvnpt83n2dy7sm333jjczfqvnz0a4u2x

but the result in BIP 0173 is
tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3q0sl5k7

I use the same script to generate P2WPKH that you can find in BIP_173 and it works. Of course I change Public key with public key hash, but the logic of create group of 5 bits and python part is the same.
Another question: can I create these address (P2WPKH and P2SH native) from bitcoin-cli?

The data encoded using 8->5 bit conversion is not the entire scriptPubKey, just the witness program itself (=the 32 bytes coming out of SHA256). You then prefix it with a 'q' (for witness version 0).

thanks for reply, but I don't understand sorry. Now I use Public key to generate group of 5 bits. You mean use the SHA256 of SCRIPTPUBKEY? In that way I have the same problem, I don't receive the right result. thanks

You're converting the entire scriptPubKey to groups of 5 bits. You're only supposed to convert the script hash (this is also the case with P2WPKH, except with ripemd160(sha256(pubkey)) instead of sha256(script)).

Script is SCRIPT=210279BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798AC script hash is 1863143c14c5166804bd19203356da136c985678cd4d27a1b8c6329604903262 scriptPubKey is: 00201863143c14c5166804bd19203356da136c985678cd4d27a1b8c6329604903262
Then I convert to base2 the scripthash 1863143c14c5166804bd19203356da136c985678cd4d27a1b8c6329604903262 but I can't get the right result

Ok, that sounds correct. I was confused by your first "00000" 5-bit group that came out. I don't have time right now to go into more detail, but perhaps someone else will.

Your mistake is in bech32 encoding (the part of the code you removed from your post). The hash being 1863... makes your bits be like this (first item is witver) 00000 00011 00001 10001 1... which are 0,3,1,17,... as integers that makes chars as q,r,p,3,... that is the same as correct address tb1qrp3...

@CodingEnthusiast thanks for your reply, I updated my question. I don't understand why I should to have 00011, i need to add just two zeros at the beginning. Thanks !

Bech32 encoding, apart from the checksum, is a simple matter of converting base-256 (8-bits) to base-32 (5-bits). Base-256 is the byte array (octet string) that you get from a hash function. Only focusing on first 3 bytes of the hash:
as hex    = 0x18     0x63     0x14
as bytes  = 24       99       20
as binary = 00011000 01100011 00010100

In order to convert the above base-256 (8-bits) input to base-32 (5-bits) we start from the most significant bit and select 5 bits at a time until we run out.
12345123 45123451 23451234 ...
00011000 01100011 00010100
(00011) (00001) (10001) (10001) (0100 ...

For a bech-32 address there is an extra step here after the base conversion is done. That step is to append of the "witness version" to the beginning of this group as an already converted value in base-32 (since witness version is defined from 0 to 16 inclusive it is already in range).
[00000] (00011) (00001) (10001) (10001) (0100 ...

This final result can be converted to an array of numbers that are between 0 and 31
0, 3, 1, 17, 17

To convert this "number" array to human readable format we print the corresponding character from the bech32 charset (qpzry9x8gf2tvdw0s3jn54khce6mua7l)
0->q, 3->r, 1->p, 17->3, 17->3 ...

P.S. There is a checksum calculation that I skipped to keep it simple but it is just another appended set of 5-bit values at the end of what we have in last step.

oh thanks, I just convert SHA256 digest into base2. it's not enough?
SCRIPT_HASH=`printf $SCRIPT | xxd -r -p | openssl sha256| sed 's/^.* //'
Then convert to base2echo "ibase=16; obase=2; $(echo $SCRIPT_HASH | tr '[:lower:]' '[:upper:]') " | bc  | sed 's/\\//g' | tr -d '\n' > base2.txt

that command is not correct echo 'ibase=16; obase=2; 18' | bc? I use the same logic and script for P2WPKH and same logic to calculate Seed phrase. thanks again

I can generate P2WPKH without a problem with same logic, even your post in bitcoin talk (https://bitcointalk.org/index.php?topic=4992632.0). the P2WSH logic about Base2 is different?

I can't understand the code you posted so I can't tell which part of it is wrong. But you may be having a bug that works with 20 bytes input but not with 32. There is a padding involved when converting bits (20 byte = 160 bit % 5 = 0 but 32 byte = 256 bit % 5 = 1).

Enthusuast. Thanks for your time, it's very funny because with 20 byte it works. Anyway maybe I find a bug, but I have a new problem with checksum (in 20 byte is ok obviously)


text:
Follow-up to Segwit: Arbitrary data storage in witness?
In 2017 a question about Segwit: Arbitrary data storage in witness? asked whether people wanting to store more data in the blockchain than OP_RETURN allows could instead store data in the witness components.
The answer there stated that such a transaction would not be relayed and so might have to be sent to a miner directly (or via nodes that don't enforce the relevant rules)
In several recent transactions, large amounts of data seem to have been stored in the blockchain this way. For example transaction a6628f32a5b41b359cfe4ab038ff7c4279118ff601b9eca85eca8a64763db40c has one output and one input with three witness components, the second component is of size 73433 bytes.
Am I understanding this correctly? will this transaction have failed the normal rules in Bitcoin Core for relaying transactions and will it affect the size of the UTXO set?

For anyone wondering, these recent transactions belong to the Ordinals project. They contain raw image data and are called "Inscriptions", which I understand to be an effort to bring NFTs to Bitcoin.

See the inscription here. Ordinals is a colored coins project primarily, I think...

Related: What is the maximum size of a Bitcoin transaction

Am I understanding this correctly?

Yes.

will this transaction have failed the normal rules in Bitcoin Core for relaying transactions

It's a P2TR (taproot) spend. Those spends have different policy rules than the witness v0 rules talked about in the answer you link to. I'm not sure whether this spend is currently considered standard by Bitcoin Core, but the rules for P2TR spends are much more relaxed.

will it affect the size of the UTXO set?

No, by definition, the UTXO set only contains unspent outputs. This is input data.

Pieter Wuille has answered the technical question of how these transactions are affected by the rules.
Vojtěch Strnad identified the origin as Ordinals Inscriptions - a kind of NFT.

When I asked "will it affect the size of the UTXO set?", I was also interested in the overall effect on Bitcoin ...
In January, I wrote a program to look for witness components larger than 1000 bytes in recent blocks and found 55 of them. The latest "Inscription" on the Ordinals.com Inscriptions page was "Number 81". I was short because some inscriptions are just a short URL or a tiny image and are smaller than 1000 bytes.
Tx 26482871F33F1051F450F2DA9AF275794C0B5F1C61EBF35E4467FB42C2813403 W1 C2  20437 bytes
Tx C17DD02A7F216F4B438AB1A303F518ABFC4D4D01DCFF8F023CF87C4403CB54CA W1 C2   9480 bytes
Tx 22D7FA836A87E0532E9AFF8D29A1B0AA872CE45545E55D9D9C73CB4309FC8BC3 W1 C2   5553 bytes
Tx A4B5580DB345DB7534B74371F40562BA0D6F79FD272E05C62C05DB1B62996D23 W1 C2  34393 bytes
Tx D95C0FB86BC0F0DCE6A732C5AB77D47E33ED24099BDB01133F768CEF75A47724 W1 C2  28650 bytes
Tx 7460A1068F98E1FAC798304ADDCA4B5EED1CC9968CD5526E07C2CEB3EC7CF7B3 W1 C2  49970 bytes
Tx 7641EF7165BC59C40B269D4B2F6741CA3F34334B8C758FBBA155BD0E29B4011B W1 C2 104169 bytes
Tx 16F3C32468E3E52AC20DC8FC633C686F0E31C5F34407413D12AD764BA5AD5F3B W1 C2  71832 bytes
Tx 517EE232143D289D70867F88CBE2B9B161EF56554BC4FA7796E672D41E2E2BF3 W1 C2  37718 bytes
Tx F04DD50561899F650103703526A62BC2510CD1B2F185F02E76936314AF42A145 W1 C2  60034 bytes
Tx A6628F32A5B41B359CFE4AB038FF7C4279118FF601B9ECA85ECA8A64763DB40C W1 C2  73433 bytes
Tx 31833061114C2EE53D63DBA53EF0BC2AF741C87463CF573A4E211196883A5F2D W1 C2 245308 bytes
Tx 9163AF650DCDEEEB9A7E1F47F693B51921DCE3BDF2475E69360EC83D9956F5D7 W1 C2   2692 bytes
Tx CA009BF4CAE18D22444C7A31FB05AB372816CDBFBB3FD741812DCA674ADF0CB5 W1 C2   6821 bytes
Tx FD5B77F56C2B785F7266143E1DCD8B83B82050CEB7D2D7344AA3999F3CC17D4D W1 C2  76022 bytes
Tx 0C107942E4C945B6B44E193C950B0FAE65D854A88B450758A3FCA54017C879BE W1 C2  55261 bytes
Tx 9905C43CABE642666E43BD1C059D9093B96204330A2EEB33AC22B7142B1D57ED W1 C2  24745 bytes
Tx ADC408A32E887777007C145DA9CFAFDA88B88917E15D06E4B0097C31CD38AB11 W1 C2   2628 bytes
Tx 562CD1136399F7A6568F41081F85C88145B87E7E70A3A53748A46902E6B84D60 W1 C2   2682 bytes
Tx B375BCCE16C91F3DEF7871933F1696DD3681199E0F23E90D980A87DBF57E6699 W1 C2   2646 bytes
Tx 1FDBD2BBABFAA9B64BBD529D5A2D5FB1B39FFCBDD6C39601BEAAC5E3260C9FCE W1 C2   2728 bytes
Tx 7B68ACED40476A4CAEDB2A5D014974C522331291B6A78BED06BBC891CBE14C9B W1 C2  96909 bytes
Tx 9D0AD29EF2923DF9D598A1A890EAD36EBBE44F1F1D77D93EFA21325806311F28 W1 C2 360490 bytes
Tx 03A6381C7E224D4FE2425B5F5DA3782E8BD5701E783BD0AF4EE1E2700DBBB347 W1 C2 269502 bytes
Tx B8BF03E34F8FB497941A878793F7138AAB502F4A34604923CC3147EF7F6BA471 W1 C2   2702 bytes
Tx 372284D650D297F53309D790CF173D1FC5C2EE4D90250CEE76C6A574EC69882F W1 C2   5345 bytes
Tx 239882AB23041B1F017E19174F24E6397EF10A295484F395D550CAAA61239B8D W1 C2   1907 bytes
Tx 7ECCD70601A5A65421F560743F2661116BC88B4D73A72F4199850B498CE8E996 W1 C2 245062 bytes
Tx 5166A9EF575565ED67D63044FC442A8EF07B4AD20631442D477F784B4CB1BD29 W1 C2   2677 bytes
Tx 6B76932BB8F2478FE58D27B9F80C1C6D02AC0083BA34F9F46A2A171E9A385851 W1 C2 201956 bytes
Tx 40B3279C70D31B1C53D430A245EC012DABF173A47384F33E54DB34E8E7732570 W1 C2   2715 bytes
Tx 913D65CA95AFD862A71FEA8D48CF95434EFD3581B8D08D3F0402DB526D975EFA W1 C2 101461 bytes
Tx 8D9933F3C5BA17025B69FBCBF136EE237320125448E02C2EB1045286879955D5 W1 C2  45629 bytes
Tx E9B1379E9A30E4E2F08FA0C38394F49AA0B92449423F966C6108BE93533C17B6 W1 C2   6979 bytes
Tx 5E1BA5C92673452E3422A553BF641CD634B46FC28FA27ECABFFC917039DE1869 W1 C2   2741 bytes
Tx 1AA4F606890680A9B381BA4E9130894288DD21336B82CBFD75DC19DB38ECE937 W1 C2   2654 bytes
Tx CFAB194B924F7785C6E453728E1C264B89B74843633278CDA3AD3F57576C1E93 W1 C2  51196 bytes
Tx 69908239157F1E069FA3A0469BAD21B49187823D18E729D1EBE29B9252F5BD98 W1 C2  14753 bytes
Tx E3E29332B269D0AE3FA28AC80427065D31B75F2C92BAA729A3F8DE363A0D66F6 W1 C2  28597 bytes
Tx 54E47C2F0E75142D1D7A0FE585E81ACEB8759B07C6CFE9FA1A0BD6C317EAE8B3 W1 C2  37099 bytes
Tx 8A3E28442DEC1E4C56133F75000778121BFE46ECD9FC1C447F8A8315D01017C9 W1 C2   2699 bytes
Tx 36E0C45C1476F059E0A990B5358DA3C3ED9E15F6BBD12AFF5C955A009B65AA5F W1 C2   1077 bytes
Tx 94C7DF559AF3CE875ED49375D8F199B30735D580AD102B920F70B74BAAD17801 W1 C2   4137 bytes
Tx AB2F4E9DCE0583264078428A91AA9037DA0E75F90DC77FE3CBA7CF5320AD003D W1 C2  29518 bytes
Tx 87295FF96556BC668C44068875AED32FBBBCEBB8D5AF3869FE37B264BA319A00 W1 C2   5023 bytes
Tx 85B10531435304CBE47D268106B58B57A4416C76573D4B50FA544432597AD670 W1 C2 185416 bytes
Tx 5A16C5BF8BBCDF978AF8BF511D9AC71CC6E4457F694F4F7ED499F4C8E18EDF79 W1 C2  60199 bytes
Tx 0BD542EC42B205332C4C00739A83C7342BF4F435CAFD569EB543B00E62A852FD W1 C2 126091 bytes
Tx BD0731B218B77A6F2EDA6FCD64FC00305686A38DD474B4D5341BF57945899559 W1 C2  96318 bytes
Tx 2999656AA17255CB9944AAD1B0853937C0BDBC595120E5A5FA97F622ED302AEC W1 C2 128809 bytes
Tx FDCF0B5725301493F3BBB0564D9A1ECAC9AB5BAA0D3C6523CA77186184F3C3FA W1 C2 160042 bytes
Tx 9FD770D420DE2C82C2CCCD30F41A442C3D7CCB75222631DC866E3EA0F43DFB28 W1 C2 124389 bytes
Tx 43008081DC3723C73759F71DD09094BF962F09B019CBB91623EA095311DD3D5D W1 C2  12892 bytes
Tx CD55A39D881663508A9340BAFB4E860F016F16CB07BF6D34CF40BF5A62ADF57B W1 C2  21850 bytes
Tx B1C5BAA2593B256068635BBC475E0CC439D66C2DCF12E9DE6F3AAEAF96FF818B W1 C2  51497 bytes
Found  55  oversized witness components in  7607  blocks.

In February I graphed the effect on daily amounts of Blockchain data.

I reviewed this after a few months, in late April:

So in February, Ordinal Inscriptions had a large effect on blockchain data size. This effect seems to be diminishing. Initially there was little impact on numbers of transactions, but this has grown in late April. I thjink there has been a transition in Ordinals Inscriptions from "art" NFTs, some of which were large, to BRC-20 tokens - which are mostly small - around 50 bytes of JSON.
There were less than 100 inscriptions when I asked the question. There are now well over 2,500,000 inscriptions.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

sort: votes


text:
How could 6 billion people be onboarded to Bitcoin and Lightning today?
How could 6 billion people be onboarded to Bitcoin and Lightning today?

The short answer is we’re not quite there yet but almost…the things we need to accomplish this goal however are on the roadmap. I say this to address the common FUD which states that Bitcoin can never scale to world adoption due to its 1MB block size and slow transaction rate. This is false. Not only have scaling solutions been thought of but they are on the active roadmap of lightning and bitcoin developers going forward. So if you think Bitcoin is some dead and ancient protocol with no clue as to how to move into the future…think again.
So what is needed? First, a future and not controversial upgrade to Bitcoin via soft fork implementing some form of SIGHASH_ANYPREVOUT. (hopefully in Segwit v2) In addition, the implementation of eltoo and finally, channel factories. (look up info on eltoo and factories if you are not already familiar) Assuming micropayment channel networks like Channel Factories come to life on Bitcoin, onboarding the planet would be a fairly arbitrary thing to do.
Channel factories would allow us to onboard 20 people at once onto the lightning network. From there, 100 lightning channels can be created. Assuming that the driving narrative is that 6 billion people want to use the Lightning network ASAP, then this can be easily achieved using channel factories and direct cooperation with the KYC exchanges. (This is assuming the world did not mind using exchanges to onboard themselves and that using peer-to-peer atomic swaps wasn’t of critical importance)
Coinbase, for example, could conceivably ask for a public-key from a user’s custodial wallet after withdrawing funds from a person’s account. They would group at least 20 people together and use their public keys to derive the 20 of 20 tapscript address. They would send out the applicable information to all parties involved and then send the sum of all 20 peoples funds to the taproot address effectively onboarding 20 people onto the Lightning Network and thus Bitcoin network with 1 transaction. By my calculations, the exchange could create a massive transaction that fills an entire block with 1 P2TR to 23,230 P2TR outputs.
The arbitrary fee Coinbase would charge each person and thus put towards the massive transaction would more than incentivize any miner to mine the massive transaction into their block since the fee would be larger than any other combination of other transactions in the mempool. Given that each output is effectively representing 20 new people being onboarded to the network, this would mean 20*23,230 = 464,600 people could be onboarded per block. (That comes out to 774 tx/sec) This would mean that you could onboard 6 billion people in 90 days. Even if you were just allocating 25% of each block for transactions like this and leaving the other 75% for regular transactions, that would still mean you can onboard the entire planet in 1 year which seems more than reasonable to me.
Granted, I realize I am neglecting the time it would take to offboard all those people but I’m dealing with just the idealized best-case scenario here. (Especially since FUD is always centered around perfect worst case scenarios) In addition, the entire point of payment channels is to keep them open and not close them arbitrarily and regularly. Channel Factories allow people to open multiple channels at once and to re-balance their channels without any on chain transactions. And while this compressed onboarding allows for such speed by my calculations the worse case scenario to offload 6 billion people from the channel factories to on chain P2PK addresses would be 4 years. 1TR to 20 PWSPKH is 2,752WU.  3,996,000 WU / 2,752 = 1,453. So 1,453 trans can fit in a block. 23,230/1,453 = 16 so it takes 16 blocks to offload one original block. 90 days * 16 = 4 yrs (BitcoinCore Max WU per block: 3996000)

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Mt. Gox API - getting confirmation of a trade order
I want to place a trade order at market price from an existing wallet in some auxiliary currency. After a successfull trade, I need to do some other work (fullfillment).
However, I'm having trouble figuring out whether my order went successfull :(
For instance, when the wallet in the auxiliary currency is empty or too low (and the order should fail), I'm getting the exact same response that I'm getting upon a successfull trade:
$response = {
          'data' => 'XXXXXX-XXXX-XXXX-XXXX-XXXXXXX', ## not actual order id/oid
          'result' => 'success'
        };

What's the way I'm supposed to check for a successfull trade?

The success message is telling you that your request to place an order was successful, not that the order has been fulfilled.  For that, you have to poll money/order/result.
Also, I use the order submission API in V2 and it does respond with an insufficient funds error.  If you're using the older V0/V1 APIs, you may want to upgrade.

yeah this is a really annoying bug in mtgox api. your best bet is to listen to either the streaming user_order messages or make a request to /money/orders and verify that it contains or not the oid you just got.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Running full node over Tor
I am attempting to run a full bitcoin-core (v0.13.1) node over the Tor network for the first time. I have set up my /etc/tor/torrc file with the following two lines:
HiddenServiceDir /var/lib/tor/bitcoin_service/
HiddenServicePort 8333 127.0.0.1:8333

I have set up a file ~/.bitseed/bitseed.conf with (not sure this is required)
onion=1

I retrieved my onion address from /var/lib/tor/bitcoin-service/hostname allowing me to set up ~/.bitcoin/bitcoin.conf with settings such as:
onlynet=onion
onion=127.0.0.1:9050
listen=1
bind=127.0.0.1:8333
externalip=<my-onion-address>
seednode=wxvp2d4rspn7tqyu.onion
seednode=bk5ejfe56xakvtkk.onion
seednode=bpdlwholl7rnkrkw.onion
seednode=hhiv5pnxenvbf4am.onion
seednode=4iuf2zac6aq3ndrb.onion
seednode=nkf5e6b7pl4jfd4a.onion
seednode=xqzfakpeuvrobvpj.onion
seednode=tsyvzsqwa2kkf6b2.onion
banscore=10000
bantime=11

It seems to be working as I can see my mempool growing from the debug file, and I have one inbound connection. But my connection count is very small (2 or 3). Is there anything else I need to do? In particular, I wanted to confirm that I have no need to set up my firewall ufw to accept connections on port 8333 (or 9050) in order to achieve inbound connections, and I have no need to redirect port 8333 or 9050 from my router to the fixed local ip address of my machine (setting up ufw to allow 8833 and redirecting port 8333 from router would be required if I was running a normal node).
EDIT: 9 connections of which one inbound, but this single inbound connection is myself. So the question really is: How do I allow inbound connections?
EDIT2: I am now of the opinion that this setting is correct. I was wrong to think a prior inbound connection was to 'myself', after 24 hours I have seen a peek of 4 inbound connections. I can confirm there is no need to tweak ufw or change any of your router settings (the tor protocol is not affected by either of these), and this seems to be working having tor on top of a VPN connection (bitmask). Hence I have no more questions but happy to stand corrected if any of the above is wrong.

You can answer your own question so others see it's solved.

I d rather leave the slot open to encourage someone who really knows.

Your settings look correct for the versions you would have been using, I do not know about bitseed.conf however.
For a more up to date guide for setting up Bitcoin Core to run over Tor, you can try this question. Bitcoin Core now supports automatically configuring an ephemeral Tor service, for example.

Thx v much Will.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Failing to build bitcoin-core v0.13.1 on debian stretch
I have recently set up a new machine on debian stretch:
$ uname -a
Linux front 4.8.0-1-amd64 #1 SMP Debian 4.8.7-1 (2016-11-13) x86_64 GNU/Linux

I am now attempting to install bitcoind. I have already set up a directory db4 in my build directory for the Berkeley database version 4.8.30. I have installed all the dependencies as per doc/build-unix, including boost from the distribution:
$ sudo apt-get install libboost-all-dev
$ apt-cache show libboost-all-dev
Package: libboost-all-dev
Source: boost-defaults
Version: 1.62.0.1
...

$ ./autogen.sh
...

$ ./configure LDFLAGS="-L..bitcoin/db4/lib/" CPPFLAGS="-I..bitcoin/db4/include/"
...

$ make
...
CXX      wallet/test/test_test_bitcoin-wallet_tests.o
CXX      wallet/test/test_test_bitcoin-crypto_tests.o
wallet/test/crypto_tests.cpp: In function ‘bool wallet_crypto::OldEncrypt(
const CKeyingMaterial&, std::vector<unsigned char>&, const unsigned
char*, const unsigned char*)’:
wallet/test/crypto_tests.cpp:45:20: error: aggregate ‘EVP_CIPHER_CTX ctx’
has incomplete type and cannot be defined
EVP_CIPHER_CTX ctx;
                ^~~
wallet/test/crypto_tests.cpp: In function ‘bool wallet_crypto::OldDecrypt(
const std::vector<unsigned char>&, CKeyingMaterial&, const unsigned
char*, const unsigned char*)’:
wallet/test/crypto_tests.cpp:69:20: error: aggregate ‘EVP_CIPHER_CTX ctx’
has incomplete type and cannot be defined
EVP_CIPHER_CTX ctx;
                ^~~
Makefile:8232: recipe for target 'wallet/test/test_test_bitcoin
crypto_tests.o' failed
make[2]: *** [wallet/test/test_test_bitcoin-crypto_tests.o] Error 1
make[2]: Leaving directory '/home/john/Libs/bitcoin/src'
Makefile:8370: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/john/Libs/bitcoin/src'
Makefile:680: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1

Any suggestion is gratefully appreciated.
EDIT: adding the option --disable-wallet to configure leads to a successful build.
EDIT2: however, even with the --disable-wallet , the command make check fails with:
make[4]: Entering directory '/home/john/Libs/bitcoin/src/secp256k1'
  CC       src/tests-tests.o
src/tests.c: In function ‘test_ecdsa_der_parse’:
src/tests.c:3561:52: error: dereferencing pointer to incomplete type
‘ECDSA_SIG {aka struct ECDSA_SIG_st}’
valid_openssl = !BN_is_negative(sig_openssl->r) &&
!BN_is_negative(sig_openssl->s) && BN_num_bits(sig_openssl->r) > 0 &&
BN_num_bits(sig_openssl->r) <= 256 && BN_num_bits(sig_openssl->s) > 0 &&
BN_num_bits(sig_openssl->s) <= 256;

This error relating to the C library secp256k1 on debian stretch has already been reported on this post and it seems to be related to some openssl API change (a work around put forward by Andrew Poelstra is to configure secp256k1 with the option --enable-openssl-tests=no. However, this is not an option available for bitcoind configuration)

This is due to some incompatibility between Bitcoin-Core 0.13 (and below) with openSSL 1.1. openSSL 1.1 has some significant API changes: https://wiki.openssl.org/index.php/1.1_API_Changes
The pull request (patch) #9326 should fix this problem (will very likely be in 0.14).
https://github.com/bitcoin/bitcoin/pull/9326
Until this has been resolved, you should use an openSSL version below 1.1.
EDIT: this has been fixed in the bitcoin-core's MASTER branch

I had to make changes to the file src/qt/paymentrequestplus.cpp similar to those of src/wallet/test/crypto_tests.cpp in order for it to compile.

Good point, wasn't aware that you are compiling with the GUI.

Otherwise the build is successful (albeit with the remaining secp256k1 error).

This is now fixed in the master branch of bitcoin core

Yes, master branch builds perfectly. make check successful. Thank you !


text:
Wallet not updating with received bitcoin
I should have received an amount of bitcoins but my wallet balance in the client is still showing $0. The transfer occurred yesterday, while the client was not running. I confirmed the whole blockchain is updated and that the transaction appears at blockchain.info, yet the wallet still shows $0. What could cause this?

Does your wallet address at http://blockchain.info/address/ show the coins?

Yes it does: link

If the address is really in your wallet, that is weird.

Are you sure that the number of blocks in your client is the same as the number on blockexplorer?: http://blockexplorer.com/q/getblockcount

Yep, I just double checked and they match.

@HighlyIrregular that question is tagged bitcoin-qt, if this is closed as a duplicate should that other question be made more general and re-tagged?


text:
OP_CHECKLOCKTIMEVERIFY non-mandatory-script-verify-flag
I have two addresses in my regtest.
A address is the P2SH-P2PKH. (sender)
B address is the P2SH-P2PKH, but with OP_CHECKLOCKTIMEVERIFY block height 201. (receiver)
My regtest doesen't have any block before it, Then I create some blocks (101) for A and transfer some bitcoins to B. A Wants that the UTXO is available after block with height 201 for that reason B creates this kind of script
$ bitcoin-cli decodescript 04C9000000B17576a914697c78eb51aadd3d977c1407e99baf9fe772240588AC
{
  "asm": "201 OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 697c78eb51aadd3d977c1407e99baf9fe7722405 OP_EQUALVERIFY OP_CHECKSIG",
  "type": "nonstandard",
  "p2sh": "2N9X4FL8mg9Tc88FuHgPzBqFXa6U1etuUck",
  "segwit": {
    "asm": "0 30ff9dbf6bab02945016f39e95aa5d67e0f2e6adc7392d1066a1e171513bcb33",
    "hex": "002030ff9dbf6bab02945016f39e95aa5d67e0f2e6adc7392d1066a1e171513bcb33",
    "reqSigs": 1,
    "type": "witness_v0_scripthash",
    "addresses": [
      "bcrt1qxrlem0mt4vpfg5qk7w0ft2javls09e4dcuuj6yrx58shz5fmeves2tkaxf"
    ],
    "p2sh-segwit": "2MtXn1EgzySHEw8BQXLG8n58dxss6NGRsGU"
  }
}

B wants spend his bitcoins, it's the UTXO
[
  {
    "txid": "8cfc83e28fa520fed13a4199b72f588bf95fa84679d44b94efdff5d1f9f7812f",
    "vout": 0,
    "address": "2N9X4FL8mg9Tc88FuHgPzBqFXa6U1etuUck",
    "label": "",
    "scriptPubKey": "a914b2808972cf93673354475ece46820a2b3060978487",
    "amount": 49.99100000,
    "confirmations": 600,
    "spendable": false,
    "solvable": false,
    "safe": true
  }
]

And the current tip
$ bitcoin-cli getchaintips
[
  {
    "height": 701,
    "hash": "1967a98ea0cca367a3699d09a30d046d31ed711989bc6f1a2ae61d7ade910866",
    "branchlen": 0,
    "status": "active"
  }
]

Then B creates the transaction like this
02000000012f81f7f9d1f5dfef944bd47946a85ff98b582fb799413ad1fe20a58fe283fc8c000000008B47304402204cdc56d5be942d05edc218e40de872c9f50e78e018bbbbc9c11a05590aa54e8d02204163ce5796789fe4a7c9d1b1f0b3145ccca1eabb9489b92a4c6bc05508d5cbe6012102839f6ea8422639336f208a2cd2c199872f3e628bff39545eda72d8f71d4b45e42004C9000000B17576a914697c78eb51aadd3d977c1407e99baf9fe772240588ACfeffffff01c07aea290100000017a914d872ea0250c832eca1d7a75434db807397670ccd87C9000000

and uses C9000000 in Locktime field
{
  "txid": "d45d54d3cdae6c22f44cacfd705b2c1234658759f390d387186794240a77b16c",
  "hash": "d45d54d3cdae6c22f44cacfd705b2c1234658759f390d387186794240a77b16c",
  "version": 2,
  "size": 222,
  "vsize": 222,
  "weight": 888,
  "locktime": 201,
  "vin": [
    {
      "txid": "8cfc83e28fa520fed13a4199b72f588bf95fa84679d44b94efdff5d1f9f7812f",
      "vout": 0,
      "scriptSig": {
        "asm": "304402204cdc56d5be942d05edc218e40de872c9f50e78e018bbbbc9c11a05590aa54e8d02204163ce5796789fe4a7c9d1b1f0b3145ccca1eabb9489b92a4c6bc05508d5cbe6[ALL] 02839f6ea8422639336f208a2cd2c199872f3e628bff39545eda72d8f71d4b45e4 04c9000000b17576a914697c78eb51aadd3d977c1407e99baf9fe772240588ac",
        "hex": "47304402204cdc56d5be942d05edc218e40de872c9f50e78e018bbbbc9c11a05590aa54e8d02204163ce5796789fe4a7c9d1b1f0b3145ccca1eabb9489b92a4c6bc05508d5cbe6012102839f6ea8422639336f208a2cd2c199872f3e628bff39545eda72d8f71d4b45e42004c9000000b17576a914697c78eb51aadd3d977c1407e99baf9fe772240588ac"
      },
      "sequence": 4294967294
    }
  ],
  "vout": [
    {
      "value": 49.982,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_HASH160 d872ea0250c832eca1d7a75434db807397670ccd OP_EQUAL",
        "hex": "a914d872ea0250c832eca1d7a75434db807397670ccd87",
        "reqSigs": 1,
        "type": "scripthash",
        "addresses": [
          "2NCyhc6DkujYJE6ui1sVFCJAiSa79BDWqKv"
        ]
      }
    }
  ]
}

But When I try to send Transaction I get that error:
non-mandatory-script-verify-flag (unknown error) (code 64)

With help of btcdeb I can see that error "error: exception thrown: non-minimally encoded script.
number". The same logic BUT with date works.
One more question: Is it correct flow? B(receiver) creates P2SH with 201 OP_CHECKLOCKTIMEVERIFY OP_DROP in order to satisfy A (sender) requirements?

The problem is with your script. If you want to push 201, you should use 02C900 rather than 04C9000000. The argument to OP_CHECKLOCKTIMEVERIFY is a number, not a byte array, so you must use the shortest encoding possible for it.

Thanks again for your time. the scenario is correct? I Mean, B(receiver) creates P2SH with 201 OP_CHECKLOCKTIMEVERIFY OP_DROP in order to satisfy A (sender) requirements?

Why I need to use C900 instead of C9?

The top bit is a sign bit, so C9 would be interpreted as the number -73.

If I use 102, I can use 66 without top bit (0166B175...), why?

Because 0x66 has top bit 0, so it's interpreted as a positive number.

The numbers are converters in binary before put in the stack and use Two Complement? 01100110 top bit is 0 and so its positive.

I don't know what that means. The number is of course already in binary in the script. Bytes in a computer contain bits...

I mean that the stack uses two's Complement in order to have arithmetic operations, for that reason 1000 0001 isn't 129, but it's -1. thanks for your time

Ah, I see. Now, when stack elements are interpreted as numbers, they use a sign and magnitude representation, not two's complement.


text:
How Bitcoin decide which scriptPubKey use?
I'm studying Bitcoin protocol, and I'm able to create address by my bash script.
The addresses "P2PKH" and "P2PK" have the same procedure.
Compressed or uncompressed public key – SHA256 – RIPEMD160.
When I create a transaction using createrawtransaction I can see that the protocol use P2PKH validation by default, and in listunspent I can find its scriptPubKey.
My question is: How the protocol (and where in the code) recognize the validation? I'd like to understand when the protocol add
OP_PUSHBYTES[33] PBKEY OP_CHECKSIG instead of OP_DUP OP_HASH160 OP_PUSHBYTES[20] HASH160(PB) OP_EQUALVERIFY OP_CHECKSIG and How can I use P2PK instead of P2PKH?
UPDATE
For istance, my address is: (testnet)
mwqCgoJBcyciRUawXerkvom8sbg3zkjrvV
Import my address (I don't have it in my wallet, I created this address from outside of bitcoin-core)
bitcoin-cli importaddress mwqCgoJBcyciRUawXerkvom8sbg3zkjrvV

then I mined 101 blocks
bitcoin-cli generatetoaddress 101 mwqCgoJBcyciRUawXerkvom8sbg3zkjrvV >> /dev/null

After that I check my UTXO:
bitcoin-cli listunspent 1 101 '["'mwqCgoJBcyciRUawXerkvom8sbg3zkjrvV'"]'
[
  {
    "txid": "531dcfeea3f87feb4101bfea6fe91ffb0262072cb27acc56f885677ccca089cd",
    "vout": 0,
    "address": "mwqCgoJBcyciRUawXerkvom8sbg3zkjrvV",
    "label": "",
    "scriptPubKey": "76a914b2f58389a224c2fac62b51e78aad7ed058b50f5f88ac",
    "amount": 50.00000000,
    "confirmations": 101,
    "spendable": false,
    "solvable": false,
    "safe": true
  }
]

retrieve the UTXO
bitcoin-cli getrawtransaction 531dcfeea3f87feb4101bfea6fe91ffb0262072cb27acc56f885677ccca089cd 2 | jq

...
{
      "value": 50,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 b2f58389a224c2fac62b51e78aad7ed058b50f5f OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914b2f58389a224c2fac62b51e78aad7ed058b50f5f88ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "mwqCgoJBcyciRUawXerkvom8sbg3zkjrvV"
        ]
      }
    },

...

Why I have P2PKH instead of P2PK? And how can have the hash of my Public key if I imported just address (HASH160(PB))? And the last question, I understand that if the wallet find the 1 as the first char it apply P2PKH by default. How Can I use P2PK instead (study purpose).

The protocol is not what decides the scriptPubKey, it's your wallet that creates the transaction. Your wallet chooses what scriptPubKey to use based on the address that it is given. It uses P2PKH for 1... addresses because that's the scriptPubKey that that type of address specifies. It cannot use those addresses for P2PK because they do not contain enough information for P2PK - they only have the hash160 of the pubkey, not the full pubkey itself. Additionally, using a different scriptPubKey for those addresses would mean that the Bitcoin is sent to a scriptPubKey that the receiver is not necessarily watching.
The same applies to all of the other address types - the address type specifies the scriptPubKey to create.

Why I have P2PKH instead of P2PK?

Because that's the address type you imported. You are using regtest, so P2PKH addresses begin with m or n.

And how can have the hash of my Public key if I imported just address (HASH160(PB))?

The address specifies the hash.

And the last question, I understand that if the wallet find the 1 as the first char it apply P2PKH by default. How Can I use P2PK instead (study purpose).

You cannot. P2PK does not have an address type. There are no P2PK addresses.
Some software and blockchain explorers will show P2PKH addresses for P2PK scriptPubKeys, but this is incorrect. P2PK scriptPubKeys do not have a corresponding address.

Thanks for your comments, I updated my question. thanks again

I've updated my answer to answer your questions.

thanks again, I understand the the wallet can decode the address and retrieve HASH160(PB) and put in scriptPubKey like: printf mwqCgoJBcyciRUawXerkvom8sbg3zkjrvV" | base58 -c -d | xxd -p =>     6fb2f58389a224c2fac62b51e78aad7ed058b50f5f

but in this case https://btc.bitaps.com/f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16 the address is: 1Q2TWHE3GMdB6BZKafqwxXtWAWgFt5Jvm3 and the public key (uncompressed) is: 04ae1a62fe09c5f51b13905f07f06b99a2f7159b2225f374cd378d71302fa28414e7aab37397f554a7df5f142c21c1b7303b8a0626f1baded5c72a704f7e6cd84c. How can I generate 1Q2TWHE3GMdB6BZKafqwxXtWAWgFt5Jvm3? In P2SH I can create a script like $PBLENGTH$PB"AC".

There is no address for that scriptPubKey. It is incorrect for the block explorer to be showing that. You can create an address for a given pubkey by hashing it, however that address will not correspond to a P2PK scriptPubKey. You can read https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses#How_to_create_Bitcoin_Address for some more information on how an address can be created from a pubkey.

Thanks again, I understand and I can reproduce the generation of P2PKH, P2SH, wrapped and native SegWit (from my script).
But i'd like (study purpose) to replicate in regtest a P2PK transaction, is it possible (at the moment i'm using 0.20.0)? thanks again

Ok before bitcoin was locked on Public key, and only who provides a signature the satifies the OP_CHECKSIG (stack with 1 result) can move it. Now We paid to hash of it (in P2PKH). Anyway, is it possible to ricreate the old time? :)

I presume that I need to do something like that
$ bitcoin-cli generatetoaddress 101 uncompressed_public_key error code: -5 error message: Error: Invalid address

It is not possible to give a pubkey as an address, pubkeys are not addresses and do not have addresses. You cannot create a P2PK transaction in Bitcoin Core.

@monkeyUser Bitcoin never had any address type corresponding to P2PK. What it did (very briefly) have was a way to ask another node (over the P2P network!) how to pay it, and it would respond not with an address, but with a scriptPubKey directly. That scriptPubKey could be a P2PK. But since the introduction of bitcoin addresses (before the first release!), they have never had the ability to encode a P2PK script.


text:
Decode script return different value from my relative timelock
I want to lock a UTXO for 90 days.
My Binary is:
00000000010000000011101101010011

And my sequence is: 533B40
When I decode the witness script with bitcoin-cli decodescript I can see 4209491.
Where 4209491 comes from?
UPDATE
It's seems that the 533B40 convert into little endian and the convert into base 10
printf 533B40 | tac -rs ..
403B53

Then convert in base 2
echo "ibase=16; obase=2; 403B53" | bc
10000000011101101010011

And then in base10
echo "ibase=2;10000000011101101010011" | bc
4209491

why decodescript has this behaviour?

decodescript has this behavior because integers in Bitcoin are little endian. So decodescript is telling you what number the script interpreter would use when it processes your script.


text:
What are the steps to convert a private key to a taproot address?
The steps to convert a private key to a SegWit (version 0, bech32) address are roughly as follows:
1.  public_key = Generator * private_key  (use the compressed version)
2.  public_key_hash = RIPEMD160(SHA256(public_key)))
3.  bech32_encode

For taproot address (version 2 witness), is the tweak mandatory or optional? Are the following calculations correct? (No tweak):
Suppose the private key is 1
1. The corresponding 32-byte compressed key (x-only, without oddness indicator): 79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798

2. Directly encode the above 32 bytes using the new modified bech32m encoding, and witness version 1:
    bech32m_encode(hrp='bc', witness_version=1, bytes.fromhex('79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798'))

result: bc1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vqzk5jj0

Also, what the point of adding a tweak step? It doesn’t seem to improve any security by adding a number to privkey. Thanks.

The steps for computing a BIP350 (bech32m) address for a P2TR (pay to taproot) output spendable with a given private key depend on what you want that output to do.
The most straightforward way (but not recommended, see further) is the following:

Compute the public key P = privkey * G.
Let Pb be the serialization of P in x-only form: that's just the 32-byte big endian encoding of its X coordinate. Equivalently, it's the compressed public key encoding with the first byte removed.
The address is bech32m_encode(payload=Pb, version=1). See BIP350 for details.

Spending such outputs is then done by providing a BIP340 signature on that public key, using the message hash mechanism described in BIP341.
However, P2TR outputs are effectively a combination of a pay-to-key and a pay-to-script: each output can be spent for either by signing the output directly, or by revealing how the output commits to a script, and then satisfying that script. Even if you don't want any scripts in there, BIP341 still recommends using a "dummy" script. For simple single-key setups this is unlikely to matter, but it may matter for more advanced cases (see footnote 23 in BIP341), and thus the suggested standard is to always do this. In this case, the procedure would be:

Compute the public key P = privkey * G.
Let Pb be the serialization of P in x-only form.
Compute the tweak t = SHA256(SHA256("TapTweak") || SHA256("TapTweak") || Pb), interpreted as 32-byte big endian encoded integer.
Compute the tweaked public key Q = P + (t * G).
Let Qb be the serialization of Q in x-only form.
The address is bech32m_encode(payload=Qb, version=1).

Signing now requires a BIP340 signature with (privkey + t) as private key.

Thanks. I just re-edited my question. Is the tweak step mandatory?

No, it is not. As I pointed out, it's the standard approach as it is beneficial in some more advanced scenarios, but it is unlikely to matter for simple single-key scenarios. I strongly recommand you use it though, as it avoids needing to understand when it might matter, and will be more interoperable with other software/wallets that do the same. See footnote 23 in BIP341 for details.

I followed that algorithm step by step and used Samourai Wallet to sweep the final address and it don't worked.
I checked by another script that I already have running and tested the sweep with Samourai with success and there is a difference in this step:

Compute the tweaked public key Q = P + (t * G).

The difference is in the P, the working script that I have running don't use the X and Y source coordinates of P, it uses only the X coordinate and a new one for Y that is calculated with:
math.liftX function
So this formula should be Q = P(xP,yliftx) + (t * G)
I don't know yet what liftX does, but is the only way of making it work for sweep the address with success in Samourai.
Can you pronounce about this?
It's very annoying some formula like this don't be correct or should I think that maybe Samourai Wallet use another method ?

It is almost the same as doing a version 0 Bech32 encoding with a couple of differences. For all bech32(m) encodings, the data that gets encoded starts with one version byte and ends with 6 checksum bytes. As far as I know, these 7 bytes are the only differences.
The version byte changes from 0 to 1.
The checksum bytes are also determined differently. A function called PolyMod is called to produce the checksum. The result of this function is XORed with a constant. For the version 0 (Bech32) encoding, this constant is 1. But for the version 1 (Bech32M) encoding, the constant is 0x2bc830a3.
As far as I know, every other part of the process is the same. Writing a step-by-step is somewhat difficult because it depends on various parameters. If you don't mind wading through a bunch of C++ code (it actually isn't that much and is pretty straight forward), the exact algorithm is in the files bech32.h and bech32.cpp. The process of doing either a Bech32 or a Bech32M encoding would begin on line 357 in bech32.cpp, with a call to the Encode function.

This answer is correct, but only focuses on the difference between bech32 and bech32m. There are many more differences in other steps between the private key and the finding the data that goes into the address; see my own answer.


text:
Easier way of backing up/remembering a bitcoin private key
This is a bit of a general question, knowing already of HD wallets and the mnemonic system for creating, backing-up and using the bitcoin blockchain.
However say you have for example a cold/paper wallet, with just one Bitcoin Private Key. Wouldn't an easier way to back-up/save/remember that address be simply be figuring out where the key lies within the range of possible bitcoin keys and taking note of the exponent of said number? Or Additionally a 10 digit scientific notation number, pretty much the same as remembering a phone number...
Example using python:
from bit import Key

# The exact position of this key is 2^65 in int form: 36893488147419103232
privKey = Key.from_int(36893488147419103232)

print(privKey.address)
print(privKey.segwit_address)

This gives the outputs 1LgpDjsqkxF9cTkz3UYSbdTJuvbZ45PKvx and 3FC7umZDWPvTskbVwG7mn72M8RtW8yFSy7. This is so much easier to remember and technically as long as the key was generated randomly enough wouldn't it be just as secure but easier to remember as opposed to 12/24 words one has to write down somewhere, or the hex format or WIF format private key?
After considering other factors... It wouldn't be all that secure if you want to save a key in the range of all possible keys, some exponents of certain numbers produce floats, I assume eventually one would be limited to specific keys, rendering the security bit a quite useless, but I only tested with exponents of 2 my maths could be wrong.
Say the exponent output was always converted to an exponent of the keys position that gives a non-decimal integer, one could in a sense cover all possible keys in the range no? If so then I stand by my question.
I'm trying to understand why this won't work not proving it works.

Given that private keys need to be random, it's unlikely that a properly chosen private key will be easily represented in the method that you have described. Relying on exponentiation in order to essentially compress the private key will be lossy, or require addition of additional exponentiations. This either leads to reduced security as the private key is no longer uniformly random, or having memorize the entire number anyways, just in a different form.
When it comes to memorization, it's probably easier for people to remember a series of words rather than a sequence of numbers. The words are also able to encode more information per word than per digit in a number, which reduces the number of things actually being memorized. Furthermore, when reading a sequence of numbers, it's easy to lose your spot which can result in memorizing the incorrect number. Lastly, words are also self correcting (with enough letters, the intended word becomes obvious, and BIP 39 is designed such that only the first 3 letters are required), and mnemonics also include a checksum. These make writing down the seed from memory much easier to do.

Ok understood, however, I think I may have been a little all over the place with the question. Again say all I want is to generate a cold wallet, Say I use bitaddress.org's code to securely generate a paper wallet. Then import it using the library I used above, and export it to it's integer wallet format, and I turn the resulting integer into an exponent of whatever number that's exactly equal to the exported integer value. Say its 10^98, that's pretty easy to remember, and I generated securely no?

Please take note I did read through your answer, if you find the time please try look into the Bit library, it may help you better understand my question, it allows for one to have private keys in WIF, HEX, INT, PEM, and DER format. That's pretty much where I got curious...

If given the option for INT, I could simply create a backup of my address into something that's as easy as a number to use maybe I can give a follow up edit to the question to demonstrate how that would work. Again I'm am trying to find the flaws not defend something I'm very sure a lot of people in the bitcoin-core developer team, yourself include have already written off. I really appreciate you taking the time Mr. Chow.

I'm fairly sure that most private keys cannot become a nice exponential that's easy to remember. If you're going to randomly generate keys until you do get one that is a simple exponential, that can still reduce the security of your key since it effectively reduces the search space for your key.

Alright that makes sense, thank you Mr. Chow


text:
Testing the blockchain for ECDSA signature random collision
The wikipedia page on ECDSA signature explains how the signer's private key can be recovered if two signatures are produced with the same random (private key looking) element k. In fact, it is claimed on the DSA page that a fault in the implementation of java's SecureRandom class have led to such collision. I would like to confirm that in principle, it is possible to write code checking for such collisions in the blockchain in order to steal bitcoin private keys in the hope that some faulty wallet implementation has prevailed somewhere. Does the following algorithm outline make sense?

Check every signature of every transaction input in the blockchain
If two signatures correspond to the same public key, check if same r
If same r assume there is a collision and derive private key
Check if corresponding address is part of utxo set

Assuming this can be implemented, has it been done already?

It can easily be done, and has been done. See https://bitcointalk.org/index.php?topic=581411.0 for example.


text:
Does the mempool size equal roughly the unconfirmed transactions?
My bitcoind (v0.13.0) mempool size is currently 12k transactions as can be seen from:
tail -f ~/.bitcoin/debug.log
I find this number very surprising as I naively expected it to keep in line with the number of 'Unmatched transaction' as reported say by blockchain.info which currently shows 3k transactions.
https://blockchain.info/unconfirmed-transactions

What am I missing?

How long has your code been running? It usually takes hours to days before the mempool fills us that much.

It has been running for 10 hours now today. Showing poolsz = 12k and 157MB.

Oh, sorry. I thought that your mempool was 12 kB in size. Since Bitcoin Core 0.12, the mempool is really designed to be always at its maximum size. You can check the memory usage with the getmempoolinfo RPC command.

what's the difference between "bytes" and "usage" ? "bytes" only showing 85MB with usage 160MB. Please ignore bitcoin-cli getmempoolinfo help got it :) Thanks v much !

The sum of the 'size' of transactions is 85 MB (size on the wire), but in memory they consume 160 MB of RAM (due to indexes, allocation overhead, metadata, ...).

By default, that 160 will grow to 300.

217MB now :) By the way I used to find it very entertaining to watch the mempool log scrolling down with each new accepted transaction and the "subver" field of my connected peers (which I can still get from getpeerinfo). This feature disappeared 2 or 3 upgrades ago. Is there a setting which allows me to have it back?

Every node owner can set their own policy for the mempool. The mempool is limited two-fold:

With -maxmempool=<n> you can set an explicit limit of MB that it will not exceed. The default is 300MB.
Transactions that don't surpass the minRelayTxFee are not added to your mempool.

As statoshi.info has the mempool at 145MiB and ~11k transactions, it appears likely that different settings on the minRelayTxFee seem to cause your and blockchain.info's divergent mempool size here.

This is great thank you ! I have minrelaytxfee=0.0002, I am assuming config file is not case sensitive.

@SvenWilliamson: Yeah, that's fine. The option is -minrelaytxfee while in the source code it is the camel-case minRelayTxFee.

Note that since 0.12, the effective relay fee is dynamic, and automatocally increases when the mempool fills up.

@PieterWuille: I was wondering about that: The Developer Guide says "it effectively increases the minRelayTxFee", which I understand to say that some transactions that exceed minRelayTxFee are still not included in the mempool. Does the minRelayTxFee actually increase or does just the lowest included fee rise? The difference would be that the former would also raise derived values such as the dust limit, while the latter wouldn't. Do you happen to know?

The dust limit and minimum fee increase for replacement (both depend on minRelayTxFee) are not increased when the mempool min fee goes up. The developer guide is wrong to say that minRelayTxFee is increased.


text:
ScriptSig in P2SH-P2WPKH BIP16
I have some doubts about P2SH-P2WPKH BIP16.
I can read the witness program and I understand that a node is triggered when find 0 and 20 o 32 bytes in scriptSig or ScriptpubKey, more precisely:
If is P2WPKH nested in BIP16 P2SH node check inside scriptSig and search 0-20 bytes (witness program). the witness program must be uguale to redeem script. (address start with 3)
If is P2WPKH scriptSig must be empty. and the witness program is inside scriptPubKey (address start with bc1)
Here I have a P2WPKH nested in BIP16 P2SH transaction output. I can see 160014fdda5544c22213f51080d48da9521b452b99a92c in scriptsig.

the question is:

For node > 0.13
is it a trigger the say to node, Hey, I'm a segwit transaction! check in Txinwitness!
For node < 0.13
Push ScriptSig inside and that's it, the transaction is ANYONE_CAN_SPEND
    {
  "txid": "1fef9c4f076c7dcd92b623bd68136938da4cac6f20fe5384e05c2856e6ec96cc",
  "hash": "df766b607caec934ce35fb0fad6d9caecdc376766135d6f76f5e5c0fad907815",
  "version": 2,
  "size": 215,
  "vsize": 134,
  "weight": 533,
  "locktime": 0,
  "vin": [
    {
      "txid": "5b263a77d64d1aa9d71335f31a46fa6e29212f164d14faea6e7340ae45f5efe6",
      "vout": 0,
      "scriptSig": {
        "asm": "0014fdda5544c22213f51080d48da9521b452b99a92c",
        "hex": "160014fdda5544c22213f51080d48da9521b452b99a92c"
      },
      "txinwitness": [
        "30440220341fd51d549c0ac8269e3711012c91dc4795bc70944ae4fbe77e0bb163977987022076150a459ec655082cae691833d205bb512e926b16511ec7ccf1785ca08476b001",
        "023bbedf4ba488bc1c0c422d14e8f5a151feeb14dae93e891d17489ec007b654ce"
      ],
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 49.991,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_HASH160 09731285fcf96b502243a34e2447ee9a9ffac839 OP_EQUAL",
        "hex": "a91409731285fcf96b502243a34e2447ee9a9ffac83987",
        "reqSigs": 1,
        "type": "scripthash",
        "addresses": [
          "2Mt7BvNshtjdEHRysNdaBi7T82nUCEVZjoW"
        ]
      }
    }
  ]
}

What is your question?

@PieterWuille I updated my question. it's just a doubt. Thanks

For node > 0.13 is it a trigger the say to node, Hey, I'm a segwit transaction! check in Txinwitness!
For node < 0.13 Push ScriptSig inside and that's it, the transaction is ANYONE_CAN_SPEND

Almost exactly right.
Segwit validation code was added in Bitcoin Core 0.13.0, but mainnet activation logic was only added in 0.13.1. That means that 0.13.0 will not enforce these things on mainnet yet (and 0.13.1 will only do it for the part of the blockchain after block 477120).


text:
Sign P2SH transaction with Openssl
I have an P2SH 1-3 and I want to use openssl to sign a transaction.
my redem script is
512103e6b11909698c11ff8232c02f4fbac409fcb5ef2cdacaf22a3c496f334d349a462103f026ba3cff269ae6ba6269b5728829c7879d9d1024fb1ede192cb4088bf86e5c2103f026ba3cff269ae6ba6269b5728829c7879d9d1024fb1ede192cb4088bf86e5c51AE

My transaction data is:
02000000012432698bd45d5bdd68c5439de2a98ac70c63f12c5196970b2fba40b9e01e48010000000069512103e6b11909698c11ff8232c02f4fbac409fcb5ef2cdacaf22a3c496f334d349a462103f026ba3cff269ae6ba6269b5728829c7879d9d1024fb1ede192cb4088bf86e5c2103f026ba3cff269ae6ba6269b5728829c7879d9d1024fb1ede192cb4088bf86e5c51AEffffffff01c07aea29010000001976a914a6cdf0c6e4850e2114cbc96df01f155b8792ed8c88ac0000000001000000

Inside it you can find Redeem Script and SIGHASH.
I do SHA256 twice and save it in a.txt file
printf $A | xxd -r -p | sha256sum -b | xxd -r -p | sha256sum -b | xxd -r -p > a.txt

Now I can sign it with my private key
FIRMA=`openssl pkeyutl -inkey chiave_priv_1.pem -sign -in a.txt -pkeyopt digest:sha256 | xxd -p -c 256`

append to FIRMA the byte 01 (SIGHASH_ALL) and prepend the length and OP_0 for OP_CHECKMULTISIG's bug.
00483045022019d6d4efa4c714c3936e87acd69b1c3d791fb5a9c956e611a33c5a0cb007b209022100de2c9447adc07d1a27f0364a41db87cba09b50f68119a807fc5328df6ce1da1f01

The redeem script length is 210 char hex, 69 in base16.
prepend 4c (OP_PUSHDATA1).
4c69512103e6b11909698c11ff8232c02f4fbac409fcb5ef2cdacaf22a3c496f334d349a462103f026ba3cff269ae6ba6269b5728829c7879d9d1024fb1ede192cb4088bf86e5c2103f026ba3cff269ae6ba6269b5728829c7879d9d1024fb1ede192cb4088bf86e5c51AE

My whole scriptSig is:
00483045022019d6d4efa4c714c3936e87acd69b1c3d791fb5a9c956e611a33c5a0cb007b209022100de2c9447adc07d1a27f0364a41db87cba09b50f68119a807fc5328df6ce1da1f014c69512103e6b11909698c11ff8232c02f4fbac409fcb5ef2cdacaf22a3c496f334d349a462103f026ba3cff269ae6ba6269b5728829c7879d9d1024fb1ede192cb4088bf86e5c2103f026ba3cff269ae6ba6269b5728829c7879d9d1024fb1ede192cb4088bf86e5c51AE

The ScriptSig Length is B5, the my whole transaction is:
02000000012432698bd45d5bdd68c5439de2a98ac70c63f12c5196970b2fba40b9e01e480100000000B500483045022019d6d4efa4c714c3936e87acd69b1c3d791fb5a9c956e611a33c5a0cb007b209022100de2c9447adc07d1a27f0364a41db87cba09b50f68119a807fc5328df6ce1da1f014c69512103e6b11909698c11ff8232c02f4fbac409fcb5ef2cdacaf22a3c496f334d349a462103f026ba3cff269ae6ba6269b5728829c7879d9d1024fb1ede192cb4088bf86e5c2103f026ba3cff269ae6ba6269b5728829c7879d9d1024fb1ede192cb4088bf86e5c51AEffffffff01c07aea29010000001976a914a6cdf0c6e4850e2114cbc96df01f155b8792ed8c88ac00000000

Decoderawtransaction
bitcoin-cli decoderawtransaction 02000000012432698bd45d5bdd68c5439de2a98ac70c63f12c5196970b2fba40b9e01e480100000000B500483045022019d6d4efa4c714c3936e87acd69b1c3d791fb5a9c956e611a33c5a0cb007b209022100de2c9447adc07d1a27f0364a41db87cba09b50f68119a807fc5328df6ce1da1f014c69512103e6b11909698c11ff8232c02f4fbac409fcb5ef2cdacaf22a3c496f334d349a462103f026ba3cff269ae6ba6269b5728829c7879d9d1024fb1ede192cb4088bf86e5c2103f026ba3cff269ae6ba6269b5728829c7879d9d1024fb1ede192cb4088bf86e5c51AEffffffff01c07aea29010000001976a914a6cdf0c6e4850e2114cbc96df01f155b8792ed8c88ac00000000
{
  "txid": "e3d1d4fba5ebd8e6042ece0e5ecc40caf7f81b35fd06e17f76dace8565e2f15f",
  "hash": "e3d1d4fba5ebd8e6042ece0e5ecc40caf7f81b35fd06e17f76dace8565e2f15f",
  "version": 2,
  "size": 266,
  "vsize": 266,
  "weight": 1064,
  "locktime": 0,
  "vin": [
    {
      "txid": "01481ee0b940ba2f0b9796512cf1630cc78aa9e29d43c568dd5b5dd48b693224",
      "vout": 0,
      "scriptSig": {
        "asm": "0 3045022019d6d4efa4c714c3936e87acd69b1c3d791fb5a9c956e611a33c5a0cb007b209022100de2c9447adc07d1a27f0364a41db87cba09b50f68119a807fc5328df6ce1da1f[ALL] 512103e6b11909698c11ff8232c02f4fbac409fcb5ef2cdacaf22a3c496f334d349a462103f026ba3cff269ae6ba6269b5728829c7879d9d1024fb1ede192cb4088bf86e5c2103f026ba3cff269ae6ba6269b5728829c7879d9d1024fb1ede192cb4088bf86e5c51ae",
        "hex": "00483045022019d6d4efa4c714c3936e87acd69b1c3d791fb5a9c956e611a33c5a0cb007b209022100de2c9447adc07d1a27f0364a41db87cba09b50f68119a807fc5328df6ce1da1f014c69512103e6b11909698c11ff8232c02f4fbac409fcb5ef2cdacaf22a3c496f334d349a462103f026ba3cff269ae6ba6269b5728829c7879d9d1024fb1ede192cb4088bf86e5c2103f026ba3cff269ae6ba6269b5728829c7879d9d1024fb1ede192cb4088bf86e5c51ae"
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 49.98200000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 a6cdf0c6e4850e2114cbc96df01f155b8792ed8c OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914a6cdf0c6e4850e2114cbc96df01f155b8792ed8c88ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "mviwAtz3zQj4xzH5mqLhRFrMSHwEcz7rYn"
        ]
      }
    }
  ]
}

Sendrawtransaction:
$ bitcoin-cli sendrawtransaction 02000000012432698bd45d5bdd68c5439de2a98ac70c63f12c5196970b2fba40b9e01e480100000000B500483045022019d6d4efa4c714c3936e87acd69b1c3d791fb5a9c956e611a33c5a0cb007b209022100de2c9447adc07d1a27f0364a41db87cba09b50f68119a807fc5328df6ce1da1f014c69512103e6b11909698c11ff8232c02f4fbac409fcb5ef2cdacaf22a3c496f334d349a462103f026ba3cff269ae6ba6269b5728829c7879d9d1024fb1ede192cb4088bf86e5c2103f026ba3cff269ae6ba6269b5728829c7879d9d1024fb1ede192cb4088bf86e5c51AEffffffff01c07aea29010000001976a914a6cdf0c6e4850e2114cbc96df01f155b8792ed8c88ac00000000
error code: -26
error message:
mandatory-script-verify-flag-failed (unknown error) (code 16)

My goal is create custom script. I tried even with 2-3 but without lucky.
UPDATED QUESTION AFTER ANDREW'S ANSWER

You have made a mistake in the transaction data that you signed. For P2SH, you actually have to sign the redeemScript, not the scriptPubKey. You have to sign it as if that redeemScript were the scriptPubKey.

There is another mistake in your redeemScript as well. An OP_CHECKMULTISIG requires you to push the number of signers needed, then the keys, then the number of keys. So for a 1-of-3 as you have, it should be
1 <key1> <key2> <key3> 3 OP_CHECKMULTISIG

But you have
1 <key1> <key2> <key3> 1 OP_CHECKMULTISIG

which makes the entire redeemScript itself invalid.
Your redeemScript really should be
512103e6b11909698c11ff8232c02f4fbac409fcb5ef2cdacaf22a3c496f334d349a462103f026ba3cff269ae6ba6269b5728829c7879d9d1024fb1ede192cb4088bf86e5c2103f026ba3cff269ae6ba6269b5728829c7879d9d1024fb1ede192cb4088bf86e5c53ae

Because the redeemScript is not valid, the output you are trying to spend is also invalid and thus unspendable.

Thanks again for your time. I updated the question and I changed scriptPubKey with redeem script and sign it. I have the same problem. I don't understand when use 4c, OP_PUSHDATA1. I tried even 4c before sign the transaction, but I get the same issue

I presume that I must use OP_PUSHDATA1 when the data is up to 75 bytes, and my redeem script is 105 bytes.

You use OP_PUSHDATA1 when the data you want to push onto the stack is between 76 and 255 bytes in length, inclusive. I've found another issue with your transaction and have updated my answer.

Thanks again. very dumb mistake! Anyway it works thanks. Just to clarify, I add 4c in front of redeem script because it's 105 bytes after add Signature in my transaction data. Why I don't need to add 4c in front of redeemscript before sign it?

The way that P2SH works is that you push the entire redeemScript as a single stack element to the top of the stack. It then pops it off the stack and executes it as a script during script execution. So when you put it in the scriptSig, you need to make it a push to the stack, hence the need to put OP_PUSHDATA1. But when you are signing the transaction, you need to put the actual script that will be executed, so this can't be a push. You put it as if the redeemScript were in a scriptPubKey. If it were in a scriptPubKey, you would not have a push because it is executed as is.

to understand which part of transaction is signed I can see that file? https://github.com/bitcoin/bitcoin/blob/master/src/script/sign.cpp#L98


text:
P2SH non-segwit and no multi-sig
I have a P2SH no segwit address (regtest) I create the redeem script with SHA256 and RIPEMD160 of my public key and prepend 0x0014
 ---------- Redeem Script ---------
001407b01acbc2869d92912d50de6c7a6b9cb31487f0

 ---------- scriptPubKey ---------
36e74f3c86af031ee34a4552c0d935d180db0a26

 ---------- ADDRESS P2SH ---------
2MxFXaJvTozTJNZmd6E53wwFX7RnbDkGsGe

After that I want to create a transaction manually. I put redeem_script in scriptSig place holder and sign the transaction data.
After that I create the transaction with my signature and add even the redeem_script in scriptSig (like P2SH multi sig)
my final transaction data is:
0200000001f1838b3d294b74a1869140f538ba895b7aef81eab5e87206725ef1f868598a01000000005F47304402204a181d59fd36fb921d68596a4ae89ee6aef6980ab4a2f433ff28be4760744b76022027752d2a405c20aeda51038a8dccc3f2c0df1088fdebaee5f1eed9fad6ae086b0116001407b01acbc2869d92912d50de6c7a6b9cb31487f0ffffffff016036f829010000001976a9143dc3d9dc346b539125506ca681442d89c336813688ac00000000

I get this error:
mandatory-script-verify-flag-failed (Opcode missing or not understood) (code 16)

If you want to check the signature, then you have to have one of the CheckSig OP codes in your scripts. Right now all you are doing is pushing data to the stack without ever using them (apart from the 1 HASH160 OP).

@CodingEnthusiast Yes, I want to understand how P2SH (no multisig) works. I want to understand When I create new address ("getnewaddress") I get P2SH by default (0.19.1) and I want to understand How it works the transaction. I don't want to create a custom script.

I want to understand how P2SH (no multisig) works

To understand that you first have to realize that despite what bitcoin wiki says bitcoin script evaluation is not as simple as running a Forth-like language. More precisely it is not 1) read 2) run. Instead it is more like 1) read 2) interpret (decide how to run) 3) construct the entire script based on 2 4) run. And it is not only "left to right" evaluation. Instead it always starts from looking at far right (PubkeyScript of the previous transaction ie. the tx being spent) then continues from left (which may be different now).
Focusing on P2SH, here are some examples (assuming reader knows what each OP code does, otherwise first take a look at the wiki link above):

First fetch PubkeyScript of the transaction that is being spent and evaluate it to decide how to continue. Here we focus only on P2SH that has this pattern: OP_HASH160 <20 bytes push> OP_EQUAL. Because it is P2SH we continue like this:
Start from SignatureScript and "run" only that script. It must contain at least one PushData operation at the end (the script can only be 1 push, or it could be other OPs ending with 1 mandatory push)
Duplicate that mandatory push
Run PubkeyScript with that duplicated item (pop1>hash>pushResult>push20>pop2>equalityCheck) if they were equal continue otherwise fail.
Evaluate the mandatory push as a script (ie. RedeemScript) and decide how to continue.
Here are different cases:
6.1. RedeemScript = OP_0 <20 bytes push>
6.2. RedeemScript = OP_0 <32 bytes push>
6.3. RedeemScript = whatever else (I don't think there is any more special patterns other than above 2)

Case 6.3 is probably the easiest since it simply "runs" the RedeemScript. I say "whatever else" because as long as it is not a "special pattern" the evaluation is very simple and "normal". You can see this in all legacy multi-signature P2SH transactions easily found on the blockchain. But here is another example with a very simple RedeemScript to show what "whatever else" means: 463782617f0e6a69102530caa9ba2fe48f996128378af99ee437a22660afc5a7 that uses OP_2 OP_3 OP_ADD OP_5 OP_EQUAL as the RedeemScript (only 1 mandatory push).
Cases 6.1 and 6.2 are harder and a bit tricky because during the evaluation you have to "run" OP codes that don't even exist in the scripts! For example in case of 6.1 or the P2SH-P2WPKH you continue like this:

Make sure there was no more than the single PushData in SignatureScript.
Look among witnesses and expect 2 items, extract those
Run a special OP_CheckSig (although it doesn't exist) for SegWit transactions. That means: first item in step 8 was a signature, the second one was a public key. Compute sigHash as descibed in BIP-143, run ECDSA.Verify(signature,sigHash,pubkey).

With 6.2 things get more complicated since there is now a WitnessScript which should be evaluated separately (a bit similar to RedeemScript).

very nice answer, thanks a lot! there is a lot of stuff! I need to study more in order to create a clear question. thanks for your time

I'm reading BIP141. I created P2WPKH not P2SH right?

No, P2WPKH is directly paying to hash of a public key but P2SH (and the nested version P2SH-P2WPKH) pay to the hash of a script.

Your redeemScript is incorrect. You need to push the public key to the stack by prepending it with its length. Otherwise the script interpreter will try to interpret the pubkey as opcodes, which is incorrect. Just putting the pubkey there does not work because the script interpreter does not know that those bytes are for a public key.

you are right sorry, I pasted wrong code. Updated it. During generate my address I don't use segwit.


text:
Please explain network propagation with unconfirmed transactions (blockchain.info)
I am wondering if someone could explain why two transactions have different network propagation values... and what does it even mean considering they are both unconfirmed transactions.
Do the transactions propagate through the nodes without being confirmed?
See below:

https://blockchain.info/tx/aec00216dfad6100638580bdc17a52d62e9c5687d9a981aaa2ece769d1f305c3

https://blockchain.info/tx/bda711e375d32b70b9fe65f4e4ceba041c6d2bdcfdaa03c5cfaff02de5445539
A number of my transactions are still unconfirmed after 10 hours of waiting.
All transactions included a fee.
I am trying to work out what has happened to them and what this whole network propagation thing means.

Network propagation is the number of nodes (computers running a bitcoin client) that have heard about your transaction.
Confirmations is how many blocks have included your transaction and how many blocks have linked onto that block.  1 confirmation means your transaction was included in a block, 2 confirmations means that another block linked onto that first one, and so on.
Until a transaction has been included in a block, it isn't considered to have really happened, regardless of how many nodes have heard about it.
Propagation needs to happen before a confirmation can occur, as a mining node needs to be aware of the transaction to include it in a block.
As of this moment, both of your transactions you linked are now showing as having 1 confirmation after being included in block 228337.
As for why it took so long to get a confirmation (468 minutes for the first one), no real idea.  Might be something regarding some miners dislike for satshoidice.  For example, the Eligius pool is configured to exclude any Satoshidice transactions from their blocks, as they view them as spam.

Thanks! I wasn't aware that transactions could be ignored by the nodes. Thanks for this, informative!

"Might be something regarding some miners dislike for satshoidice."
That seems like a reasonable explanation as some miners explicitly filter SatoshiDice transactions: https://bitcointalk.org/index.php?topic=149668.msg1590550#msg1590550.

It appears that blockchain.info has removed this field now...

@strat - Nodes aren't ignoring the transactions.  The vast majority of nodes aren't mining nodes, just people who use bitcoins and run a client.  They just relay the transactions to any nodes they're connected to.  Mining nodes can pick and choose what transactions they include in their mining attempts based on whatever criteria they choose, be it transaction fees, or in this case, probable origin.

@Compro01, can you elaborate on the mechanics of "might be something regarding some miners dislike for satoshidice"?

@Pacerier - exactly as I said.  Some pools, such as Eligius, explicitly refuse to include Satoshidice in their blocks.  I edited in the info from my comment.

@Compro01, How does one go about refusing certain transactions like this?

@Pacerier - Look at the transaction size, destination address, etc.  Here's an example.  Elligus I believe uses a more extensive transaction blacklist with more criteria that blocks more "unwanted" transactions


text:
Selection of inputs from UTXO's who are not used by other unconfirmed transaction
How to prevent selection of unspent transaction from UTXO's which is already used in another unconfirmed transaction ?
I am fetching list of UTXO's from here -
https://mempool.space/testnet/docs/api/rest#get-address-utxo
Trying to send bitcoins from native segwit address to all other types of addresses using bitcoinjs-lib in node js.
From list of UTXO's I am selecting the inputs as required.
If the first input is already selected for a transaction which is unconfirmed how can I prevent the selection of that first input in next transaction ?

When writing a wallet it is probably a bad idea to rely on a trusted third party to provide a list of UTXOs. I would expect any wallet application to keep a local list of UTXO's for which it has the corresponding private keys.
Then you mark UTXO's as provisionally committed when you transmit a transaction consuming them. When creating transactions you avoid selecting local UTXOs you have previously marked as provisionally committed.
If a transaction doesn't get confirmed in a reasonable time (days, weeks?) you could unmark the appropriate UTXOs in your local list.

You could maybe maintain a list/map of "reserved" UTXO's -- meaning UTXO's you're already using in a unconfirmed transaction.
Once transaction is confirmed you can update your list/map of reserved UTXO's.


text:
Can we or Should we build a public health records be kept on the bitcoin network?
Can/Should we public health records be kept on the bitcoin network?
If your answer no, would love to know why?
If your answer is yes, what do you think the most efficient way to build such a ledger?
Can it be cheap to mint (if the time of minting the record takes a while?)
Could it be done with ordinals?

No. It’s not clear to me why putting medical records on the Bitcoin blockchain would be desirable in any way. Firstly, it’s expensive to write to Bitcoin blockspace. Secondly, the data is immutable, and therefore any updates to the data would require writing even more data to the blockchain. Thirdly, all data in the Bitcoin blockchain is public. Clearly, the data should not be written in clear-text, since we’re talking about sensitive health records. Yet, even if it’s encrypted, who would you encrypt it to? If you encrypt it symmetrically with a password, nothing stops a recipient from forwarding the information or password once they learn it, which is much worse protection than the current. If you asymmetrically encrypt it to specific recipients, at least you’d need to share tweaks on the blockchain to add more readers, and either way it’s just useful to a small number of recipients. Especially if a lot of people were using the Bitcoin blockchain for this purpose, it would quickly overwhelm the Bitcoin blockchain’s data capacity.
It’s not clear to me what benefit you expect from putting health records on the Bitcoin blockchain, but I am convinced that you would be able to achieve that same benefit with a less inefficient and more suitable technology.

I don’t know if you or anyone else would agree with my theory.

Well, clearly I don’t agree, I think it’s a bad idea.

Sorry my response was cut short somehow….
Philosophically health and wealth are connected.  You’re nothing with out your health. And a trustless health system is just dying to be created.  I don’t know if you or anyone else would agree with my theory., but Offering a dynamic immutable health record solution perhaps using layer tows? would be a great service to any economy as if my research is correct, it would be deflationary for the economy (in the right places) and would bring adoption; slow ; but never the less a massive wave of adoption to the bitcoin network. Thoughts ?

I don’t see how building a “trustless health system” is helped by or predicated on putting health records on the Bitcoin blockchain. I simply don’t see how that solves any interesting problem for you.

Perhaps this idea might sound counter intuitive at this point in time.

Could you elaborate what benefit you expect from health records on the blockchain? What are you trying to achieve? Auditability, transparency, completeness, accessibility?


text:
Sign manually P2SH-P2WPKH with openssl
I have a very similar problem of my last post before post again, I tried a lot of time but whitout success. I studied this link but I don't find solution.
I have 50 bitcoins (total Amount) and I want to move 49.999991
It's my compressed public key 02c142cea1c25689d233b35c0021c47194ebc99cbc6154f7de66f2c078c1e773f3
And It's my transaction data
{
  "txid": "b4a786ec1a4263cec671aca7865ec71058230596e134c5b6bdf82d7cdc324ab6",
  "hash": "b4a786ec1a4263cec671aca7865ec71058230596e134c5b6bdf82d7cdc324ab6",
  "version": 2,
  "size": 83,
  "vsize": 83,
  "weight": 332,
  "locktime": 0,
  "vin": [
    {
      "txid": "414731e9d65e29e8830052333b316e9d882a6e93e068c4b63130a69ec67afba2",
      "vout": 0,
      "scriptSig": {
        "asm": "",
        "hex": ""
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 49.99999100,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_HASH160 a37ff6b27599b48c2e0f30fc2e4255d0d81865fb OP_EQUAL",
        "hex": "a914a37ff6b27599b48c2e0f30fc2e4255d0d81865fb87",
        "reqSigs": 1,
        "type": "scripthash",
        "addresses": [
          "2N89jRd76YdyNA7Ztw1hQJ3ofLRUHqskiZ2"
        ]
      }
    }
  ]
}

0200000001a2fb7ac69ea63031b6c468e0936e2a889d6e313b33520083e8295ed6e93147410000000000ffffffff017cee052a0100000017a914a37ff6b27599b48c2e0f30fc2e4255d0d81865fb8700000000

The new transaction digest:
TX_VERSION: 02000000

SEQUENCE: ffffffff

OUTPOINT UTXO: a2fb7ac69ea63031b6c468e0936e2a889d6e313b33520083e8295ed6e931474100000000

HASH_PREV_OUT: 4ba3331b8f45c53aabdf26d43ff3ac93c839825cf400eddb935bf47685bc9412
(HASH_PREV_OUT is SHA256 twice of $OUTPOINT)

HASH_SEQUENCE: 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044
(HASH_SEQUENCE is SHA256 twice of $SEQUENCE)

SCRIPTCODE: 1976a914555dbe4f4b6c5c8919df01dd15c2490b34383b83ac
(SCRIPTCODE is P2PKH script: OP_DUP OP_HASH160 <Public KeyHash> OP_EQUAL OP_CHECKSIG

AMOUNT: 7CEE052A01000000
(49.99999100000000000000)

OUTPUT: 17a914a37ff6b27599b48c2e0f30fc2e4255d0d81865fb87

OUTPUT_HASH: d7515382a6eed4652620ceb623aff05eb2f872e9185220ab2e456eebf2383197
(OUTPUT_HASH is SHA256 twice of $AMOUNT$OUTPUT)

LOCKTIME_PART: 00000000

SIGHASH: 01000000

Then "merge" all values and sign it.
where SIG_AMOUNT is 00F2052A01000000 (50 bitcoins)
$ WITNESS_V0_DIGEST=$TX_VERSION$HASH_PREV_OUT$HASH_SEQUENCE$OUTPOINT$SCRIPTCODE$SIG_AMOUNT$SEQUENCE$OUTPUT_HASH$LOCKTIME_PART$SIGHASH
echo $WITNESS_V0_DIGEST
020000004ba3331b8f45c53aabdf26d43ff3ac93c839825cf400eddb935bf47685bc94123bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044a2fb7ac69ea63031b6c468e0936e2a889d6e313b33520083e8295ed6e9314741000000001976a914555dbe4f4b6c5c8919df01dd15c2490b34383b83ac00F2052A01000000ffffffffd7515382a6eed4652620ceb623aff05eb2f872e9185220ab2e456eebf23831970000000001000000

The sign it, ad put the signature, the public key, the redeem script inside my transaction.
My Signed transaction is:
02000000000101a2fb7ac69ea63031b6c468e0936e2a889d6e313b33520083e8295ed6e93147410000000017160014555dbe4f4b6c5c8919df01dd15c2490b34383b83ffffffff017cee052a0100000017a914a37ff6b27599b48c2e0f30fc2e4255d0d81865fb870247304402207f49b94bf1b7251dbb56b56c32f1183cfbdf1ed379b4c118d29430f355d6b05a02201800c4c05c6ba969e7d971f52a5b52aa096d9f392122b53129c11727851c983a012102c142cea1c25689d233b35c0021c47194ebc99cbc6154f7de66f2c078c1e773f300000000
{
  "txid": "ea46711ec5e4896632c6d2b1dead1ccf954d4576d2f2c23b1790813116e7ca6d",
  "hash": "50135ee943a252816b41f7f1b25f7ec95d178178427c2b5cc6a3c2a1041f71fe",
  "version": 2,
  "size": 215,
  "vsize": 134,
  "weight": 533,
  "locktime": 0,
  "vin": [
    {
      "txid": "414731e9d65e29e8830052333b316e9d882a6e93e068c4b63130a69ec67afba2",
      "vout": 0,
      "scriptSig": {
        "asm": "0014555dbe4f4b6c5c8919df01dd15c2490b34383b83",
        "hex": "160014555dbe4f4b6c5c8919df01dd15c2490b34383b83"
      },
      "txinwitness": [
        "304402207f49b94bf1b7251dbb56b56c32f1183cfbdf1ed379b4c118d29430f355d6b05a02201800c4c05c6ba969e7d971f52a5b52aa096d9f392122b53129c11727851c983a01",
        "02c142cea1c25689d233b35c0021c47194ebc99cbc6154f7de66f2c078c1e773f3"
      ],
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 49.999991,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_HASH160 a37ff6b27599b48c2e0f30fc2e4255d0d81865fb OP_EQUAL",
        "hex": "a914a37ff6b27599b48c2e0f30fc2e4255d0d81865fb87",
        "reqSigs": 1,
        "type": "scripthash",
        "addresses": [
          "2N89jRd76YdyNA7Ztw1hQJ3ofLRUHqskiZ2"
        ]
      }
    }
  ]
}

it's seem well format but when send it, I receive that error
error code: -26
error message:
non-mandatory-script-verify-flag (Signature must be zero for failed CHECK(MULTI)SIG operation) (code 64)

Im sorry to open a very similar post, but i slightly different.
Another question is: If I obtain the well format transaction (I can do decoderawtransaction without problem) it means that the problem is the signature?

Can you check your code with testnet coins on testnet blockchain? I can send you testnet coins if you need them.

I'm using regtest

SCRIPTCODE: 1976a914555dbe4f4b6c5c8919df01dd15c2490b34383b83ac
  (SCRIPTCODE is P2PKH script: OP_DUP OP_HASH160  OP_EQUAL OP_CHECKSIG

Your script code is missing the OP_CheckSig that is 0x88 so consequently your final hash (hashPreimage) is wrong and the signature is produced from an entirely different hash digest hence is invalid.

yep! stupid error! thanks man


text:
P2SH-P2WPKH stack
I'm studying P2SH-P2WPKH and when I create the signed transaction I can see this stack (using btcdeb)
script                                   |                                                             stack
-----------------------------------------+-------------------------------------------------------------------
OP_DUP                                   | Public Key
OP_HASH160                               | Signature
3ecfc6b4....a49                          |
OP_EQUALVERIFY                           |
OP_CHECKSIG                              |

The question is
Where and When I push OP_DUP e OP_CHECKSIG?
I don't find anything inside Bitcoin code in GitHub, maybe during signrawtransactionwithkey?
I understand that the stack contains the
OP_DUP OP_HASH160 <PubKHash> OP_EQUALVERIFY OP_CHECKSIG

like P2PKH, but I don't understand why are inside the stack.
It's my UTXO and I don't find 1a83d46422201593cb8f42f44a22a29e86ad652f inside my stack.
{
  "asm": "OP_HASH160 1a83d46422201593cb8f42f44a22a29e86ad652f OP_EQUAL",
  "hex": "a9141a83d46422201593cb8f42f44a22a29e86ad652f87",
  "reqSigs": 1,
  "type": "scripthash",
  "addresses": [
    "2MufRUxRcGnwbdL4PWKzKb7uSFzBT1wQL7u"
  ]
}

UPDATE
I don't find the code inside Github, but maybe thanks to the witness program (<0 <20-byte-key-hash>>) the software is triggered and create the stack with P2PKH. For the older node is ANYONE_CAN_SPEND, for newer node check if hash160 (pubkey) == pubkeyhash and then check the signature.
In that case When the UTXO is involve only for TXID and Amount, not for validation (scriptPubKey) like P2SH and P2PKH.

I think!! Your script a ScriptPubKey (unlock script) and the operator OP_DUP create a dump of the stack whet the ScriptSig (locked script) was execute and copy on a different stack. Why this? because in past the bitcoin worked on the single stack and it was corrupted. the OP_DUP is used because now bitcoin uses more stack to verify a script. I'm only a bitcoin student, not take my answer how true, but test this or wait for a possible answer from bitcoin-dev.

Thanks, Do you have some documentation about it?

OP_DUP Duplicates the top stack item, not the entire stack

I don't know where you can found the documentation. about the operator OP_DUMP if you think, the entry stack is the ScriptSig. Maybe I have the wrong information. I only added an idea.

no, it's the public key

OP_DUP only duplicates the top stack element.

I believe I may be to blame for the confusion here. Btcdeb creates a virtual script to emulate the process of verifying the program. The latest btcdeb will now output a short note regarding this. Try running with --dataset=p2sh-p2wpkh for example of this.

The question is Where and When I push OP_DUP e OP_CHECKSIG?

You don't. Neither the transaction creating the output or the transaction spending it explicitly contain these instructions.
When verifying a P2WPKH spend (which means either the scriptPubKey or the P2SH redeemScript is exactly OP_0 <20-byte hash>), special logic is triggered which verifies the witness stack against the script OP_DUP OP_HASH160 <20-byte-hash> OP_EQUALVERIFY OP_CHECKSIG.
See the examples in BIP 141 for more information.

In that case I get only VOUT Amount and Txid from UTXO. Why I need to store informations in asm (and hex) of UTXO scriptPubKey?

I don't understand your question. What are you trying to accomplish?

In P2SH and P2PKH, I need to get informations from ScriptPubKey to unlock the transaction. In P2SH-P2WPKH I don't care about scriptPubKey a9141a83d46422201593cb8f42f44a22a29e86ad652f87 to unlock the transaction

I know that 1a83d46422201593cb8f42f44a22a29e86ad652f is hash160 of redeem script. Maybe first of all check if redeem script hash160 is equal to scriptPubKey to satisfy backwards? And "duplicate" the stack like "classic" P2SH, where older node check only this condition and "see" the transaction ANYONE_CAN_SPEND?

I have no idea what you're talking about. In all of P2SH, P2WSH, and P2SH-P2WSH, no actual locking code is in the scriptPubKey (and in P2SH-P2WSH not in redeemScript either). They all just have some fixed magical formula in scriptPubKey that says "look elsewhere for the script".

As noted above, this confusion is my fault. I've amended btcdeb to now print a notice when it does this.


text:
My lightning node is unreachable and lightning-rpc': Connection refused
I'm trying to use c-lightning on my raspberry.
When start the lightning daemon I get two errors:
the first one is:
    2020-06-05T17:02:08.784Z DEBUG connectd: Failed to connect 10 socket: Network is unreachable
...
 gossipd: seeker: no peers, waiting

My .lightning/config is:
alias=LIGHTNING_NODE_ROCK
rgb=DDFF06
addr=:9735
log-level=debug
network=testnet
bitcoin-cli=/usr/local/bin/bitcoin-cli
bitcoin-datadir=/home/bitcoin/.bitcoin
log-prefix=raspi-lightning
ignore-fee-limits=true
fee-base=10
bitcoin-rpcuser=user
bitcoin-rpcpassword=userpass
bitcoin-rpcconnect=127.0.0.1
bitcoin-rpcport=18332

my bitcoin.conf is:
testnet=1
[test]
rpcuser=user
rpcpassword=userpass
rpcport=18332
rpcconnect=127.0.0.1

telnet works on my public ip and 9735
I tried to connect to someone like:
bitcoin@raspberrypi:~ $ ln-cli connect 03ad4870c7a9dd0b429958cf9659b1330afbe33df8207cd1c882798cdad1dfb039@5.95.80.47:9737
{
   "code": 401,
   "message": "5.95.80.47:9737: Connection establishment: Connection timed out. "
}

the second problem is:
2020-06-05T17:02:08.864Z UNUSUAL plugin-bcli: Could not connect to 'lightning-rpc': Connection refused
2020-06-05T17:02:08.865Z INFO plugin-bcli: bitcoin-cli initialized and connected to bitcoind.

My Info is:
bitcoin@raspberrypi:/mnt/hdd/bitcoin $ ln-cli getinfo
{
   "id": "0310e9f97def619a7ee02b321cf2fad4f67b59f2c6bd12456dc8d6d8be125e1b14",
   "alias": "LIGHTNING_NODE_ROCK",
   "color": "ddff06",
   "num_peers": 0,
   "num_pending_channels": 0,
   "num_active_channels": 0,
   "num_inactive_channels": 0,
   "address": [],
   "binding": [
      {
         "type": "ipv6",
         "address": "::",
         "port": 9735
      },
      {
         "type": "ipv4",
         "address": "0.0.0.0",
         "port": 9735
      }
   ],
   "version": "v0.8.2-198-g0f568e1",
   "blockheight": 1747789,
   "network": "testnet",
   "msatoshi_fees_collected": 0,
   "fees_collected_msat": "0msat",
   "lightning-dir": "/home/bitcoin/.lightning/testnet"
}

My testnet is fully sync and I'm able to use rpc calls form my bitcoin-cli
bitcoin@raspberrypi:/mnt/hdd/bitcoin $ bitcoin-cli echo hello world
[
  "hello",
  "world"
]

I don't have any firewall

The first error you are seeing might be related to a previous peer that is no longer reachable. The type of the error (Failed to connect 10 socket: Network is unreachable) suggests that it is using a network that is no longer available. This can be because the peer was connected through Tor, or IPv6, and the Tor proxy isn't running anymore, or the network configuration changed and doesn't support IPv6 anymore. It could also be during OS startup that the network device just isn't ready yet, and this is just transient.
Regarding the connection timeout when attempting to connect to another node, it's likely just not online. I went and checked with nmap if the node is online, and it wasn't when I checked:

Starting Nmap 7.60 ( https://nmap.org ) at 2020-06-06 13:47 CEST
Nmap scan report for net-5-95-80-47.cust.vodafonedsl.it (5.95.80.47)
Host is up.

PORT     STATE    SERVICE
9737/tcp filtered unknown

Nmap done: 1 IP address (1 host up) scanned in 2.05 seconds

So that's nothing out of the ordinary. Might I suggest connecting to some other node?
And finally the UNUSUAL plugin-bcli: Could not connect to 'lightning-rpc': Connection refused error is an artifact from the order in which we start up the plugins and the RPC interface: usually plugins are told that we are ready only after the RPC is made available. The bitcoin-backend plugins are a bit special, because they are needed to check whether we are in sync with the bitcoin network and that we can talk to bitcoind. Therefore the bcli plugin starts before the RPC is ready. The error can be safely ignored and we'll make it less verbose soon (see Github Issue #3553).
Disclaimer: I am one of c-lightning's developers.

Thanks for reply. Now I'm able to connect to another node, but I don't understand how I can't find my id in that service https://1ml.com/testnet/, my id node is 0310e9f97def619a7ee02b321cf2fad4f67b59f2c6bd12456dc8d6d8be125e1b14@93.55.242.131:9735. and my lightning config is:https://pastebin.com/QNQvecVY

In order to be part of the gossip you'll need to open at least one channel. Since you opened some channels you can now be found on network explorers. If you don't have any open channels nodes will forget about your node as well.


text:
How to implement stake.com model of deposit & withdraw flow for my crypto poker casino?
In stake.com for each user they generate separate bech32 address for deposit & displays the deposited amount as balance in top of the navigation bar.
Similarly for withdraw they just ask for the amount to be withdrawn & receiver address for withdrawal.
Currently for our setup we're generating bech32 address with publicKey & privateKey using node JS. But for sending transaction to another bech32 wallet it's more complicated to calculate transaction fee & sochain.io costs too much.
How to implement this model of deposit & withdraw model for my crypto poker casino?

Are you asking how you can estimate the transaction size in advance, or how you can reduce your cost for facilitating a high payment volume on Bitcoin?

Your question is very broad and depends on a lot of circumstances.
The most straight-forward approach to any hot web wallet is building your solution on top of bitcoin-d and the existing JSON-RPC API. (https://developer.bitcoin.org/reference/rpc/)
There are libraries for almost every language.(https://en.bitcoin.it/wiki/API_reference_(JSON-RPC)#Languages)

Run a dedicated server/VPS
Install bitcoin-d at your preferred version
Update bitcoin.conf if you want pruned, also you can set walletnotify here which works like a callback that will ping or run a script of your choosing whenever funds are received to the wallet.
Familiarize yourself with the wallet JSON RPC calls (https://developer.bitcoin.org/reference/rpc/#wallet-rpcs)

Implement into your site as necessary.


text:
Pruned Bitcoind Backend for LND with txindex enabled for version > v0.13.0
I'm looking to prune a bitcoind node that will be used by LND.
https://github.com/lightningnetwork/lnd/commit/410b30b9caaf59a78a29d8b924e14395b7daa59d
From the LND commit recently by Kixunil.
Note that since version 0.13 pruned nodes are supported
although they cause performance penalty and higher network usage.

I ideally would want to delete all block data before ~March 2018.

What are the bitcoin-cli cmd(s) to prune Bitcoind while txindex is enabled?
Is it possible to avoid the potential "performance penalty and higher network usage"?

Edit: txindex is not compatible with pruned nodes in the generic sense. If you know a use case won't require older blocks, is there a way to get the best of both worlds (meaning txindex enabled and removing old blocks)?

AFAIK, txindex=1 helps performance with LND.
If we know lightning nodes aren't going to need the first ~8 or so years of blocks, do we really need to hold on to them? Possible to not suffer the penalties of txindex being off for this use case?


text:
Taproot, potential quantum bug, and general clarification
Here seeking information. I have 2 questions marked with parens
Would like some clarification pertaining to the Mark Friedenbach article:

Why I'm Against Taproot

The point of contention with Mark seems to be with the space savings for the N-N Musig2 everyone signs/happy path, being embedded into the the root of the MAST/Taproot, thus exposing a pubkey in an output that sits on the blockchain.
(1) please correct if I'm wrong about the way I'm describing this.
I did see Pieter's presentation at Bitdevs from a while back reference, "plain pubkey security model in mind" for taproot. But, it wasn't apparent that this would hypothetically make it quantum vulnerable,.. as Mark's article says, "a naked secp256k1 pubkey on chain at the time the output is created which has absolute spend authority for the underlying bitcoins".
(2) Would love for someone to rebut or verify this claim.

See https://bitcoin.stackexchange.com/a/95133/208

Help me understand something.. a pubkey for bech32 (native segwit v0) is only revealed on a spend. Segwit v1 will make it where a pubkey is available before a spend?

Yes, the (tweaked) pubkey goes directly in the scriptPubKey.

See Pieter's responses.
(1) seems ok
(2) Mark's concern is real, but worry about exposing the tweaked pubkey doesn't seem to be of a high concern to people supporting Taproot. In ref to Taproot exposing pubkey, "numerous advantages (it's smaller, cheaper, and makes a number of more advanced protocols on top a lot easier)."
"TL;DR: public keys should be public."
Quotes from:
What are the potential attacks against ECDSA that would be possible if we used raw public keys as addresses?


text:
walletprocesspsbt rpc not signing psbt tx
After extensive regtest testing I've been unable to reproduce this issue.
This is a gist to regtest psbt commands that do work.
https://gist.github.com/miketwenty1/ecb9acdbca858878f1856b75493fef4c
wpkh() + tr() are the descriptor inputs used for each and in the same format.
The step on main chain where I'm getting stuck is when I try to do a walletprocesspsbt.
I will get a "complete": false instead of "complete": true
When I run analyzepsbt It says I'm missing a signature.
{
  "inputs": [
    {
      "has_utxo": true,
      "is_final": false,
      "next": "updater"
    },
    {
      "has_utxo": true,
      "is_final": false,
      "next": "signer",
      "missing": {
        "signatures": [
          "<some_hex_sig>"
        ]
      }
    }
  ],
  "estimated_vsize": 204,
  "estimated_feerate": 0.00010078,
  "fee": 0.00002056,
  "next": "updater"
}

This is confusing for me, because when I run ./bitcoin-cli listunspent
Both of my UTXO's are

"spendable": true
"solvable": true
"safe": true

Question:
What are the next steps in troubleshooting why my wallet can't sign this this psbt transaction?
Note:
This looks like a similar issue that never really had a conclusion:
Why isn't my PSBT considered complete after walletprocesspsbt and finalizepsbt?

In my frustration I followed what francois said he did, I just reimported and now everything magically works.. the unspent utxo's have not changed. I'm thinking this is a bug.