text:
Less circuitous way to get network fee in raw transaction
I have my code working correctly now to create and send a transaction with the correct network fee. Here is my pseudo-code using the json rpc:

Estimate network fee using estimatesmartfee "ECONOMICAL" based on a typical transaction size
Adjust payout amount based on fee estimate
createrawtransaction using estimated payout amount
signrawtransaction
read size of decoded raw transaction from step 2
Recalculate network fee using estimatesmartfee "ECONOMICAL" based on a actual transaction size from last step
Adjust payout amount based on actual network fee
createrawtransaction using actual payout amount
signrawtransaction
sendrawtransaction

Steps 6-9 repeats Steps 1-4.
Is there a way to do this without having to call everything twice?

Are you using inputs that are available to the Bitcoin Core wallet?

@AndrewChow, before the pseudo-code begins, I already know the txid and the vout for my input. This tx will not be one from my wallet; it will be a tx created by someone else.

If the inputs to the transaction are known to the Bitcoin Core wallet, then you can use the fundrawtransaction command to skip fee estimation and input selection. The process then becomes:

createrawtransaction with only the outputs you want (i.e. no change, only the recipients).
fundrawtransaction
signrawtransaction
sendrawtransaction

If you are not using Bitcoin Core's wallet, you can use effective values.
Presumably you know the amounts in the inputs before you actual create the transaction. So you can then calculate how large the inputs will be, calculate how much in fees that will cost based on the output of estimatesmartfee, and subtract that fee amount from the actual value of the input. This is your effective value.
When you create the outputs, you calculate the total size of the non-input data and calculate the fees for those data. Now you have how much total value your inputs must cover. You can then select coins that way.
So the process is:

estimatesmartfee
For each potential input, calculate the fee for that input and compute the effective value.
For each output (including change if you assume that there will be change) and for the extra fixed size transaction overhead, calculate the non-input fees.
Add the non-input fees to the amount you want to send, this is the amount that your inputs will need to cover the total cost.
Choose the inputs you want to spend based upon their effective values.
createrawtransaction, signrawtransaction, sendrawtransaction.

The size of inputs in vbytes are as follows:
P2PKH: 148 vbytes
P2WPKH: 37 vbytes
P2SH-P2WPKH: 60 vbytes
For P2SH and P2WSH inputs, it depends on the script that you are using. Most people though will be using P2PKH, P2WPKH, or P2SH-P2WPKH.


text:
How to generate a new extended public key (xpub)?
I have a need to generate a new extended public key (xpub).
Examples:
xpub6CUGRUonZSQ4TWtTMmzXdrXDtypWKiKrhko4egpiMZbpiaQL2jkwSB1icqYh2cfDfVxdx4df189oLKnC5fSwqPfgyP3hooxujYzAu3fDVmz

tpubD6NzVbkrYhZ4WLczPJWReQycCJdd6YVWXubbVUFnJ5KgU5MDQrD998ZJLNGbhd2pq7ZtDiPYTfJ7iBenLVQpYgSQqPjUsQeJXH8VQ8xA67D

How can I do this?
I would like to do it inside json rpc, because that would help automate testing, but I ultimately don't care how I get them. They are for testing.

You can generate new extended public keys on
http://bip32.org/
You can generate them for testnet or mainnet. Just set the network combo box in the upper right to the network you want.

ADVISO: Please don't ever use websites to generate key material. Suitable only for throw-away addresses for testing only.

You can do that, but each HD seed needs to be inside its own wallet file which is loaded by the server. Running bitcoind with multiple -wallet arguments will achieve what you are aiming for. Currently it is not supported to dynamically load and unload wallets at runtime, but support for that is being added and will be available in a future release.

Exporting xpub from bitcoin node doesn't server purpose as it uses hardened key derviation... you need to export the xprv https://bitcoin.stackexchange.com/questions/50244/how-to-get-xpub-or-mpkbip32-for-my-bitcoin-core-wallet?noredirect=1&lq=1

@toddmo you can generate a valid xpub any way you like if you just want one for testing, it doesn't have to be the same one as the one in your wallet

ok I put a lot of effort into editing my question and doing research, which provided an answer, which may not be the best. Sorry but I needed to learn what I needed to ask and cut out all the extraneous babbling in my original question. Now you can see what I really want by looking at my edited question and my new answer. Again, sorry. Feel free to give a better answer than mine.

It's worth noting that Bitcoin Core can load and unload wallets at runtime since 0.16.

source: Stack Exchange

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

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

sort: votes


text:
How to specify testnet via curl against json-rpc?
The testnet=1 option can be (not) specified in the bitcoin.conf file (thus causing it to be on mainnet by default), and this can be over-ridden in bitcoin-cli with the -testnet command-line option.
But, when using the json-rpc interface via curl, I can't figure out how to specify I want testnet in this case. I can put the testnet port 18332 in the url, but I don't know how to use any other "command line" switches when using curl?
Can I do it with curl?

The port 18332 is the specification you speak of.
When the testnet bitcoind is running on your system, port 18332 is open to accept rpc's. In case of mainnet, that port changes to 8332.
Every thing that you can do from the commandline is accessible via curl on that port.

Note that I did have to remove testnet=1 and rpcport=8332 from the bitcoin.conf in order to have this flexibility. Good answer.

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


text:
Best way to distribute bitcoin to heirs in a will
I see on [bitaddress][1] you can generate a split wallet. That's where multiple parties have to each submit their "share" keys to generate the combined private key.
So the hard part, the math, has already been done.
But, I'd like a system that has the following advantages if possible:

No lawyers / legal contract required
No trust required among the heirs
If an heir dies after me but before the distribution, the surviving heirs can divide the inheritance equally
While I'm alive I can freely use my bitcoin, and move it around, without worrying very much or at all that my heirs won't be able to find it
My heirs can't see my private keys while I'm alive
Non-heirs can't ever see my private keys
My heirs can find what they need to get started after I'm gone, without too much trouble

It's probably going to have to be a combination of a physical safe, a physical key, and the online stuff and software.
I'm willing to make the assumption that my heirs will know beforehand how to initiate the process with the physical key, and that they aren't going to take their inheritance early by force (e.g., breaking into my house).
I'm also willing to use a dead man switch website. That might be like an email that I must respond to every month or else it emails all of them their keys / instructions. Note I don't know what that website might be.
Has anyone thought through a process? Even a different process that doesn't have all the advantages I'm looking for might give me ideas.

To meet your requirement of freely using your bitcoins and moving them around, a deterministic wallet such as Electrum may suit well. In that case, you'd just need to share the wallet seed (and some details on how to use it), perhaps with half of the seed stored in each of 2 secure facilities to protect against theft.
That doesn't meet some of the other requirements, such as handling an equal split, but writing a will could handle that part reasonably effectively (though still with some chance of human error or fraud).

I voted up because a seed key, like a BIP39 is probably part of the solution

Helpful websites:
Dead Man Switch is not free at the level of service a typical person would need, but the fee is a $20 lifetime fee, so it's cheaper than what it would cost me to build the same mechanism. It will send different messages to different recipients if I don't respond to 3 keep alive messages within a 60 day window. This website doesn't deal with bitcoins, however, so it can't automate the actual distribution.
Passphrase allows a document to be stored online with a password to decrypt it. This could be the will itself and you could have a slightly different document for each heir with a different passphrase. I don't know how secure it really is, but it's really easy to use.
bitaddress needs to be stored locally! Just go there and do Save As.... Unplug your internet before using it. It has split wallets and paper wallets, which are perhaps part of the solution.

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


text:
Bitcoin market hours (open/close prices)
If Bitcoin trading never stops then what does it mean when news sites and others talk about bitcoin opening or closing at a certain price, and why is this terminology used?
Could two people mean different things when they talk about the closing price at the same date? (apart from price differences between exchanges)

In 24 hour markets High and Low usually mean "highest/lowest price in last 24 hours".
Open generally refers to the price at 12:01 AM UTC of any given day and close generally refers to the price at 11:59 PM UTC of any given day.

For the Gemini exchange the closing price is at the time of their daily auction at 4pm ET.
You can read more about the auction here:
https://gemini.com/marketplace/
And why it is considered their "end of day" price here:
http://www.coindesk.com/winklevoss-exchange-gemini-bitcoin-auctions/ with a quote from one of their founders.

Traditional markets are not open for trade all day, so the opening and closing price refer to the first and last price of the day. They are used as measurements for the trading activity of a day.
Since Bitcoin exchanges are open 24/7, I would expect the opening price to refer to the price at midnight and the closing to refer to the priceat 23:59:59 in the exchange's respective timezone. Since closing of the previous day is essentially the same as opening of this day, some pages such as e.g. CoinDesk only show the closing values for the historical data.
Closing price should always be the last price of the day, so it should be unambiguous.

What about timezones?

Well, it's the opening and closing of the market, so it should be in respect to the market's timezone. I.e. if you were in London, for you a market in Shanghai would open at 4pm (UTC+8), a market in Berlin at 11pm (UTC+1), and a market in NYC at 4am (currently UTC+4, due to their summertime being longer than Europe's).

So pretty clear if talking about a specific exchange, and pretty confusing if saying "bitcoin closed at X" (of course that is also confusing because the price differs between exchanges)

Ooooh. I hadn't even realized that it could be read that way. Then maybe the last price in that timezone; what exchange though, or an index?

Bitcoin price indices are made up of prices from different exchanges in different timezones. What exactly does the index closing price for a date consist of?

This answer is somewhat misleading.  For traditional markets, the open and close prices have significance and are calculated according to methodologies.  For 24 hour markets, like currencies, there are standard price fixes in addition to closing regional prices.  For crypto, where often people adopt similar language of traditional markets (but perhaps without understanding the nuances), it essentially means a random trade that just happened to be the first or last in a given day.

I only know about one exchange for sure but I'm pretty confident this is a widespread concept and applies to many other exchanges, too.
https://www.bitcoin.de uses candlestick charts. These charts exist in traditional markets, too. There, a candle stick typically represents 1 day. That day has among others an opening and a closing price. Note that the closing price December 29th doesn't have to be the opening price of December 30th and the opening price of December 29th wasn't necessarily the closing price of December 28th, in such markets. In fact, it's fairly unlikely that these prices are the same.
https://www.bitcoin.de always trades. Its candlesticks are different.
First of all, they have different sizes depending on the length of the period of time the diagram shows. In the 48 h chart, they only are 15 minutes wide. In the 1 Y chart, they are as wide as in old markets: 1 day. In the 5 Y chart, they are a week wide.
Furthermore, the closing price of one candlestick is always the same as the opening price of the next one. This is because they simply slice time up on the clock (00:00, 00:15, 00:30, etc.) or calendar (December 29, December 30, December 31th, etc.). Every time slice's opening price is the price when that time slice started and its closing price is the price when it ended. Because the one time slice begins right when the one before it ends and price is is simplified to a function of time, the opening price of a slice must always be the same as the closing price of the previous one.


text:
Leading zeros and numbers of hashes before arriving to solution
Had been reading a post written by Adam Back a couple years back (no pun intended) with regards to calculating bitcoin difficulty in bits (so we could arrive to the number of hashes roughly needed before a solution to a block is found).
The equation being log2(difficulty)+32.
Link: https://bitcointalk.org/index.php?topic=192886.0
From his post I also understood we could also find the difficulty in bits via the block hash in hex, i.e. each leading zero * 4, then check the next hex char with the following rule: >7=+0bits, >3=+1bit, >1=+2bits, 1=+3bits.
Question being:

What is the intuition to Adam's elaboration of >7=+0bits, >3=+1bit, >1=+2bits, 1=+3bits? Maybe there is something with regards to hex conversion that I need to catch up on?
With log2(difficulty)+32, we could arrive to a fractional bit (e.g. 54.8713). Would it be possible to derive the same fractional bit given the leading block hash values, or are we at best left with an approximation?

Thanks in advance!

Look at these numbers in binary.  A hex digit is 4 bits, so 7 in hex is 0111 binary, 3 is 0011, 1 is 0001.  You can see that 7 is the largest hex digit in which the most significant bit is 0; 3 is the largest hex digit in which the two most significant bits are 0; and so on.
Yes, you can get this same value by taking the log2 of the hash value and subtracting from 256 (which is the total number of bits in the hash).  Note that the number of leading zero bits of the hash (including "fractional bits") is required to be less than or equal to the target difficulty, but in general is much more likely to be less.

I sincerely, sincerely appreciate your response. Thanks a ton @Nate.


text:
Hardware wallet can be used anywhere?
I haven't yet traded any cryptocurrencies. I'm planning to buy BTC through Coinbase then exchange BTC for a small amount of XRP.
The main reasons for going with Coinbase is it's safe, well regulated and I'll always want an account there. For XRP, I'll use changelly.com since they are popular, have low fees, and haven't been hacked (yet).
A big concern is safety. Coinbase probably has a good wallet but I'd like to use a hardware wallet since I'll be using other exchanges for various alt coins not offered on Coinbase. I don't really trust other exchanges and hence the hardware wallet.
Is a hardware wallet the safest option in this case? Are there any issues using it at Coinbase and Changelly?
Do I still need to setup wallets at exchanges I'm using?
When using a hardware wallet, from what I understand, you plug it into your computer via USB and do whatever transaction at whatever exchange. Once complete, you unplug it. From this, it basically can't ever get hacked?

I think you're slightly misunderstanding how a hardware wallet works. You cannot have your coins simultaneously stored on a hardware wallet, and accessible to trade on an exchange. You can store your coins on the hardware wallet, but then if you'd like to trade, you'll have to send a transaction depositing them to your exchange of choice. When done trading, you'll request a withdrawal to return the coins back to your hardware wallet.

Hardware wallets are easy-to-use ways (compared to paper wallets (hard to use) and software wallets (not as safe as hardware wallets)) of being in control of your private keys hence the safest and the easiest way of using and storing cryptocurrencies.
When you use a (traditional) exchange as a wallet, you won't be in control of your private key so the exchange can steal your funds or get hacked and lose them etc.
There are decentralized exchanges where you don't need to deposit your funds (thus you don't need to trust, a.k.a trustless) like RadarRelay. You can use them with software wallets and some of them with hardware wallets directly.
Don't forget that cryptocurrencies' reason of existence is being trustless, don't hand over your funds to anyone, always be in control of your private keys.

I'll start with Coinbase, since I'd like to initially buy BTC. I'll use their wallet. Once the Ledger wallet comes in, I can move everything out of the Coinbase wallet onto Ledger. Security issues solved. As for RadarRelay, it's only ETH right? Seems a bit useless if so.

RadarRelay let's you trade dozens of ERC20 tokens, not only Ether. There are other decentralized exchanges as well, not just RadarRelay.

Doesn't a hardware wallet defeat the purpose of something like RadarRelay since you don't ever have anything on an exchange?

@4thSpace No, you still need decentralized exchanges to exchange in trust-less fashion. Hardware wallets let you transact not exchange.

So instead of transferring BTC to something like www.bitfinex.com and then buying XRP, I could use RadarRelay and go straight from my hardware wallet -> BTC -> XRP? Guess I'm still not getting it.

@4thSpace You could, except RadarRelay doesn't trade Ripple. Read this for alternatives: https://www.google.com.tr/amp/s/coinsutra.com/best-decentralized-exchanges-dex/amp/

@4thSpace I think you didn't understand enough the of concept of public and private keys, that's why you are confused.

@ferfit: If it doesn't trade Ripple, there isn't a reason to use it.

@4thSpace Such a Ripple lover : )

Actually, there's quite a lot that can't be used on there.


text:
Transaction taking a long time to confirm, now it doesn't even show up on Bitcoin Explorer
UPDATE: Electrum now says the transaction is "Local" and now I have an option to "broadcast", should I do that?
OP:
So, I'm trying to spend a small amount of bitcoin on a website (not relevant) and I send over 0.0010346 BTC with a fee of 0.0000543 BTC  ( 30.2 sat/byte ) and it's been almost 24 hours, and it still hasn't confirmed. The website stated it saw my payment, and will convert my BTC into balance once the BTC gets confirmed, and it's stressing me out because I'm afraid my BTC was lost somehow... I'm generally new to BTC so any help is appreciated.
The transaction used to show up on Bitcoin Explorer (blockstream.info) which is what my wallet (electrum) directs me do, and now it doesn't?!? Really stressing me. Transaction id is c4bea179e5e772b131c475f9030088b67dea5054a545713dc32458829fa61598

Hi Connor,
I think the main gist of your question is addressed on https://bitcoin.stackexchange.com/questions/50064/how-to-unstuck-a-low-fee-transaction-with-electrum. Could you please check that topic out? A transaction at 30 sat/B is probably going to confirm sometime next week.


text:
Is the potential number of blocks in the Bitcoin blockchain limited?
i.e. Is there a finite number of transactions that will ever take place using Bitcoin?
I have Googled this somewhat and found discussions about Bitcoin's limited, finite supply, but it's unclear to me whether the blockchain itself is a finite resource.

No, there is no limit on the number of blocks in blockchain. The transaction can go on for ever.
The limit is only on the bitcoin that will ever be produced in the environment (Why was 21 million picked as the number of bitcoins to be created?) , but no limit on the number of times it can be exchanged.

The finite amount of Bitcoin (21,000,000) has little to do with the number of blocks in the blockchain. Although the miners (the people who create the blocks) are rewarded with newly generated Bitcoin which will get fewer and fewer by time, they will still create blocks after they get no newly generated Bitcoin at all. Why? Because they get the fees in addition. In the far future all miners will be rewarded with the fees only and still generate blocks.


text:
How to produce a Hash160 bitcoin address?
tl;dr
How should one perform Hash160, using most basic tools?
====================================================
Hi,
I'm trying to figure out, how transactions work in bitcoin.
When I choose inputs for a new tx I want to make sure they belong to a specific address. However, existing txs do not specify previous outputs' addresses, but instead they contain address' hashes.
e.g.:
>> bx fetch-tx 11a1b7ac0a65bd50b7094c720aecd77cfd83d84b1707960fd00dd82a888aab5c --config /home/theo/Desktop/bx-testnet.cfg

{
    hash 11a1b7ac0a65bd50b7094c720aecd77cfd83d84b1707960fd00dd82a888aab5c
    inputs
    {
        input
        {
            address_hash f3b7278583827a049d6be894bf7f516178a0c8e6
            previous_output
            {
                hash 4a3532061d43086299ae9b2409a456bb9638dff32e0858c4ccda27203fb2e4f6
                index 1
            }
            script "[30440220146b8b5b014245a9e27e21122d4dded04c3f39c3a49ac2494743d6f6ae8efff602206d417a4be9c7431ea69699132438510ade1cf8d746607f77d114907762ed1eb301] [023dd2e892290e41bb78efce6ea30a97015ef13eaaa9ebb7b0514485fc365cc391]"
            sequence 4294967295
        }
    }
    lock_time 0
    outputs
    {
        output
        {
            address_hash a73706385fffbf18855f2aee2a6168f29dbb597e
            script "dup hash160 [a73706385fffbf18855f2aee2a6168f29dbb597e] equalverify checksig"
            value 130000000
        }
        output
        {
            address_hash ad6e80394af99ece5d7701bf2f457480b93965b7
            script "dup hash160 [ad6e80394af99ece5d7701bf2f457480b93965b7] equalverify checksig"
            value 49525957813
        }
    }
    version 1
}

Say, I want to check which of the outputs can be sent from address mvm74FACaagz94rjWbNmW2EmhJdmEGcxpa
So I take its Hash160 in Python:
>> hashlib.new('ripemd160', hashlib.sha256("mvm74FACaagz94rjWbNmW2EmhJdmEGcxpa".encode('utf-8')).digest()).hexdigest()
'748598cd9b004aecf8a2d97464fb1f2a90562ffe'

That is not the result I expected: a73706385fffbf18855f2aee2a6168f29dbb597e
Meanwhile, this online service calculates hash correctly.
How do I Hash160 a bitcoin address, preferably in Python?

while I can't help with python, you may want to look at "http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html", it has good explanation. Also I'm not sure if I understand  your logic with the addresses to spend from. You would use the UTXOs from previous transactions... So I'd use "listunspent" in the core wallet, to see the prev tx ID and the vout, to use in a new (unsigned) transaction. An address hash cannot be reversed easily, that's why we have hash functions. Easy to go into one direction, impossible to reverse. That gives us the security in the whole bitcoin network.

@pebwindkraft But I need the script in previous output to sign, don't I? Also, seems to me I got the encoding idea wrong. Hash160 clearly has bytes bigger than 3a (58 decimal), so my decoding function is nonsense

yes, you give it the scriptPubKey, see the meanwhile famous 19step example, and some python at the end: here: https://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-tx

The address is already a hash, together with a 4-byte checksum and a version byte.  To get from an address to a hash160, you don't have to compute sha256 or ripemd160 of anything.  You just have to decode it from base58 back to hex, and discard the unwanted junk.
If you take mvm74FACaagz94rjWbNmW2EmhJdmEGcxpa and base58 decode, you get
 6FA73706385FFFBF18855F2AEE2A6168F29DBB597EF59C240B
 VVxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxSSSSSSSS

The first byte (6F) is the version byte; discard it.  The last 4 bytes are the checksum; discard it.  The remaining 20 bytes are the hash160 of the public key corresponding to the address.

I have already answered this question on StackOverflow, but I guess I'll just repost the answer here.
Finally I've made it.
Some revelations in my answer may look obvious and basic to you, but I hope they'll be helpful to the people that are completely new to Bitcoin (such as me).

Wiki says that I can get Hash160 by reversing last step of address production

(Hash160 is higlighted)
This step is encoding a byte string with base58 alphabet
b58 = '123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz'

This alphabet lacks 0, I, l, O, as these symbols are easy to mix up. And that's the last thing you want to do when one wrong symbol may lead to losing a fat amount of money.
Thus, we need to turn mvm74FACaagz94rjWbNmW2EmhJdmEGcxpa into a byte-string. Bytes go in hexadecimal format and may range from 0x00 (0 decimal) to 0xff (255 decimal).
And mind that we have a special b58 alphabet to deal with: decoding the address with utf-8 or other encoding standards will yield nonsense.
At first I thought that I can easily decode the address with this function:
def decode(addr):
    b58 = '123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz'
    decoded = ''
    for i in addr:
        temp = hex(b58.index(i))
        if len(temp) == 3:
            temp = '0' + temp[-1]
        else:
            temp = temp[2:]
        decoded += (temp)
    return (decoded)

decode('mvm74FACaagz94rjWbNmW2EmhJdmEGcxpa')

>> '2c352c06030e090b212127390803312a1d22152c1d010d2c2811242c0d0f23372f21'

But the result is nothing like the hash I looked up in the transaction (a73706385fffbf18855f2aee2a6168f29dbb597e). This way I learned I had no idea how decoding is done. What if Hash160 has 0xff ? There's no such symbol in b58, as 58 in hex is just 0x3a. While decoding b58 we can't treat each symbol independently. The whole address makes up one  giant number written in base58 numerical system (its first digit corresponds to 58**34).
To get the byte string I first turned this number into a decimal and only then in byte-string.
If you know how to avoid this detour and get bytes directly -- please comment
def decode(addr):

    b58 = '123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz'

    def base58_to_dec(addr):
        dec = 0
        for i in range(len(addr)):
            dec = int(dec * 58 + b58.index(addr[i]))
        print('Decimal representation')
        print(dec)
        return(dec)

    def dec_to_byte(dec):
        out = ''
        while dec != 0:
            print(dec)
            remn = dec % 256
            dec = int((dec - remn) / 256)
            temp = hex(remn)
            if len(temp) == 3:
                temp = '0' + temp[-1]
            else:
                temp = temp[2:]
            out = temp + out
        return(out)

    dec = base58_to_dec(addr)
    out = dec_to_byte(dec)
    return (out)

decode("mvm74FACaagz94rjWbNmW2EmhJdmEGcxpa")
>> Decimal representation
>> 700858390993795610399098743129153130886272689085970101576715
>> '6fa7370638600000000000000000000000000000000000000b'

That output looks somewhat like what I need (a7370638...) but has way too many zeroes. Don't look that the first byte (6f) doesn't match: it has nothing to do with Hash160 we need, just protocol version.
This is likely a precision error. To deal with it, I used mpmath which lets you operate with integers precisely.
import mpmath as mp
mp.dps = 1000

def decode(addr):

    b58 = '123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz'

    def base58_to_dec(addr):
        dec = 0
        for i in range(len(addr)):
            dec = int(dec * 58 + b58.index(addr[i]))
        return(dec)

    def dec_to_byte(dec):
        out = ''
        while dec != 0:
            remn = mp.mpf(dec % 256)
            dec = mp.mpf((dec - remn) / 256)
            temp = hex(int(remn))
            if len(temp) == 3:
                temp = '0' + temp[-1]
            else:
                temp = temp[2:]
            out = temp + out

        return (out)

    dec = base58_to_dec(addr)
    out = dec_to_byte(dec)
    return (out)

Apply precise modulo operation and we can finally get the Hash160. Just make sure you trip the first and last 4 bytes that carry fat-finger check.
x = decode('mvm74FACaagz94rjWbNmW2EmhJdmEGcxpa')
print(x)
>> 6fa73706385fffbf18855f2aee2a6168f29dbb597ef59c240b

print(x[2:-8])
>> a73706385fffbf18855f2aee2a6168f29dbb597e

Yay! Just like in the transaction!

I've tested the last code example and it prints the wrong value. print(decode('mvm74FACaagz94rjWbNmW2EmhJdmEGcxpa')) prints 6fa7370638600000000000000000000000000000000000000b instead of 6fa73706385fffbf18855f2aee2a6168f29dbb597ef59c240b (Python 3).

Python 3
Install base58 (pip3 install base58) and use the following code:
import base58
print(base58.b58decode_check(b'mvm74FACaagz94rjWbNmW2EmhJdmEGcxpa').hex()[2:])

One-liner:
$ echo 'import base58; print(base58.b58decode_check(b"mvm74FACaagz94rjWbNmW2EmhJdmEGcxpa").hex()[2:])' | python3
a73706385fffbf18855f2aee2a6168f29dbb597e

Script to convert file with list of addresses to the corresponding hashes:
while read addr; do python3 -c "import base58; print(base58.b58decode_check(b'$addr').hex()[2:])"; done < btc.csv > btc.hash

Install base58 package (Ubuntu: sudo apt-get install base58) then run the following:
$ printf mvm74FACaagz94rjWbNmW2EmhJdmEGcxpa | base58 -d | xxd -p
6fa73706385fffbf18855f2aee2a6168f29dbb597ef59c240b

To decode into address, use:
$ printf mvm74FACaagz94rjWbNmW2EmhJdmEGcxpa | base58 -d | cut -c2- | xxd -p | head -c40
a73706385fffbf18855f2aee2a6168f29dbb597e


text:
Exit Strategy: How to communicate / configure my fiat bank when selling large amounts of crypto in a short period of time
Anyone can readily see by my previous questions that I have virtually no idea what I'm doing. Be that as it may, it seems very realistic that I may become a bitcoin (multi?)millionaire within the next 12-36 months. I am rapidly headed in that direction with no further action necessary on my part.
If I get to that point, I'm not going to wait around to see if I can become a billionaire. I'm going to get out at a level I can buy a house and retire.
However, I am not prepared for all this. I know even less about being rich than I do about bitcoin. And one of my questions is becoming

How is my bank going to react to massive amounts of deposits in a short period of time? (For example, $100,000+ a month as I liquidate my crypto)
What can I do to keep my bank from some type of adverse reaction: freezing my account or launching an investigation or worse?

I will have records from the exchanges (including local bitcoins) of every sale documenting it's a crypto-currency sale as opposed to some kind of proceeds from criminal activity. And I will set aside the 15% for capital gains needed to give the IRS.
I don't consider myself a paranoid person; however, the owner of my bank is the man who called bitcoin a fraud.
Update
Lo and behold, what I fear is not imaginary. It actually happened to at least one guy. See this reddit article. Like him, almost all my transactions are to / from Chase and Coinbase. And here's another guy, same thing:

Update 2
I called Chase and I was very blunt about my intentions. I realize their Customer Support Department is probably the least in the know with regards to what the Fraud Prevention Department would or wouldn't do in a given situation. But they told me, if I started making large deposits frequently, they would pull me aside and, and offer me an upgraded set of accounts. He told me it's no different than being successful with an E*Trade account. I am also gradually working to get my Coinbase limits increased by progressively making larger and larger transactions on their site. So, when I'm ready to sell I can sell and withdraw more in a given period of time.

I'm voting to close this question as off-topic because you should consult a financial advisor at your local jurisdiction

The one thing not to do is to try to adjust the amounts or timing of your transactions to minimize scrutiny or reporting.  That is a crime in itself ("structuring", 31 USC 5324 (a) (3)), even if the transactions themselves are perfectly legitimate.

To cover your bases, you might like to get an account with a different bank just in case your current one gives you trouble?

@HighlyIrregular, I appreciate your suggestion, but my goal is to prevent the trouble from occurring in the first place, not run away from it, so I would like to know what all I can do with my bank in advance or during the sales to prevent issues.

This question may be better asked on the Money StackExchange site (https://money.stackexchange.com) where they have a bitcoin tag.


text:
Error connecting to json rpc server
For testing purposes, I need to connect from a web page in my shared hosting account (on the public internet) to my json rpc server which is running on my laptop . So bitcoind is running on my laptop, which is behind my router, and I have a shared web hosting account with easybitcoin.php running on it.

Let's say my router's public IP is 1.2.3.4, and the web server (where easybitcoin.php lives)'s IP address is 5.6.7.8, and my laptop LAN address is 192.168.1.99
The error I get is

Failed to connect to 1.2.3.4 port 8332: Connection refused

bitcoin.conf
server=1
rpcallowip=5.6.7.8
rpcport=8332

Router Port Forwarding

Firewall
Down. I checked it at the router and on the laptop (where there is an exception for bitcoind).
DMZ
Laptop is in the router's DMZ.
VPN
off
Online Port Scanner Check (looks good)
Result: 1.2.3.4 is listening on port 8332

Going to http://192.168.1.99:8332/ from inside the LAN (looks good)
JSONRPC server handles only POST requests

Going to http://1.2.3.4:8332/ from inside the LAN
A connection attempt timed out.

Going to http://1.2.3.4:8332/ from the public internet (I made an rpcallowip=IP of the testing website)
403 Response (0 characters)

Going to http://1.2.3.4:8330/ from the public internet (bogus port)
Connection timed out.

Once I get this working I will go back and tighten everything back up. But I need to get it working first. I must be missing something.

try to add: rpcallowip=0.0.0.0/0 instead of your IP address and see if it works.

Do you have a dedicated IP address? Most people have a dynamic IP with their ISP which makes things like this difficult. Look into a dynamic DNS service which will give you a static IP to provide to the internet, but will change in sync when your IP changes. The only way I've been able to make my laptop accessible to the public internet is by doing what you describe below in your answer by putting it behind a web server like wamp.

@m1xolyd1an, I don't think I do, but my provider hasn't changed my address in a year now. So for my purposes, my provider ip is static. My VPN IP might stay the same if I keep choosing the same VPN server to go through. But I have not looked into that since I turn it off when I want this functionality.

I could never get this to work. So as a work-around, I port forwarded http and https, and made and http endpoint that in turn called the function in question and returned the result. A roll-your-own http wrapper around bitcoind, because I couldn't get the bitcoind http server to accept a connection coming in from the outside to my router. This is not ideal, since I must turn off VPN to get even this to work.
I can tell by the settings available in bitcoin.conf that this functionality was intended to be possible. Therefore, I see this as a documentation failure. Someone somewhere knows how to do this, and I'm sure it's trivial to them, but it's a well kept secret.
I request an example of specifically this be added to bitcoin.org, since this is functionality intended to be possible.


text:
Downloaded and installed bitcoind--bandwidth usage gone through the roof
I downloaded the Bitcoin Core daemon on a Ubuntu 16.04 platform from the bitcoin PPA.
sudo apt-get install software-properties-common
sudo apt-add-repository ppa:bitcoin/bitcoin
Press ENTER to continue

sudo apt-get update
sudo apt-get install bitcoind

Set up the Bitcoin daemon to auto-run.
nano /etc/systemd/system/multi-user.target.wants/bitcoind.service

Entered these instructions to the file:
[Unit]
Description=Bitcoin Server
After=network.target
After=syslog.target
[Install]
WantedBy=multi-user.target
Alias=bitcoind.service
[Service]
User=bitcoin
Group=bitcoin
Start=main service   (was a missing = in the original script)
ExecStart=/usr/bin/bitcoind
ExecStop=/usr/bin/bitcoin-cli stop
Restart=always
PrivateTmp=false

Looks as if the program has been installedd since I get this output from the following command line:
snerx@snerx:~$ systemctl status bitcoind
● bitcoind.service - Bitcoin Server
   Loaded: loaded (/etc/systemd/system/multi-user.target.wants/bitcoind.service; bad; vendor preset: enabled)
   Active: active (running) since Wed 2018-04-18 12:06:30 AEST; 17min ago
 Main PID: 4283 (bitcoind)
   CGroup: /system.slice/bitcoind.service
           └─4283 /usr/bin/bitcoind

Apr 18 12:06:30 snerx systemd[1]: Started Bitcoin Server.

That's all well and good. For the time being I'm not interested in downloading a full bitcoin blockchain but it appears that it must be doing so since after the install a full month's worth of bandwidth (200 GB) got eaten up in a 24 h period. And it looks as if something similar is going on still when I fire up my Ubuntu machine. Bandwidth usage has gone from KiB/s to MB/s and is going to drain the household internet budget very rapidly.
What is this Frankenstein monster I have installed?

I have since got an unlimited download internet account and have got a blockchain node up and running. I used the following command to install Bitcoin Core v0.16.0:
$ curl https://bitnodes.earn.com/install-full-node.sh | sh

Downloading the full node using the Bitcoin Core GUI was quite an epic, taking 9 days in total to catch up with 9 years and 18 weeks of blockchains (180GB)--much downtime from internet connection shutting down overnight. At a mere 13.6GB, downloading the full testnet blockchain with the bitcoind -testnet -daemon command was a much less time consuming proposition.

Bitcoin Core is full node software. This means that it will download, validate, and keep up with every transaction made in Bitcoin's history and future. Its goal is independence: if you run a node, you know that everything you see adds up (no theft, no money created out of nothing, ...), without relying on anyway else's judgement. However, it comes at the cost of high resources.
This is one of the ways of interacting with bitcoin-the-currency, but certainly not the only one. A good resource for finding wallet software is here: https://bitcoin.org/en/choose-your-wallet


text:
Lite-wallet transaction confirmation procedure
BTC lite-wallet sends a bloom-filer request to bitcoin node about what is the current balance of the particular address. After that wallet will have a Merkle-tree prove that transaction is indeed on a blockchain.
The question
Do lite-wallets store all headers since genesis block? A block header is just 80 bytes, however, 80 bytes *6 blocks/hour *24h*365d*9y ~37M which is a lot for a lite wallet.

No, lite wallets can function just fine without storing all the block headers. Instead, what wallets usually do is confirm if there is a new tx involving one of the wallet addresses, and then download that specific tx. They will then only store the tx, and not the rest of the information.
As their UTXO set expands, they will check new blocks to see if they contain a new UTXO, or consume an existing UTXO that the wallet cares about.
Additionally, many wallets these days keep track of when an address was created, and will not scan blocks before that.


text:
Elliptic Curve algorithm not supported by cref Java Card simulator
I am trying to create a Bitcoin Key Pair using Java Card 3.0.4. Compilation works good, but I have a runtime problem, I think the EC algorithms are not implemented in cref. Let me share some code:
import javacard.framework.Applet;
import javacard.security.KeyPair;
import javacard.security.KeyBuilder;
import javacard.security.CryptoException;
...
public class Wallet extends Applet {
    …
    private static KeyPair keyPair;
    …
    protected Wallet () {
        …
        try {
            keyPair = new KeyPair (KeyPair.ALG_EC_FP, KeyBuilder.LENGTH_EC_FP_256);
        } catch (CryptoException e) {
            reason = (short) e.getReason();
        }
        …
    }
    …
}

The exception is thrown and catched, and I get reason 3:
3: NO_SUCH_ALGORITHM
public static final short NO_SUCH_ALGORITHM
This reason code is used to indicate that the requested algorithm or key type is not supported.

My cref is:

Java Card 3.0.4 C Reference Implementation Simulator
32-bit Address Space implementation - with cryptography support
T=1 / T=CL Dual interface APDU protocol (ISO 7816-4)
Copyright (c) 2011, Oracle and/or its affiliates. All rights reserved.

Is there any cref version or configuration I can use to make my code work?
Thank you !


text:
Schildbach Wallet complains: not enough mBTC for transation
this app was shown to me by a friend.
now wanted to test it, so send some BTC into the wallet-app some time ago.
that worked. now got 46.94€ worth of mBTC
("An mBTC, or MilliBitcoin, is equivalent to 0.001BTC"
is this a fixed "forever" exchange rate (BTC)1:1000(mBTC)?
https://support.coins.co.th/hc/en-us/articles/202087736-What-s-the-difference-between-mBTC-and-BTC-
is technology wise mBTC and BTC working the same?)
and it complains "not enough funds" for transfer.
how in the world, should this be usable to buy a cappuccino worth 3.10€?

An mBTC, or MilliBitcoin, is equivalent to 0.001BTC" is this a fixed "forever" exchange rate (BTC)1:1000(mBTC)?

This is not an exchange rate, it is just a unit prefix. There are 1000 millibitcoin in a bitcoin, in the same way there are 1000 millimetres in a meter. Some wallets will allow the user to change the unit that their balance is displayed in (eg BTC, mBTC, sats, etc). Functionally, there is no difference between BTC and mBTC, it is just a display preference.

and it complains "not enough funds" for transfer.

The bitcoin network has been extremely busy for the last few days, so transaction fees are currently very high compared to the what we've seen for the last year. Your wallet may be attempting to construct a transaction which includes a very high fee (more than the wallet contains - which seems kinda crazy, but I've seen some very poorly designed fee management algorithms in some wallets before), but without additional information, its not really possible to fully diagnose the issue. It is probably worth contacting the developer of the wallet if the problem persists. You can also search for 'mempool visualizer' online to watch how busy the network is, and then make transactions during less busy times.
Keep in mind as well, some scam wallets will ask you to deposit coins in order to 'unlock a deposit', 'pay a transaction fee', or some other similar nonsense. I am not saying that the wallet you are using is indeed a scam, but I have not heard of it before, so I mention this just to make you aware of the possibility. The prudent bitcoin user stays alert for such scams.

Schildbach Wallet (...) this app was shown to me by a friend.

I̶ ̶h̶a̶v̶e̶ ̶n̶e̶v̶e̶r̶ ̶h̶e̶a̶r̶d̶ ̶o̶f̶ ̶t̶h̶e̶ ̶w̶a̶l̶l̶e̶t̶ ̶s̶o̶f̶t̶w̶a̶r̶e̶ ̶y̶o̶u̶ ̶a̶r̶e̶ ̶u̶s̶i̶n̶g̶ (EDIT: this wallet is indeed listed on bitcoin.org, as RedGrittyBrick pointed out in a comment below). To help ensure you are using software which is not malicious, I would suggest starting from this page: https://bitcoin.org/en/choose-your-wallet. There are a lot of malicious wallets out there that will steal/scam you.

how in the world, should this be usable to buy a cappuccino worth 3.10€?

When the network is busy and fees are high, it really isn't. During low fee times it is more reasonable, though it is worth mentioning that a ledger which computes and stores every person's coffee transaction information for all time (on tens of thousands of nodes) is a grossly inefficient way to expect a monetary network to work.
If I had to make a small value purchase using BTC, I would instead use the lightning network, which is quite well suited to the job. Doing so will generally require setting up a lightning node/wallet before transaction fees skyrocket though.

FYI: https://bitcoin.org/en/choose-your-wallet -> android -> new --> (none) -> (none) -> "Bitcoin Wallet" = Schildbach wallet

@RedGrittyBrick oh! Thats funny, I didn't realize it was listed there. My mistake, thanks for pointing that out

thank you for your detailed answer, really appreciate it. yes have heard that Bitcoin is nowadays used as "store of value", not for "cappuccino" (small) transactions anymore, which is kind of sad and also greatly reduces its usefulness (imho) because received my first bitcoins in a cafe as a gift via this above wallet. what is nice to see it's value skyrocket as well X-D the mBTC 5.18/1000 = 0.00518 BTC are now worth 72€! WTF? X-D have a good time, here is a nice chart on the transaction fees (did not know they fluctuate so much) https://privacypros.io/tools/bitcoin-fee-estimator/

https://f-droid.org/en/packages/com.greenaddress.greenbits_android_wallet/ (is not listed here) https://bitcoin.org/en/choose-your-wallet?step=5&platform=android (UNTESTED!) let's the wallet-user decide the priority of the transaction, and can do the transaction when cheapest https://privacypros.io/tools/bitcoin-fee-estimator/


text:
Are hashes of Merkle tree roots unique throughout whole blockchain?
The "Mastering Bitcoin" book says that each block header contains a 32B long hash of the Merkle root for all the transactions it contains.
If I extract all these Merkle roots from all the blocks in the blockchain (longest branch only) and put them in a list, will that list have any duplicates?

The merkle root is a 32 byte hash.
As the hashing operation is sha256, it is exceedingly unlikely that you will find duplicates, but it is not, strictly speaking, impossible.

The list will actually have 2 duplicates, due to the coinbase duplications before BIP30.

@PieterWuille Isn't that simply a duplicate coinbase transaction? Since block 91880 contains a non-coinbase transaction as well, the merkle root in the header will be different

Ah, I must have misremembered then! I thought they both had no other transactions.


text:
How would a hard fork for a new key-pair/address generation algorithm be implemented practically?
If an upcoming hard fork entails a switch to new method for key-pair/address generation, how exactly is it going to be carried out? How would all the old addresses going to change to ones that are compatible with the new algorithm and how is the transfer of ownership going to be conducted exactly?
For the blockchain to keep the same state after the fork, there would have to be a new address for each old (incompatible) address that holds the same amount of BTC and has the same owner.
One way I can think of is adding support for both the old and new key-pair/address generation methods temporarily, and then prompt all owners holding addresses generated using the old method to send their BTC to new addresses generated using the newer method, and finally dropping support for the old method. With ~30 million unique BTC addresses as of today, and a current block size capable of processing 2-7 transactions per second, this transition would need between 50-173 days to complete, during which the blockchain is completely incapacitated, and miner fees being higher than usual. I suppose it could also trap any BTC that hasn't been transferred to a new address by owners in a timely manner within the old, incompatible address.

You'd have both the old and new address types valid. You can't drop support for the old address types because there's no guarantee all coin users are going to convert their coins right away.
The updated wallet software, merchant services, etc will all only provide addresses in the new format though, so eventually the use of the old addresses will slowly drop off, just like how with the adoption of segwit, legacy address use dropped off (although not completely phased out).

I think what you are suggesting here is that this can only be done using a soft-fork with a gradual shift to using more of the new signature method. Can this be done fast enough? Do you know what proportion of BTC lies in non-segwit vs segwit addresses? It's been more than 3 years of segwit. If adoption is slow then maybe with quantum computing on the way the soft fork would have to start sooner rather than later.

We're nowhere close to a general purpose quantum computer with enough qubits to feasibly attack Bitcoin. The quantum computers in existence right now are special purpose ones that only have very limited use cases that aren't applicable to cracking cryptography. Also, note that a quantum computer can only attack addresses where the public key has been exposed (in other words, an address that has already been spent from) and since addresses are supposed to be single-use it'll be a while before this becomes a real problem.


text:
Is there a way to generate new addresses for someone else's wallet?
I thought I saw this feature existed somewhere but I can't find the reference.
Use Case: Alice needs to keep sending multiple bitcoin transactions to Bob, and wants to use a different payment address each time, but neither Alice nor Bob wants to trouble Bob with having to send over a new address for Alice to use. Neither Alice nor Bob want Alice to have Bob's private key.
Any service that sends bitcoins in multiple transactions to a client could make use of this feature. Current services that I've seen, like mining, just reuse the same address over and over, which is not recommended.
What is this feature called?
What bitcoin api (if any) facilitates it, or how would I get started using this api feature?
EDIT
With help from the answer, I was able to do this by adding bitwasp/bitcoin to my php project and this code:
//bitwasp/bitcoin library
require_once(__DIR__.'\..\../vendor/autoload.php');
//use BitWasp\Bitcoin\Bitcoin;
use BitWasp\Bitcoin\Key\Deterministic\HierarchicalKeyFactory;
use BitWasp\Bitcoin\Key\Deterministic\HierarchicalKeySequence;
use BitWasp\Bitcoin\Key\Deterministic\MultisigHD;
use BitWasp\Bitcoin\Network\NetworkFactory;
use BitWasp\Bitcoin\Address\PayToPubKeyHashAddress;

//$xpub = 'xpub661MyMwAqRbcGYcu6n1FmV1TbE8EwnSKecRZLvKAMyj4qLf15qXsoNryiKNvCkRq3z5kBCeZG8115jj28eVqmeKBJZPqjAfwRD3TGx1w5hY';
//$xpub = 'xpub6CUGRUonZSQ4TWtTMmzXdrXDtypWKiKrhko4egpiMZbpiaQL2jkwSB1icqYh2cfDfVxdx4df189oLKnC5fSwqPfgyP3hooxujYzAu3fDVmz';
//$path = '0/0'; // 1st receiving address
// $path = '0/2'; // 3rd receiving address
// $path = '1/0'; // 1st change address
// $path = '1/1'; // 2nd change address
public static function NewReceivingAddress($xpub, $index, $change = false){
    $key = HierarchicalKeyFactory::fromExtended($xpub, NetworkFactory::bitcoin());
    $path = ($change ? '1' : '0').'/'.$index;
    $child_key = $key->derivePath($path);
    return new Result('data',(new PayToPubKeyHashAddress($child_key->getPublicKey()->getPubKeyHash()))->getAddress());
}

Bob can provide Alice with an extended public key (xpub). This will allow Alice to generate as many addresses as required, all of which will be accessible to Bob via the corresponding extended private key (xpriv), which only he has access to.
There are many tools and libraries around that support address derivation from xpubs, such as BitcoinJS-lib.
As far as I know, blockchain.info is the only explorer with xpub support, and that also only applies to p2pkh addresses. Here's an example: https://blockchain.info/xpub/xpub6CUGRUonZSQ4TWtTMmzXdrXDtypWKiKrhko4egpiMZbpiaQL2jkwSB1icqYh2cfDfVxdx4df189oLKnC5fSwqPfgyP3hooxujYzAu3fDVmz

The process I'm after is described in BIP32 in the section about generating public child keys from public parent keys. Then here is an example use that can be used anonymously. You're correct there are many implementations, but do you have any idea whether or not the bitcoin core json rpc server supports this? Thanks.

Bitcoin Core supports BIP32 derivations, but has no concept of xpubs. You'll have to look elsewhere. Bitcoinjs-lib is a good place to start


text:
Cheapest way to switch from Exodus wallet to something else
A few months back I moved my Bitcoins and Ether to Exodus.  I've now decided, as pretty as it may be, the high transaction charges and no way of changing them mean I want to switch wallets. There are other issues too, but this is the main one driving me away.
I tried using Jaxx to transfer the small amount of Ether, using the exported key from Exodus's developer menu.  However, this appears to have swept my Exodus address, rather than importing the address and private key into Jaxx.  It wasn't a complete sweep either - there is still balance in my Exodus Ether wallet.
What I am looking for is a way to just switch Bitcoin wallets from Exodus to something else, at minimum cost.
I believe I should be able to do that by importing private keys exported from Exodus into some other wallet, but my experience with Jaxx suggests that not all wallets support this. Jaxx support sweeping only.  A discussion of difference between sweeping and importing on 99 coins.
Am I right in my thinking?  If I am, can you suggest good wallets that support what I want to do, and have clear documentation about how to do it?

Exodus eventually answered this questions themselves, with a similar answer to that given by @McLeodX but specifically discussing import of BTC private keys rather than sweep or transfer.
In short, export BTC private keys from Exodus, import them into Bitcoin.info wallet, then use bitcoin.info to do future transactions with fees that can be adjusted.
I am sure there are other wallets for which this method will also work.

I closed my Exodus account for the same reason. The worst case was with Bitcoin with a $200 transfer fee!  Of course it goes to the miners, but Exodus doesn't allow you to reduce it.  Exodus makes their money by taking a % on exchanges.
I found BitcoinCore the most economical for Bitcoin. You can set the transaction fee as low as you like. Since I am just sending it to myself (paper wallet, or friends) I don't need 6 confirmations in 1 hour.  If it takes a week, that's worth it to save $200.
The other advantage of running Bitcoin Core (Bitcoin.org) is that you are helping the network by storing and updating the 200 GB blockchain locally.  You can search the blockchain on your own computer.

Why not get a blockchain.info wallet and transfer all your btc there, and get a MEW(MyEtherWallet) and transfer all your Ether there.  100% free is about as cheap as it gets, and I’m not sure if a “pretty” wallet is important unless you plan on staring at your coins all day.

Are you saying the wallets are free, or that I can transfer my private keys into them without having to pay Exodus high transfer fees? (I don't believe that any parts of the fee go to Exodus, it's just how they ensure they are a fast wallet)

Yeah for sure, blockchain.info (for example) has the longest running and one of the more secure wallets anywhere, and they are free to setup, own and use (small fee for withdrawals, which is standard anywhere).  I don’t know what exodus is, but go an create a blockchain.info wallet, then transfer your coins there.  You don’t need private keys for that.

The point is Exodus is a wallet with high fees that can't be changed. I'm looking for a way to transfer the balance to another wallet without incurring those high fees.

How high can the fees to withdraw coins from one wallet to another possibly be?  If “high fees” are comparative to other wallets then you’re going to have to bite the bullet and pay fees no matter who you’re with, if they’re significantly more expensive then how are exodus still in business.  If you look at your situation logically, the only 2 ways to move your coin is a) withdraw to another wallet, b) convert to some other medium like other cryptos or fiat inside exodus (if you can) and then withdraw.  I’m not sure what magical third option you’re expecting people to conjure up, but that’s it

For small transactions (e.g. <$5), Exodus sets fees that are often higher than the transaction. Other wallets allow the fees to be set, balancing speed and cost. So what you are saying is private keys don't allow you to move balance between wallets without a bitcoin transaction taking place?

Other wallets don't have fees, or the fees are insanely small.  I get the feeling you're quite new to this, and my advice is don't get too wrapped up on fee structures of wallets, instead save your time and set up a free and extremely secure wallet at blockchain.info and transfer your coins there today and forget about exodus.

Exodus allows in the setting now to change fees to slide from higher speed higher cost to lower speed lower cost.


text:
I have 23 words of my 24 word mnemonic (and passphrase) for my ledger nano-s, is it possible for me to brute-force the last word (not in order)
I have ended up wiping my ledger nanao S during test (thoroughly stupid I know) and I am left with 23 (!) seed words and a passphrase. I understand that I should have both backed up my wallet, and made sure of my seed words.  I was looking into a program (in python due to there not being too many combinations) that could brute force it due to me knowing that I had written them down in order, just having missed a word, (pasted here due to the massive size due to the size of the word list)
So how would I go about brute forcing it through python, what I have now can (as far as I can see) will give me all of the valid mnemonics, but from there how would I automate the collection of private keys from a bip-39 generator, and the checking of funds in them?
(edit)
I know the order of the words, just not where the missing one is, Ive tried to manually sift through the combinations for if the missing word was the last one
(further edit)
Im using an offline version of this site for turning the mnemonics into private keys iancoleman.io/bip39 but unfortunately I dont know how to canabalise the code or interact with it with python. from there I was going to use a tool like this github.com/gurnec/btcrecover to find the wallet with btc in it. At least thats what I have so far.

Do you not know the order of any of the words in the list, or do you just not know the position of the missing one?

I know the order of the words, just not where the missing one is, Ive tried to manually sift through the combinations for if the missing word was the last one.

There are 2048 words in the BIP39 list, there are 24 possible positions for your missing word.
You need to try 2048 x 24 = 49,152 combinations.
For each one, you need to generate a private key + public key and check whether addresses generated from that have any unspent bitcoin associated with them. You can work with a pruned blockchain and probably further prune based on the known date-ranges of your most recent transactions.
Superficially at least, it seems feasible for an automated process to do this in reasonable time (i.e. less than years).
Having tried all words in one position you should have a reasonable idea of how long this will take.

Due to the way that the mnemonic has a checksum, I only needed to sift through 1/256 of the combinations and thats what the above program does, I was just curious if there were tools to do this already, or if I was overly complicating it. I had an offline version of this site for turning the mnemonics into private keys https://iancoleman.io/bip39/ but unfortunately I dont know how to canabalise the code or interact with it with python. from there I was going to use a tool like this https://github.com/gurnec/btcrecover to find the wallet with btc in it.

Same thing happened to us. There is a script available here https://github.com/ashmoran/bip39_missing_word which you can use to recover this.
You may want to extend it to check the correct derived path if it has any previous transactions.
It usually generates about 100 valid wallets with one word missing.

Since you know the first 23 words, it sound like you only need to calculate the BIP39 checksum, correct?
If so, this script might be what you are looking for. (I have not tried it)


text:
How does new -blocksxor switch that obfuscates LevelDB blocks.dat files work?
I would please like help understanding the new -blocksxor enhancement, mainly from an admin perspective.  I did see the following useful info.
Output from bitcoind --help:
   -blocksxor
        Whether an XOR-key applies to blocksdir *.dat files. The created XOR-key
        will be zeros for an existing blocksdir or when `-blocksxor=0` is
        set, and random for a freshly initialized blocksdir. (default: 1)

From v28.0 release notes:

Block files are now XOR'd by default with a key stored in the blocksdir. Previous releases of Bitcoin Core or previous external software will not be able to read the blocksdir with a non-zero XOR-key. Refer to the -blocksxor help for more details. (#28052)

Comments for this change are at: Pull Request #28052
Reading further, it sounds like this enhancement compensates for some AV softwares wrongly flagging blockchain storage files. It sounds like this was originally reported against chainstate files (Issue #4069), whereas this new "-blocksxor" remediation deals with erroneous AV flags to the blocks data files themselves.
For the new enhancement, it sounds like a rolling random XOR obfuscation  blocks directory which is then used to optionally obfuscate file contents.
My questions I'd please like help with are:

I didn't see the "rolling" nature of these keys described?  When are the random XOR keys generated, and when do they "roll?" Are new keys created for each block?  Does the new -blocksxor key-file contain multiple obfuscation keys, it must?
Also, how does this help prevent AV softwares from continuing to wrongly flag these data files? Doesn't randomly XOR(ing) persisted data just "kick the can down the road"? Eventually the same problem may happen. Are there AV-integration tests which prove out this XOR(ing) solution?

I can only think of one way to use a XOR key for obfuscation, which is splitting the data into chunks that have the same length as the key and XOR'ing each chunk with the key. I'd assume that's how it works here as well.
Antivirus software can flag the blocks directory when someone inserts data matching a known virus into a block. XOR'ing randomizes the data, so it will no longer match.

Hi Vojtěch, thank you for very much your efforts. I apologize for the my unclear questions. I was specifically asking about the new "-blocksxor" option which you also haven't worked with either it sounds like. Thank you again.

Hi jimhash, I was indeed answering with regards to the -blocksxor option. What exactly in my answer seems wrong?


text:
Where is wallet.dat file?
I have clearly installed Windows 7 and Bitcoin Core.
There is no Bitcoin folder in {User}/AppData/Roaming... Blockchain is dowloading but I cannot find where it is and wallet.dat also. Anybody help?
My OS in Windows 7.
Maybe I am kind of idiot so I'm pasting PrintScreens with steps I have done
1

2

This is a duplicate of the linked question. The wallet.dat file will be at C:\Users\YourUserName\Appdata\Roaming\Bitcoin\wallet.dat

No there is no wallet.dat. Auxilly there is no Bitcoin or Litecion folder in Roaming. I have hidden and system files visible.

I connot find any wallet.dat file with Windows Search and also with Total commander search tool. Any ideas?

@NickODell want TeamViewer to my PC?

@NickODell you made my question duplicate so prove me tjat there is correct answear in another question!

As explained in the linked answer, browse to %APPDATA%\Bitcoin

I did it many times with RUN functionality of the Windows OS

Any other ideas? It makes me sick :(


text:
Where is data folder for Bitcoin Core in Windows 7?
I cannot find any wallet.dat file on my c: drive. Any ideas where it can be put?
Everybody says the same and I'm doing it. Maybe I'm kind of idiot so I'm pasting screens with steps I have done:
1

2

The same with Litecoin Core

Type literally in your explorer location bar: %APPDATA%\Bitcoin

I did it many times

Are you sure you're running Bitcoin Core?

Any other ideas? It makes me sick :(

Perhaps you selected another data directory yourself. Bitcoin-Qt asks you what directory to use the first time it is started?

I don't remeber... But I don't think so....

@PieterWuille is there a way to check it?

It seems that the answer is no, but we're working on fixing it: https://github.com/bitcoin/bitcoin/pull/7732

So now I cannot import my old keys to new wallet? :o

The default directory would be %APPDATA%\Bitcoin
If you can't find it you may hit the Windows-Key+F and enter "wallet.dat"
You can also export your wallet from within Bitcoin-QT: File>Save Wallet

I want to import... There must be sth wrong with my Windows configuration. Win+F and search for "wallet.dat" gives me just results with my back-up files. Win+F for "size:gigantic" search for files greater that 128MB. It cannot find the blockchain file also which is greater for sure. Windows sucks ;)

You don't need to know where your Blockchain and other files are in order to import a new wallet.dat. Although it's very strange that you're unable to find it!【・ヘ・?】

So how import without wisdom about data folder?

wallet.dat is only kilobytes big. You should include all files and folders in your search.


text:
taproot script spending issue
I have been working in a bitcoin library for educational purposes (being taught in courses/meetups/etc.). I had quite some time to work on it and decided it was about time to support taproot.
I have successfully spend taproot UTXOs created by bitcoin core as well as created p2tr UTXOs that I could then spend. Key path spending seems to be working as expected.
I am having issues (creating/) spending from script path.
I am not sure if it is an implementation issue or just not following the specs properly but I was hoping that fresh (and more experienced) eyes will identify the issue.
I use a single tap leaf script for now.
I will post the critical code snippets below but the whole branch can be found here.
I am getting:
"reject-reason": "non-mandatory-script-verify-flag (Witness program hash mismatch)"
The raw transaction is the following:
version:                02000000
segwith marker/flag     0001
inputs                  01
txid                    b193e4af59323b28ed8a37432bf65e0418cbcdc310d8eb733b9b50e27a578f34
vout                    00000000
scriptSig               00
nSequence               ffffffff
outputs                 01
amount                  3421000000000000
scriptPubKey            225120d4213cd57207f22a9e905302007b99b84491534729bd5f4065bdcb42ed10fcd5
witness stack items     03
signature               400efe4d084bf03c3aa72d856a6aa17078eb002d6330a53230b4ac832cac8fd5b6fd49d95854afffeaeec2f2163c32ba8129383ae367f54a2b32dfbae042569ccd
script                  22205d238354a7e74c9e373317053226537dec221c5c775bcca01e806ec358c5c08dac
control block size      41
version                         c0
internal pubkey                 1036a7ed8d24eac9057e114f22342ebf20c16d37f0d25cfd2c900bf401ec09c9
tapleaf_hash                    7f57a76fa4006c7f31e695ad977dfe9f8b736e2f82249a7c9c1fc7072544ca29
locktime                00000000

When I had issues with properly tweaking the keys I was getting 'Invalid schnorr signature' so I assume that the above issue has to do with the control block I use..?
The code of the spending script that produces the error is as follows:
from binascii import hexlify
from bitcoinutils.setup import setup
from bitcoinutils.utils import to_satoshis, ControlBlock
from bitcoinutils.script import Script
from bitcoinutils.transactions import Transaction, TxInput, TxOutput, TxWitnessInput
from bitcoinutils.keys import P2pkhAddress, PrivateKey
from bitcoinutils.hdwallet import HDWallet

def main():
    # always remember to setup the network
    setup('testnet')

    # Keys are hard-coded in the example for simplicity but it is very bad
    # practice. Normally you would acquire them from env variables, db, etc

    #######################
    # Construct the input #
    #######################

    # INTERNAL PRIVKEY of UTXO
    # get an HDWallet wrapper object by extended private key and path
    xprivkey = "tprv8ZgxMBicQKsPdQR9RuHpGGxSnNq8Jr3X4WnT6Nf2eq7FajuXyBep5KWYpYEixxx5XdTm1Ntpe84f3cVcF7mZZ7mPkntaFXLGJD2tS7YJkWU"
    path = "m/86'/1'/0'/0/7"
    hdw = HDWallet(xprivkey, path)
    priv1 = hdw.get_private_key()
    pub1 = priv1.get_public_key()

    # taproot script is a simple P2PK with the following keys

    # TAPLEAF script (P2PK)
    privkey_tr_script = PrivateKey('cQwzrJyTNWbEwhPEmQ3Qoo4jSfHdHEtdbL4kNBgHUKhirgzcQw7G')
    pubkey_tr_script = privkey_tr_script.get_public_key()
    tr_script_p2pk = Script([pubkey_tr_script.to_x_only_hex(), 'OP_CHECKSIG'])

    # taproot script path address
    # note that .get_taproot_address(script) negates if necessary, then tweaks
    # and then negates again if necessary (I have tried w/o 2nd negation as well)
    fromAddress = pub1.get_taproot_address(tr_script_p2pk)
    print('From Taproot script address', fromAddress.to_string())

    # UTXO of fromAddress
    txid1 = '348f577ae2509b3b73ebd810c3cdcb18045ef62b43378aed283b3259afe493b1'
    vout1 = 0

    # create transaction input from tx id of UTXO
    txin1 = TxInput(txid1, vout1)

    # all amounts are needed to sign a taproot input
    # (depending on sighash)
    amount1 = to_satoshis(0.00009)
    amounts = [ amount1 ]

    # all scriptPubKeys (in hex) are needed to sign a taproot input
    # (depending on sighash but always of the spend input)
    scriptPubkey1 = fromAddress.to_script_pub_key()
    utxos_scriptPubkeys = [ scriptPubkey1 ]

    ########################
    # Construct the output #
    ########################

    hdw.from_path("m/86'/1'/0'/0/5")
    priv2 = hdw.get_private_key()
    print('To Private key:', priv2.to_wif())

    pub2 = priv2.get_public_key()
    print('To Public key:', pub2.to_hex())

    # taproot key path address
    toAddress = pub2.get_taproot_address()
    print('To Taproot address:', toAddress.to_string())

    # create transaction output
    txOut = TxOutput(to_satoshis(0.000085), toAddress.to_script_pub_key())

    # create transaction without change output - if at least a single input is
    # segwit we need to set has_segwit=True
    tx = Transaction([txin1], [txOut], has_segwit=True)

    print("\nRaw transaction:\n" + tx.serialize())

    print('\ntxid: ' + tx.get_txid())
    print('\ntxwid: ' + tx.get_wtxid())

    # sign taproot input
    # to create the digest message to sign in taproot we need to
    # pass all the utxos' scriptPubKeys, their amounts and taproot script
    # tweak=False means that the key should not be tweaked, but it is still negated
    sig1 = privkey_tr_script.sign_taproot_input(tx, 0, utxos_scriptPubkeys, amounts, script_path=True, script=tr_script_p2pk, tweak=False)

    control_block = ControlBlock(pub1, [ tr_script_p2pk ])

    tx.witnesses.append( TxWitnessInput([ sig1, tr_script_p2pk.to_hex(), control_block.to_hex() ]) )

    # print raw signed transaction ready to be broadcasted
    print("\nRaw signed transaction:\n" + tx.serialize())

    # sendrawtransaction is used to send it to a node

if __name__ == "__main__":
    main()

The key path can be spend normally with another script.
The code for the ControlBlock is the following:
class ControlBlock:
    '''Represents a control block for spending a taproot script path'''

    def __init__(self, pubkey, scripts):
        self.pubkey = pubkey
        self.scripts = scripts

    def to_bytes(self):
        # leaf version is fixed but we check if the public key required negation
        # if negated (y is odd) add one to the leaf_version
        #if int(self.pubkey.to_hex()[-2:], 16) % 2 == 0:
        #    leaf_version = bytes([LEAF_VERSION_TAPSCRIPT])
        #else:
        #    leaf_version = bytes([LEAF_VERSION_TAPSCRIPT + 1])
        leaf_version = bytes([LEAF_VERSION_TAPSCRIPT])

        # x-only public key is required
        pub_key = bytes.fromhex( self.pubkey.to_x_only_hex() )

        # TODO only single alternative script path for now
        script_bytes = self.scripts[0].to_bytes()

        # tag hash the script
        th = tagged_hash(bytes([LEAF_VERSION_TAPSCRIPT]) + prepend_varint(script_bytes),
                         "TapLeaf").digest()

        return leaf_version + pub_key + th

    def to_hex(self):
        """Converts object to hexadecimal string"""

        return hexlify(self.to_bytes()).decode('utf-8')

The message digest created includes the script that we are spending with ext_flag=1:
        ...
        # Data about this input
        spend_type = ext_flag * 2 + 0      # 0 for hard-coded - no annex_present
        ...
        if ext_flag == 1:    # script spending path (Signature Message Extension BIP-342)
            # committing the tapleaf hash - makes it safe to reuse keys for separate
            # scripts in the same output
            leaf_ver = LEAF_VERSION_TAPSCRIPT   # pass as a parameter if a new version comes
            tx_for_signing += tagged_hash(bytes([leaf_ver]) + prepend_varint(script.to_bytes()),
                                          "TapLeaf").digest()

            # key version - type of public key used for this signature, currently only 0
            tx_for_signing += bytes([0])

            # code separator position - records position of when the last OP_CODESEPARATOR
            # was executed; not supported for now, we always use 0xffffffff
            tx_for_signing += b'\xff\xff\xff\xff'

Tweaking seems to be working fine since I have no issues with the key spending path, which is why I don't include the code for tweaking the keys but everything is here for the  brave hearted.
Any help will be greatly appreciated!

If you only have a single script in your script tree, the Merkle path should be length zero, and the control block should be 33 bytes.

Thank you Pieter. In hindsight obvious since you provide the path in order to construct the root... quite some hours of frustration.  I wish I had asked sooner! :-)   Please write your comment in a reply to accept it.

Since you only have a single script in the tree, the Merkle path would be empty, and the control block would be 33 bytes long.
In general, the Merkle path elements in the control block are the other hashes to hash together with. For a balanced tree with 2n elements you need n such hashes.


text:
Why is a library's signature of a segwit tx different from Bitcoin Core signature?
I have been writing a (yet another) Bitcoin python library primarily for educational purposes; for me and my students.
Signing a non-segwit transaction results in a signed tx that is identical to what Bitcoin Core produces.
However, signing a segwit tx results in a signed tx that is valid but different to what Bitcoin Core produces. The signature created is different.
I am trying to understand why. The library uses the same signing method in both cases. The library's tx digest calculation seems to be working fine since valid transactions are generated.
I have seen another post that mentions lax and strict DER encodings. Is this relevant, and if yes, does it only applies when signing segwit inputs?
What am I missing?
EDIT: the signature from the library is:
483045022100debdd831b8f144afcaa4e9cb71713ec657292ac09d163e827dc1d458417841a70220292b6f250e4ad94ec2b3f062129b85620c22be9be97f8a42346612de8fc423200121
And from Bitcoin core:
4730440220413d31dcd84594d2bf1408d41ec6913694b7936c2cc598f436a4709cd2d70264  02201b646f18fa4108ee19d103d427c2323a0f221e33ecb65bed0690ec69c478b8800121

Can you show the signatures that come out?

updated question to include the signatures

This is unrelated to segregated witness.
Since Bitcoin Core version v0.17, signatures have low R signatures. The signing operating is repeated until an R value is constructed that's below 2255. On average this only takes 2 attempts, but it makes all signatures equally long (71 bytes; rather than 50% 71 bytes and 50% 72 bytes), making them more predictable and slightly cheaper on the network.


text:
Pull Bitcoin node data from external public nodes using JSON-RPC
I read couple of blogs and responses on hosting server to expose data using JSON-RPC but wanted to confirm if there is a way to query node data that I am not hosting (not connecting via P1P) using JSON-RPC protocol (or any other protocol that allows querying data and not pull everything)
Note: I am talking about mainnet and not testnet

The port has to be bound explicitly to the Internet. Why do you want this? What's the problem you need to resolve?

I want to query Bitcoin node for some specific data like transaction. I do not want to host my own BTC node

OP posted:

I read couple of blogs and responses on hosting server to expose data using JSON-RPC but wanted to confirm if there is a way to query node data that I am not hosting (not connecting via P1P) using JSON-RPC protocol (or any other protocol that allows querying data and not pull everything)
Note: I am talking about mainnet and not testnet

OP clarified in a comment:

I want to query Bitcoin node for some specific data like transaction. I do not want to host my own BTC node

Yeah, you can query node data that you are not hosting using JSON-RPC.
However, there are many other options you can use:

Use a node's REST API, Bitcoin Core REST API.

Use a REST API provided by some third party, like for instance any famous Bitcoin data analytics platform, or any famous blocks chain explorer.

Contribute a full node to the network and query it privately.

The third option is actually the easiest to get, [by largely far] the most secure, the most readily available, the least vendor lock in, the cheapest to maintain, and the most beneficial to the Bitcoin ecosystem.

If you don't have access to a node's RPC interface, you won't have access to its REST interface either (assuming you're talking about Bitcoin Core).


text:
Bitcoin - Level DB - Block Index - Parsing value for block hash
I am trying to read the value against block hash in level DB of Bitcoin node database - Block/index. For Genesis block, I get 88 bytes which I want to parse. I tried to follow instructions in https://bitcoin.stackexchange.com/questions/67515/format-of-a-block-keys-contents-in-bitcoinds-leveldb but wasnt able to do that successfully as the first 4 bytes should be version but I get an invalid version.
I tried obfuscating the whole value as well but still the first 4 bytes does not give me a valid version. I must be doing something wrong but not able to identify that.
Value I get (in hex string)
8be750000b0100080100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49ffff001d1dac2b7c

Additional resource I tried - Link
Note: I am using c# to read and parse the data.

Found the logic for parsing the block index here

This logic for parsing is up to date already. If you need to know how to parse RAW data, you can try my parser https://github.com/ragestack/blockchain-parser/

@DenisLeonov, your code talks about parsing the bat files however my question is on Block index


text:
How convert Bitcoin Privat Key Compression to public address?
This script gets the public address from the uncompressed private key.
import ecdsa
import hashlib
import base58

private_key = input("privatekey: ") # e41b45e722251672c01a28e4fada590471fea09f90d13b143033ed3a1107ef49

# Convert hex private key to bytes
private_key = bytes.fromhex(private_key)

# Derivation of the private key
signing_key = ecdsa.SigningKey.from_string(
    private_key, curve=ecdsa.SECP256k1)
verifying_key = signing_key.get_verifying_key()

public_key = bytes.fromhex("04") + verifying_key.to_string()

# Hashes of public key
sha256_1 = hashlib.sha256(public_key)
ripemd160 = hashlib.new("ripemd160")
ripemd160.update(sha256_1.digest())

# Adding prefix to identify Network
hashed_public_key = bytes.fromhex("00") + ripemd160.digest()

# Checksum calculation
checksum_full = hashlib.sha256(
    hashlib.sha256(hashed_public_key).digest()).digest()
checksum = checksum_full[:4]

# Adding checksum to hashpubkey
bin_addr = hashed_public_key + checksum

# Encoding to address
address = str(base58.b58encode(bin_addr))
final_address = address[2:-1]  # change 2

print(final_address)

Format (private keys):
        uncompressed: 0x80 + [32-byte secret] + [4 bytes of Hash() of previous 33 bytes], base58 encoded
        compressed: 0x80 + [32-byte secret] + 0x01 + [4 bytes of Hash() previous 34 bytes], base58 encoded

    case 1:

    secret (hex): 1111111111111111111111111111111111111111111111111111111111111111
    uncompressed:
        secret (base58): 5HwoXVkHoRM8sL2KmNRS217n1g8mPPBomrY7yehCuXC1115WWsh
        pubkey (hex): 044f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa385b6b1b8ead809ca67454d9683fcf2ba03456d6fe2c4abe2b07f0fbdbb2f1c1
        address (base58): 1MsHWS1BnwMc3tLE8G35UXsS58fKipzB7a
    compressed:
        secret (base58): L4xkFv5sbttQcsgnTjzqJuQdNfHC5gk9zsK5HmaV822qu79zJA7L
        pubkey (hex): 034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa
        address (base58): 1Q1pE5vPGEEMqRcVRMbtBK842Y6Pzo6nK9

I need to get this code to work with two formats, but I don't understand what needs to be fixed. If I insert a compression private key 682cf5791be8d4526aacf63bb7ab201f5cd1d732c1f634e5839379191b02295925 , I get an error:

ecdsa.keys.MalformedPointError: Invalid length of private key,
received 33, expected 32

I understand that the bottom part of this code can be used, but I am failing to lack knowledge.
def __private_to_compressed_public(private_key):
        private_hex = codecs.decode(private_key, 'hex')
        # Get ECDSA public key
        key = ecdsa.SigningKey.from_string(private_hex, curve=ecdsa.SECP256k1).verifying_key
        key_bytes = key.to_string()
        key_hex = codecs.encode(key_bytes, 'hex')
        # Get X from the key (first half)
        key_string = key_hex.decode('utf-8')
        half_len = len(key_hex) // 2
        key_half = key_hex[:half_len]
        # Add bitcoin byte: 0x02 if the last digit is even, 0x03 if the last digit is odd
        last_byte = int(key_string[-1], 16)
        bitcoin_byte = b'02' if last_byte % 2 == 0 else b'03'
        public_key = bitcoin_byte + key_half
        return public_key

I've done a lot of tests, but I can't figure out what's wrong. Tell me how to modify the code correctly.
Thank you in advance for your help.

Why are you adding an extra byte into the compressed private key?

This code for an example to get an uncompressed key. I tried to change the code but can't, the code breaks after running ecdsa library when I add a compressed key. It does not reach the lower parameters.

The WIF-encoded private key has a flag byte indicating whether to use a compressed or uncompressed public key, but the private key of elliptic curve cryptography itself does not distinguish between compressed and uncompressed.

If I get your code and use "e41b45e722251672c01a28e4fada590471fea09f90d13b143033ed3a1107ef49" as secret hex value AKA secret private key... then I get result: "12sF1DbBbPaoNYrs28Qm7waiCcAVoF93Nn" which is uncompressed public address.
Check my script, it is more extended, but with a copule of imports for an educational point of view, to show all the process. You will get compressed and uncompressed public keys from a given secret in hexadecimal value.
First, the script will get uncompressed private key and compressed private key in hex:
'04417A55413D948D79F5194F1F2CD670F078CB7F6D3A2F2B12E8CDF9A3268CAD3BAAA3251D2587D4E57ACBCE7991B72355EA33C44DBCF260D09B6C921879A61AA4'
'02417A55413D948D79F5194F1F2CD670F078CB7F6D3A2F2B12E8CDF9A3268CAD3B'

Then it will get both public uncompressed and compressed public keys.
The code:
#!/usr/bin/python3
from hashlib import sha256, new
import binascii

PCURVE = 2 ** 256 - 2 ** 32 - 2 ** 9 - 2 ** 8 - 2 ** 7 - 2 ** 6 - 2 ** 4 - 1  # The proven prime
N = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141  # Number of points in the field
ACURVE = 0
BCURVE = 7  # These two defines the elliptic curve. y^2 = x^3 + Acurve * x + Bcurve
Gx = 55066263022277343669578718895168534326250603453777594175500187360389116729240
Gy = 32670510020758816978083085130507043184471273380659243275938904335757337482424
GPOINT = (Gx, Gy)  # This is our generator point. Trillions of dif ones possible

def modinv(a: int, n: int = PCURVE):
    # MAXIMO COMUN DIVISOR: Extended Euclidean Algorithm/'division' in elliptic curves
    lm, hm = 1, 0
    resto = a % n
    high = n
    while resto > 1:
        ratio = high // resto
        nm = hm - lm * ratio
        new = high - resto * ratio
        lm, resto, hm, high = nm, new, lm, resto
    return lm % n

def ECadd(a, b):  # Not true addition, invented for EC. Could have been called anything.
    LamAdd = ((b[1] - a[1]) * modinv(b[0] - a[0], PCURVE)) % PCURVE
    x = (LamAdd * LamAdd - a[0] - b[0]) % PCURVE
    y = (LamAdd * (a[0] - x) - a[1]) % PCURVE
    return x, y

def ECdouble(a):  # This is called point doubling, also invented for EC.
    Lam = ((3 * a[0] * a[0] + ACURVE) * modinv((2 * a[1]), PCURVE)) % PCURVE
    x = (Lam * Lam - 2 * a[0]) % PCURVE
    y = (Lam * (a[0] - x) - a[1]) % PCURVE
    return x, y

def EccMultiply(gen_point: tuple, scalar_hex: int):  # Double & add. Not true multiplication
    if scalar_hex == 0 or scalar_hex >= N:
        raise Exception("Invalid Scalar/Private Key")
    ScalarBin = str(bin(scalar_hex))[2:]  # string binario sin el comienzo 0b
    Q = gen_point  # esto es una tupla de dos integer del punto de generacion de la curva
    for i in range(1, len(ScalarBin)):
        Q = ECdouble(Q)
        if ScalarBin[i] == "1":
            Q = ECadd(Q, gen_point)  #
    return Q

def private_to_hex_publics(hex_private_key: hex):
    public_key = EccMultiply(GPOINT, hex_private_key)
    public_uncompressed = f"04{hex(public_key[0])[2:].upper()}{hex(public_key[1])[2:].upper()}"

    if public_key[1] % 2 == 1:  # If the Y value for the Public Key is odd.
        public_compressed = ("03" + str(hex(public_key[0])[2:]).zfill(64).upper())
    else:  # Or else, if the Y value is even.
        public_compressed = ("02" + str(hex(public_key[0])[2:]).zfill(64).upper())
    return public_uncompressed, public_compressed

def hash_256_from_hex_string_like_bytes(hexstring: str):
    return sha256(bytes.fromhex(hexstring)).hexdigest()

def ripemd160_from_hex_string_like_bytes(hexstring: str):
    return new('ripemd160', bytes.fromhex(hexstring)).hexdigest()

def b58encode(hex_string, expected_length=None):
    v = binascii.unhexlify(hex_string)
    alphabet = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"
    lev, number = 1, 0
    for char in reversed(v):
        number += lev * char
        lev = lev << 8  # 2^8
    string = ""
    while number:
        number, modulo = divmod(number, 58)
        string = alphabet[modulo] + string
    if not expected_length:
        return string
    elif len(string) != expected_length:
        raise Exception(f"b58encode: Expected length={expected_length} obtained length={len(string)}")
    else:
        return string

def sha256_get_checksum(hex_string_to_checksum):
    hasha1 = hash_256_from_hex_string_like_bytes(hex_string_to_checksum)
    # print("HashA1", hasha1)
    hasha2 = hash_256_from_hex_string_like_bytes(hasha1)
    # print("HashA2", hasha2)
    return hasha2[:8].upper()

def sha_ripe_digest(hex_string_to_checksum):
    hashc1 = hash_256_from_hex_string_like_bytes(hex_string_to_checksum)
    hashc2 = ripemd160_from_hex_string_like_bytes(hashc1)
    return hashc2.upper()

def wif_from_private(privkey: hex):
    # put 80 for bitcoin and concatenate with privkey
    prepend = "80"
    private_key_str = hex(privkey)[2:].zfill(64)
    prepended = (prepend + private_key_str).upper()
    compressed = (prepend + private_key_str + "01").upper()

    if len(prepended) != 66 or len(compressed) != 68:
        raise Exception("WIF conversion: Wrong prepended or compressed private key, length not 66")

    uncompressed_checksum = sha256_get_checksum(prepended)
    compressed_checksum = sha256_get_checksum(compressed)
    private_key_uncompressed_checksum = prepended + uncompressed_checksum
    private_key_compressed_checksum = compressed + compressed_checksum
    private_key_WIF_uncompressed_Base58 = b58encode(private_key_uncompressed_checksum, 51)
    private_key_WIF_compressed_Base58 = b58encode(private_key_compressed_checksum, 52)

    print("PREPENDED:\t\t\t\t", prepended)
    print("PRIV_UNCOMP+CHECKSUM:\t\t\t", private_key_uncompressed_checksum)
    print("Private_key_WIF_uncompressed_Base58:\t", private_key_WIF_uncompressed_Base58)
    print("PRIV_COMP+CHECKSUM:\t\t\t", private_key_compressed_checksum)
    print("Private_key_WIF_compressed_Base58:\t", private_key_WIF_compressed_Base58)
    return private_key_WIF_uncompressed_Base58, private_key_WIF_compressed_Base58

def hex_public_to_public_addresses(hex_publics):
    uncompressed = hex_publics[0]
    public_key_hashC_uncompressed = "00" + sha_ripe_digest(uncompressed)
    checksum = sha256_get_checksum(public_key_hashC_uncompressed)
    PublicKeyChecksumC = public_key_hashC_uncompressed + checksum
    public_address_uncompressed = "1" + b58encode(PublicKeyChecksumC, 33)
    print("Public address uncompressed:\t", public_address_uncompressed)

    compressed = hex_publics[1]
    PublicKeyVersionHashD = "00" + sha_ripe_digest(compressed)
    compressed_checksum = sha256_get_checksum(PublicKeyVersionHashD)
    PublicKeyChecksumC = PublicKeyVersionHashD + compressed_checksum
    public_address_compressed = "1" + b58encode(PublicKeyChecksumC, 33)
    print("Public address compressed:\t", public_address_compressed)
    return public_address_uncompressed, public_address_compressed

if __name__ == "__main__":
    privkey = 0xe41b45e722251672c01a28e4fada590471fea09f90d13b143033ed3a1107ef49
    print(f"PRIVATE KEY:\t {hex(privkey)[2:].zfill(64).upper()}")

    # Public hex test
    hex_publics = private_to_hex_publics(privkey)
    print(hex_publics)
    print()

    # WIF creation test
    wif = wif_from_private(privkey)
    print(wif)

    # Public keys
    public = hex_public_to_public_addresses(hex_publics)
    print(public)

The script is inspired by this site.
Finally you will obtain the two public keys, uncompressed and compressed:
'12sF1DbBbPaoNYrs28Qm7waiCcAVoF93Nn', '1BMKGYmgjrvmSDtvLZvKjyVMnbi6FLmcVi'

Hope this will help you.
Note: it will give you the WIF format too.
Full output:
PRIVATE KEY:     E41B45E722251672C01A28E4FADA590471FEA09F90D13B143033ED3A1107EF49
('04417A55413D948D79F5194F1F2CD670F078CB7F6D3A2F2B12E8CDF9A3268CAD3BAAA3251D2587D4E57ACBCE7991B72355EA33C44DBCF260D09B6C921879A61AA4', '02417A55413D948D79F5194F1F2CD670F078CB7F6D3A2F2B12E8CDF9A3268CAD3B')

PREPENDED:                               80E41B45E722251672C01A28E4FADA590471FEA09F90D13B143033ED3A1107EF49
PRIV_UNCOMP+CHECKSUM:                    80E41B45E722251672C01A28E4FADA590471FEA09F90D13B143033ED3A1107EF496CB6A884
Private_key_WIF_uncompressed_Base58:     5KYkFr9FMmBVcwjLbJinAw94b985tgyt4PL9Jhcjsk6J6ZRfxjM
PRIV_COMP+CHECKSUM:                      80E41B45E722251672C01A28E4FADA590471FEA09F90D13B143033ED3A1107EF4901070CD9AC
Private_key_WIF_compressed_Base58:       L4s7vXuQNe1KKeZsURDQNqxaqgrGb9U4MwZVf8GkEyCNTKyEk3iK
('5KYkFr9FMmBVcwjLbJinAw94b985tgyt4PL9Jhcjsk6J6ZRfxjM', 'L4s7vXuQNe1KKeZsURDQNqxaqgrGb9U4MwZVf8GkEyCNTKyEk3iK')
Public address uncompressed:     12sF1DbBbPaoNYrs28Qm7waiCcAVoF93Nn
Public address compressed:       1BMKGYmgjrvmSDtvLZvKjyVMnbi6FLmcVi

Editing original code by Jon Do request
import ecdsa
import hashlib
import base58

def bytes_to_hex_string(b: bytes):
    return ''.join('{:02x}'.format(x) for x in b).upper()

def get_prepend_if_even_or_odd_for_compressed(x_point):
    y = int(x_point[64:], 16)
    if y % 1 == 1:
        return "03"  # odd
    return "02"  # even

private_key = "e41b45e722251672c01a28e4fada590471fea09f90d13b143033ed3a1107ef49"

# Convert hex private key to bytes
private_key = bytes.fromhex(private_key)
print(f"Private key hex string: \t\t {bytes_to_hex_string(private_key)}")
print(f"Private key bytes: \t\t\t {private_key}")
# Derivation of the private key
signing_key = ecdsa.SigningKey.from_string(private_key, curve=ecdsa.SECP256k1)

verifying_key = signing_key.get_verifying_key()
print(f"Verifying key, x and y points (bytes):\t{verifying_key.to_string()}", type(verifying_key.to_string()))

x_point = bytes_to_hex_string(verifying_key.to_string())
print(f"Uncompressed private key (hex):\t\t 04{x_point.upper()}")

even_odd = get_prepend_if_even_or_odd_for_compressed(x_point)
print(f"Compressed private key in (hex):\t {even_odd}{x_point.upper()[:64]}")

# public_key = bytes.fromhex("04") + verifying_key.to_string()  # this is error, you're using uncompressed private key
public_key = bytes.fromhex(even_odd) + verifying_key.to_string()[:32]

# Hashes of public key
sha256_1 = hashlib.sha256(public_key)  # now public_key contains compressed private key
ripemd160 = hashlib.new("ripemd160")
ripemd160.update(sha256_1.digest())

# Adding prefix to identify Network
hashed_public_key = bytes.fromhex("00") + ripemd160.digest() # hashed_private_key is public key

# Checksum calculation
checksum_full = hashlib.sha256(
    hashlib.sha256(hashed_public_key).digest()).digest()
checksum = checksum_full[:4]

# Adding checksum to hashpubkey
bin_addr = hashed_public_key + checksum

# Encoding to address
address = str(base58.b58encode(bin_addr))
final_address = address[2:-1]  # change 2

print(f"Public compressed key (hex): \t\t {final_address}")

The new output is:
Private key hex string:                  E41B45E722251672C01A28E4FADA590471FEA09F90D13B143033ED3A1107EF49
Private key bytes:                       b'\xe4\x1bE\xe7"%\x16r\xc0\x1a(\xe4\xfa\xdaY\x04q\xfe\xa0\x9f\x90\xd1;\x1403\xed:\x11\x07\xefI'
Verifying key, x and y points (bytes):  b'AzUA=\x94\x8dy\xf5\x19O\x1f,\xd6p\xf0x\xcb\x7fm:/+\x12\xe8\xcd\xf9\xa3&\x8c\xad;\xaa\xa3%\x1d%\x87\xd4\xe5z\xcb\xcey\x91\xb7#U\xea3\xc4M\xbc\xf2`\xd0\x9bl\x92\x18y\xa6\x1a\xa4' <class 'bytes'>
Uncompressed private key (hex):          04417A55413D948D79F5194F1F2CD670F078CB7F6D3A2F2B12E8CDF9A3268CAD3BAAA3251D2587D4E57ACBCE7991B72355EA33C44DBCF260D09B6C921879A61AA4
Compressed private key in (hex):         02417A55413D948D79F5194F1F2CD670F078CB7F6D3A2F2B12E8CDF9A3268CAD3B
Public compressed key (hex):             1BMKGYmgjrvmSDtvLZvKjyVMnbi6FLmcVi

Thanks. You have a very nice script. But I need to modify my script for my application. Would you suggest how you can fix it?

I will try and add it to the previous response

Added some prints for explaining the error and commented errors @JonDo

I figured out what the problem is, your code in both cases accepts an uncompressed private key as input (Hex e41b45e722251672c01a28e4fada590471fea09f90d13b143033ed3a1107ef49). My task was to send a compressed private key as input (Hex-compressed 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef01) and from it I have to get the address. As a result, in the first version, the scripts work fine, and in the second case, an error occurs. Perhaps I did not explain the problem well, in any case, thanks for the help and I will be grateful if you can help me solve my question.

Hi @JonDo, maybe we can open another question and I will be happy to answer in it. Please send me a message and I will check it