text:
Brute force a wallet.dat file
I have a wallet.dat file which is encrypted and I can remember that I have put only numbers as password(4 or 5 digits, not more, not less).
My friend suggested to do brute force on it using python.
I tried googling and unfortunately(poor programming) didn't got any python script.
Can anyone help me please ?

I would approach this using JSON-RPC with the programming language of your choice and the walletpassphrase command.
walletpassphrase "12345" 60
The 60 at the end is number of seconds before the passphrase times out and needs to be entered again. Now all you need to do is create a loop that iterates through all number combinations.
If the guess is wrong the bitcoin client will return
Error: The wallet passphrase entered was incorrect. (code -14)
If the guess is correct the bitcoin client will return
null
So all you would need to do is check for the response and if null then the guess is correct and you can stop your loop.

To bruteforce a wallet.dat file you would need to follow these steps.

Install python from python.org
Download john the ripper from github
run the script bitcoin2john.py to extract the hash
get hashcat from hashcat.net

With hashcat you can search the entire space of numbers of your choice using a mask ?d?d?d?d?d?d and increment.
Your hashcat command would look like: hashcat -m 11300 wallethash.txt -a 3 ?d?d?d?d?d?d?d --increment etc would work
Once the password is found you can use it to export the private key from core.


text:
Bitcoin daemon Error: Invalid combination of -regtest and -testnet
How to solve above title problem?
I first started with bitcoin as regtest.
Now I want to launch bitcoin as -testnet.
So I did like
root@q352-3023-vps:~/.bitcoin# bitcoind -testnet -daemon
but above error..

So this was because .conf file has line of regtest=1

source: Stack Exchange

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

sort: votes


text:
Electrum wallet not restoring with the right address?
I have the address and i can see my bitcoins in it. I have the 12 word seed, but when restoring my wallet with it in Electrum the address with my bitcoins isnt included in the ones generated.
I'm a noob at this please help :)

I wrote an FAQ about this here. It contains various things you can try.
Another possibility is that the address corresponds to an imported private key. In the past electrum used to allowed you to import private keys into HD wallets. These imported private keys are not restored when you restore from seed. So is this an address of an imported private key?

There are too many reasons for that, you should provide more details, but I'll share some possible reasons:

your 12-word mnemonic phrase is extended by an extra word (password), To fix there's an option while you are restoring your wallet, you should select and pass in your password.
derivation path, if you were using legacy bitcoin addresses so you should use path 44, Segwit 49, bech32 Segwit 84
electrum has their own bip39 wordlist, so if you are not importing electrum mnemonic phrase, you should select that option while importing.

electrum doesn't use bip44 for legacy addresses

I'm pretty sure they support bip44.

https://prnt.sc/j4obgt

that's for restoring from bip39. Electrum doesn't use bip44 or bip39 for it's native wallets. A wallet restored from a native electrum seed mnemonic would not use bip44 derivation.

That what I exactly mentioned, electrum has their own bip39 wordlist, so if you are not importing electrum mnemonic phrase, you should select that option while importing.

those are separate points so I got confused. you may want to edit it so it's clearer. you only need to select the derivation path if your wallet mnemonic is from some other wallet. if your wallet mnemonic is native to electrum you don't need to do that. btw the electrum dictionary is identical to bip39's. it's just the mnemonic format and derivation path for legacy addresses that's different.

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


text:
How get fingerprint after derive parent key?
After derive parent key i have IL, IR and pIL
Then i get ki:
curve_n = 'fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141';

ki = remainder((pIL + priv), curve_n);

I know that parentFingerpring is:
parentFingerprint = slice(rdm160(sha256(UNKNOW)), 4);

what varable or operation must be instead of UNKNOW?

UNKNOWN is the serialized compressed public key for ki. ki is the private keys, so compute the public key for it and serialize it in compressed form.

thx, can you say what formula i need to use for it ? ki * G where G is 0279BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798?

@Gabriel Yes, that is the correct formula and value for G

but the formula as I understand it is conditional?
and a rough multiplication will not give any result?

G is an elliptic curve point. It's standard elliptic curve point multiplication which is different from integer multiplication. The algorithms for that are more complicated, but there's plenty of literature on elliptic curve math that you can search for.

If possible, tell me articles about the literature, about this, where it is possible to explain step by step the course of actions of turning a private key into points on the eleptic curve

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


text:
bitcoin-cli error: couldn't connect to server on importaddress
When I give the import command I get an error after about 15-20 minutes. It's obvious that any other command did't show the same error.
~:./bitcoin-cli importaddress mvcWTfVhCMhwvqQf2TKkEqpLrNdW7Uekod false
error: couldn't connect to server

I found that client is rescanning blocks in debug.log which should not happen because I have added "false" after address.
2018-06-21 08:39:30 Still rescanning. At block 192380. Progress=0.011339
2018-06-21 08:40:30 Still rescanning. At block 218992. Progress=0.024155
2018-06-21 08:41:30 Still rescanning. At block 237569. Progress=0.036879
2018-06-21 08:42:30 Still rescanning. At block 261271. Progress=0.049859
2018-06-21 08:43:30 Still rescanning. At block 279577. Progress=0.061887
2018-06-21 08:44:30 Still rescanning. At block 294150. Progress=0.072921
2018-06-21 08:45:30 Still rescanning. At block 308378. Progress=0.123854
2018-06-21 08:46:30 Still rescanning. At block 321405. Progress=0.177669
2018-06-21 08:47:30 Still rescanning. At block 332018. Progress=0.230362
2018-06-21 08:48:30 Still rescanning. At block 341285. Progress=0.281512
2018-06-21 08:49:30 Still rescanning. At block 349955. Progress=0.329082
2018-06-21 08:50:30 Still rescanning. At block 358093. Progress=0.376275
2018-06-21 08:51:30 Still rescanning. At block 364784. Progress=0.417902
2018-06-21 08:52:30 Still rescanning. At block 370366. Progress=0.450470

The error :couldn’t connect to server shouldn’t happen even though blocks scanned because of import commend. And when running a shell script I wrote for the loop of importing address alarmed another error.
2018-06-21 08:33:57 WARNING: request rejected because http work queue depth exceeded, it can be increased with the -rpcworkqueue= setting
2018-06-21 08:34:18 WARNING: request rejected because http work queue depth exceeded, it can be increased with the -rpcworkqueue= setting
2018-06-21 08:34:24 WARNING: request rejected because http work queue depth exceeded, it can be increased with the -rpcworkqueue= setting

I wonder what the default rpcworkqueue is. And I did't find -rpcworkqueue command when I am using -h in bitcoind.
Following is my bitcoin.conf.By the way ,I didn't put block chain data in default place,but I assigned the position of block chain data and bitoin.conf when start bitcoin core.Following is content of bitcoin.conf.
txindex=1
server=1
rpcuser=username
rpcpassword=password
rpcbind=0.0.0.0
rpcport=8545
rpcallowip=0.0.0.0/32

Finnaly ,if adding "false" is useless,import one address about to spent one hour,and I need to import 20,000 adress that may cost 2.2 years.That impossible for me to wait so long.

The arguments for importaddress are:
Arguments:
1. "script"           (string, required) The hex-encoded script (or address)
2. "label"            (string, optional, default="") An optional label
3. rescan               (boolean, optional, default=true) Rescan the wallet for transactions
4. p2sh                 (boolean, optional, default=false) Add the P2SH version of the script as well
So, you need to use ./bitcoin-cli importaddress mvcWTfVhCMhwvqQf2TKkEqpLrNdW7Uekod "" false
Also, you may consider adding a final true argument after the false.
Note that importing without rescan means your utxo's will not be found (using bad terminology, your addresses will have no balance).
Also, note that since you have so many addresses to import you may wish to consider using importmulti the usage of which is described via ./bitcoin-cli help importmulti

Thank you , it's exactly where the problem is .I'll try to use importmulti to import 20,000 addresses.

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


text:
If the prices of virtual currencies on multiple platforms are different, can you buy low and sell high to make a profit?
I have observed that the prices will be different, can I earn the difference?

Does this answer your question? Why don't people buy at one exchange and sell at another? or  Is anyone taking advantage of different prices across exchanges?

This is called arbitrage.  It is theoretically possible to make money this way.  Whether it is practically possible is another question.
There was a feature of the market known as the 'Kimchi Premium', where it looked like this should have been possible with South Korean markets.  However the capital controls and other regulations made this difficult or impossible to exploit.  It is possible you are missing some forex complexity.

Yes, I should think about it. In terms of withdrawal fees, blockchain fees, and time lag, it is feasible for profit> fees


text:
How can blockchain prevent bad transaction script
Novice here trying to understand blockchain and transactions.
I was reading about the scripts to verify the ownership of UTXO and understand that, this script actually can be client-defined. What if a bad client decided to add a script that never lets the owner to  claim the UTXO? Something which just would always return false (OP_RETURN, maybe?)
My questions are:

Are these scripts agreed upon by all the clients? i.e There is a known catalogue of scripts that will be supported?

If #1 is true, then this seems to be more for future proofing or for independent networks trying to solve a custom problem.

Are above statements true?
Thanks in advance.

Are these scripts agreed upon by all the clients? i.e There is a known catalogue of scripts that will be supported?

An individual (wallet or script constructor) defines the script that the funds are sent to or locked up by. This individual can decide unilaterally what that script is with two constraints: they use opcodes or script building blocks that are recognized by the rest of the network (consensus rules, you can't redefine these on the fly) and if they want the recipient's wallet to recognize it as an incoming transaction the recipient needs to be able to spend from it. For example, a merchant is not going to hand over a good or service unless the funds have been sent to a script that they can spend from.

If #1 is true, then this seems to be more for future proofing or for independent networks trying to solve a custom problem.

It is certainly true that some sidechains and altcoins have different consensus rules to Bitcoin. If you need access to a different set of consensus rules to Bitcoin's these may present a solution. Bitcoin's consensus rules (e.g. script building blocks) can only change with a network soft fork (or hard fork) that generally happen infrequently.

Understood. My takeaway here:
"if they want the recipient's wallet to recognize it as an incoming transaction the recipient needs to be able to spend from it "  --> There will be validations happening on the script as part of consensus.
Will that be right thing to say?

No the recipient's wallet software will determine whether they can spend from the script (that the funds were sent to) and hence whether to increase their effective wallet balance by that amount. Then when the recipient comes to spend those funds the network consensus rules will determine whether the recipient successfully unlocked those funds to spend them. The recipient's wallet cares whether a specific recipient has control over funds, the network consensus rules don't care. The consensus rules just care that spending rules are followed.

What if a bad client decided to add a script that never lets the owner to claim the UTXO?

A UTXO script is defined by whoever previously owned the money. If they want to make the funds be unspendable, unreasonable, or implausible to recover, so be it. There's no reason or method for preventing that from happening.

Are these scripts agreed upon by all the clients?

No.

There is a known catalogue of scripts that will be supported?

No.

Assume if A is sending 1 BTC to B. Now, if A is adding a script that makes that 1 BTC unspendable  by B (If the the script always return false, B might never be able to claim that UTXO, but the transaction might still be confirmed.) Wouldn't that be like B receiving nothing ?
Am I missing something here?

You have the flow around the wrong way. B produces the script, A has nothing to do with the process other than paying to that script. If B decides to add other restrictions to the script, they have no longer paid A at all.


text:
Sharing ownership of coins via Multi-Signature transactions
I wonder if it would be possible to use a script to share ownership of an UTXO between 2 or more people.

1 <A pubkey 1> <B pubkey 2> N OP_CHECKMULTISIG

That would let every owner be able to spend these coins without needing to ask the other ones for permission.
This is at the moment a valid standard script that is accepted when it is being sent to the Bitcoin network.
But i am asking myself if this could be used to trick people?
If i pay with such a transaction with the receivers public key and my one in the script, i would still be able to spend these coins afterwards. And the receiver would not even notice that i am able to steal back my paid coins. Is this a realistic scenario?

Generally wallets don't recognize payments to random outputs, even if they're able to spend from them. In situations where multi-signature outputs are used, they're generally part of a scheme that the wallet knows about and participates in (for example 2-of-3 multisignatures where one of the keys is in your phone, one in a vault, and one is held by the wallet provider; usually the provider signs transactions you ask them to, but you can also spend with just the vault key).
This avoids the situation you're describing.

in your 1-of-2 example, you would have four steps to be followed:
1.) creation of redeem script
2.) share of redeem script
3.) create a funding transaction with the condition in the redeem script
4.) create a spending transaction with one of the two public keys

at the point where you share the redeem script (2), you would already know (and even see), that there are two keys involved. So wether it is you or your transaction partner, both have the information to see, that there are two possible spending ways: creating a tx with pubkey1 or creating a tx with pubkey2. Not sure how you could trick people with this...


text:
The status of the transaction
I send 0.00528479 BTC to the address 1HkqAUTgCgnnMP1CconWudxWAT3fMVpLtw with network fee of 0.0001 BTC. i checked the status and i dont know whether confirmed or not. one shows in green colour and one shows in red Color. kindly help me.

The bitcoins were received by the address and then spent, leaving the address with no balance. It appears both transactions are confirmed.

what need to be done to get it back?

Was the payment made in error? If so, you'll need to ask the recipient for a refund.


text:
worker showing offline in nanopool my rig shows it is hashing. Need help please!
I am using nanopool and it did work after initial start up. I rebooted the rig and now my worker is offline. I am hashing and connected ot pool1 us-pool pool2 eu-pool.
Has anyone else had this problem?
Please help and thank you in advance for any assistenace.

Same here. Glad to hear I'm not alone but still curious what is going on. Are you using SMOS or Windows for mining? I have a rig on Windows and rig on SMOS and both show offline but are hashing fine.
I do have a rig that has been running for weeks just fine and today it shows it has rebooted 5 times. I wonder if nanopool is having issues or something.

Same problem here. After running nicely for days (ubuntu) now my worker it show as offline on nanopool. However n. of shares found is increasing (hashing as normal) but last share submitted it shows as hours ago. Could be that there is problem with the pool or possibly anything else?

ive had the same problem for the past 5 hours. was worried it ws only me but i suppose others are having the same problem. could be a nanopool back end issue.
hope they resolve it soon for us. nanopool has been acting up a bit in recent time and i hope its not something permanent with them as theyve been quite good.


text:
Classic - I´m a newbe in Bitcoin and Bitcoin core offered me a fee and I accepted it. It was very low (see details)
The transaction has not been confirmed for over 14 days. Is it normal? Am I going to see my BTC ever again? :( Thank you all very much for any help!
Details:
Stav: 0/nepotvrzeno, v transakčním zásobníku
Datum: 21.12.2017 16:38
Pro: 18hSgrZD5CpPftpjPZMhWy9K7hFmmCZUop
Výdaj: -0.03419607 BTC
Transakční poplatek: -0.00000340 BTC
Čistá částka: -0.03419947 BTC
ID transakce: 3857e01084275a0259efee900b30ecd985a81b7e8a30ed53a5853ff9a73d670e
Celková velikost transakce: 339 bytes
Pořadí výstupu: 0

Really, Bitcoin core offered you a fee? How did you get that?

Please don´t solve your miserable life on me. I will not reply on this scrap. Please don´t write me Nicolas Barbulesco thx.

Thx Matthew, yes, I´m studying the thread. I just wondered if 14 days are normal and I can either expect return of BTC to my wallet or whether it will pass through one day. Should I try double spend?


text:
Historical Crypto Data
I'm looking for for historical data on crypto currencies that tracks down to at least the hour if not 5 minutes for each day for at least the past year. I need OHLV price, and volume at a minimum for each interval, but further trade data would be a great plus. I would prefer to get this from an API if one is available, but at least some csv's would help to start with, all the historical sources i see only track on a once per day basis.

maybe dublicate: https://stackoverflow.com/questions/16143266

Free version to the previously proposed paid version:

Actually, you CAN get the whole Bitcoin trades history from Bitcoincharts in CSV format here : http://api.bitcoincharts.com/v1/csv/
it is updated twice a day for active exchanges, and there is a few dead exchanges, too.
EDIT: Since there are no column headers in the CSVs, here's what they are : column 1) the trade's timestamp, column 2) the price, column 3) the volume of the trade

Please search first.

ClueDex Offers the online data you need. For OHLCV data, all markets are returned in a single query. You can specify the number of periods you wish, as well as the period interval. Additionally, you can create your own period interval, such as 25-seconds, 47-seconds, or whatever, in addition to the standard period intervals, 1M, 5M, 30M, etc. Cluedex doesn't cache the data either, and they don't impose a delay; you get the data as they receive it. It is a premium service, however.

I would recommend historicalcryptodata.com. Used it before, their pricing is quite cheap and good.


text:
Can I receive bitcoin to a cold storage device without an exchange being involved?
Do I have to use for example "coinbase" or another exchange to receive bitcoin to a "Ledger" device?

Answer to the title question

Can I receive bitcoin to a cold storage device without an exchange being involved?

Yes, you can.

Do I have to use for example "coinbase" or another exchange to receive bitcoin to a "Ledger" device?

No, there is no requirement of using any centralized exchange. If you want to acquire bitcoin you can do it in P2P fashion. You can buy it on P2P exchange (bisq, hodlhodl) or at your local bitcoin community meetings. Or you can ask friend who already have bitcoin to either gift you some or sell it to you. Or you can earn it. So no, you don't have to use exchange, but it's the most frictionless option for most people, due to KYC process that you have to go through, stamping your identity on the coins you want to acquire.
It doesn't matter if the address is in cold storage or "hot" storage to be able to receive bitcoin into it. Addresses don't have to be "hosted" to be able to receive bitcoin.

SO BASICALY you centralize everything into your cold wallet and from there you can withdraw to other cold wallets exchanges etc... right?


text:
Did Satoshi Nakamoto (in his blogs or the whitepaper) forecast that mining pools would exist?
Mining pools are common today where users pool their resources together and share profits accordingly. Such pools today can account for significant proportions of a network's hash power and they're are risks shold a coalition of malicious parties form a pool with 51% of the mining power.
My question is, did Satoshi ever forsee this coming or consider it as a possibility that may arise? Did Satoshi ever provide any thought about the positive/negative implications of the existence of mining pools?

Nakamoto did discuss the idea when others brought up the notion of cooperative mining, but I don't know if he wrote about it before anyone else came up with the idea.
You can search an archive of Nakamoto's communications
https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/250/?view=satoshi

ribuck's description is spot on.
Pool operators can modify their getwork to take one additional parameter, the address to send your share to.
The easy way for the pool operator would be to wait until the next block is found and divy it up proportionally as:
user's near-hits/total near-hits from everyone


text:
Are there any academic papers on the link between energy markets and Bitcoin mining?
I am keen to see if there have been any academic papers that have studied the link between bitcoin miners and energy markets, in-particular, if there is a so called 'no-arbitrage' requirement, or a hedging strategy for miners, that exists.
Suppose there is a miner, Bob, who's mining equipment produces a fixed hashrate and is not a part of any mining pool. The decision, whether Bob should mine or not, depends on the following variables (some are random):

The spot price of electricity (Random)
The spot price of Bitcoin (Random)
The network difficulty (Random)
The network hashrate (Random)
Block reward (Deterministic)
Equipment depreciation (Deterministic)
Transaction fees (Random)

Bob wishes to ensure that in expectation, mining yields a profit. Of course this depends on these aforementioned variables. Bob also wishes to ensure that if mining isn't profitable with the spot prices, perhaps there is a way he could still mine, by using energy market or cryptocurrency derivatives to hedge against this.
Or, if it would not be profitable to mine, he could lease his computation as cloud services for a fixed, deterministic rate per given time period, to ensure his machinery isn't idle. Conversely, he could choose to mine an entirely different cryptocurrency that would yield a profit, of course, in expectation.
My immediate, non-academic "hunch" tells me that there is a link here, or a way to ensure that miners have more certainty when mining, using derivative products to hedge themselves against sudden drops in the price of Bitcoin, or sudden increases in the cost of electricity. And the dynamics would be interesting to study.
I was wondering if there have been any academic papers published, which might deviate from what I have mentioned above, but include some relevant concepts. I have seen other answers on this site that have explored similar questions, seen here. As well as an academic paper on the sustainability of bitcoin mining, seen here.

Do please let me know if you feel this question would be better suited on Quant.SE instead.


text:
How do I convert a private key in hex to a Segwit private key expected by Electrum?
I've been following this code to generate SegWit addresses with python. However, I'm confused because this script doesn't output the private key in a usable way for Electrum.
I found this site which told me how to convert the key to a compressed WIF.
Here's one example, I ran the script and got this output:
Private key: ce534f3d1f481f8736c30d866a6b2c5defe5edc36afaafc0e923586791a2462b
Verifiction key: e5ee63efe153ebf1ec537831f2fba227f4b5f80275e750a9d0a8284c9fb4f91fb5427e034ffec25bacc346263f0f6281f951926f924f7c53f771f632ca9e3cbb
Compressed public key: 03e5ee63efe153ebf1ec537831f2fba227f4b5f80275e750a9d0a8284c9fb4f91f
keyhash: 17f022e2c24238760a0a1b070eaa456df4e8b915
Native address: bc1qzlcz9ckzggu8vzs2rvrsa2j9dh6w3wg4atezy6
P2WPKH_V0: 001417f022e2c24238760a0a1b070eaa456df4e8b915
Hashed P2WPKH_VO: b9502db522524782980563a09355fa7052ee7ff1
P2SH_P2WPKH_V0: a9b9502db522524782980563a09355fa7052ee7ff187
Checksum: 7fcb7c1d
Binary address: 05b9502db522524782980563a09355fa7052ee7ff17fcb7c1d
Nested address: 3JarywCp1dbFiykdGNWyo5pdZyvSLEGZ96

I then added my own additional code to convert to WIF.
WIF: 5KP9tSHuzYd1WTCTwr5ewace9eNM8Kv8xjsWYyELHdEkKcQkiUZ
Compressed WIF: L48nE2detzZwEzdbw5dYTuNJy9wDqLVY92DwS7Br8NwgD6S8NiyT

I imported the compressed WIF key into Electrum, but I get 13BaDNdBXkfrGkvJT41HNosBBbbLZRWyZJ as a public key. Everything online confirms that only legacy addresses begin with a '1', but surely it is a SegWit address, no?.
When I view 'details', Electrum gives me the correct compressed public key (03e5ee63efe153ebf1ec537831f2fba227f4b5f80275e750a9d0a8284c9fb4f91f).
Why doesn't Electrum give me a bech32 address or a nested address? Have I done the correct conversion of the private key?
Here's my code just in case there's an obvious mistake somehow.
fullkey = '80' + (private_key.hex())
sha256a = hashlib.sha256(binascii.unhexlify(fullkey)).hexdigest()
sha256b = hashlib.sha256(binascii.unhexlify(sha256a)).hexdigest()
WIF = base58.b58encode(binascii.unhexlify(fullkey+sha256b[:8]))

compressedPubKey = private_key.hex()+'01'
compressed_fullkey = '80' + (compressedPubKey)
compressed_sha256a = hashlib.sha256(binascii.unhexlify(compressed_fullkey)).hexdigest()
compressed_sha256b = hashlib.sha256(binascii.unhexlify(compressed_sha256a)).hexdigest()
compressed_WIF = base58.b58encode(binascii.unhexlify(compressed_fullkey+compressed_sha256b[:8]))

I don't know anything about Electrum, but the 1... address is a P2PKH address, not P2WPKH or P2SH-P2WPKH. And there isn't any conversion to perform on the key; keys are keys, but they can be used to construct multiple types of addresses. Presumably you need some other way of informing Electrum that you want a P2WSH address instead of a P2PKH one.


text:
I have been robbed after dust attack
Dear colleagues of the crypto community!
I am Roman Frolov (Vader), a private investor and trader, was subjected to a new version of a micropayment attack (dust attack) and was robbed of about 335.84997800 bitcoins in a cold wallet via supposedly Bitcoin Core access.
Stored bitcoins in a wallet generated in Bitcoin Kore (Knot). Earlier in the year 2015 I added private keys from BitcoinHD to Knotts and then to Core. I stored the listing of keys in a document archived in 7zip with maximum security settings and a long password.
Source of funds: buying bitcoin since 2012, participating in cryptocurrency HYIP projects according to the rules, trading on exchanges, including leveraging on bullran in BTC-E in 2017, got under the closure of the exchange and after a while received 80%, to this day I trade on Bittrex Global and Kraken. Followed the law, ethics and property rights. Didn't steal a penny.
2021-01-06 18:39:38 hackers produced multithreaded output from 12 addresses:
15hT9GMi1ThhmJts24WKG1Jm3so7bmiuW4
16BjABjMQB8wshTVhTbQUqoPfKQi7sSNRM
15D9TctYq3DvK1eDmxWfp8FWP73a1a2hEA
1Gi7qn77XqtGknJ9dUc3yRAoRFgNXBQBiW
1EAN8MxjfmRToVwsoVtfSzRz2FsCN89unX
13P1YEZjPDTpCtaqMbTbhu6VB3csu3qsZu
19DrKeLdYd47wHvbhkvccYQ4fQNycfdzhL
15hT9GMi1ThhmJts24WKG1Jm3so7bmiuW4
16BjABjMQB8wshTVhTbQUqoPfKQi7sSNRM
15D9TctYq3DvK1eDmxWfp8FWP73a1a2hEA
1Gi7qn77XqtGknJ9dUc3yRAoRFgNXBQBiW
1EAN8MxjfmRToVwsoVtfSzRz2FsCN89unX
13P1YEZjPDTpCtaqMbTbhu6VB3csu3qsZu
19DrKeLdYd47wHvbhkvccYQ4fQNycfdzhL
1JLTq3VLiU4qY1DfC7fYs4N5g45HByjE8H
1CfEuYincqgWfMGvBx8o1ysArCSMQhqM4f
12hBEaVfHGRXL4HnFjrAdoWudKhWdCPaoU
1PsKsr8hR7DBKB9q76JZwhTwD5W5QWG9Fj
19zvjxagjet8PNiCk4D7ZjWqqfoaM2qdZG
Output was made in 601 transactions starting with the output address:
bc1qxuyrx3n86nu0l5mf7wv8fzgkwn4vmeh5lqm2je 0.00291700 btc
and ending with 1B1ztXtrbnLWjMFGqSaW22DpdEWwiaoUbN 15.85027800 btc
the output went up evenly up to bc1qsx9q4cfpp33y4vxwhmr85n43zzv2qs85pr2jvw 0.97108300 BTC
and then 15.85 B1ztXtrbnLWjMFGqSaW22DpdEWwiaoUbN 15.85027800 btc
I ask everyone who is involved in currency exchange to pay attention to the withdrawal addresses from my addresses and their derivatives at 6 january 2021, and freeze their use and return to the original sender,
I hope for your justice, Roman Frolov (Vader)

I’m voting to close this question because it isn't actually a question - more an appeal for people to monitor certain addresses.

The transaction taking the coins is very strange, the criminals have obviously got a strategy which requires the multiple denominations of UTXO's. It's not clear what this is but regardless the TXID showing funds being stolen is: de991dda2cd10a31bea1dd92c5e5466f916b060f5bd31fe0840b9fd08a0aa786
If you follow one of the outputs you can see via the following transactions that it moves to an address: 169ksrn7RgXFZmUVtvBFfbEKG5mmMxvQU7
TXID 1: fa53e39eb02809ea03986484325141d7e97c8a9b8c793974841b6850be43cd70
TXID 2: 177b996bdf4c2986faed0830a064242e553a8d914b0d7771561d5a017e2eca3e
This address resides in a wallet clustered under the following reference in walletexplorer.com:
https://www.walletexplorer.com/wallet/00011cbc1c9321ec
When you review the activity of this wallet there is a lot of receipts and only one daily transaction out of the cluster to an address attributed to Binance (for the several days at least). No other exchange or entity is mentioned as an output. Given this my thoughts would be this is a hot wallet associated with Binance. As such if you have any contacts at Binance I would getting in touch with them.


text:
If anyone with your seed phrase can generate your wallet private keys, what is the advantage of a hardware wallet?
When you start using a cryptocurrency hardware wallet, you get to write down a seed phrase in some physical medium (paper, metal, etc.) so you can regain access to your funds if you lose the hardware wallet.
If anyone who gains access to this seed phrase can regenerate your private keys in another wallet and get access to your funds, why use a hardware wallet in the first place? Why not just keep the seed phrase well hidden, remove your data from any wallet app and use the seed phrase to regenerate your keys anytime you need to transfer funds? Is it only a matter of convenience and security when actually transferring the funds?

You may find https://metasafe.org useful if you ever lose your seed phrase

Well, in both cases, your seed words are ultimately the key to the wallet.
If you use a regular wallet, you open yourself up to a number of other attacks

Malware on the device that runs the software wallet
Keyloggers
People shoulder surfing
Backdoored wallet software

Moreover, larger OSes like Windows, Linux, and Mac OS have considerably larger attack vectors than a hardware wallet. Someone may gain access to your machine through some completely unrelated.
A hardware wallet not only minimizes the attack surface, it also makes use of secure elements (the good ones, anyways), which are specifically designed to prevent exfiltration of things like keys. Most computers do not have similar hardware.
Moreover, since the seed generation happens on the hardware wallet, the seed does not pass through a potentially compromised computer. Of course, one must trust that the hardware wallet is honest, which is why it is better to stick with reputable ones, such as Trezor and Ledger.

The idea would be to not keep any data in any wallet, just keep the seed phrase on a physical medium well hidden. That would reduce the time window for the attacks you mentioned to:

the moment the seed is generated until it is copied into the medium and deleted.
any time I use the seed to regenerate keys to access the funds and then delete all data again.

Your point about the seed being generated in a safer environment is valid, though. As the fact that in normal cases using the hardware wallet instead of regenerating the keys every time I want to access the funds would be much safer.

But it increases the opportunities for a others. If I know you do that, all I need is a usb keylogger between your keyboard and your computer, and patience. The more often you type the seed, the more chances I have.

In reality, there is no perfect solution. It's just that, currently, hardware wallets tend to have the fewest attack vectors, especially if you add a passphrase so your seed that you have memorised. Then, even with the seed, your wallet is inaccessible unless you give up the passphrase, which is also entered on device, and cannot be logged.

With a hardware wallet, the physical signing of transactions is often done within the hardware wallet itself, as opposed to through a trusted website.
The hardware wallet keys never leave the device as it acts as a simple black box that takes in a request from the browser (or website) and returns a signed transaction. A paper wallet is also extremely safe, except that there's a small risk when the user eventually enters the seed phrase or private key directly onto the computer.

Agreed. The thing is that these hardware wallets are marketed as "secure storage for your cryptocoins", which is a bit misleading. Their advantage over a paper wallet seems to be in the safety of the keys generation and transactions only. So they should be marketed as "secure transactions for your cryptocoins".


text:
What does this Pubkey mean?
I just started learning about Bitcoin, and am sorta familiar with p2pk and p2pkh. I just found this input on a Bitcoin blockchain explorer:

It looks like the Pkscript can be "solved" (I'm not super familiar with terminology) by something thats hash160 is the 0b49fe...
The ScriptSig looks a little more intimidating :)
What exactly is the ScriptSig doing? How does this sort of paying mechanism work?
Thanks

This is a P2SH script (pay to script hash), defined in BIP 16.
The scriptPubKey itself is very uninteresting: it takes an element from the scriptSig, hashes it with OP_HASH160, and then compares it with 0b49fe...f1. In other words, ostensibly the only thing needed in order to spend is knowing some piece of data whose hash is 0b49fe....f1.
Now, BIP 16 changed this. If a scriptPubKey has exactly the form OP_HASH160 + 20 byte hash + OP_EQUAL, then the special P2SH validation rules trigger:

All operations in the scriptSig must be pushes.
The final push in the scriptSig (the one whose hash we know is 0b49fe...f1) is taken to again be a Script (called the redeemScript).
That Script is executed, with as inputs all but the final push in the scriptSig.

So, semantically, the whole operation is equivalent to just using the redeemScript as scriptPubKey, but without needing to reveal this to the sender. Instead, the sender can just be given a short P2SH (3...) address that encodes the hash of the redeemScript, and the real one is only revealed at spending time.
In your example, the redeemScript appears to encode a 2-of-3 multisig policy: OP_2 <pubkey1> <pubkey2> <pubkey3> OP_3 OP_CHECKMULTISIG, and the additional stack items in the scriptSig are OP_0 (a workaround for a bug that OP_CHECKMULTISIG pops off one item too many from the stack) plus 2 signatures.


text:
Why are there fees for arbitrage trading and wallet transfers?
Deciding which exchange to buy BTC from (and sell at a future date) I wondered if I could choose one with the best fees for buying and a separate one with the best fees for selling and if this is even allowed.
It is as I read in other threads but there seemed to be a fee for this type of operation. I thought when you bought BTC from an exchange it would be exactly the same BTC (not a wrapper instrument) as if you bought it from any other exchange. How could there be extra fees if the exchanges themselves can't tell where the BTC in your wallet came from?
I also struggle to understand why there would be fees to transfer BTC from one wallet to another. A wallet AFAIK just stores private keys, anyone in possession of those keys (like yourself) could just register in another wallet and use that private key to transfer the BTC to your second wallet. I'm sure there's a hole in my reasoning somewhere.

Deciding which exchange to buy BTC from (and sell at a future date) I wondered if I could choose one with the best fees for buying and a separate one with the best fees for selling and if this is even allowed.

Sure, but you'll have to use the blockchain to transfer the bitcoin from one exchange to the other.

It is as I read in other threads but there seemed to be a fee for this type of operation. I thought when you bought BTC from an exchange it would be exactly the same BTC (not a wrapper instrument) as if you bought it from any other exchange. How could there be extra fees if the exchanges themselves can't tell where the BTC in your wallet came from?

There's a fee for executing a transaction on the blockchain. Exchanges typically impose this as a "withdrawal" fee. They don't care where you're withdrawing from or where your deposits come from. But those transactions do have a fee associated with them.

I also struggle to understand why there would be fees to transfer BTC from one wallet to another. A wallet AFAIK just stores private keys, anyone in possession of those keys (like yourself) could just register in another wallet and use that private key to transfer the BTC to your second wallet. I'm sure there's a hole in my reasoning somewhere.

Right, so to transfer the bitcoin from one wallet to another wallet, the private key that authorizes their transfer has to be changed from one custodied by one wallet to one custodied by the other wallet. Only the blockchain can do that.
It is impossible for an exchange to assign separate private keys to every user to minimize fees. In fact, such a setup would maximize fees because every transfer of bitcoin balances between users on the same exchange would result in a blockchain transfer.
For example, say I deposit one bitcoin, then sell it to Alice who sells it to Bob who then sells it to Charlie. If the private key securing that bitcoin had to change each time, then each of these exchanges would require processing a transaction on the bitcoin blockchain. That would be much more expensive than executing blockchain transactions only on withdrawals.

"use the blockchain to transfer the bitcoin from one exchange to the other." - do you mean from one wallet to another? I thought BTCs were not stored in exchanges, but rather in BTC's network addresses (commonly managed by wallets). As per the second part, I understand making a BTC transfer directly on the network will incur a network fee 'for the inconvenience', but you seem to imply that fee is higher than the one an exchange would charge for doing the same operation (because they would do it above the BTC net level) - is my understanding right? Thanks so much for the answers

@eduardo If I have $10,000 in a bank account, the bank presumably also has $10,000 somewhere somehow so that it's possible for me to withdraw. But there doesn't need to be any connection between these two things anywhere but on the books of the bank. And the more tightly the bank tries to tie them together, the less efficient the bank will be. Exchanges perform transfers between accounts at the exchange solely on their own books so these transfers are cheap and rapid. A single trade might change dozens of people's bitcoin balances and trades might happen many times in a second.

Thanks for the patient answers

Deciding which exchange to buy BTC from (and sell at a future date) I wondered if I could choose one with the best fees for buying and a separate one with the best fees for selling and if this is even allowed.

There are countries where transacting Bitcoin is illegal. There are other countries where people are free to transact with any person they wish, with or without intermediaries, globally.
The precise answer to this question thus depends on space and time, as corps iuris - jurisdiction - changes through frontiers, over time, and the territory a particular jurisdiction is overseeing sometimes also changes.

It is as I read in other threads but there seemed to be a fee for this type of operation. I thought when you bought BTC from an exchange it would be exactly the same BTC (not a wrapper instrument) as if you bought it from any other exchange. How could there be extra fees if the exchanges themselves can't tell where the BTC in your wallet came from?

On some free trade systems it might be legal for them to apply on you whatever fees they want to charge.
On some systems it might be even legal for them to gather and share intel on you so as to know what's your economic history.

I also struggle to understand why there would be fees to transfer BTC from one wallet to another. A wallet AFAIK just stores private keys, anyone in possession of those keys (like yourself) could just register in another wallet

That's correct.

and use that private key to transfer the BTC to your second wallet. I'm sure there's a hole in my reasoning somewhere.

That's mostly correct. They funds get transferred to that wallet. But they don't get transacted, in case anyone could be thinking they get.


text:
How can I collate blocks in blk*.dat files and rev*.dat files?
According to this answer, blocks in blk*.dat files and rev*.dat files don't necessarily appear in the same order, nor are either files necessarily in monotonic order, and blocks not part of the active chain may or may not have undo data available. The only guarantee is that the undo data (if available) for a block in a blk*.dat file will be stored in its matching rev*.dat file.
Given these limitations, how can one reliably collate the block entries in a blk*.dat, rev*.dat pair?


text:
What is the compact_size function used in BIP341?
BIP341 uses a function named compact_size in two instances: when constructing the tapleaf hash, it takes as input the size of the spending script, and when constructing the signature message, if the annex is present, it takes as input the size of the annex.
However, unlike other functions in the document which are mostly defined in BIP340, I can't find the definition for this one in either of them, so what is it?

It refers to the CompactSize encoding frequently used in the Bitcoin P2P protocol for integers (in particular, lengths of vectors). It's also called VarInt in some other protocol descriptions. Since it predates the BIP process (was part of the original 2009 Bitcoin protocol), it is not described in any BIP.
It encodes integers between 0 and 252 as a single byte, though bigger integers as 3, 5, or 9 bytes.
It is not in BIP340 because it has nothing to do with the digital signature scheme.


text:
How difficulty variation is technically linked to time take for the block discovery?
Can anybody explain to me technically in units about the time relation to difficulty variation in bitcoin mining e.g. if a block is discovered in 10 minutes, does
T = 10 minutes?
or T = 20160 minutes
and then as
Difficulty is inversely proportional to the time taken.
How it can be formulated to proper time and difficulty relation evaluation.

The purpose of difficulty variation is to maintain a consistent block time.
Let's say you have a network, and you want a 10 minute block time. You are the only miner. The process of mining can be thought of as rolling a die. For simplicity, let us assume it takes you five minutes to roll a dice once.
Now, we need to set our difficulty such that you find a valid solution roughly every ten minutes. In ten minutes, you will be able to roll the die twice (since it takes 5 minutes to roll once). Thus, we need half the rolls to give a valid result, and set our difficulty to <=3 (since you have a 1/2 chance of getting a number less than or equal to 3 on any roll).
If you do this 2016 times, you will, on average, find a block every 10 minutes.
Now, let's say a friend joins you, and can also roll a die once every 5 minutes. Now, suddenly, we are trying 4 solutions per ten minutes instead of 2. This would result in a block being found every 5 minutes, on average.
After 2016 blocks, Bitcoin nodes will look at the average time taken to find a block over the last 2016 blocks. Once they see that this is 5 minutes instead of 10, they will increase the difficulty by lowering the target. In our case, with two people mining, this would make the difficulty 1.5 instead of 3.
Now, with die, you cannot actually have that much control. There are only six possibilities, which makes your difficulty jump more than you need.
With bitcoin, the blockhash is essentially a 256 bit number, and can store 2^256 values. This allows for fairly precise difficulty adjustments.

Can I have some mathematical calculations for this?


text:
Smaller transactions are easier to validate; larger transactions take more work in Bitcoin
I am working on Bitcoin and trying to understand how transaction fee is calculated. Bitcoin support site states that the reason for selection of small and large transaction by miner:

Again due to the fact that a block on the bitcoin blockchain can
  contain no more than 1 MB of information, transaction size is an
  important consideration for miners. Smaller transactions are easier to
  validate; larger transactions take more work, and take up more space
  in the block. For this reason, miners prefer to include smaller
  transactions. A larger transaction will require a larger fee to be
  included in the next block.

https://support.blockchain.com/hc/en-us/articles/360000939883-Explaining-bitcoin-transaction-fees
I have below questions on it:

Does the size difference matter only in case of validation or even while mining or PoW.
What is the mathematical reasoning for difference.

Smaller transactions are easier to validate; larger transactions take
  more work, and take up more space in the block. For this reason,
  miners prefer to include smaller transactions.

This is not necessarily true. Miners do not validate transactions, nodes do. Miners generally are only aware of the current block template they are trying to mine. That's why it's important for a miner to connect to a node they trust, in order to get the block template. Miners will get block templates that prioritize transactions with the highest fee/kB. This maximizes the tx fees for the miner for mining the the block.
While it is true that larger transactions are harder to validate, a larger transaction is not harder for the miner to validate because it does not do validation. See Node Operation under Bitcoin Mining. It is also not harder for the miner to hash because it is only hashing the merkle root of all the transactions (along with the other header data) selected for the block. See Block Hashing Algorithm. The merkle root is the same size regardless of how many transactions it represents.
Users must compete for the higher fee/kB if they want a better chance that their tx will be included in the next block.
Edit: As an aside, extremely large transactions with lots of inputs can cost the network almost as much to process as they cost the sender in fees, because computing signature hashes is O(ninputs*txsize). For this reason, nodes limit transactions to MAX_STANDARD_TX_WEIGHT to mitigate CPU exhaustion attacks.

Thanks for the help. What you are telling is correct. Right now I am looking into difference between small and large size transaction which is important for miner.
"Smaller transactions are easier to validate; larger transactions take more work, and take up more space in the block. For this reason, miners prefer to include smaller transactions. A larger transaction will require a larger fee to be included in the next block."
Can you comment on this part.

Just added another paragraph addressing that specifically


text:
Can I run a full bitcoin node on a Raspberry Pi?
If so, what would be the best way to get started?

That's about 4 years old.. But I'll look into it.

Yes. I have one with an external usb hard drive if you want to store full blockchain or without it if you run a pruned node.

Thanks could you point me in the direction to where I can get started?

If you want full Bitcoin node and Lightning you have a script here: https://github.com/jochemin/raspnode


text:
Bitcoind Cannot assign requested address
I'm trying to run a regtest bitcoind node but I'm always receiving the following error

connect() to [2a05:d01c:a35:2902:6e18:7290:ff27:e9aa]:18444 failed:
  Cannot assign requested address (99)

My config:
bitcoind -printtoconsole -regtest=1 -rpcallowip=::/0 -rpcauth="...."

I'm running the node with through docker with the following image https://hub.docker.com/r/ruimarinho/bitcoin-core/
Thanks by advance for your answer.

First of all check that your system support IpV6.
Run this:
test -f /proc/net/if_inet6 && echo "IPv6 supported" || echo "IPv6 not supported"

Then make sure to bind to ::ffff:0.0.0.0


text:
How can I import wallet.dat file to Bitcoin ABC wallet without downloading whole blockchain?
I keep my BTC in Bitcoin Core wallet. I would like to start using my BCC but full node is downloading whole blockchain. How can I avoid it?

If you want to support BCC without downloading blockchain, there are two options.
1) Bitcoin ABC + pruning
Pruning allows your Bitcoin-Qt/BU/ABC to work as a node without downloading the entire blockchain.
See this on how to prune: Can Bitcoin-Qt be configured to trim the blockchain?
2) Electron Cash
Electron Cash is the changed version of Electrum SPV client with BCC support. As it's a SPV client, ----it won't download the entire blockchain-----, as change suggested by @Pieter Wuille, SPV clients do download the blockchain, they just don't store entire blocks, they keep only the required parts.

Pruning does not mean you don't download the chain; only that you don't store it after validation.

If you don't need a BCC full node, you can use an SPV wallet like Electrum (see instructions on BCC here).


text:
Isn't an encrypted wallet.dat automatically a "watch-only" wallet?
I have encrypted my wallet.dat outside of this computer. Now I store my wallet.dat on this computer.
If I open it in Bitcoin Core, I can view the balance but not spend it (without entering the decryption passphrase).
Doesn't this make an encrypted wallet.dat a "watch-only" wallet? Can't I simply safely keep this on my PC and use the RPC API to check on the balance to make sure that it still contains my coins?
Basically: What is the difference between an encrypted wallet and a "watch-only" wallet? Why would I make a "watch-only" wallet when the encrypted wallet apparently has the same functionality, and is as secure?

An encrypted wallet may be cracked if its password is weak with enough budget and computing power, while a watch-only wallet doesn't give any information other than the address and what can be derived from the address.


text:
Do you have to keep broadcasting transactions until mined?
From what I know, you can broadcast a transaction including input addresses, output addresses, and amounts, which is signed by your private key.
I often hear that your transaction might not be mined in the next block, since there is a limited capacity, and you can incentivize miners to prioritize your transaction by paying a higher mining fee.
But this doesn't make sense to me... I assumed that transactions must be mined in the next block, since your transaction also includes the hash of the previous block in order to prevent double-spending. Is this assumption correct?
Does this mean, for every block in which your transaction is not included, you need to continuously broadcast a new transaction with the hash of the new current block?
Or, is there a mechanism for just broadcasting a single transaction that can be mined in any future block, but cannot be mined more than once so that you don't accidentally spend extra? If so, how would this work?
I was thinking, because transactions must consume all bitcoin in an address (and you can send some back to yourself if you want), that a miner can not mine the same transaction twice because your address would now be empty in the new state of the blockchain. Is this the case?
Thanks for trying to clarify this for me :)

But this doesn't make sense to me... I assumed that transactions must
be mined in the next block, since your transaction also includes the
hash of the previous block in order to prevent double-spending. Is
this assumption correct?

This is not correct, the transaction does not reference blocks, it references outputs. A block references the previous block.
To answer your question, no, you only have to broadcast your transaction once. In some cases that the mempool is too large, nodes might start deleting transactions from their mempool starting with the ones with the lower fees. In that case if your set fee is too low you might want to rebroadcast it.
Miners of course cannot mine the same transaction twice because as you said a transaction spends the input coins and therefore you cannot spend them again.


text:
Broadcasting fake Lightning channels
As I understand it, right now every public Lightning Network channel must be tied to a UTXO. This is required in order to prevent nodes from spamming the gossip network with nonexistent channels, but it's not great for privacy. It seems to me though that this anti-spam measure would still work if, for example, the protocol allowed nodes to announce one channel without public UTXO for every channel with. Additional restrictions might be necessary but you get the idea.
Apart from improving each node's privacy by default, this would also allow creating fake public channels for additional privacy. Some wallets today create fake private channels and pretend to route payments through them while actually being the final payment destination themselves, but this pattern seems easy to spot and could be made more believable with a fake public channel.
Is there a reason allowing this would be a bad idea?

I think you answered your own question in the first part: Gossip at no-cost on a broadcast network is a potential Denial-of-Service attack vector. Since there is nothing stopping Sybil from creating many nodes and false channels, she could easily overwhelm other nodes who receive and rebroadcast gossip.
Since gossip is rebroadcast without reward, the incentive to engage in gossip is so that your own node has a robust, up-to-date understanding of the current state of the network which will improve the probability of your payments succeeding, and provide you with more routing options which may reduce costs.
But gossip must ultimately be limited in scale. It will not be possible for billions people around the world to globally broadcast channel states every 2 weeks because most people will not have the bandwidth or computers powerful enough to process gossip of this scale.
Having an up-front cost to channel creation - the requirement to broadcast a 2-of-2 transaction on the bitcoin mainnet, is an extremely useful way of mitigating the DoS vector, as any potential attacker must expend real bitcoin in transaction fees in order to create many channels.
There are other proposals to limit the scale of gossip by reducing the requirements each node must have, and offloading route-making decisions to others. These have trade-offs in privacy, reliability and censorship-resistance, and some may create a centralizing effect which could end up with a hierarchy of registrants in a system like DNS.
So if anything, the goal should be to continue to make efforts to reduce or constrain gossip requirements, and ensure that there is always a tangible cost to advertize a channel.
Communicating false channels should be done over an alternative gossip network which might have a different incentive mechanism in place to reduce the DoS vector - but I suspect attempts at this will lead to a centralized registration network like DNS.

This sound like an interesting idea. I fear it will be a bit complicated though. As gossip is peer to peer a node could announce verious fake open channels to its different peers. Nodes opon relying announcements would have to decide how many real channels already exist. This could split the network as some nkdesvbelieve the one fake channel and other nodes might believe another one. Also to create a fake channel my peer would also have to have available capacity to do so. Additionally how would we notify that the channels are closed? Currently we see this if funding TX is spent. Overall I'd say a lot of details would have to be worked out. I guess the best place to discuss such ideas is the mailinglist or the BOLTs repository on github.


text:
Alternative fee functions for the Lightning Network
The current Lightning Network specification allows channel peers to specify a base fee and a proportional fee. In other words, the fee charged is a linear function of the forwarded amount. While that sounds completely reasonable, my question is, have there been any other proposed fee functions, perhaps to more closely align with node operator incentives, or to make path calculations easier? (Feel free to include the "zero base fee" proposal for completeness.)

Notably, Rusty Russell mentions here that the current system was a compromise against more complicated ideas.

I'm not familiar with any proposals to add new variables to the fee function. There have been discussions on HODL invoices which would (if enabled on the Lightning Network) require additional fees proportional to the time the capital was going to be locked up for. I'm not sure what the latest status of HODL invoices is, their introduction would compete with (and potentially negatively impact) the current use case of instantaneous payments but some form of them seems to have been merged into LND.
Most of the discussion I am aware of has been about removing the base fee and just having the proportional fee as this would better facilitate some proposed path finding algorithms.


text:
BTC invalid transaction: double spending attempt?
I'm writing because I need some help in understanding the below hash data. Thank you.
https://www.blockchain.com/btc/tx/976e6d64a4c98cf15ac917b98a04333f896b7cd15c1f2fdfb18f6fee668b670c

Is it a double spending attempt?
What is the recipient address valid transaction was sent to (how to retrieve it from hash data)?
The real amount B received from A in the valid transaction (not considering the utxo - unspent transaction output).

Thank you :)

Its sender 12zVe8P1gzcJvHqMEozpzxVa2uqVPYtxVV is a weird bot.


text:
Detecting BTC transaction hash data: help
please I need some help in reading the hash data correctly.
Given below transaction of total value btc 1.55821903
https://www.blockchain.com/btc/tx/8bbae353ce95fb0a6cbff44b8dd1c3cdd7d6419e0c63ee73f59db7cc0c110dc1
Only btc 0.00621581 were effectively received by B (recipient)?
The amount come back to A (btc 1.55200322) was not sent to B at all?
Therefore, can A say "I paid B with btc amount 1.55821903" in any ways?
Many thanks to the community

can A say "I paid B with btc amount 1.55821903" in any ways?

No.
A used a 1.55824169 BTC "coin" but sent themselves change in the form of a 1.55200322 BTC "coin". B only ever received a 0.00621581 BTC "coin" and nothing else. B never had any control over the amount of change.
At no time did B have any control over the 1.55824169 BTC "coin".
At no time was there ever any  1.55821903 BTC "coin". That amount is just the sum of the two "coins" created in this transaction.
The difference between 1.55824169 BTC and 1.55821903 BTC is the fee amount that a miner will include in the coinbase "coin" that they create. The face value of the coinbase "coin" will be a larger amount because it typically includes other fees from other transactions in the same block and a mining reward for the block of transactions.


text:
Dog identifier in blockchain
I would like to print qr-code with transaction that contains my home address to print it for my dog's necklace. If dog will get lost everyone can scan it and get the address.
How can I prepare the transaction?

Why don't you just print the address as a QR-Code? What's the benefit of it being on the blockchain, when you want people to scan it from your dog's necklace?

Because I want my dog to be the bitcoin user ;)

Is this to put a reward for finding your dog in the case that is is lost? If so, you'd need to put a private key, not the public address. The public address is what you pay TO. What good does having an address on the blockchain associated with your dog do?

Guys, it is just example to show how to prepare the transaction with custom message :P

Your example doesn't work and only makes the question confusing. There are no custom messages in transactions.

@Jannes: http://wlangiewicz.com/blog/2014/10/24/how-to-put-custom-messages-into-bitcoin-blockchain-op-return/

@XaweryWiśniowiecki That's not something that you can put in a QR code. A transaction doesn't go into a QR code at all. I guess you could put an URL in the QR code that points to a blockchain explorer with a transaction ID. Still makes no sense though. Just make a website with your home address on it and make a QR code with the URL to that. Which still doesn't make sense. Why don't you create a vCard QR code? http://snapmyinfo.com/vcard/

Janina Lowisz of Bitnation's BlockchainID project became the first "World Citizen on the Blockchain" by making a sort of blockchain passport:

Something similar could be done for identifying pets.
For instructions on how she did it, see:
https://github.com/MrChrisJ/World-Citizenship


text:
How to query sender address from copay?
I have transaction ID and some other data in my disposal when I am on first screen on Copay wallet. I need to show in transaction details originating address for transfer to my wallet.
Is there some API endpoint I can hit in bitpay API ?

copay didn't provide this information for the transaction. It can be retrieved from other APIs.


text:
bitcoin transfer without creating wallet
My question is about transferring bitcoin between two addresses without having a wallet.
Here is my idea of transferring bitcoins in following way:
Idea:
I have my own Android Application. I am willing to send/receive bitcoin using blockcypher Apis
I will keep private and public keys generated from above apis in my own database by encrypting it.
Does it make sense?
This might be a stupid question to experts, but as a newbie in block-chain technology I am curious to know the right direction of the concept.

Essentially, it seems to me, what you are writing is what most would call "a wallet."   A wallet is a system that keeps and manages bitcoin addresses (public keys) with their corresponding private keys. A wallet also knows and displays the total number of unspent coins it holds .

Sure, this would work.
That said, you are essentially building your own wallet - A wallet is simply a program that hold private keys, keeps track of spendable inputs, and signs transactions.
Your system achieves all of the above, so you are essentially building your own wallet.


text:
Is it safe to store user's secure pass-code in database with encrypted form while creating bitcoin wallet?
I would like to create a Bitcoin Wallet.
Part of the process is to store public and private keys in encrypted form in server database.
All keys I am storing is encrypted using user's passcode.
1) Is it safe to store user's passcode in encrypted form in server database.
(Thinking that User might forget his passcode so considering one recovery option)
2) Is there any kind of future possibility that I get in trouble if any kind of attack happens or by action of some intruder/admin itself(worst possibility) - the key reveal to the attacker which will lead access and open up all the pub/priv keys from database of that specific User? This way I can not give forget pass-code option to user.
So considering both option Shall I store User's pass-code or not?
What is the best practice to implement this security feature in bitcoin wallet ?

Best practise is to only store a hash of a password, not the password itself. You should also include a random salt before hashing. You should be aware of which well-known hashing algorithms are no longer considered safe for this use.
Encrypting the password before storing it is not a good strategy because you end up with one encryption key, stored somewhere as plain-text, that can unlock all user's passwords. This is a gift to hackers.
You need to take care of how you hold the password in memory for use when encrypting and decrypting other data (keys etc). For example, you need to be sure other processes and plugins can't see into your processes' memory space and that before being released, any allocated memory is cleared. This should be automatic with most modern systems but it is your responsibility to be certain of this.
Yes, amateur attempting to write security code is probably a good way to destroy your business, destroy your reputation and put yourself in the way of civil or criminal proceedings for negligence.
To be honest this question might be better asked on somewhere like Security.stackexchange. There's nothing Bitcoin-specific about this.


text:
What if I change PubKeyHash in scriptPubKey of a transaction to my PubKeyHash?
Suppose a person A makes a transaction to person B and sends it to bitcoin network. Suppose I changed PubKeyHash in scriptPubKey of a transaction to my PubKeyHash and send it to bitcoin network. The transactions sent by me will be a valid transaction, right ??
Thanks.

When person A "Sends" their transaction, they must first sign it, and then broadcast it to the mempool. The signing ensures that the transaction is not valid if any of the signed portions are changed. Thus, if you change a scriptPubKey, the signature they added to the transaction will be rendered invalid, and when you attempt to broadcast your updated version of the transaction, it will be rejected by all nodes.
One possible exception is if person A uses SIGHASH_NONE. If this flag is set, the signature does not sign the scriptPubKeys of the outputs, and thus they are mutable without invalidating the signature. AFAIK, no one uses SIGHASH_NONE due to this insecurity.
More on Sighash flags: https://river.com/learn/terms/s/sighash-flag/

To ensure that the transaction is not tampered with, the owner will SIGN the transaction and then broadcast to the network. Changing any part of the transaction WILL change the transaction's signature and other nodes will DROP that corrupted transactions as message(transaction) has changed.
But still the possibility of tampering exists,
Because the transaction contains signatures themselves, a signature can't sign itself and hence signatures are not included in the transaction string during signing. So while a transaction is in the mempool(staging area waiting to be mined) and has been computed/assigned a TxnID(a hash of transaction), a node can slightly change your signature(in a way not making transaction invalid) and because the signature is now changed(in turn transaction string is modified)..a new hash will be created.
While the integrity of transaction remains well and bitcoins will be sent to intended receiver, the software/wallet waiting for confirmation of the previously known TxnID will still be waiting for confirmations.
Even this has been fixed with the introduction of SegWit to bitcoin network after the BIP-141.


text:
Bitcoin mining with cloud
Where is cloud mining ok? many companies dont let you use their cloud to mine bitcoin so how do you do cloud mining? And is cloud mining worth it and does cloud mining have more advantages than normal mining?

@Prayank I agree, though I don't think that's what OP is asking about (it sounds like literally using some compute cloud to run mining on, not companies offering "cloud mining" as a concept directly).

@Pieter Wuille yeah I was not talking about companies doing it.

@Prayank Absolutely, I upvoted it too, because it's useful for people looking for related information. I commented to avoid letting OP think it was an answer to their question.

Bitcoin is mined using chips specifically produced for the purpose of SHA256 mining (ASICs). Anything else is an pointless waste of electricity and hardware, and will cost you orders of magnitude more than the gains.
Using clouds does not change this. Even if companies allowed it, it would cost you more than what it earns you.
You need ASICs.


text:
how target walled address is secure to save received amount?
What about if I (as a hacker) change the amount from 5 to 1 for any transaction and put signature with my (as a hacker) Private Key and mine that block again. Yes, I lose  1 coin, At the same time isn't it an attack to target the public key (target walled address)? Because target walled address lost coin from 5 to 1.
How is bitcoin preventing this? Democracy?

If I understand the scenario you're describing, you are effectively constructing an independent, second transaction that also pays the receiver, but using your own funds rather than the original sender's, for a smaller amount.
The two transactions will not conflict, and both will go through. So not only will you have done nothing to prevent the original transaction, you'll have donated some of your own money to the recipient in addition to it.

what about change existing transactions? just alter the amount and sign with the hacker's key-pair? not possible? how a miner can recognize it invalid transaction ? my target is to decrease the amount of the receiver's wallet.

You can't just make every node in the network forget the old transaction. All you can do is broadcast transactions of your own. From the network's perspective, there is no distinction between "transaction A, but with key/amount changed" or "transaction B, which always had your key/amount in the first place". Transactions have no identity, apart from their hash, and when you change their behavior, the hash changes - and the result is that it'll be treated as an independent transaction from the original.

I Understood it. So, it is avoiding by democracy. Means, single hash of changed block will be rejected by others.

I don't understand what democracy has to do with it. You simply don't invalidate a transaction by broadcasting another one.

Let's put in this way:
Amount:20 from: Alice to: Bob
Signature: AliceSign.
hacker miner block and alter some transaction to:
Amount:5 from: Fariz to: Bob
Signature: FarizSign.
(Suppose cryptographic algos are matching for a signing.)
How to avoid this? Because altered transaction also is valid.
My question is in a cryptographic way how the receiver is a safe zone?
Because from your answer I understand single block can be altered, but other nodes will reject it. Because hash will not match with other nodes.
But I want to know how to avoid this in crytographc way.

As I told you: both the original and the modified transaction will go through. The original transaction does not conflict with the modified one, so the original one will still also be mined, possibly by some other miner in a later block. So what you describe you can't be prevented but it is also harmless: it's just the attacker creating an independent additional transaction from them to the recipient. The only effect is the attacker losing money, and the receiver getting a gift.

Also, the block cannot be altered in any way after creation without invalidating it, but the miner who creates it has full authority to choose whatever they want to include in it. So I'm assuming you're asking about a miner who chooses to not include the original transaction, but instead includes an alternative transaction paying the same person, but using their own (the miner's) funds instead. What will happen is that the next miner will likely include the original transaction instead.

Understand it. Now it is clear. So, end of the story, transaction content is just signing by senders private key, and not encrypting with receivers public key (to open by receiver's private key only). So, transaction can be read by everyone and avoiding from altering only is distribute transactions/blocks.


text:
How can I get coins from a personal pool?
I'm running a node and a private mining pool, does my miner have to solve the block for me to receive any coin?

Right now, by my math, you would need to have at least 1.2PH/s to average 1 found block per year. So, if you don't have the equivalent of 11 Antminer S19Pro machines, there's a VERY high chance that your miners will be obsolete before you ever complete a block & get paid!

I am part of some larger pools.  This is me just screwing around at a 512 difficulty trying to catch lightening in a bottle.  Thanks for your reply.

Yes, it does.
Pools help reduce the variance in payouts, but aggregated over all your miners, it needs to have enough hashrate to at least find a block occasionally.

I am part of some larger pools.  This is me just screwing around at a 512 difficulty trying to catch lightening in a bottle.  Thanks for your reply. :)


text:
Bitcoin-Qt client wallet.dat extract private key to import on another service
I have a file: wallet.dat where should be saved one or more private keys of my old wallet linked to one/more public btc addresses. I also had more than a wallet, so I don't really know if there are some created address with an amount of money in that file or not. Of course, I don't want to download 500 gbs of transactions since 2009 using Qt-Coin and my idea was to extract private keys in order to import them on another wallet like blockchain.com.
I managed to use some open source tool (wt_extract_keys.py https://github.com/akx/walletool) to extract private keys, one seemed to work but the format of private keys seems to be not compatible because blockchain.com requires a private key in a wif format and what I got is a very big private non-compressed key.
So how can I get the private key/s with the right format this if it's possible? What do you suggest?

I would use the dumpwallet approach using Core, then use a script to remove everything but the WIF private keys and import them to Electrum which can import a list of private keys

I have bitcoin-core installed, but I can't find dumpwallet executable. I'm working on windows

Once you run Core find the "console" menu item from which you can call dumpwallet

Ok I have found it, but I can't import the dumped wallet on electrum, maybe there are no valid addresses because if I try to type dumpprivkey it says: Invalid Bitcoin address (code -5). On electrum, I do: import btc addresses or private keys, then I select the file which contains a lot of strings (but I don't know if they represent valid addresses) and I cannot move forward after that: https://i.imgur.com/5JRM4qX.png

OK, that file contains private keys. Private keys are all words that start with K, L or 5. You need to copy paste those and only those, not comments, not anything else to Electrum. You may also skip the private keys that have reserve=1, those are unused. I'm going to write a script that takes the output and filters the private keys and I'll post them here in ~48 hours, so if there are too many addresses without reserve=1, please wait one to two days

I could have coded it by myself but if you have already done the work and want to share it I'll appreciate, thank you.

alternatively, you should be able to import only the "extended private masterkey" into your wallet software as an HD Wallet seed, and your wallet software should be able to re-derive the private keys from there & tell you which (if any) of the wallets still contain btc.

@Virgula Here is it: https://gist.github.com/DesWurstes/ce0e1727a53e4b1f6e808e2ef5801ece

@MCCCS Ok I have tried your script and keys have been imported on electrum. Unfortunately the address that I was looking for is not shown in electrum btc list, so I assume that is a wrong version of wallet.dat file. But can I know why if you create a new wallet it automatically creates not a single BTC address but a lot of them? I mean, shouldn't I have been able to create one whenever I need instead to have a list of already created addresses?

@Virgula Yes, lots of them. It could generate it when needed, however, that's just not how it chooses to work. reserve=1 addresses are unused, as expected. Core prefers to generate the default 50 next addresses whenever it can, and updates again when one of them is used.


text:
Please help out I send 109k to my client he was able to receive $50,000 please help
I send a bitcoin transaction of all coin my wallet which is $109,180 to my client wallet address giving to me. But he received $50,000 in is wallet address. And I sent all the coin my of 109180. Please what going on and the transaction output is show two wallet, I don’t understand the second wallet that showing I sent the remaining coin there?? Please advice

Possibly related: https://bitcoin.stackexchange.com/q/736/5406

When transacting Bitcoin, especially large amounts, you should verify the amount in Bitcoin terms. So if it was worth 2.25 Bitcoin at the time, verify that with him. That you agree on the amount in terms of bitcoin.
You can see the transaction hash or transaction ID in your wallet interface to see how much was sent and where it went to. You can also check his wallet address and see his balance.


text:
How do I get my small amount of BTC out of binance without getting charged 22%?
Using the withdraw options I’m being charged 22% of $95 to send BTC to a BTC address.
I didn’t know that binance had these kind of rules.
Binance pay can’t help me as it accepts payid, some kind of binance thing, or QR code, you can’t send to BTC addresses with that service.
So how do I get my coins out of there to a BTC address without being robbed?

Are you concerned about paying 5 mBTC or about pushing down the proportion that 5 mBTC is of what you get in the end?

I’m trying to find a way (if there is one) to withdraw my BTC without having to pay 22% on my $95… Never using binance again

Well, if you buy more, the withdrawal fee will still be 5 mBTC, but it will be a smaller percentage. If you don't want to pay 5 mBTC, you could potentially try to trade it for a different cryptocurrency with lower withdrawal fees (if they differ between currencies), e.g. Tether, move the Tether to a different platform to buy and withdraw BTC from there. Not sure if you'll be able to significantly reduce your overall cost.

Errr… I just noticed. $20 are 0.5 mBTC, not 5 mBTC. The withdrawal fee table that you showed in your earlier question seem to be off by a factor ten.

Are you saying the 0.002 value is off?


text:
Is password important in most installed wallets?
Usually in many wallet, ronin, xdefi, electrum, and metamask, we are given seed phrase and we got to set password
I set my password to be really simple.
The reason is because I think the seed phrase is what's really important.
Anyone that knows the seed phrase can just recreate the whole wallet set a new password and get my money.
So why do we even have to set password in most wallets?
Is it even important?
The only think I can think of is if I left my computer unattended and the screen saver doesn't work locking the screen. I can't think of any other reason why.

The password encrypts the wallet file itself, protecting all your secret keys in any situation that an attacker gains access to your files. This includes physical access, but also viruses/malware, recovery off an old hard drive you sold without properly wiping, and so on. It is also important if you store backups of the wallet file elsewhere (for example, an external backup drive - or even worse, the cloud), which could be potentially stolen and accessed.
Thus, compromise of your wallet file is certainly as severe as compromise of the seed words (and more likely, if you've stored your seed phrase securely on paper). So it's important to have a good password on it. A weak password on the wallet file would be similar to leaving your seed words in a text file on your desktop.

A weak password on the wallet file is like seed words on a text file? No a text file need can be read by hidden scripts. Anything encrypted even with simple password cannot.

A simple script could easily send the wallet file to the attacker who could crack the simple password very easily. Essentially, a weak password gives almost no protection.

Why enscrypt wallet file using password? Why not using the seed phrase then?

Because a password is more convenient and easier to remember for a human than a seed phrase is

As Meshcollider points out, the password file encrypts the local copy of the wallet (file), which includes the seed phrase.
In other words, an attacker needs either:

The seed phrase
The wallet file AND its password

So the password can be justified to be weaker than the seed phrase - because the attacker also needs access to the wallet file. The extent to which its security matters thus depends on how well you can secure access to the wallet or wallet file. Without specifics of one's setup, I would recommend a strong password regardless.


text:
Getbalance amount 0 aftering generating blocks with bitcoin-cli

After starting bitcoind bicoind -regtest -daemon then i load one of the wallets i created bitcoin-cli -regtest loadwallet "wallet-name". The wallet loads fine but no matter how many blocks i generate to whatever address my balance stays 0.

Regtest halving events are not the same as mainnet they occur much quicker, i had gotten all the block rewards already and deleted that wallet thinking i could mine more in a newly created wallet lol


text:
decoding transaction hash returned in rpc call getrawtransaction
hex: 010000000001026a8da33916366b884349772dc022a39c4cf8d60acc45fd2527a71e5c80cc6da2000000000000000000208a35c4425160d006ed968606485258a1ecca80550ea48def5d44511bab553200000000000000000002e847791400000000160014885f1f476949438e34d3928fcff3449c339f934dc8633b0300000000160014618736c1f42c5029a5887a5ebac292720a4ccd1802483045022100f3d721d184ad19e50ca085fedb0c2654b1c5bd3cedb4b5f1d502ca7f21df125402204d87cda1511ebc1d943b0ee223aa2ade62410c51028d04ffabb3dfd7c1120273012102826930ee848903793b57d2e253284dfa0df86de1103bace30b84ab619e663fb402463043021f718f2adabc9214c196942861bfe93c8e96dd3517c6d4988898a901485ed0c1022007fee4bfd89d6d1f936932c3dd37fcad44cdcd6ec3ad9daebc2b8d8d7da1d5e1012102826930ee848903793b57d2e253284dfa0df86de1103bace30b84ab619e663fb400000000
https://live.blockcypher.com/btc/decodetx/
This site decodes it fine but when I use decoder in golang or python either from bytes or a hex string it outputs garbage, is there something I am missing?

The hex data you posted is a perfectly cromulent SegWit transaction (this one). I can decode your hex data in go without any obvious problem. Maybe you can post the decoder you are using, full details of how you are using it and full error messages it produces

thanks for the reply just like that str :="hex posted", hex.DecodeString(str).   dst := make([]byte, hex.DecodedLen(len([]byte(str))))
n, err := hex.Decode(dst, []byte(str))`

In Go that just converts hex to binary. You need to also subsequently invoke methods from a proper blockchain parsing libary.

You must use a library written to parse Blockchain data.
Here's my own example. My library is unpublished, pick a different one from search results
package main

import (
    "encoding/hex"
    "fmt"
    "os"
)

// Read transaction data in hex from a file, parse & print it
func txFromFile(fileName string) {
    txHex, err := os.ReadFile(fileName)
    if err != nil { panic(err) }
    fmt.Println(string(txHex))

    b, err := hex.DecodeString(string(txHex))
    if err != nil { panic(err) }

    tx := parseTx(NewMyBuffer(b), 1)

    // Arbitrary print to show we parsed to a struct
    fmt.Printf("\nThe first output is worth %d Satoshi\n",
        tx.Outputs[0].Value)

    // tx is a Stringer (has String() method)
    fmt.Println(tx)

}

Example use
C> blockchain -txfile tx.hex
010000000001026a8da33916366b884349772dc022a39c4cf8d60acc45fd2527a71e5c80cc6da2000000000000000000208a35c4425160d006ed968606485258a1ecca80550ea48def5d44511bab553200000000000000000002e847791400000000160014885f1f476949438e34d3928fcff3449c339f934dc8633b0300000000160014618736c1f42c5029a5887a5ebac292720a4ccd1802483045022100f3d721d184ad19e50ca085fedb0c2654b1c5bd3cedb4b5f1d502ca7f21df125402204d87cda1511ebc1d943b0ee223aa2ade62410c51028d04ffabb3dfd7c1120273012102826930ee848903793b57d2e253284dfa0df86de1103bace30b84ab619e663fb402463043021f718f2adabc9214c196942861bfe93c8e96dd3517c6d4988898a901485ed0c1022007fee4bfd89d6d1f936932c3dd37fcad44cdcd6ec3ad9daebc2b8d8d7da1d5e1012102826930ee848903793b57d2e253284dfa0df86de1103bace30b84ab619e663fb400000000

The first output is worth 343492584 Satoshi

  Version:................01000000 (1)
  Type:...................0001 (Segwit)
  Inputs:.................02 (2)
  Input:1
    Previous Transaction:.A26DCC805C1EA72725FD45CC0AD6F84C9CA322C02D774943886B361639A38D6A
    Previous Output Index:0000 (0)
    Script Length:........00 (0)
    Unlocking Script:.....
    Sequence:.............00000000
  Input:2
    Previous Transaction:.3255AB1B51445DEF8DA40E5580CAECA1585248068696ED06D0605142C4358A20
    Previous Output Index:0000 (0)
    Script Length:........00 (0)
    Unlocking Script:.....
    Sequence:.............00000000
  Outputs:................02 (2)
  Output 1
    Value:................E847791400000000 (343492584)
    Script Length:........16 (22)
    Locking Script:.......0014885F1F476949438E34D3928FCFF3449C339F934D
  Output 2
    Value:................C8633B0300000000 (54223816)
    Script Length:........16 (22)
    Locking Script:.......0014618736C1F42C5029A5887A5EBAC292720A4CCD18
  Witness 1
    Item Count:...........02 (2)
    Item 1
      Length:.............48 (72)
      Data:...............3045022100F3D721D184AD19E50CA085FEDB0C2654B1C5BD3CEDB4B5F1D502CA
                          7F21DF125402204D87CDA1511EBC1D943B0EE223AA2ADE62410C51028D04FFAB
                          B3DFD7C112027301
    Item 2
      Length:.............21 (33)
      Data:...............02826930EE848903793B57D2E253284DFA0DF86DE1103BACE30B84AB619E663F
                          B4
  Witness 2
    Item Count:...........02 (2)
    Item 1
      Length:.............46 (70)
      Data:...............3043021F718F2ADABC9214C196942861BFE93C8E96DD3517C6D4988898A90148
                          5ED0C1022007FEE4BFD89D6D1F936932C3DD37FCAD44CDCD6EC3AD9DAEBC2B8D
                          8D7DA1D5E101
    Item 2
      Length:.............21 (33)
      Data:...............02826930EE848903793B57D2E253284DFA0DF86DE1103BACE30B84AB619E663F
                          B4
  LockTime:...............00000000 (0)
  (Calculated hash is 2C1DEA91142889092E41F0617250F83E0601E87290FAF0676F813F0F55063270)

Related: https://bitcoin.stackexchange.com/q/117397/13866


text:
Bitcoin protocol allows a chain to be undone by a longer chain
In Mastering Bitcoin, page 196, it says "While the protocol always allows a chain to be undone by a longer chain and while the possibility of any block being reversed always exists, the probability of such an event decreases as time passes..."
How and when will a chain be undone? How and when a block be reversed? Does Bitcoin core actually allow/support such operations?

Possible duplicate of What can an attacker with 51% of hash power do?

I am asking how and when it will be undone, 51% can be one way but not the only way, therefore it's not a dupe.

Bitcoin is a distributed system. At any given time, there are n different representations of the network, where n is the number of nodes participating in the network. These nodes have a consensus protocol (defined by the Bitcoin specification) which allows each of the nodes to maintain a state consistent with all of the other nodes on the network. The consensus mechanism in Bitcoin is related to the chain of blocks (hence the namesake, "blockchain"), essentially, the longest chain wins.
Blocks can be created by any miner participating in the network, anywhere in the world. When a block is created it needs to be propagated across the entire network, to all n nodes in the world. This can take time, and there is a chance that a new block is created before this process completes. That new block could then get propagated to nodes which haven't heard of the prior block (think network locality). When this happens your network has a fork.
The way the consensus protocol deal with this fork is by seeing which version of the chain the next block is built on top of--that chain will then be 1 block longer than the other and the nodes that see this will consider this the main chain, and the true representation of the Bitcoin ledger.
Interesting cases can come in where there is a major segmentation of the network (say an intercontinental cable is severed and India drops off the internet). Different segments of the network will have a different understanding of the state of the Bitcoin ledger, and thus, could begin building a diverging set of chains. When networks are rejoined, nodes again regain consensus by comparing chain length and choosing the longes; the shorter chain's blocks become invalid.
As time goes on, the ability of a network segmentation unseating a chain is reduced--the likelihood your transactions are on an invalid chain (i.e. the likelihood there is a longer chain being mined by a different portion of a segmented network) goes to zero.

Thank you - very detailed. Where do you get such good information or understanding from? Looking for you to teach me how to fish for this sort of info.

What about the part where a block can be reversed?

@Boon By virtue of those blocks no longer being in the longest chain, those transactions are no longer considered valid. Therefore any coins spent in those invalid chains are available to be spent again. It's not about actually reversing blocks, it's that nodes no longer consider them valid.

@Boon I mined Bitcoin back in '11 and wrote Bitcoin apps in the years following. I've worked with Bitcoin, Ethereum, and a handful of other cryptocurrencies in the time since then. There's no one place I got this information, it's just built up over time.
If you are technically minded, or have some programming experience, I would point you to the excellent article "Learn Blockchains by Building One": https://hackernoon.com/learn-blockchains-by-building-one-117428612f46?gi=f16a96caa9eb

By saying the longest chain wins, does it mean the entire chain is broadcasted when a new block is mined? Isn’t that a lot of data?

No, all node records each block that is broadcast; when a new block comes in it contains a reference to the block it builds on.

So when or where does "the longest chain wins" happen? Surely the node's current chain must be compared against something to know it is longer or shorter? Simply having the  previous hash reference can't give you that info.

Consider the simple case of a chain with 4 blocks, in sequential order, 1->2->3->4. Block 5 could come in and be built off of block 4--in this case everything would proceed on its merry way. If block 5 came in instead on top of block 2, it would be recorded, but those transactions wouldn't be considered a valid part of the current networks state. If block 5 came on pointing at block 3 though, you'd have to wait for block 6 to come through; whichever block it built on (4 or 5) would then be considered the canonical chain.


text:
If I invest £2,000 in bitcoin and the price goes down, can I lose more than my investment. Could i Have to sell my house to pay back the losses?
If I invest in Bitcoin is it possible to lose more than my initial investment ?
In other words if the price goes down substantially, to well below that of when I initially invested; is it possible that I might be sent a bill for the further losses ? Could I be sued for Bitcoin losses ?
I might be prepared to risk an investment if all I can lose is that investment, however I may not be prepared to make an investment if there is a risk, however seemingly small at the moment, that Bitcoin investors may be sued or expected to sell their house to pay off Bitcoin debts in the future.

Hi, welcome @Rob Strachan, please have a look at a list of topics for this site: https://bitcoin.stackexchange.com/help/on-topic. This one is a little off-topic because it is related to "investment advice", but feel free to ask any questions listed in the top half of the page linked.

@JBaczuk I think this question is okay: it is not looking for advice on whether or not to invest (a matter of opinion), it is just a question about how investing works (a matter of fact, or at least closer to it).

...if the price goes down substantially, to well below that of when I initially invested; is it possible that I might be sent a bill for the further losses ?

No.
If the price of a bitcoin dropped to $0, you would lose your entire investment, but no more than that.
Think of it like buying gold: if the price of gold dropped to zero, you would now just own some worthless metal. You wouldn't owe anyone money, you would simply have lost the capital you used to buy the gold in the first place.
The only way you are going to owe more money than your investment is through some external factor. As an example, if you took out a loan to buy bitcoin, and then owed interest on the loan. But that debt would be owed to whoever lent you the money.

Also: Margin trading

If I invest £2,000 in bitcoin and the price goes down, can I lose more than my investment.

Exchanging Currencies vs Making investments
This is just the same as investing in Euros by exchanging £2000 for Euro banknotes at a bank or money exchange. Once you have those €2227 they can never be worth less than nothing. No Euro banker will come after you and force you to pay them more GBP to take those Euro notes away from you. That's not the way currencies work.
It is more of a currency exchange than an investment. You might exchange GBP for Euros because you need the Euros to buy something (e.g. on holiday in Italy) or because you hope that the exchange-rate will change after Brexit so that your €2227 can be exchanged back for £3000.
It is not like investing in tangible things (e.g. land) and it is not like investing in complex financial instruments (e.g. derivatives of various types) where liabilities can accrue.
From the point of view of someone looking for a store of value, or speculating on exchange rate changes, whether exchanging £2000 for Bitcoin is more like buying Euros or like buying Venezuelan Bolivars is something that only time will tell.

Heh,
You can under extreme circumstances, but margin trading is one avenue where this is possible. Though the exchange is set to liquidate as to not have losses for the margin funding, just your funds unless you set a conservative stop limit. A great example would be the Ethereum flash crash of 2017 on Coinbase, where from a trading price of $340/ETH it dropped to 11 cents and people instantly were liquidated --- though ironically since the exchange liquidated and hovered around 160, most people did not "owe" coinbase much -- and in the end the trades were reversed (after bad publicity.)
Now if you use bitmex, you'll lose your investment on the slightest of market movement but as for losing your house. Unlikely.


text:
Help me resolve few queries about bitcoin network ( regarding validation, mining and state of transactions...)
Q1. Suppose I make a transaction from node A to node B, it is gets validated by the nodes in the network, A new block hasn’t been mined yet, in the meantime miner is stashing up the transactions Miner doesn’t include my transaction in the newly minted block, what happens to my bitcoin in the time between the next miner decides to put my transaction in the next block?
Q2. Bitcoin has a public ledger, by public ledger do we mean that each node in the network has a chain of blocks, each block having a set of transactions…and all these node have the same chain of blocks associated with them?
Q3. Whilst my transaction is internally being validated by the nodes in the network (not yet accepted by the miners), is this transaction being added to the ledger of various nodes in the network?
Q4. Also, let say, some node in the network validated a transaction, will the same node propagate this result to its neighbours, and the neighbours to their neighbours?

A1. It remains in the mempool of those nodes until a miner decides to include it in the block it's attempting to mine. Making a transaction from node A to node B is a little confusing, maybe you meant from address A to address B?
A2. Yes, nodes that share the same consensus rules (have not hard forked) will have the same blockchain (public ledger). The blockchain determines history of transactions, and the order in which they occurred.
A3. Nodes will validate transactions before they enter their mempool. Miners typically will just mine the block presented by the node (with tx's chosen to maximize profitability in terms of BTC fee/kB). The transaction is not entered into the blockchain (ledger) until a miner finds a valid solution and submits that back to a node. The node then begins to propagate the new block through the network.
A4. Yes, but this does not mean that transaction has been mined in a block yet, it will just be in each node's respective mempool.