text:
bitcoin transaction spent but not received
I hope you are well.
I had a weird transaction which was sent a few days ago,
it now says spent, and received but has not changed my wallet balance, sent it from one exchange to another. When it is spent, does it still have to be credited to your wallet somehow?
https://live.blockcypher.com/btc/tx/bddc545bb6963e964d82f6c80b1b8915f6cc94e228ea848818905fbc396a2a88/
Thanks,
Deon

yes, very much somehow, it would have to be credited. But: the tx number is currently not visible, so there is no possibility to see, what happened. I guess it might be somewhere "hanging", but other block explorers don't show it. When you say, it is spent, who rovides this info? And who provided the tx number?

@pebwindkraft thanks for the response! Oh, sorry, so if you look at blockchain.info or any blockchain for that matter, you will see it says spent, for one of the two amounts sent, for transaction, bddc545bb6963e964d82f6c80b1b8915f6cc94e228ea848818905fbc396a2a88

oh, so the transaction number was provided by the sending exchange, for some reason there are two amounts, mine and someone else's' maybe?

Ah, now I see it on blockchain.info. Yes. And ii has 57 confirmations right now. So if your providers wallet (exchange?) is linked to this address ("19wRqfMcdp2v1CuRGfJDdRKku4JMh5fUhX"), you should see the funds. The second amount is usually a return address for the change. Like if you pay for 45 Euros with a 50 euro bill, and get 5 back ...

@pebwindkraft, thanks I see, but my final balance has not changed, it says received x in total, but nothing in the final balance so it means what exactly?
https://blockchain.info/address/17eQCDAkfhSSB71kYis9UL4KioXdrgk5q1

19wRqfMcdp2v1CuRGfJDdRKku4JMh5fUhX, is their address where the refund when to probably, and this is my one, 17eQCDAkfhSSB71kYis9UL4KioXdrgk5q1

I can see that the 17eQCDA... address spent 50 bitcoins to other addresses in the last 4 tax. This doesn’t look like yours. These amounts are usually managed by exchanges... so it might be vice versa. I have the feeling that your “receive” address is wrong. Certainly I can’t help any further, best seems to be to get in touch with your provider.


text:
Increase the fee for hanged transaction
So I made the transfer from my wallet’ address to other wallet. I use Bitcoin Core 0.14.2. And I read "Would replace by fee increase the fee on my transaction?"
I apologize, was mistaken and appointed the small commission. Transaction hangs as unconfirmed the fourth day. How many will hang and it will be forgotten for backward God only knows.
Thus, my small mistake can lead to dramatic loss of time. The key of command line "- walletrbf" (for use further "bumpfee") is incompatible with a key "- prune".  In general this key  does many useful keys useless. But I use
 "- prune" for easy obvious reasons.
Can somebody explain, as it is possible to increase the fee of the outed transaction. Or to accelerate time of removal of transaction from network memory, spent it and a refund back to my wallet' address. I did not find any services for these actions in the Internet.

I don't see why -walletrbf and -prune should be incompatible. How did you arrive at the conclusion that they can't be used together?

For call "bumpfee.." in the console window I must start wallet with "-walletrbf" firstly. Yes, if I use both keys to start wallet  nothing happens. But after call "bumpfee.." I see notification that this command don't work with "-prune" mode and I need to start with "-reindex" command. It means I should wait aprox more one week for download full stack of blockchains. Unwanted hard case of overbombing. Nevertheless thank you.

Ah, I see. It might not have all the fee information in pruning mode. I'll have to ask around a bit.

The only command affected by -txindex is getrawtransaction. I don't see how it would have anything to do with bumpfee.

P.S. After all above I closed BTC Core and started it again. I get notification like this "Blockchains integrity failured. Start reindex blockchains?".  I just click "Abort" button to close BTC Core and restart it. I get both tx on the right side in gray. But after 20-30 minutes old (conflicted) tx disappeared forever,  simultaneously the new (confirmed) tx painted in black. Long Life "Rolling Stones"!
That's all.

I find easy way to solve the problem without bumpfee, -rescan, -reindex..

I stopped Bitcoin Core and renamed my wallet (from wallet.dat to wallet.old) and deleted mempool.dat.
VERY IMPORTANT! I had backup my walled before sent with mistaken fee!
Copy this wallet in bitcoin wallet folder and start Bitcoin Core.
First time all my actions go on 5 min and my failured transaction (tx) came back. I repeat 1-3 points and made all less than 3 min. - created new tx with increased fee and sent it.
blockchain.info showed my old tx, and didn't see the new tx. I try find it by hash, recipient address etc. - all the same: Oops, non existent transaction..
Ok, standby myself.
After aprox 10-12 hours I received the first confirmation of my new tx. At the same time old tx came back with cross icon. Right mouse click - on the bottom of context menu click "deny tx". Failured tx disappear.
After 1-2 hours my new tx get full confirmations and reached to recipient address!

Thanks to everyone.

Using opt-in RBF to increase your transaction's fee is only possible if the transaction was created as an RBF transaction in the first place. To that end, -walletrbf would have to have been active before the transaction was created.
For general advice on stuck transactions, please see: Why is my transaction not getting confirmed and what can I do about it?

Thanks. I see "Why is my transaction not getting..". What I get if used both commant line options "-walletrbf" and "-prune=600" I wrote above. Appropriate is obtained with deleting "mempool.dat" and trying start with "-zapwallettxes". Oh, "You have to use -reindex.."

source: Stack Exchange

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

sort: votes


text:
I used an old wallet address. Is my coin lost?
I was stupid enough to use an old exported QR code from my Electrum to send bitcoins to, and now I realized the address apparently has changed. The trader advises me the coins have been sent, so they are most likely lost in the ether -- or is there any chance this will get to my wallet eventually? I'm asking this because my Electrum is still syncing and I'm suspecting the coins might be climbing the blockchain-ladder to arrive in my account later?

Whats the transaction id? if you sent to an address generated by your electrum seed, then you have no problem.

If the address a wallet shows changes, that's OK. When you look at a wallet's receiving address at different times, unless it's a poorly designed wallet, it'll show different addresses. To increase anonymity, addresses shouldn't be reused, and therefore your wallet has multiple addresses. Don't worry, they'll come sooner or later (but make sure to be using the same Electrum wallet file).

Thanks a lot, you have successfully reduced today's alcohol intake. The amount is considerable.

@FissionChips regarding the synchronization problem you might want to upgrade to the latest version via electrum.org. Old versions have trouble syncing.

Thank you MCCCS and @Abdussamad, the problem has solved updating Electrum. Sorry for coming back so late.

Glad to hear that your problem is solved!

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


text:
Block 566687 nonce with extranonce, how to interpret?
This could apply to any block, but I was checking this one out found by Slushpool.
I've looked this up in Mastering Bitcoin and here on StackExchange, but the best I can get so far is: the coinbase tx is a script, where the first byte says "push three bytes on the stack", which turns out to be 9fa508 in hexadecimal.  Reversing the byte order to 08a59f gives the block number (566687 decimal).
This is where I get stuck. The book says the next few bytes are used to encode the extra nonce.
Then it gets a bit more detailed: "Eight bytes of extra nonce, plus the 4 bytes of "standard" nonce allow miners to explore a total 2^96 (8 followed by 28 zeros) possibilities per second without having to modify the timestamp." p. 266 Chapter 10 in the latest edition of Mastering Bitcoin.
I can't find any code examples to try and find the nonce for a block using the extra nonce, rather than the usual examples that go to a maximum 32-bit unsigned integer as the nonce.
Is it a concatenation of nonce + extranonce, simply 41678782744206783853?  (With  4167878274 the nonce, then the additional 8 bytes interpreted as a large little-endian integer?)
I've also seen it's apparently a push of a timestamp then another push of N bytes for the extranonce, but it's getting hard to find anything to actually test.
I can't just write something like this in Python:
 header = ( struct.pack("<L", version_) + prev_block.decode('hex')[::-1] +
      merkle_root.decode('hex')[::-1] + struct.pack("<LLQ", timetamp_, bits, nonce))

The nonce is way too big in this case to pack with Q of course.
What is the correct way to validate recent blocks interpreting the nonce and extra nonce?  Subtracting a little from the given nonce, so a loop only goes for say a few thousand times, adding +1 up to the nonce, then finding a block hash lower than the target doesn't seem to work with the extra nonce, although it does with older blocks that have a nonce that fits within an unsigned 32-bit integer.
The real nonce a much larger number, isn't it?  If it is, where is it, and how is it put together with the apparent nonce given on blockchain explorers so that a simple script can validate a recent Bitcoin block?
Thanks!

I can't find any code examples to try and find the nonce for a block using the extra nonce, rather than the usual examples that go to a maximum 32-bit unsigned integer as the nonce.

The nonce for the block remains unchanged. Since the extra nonce is part of the coinbase transaction, it modifies the merkle root, which is part of the block header. Thus, for each extra nonce, you get a unique merkle root, which then allows you to try the full range of regular nonces with that merkle root.
You do not need to concatenate or otherwise mix the two nonces in any form - the extra nonce's purpose is simply to alter the merkle root.
To validate a block with an extra nonce, you don't need to do anything special. Just build the transaction merkle tree, verify the merkle root matches the root in the block header, then hash the header and check it agains the target. It's the same process for blocks with and without the extra nonce.

Thank you Raghav, that was very useful. Now I can appreciate the books and other things I find.  I did find a big problem once I examined all the block values again after reading your answer.  I still had the version in the header set to 2, instead of 0x20800000.  Now the script works as expected.  Thanks again.

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


text:
Unable to find peers when connecting through tor proxy
I have tor running as a service on my computer and start bitcoind with -proxy=127.0.0.1:9050 but it fails to find any seeds through DNS or anything during startup, and even after leaving it on for more than a day it still not finding peers. I'm not getting any errors with connection or anything, and if I change port to for example 9051, it complains indicating that tor is running ok.
Also, if I run it without the proxy option I get peers immediately and syncing starts right away. Can someone please help me? I'm running 0.17.1.
Here is also a little bit of the console print during startup. I was running it without proxy right before this so it got a few blocks:
2019-03-12T00:45:31Z Loaded 8954 addresses from peers.dat  23ms
2019-03-12T00:45:31Z init message: Loading banlist...
2019-03-12T00:45:31Z init message: Starting network threads...
2019-03-12T00:45:31Z addcon thread start
2019-03-12T00:45:31Z init message: Done loading
2019-03-12T00:45:31Z net thread start
2019-03-12T00:45:31Z opencon thread start
2019-03-12T00:45:31Z dnsseed thread start
2019-03-12T00:45:31Z msghand thread start
2019-03-12T00:45:42Z Loading addresses from DNS seeds (could take a while)
2019-03-12T00:45:42Z 0 addresses found from DNS seeds
2019-03-12T00:45:42Z dnsseed thread exit
2019-03-12T00:46:02Z Syncing txindex with block chain from height 13187

Have you confirmed that tor is working correctly, say with a web browser? Temporarily set it to use a SOCKS5 proxy at 127.0.0.1:9050.
For more verbose information, try starting bitcoin with
commandline:
-debug=1
or
-debug=tor
bitcoin.conf:
debug=1
or
debug=tor


text:
Why do LedgerJS and Electrum, using the same Nano S and derivation path, not refer to the same Wallet?
I start Electrum in my cmdline like this:
./Electrum --testnet

I connect Ledger Nano S to my laptop.
In Electrum I make a new HD Wallet with Derivation path using the Nano S's private key as seed:
"m/49'/1'/0'"

In NodeJS (LedgerJS library) I write this code, using the exact same derivation path, also using the Nano S private key as seed:
const transport = await TransportNodeHid.create();
const btc = new AppBtc(transport);
const result = await btc.getWalletPublicKey("m/49'/1'/0'");
console.log(result.getWalletPublicKey())

Now, since the TransportNodeHid connects to my Ledger Nano S, I expect that the AppBtc object generates a HD Wallet with the exact same seed, and therefore the derivation path
"m/49'/1'/0'"

should give me the exact same Wallet Master Public key and receiving Bitcoin address right?
However, in Electrum:
Master Public Key: upub5EorGi4nr15AW.....
Receiving Address: 2NEYbAH7x6sXU2bS....

and in my NodeJS application, using getWalletPublicKey():
{
    publicKey:'049bd7786109d5bed56.....',
    bitcoinAddress: 'mtCKwjnNzNZr.....',
    chainCode:'c511f1afedb628fdb93299747604b...'
}

Now, I figured out that the publicKey and chainCode that the NodeJS code returns can be combined somehow to create the Master Public Key. However, the bitcoinAddress property should be the address associated with my HD wallet right? It's different from the receiving address in the Electrum app, but it should still be a receiving address.
However I already tried sending 0.0001 BTC to it with Testnet but it never arrived in my Electrum Wallet. So does this mean that this address is not associated with my Electrum Wallet? Even though I gave the exact same Derivation Path and used the exact same seed (hardware device Ledger Nano S)?
How can I "get" more receiving Address from my HD Wallet using the LedgerJS library?
I have checked LedgerJS documentation and examples, but I wouldn't go so far as to call it "documentation", because most functionality is barely explained and examples are virtually non-existent. There's a lot of guesswork involved in how exactly everything works.
https://github.com/LedgerHQ/ledgerjs/tree/master/packages/hw-app-btc#getwalletpublickey
http://ledgerhq.github.io/ledgerjs/docs

A public key can have multiple addresses. It looks like what is happening here is that Electrum is creating a P2SH-P2WPKH type address while your NodeJS code is creating a P2PKH address. These are two different address types which have different spending requirements and transaction data. However Bitcoin sent to either address type can still be spent with the same private key and the same public key was used to create both addresses.
When you sent the Bitcoin to the P2PKH address, Electrum won't show it because it is not looking for Bitcoin sent to that address. Just because you have the private key necessary to spend some Bitcoin does not necessarily mean that your wallet will be looking for outputs of that kind. A wallet cannot track all possible output scripts that it can spend (it is infinite), it can only track the ones it is expecting to see. So for Electrum, it's only tracking the P2SH-P2WPKH address and not the P2PKH address that you sent Bitcoin to.

I see, so the bitcoin address given by Ledger is indeed connected to my wallet, but it isn't tracked. Then I suppose I have to get both apps to either use P2PKH or P2SH-P2WPKH. After that I need to find some way to either track the address given by LedgerJS in the Electrum app... Or I need to get an address from Electrum and use it in LedgerJS. Either way you have my gratitude, your elaborate answer has helped me greatly.


text:
How does a Cryptocurrency Exchange Start
I understand the basics of an exchange and how they work, but I am confused as to how one initially begins.
For example, in order for an exchange to function, there needs to be both bids and asks simultaneously. If there is no asks, then no one can buy that specific cryptocurrency therefore there is no volume/trades.
Would an exchange have to simply front some money and place ask orders themselves in order to get the volume jump started and then having the market take over?

For example, in order for an exchange to function, there needs to be both bids and asks simultaneously. If there is no asks, then no one can buy that specific cryptocurrency therefore there is no volume/trades.

No problem. One customer places the first bid. Later, someone places the first ask. If the prices cross, a trade happens. If not, then you now have an exchange with some liquidity.

Would an exchange have to simply front some money and place ask orders themselves in order to get the volume jump started and then having the market take over?

I don't see why. If I saw a new exchange with no offers at all, I'd happily place both a buy and a sell at prices I'd be happy to exchange at. The next person to come along may beat both of my offers if they're not generous enough. Now, the two of us are in a bidding war, the spread is getting tighter, and soon the prices will be attractive to people who need to buy or sell.

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


text:
My bitcoin address and name
Please how will the receiver of the bitcoin know that I send the bitcoin into his wallet. And how do i send the bitcoin into another person's wallet

Typically the receiver will create a different address for every payment he expects.
That way, once the expected amount of coins have arrived at the expected address, the receiver knows which payment was fullfilled.
This is a better approach than trying to figure out who paid - something that's not generally possible and hurts Bitcoin's privacy. Typically you don't care who pays a bill, only which bill was paid.

That's two questions, but I'll attempt to answer both:
The "receiver" of a bitcoin transaction is really just an address that in your case happens to be a peson and where that address is associated with a Wallet, e.g. a software app, installed on a SmartPhone.
The wallet app will have an area within it allowing users to view transactions. Depending on the wallet, it will either display as coins sent and received, or provide a link to an external service such as https://blockchain.info where info about the transaction can be viewed. Using the latter, the receiver (actually, anyone) can see that the address you used to send coins to, has been used as an "Output" in a transaction, and the address used to send the coins (e.g. your own wallet address) has been used as an "Input" to that transaction.
In summary: If both the sender and receiver address are displayed on blockchain.info, and have at least 6 "Confirmations", you can pretty much safely assume that the coins have been successfully sent and received.
As for how to send coins to another wallet, you'd follow the same principle:
1). Obtain address from the person you wish to pay
2). Using any wallet, punch in that address
3). Select the amount of coin to send to that address
4). Hit "send" or "pay" or whatever.
I hope that helps.

If you're happy with the answers, please consider marking it as "accepted".


text:
Creating a BTC Gateway with ATM Network
We have a ATM Network and we want to sell and buy BTC or ETH on our ATMs, using our own switch. How can we do it?

Buy one of these: https://coinatmradar.com/shop/buy-bitcoin-atm/

We already have the ATMs and Swtich software, just want to know how to interconnect to BTC provider.

What do you mean by "switch software"? What software do you have that supports buying and selling bitcoins with an ATM?

Unfortunately, not every platform is supported by all software decisions.
Try to use bitcovault software - it supports all means of BTC ATMs almost.
More info is here - https://bitcovault.com/software-for-crypto-atm

Unless I'm misunderstanding you. You just need to track the multi-currency balances inside your own gateway. There are a number of ways you could do this but without more information its difficult to help.
We recently built a Ripple based solution which keeps track fiat and virtual deposits using Ripple and you might be able to build or purchase something similar.
I hope this helps.


text:
Is it possible to use something besides sheer computational power as the limiting factor on block release?
Why hasn’t anyone tried to create a blockchain that, rather than using computational capacity as the hash scarcity test, just has a direct limit on how many times a particular wallet can make a guess per day? (or something like that..)
I’m just thinking that the whole arms race for processing power means that the system isn’t really as democratic as it initially seems. Like sure, you don’t have a fed that controls inflation, but every new crypto currency from now on will be mostly owned by whoever has the most ASIC farms won’t it?

direct limit on how many times a particular wallet can make a guess per day? (or something like that..)

Guess per day for what?
You can't limit it by wallet since you can't know what addresses are in a wallet. To the network, there is no such thing as a wallet (and technically no such things as addresses or Bitcoin objects either). If you were to limit it on a per address basis, then people would just generate infinite addresses (because they are essentially infinite and you cannot prevent people from generating as much as they want) to do their "one guess per day".

but every new crypto currency from now on will be mostly owned by whoever has the most ASIC farms won’t it?

No, that is completely incorrect. Miners are not an absolute authority and do not have a final say on anything. The consensus rules are something that everyone who uses a coin follows. If any consensus rule is violated by a block or transaction, that block or transaction will be rejected by everyone who is validating consensus rules, i.e. the full nodes. So no, miners don't control it or own the currency because they cannot force changes onto the community and it would be pointless to mine a coin if you are the only holder of it (i.e. there is no market so no value).


text:
BitMinter Hash rate
I checked on BitMinter (https://bitminter.com/) and it says my computational power is 2058Thps, is that a good thing for bitcoin mining, i'm rather new to the mining community and am uncertain. I would also like to know what software would be best to use on my computer, i am using a MSI GE62 Apache Pro.

That 2058 Thps is not your hash power, it's the total hash power of that mining pool.  And even if you have a super-fast computer, it's not worth mining. More info: In the ASIC-age, is it worth starting mining Bitcoin at home?


text:
Taxation and Cryptocurrencies
How can a government make people holding Bitcoin pay capital gains tax on their holdings if everyone is pseudonymous?
If crypto becomes widely adopted, will we have to rely more on sales taxes (e.g. at the point of sale), and less on wealth taxes?

This question seems borderline off-topic, as tax laws are localized to each country, but I think a generalized answer could be of interest nonetheless:
Bitcoin is money that grants the user of it full financial sovereignty. No third party needs to be involved for the user to hold, or use bitcoin. This means that there is the possibility of the user avoiding their tax liabilities.
However, this is not much different from cash, which is used to transact anonymously and without record, all around the world, every single day.
So I suspect that many jurisdictions will approach Bitcoin taxation in the same way that they do other things: voluntary reporting, with stiff penalties for those that make fraudulent claims.


text:
Incentives against selfish miners with 51% power
To me the situation of a '51% miner' is much like a government printing money - when they do, they get to finance their budget deficits as they get to spend the money first (when prices haven't changed yet). However, when that money gets into the system and people realize there's more money in the system, it leads to inflation that reduces the value of the currency (much like the reduction in the price of BTC). What stops a selfish miner with 51% mining power from double-spending like crazy in the short term before the price of BTC has had time to react, then pull out of BTC altogether? Then there would be no loss of wealth that the whitepaper says disincentivizes greedy attackers?
Thanks for your response in advance!

The minting of bitcoins is constant and a 51% miner can't change the supply of it and cause inflation. Changing the supply can only be done by developers, resulting in a chain split, which wouldn't be called Bitcoin (unless it gains the support of various companies and users)
You can't just mine loads of coins, double spend them and cash out. To spent the reward of a block, its miner has to wait 100 blocks (144 blocks = 1 day) If you're double-spending coins that aren't newly minted, you can do that, but economics says while you own 51% of the network, you would be devoting lots of hashpower (=electricity) and would earn lots of block reward, so you wouldn't want to forget to cash out the block reward. On the other hand, to cash out the block reward, you'll wait 100 blocks, by when the price of bitcoins will drop, and you'll be at a massive loss. In addition, if you have that much of a hashpower you'd want to continue mining for a long time. That means even more loss due to the change in the value of bitcoins.

For your second point, the miner does not need to use newly minted coins. They can use coins they have in reserve, or collude with another party that does, and then double-spend their coins.

Yes, I need to emphasize that miners wouldn't collude with double spenders because even if the double spent amount is huge, and miners are offered a portion of it, the miners wouldn't want to risk their investments.


text:
How many times has the dust limit and minRelayTxFee changed?
I understand that there's no minimum tx fee or minimum tx output amount in the consensus rules. However, the default minimum values for a transaction to be considered 'Standard' in Bitcoin Core have changed over time.
Is there any record of what these minimum values were (for output value and tx fee) in previous versions of Bitcoin Core without having to dig through the code?
Related to that, what's the best way to find out about possible changes that may be made to these values in the future?


text:
Help signing a P2WSH Multisig
I'm trying to construct a transaction in regtest mode that spends from a P2WSH 2-of-2 multisig.
Here is the funding transaction for 5 btc. It also contains a change output for 5 btc.
020000000001013314dcdc95c9aee89b7b0324ff2b472d73561d29cbd0cb58b37009b7193573700100000017160014a41c072b586d97105728775b124a88041e43afd2ffffffff020065cd1d00000000220020f9b7fbe4a3a7a621a19e03ef53d91a6391da83615826cbafa3062d3b39adfd380065cd1d00000000160014331039b508a3ad5633c045b24d94489adbaba0a00247304402204538711966348202e3d91352c7e5b2b0a4a7dab503946bc90ce912fd26f407ca02201e4334064a150227acc24095a6685505ef568c8e1e8a4e7053aa389c395ddf26012103993a782afaa894a4ea296210a5e72d46924898e9df91a74e32435c52b044fb3700000000
This is the transaction I am trying to spend from the escrow:
0200000000010135fff0ef75190ac3ead75b46713fb63da6bf642b4e064856d5778a3e21615f300000000000ffffffff010084d717000000001600141a6053fa355499bad556165474ca9661fd517c2b040047304402207be65e2f6d5fd8f7fdb421b65bdd53a1d0c9656e6fd7a8b9bef4954b08bc4250022066156cc85b84a783a7431cafa20f6e92272a2d28a484dd2becc259fea69b687501483045022100b608f0955ec89d0e3ff5e40ca36fb141425ddf0c8ab3880f45c44ca90155fd5702206606bbde73f5bea1fbb5da07fc17445ea5a1018efcad79fcda058180e203dd220147522103c2f21de0f430251d8e3987fbe89ff51f3d6f3a48b234b84b60ddb9f24d587cf52103e0948a03f50377290847d27c93d383b8ab7e2d0bc065e96e0e1136b315388b5452ae00000000
bitcoin-cli is giving me this error message when I try to broadcast it:

error code: -26
error message:
non-mandatory-script-verify-flag (Signature must be zero for failed CHECK(MULTI)SIG operation) (code 64)
Here are the private keys associated with the escrow tx:

privkey1 = "CF933A6C602069F1CBC85990DF087714D7E86DF0D0E48398B7D8953E1F03534B"
privkey2 = "BF933A6C602069F1CBC85990DF087714D7E86DF0D0E48398B7D8953E1F03534B"
and here is the bip_143 transaction digest preimage that does into double SHA256, which is then getting signed by the private keys:
hashPrevOuts ec4982463833211511676584168e5c2749598a966f84594d529ca4627af6f541
hashSequence 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044
outpoint txid 35fff0ef75190ac3ead75b46713fb63da6bf642b4e064856d5778a3e21615f30
outpoint index
00000000
scriptCode
522103c2f21de0f430251d8e3987fbe89ff51f3d6f3a48b234b84b60ddb9f24d587cf52103e0948a03f50377290847d27c93d383b8ab7e2d0bc065e96e0e1136b315388b5452ae
input_amount
0065cd1d00000000
sequence
ffffffff
hashOutputs
0c4a4515b0c862221d8376400bef5e085aba67281d774776f1bc083294180d6b
locktime
00000000
sighash
01000000
Full bip143 tx digest preimage:
02000000ec4982463833211511676584168e5c2749598a966f84594d529ca4627af6f5413bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e7066504435fff0ef75190ac3ead75b46713fb63da6bf642b4e064856d5778a3e21615f3000000000522103c2f21de0f430251d8e3987fbe89ff51f3d6f3a48b234b84b60ddb9f24d587cf52103e0948a03f50377290847d27c93d383b8ab7e2d0bc065e96e0e1136b315388b5452ae0065cd1d00000000ffffffff0c4a4515b0c862221d8376400bef5e085aba67281d774776f1bc083294180d6b0000000001000000
Any help with what could be going on or what to try would be much appreciated!

I found the problem, in the bip143 tx digest preimage, the scriptCode needs to be preceded by the length of the scriptCode. In this case 0x47


text:
What's the difference between all kinds of bitcoin addresses (Single, multisig, etc...) also compared to all bitcoin forks?
Bitcoin addresses start with 1. Multisig/Script addresses start with 3. Other forks of bitcoin have single letters that are different at the beginning. Is this letter simply and only prepended to the address after calculating it from the public key, or is there more math to be done in certain cases?

please find here some reference with links inside: https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses and step 4, https://bitcoin.stackexchange.com/questions/48322. Also I draw a picture in my response to this thread: https://bitcoin.stackexchange.com/questions/69315/how-are-compressed-pubkeys-generated/69366?noredirect=1#comment80625_69366. But I think it will be difficult to get the answer you are looking for - there are more than 1500 crypto currencies - maybe be a bit more specific what you are looking for?

@pebwindkraft Thanks for the answer. Well, come on. There's no 1500 bitcoin forks. Most of these 1500 are ethereum tokens. Let's talk about some like Dash, Litecoin, Vertcoin, Smartcash, Neblio, and a few others. All I see is that they have different prefixes. I'm wondering whether there's more to do there than prefixes.

@RutgerVersteegden I did mention examples in the last comment.


text:
What's the logic behind the way block proofs (in GetBlockProof) is calculated?
Bitcoin Core uses GetBlockProof() function to determine the contribution of a block to the total difficulty of the current chain, aka, nChainWork in CBlockIndex. I'm having trouble understanding the logic in that implementation.
Let's ignore the math gymnastics done there to avoid overflowing off uint256. The only part we need is the beginning of the comment:
// We need to compute 2**256 / (bnTarget+1)

And the question is simply, why?!
If I want to calculate the difficulty contribution of a block to the chain, my (possibly naive) logic would be: The lower the block hash value, the higher its contribution. While the equation mentioned in the comment achieves that, it doesn't do so linearly, but in a f(x)=1/x fashion. I don't get why. Again, my (possibly naive) implementation would simply be:
~arith_uint256(0) - UintToArith256(block.GetBlockHash())

which basically means: The lower the hash of a block, the higher its contribution to the difficulty. And if using the block hash is bad for some reason (I'd appreciate explaining why if it's the case), a similar proportionality can be made with just the target:
~arith_uint256(0) - bnTarget

Can someone please explain the reason for that division choice?

Any block, no matter how low its block hash is, contributes the same amount of work. This work depends on the current difficulty, as an average expected amount of work that should be performed to find this hash.
See these answers which explain the code you linked. Also this answer gives two examples of why the increased variance caused by making the work depend on the hash value isn't desirable.

Thank you for the links. This answers only why we're using the target instead of the block hash. It doesn't explain why division is used instead of difference like I showed in the question.


text:
Would bitcoin core work on a big endian system? Or even a system where C++'s `int` is not 32-bit?
Looking at the source code of bitcoin core, the serialization part, I see that there's no serialization abstraction layer that accounts for a possible different endianness or different binary layouts on different machines.
This is not only for disk serialization, but also for network serialization.
If bitcoin core was used on a big-endian machine, or a machine with int size not equal to 32-bit, it'll fail to connect to the network because all sizes will be incorrectly interpreted and values will be different.
Am I missing something or did I arrive at the correct conclusion?

The byteswap has been addressed in MCCCS's answer (it's done by htole16 and the like).  For the word size, can you explain specifically what you think is wrong?  That code appears, at first glance, to make proper use of the uintNN_t types.

@NateEldredge Many of the data structures being serialized use int/long/short/..., and serialize those directly. The serialization code per se does the right thing, but the data being serialized wouldn't.

ser_writedata8 does not care about endianness, in contrast to ser_writedata16, ser_writedata32, ser_writedata64. Single bytes don't need to swapped, as 8 bits have one address and there's no way to access specific bits without using BMI or arithmetic operations. Therefore, bit endianness is not important except in bitfields.

I know 1 byte doesn't need endianness flips. I just couldn't see how the flipping is being done.

@TheQuantumPhysicist For example, Serialize(Stream& s, uint16_t a) calls ser_writedata16, which calls htole16(obj);. htole16 does the bswap there.

It should work on big-endian systems. The serialization code for integers will byteswap on such systems. This was certainly tested at some point, but I'm not sure how recently someone has.
I don't think it will work on systems where int is different than 32-bit.


text:
If BTC.com has the highest hash rate, then why is it not the only pool prodcuing the blocks?
with respect to : https://blockchain.info/pools
BTC.com pool seems to have the highest hashpower of 5648.00  PH/s[as per https://btc.com/] .Then how is it that other pools are also able find the correct blocks before btc.com ?

Because it is like a lottery. You're not bound to win all the time, even if you "bought" the majority of tickets.
Everyone basically has a % chance of finding a new block ( which correlates with the amount of hashpower you have  ofcourse.)
Unless ofcourse you do a 51% attack, https://www.investopedia.com/terms/1/51-attack.asp, where certain blocks would be orphaned (not confirmed, since nodes are bound to follow the longest chain.
You could basically prevent other miners from mining any blocks, since you hypothetically will always find a block before they do ( and thus creating the longest chain.)


text:
If transactions are changed in memory how miners know it?
If Alice requests something to bob, then Alice sends her public key and Bob encrypts message by using Alice's key.
Bob uses his private key and hash function to make a signature.
After finishing this procedure, Bob sends encrypted message with signature.
At last, Alice decrypts message and put it in hash function and she compares output with decrypts signature.
This is what I understood about transaction.
But When transaction is waiting in memory If someone changes a content of signature by using bob's public key How miner know it is wrong signature?
To compare message with signature, miner needs Alice's private key. But miner doesn't have.
Is there other way to compare signature with encrypted message?

There’s literally no encryption in bitcoin anywhere.

The process you described is not what happens in Bitcoin. It is loosely what happens with software like PGP which use public-key cryptography to provide various security benefits when sending e-mail messages.
In either case, you don't use a private-key to verify the integrity of the data-content.
In the case of something like PGP, the recipient can use the sender's public-key to determine whether the signature was produced by the corresponding private key from the received message contents.
In the case of Bitcoin, any bitcoin node can verify any transaction in the blockchain using only data in the blockchain. For details of the principles you could read Satoshi Nakamoto's original whitepaper or online resources such as

https://en.bitcoin.it/wiki/Transaction
http://learnmeabitcoin.com/guide/digital_signatures_signing_verifying


text:
What is a relationship with total hash rate(hash power) and average block generation time?
This chart - hash rate means total hash rate of All minor?
I think the most significant factor for difficulty and block generation time is the hash rate of the biggest mining pool not total hash rate of all of minors.
I want to assure it that if there is a mining pool have 30% of total hash rate and this mining pool is the biggest pool.
Then this mining pool will succeed to find target hash value faster than others(stochastically).
Therefore, I think difficulty for block generation time will be set by this mining pool.
As a result, if other mining pools don't have a enough hash rate for example,  10% of total hash rate, then stochastically, it will takes 3 time more to find a traget value.
So i think the most significient factor is hash rate of the biggest mining pool
Am i thinking well?
And it seems like out of title, but i have one more question.
If fork is happened, Mining pool can recognize fork is happened?

This chart - hash rate means total hash rate of All minor?

No, it represents the hash rate of the network. It is determined by using the time it took to find the block and the current difficulty of the Bitcoin blockchain. To cite an example, the current difficulty bits are 0x1729fb45, which means we need to find a block header hash that is less than '0x00000000000000000029fb450000000000000000000000000000000000000000. This represents a one in 2.88e+22 chance of finding the header hash. Assuming block time of 10 min, this is 2.88e+22/600 = 47e+18 hashes/sec. If the block are found faster than 10 minutes the hash rate is higher, if it is found in more than 10 minutes, the hash rate is lower. That is what you see in the hash rate graph.

I want to assure it that if there is a mining pool have 30% of total hash rate and this mining pool is the biggest pool. Then this mining pool will succeed to find target hash value faster than others(stochastically).

No. Your big mining pool will only have a 30% influence over the difficulty adjustment. The rest of the network will have a 70% influence, which is more than what a solo miner has. The block time adjustement is based on how fast the blocks are mined (the algo tends to keep the average time at 10 min) not how much percent hash power each miner has.

Can a miner find if fork happened?

If miner receives two different blocks at the same height then he will know that the network has forked as half of the network will be seeing a different tip versus others. When the next block will be mined, on top of either of them, the network will converge again.

Thank you for answer:) but i still have a somthing unclear you said The rest of the network will have a 70% influence, which is more than what a solo miner has. Ues i agree when other network gather their hash rate. But I think other miner or mining pool will mine independently for their profit. so other miner's or other mining pool's hash rate will be less than the biggest mining pool. therefore If they mine independently, then it will takes more time than biggest mining pool when they try to generate a block. If you don't mind can you explain about this?

And one more... If the block are found faster than 10 minutes the hash rate is higher, if it is found in more than 10 minutes, the hash rate is lower. That is what you see in the hash rate graph. by this sentence, If i want to guess by using network hash chart that block generation will takes more than 10min or less than 10min, do i have to calculate expected hashes/sec by using difficulty? like 47e+18 hashes/sec

First, If your mining pool has a 30% hash rate of the network, that means that of the 100 blocks that are mined, 30 blocks are mined by the biggest mining pool you are talking about and rest 70 blocks are mined by others. Now, the block finding difficulty is adjusted based on time, which means it is dependent on how fast the network is mining the blocks. That means it is dependent on the absolute hash power of the total network and not the % of the total hash power one owns.

@HSKim Second As an example, when the chart shows that the hash rate is 55 exa hashes/sec, it means the block was found in 8.7 minutes.

Then in 51% attack,  51 % is percent of what...? If there is a 3 miner A, B, C and If A has a 51% of what..? I am sorry to continous question, but i think i am confusing hash rate of network and absolute hash power

@HSKim In that case the 51% is the percentage of the total hash rate of the network. What happens in that case is that one person will have higher hash rate than rest of the network combined. So the attackers probability to launch a double spend attack increases as he can change transaction is last few blocks and then race the network to create the longest chain. Having 51% hashpower doesn't guarantee a double spend attack, just that the probability of launching one is increased

Really Really thank you for answer:) I think i need more research for fully understing. Your answer must be helpful for further research. Have a nice week!


text:
When a new block is propagated, nodes validate from genesis block to propagated block?
For example, I have a nth block and when n + 1 th block is propagated, i have to compare with n+1 block's previous hash and nth block's hash for validation. It is pretty trivial.
But do i have to compare hash value for validation from genesis block to n + 1 block?
like comparing 0 and 1, 1 and 2, 2, and 3 ... n and n + 1
One of the most famous pseudo block chain code in github
https://github.com/dvf/blockchain/blob/master/blockchain.py#L37, block is validated from genesis block.
Bitcoin use similar way to validate a new block?

Related? https://bitcoin.stackexchange.com/questions/72910/verifying-old-blocks

Nodes do not validate blocks from genesis each time a new block is received.
During the initial sync, nodes will validate, at the very minimum, the headers from the genesis block upto the current chain head - this allows them to find the best chain (by amount of work done). They also usually verify the utxo set.
When a new block is received, simply validating it against the previous block hash and the current utxo set is enough, as your previous block is already verified, which means all blocks before that are also verified.
If you happen to lose your local copy of the chainstate and only have raw blocks left, then you would need to revalidate from genesis.


text:
Does buying bitcoins and not spending them have negative influence of the bitcoin price?
I'm curios whether stock investing behavior have negative infect on the price of the bitcoin and other cryptocurrencies. Since popular delusion is that the crypto is like a stock where you buy coins and wait for the right time to exchange it. What if most of the people don't wanna spend there bitcoins will that make them unpractical for use?

Possible duplicate of Does hoarding really hurt Bitcoin? or Will deflation destroy Bitcoin?

No, it won't.
Why do I buy things with dollars rather than used toilet paper? I have lots of used toilet paper. I don't need it. I would much prefer to keep my dollars and get rid of my used toilet paper. But instead I buy things with my precious dollars. Why?
Simple. I buy things with dollars because the people I trade with really, really want dollars. They don't want used toilet paper. Because they really want dollars, they offer me good deals when I pay with dollars. Thus, even though I'd prefer to hold my dollars, I use them in trade precisely because other people also want to hold them, which makes them ideal for trade.
The more people want to hold bitcoin, the more useful they are in trade. The people I trade with want to hold them, and so will offer me good deals to make my part with my previous bitcoin.

Every investor has a different threshold for risk tolerance. A price one investor might consider as cheap, might be expensive for another investor (read Greater Fool Theory.) If the investor base of bitcoin is considerably large, at any point in time you are highly likely to have two parties trying who will be willing to take opposite positions. Improvement in liquidity, introduction of new financial contracts (futures, derivatives) can go a long way in helping improve the price volatility in bitcoin and attract a wider base of investors.

I think, it does not. Because we also don't buy things with gold. But the value of gold is not lessing.
We have gold jewelry and it does not lose is value because of laying in our caskets


text:
Is 24 words seed safer than 12 words in terms of bruteforcing the private key
Is a 24 words seed more secure than 12 words in terms of brute forcing the private key?
From the following answer I read that a private key is always "just" 128bit even when derived from 24 words. So it doesn't matter is that correct?
Using more than a 12 word mnemonic phrase
here it says "ECDSA secp256k1 only have 128 bit strength" but the question linked is about if passphrase improves security.
12 or 24 words for menomonic?
Or is it recommended to use 24 words over 12 words in regards to brute forcing?

Regardless of whether you have a passphrase or not 12 words is just as secure as 24 words because the resulting public key will still require 2^128 iterations to compute its private key using the most efficient algorithm.
That is relevant because the most efficient algorithm to crack secp256k1 keys "Pollard's rho algorithm" does not try to guess your password or seed words but instead tries to reverse a public key to its private key.
It should probably be noted that properly generated Bitcoin keys cant be cracked efficiently with modern hardware even with Pollards rho, improperly generated or purposefully weaker keys may be cracked
So no it is not recommended to use 24 words it is completely optional, it may theoretically help against attacks in which someone guesses / brute-forces your seed phrase (assuming your seed phrase was generated in a securely random fashion) but brute-force is still highly inefficient compared to Pollard's rho algorithm. This is more or less  covered here:
12 or 24 words for mnemonic?.

In fact, cryptographically speaking, there is no benefit to private keys having more than 128 bits of entropy, as long as there is no pattern in them (e.g. don't use just 128 bit numbers as private keys, that's broken, but using the hash of 128 bit numbers appears to be just fine). The reason for suggesting more is just defense in depth. –
Pieter Wuille
Feb 25 at 6:00

24 words = 256 bits, 12 words = 128 bits. But finding a private key given the public key already costs only 2^128 operations (using e.g. Pollard's rho algorithm, not using brute force of course). So if an attacker can just attack the private key keys that come out directly, there is no reason to try to find the seed. –
Pieter Wuille
Feb 25 at 19:28

@drivenuts yes thanks, sorry I typed it pretty fast

My colleagues argue that in Bitcoin the "Pollard's rho algorithm" does not apply. The master key's public key should never be exposed and therefore brute forcing it will only depend on the input entropy. Therefore 24 words > 12 words.

@Poseidon Entropy is the wrong term. 24-word based private/public keys do have 256 bits of entropy, but it still only takes on the order of 2^128 iterations to compute the private key from a public key.

@drivenuts It is indeed often the case that the master public key is not revealed, so it is true that a hypothetical 2^128 attacker can break individual keys (because those get their pubkey revealed), without being able to break the master key. I'm not sure how much that distinction matters, but it is correct.

@PieterWuille Thank you I edited the post to include your correction.

@drivenuts If you never spend from your master public key (which is normal as far as I know) then yes, the input entropy is what is important for the master public key. However there are still child keys which are commonly spent from in which case Pollards rho becomes relevant to those keys. If it is an HD wallet an attack on a child key would not reveal its parent key but if it was not HD then it would be trivial to reveal from an attacked child key. Brute forcing 12 or 24 word seed phrases when picked in a securely random fashion is incredibly unlikely / inefficient.

@Poseidon in your last update you start mentioning "password", this is slightly confusing me now, are you referring to mnemonic passphrase (infamously called 25th word)?

@drivenuts I brought up passwords because of the first link you provided, I was just suggesting the passphrase would not increase number of rounds to crack in Pollards rho. It may increase input entropy though.

makes sense to me, thanks for clarifying.

Both a 12 and 24 word seed should be secure.
2048^12 = 5.44x10^39 and 2048^24 = 2.96x10^79 are both insanely high numbers of possibilities that will protect you from brute force attempts. Note given the checksum these numbers are smaller, but very high none the less.
The amount of starting entropy is going to be larger with a 24 word seed, but yes they will result in the same sized keys.
Given a sufficiently random process or wallet software, both a 12 or 24 word seed will be safe.

yes both are safe, but I explicitly want to know if 24 is safer. You say: "they will result in the same sized keys" does that mean they are equally safe in terms of brute-forcing the private key?
https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#master-key-generation says: "the produced keys are only 256 bits long, and offer about half of that in terms of security."
Does it matter if the "starting entropy" is higher if it is reduced later to 128bit anyway?

and in my first link Pieter Wullie writes: "a private key is always just 128bit even when derived from 24 words." so is it the same security regardless of starting entropy?

What if they aren’t generate properly?  Wouldn’t a 24 word seed then still provide good security while the 12 word would not ?  Again assuming both were generated improperly

In terms of brute-forcing the private key, both a 12-word seed phrase and a 24-word seed phrase offer the same level of security if they are generated using a strong random number generator.
The reason for this is that the private key derived from the seed phrase is essentially a 256-bit number in the case of the Bitcoin protocol (specifically, the secp256k1 elliptic curve used in Bitcoin). The seed phrase is used to deterministically generate the private key, but the private key itself has a fixed length of 256 bits.
When using a 12-word seed phrase, the seed phrase is used to generate the private key through a series of cryptographic operations. Similarly, when using a 24-word seed phrase, the same process is followed to generate the private key.
The extra words in a 24-word seed phrase are used to provide additional entropy and increase the number of possible seed phrases. This helps in protecting against the possibility of collisions (two different seed phrases generating the same private key), but it does not directly impact the security of the private key itself.
In summary, the security of the private key is determined by the length and randomness of the underlying bits used to generate it, rather than the number of words in the seed phrase. Both a 12-word seed phrase and a 24-word seed phrase can provide strong security if generated properly.


text:
Calculating height of block
How do I calculate a possible height at which a block should be mined some time between 2 given times (say 8:00 am - 10:00 am)?

The average interval between blocks is 10 minutes for BTC. There are twelve of intervals of ten minutes in two hours, so nine or ten blocks is a good estimate.

You can’t. There’s no solid relationship between block interval and the time stamp in Bitcoin, you can’t estimate how many blocks will have been mined in any given period with any accuracy.


text:
Concept of Block weight and segwit are still unclear
It seems like duplicated question, but i read many articles and posts to undestand about segwit.
Below links are something i read
What is block weight and how is it different from block size?
After Segwit Activation, what is the largest block size possible?
Understanding Segwit Block Size
Block weight
But i need example to clearfy about block weight T_T
In
Understanding Segwit Block Size article, writer said that

The Segwit blocks are restricted by something called Block Weight.
  Block Weight is a new concept introduced in Segwit, and it’s calculated on a per-transaction basis. Each transaction has a “weight” which is defined this way:

(tx size with witness data stripped) * 3 + (tx size)

I think tx size is
tx = transactions + witness data

Then i stuck in recursion... I cannot undetstand.
To me, it seems like contradictory.
Because to define a tx size, needs Block weight to restrict witness data size. But to get a weight, need a tx size.
I understood that if there is no witness data, then maximum block size is 1mb(Before segwit). Yes It is clear. But some people are using weight same with byte.
For example, some people said(especially bitcoin wiki - Block weight)
weight = 1mb * 3 + 1mb = 4mb

And others said(What is block weight and how is it different from block size?)
Even in this post, Sam Jone said 4,000,000 WU but block is still 1mb
weight = 1mb * 3 + 1mb = 4,000,000 Weight unit(WU) Or 4mWU

what is the exact expression?
and If there is no witness data then what is left 3mb or 3mWU filled? is it empty?
In Block #577639, Block size is 1158.038 kB
How witness data is sotred?
1mb transaction + witness data right...?
or
1mb block is shared by transactions and witness data?
Basic concept of segwit is keep a block size as 1mb for transactions and add witness data right...?
It means size of transactions(witness data is excluded) is 1158.038kB?
or transactions + witness data is 1158.038kb?
As we know, maximum block weight is 4mWU or 4mb. Therefore, if transactions without witness data is about 1.1mb, then it seems like weird
block weight = 1.1mb * 3 + (1.1mb + witnessdata)

Because it is larger than possible maximum size.
If transactions + witness data is about 1.1mb
block weight = (1.1mb - witnessdata) * 3 + 1.1mb

this calculation seems more reasonable. But if witness data is less than 0.1mb then block weight is more than 4mb. Is it possible that so little witness data?
And If There is only transaction data and no witness data like 1mb transaction data and 0 witness data(block weight is 4mb or 4mWU which is theoritical maximum size)
Then how Transaction Malleability problem is solved?
I am so sorry. Questions are quite long, but i hope it can be helpful not only me but also person who are studying about blockchain.
Thank you for reading

Have a look: https://blockchair.com/bitcoin/block/0000000000000000000cbbceb342e07071f9621607e044ec909aa86fcdf88e8a
Size = 1,158,038 bytes
Weight units = 3,992,825 WU

Now what does it mean? So the size is what you probably understand well – when you have a file on disk, its size is measured in bytes and this is exactly what the size means here. It is the number of bytes you would need to store such a block in memory or on disk. This is the sum of non-witness data (nWD) and witness data (WD). Let's call this the absolute size for clarity (AS).
There is also something called virtual size (VS). This is a new concept, which measures the block in new units, called vBytes. It is calculated as (absolute size of non-witness data) + (absolute size of witness data)/4.
Weight of the block (BW) is calculated in weight units and is calculated as (absolute size of non-witness data) * 4 + (absolute size of witness data). This actually equals what you have mentioned in your post: (tx size with witness data stripped) * 3 + (tx size) because the transaction itself contains both witness and non-witness data.
So, now we know that:
AS = 1,158,038 bytes = nWD bytes + WD bytes
BW = 3,992,825 WU = nWD * 4 weight units + WD weight units

What are the limits in the protocol? Currently there is no block size limit any more. There is just one limit for block weight. This limit is set to 4,000,000 WU. It follows that in case of a block without Segwit txs, each byte's weight is 4 WU, therefore, such a block without Segwit txs is limited by absolute size of 1 MB.
Blocks that contain Segwit txs can be bigger than that and there are some theoretical calculations that say you can go to something like 3.7 MB of absolute size of a block. But this theoretical limit is just that – theoretical. In practice, even if the block was full of Segwit txs, its absolute size would not reach this limit.
Currently, most blocks contain both txs - Segwit and legacy, so we see the block sizes of full blocks usually in the range between 1 - 2.2 MB. The block is full if it's weight is very close to the protocol limit of 4,000,000 WU.
This implies that it is not correct to think that a block of size 1.1 MB is composed of 1,000,000 bytes of nWD and the rest is WD. That wouldn't work because the weight of 1,000,000 nWD bytes would already be 4,000,000 WU and therefore if we added the weight of WD to it, we would be over the limit. That is not possible.
So, if we know AS = 1,158,038 KB then it is rather that there are 944,929 bytes of nWD with weight of 3,779,716 WU and the rest is 213,109 bytes of WD with weight 213,109. This makes the total weight of the block 3,779,716 + 213,109 = 3,992,825 WU.
We can now calculate VS:
VS = nWD vBytes + WD/4 vBytes = 944,929 + 213,109 / 4 = 998,206.25 vBytes

Virtual size (VS) thus cannot be greater than 1,000,000 vBytes, so this is what is meant if someone says that the new block size is still limited by 1 MB - they actually mean 1 million of vBytes.

wow.. really really clear. Thank a lot! but "Currently, most blocks contain both txs - Segwit and legacy" This sentence means even the latest block is still including a legacy transaction which has script inside?

Even the latest blocks contain non-Segwit transactions. But because they also contain Segwit transactions, the whole block is Segwit. I'm not sure what you mean by "script inside". Script is used in both Segwit and non-Segwit transactions. Because this topic is very wide, consider asking multiple questions with limited scope.

Thank you a lot very helpful. Have a nice week:)


text:
Miner modify pending block (not yet on chain) and successfully solve the PoW
For example, I pay a cup of coffee with bitcoin, and later remove that transaction from the pending block that is not yet on chain. After 10 mins, I successfully and luckily solve the PoW problem, and broadcast the modified block to everyone as well as append it to the blockchain.
Is the scenario above possible? If it is, how is it prevented?

It is perfectly possible, and it is why it is discouraged to take irreversible action based on transactions that are unconfirmed (=not in a block yet).
However, the transaction is not invalidated just because it is reversed. Another miner can still include it at a later time, unless you issue a conflicting transaction  (=double spend) with a higher fee.

thank you, but how could another miner can still include it at later time?
I thought that the transaction that I bought coffee is already on the chain (it's modified transaction, but others do not know it's fake) so they consider the transaction already validated and won't try to include it again later.
Or there's a mechanism that can help others detect the modified transaction which is already on chain, finding that its fake? If no such mechanism, does it mean that I cheat successfully(i.e. modify the transaction and push onto the blockchain, and no one knows, thus I can do double spending)

I mean that the original transaction that paid for the coffee can always be included in a later block by another miner unless a double-spend was done.


text:
Indexing of transactions in the blockchain
Say we have transaction T(1) from many years ago, at block height 125001; then a new transaction T(2), consuming all the outputs from T(1), comes up around block height 568720 (that's Today). There's a lot of blocks in between; many GB of data, and the nodes need to efficiently check that the outputs of T(1) were never used in all these years since block height 125001 before processing T(2). This looks like a scalability problem. How do the nodes usually do that? Do they perform a linear search? Do they have a B-tree index of all active transactions? A hash-index? Is there a more efficient way to find out? Is the blockchain structured in a way that this search is inherently trivial? What about the nodes that do not store the whole block chain history?
Thanks a lot.

Each full node maintains an UTXO set, that contains all the unspent transaction outputs. This UTXO set is built by each full node when it is initialized by going through all the blocks until the genesis block. The UTXO set, unlike the blockchain, is stored in the RAM of the machine to allow faster query (UTXOs are actually stored in $DATADIR/chainstate, but are aggressively cached in memory.) When a new block is received and validated, the nodes will remove data related to the UTXOs that are consumed and add the outputs of the new transactions to the UTXO set.

Would that be https://charts.bitcoin.com/btc/chart/utxo-set-size ? 69 MB sounds like a very small size to worry about scalability. Then again, it sounds too small.

It sounds like it's more like this: https://statoshi.info/dashboard/db/unspent-transaction-output-set (2.8 GB?). It's maintained in memory but, how will that escalate with time? Will forks be needed or something like that?

The latter (https://statoshi.info/dashboard/db/unspent-transaction-output-set) is more accurate. There's still work going on as to how to achieve optimization


text:
bitcoin difficulty determination
Given the bitcoin difficulty information in https://bitcoinwisdom.com/bitcoin/difficulty, determine the bitcoin difficulty on April 1, 2019 and April 1, 2020. State any assumptions made in this determination.

This sounds like homework, what have you tried already?

Bitcoin difficulty as per today is 6,379,265,451,411 which is calculated on March 24th
. It is said
that the difficulty of hashing in bitcoin is calculated every 2 weeks and each block will take 10
minutes to get generated (which is 9.9 as per the given link). So, the next hash will only be
calculated on April 7 i.e., 2 weeks from the previous difficulty. Hence, the current difficulty will be
continuing until April 1st, 2019 and it will be the same. The formula for calculating bitcoin difficulty
is Next difficulty = (previous difficulty*20160)/(time in minutes to mine last 2016 blocks). But the calculating difficulty for a year is not possible as the difficulty can only be estimated for every 2
week


text:
Outputs only from bitcoin address
I just want to ask is there any way on how to extract ONLY outputs from particular bitcoin address.
I need to export (make a list) on all address that were associated with the outputs from the sender address.
I have no coding experience at all, I've also come across this topic but I have no idea on how to make just so it will list only the output transactions and not inputs as well.
How to get the list of transactions of input/outputs for a bitcoin address in JSON format?
Hopefully someone will be able to help me,
Thanks in advance!

of course, this is possible. ready to pay for a tool?

What is the pricing for such a tool? And how does it work?

I can write such tool. It will parse the whole Bitcoin blockchain (or from specific blk00xxx.dat) and create a list of associated addresses. Mail me if you are interested in.


text:
How to run the Eclair client in terminal?
I'm trying to install Eclair on my machine according to the instructions for installing
Eclair. I downloaded the latest release, unziped the archive but coundn't find "eclair-node--<commit_id>/bin/eclair-node.sh". There is no "bin" subdirectory:
$ tree eclair-0.8.0/ -L 1
eclair-0.8.0/
├── BUILD.md
├── CONTRIBUTING.md
├── Dockerfile
├── LICENSE
├── README.md
├── SECURITY.md
├── codecov.yml
├── contrib
├── docs
├── eclair-core
├── eclair-front
├── eclair-node
├── monitoring
└── pom.xml

6 directories, 8 files

The folder structure you describe matches the source code of the repository. I think you accidentally downloaded the archive of the source code rather than the release binary of the node software.
On the Eclair release page, I see the same folder structure when I download the “Source code (zip)” (red arrow below), but you probably meant to download the “eclair-node-0.8.0-0077471-bin.zip” (yellow arrow) which when I unpack it has the folder you were looking for.


text:
What's the length of a extended key?
I'm reading Mastring Bitcoin/ch05. In this chapter, it says "Because the extended key is 512 or 513 bits, it is also much longer than other Base58Check-encoded strings we have seen previously."
Why can an extended key be 513 bits long? I think it should be: pub/private-key(256bits) + chain-code(256bits) = 512bits.

Does this answers your question? https://bitcoin.stackexchange.com/questions/114314/how-the-extended-key-in-wallet-is-512-bits


text:
Do bitcoind and bitcoin-qt resume blockchain downloading from the same place?
This is a multi-part question.
I downloaded source code of bitcoin core from github and compiled it on my Windows 10. Then I got bitcoind and bitcoin-qt among other commands. I first run bitcoin-qt and choose a directory(D:\bitcoin) for blockchain data storing. However because I need to use bitcoin-cli tool and bitcoin-qt doesn't expose an RPC service by default, I close bitcoin-qt and start bitcoind.
But then I found that bitcoind didn't download blockchain from where bitcoin-qt stopped(by run bitcoin-cli -getinfo). How can I make bitcoind download that way? (I use bitcoind -datadir=D:\bitcoin to do that, is it right?)
Another question is where should I put my configure file. In my home directory(C:\Users\MyName) or just in the same data directory(D:\bitcoin)? Does bitcoind and bitcoin-qt use the same configure file?

Not sure about the details on windows, but best is to point both to the same config file and datadir. Just setting -datadir should accomplish that. But I think by default, they should both use the same already, so not sure why that would not already work. Unless maybe you're starting one as Administrator and the other not (or a different user altogether). If bitcoind is running as a service, check which user it's running as (in service properties).

bitcoin-qt and bitcoind are built from the same source code. They largely use the same settings, data directory, and configuration file.
However, bitcoin-qt has a set of options that are specific to it. These settings are stored in a separate Qt defined location (on Windows, it's stored in the registry). bitcoind cannot read these settings. If you set your data directory by choosing the location in the dialog box that appears the first time you started, the data directory location is stored in the Qt specific settings so bitcoind cannot read it.
You can set the data directory for bitcoind by creating a bitcoin.conf file in the default data directory location (on Windows, that's %APPDATA%/Bitcoin) and adding the line
datadir=<path>

where <path> is the path to where you want the data directory to be.
Or by adding -datadir=<path> to the command you are using to start bitcoind.

I use bitcoind -datadir=D:\bitcoin to do that, is it right?

Yes, that is correct.

In my home directory (C:\Users\MyName) or just in the same data directory (D:\bitcoin)?

You should put the config file in the data directory that the software will open initially. If you are setting -datadir in your startup command or the datadir is specified in your Qt settings, then you should put the config file in the data directory.
If not, you should put it in the default data directory location which is C:\Users\<username>\AppData\Roaming\Bitcoin.

Does bitcoind and bitcoin-qt use the same configure file?

Yes.


text:
Unable to "sendcoins" using bitgo express apis - Windows OS
I am building an ASP.Net project (C# - .Net 4.8 - windows os - visual studio 2015).
I want to send bitcoin from one address in my wallet to another for test.
Trying to access api url :
https://test.bitgo.com/api/v2/tbtc/wallet/{walletid}/sendcoins
But every time getting same response:
{
    "error": "You have called a BitGo Express endpoint but this is the BitGo server. Please have a look at the BitGo Express documentation: https://www.bitgo.com/api/v2/#bitgo-express-rest-api",
    "name": "ApiError",
    "requestId": "irfo34r5541k06grtyy4j6n33",
    "context": {}
}

How can I successfully send coins using this api on windows os?
Is it possible to sendcoins without BitGo Express?

BitGo generally uses 2-of-3 multisig transactions. That means that when you send a transaction, you must provide one of the signatures, and BitGo will add the second signature once you submit the partially signed transaction to the BitGo API. Since you need to use your own private key material to generate a signature, the signature has to be created client-side, or you'd be leaking your private key to BitGo.
The flow to create transactions is that BitGo usually will create an unsigned transaction per your request, then you'll add the first signature locally, and submit the partially-signed transaction either to get BitGo's signature and submit the signed transaction yourself, or for BitGo to finalize and submit it.
Express is a standard nodejs server framework to build web applications. BitGo Express is a piece of server software meant to be run on your own server. It wraps the functionality of the BitGo SDK to a set of REST endpoints, and communicates with BitGo's API to make data requests, but since you run it (and it's completely opensource), you can trust it to perform client-side actions such as your signing operations.
The sendcoins endpoint is an Express point. To use it, you must run your own Express server and call the endpoint on your Express server. You tried calling the Express endpoint on BitGo's API instead, but since BitGo cannot perform your signature (as it doesn't have your private key), it cannot perform the functionality your Express server would offer on that call.
You will either need to use the BitGo SDK (bitgojs) locally to make a series of calls in your scripts, i.e. /api/v2/{coin}/wallet/{walletId}/tx/build, sign the tx locally, then submit it via /api/v2/{coin}/wallet/{walletId}/tx/send, or set up an Express server to be able to use api/v2/tbtc/wallet/{walletid}/sendcoins.
I suggest that you carefully read the "Overview" section of the BitGo documentation which describes the above and gives you more instructions on how to authenticate, get wallet data, etc: https://app.bitgo.com/docs/#tag/Overview

You need to call the BitGo express server running locally.

Run the docker image of BitGo express
docker run -it -p 3080:3080 bitgosdk/express:latest

Run your request using the localhost:8030, so your URL will look like this:
http://localhost:3080/api/v2/tbtc/wallet/{walletid}/sendcoins


text:
C# Bitcoin class - Create unique btc address for each order - make deposit & withdraw
I am looking for a good library in c# for bitcoin as payment method in my web site.
My purposes from this library :

Create unique btc address for each order
deposit job with callback url
withdraw job

Is there any library for that purpose?
Or should i use a third party api?

I am using visual studio 2015 & i am in .net 4.8 & i want to use that
library in asp.net.

I checked NBitcoin - It is working with .Net 4.8.
But there is no samples on it about my three purposes.

For send btc i found this Link - What about deposit with callback url & create unique btc address for each order?


text:
Is it possible to separate blockchain and wallet functions?
I'm looking for a way to use bitcoin-core in monero-way (It uses separate blockchain daemon and wallet daemon).
I'd like to run bitcoin-qt interface on my laptop and connect to external node with full blockchain. In this way I can share my full node with other people and my wallet will be safe.
Is it possible to use bitcoin-core in this way?
P.S.: I listen about electrum-server, but I don't want to use another software.

Is it possible to use bitcoin-core in this way?

No. bitcoin-qt is a completely standalone software that includes all of bitcoind's functionality. It does not start bitcoind in the background nor does it connect to a background daemon.

I know that this is not in the basic configuration. Perhaps there are highly specialized hacks for this?

You can run a node on a server and then run another node on your machine which only connects to that one. But the node on your machine would still have to download and verify the blockchain (you can prune it so it does not take up as much disk space).


text:
Bitcoin core wallet replication
I have a bitcoin core full node with a wallet on VPS.
I use my own script to connect to the RPC. The script works on another VPS.
Sometimes bitcoin VPS goes offline. Once the recovery took a long time because the blockchain broke down. I'd like to avoid this situation in future. I've bought another VPS and installed second full node. If main node goes offiline, scriptwill check it and will connect to second node.
Now I'm finding a way for syncing wallets between nodes. I know, hot copying wallet.dat file is not allowed. I tried to use cron for dumpwallet on master and restorewallet on slave. But restorewallet took a lot of time. And I lost some newest addresses.
What is right way to build bitcoin core wallet replication?

Why not let each node synchronize independently in the normal way?

Both nodes synchronize in normal way. My question about wallet synchronization.


text:
Question about Python library coincurve/libsecp256k
I am a noob with cryptography, just trying to learn using python and the library Coincurve ( https://github.com/ofek/coincurve ) which is a mature Python binding for libsecp256k1.
The following code creates a private key and produces a signature of the string "Hello world!".
pk = coincurve.PrivateKey()
message = b"this is a test!"
s = pk.sign_recoverable(message)

The signature s is a sequence 65 bytes.
The signature is recoverable: i can extract the public key of pk from s.
pub = pk.public_key
pub2 = coincurve.PublicKey.from_signature_and_message(s,message)
assert(pub == pub2)

So far all good! However I can't understand how to use the verify method. The following code
valid = coincurve.verify_signature(s,message,pub)

gives the following error:
ValueError: The DER-encoded signature could not be parsed.

So the problem is that the method verify_signature expects a signature in DER format. This is normally produced using the sign method, as opposed to the sign_recoverable method:
t = pk.sign(message)
valid = coincurve.verify_signature(t,message,pub.format())

which works fine.
So my question is:
QUESTION: How do I move back and forth from the "DER" format to the "recoverable" format in the Python library coincurve?
THANKS!

I don't know the coincurve package, but want to point out that you can't trivially move from the DER format to the compact recoverable format, as they don't contain the same information. There can be up to 4 (but typically only 2) valid public keys for a given message/signature combination, so the recoverable format contains a flag byte that indicates which of those public keys is to be recovered. This flag byte can't be computed from just the signature and message.

Recoverable -> DER
Use recoverable_convert. (which calls secp256k1_ecdsa_sign_recoverable)
DER -> Recoverable
Use sign_recoverable. (which calls secp256k1_ecdsa_recoverable_signature_convert)
^^I couldn't find an easier way.

I am not sure if I understand but
pk = coincurve.PrivateKey() message = b"this is a test!" s = pk.sign_recoverable(message) print(recoverable_convert(s))
gives me the error: TypeError: initializer for ctype 'secp256k1_ecdsa_recoverable_signature *' must be a cdata pointer, not bytes

Obviously this is an old question, but you need to deserialise the recoverable signature first: recoverable_convert(deserialize_recoverable(s))


text:
How and why we need to validate a transaction?
I've starting doing some researches about the Bitcoin protocol and the blockchain. I'm trying to understand all the sections in the Bitcoin white-paper.
So far, i couldn't understand what is the utility of adding the transactions merkle tree root on the block header. Yes, i know that it's done to save space as the paper said. But when do someone need it?
For example, when miners receives a new block, does they receive only the block header, or the block header with the transaction? Means, is the blockchain a chain of blocks of headers?
If the 8- Simplified Payment Verification section Satoshi said:

It is possible to verify payments without running a full network node.
  A user only needs to keep a copy of the block headers of the longest
  proof-of-work chain, which he can get by querying network nodes until
  he's convinced he has the longest chain, and obtain the Merkle branch
  linking the transaction to the block it's timestamped in. He can't
  check the transaction for himself, but by linking it to a place in the
  chain, he can see that a network node has accepted it, and blocks
  added after it further confirm the network has accepted it.

How can the user obtain the obtain the Merkle branch linking the transaction to the block it's timestamped in ?

So far, i couldn't understand what is the utility of adding the transactions merkle tree root on the block header.

To ensure that the transactions in the block are committed to by the block hash.
The block hash is not actually the hash of the entire block, it is the hash of the block header. If there were no merkle root, the block header would not contain anything that ensures that the transactions that are part of the block are actually part of the block. By hashing all of the transactions together into the merkle root and putting that in the block header, blocks received must contain all of their transactions so that the block header is valid.

Yes, you're right. But how does that save space? are the transactions removed and we keep just the merkle tree hash? if yes, how can we verify a transaction with just the merkle tree hash? if not, the block is always sent with it's transactions?

The merkle root isn't used to save space in block relay. A node must have the block in its entirety in order to validate it. Traditionally, this means the that the block is sent in full. The merkle root does not allow blocks transactions to not be relayed. Note that compact blocks allows block relay without sending the full block as it sends the information necessary for a node to completely reconstruct the block. That section in the Bitcoin paper is simply saying that the entire block does not need to be stored in full so it can be used to save space on disk.

Note that the method described in the Bitcoin paper for saving space on disk is not actually used. Current pruning methods are far more efficient and allow for the deletion of the block from disk entirely.


text:
multiple wallets on same mobile device
Can I install and use different wallet apps on one mobile device?
The intention is to have:

a hodl wallet and a daily use wallet
And to compare GUI for preferred UE

Will the apps interfere with each other in any way?

Yes, there is no nothing preventing you to doing that as long as you use different private key, but usually your mobile wallet will generate an HD wallet for you so you wont have to deal with that problem.
Just be sure to use recognized mobile wallet like those here https://bitcoin.org/en/choose-your-wallet?step=1
Also notice that some mobile wallet will offer you to have separate wallet inside their own software, like electrum

Sure, you can use different wallet apps. But it’s better to keep hodl wallet separate from mobile device because of security reason.


text:
Segwit includes the input amount in the SignatureHash. What possible attack can this prevent?
Legacy transactions only include transaction components in the SignatureHash, but segwit transactions also add the amounts of inputs in the SignatureHash.
Quoting from the Mastering Bitcoin Book:

Segregated Witness signatures incorporate the value (amount) referenced by each input in the hash that is signed. Previously, an offline signing device, such as a hardware wallet, would have to verify the amount of each input before signing a transaction. This was usually accomplished by streaming a large amount of data about the previous transactions referenced as inputs. Since the amount is now part of the commitment hash that is signed, an offline device does not need the previous transactions. If the amounts do not match (are misrepresented by a compromised online system), the signature will be invalid.

Quoting from that paragraph:

If the amounts do not match

What amounts? In what context?
What I don't understand here is that a transaction doesn't have the input amount anyway. It's hashed only post-segwit. But then if it's hashed, that doesn't add any value in transaction verification, because the previous output is signed in the previous transaction, and we either have the value from that previous transaction to check that no "money printing" happened, or we don't have it. It's not available in clear text anyway to add to verification.
What are the possible attacks or bottlenecks that could've been possible if the amount in the input is not part of the SignatureHash? Can someone explain the scenario in detail because I'm failing to see the full picture.

As a seed for someone that wants to write an answer: https://bitcoinops.org/en/newsletters/2020/06/10/#fee-overpayment-attack-on-multi-input-segwit-transactions

Consider a transaction that has 2 inputs and 1 output. Let's say that the inputs are both 1 BTC and the output is 1.5 BTC. This would mean that the transaction pays a 0.5 BTC fee, which is ridiculous.
Consider a hardware signer which has no idea of the blockchain's state, but it still needs to know those input values in order to display to the user before it signs the transaction. Let's suppose the hardware signer has a more efficient protocol where the host provides the transaction and just the UTXOs (the scripts and amounts) that are being spent.
If the host were honest, it would provide the transcation and the UTXOs spent with their correct amounts. The user would see that they are spending 2 BTC and throwing away 0.5 BTC as fee, so they would reject the transaction.
But what if the host were malicious? Suppose the host instead provided 1 UTXO correctly, but the second UTXO has the wrong amount - 1.500001 BTC instead of 2 BTC. Now when the hardware signer shows the user that they are sending 1.5 BTC with a fee of 0.000001. This would be a reasonable transaction so the user approve the transaction and it would be signed and sent. But what they actually signed was a transaction that sent 0.5 BTC to transaction fees.
With non-segwit scripts, the above scenario is possible, so in order to protect against it, hardware signers require that non-segwit inputs provide the entire previous transaction so that the transaction id can be calculated and compared against the transaction id given in the spending transaction. This guarantees that the amount is correct as if it were not, the transaction id would be different. But this can be a lot of data, and so it is not efficient.
However with segwit, the amount for a given input is signed, so it is not necessary to provide the full previous transaction. In the malicious case, the user accepts the transaction and the hardware signer signs it. However when it signs it, it commits to the amount of the input, and so it would commit to the wrong input amount of 1.500001 instead of 2. When this transaction is broadcast, nodes will validate the signature and find it to be invalid as they would be using the correct input amount of 2. Thus segwit prevents this attack from working.
...Except not completely. After segwit was deployed, we discovered there is a way bypass this. Suppose the malicious host is able to convince the user to sign the same transaction twice - perhaps after the first time it claims there was some error and the user needs to try again.
In this scenario, the host can provide the correct amount for the first input and the incorrect amount for the second input for the first signing attempt. This would produce a valid signature for the first input, and an invalid one for the second input. Then it prompts the user to sign again, and this time it provides the incorrect amount for the first input, and the correct amount for the second input. Now the malicious host has a valid signature for the second input too. It can combine those two signatures and produce a valid transaction which has the transaction fee of 0.5 BTC.
With this new attack scenario, some hardware vendors decided to require the entire previous transaction when signing segwit inputs as they do with legacy inputs.
But there is a solution for this second issue which Taproot solves. The solution is to commit to the amounts for all of the UTXOs being spent. Instead of just the amount for the particular UTXO that the signature will be in the scriptSig for, the amounts of all other UTXOs will be included in the signature. This means that changing one amount will result in all of the signatures in the transaction becoming invalid, so this new attack cannot work. Just for good measure, Taproot also commits to all of the scripts of all UTXOs as well.

The difference is really that with segwit, the input amounts are signed directly. They were already signed through the fact that the the prevout txids are signed, and these commit to the output amounts. But if signing software/hardware wants to observe those values, it needs to be provided with the preimages of those txids, which is a lot of data. By additionally including the input amounts directly in the signature message, we know signatures will be invalid if the amount provided to the signer mismatches the actual UTXO spent.

Thank you for the answer; I appreciate it. The Optech link in my question's comment gave me the answer, but the Taproot part from you is extra-helpful. If I understand correctly, the solution from Taproot is considered the default new way of doing things. If, however, someone wants to create an "Anyone can pay" commitment, the new solution wouldn't work, and then verification would require the old route of downloading the whole transaction of the inputs. Am I getting this right?

@TheQuantumPhysicist Yes, if you signed with anyone can pay, then the amounts are not directly committed to, because otherwise it wouldn't allow anyone to pay. The point of anyone can pay is that inputs can be added and removed by anyone, unless at least one input uses SIGHASH_ALL. However anyone can pay is almost never used in practice, and hardware signers (for which the protection is largely targeted towards) won't sign with anything other than SIGHASH_ALL.

@AndrewChow actually it is. More than a couple thousands input per day contain an ACP signature. (https://transactionfee.info/charts/bitcoin-script-sighash-anyonecanpay-all/, https://transactionfee.info/charts/bitcoin-script-sighash-anyonecanpay-none/, https://transactionfee.info/charts/bitcoin-script-sighash-anyonecanpay-single/)
The Specter supports signing using ACP. However it it's an "advanced" thing.


text:
transaction edit done by mining nodes
I'm reading through bitcoin manuals and I got this question, please help me to correct my understanding.
I'm aware that changing the transaction output amount value can make the transaction unusable. What happens if the mining nodes lowers the output value to get more transaction fee, in such scenarios how the bitcoin protocol counterfeit that?
Thank You.

very good question, I'd like to understand as well, experts to the front!
a tx is hashed, before sent to any nodes. This hash also identifies a tx. A node does for sure a complete check of the tx (https://en.bitcoin.it/wiki/Protocol_rules#.22tx.22_messages). So if the miner receives a tx, and afterwards changes a value in the tx, the tx hash wouldn't be the same anymore. It would be a new tx. This makes the tx maybe unspendable, but the miner would have increased fees? How is block assembly preventing this misbehaviour?

thank you, some clarity what I got is, the hash is computed on all the fields of transaction data except the signature field, any changes to tx data results in changed hash and for which malicious mining node can't compute the signature. But due to the changes the transaction is unusable any further. But still the mining node can compute POW and publish the block, and since each block verifies the block hash and tranaction signatures before assembling the blocks into blockchain at that point the other nodes simply reject the block.

So mining node doesn't get any support from the networking nodes in growing up the malicious chain. Though it's hypothetical if the mining dominates the power of computation of other nodes in the network, then in that case the complete corruption of block chain is possible I think.

Most transactions contain a digital signature which signs a hash of the transaction. Usually this hash includes the entirety of the transaction, so changing any part of the transaction would invalidate the signature and thus invalidate the entire transaction. The miner won't be able to change the output values you signed, because it would change the hash.

I think the hash does not include the signatures, when compiling a tx, you fill the signatures in the TXIN sigscript with the spending condition (the TXOUT pubkey script, e.g. 76A914+hash+88AC), then build the hash of the tx.

@pebwindkraft the hash did contain the signature (in the scriptSig of the input) before segwit, that is the cause of the transaction malleability. In a segwit transaction, the signature is not part of the TXID because it is part of the witness, so it is included in the WTXID hash

the signature is computed on hash of the all the data, except on signature since it won;t be possible. But here when the mining node changes the output value, hash will be changed and mining node can't compute signature on that, and if we assume mining node is malicious that skips the validation of transaction and publishes the block. But when other nodes receives the block while they accepting the block they check all the transactions and they invalidate the block, so in that sense this malicious chain of mining node won't be grown any further by any other nodes, except by mining node itself.


text:
How do I store coins during the bitcoin segwit2x hard fork?
Where should I securely store my coins during the fork? A Legacy address or a Segwit address?
I keep them on a Segwit address right now but I want to be sure that the fork won't affect my funds if kept on a Segwit address during the split.

It doesn't matter. Both types of addresses are safe during the hardfork, and you'll have access to both coins.
Have a nice weekend.

Because the Segwit2x fork has Segwit activated already and they are not disabling segwit, you can store your Bitcoin with any address that you want. You will be able to spend your coins on both sides of the fork regardless as neither Legacy addresses nor Segwit addresses will become invalid nor spendable by anyone.


text:
Is there a way to get stats about fees paid (highest, lowest, average) in a specific block?
I'd prefer to get the stats from my full node via bitcoin-cli, but if that's not possible some API would do the job too...

It is possible using bitcoin-cli, but you’ll have to write some scripts that calculate and index each transaction’s fee rate


text:
Where can I get bigger amount of test BTC?
We are conducting some testing with the end users of our application and I need a bigger amount of test BTC for it. Using faucets, I can get 0.1 or 0.01 per request with captcha, but I need something around 100. Is there any place, where I can get this amount at once?
Cheers.

I know someone who can sell you test Bitcoins instantly but that is not something I advise because Test Bitcoins should be available for free. However, if you want to buy them, reach out to  ussain bold at gmail

If you need 100 coins, you should use regtest mode, this is a message from a faucet website:

Please do not ask me to send a coin outside the faucet!
  My stocks of coins are shrinking and generation new coins is becoming more and more difficult.
If you really need a lot of testing coins, try some other solution. For example:
  bitcoin-testnet-box
  bitcoin-regnet

Link

In addition to @luong-nguyen's post above, if yours is a commercial operation you have a case to buy old mining equipment and mine your own testnet coins.
Jameson Lopp wrote about this here


text:
What happens if the commitment tx fee is too low?

How often are commitment tx fees negotiated?
Is it every time a payment is made and a new commitment transaction is formed?
What about if there are no payments but both nodes see that the on chain tx fees are rising, do they renegotiate and update their previous commitment txs?
If Bob goes offline and never returns, but the latest commitment tx is very old and the tx fee is too small to be included in a block, is there anything Alice can do to force close the channel? (anything other than getting directly involved with mining).
I believe "Child Pays for Parent" wouldn't work to help a force-close situation because the local output is encumbered by a to_self_delay relative to the time of it being mined, so the same miner couldn't include the "Child" in the same block. Is that correct?

Only if the state changes fees are negotiated (and for mutual closing the channel) so in case the onchain fees change and the channel is not used for a long time just send a fake payment hash to adapt to onchain fees.
Regarding 2 and 3. Nothing Alice can do. She just has to wait until the traffic on chain decreases. There are some ideas to include a dust level anyone can spend output to the commitment tx without timelock which could use cpfp

Is the "fake payment hash" sent automatically, or is something that a user should do if he wants to update the last commitment tx fee? Has this changed since your answer in 2019?