text:
bitcoin core wallet transactions syncing
I'll explain the steps I want to figure out.
I have an empty bitcoin core wallet.

I backup the wallet and go offline.

Someone sends bitcoin to this wallet and I can see it in balance.

I restore my bitcoin core wallet to the initial point.

What will happen then?
I assume that I'll start over with the blockchain from scratch and what will happen is that initially the balance will be 0 (since my node is not yet aware of the transaction). So I'll need to synchronize up to the block where the transaction was included (this will take some time). At that time the balance will be updated.  After that the synchronization will continue until its up-to-date with the head.

Step 1. I backup the wallet and go offline.
Step 2. Someone send me a bitcoin to this wallet and i can see it(in balance).

When you're off the internet the wallet software will not know the transaction occurred until it is synced with other nodes on the network (P2P protocol). However, as long as the sender is online, the transaction will still be pushed into the mempool and eventually exist on the network (once included in a block) and you will be able to spend the output (so long that the transaction has been created properly).

Step 3 .Ill restore my bitcoin core wallet to the initial point..

If you've backed up your wallet file, you are essentially saving your private keys which is the only piece allowing you to spend TX outputs. If you reset your node or import your wallet into a computer that is not yet fully synced, the balance will remain 0 up until the block containing your transaction.

I assume that ill start over with the blockchain from scratch, And what will happen is that initially the balance will be 0 (since my node is not yet aware of the transaction). So ill need to synchronize up to the block where the transaction was included (this will take some time). At that time the balance will be updated. After that the synchronization will continue until it's up-to-date with the head.

Yep this is correct.

Step 1. I backup the wallet and go offline.

To be more secure you should create a wallet with an offline computer.
In general I'm confused how you use wallet and node. The wallet aims to be a private key, which is computed with a random input, the seed.
The node is a program running, connecting to other programs of its art (p2p).
This program gets information from the other programs and verifies on its own, if the information satisfies a given set of rules.

I assume that ill start over with the blockchain from scratch

So your assumption depends on the deletion/backup of the information you mentioned. If you deleted the wallet directory your node won't sync from scratch.


text:
I have not received my bitcoin after 2 days and 115 confirmations
I have sent my first Transaction and waiting for it to arrive at another address but when i click on the Transaction ID 1 of the addresses is Spent and the other is Unspent? It only required 3 Confirmations but is now 115? Where is my bitcoin and how do i receive it?
Thanks in Advance

Can you post the txid or receiving address? More info is needed to provide meaningful help.

Thanks for the reply guys, here is the Transaction ID if this helps:
https://www.blockchain.com/en/btc/tx/0ec3e57ee26a68f73030f331fa18184bc3290833fb5b40509caedbd434c99301

1 of the addresses is Spent and the other is Unspent?

The simplest transaction has one input and two outputs. One output is the amount to be transferred to the destination-address. The other output is the left-over change being returned to the sender (to the wallet containing the sending-address).
One way of interpreting what you wrote is that the recipient has already spent what you sent them.
Another way of interpreting what you wrote is that you have subsequently spent the change in a second transaction.

It only required 3 Confirmations but is now 115?

The transaction is confirmed. It is not pending. If you wait longer nothing will change.

Where is my bitcoin

Someone has already spent it (i.e. spent the amount sent or the change returned).

and how do i receive it?

It has already been received.

You don't say explicitly that you "own" the sending address and both of the receiving addresses (perhaps in more than one wallet) but if so, your wallet has been compromised and you should immediately move everything into a completely new cold wallet

lets look at the transaction
Transaction: 0ec3e57ee26a68f73030f331fa18184bc3290833fb5b40509caedbd434c99301

Source of funds: Address: 18gLw9DF8aBW2PzY3rVi35bFiuSTNgiv7s
                 Amount:  0.02849847 BTC

Outputs:         0.02054938 BTC to 16FsHnvTqnYrvdPXTH4c7tXD8ZE4r8rXJg - (Unspent)
                 0.00781349 BTC to 1NtLEd3y5wEmR3bsQ1LEeN6g8H3DbxSmiU - (Spent)

Only you know which is the amount transferred and which is the left-over change. So only you know whether the amount or the change has been spent.

Thanks for replying. I sent this bitcoin from my Exodus wallet to a website and then this was getting returned to the same Exodus wallet, but i have not received anything, even the Unspent? Are you saying that i maybe have been scammed  and this will never be received?

@BigKris64: I can't tell. What website did you use and who said they would return money to you? Did you check how long the website's domain name has been registered. Did you check what business owns the website and in which country it is registered - and for how long? Is this part of a get-rich-quick scheme? Its only 82 dollars (or maybe 31 dollars) no big loss.

Yeah your right i should have did more research into the website. It was $114 which $83 is Unspent and $31 is Spent, does this mean the $83 will be returned to the sender which is me? And ifso how long Thanks

@BigKris64: You already asked that and I answered above. There's nothing in what you wrote that suggests waiting will alter the situation to your benefit. If $83 is change it is already in your wallet somewhere. Change is handled as part of the spending transaction it does not require a second transaction to get change back.

source: Stack Exchange

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

sort: votes


text:
Spendable Wallet
My friend ask me to open a wallet in blockchain and ask me to give the ID and password later he transact certain amount of btc which shows non spendable after which I am asked to change my password and finished 2FA then I was asked to deposit some btc in my wallet to create a transactions history so that non spendable can be made spendable so is it a scam

Can't add much more to it. NEVER EVER give anyone access to your wallet EVER. Unless it's already gone to hell and you're attempting to pay/beg someone to help you recover it. In that scenario never put money into that wallet again. Once you regain access, move anything into it to a new wallet. Remember, the owner of the wallet is the person who has the ability to create a transaction and move amounts away from it.

See also linked questions in answer to https://bitcoin.stackexchange.com/q/74362/13866

Yes, it's a scam, and a well known one. You will lose all money that you deposit to that wallet, even if only you have the password and 2FA for the wallet. Your "friend" already copied the recovery seed and can take the money from the wallet even without a password or 2FA. Simply stop corresponding with that person.

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


text:
Trying to open an old wallet.dat (from ~2013)
I found my old wallet.dat file taken from the bitcoin core wallet I used when mining around 2013, nothing serious tho, just fiddling around. Never been too much into the subject, and now I'm totally out of the loop.
Will explain what I did so far:
I downloaded the latest bitcoin core, opened it and after a few seconds closed it properly, replaced the default wallet.dat file (with a size of 1416kb) with a copy of my old one (only 88kb) and opened the program again to let it download blockchain, then noticed that as soon as the program opened, the wallet.dat (my old one) file size changed to 688kb, waited for the  whole blockchain to download and noticed the balance it's still 0, the send/receive/transactions screens are also blank, as a vanilla wallet.
Maybe my old wallet file is somewhat an old format and get's erased and treated like a new one?

I put back the default wallet created by the program and from inside the program opened my old wallet file, a small window with a progress bar appeared saying "opening wallet filename", but it keeps loading forever. Also the file size changed again from 88kb to 688kb.
Any clue of what is happening?
I wan't to transfer whatever is there to some online wallet like coinbase.

If you look at the debug.log file, it should indicate whether the wallet was successfully read or not.

Have a look at https://bitcoin.stackexchange.com/questions/59699/opening-an-old-wallet-dat?rq=1 which is very similar.

And it should go without saying but: make a backup of the original version of the file!

You could try checking balance from blockchain, just click on receive and copy the address and search in blockchain.com, youll see you'll how much you got there.


text:
How To Create BTC Raw Transactions With 0 BTC Wallet And Broadcast It On Blockchain Network?
https://www.youtube.com/watch?v=2NFMMNXyHNE
I watched a YouTube video of someone that created several BTC raw transactions with 0 BTC Wallet and broadcasted it on blockchain network with valid transaction hash that was Visible and remained Unconfirmed for 7 to 72 hours before disappearing from the blockchain network.
How can I replicate this using Bitcoin Core? My Bitcoin Core full node is up to date.
THANK YOU IN ADVANCE

If you have 0 BTC, what are you going to transact with?

Visit this YouTube link and watch the video so that you can understand my question very well: https://www.youtube.com/watch?v=2NFMMNXyHNE

This is not possible, and is a common scam.
The approach these scammers take is to publish a video or telegram message, like the one you've found, claiming to be able to do the impossible. They then ask you to contact them.
Once you contact them, they will provide you with a software that is apparently able to do this. Some of them may charge you for the software, some may not.
This software in turn is a lookalike of popular wallets like Bitcoin Core and electrum, and will appear to do ask you ask - however, no transaction is actually created, and nothing is broadcast.
While you try to use the software, it will search your computer for existing bitcoin and crypto wallets, before attempting to drain them, upload keys to the scammers, or installing malware to continue compromising your system.
Stay away from anyone who claims to be able to do such things, and never install or run any program or code they share with you.

The bitcoin transactions shown in the Youtube video were all unconfirmed transactions. My question is how to create raw transactions with 0 BTC and broadcast it on blockchain network that will be Visible and remained Unconfirmed for 7 to 72 hours before disappearing from the blockchain network using Bitcoin Core?

You cannot. Those videos show fake transactions to convince you to reach out to the person and ask for a program that can do this. There is no way to do this.

@RaghavSood is right on! This video is fake.

The behavior you describe isn't achievable.

You cannot use funds in a transaction that don't exist or that you don't have the private key for.
A transaction that creates new money is invalid and will not be relayed by any honest network participants.

The bitcoin transactions shown in the Youtube video were all unconfirmed transactions. My question is how to create raw transactions with 0 BTC and broadcast it on blockchain network that will be Visible and remained Unconfirmed for 7 to 72 hours before disappearing from the blockchain network using Bitcoin Core?

It's not possible, what the video is showing is fake. Invalid transactions don't show up on the Bitcoin network.

I think it's a scam.
In order to construct a bitcoin transaction, you'd have to have non-0 UTXO and a private key. The invalid transaction wouldn't be available in bitcoin core mempoool. So to create it you'd have to have non-zero UTXO and privkey.
There is no possibility that the software in the video is centralized, if the creators would use their own funds with non-zero UTXO, with zero fees, any miner could attack it by priority mining.

The bitcoin transactions shown in the Youtube video were all unconfirmed transactions. My question is how to create raw transactions with 0 BTC and broadcast it on blockchain network that will be Visible and remained Unconfirmed for 7 to 72 hours before disappearing from the blockchain network using Bitcoin Core?


text:
Blockchain pruned node still downloading old blocks
We are working on a Bitcoin project for which we need to have the bitcoin node. The point is that we do not need to have the entire bitcoin node downloaded but only from the moment we start the project and therefore we opt for pruned node. The current setting is pruned = 1, because we don't need to prune the old blocks every X size of blocks.
So, after starting the node with pruned configuration, we see that old blocks are still being downloaded because in a matter of 20 minutes we had more than 10 gigabytes used space.
We have a wrong idea about "pruned node" or we have something wrong or partially configured?
Blockchain info

So, after starting the node with pruned configuration, we see that old blocks are still being downloaded because in a matter of 20 minutes we had more than 10 gigabytes used space.

Pruning does not mean not downloading; it means deleting them after they've been downloaded and verified.
Bitcoin Core always downloads and validates the entire history (for now).

Thank you for response. So we have to have enough storage so that the entire blockchain can be downloaded and verified?
If so, with pruned = 1 after verification of full node, from which block will the storage begin to save? Since the last of the concrete moment?

No, the (older, verified) blocks will be deleted after a while, while newer ones are still being downloaded. You only need a few GB storage for a pruned node.

I still do not understand. Thank you for being able to enlighten me again. We need to synchronize the blockchain as of October 1, which is when we will start the project. The blocks prior to that date are not necessary since the wallets that we will use will be newly created from that date. So is it correct that we have prune = 1? When we run the node and the blockchain is verified, would only blocks from October 1st be saved on the hard drive?

In short, I need to save the blocks starting from X block. I don't need to download the previous blocks or from genesis.

You can't avoid downloading them all (with Bitcoin Core today at least), regardless of whether you prune or not. With prune=0 you keep everything. With prune=N you will keep the last N megabytes of blocks. With prune=1 you keep everything, but can manually ask Bitcoin Core to delete stuff using the pruneblockchain RPC.

So, from what I understand, I can remove up to X block height using the pruneblockchain RPC command. It's right?

Yes, exactly. If you have prune=1 configured, Bitcoin Core won't delete any blocks on its own, but lets you manually delete blocks up to a certain height by calling that RPC. You can even call it while it's still synchronizing. However, even in that case you will need to download and verify all old historical blocks; it just lets you delete them after verification.

Thank you for clarify. Solved!


text:
I cant open my bitcoin wallet
After a few days I have inserted my external hard drive where I have installed the wallet with my btc to update it.
Giving the .exe "Bitcoin-qt" would normally directly open my wallet and start loading.
Today, however, when I click on it, the initial message jumps, from where I would like to create my wallet for the first time ...
What I can do ?

As I can see, I also keep all the files:
- blocks
chainstate
- wallets
- .lock
- peers.dat
- mempool.dat
Also inform that I recently updated windows 10, I do not know if it would have influenced

Can you describe in more detail exactly what is happening, perhaps including screenshots? "the initial message jumps" is not clear at all.

Hello friend.
I will describe my situation to you.
Whenever I access my external hard drive, where I have the btcs stored, I simply click on "bitcoincore-qt.exe" and my wallet opens directly and starts updating.
This time the problem is that my wallet does not open and I get the message like when you click for the first time to create a new one. I attach the picture on the open post.

@PieterWuille can u see it ? :)

That seems like you just don't have a wallet; if you had one before you should restore from a backup.

Did the drive-letter, assigned to the external drive, change?

Why initial message appears? I guess another USB device occupy the disk letter of your bitcoin external hard drive.

How to fix it? use command line with -datadir parameter. or just restore wallet from your bitcoin external hard drive after initial message, then show datadir in window-information.

You are using bitcoin CORE with the default folder in appdata?
so the location of the entire data folder (including the complete blockchain, and wallet.dat (where your private keys are) is in:
%userprofile%\AppData\Roaming\Bitcoin
copy and paste all that in a folder inside the USB drive.
specially care with wallet.dat, save it into TWO different drives, not one!, never do CUT and paste, do always copy and paste, and don't drag n drop either it's dangerous specially with touchpads hehe, if you don't have two usb hard drives for the entire blockchain, do a full backup in your USB drive, and then save in a flash drive only the wallet.dat.
it is one thing to have to download the entire blockchain because your USB hard drive died, and another is loosing all your bitcoins so, wallet.dat , TWO copies (remember, copies means that the file is in your computer AND on the devices) the more the better.
RESTORE: (my way, maybe there are other options, this is how i did it, multiple times! when defender screwed my blockchain data folder)
install bitcoin core (ideally the same version!, but it could be older, it works)
RUN IT
once it says sincronizing, close it.
(this is so the wallet will create the data folders)
now go to:
%userprofile%\AppData\Roaming\Bitcoin
and delete everything inside, and replace it with your copy from your USB drive backup


text:
Bitcoinjs-lib how to add multiple utxos in addInput
Hi i want to make transactions of bitcoin bech32 addresses using bitcoinjs-lib , here is my code below, it works fine when my address has only one utxos but when it increases to two or more as its array which doesn't pass into addInput method, so it fails. Please help me out to loop through it or what is the solution to handle multiple utxo as input.
Thanks
    // THIS THING I WANT BUT CANT DO IT BECAUSE LITECORE-LIB DOESNOT SUPPORT BECH32.
//---------------------------------------------------------------------------------------
const litecore = require('litecore-lib');

let utxo = [{
        txId: 'a3f2565ab944629bc0ca46990593c8ec49c50b5eaee0789d58b1b4bc97a76eb9',
        outputIndex: 1,
        address: 'ltc1q9umns6nuxv3xrhzdwlmhkzujewu6hulyuwgx30',
        script: '00142f37386a7c332261dc4d77f77b0b92cbb9abf3e4',
        satoshis: 3000000
    },
    {
        txId: '9d1517a2499ce5496ba3c826785b25982c63dc5b59b0c256303bf19128e44747',
        outputIndex: 0,
        address: 'ltc1q9umns6nuxv3xrhzdwlmhkzujewu6hulyuwgx30',
        script: '00142f37386a7c332261dc4d77f77b0b92cbb9abf3e4',
        satoshis: 2000000
    }
]

let to = 'ltc1q9umns6nuxv3xrhzdwlmhkzujewu6hulyuwgx30'
let from = 'ltc1q9umns6nuxv3xrhzdwlmhkzujewu6hulyuwgx30'
let privateKey = ''
let value = 1000

// // 4. Create transaction
var transaction = new litecore.Transaction()
    .from(utxo)
    .to(to, value)
    .fee(1000)
    .change(from)
    .sign(privateKey);

console.log(transaction)

//----------------------------------------------------------------------------------------

// NOW I WANT TO USE THIS LIBRARY AS ABOVE.
const bitcoin = require("bitcoinjs-lib");

let utxo = [{
        txId: 'a3f2565ab944629bc0ca46990593c8ec49c50b5eaee0789d58b1b4bc97a76eb9',
        outputIndex: 1,
        address: 'ltc1q9umns6nuxv3xrhzdwlmhkzujewu6hulyuwgx30',
        script: '00142f37386a7c332261dc4d77f77b0b92cbb9abf3e4',
        satoshis: 20000
    },
    {
        txId: '9d1517a2499ce5496ba3c826785b25982c63dc5b59b0c256303bf19128e44747',
        outputIndex: 0,
        address: 'ltc1q9umns6nuxv3xrhzdwlmhkzujewu6hulyuwgx30',
        script: '00142f37386a7c332261dc4d77f77b0b92cbb9abf3e4',
        satoshis: 30000
    }
]

let NETWORK = bitcoin.networks.litecoin;
let txb = new bitcoin.TransactionBuilder(NETWORK);

//get unspent output details
let txid = "9d1517a2499ce5496ba3c826785b25982c63dc5b59b0c256303bf19128e44747"; //transaction id of the output you want to spend
let outn = 0; // n out

//need scriptPubKey for adding input
let WIF = ""; //private key of bech32 output
let keypair = bitcoin.ECPair.fromWIF(WIF, NETWORK);
let scriptPubkey = bitcoin.script.witnessPubKeyHash.output.encode(
    bitcoin.crypto.hash160(
        keypair.getPublicKeyBuffer()
    )
);

//add input
utxo.map(item => {
    txb.addInput(item.txId, item.outputIndex, null, scriptPubkey);
})

//add output - Total UTXO SATOSHIS are: 20000 + 30000 = 50000/ So sending 10000 rest should be in the same address
txb.addOutput("ltc1q9umns6nuxv3xrhzdwlmhkzujewu6hulyuwgx30", 10000);

//signing
utxo.map(item => {
    txb.sign(item.outputIndex, keypair, null, null, item.satoshis);
})
let tx = txb.build();
let txhex = tx.toHex();

console.log(txhex);

What's different with spending SegWit outputs is that signatures cover input values. In other words, every SegWit input must be accompanied by its input value.
Mozilla's documentation says don't use map if you aren't constructing a new array. So I'll use for loop. (because order is important, and for-of is too new)
for (let i = 0, k = utxo.length; i < k; i++) {
    txb.addInput(utxo[i].txId, utxo[i].outputIndex, null, scriptPubkey);
}

//add output - Total UTXO SATOSHIS are: 20000 + 30000 = 50000/ So sending 10000 rest should be in the same address
txb.addOutput("ltc1q9umns6nuxv3xrhzdwlmhkzujewu6hulyuwgx30", 10000);

//signing
for (let i = 0, k = utxo.length; i < k; i++) {
    txb.sign(i, keypair, null, null, utxo[i].satoshis);
}

I thought to do this, but i think i have a stupid question here,
You know when using bitcore-lib, we pass utxo array of object in from function like this:
txb.from(utxo).to(recipient, value).sign()
I want to use addInput function like that.
Ass i'm doing this for litecoin so i can't use litecore-lib as it don't support bech32.I hope you understand my question.

Are you using bitcore-lib-ltc? The code in the question seems to use bitcoinjs instead of bitcore-lib.

Yes i'm using bitcoinjs-lib instead of bitcore-lib,
Let me tell you, I have used bitcore-lib for bitcoin bech32 addresses and it works fine to sign the transacations, But when i used litecore-lib to sign bech32 transactions for LTC so it fails because litecore-lib doesn't support it.
So that's wht i'm using bitcoinjs-lib to sign transactions for litecoin bech32 transactions, which works fine when i have sigle utxo object on my address but when array has multiple utxos so i got confuse which object i have to use?
on the same case bitcore-lib txb.from(utxo) it accept array.

Does it work for you now? Passing each scriptPubkey to each sign with each input.

It doesn't work actually,
Here is my inputs now: `
let utxo = [{
txId: 'hash',
outputIndex: 1,
address: 'ltc1...',
script: '00142f37386a7c332261dc4d77f77b0b92cbb9abf3e4',
satoshis: 3000000
},
{
txId: 'hash',
outputIndex: 0,
address: 'ltc1...',
script: '00142f37386a7c332261dc4d77f77b0b92cbb9abf3e4',
satoshis: 2000000
}
]
utxo.map(item => {
txb.addInput(item.txId, item.outputIndex, null, scriptPubkey);
})
txb.addOutput("ltc1q9umns6nuxv3xrhzdwlmhkzujewu6hulyuwgx30", 4999000);
txb.sign(0, keypair, null, null, 5000000);
`

Do i have your email so that i can send you my full file, so that you will know what i'm doing

I have updated the question with the new code please see the code above and also read the comments in code. Thanks

I'll post a solution tomorrow.

Sure I'll be waiting

Does it work now?

Yes it does. i would like to upvote this answer but can't don't have such reputations.
Thanks (Y)


text:
What is the origin of insecure 64-bit nonces in signatures in the Bitcoin chain?
In Biased Nonce Sense: Lattice Attacks against Weak ECDSA Signatures in Cryptocurrencies Joachim Breitner and Nadia Heninger use a lattice based algorithm to recover private keys from signatures in the Bitcoin chain that were produced by insecure signers that generated biased nonces.
One large category of insecure signature that they discovered were 5,863 signatures between July 26, 2014 and June 1st, 2015 that were used in multisignature scripts where the nonces were only 64-bits in size. In the paper when a single key was used multiple times to sign multiple messages (which could be multiple inputs on a single transaction) with a small difference between the nonces their algorithm was able to determine the actual nonces used and the private keys with high probability.
Using a small nonce in multiple signatures is just an especially simple case of having a small difference.  Small nonces could also be attacked with simpler brute force search approaches without requiring multiple signatures but the paper's approach was much faster than brute force.  Their approach was also able to attack a number of 110 - 160-bit nonces which were used, a range that would have made a brute force search less realistic.
The authors were unaware of the origin of the 64-bit nonces but "hypothesize that this may be a faulty implementation intended for multifactor security, such as a hardware token".
What do we know about the actual origin of these signatures?

Based on the time-frame and my impression of the capabilities of the various groups developing wallet software during that period my initial guess was that the Bitpay copay software might be the source of these signatures. Copay is a multi-signature wallet which was initially released around that time.
As I'm not a javascript developer it took me a bit of effort to dig through the historical dependencies to find the code that was applicable at that time, but I believe my suspicion is likely confirmed:
[If there exists some tool to go grab all of the dependencies of a JS application as of some date that would have been super useful.]

return new bignum(SecureRandom.getRandomBuffer(8));

This code chooses an 8-byte (64-bit) nonce.  I'm unclear as to how exactly this mistake came about--sending 32 to a function that took bits as a size argument, for example, would have made sense--but however it happened it wasn't caught in review and appears to have been shipped.
The pull-request that introduced the vulnerability was making the javascript cryptography implementation faster by switching the underlying EC operations to a different library, 'elliptic'.  At the time elliptic featured its own signing functions which included RFC6979 deterministic nonce generation. I don't see why bitcore wasn't changed to use the elliptic signing function even with the author of elliptic commenting in support of the PR but since there was pre-existing 'home rolled' signing code it just may not have occurred to anyone to switch to the library routines. There isn't a lot of discussion on the pull-request.
The vulnerability was subsequently fixed but weak signatures continued being created for some time.  Because Bitpay's bitcore was promoted as an all purpose Bitcoin library it's possible that other software than copay had adopted it.
I'm unable to find any announcement of or discussion about this vulnerability other than the fix in the repository.
Though I haven't carefully analyzed it, I noticed that prior to switching to elliptic that codebase previously used "bitcoin-js" which--at least in some versions--used a random number generator which was weak due to a review-evading subtle type error so it may well be the case that the error-introducing change simply changed the software from one form of weakness to another.
It's also possible that although bitcore had exactly the right vulnerability introduced at the right time that it was coincidental and the bad signatures found in the paper were created by some other implementation. If so, I think the parallel breakage is still informative.
I think the research and the relevant code make for a fine example of how easy it is to get these things wrong, how even small errors can result in total security breaks, and that the mere fact that something is open source does not automatically ensure that it has received adequate review.

Nice find!  I presume you've informed the authors of the paper?

Indeed, I have.

it should be "how difficult it is to get these things right" in the last paragraph.

IDK if it helps, but you can find the dependencies of a node project in the package.json of that commit: https://github.com/bitpay/bitcore/blob/ac4d3186bfbb4df2aee4389d1a51e488df08b52a/package.json#L54


text:
how to install Bitcoin and bitcoin cash on the same ubuntu server?
I've installed bitcoin core as the documentation in bitcoin.org and its working great. then, I tried to install bitcoin-ABC manually as following:

wget bitcoin-cash-gnu.tar.gz
tar xzf bitcoin-cash-gnu.tar.gz
cd bitcoin-cash-gnu/bin
ls

bitcoin-cli  bitcoin-qt  bitcoin-tx  bitcoind  test_bitcoin

I have renamed bin directory files so it doesn't conflict with bitcoin-legacy.

bitcoinCash-cli  bitcoinCash-qt  bitcoinCash-tx  bitcoinCashd  test_bitcoinCash

then i've installed it on /etc/usr/bin

sudo install -m 0755 -o root -g root -t /usr/local/bin bitcoin-cash-gnu/bin/bin/*

Then I tried to run bitcoinCashd and

Command not found

I was able to successfully install Bitcoin ABC on Ubuntu 14.04.5 LTS, alongside Bitcoin Core, using these instructions:

Download the appropriate binary from here: https://download.bitcoinabc.org/
For me, the command would be:
wget https://download.bitcoinabc.org/0.16.2/linux/bitcoin-abc-0.16.2-x86_64-linux-gnu.tar.gz
Extract the archive:
tar xzvf bitcoin-abc-0.16.2-x86_64-linux-gnu.tar.gz
Rename the binary files:
cd bitcoin-abc-0.16.2/bin/; rename 's/bitcoin/bitcoinCash/' *
Install the files into /usr/local/bin:
sudo install -m 0755 -o root -g root -t /usr/local/bin *

And voilà!
bitcoinCashd -version outputs:

Bitcoin ABC Daemon version v0.16.2.0-6af5e93
[...]

bitcoind -version outputs:

Bitcoin Core Daemon version v0.15.1
[..]

ls /usr/local/bin outputs:
bitcoinCash-cli  bitcoinCash-seeder  bitcoind    test_bitcoin
bitcoinCashd     bitcoinCash-tx      bitcoin-qt  test_bitcoinCash
bitcoinCash-qt   bitcoin-cli         bitcoin-tx

I did exactly the same, but when I called bitcoinCashd it didn't work

Is /usr/local/bin in your $PATH?

Your answer just gave me the chance to trust my solution and try again thanks!

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


text:
Get notified of incoming Bitcoin transaction, as soon as it broadcasted
After a few weeks of searching for an answer, I decided to ask here.
I want to accept a Bitcoin payment, to a specific wallet, and immediately, when the user approved the payment, to receive an indication that the payment was made.
The problem is, I don't want to wait until it is verified in a block, which takes around 10 minutes, I need the approval in seconds, not minutes.
How can I receive an indication that a Bitcoin transaction was occured to my wallet, in the last seconds?

The standard Bitcoin client will show pending transactions as soon as they hit the network.  There is some risk in accepting a zero confirmation transaction.  If this is for a brick and mortar establishment it is not likely that a double spend attack can be performed.  However online I would be more conservative. Particularly if the item being sold is not revocable such as a digital download.

Related: How do I accept bitcoin payments at a real world store?

If using the walletnotify option in bitcoin.conf, you can get a notification any time a transaction occurs on the network that matches a bitcoin address in the wallet. To use this, of course, you'll have to keep Bitcoin-QT or bitcoind running at all times.
https://en.bitcoin.it/wiki/Running_Bitcoin
Once you have the transaction id, you'll have to look up the transaction, either at an online service like blockchain.io or use a bitcoind json-rpc command to learn more about the transaction and what action you would like to take.

Is there anyway to get all new transactions? instead of only transactions of a specific address.

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


text:
How much would it cost to do a 51% attack
how much would it cost to carry out an 51%-Attack?
If there is a place service in the web that you can rent ASIC's than i would rather hear what renting this would cost. If not then buying the asics is fine too.
To keep the calculation KiSS following assumptions:

Attacker chooses the cheapest way of renting/buying hardware. But he is NOT renting/bribing whatever the existing machines from miners from the existing bitcoin network. The gear has to come from outside the network.
Don't worry about that renting/buying such a huge qt would drive the price for the hardware up.
Ignore what the community would do, the cored devs or whoever to counterstrike your attack.
you don't need to include electricity cost in the calculation. If you do include it, please tell what you took for US-Cents/kw/h

Thank you!
P.S. is there a website that does this calculations on a regular basis? Would be cool to check this from time to time..
Update 4 Years later ond June 2019: The Hashrate of the Entire Network is right now (according to Bitinfocharts.com): 55,42 ExaHashes. Most efficient Miner is the DragonMint which has exactly (and realisticaly) 16 TH/s and costs including with power supply 2844USD. One would need 55 420 000 TH/s /16 TH/s =3,46 millin Dragon Mints * ~ 2800USD (included a small rebate)~ 9,8 billion USD. Crazy how the cost increased in the last 4 years from 145 Million to almost 10 billion...
EDIT X Years old answers to this question don't matter at all. This question needs to answered every 6 months. Entirely new generations of Asic-miners, change picture a LOT

possible duplicate of How much would it cost to execute a 51% attack?, though the answers there are out of date.  Should I move my answer to that question?

a 4 Year old answer is totally useless. 2. My focus is more on renting, more last resort buying. 3. Assumptions different.

As I mentioned in my answer, I think Assumption 2 is kind of an understatement.  Renting or buying this much hardware would not only drive up the price but far exceed the amount available on the market (in a sense, it would drive up the price to infinity).  I answered the question based on the assumption that one can buy arbitrary amounts of hardware at the current market price, but we should note that this is highly unrealistic.

You are right in a way, but without assumption 2 it would basically focus on speculation on how the "supply curve" of mining hardware is and that would be pointless. Also i think an attacker would contact a manufacturer directly and get his custom build in this case no higher cost and maybe even 10% or so more efficiency (newer generation)..

Why buy it? If you want to do something criminal you would just want to steal it instead. It's silly to model attack scenarios based on what honest people can purchase the stuff for.

@Bitcoin You CAN'T steal that much hardware because it DOESN'T EXIST.  You would have to pay the manufacturer directly, largely in advance, and they would have to seriously beef up production to actually produce in these sorts of quantities.

You can use BGP route hijacking to just borrow other peoples, it's not correct to model things on hardware costs when you can just steal other people's.

There is a handy chart at https://en.bitcoin.it/wiki/Mining_hardware_comparison.
If we assume that it is complete, and that the figures listed there are accurate (I have not verified them), and that the attacker must buy the hardware, then the most economical device is the Antminer S5+, which produces 7.7 TH/s (7.7e12 H/s) and costs US$2300.  It draws 3.4 kW.
The current network difficulty is about 5.6e10.  This means that an average of 5.6e10 x 2^32 = 2.4e20 hashes are needed to mine one block.  Assuming that one block is mined each 10 minutes (600 seconds) on average, the network as a whole is producing 2.4e20 / 600 = 4.0e17 H/s.
So a 51% attacker needs to produce about 4.0e17 H/s himself, to match or slightly exceed the hashing power of the existing network.  This means he needs 4.0e17 / 7.7e12 = 52000 Antminer S5+ devices, which would cost 52000 x $2300 = $120 million.
(This is unrealistic in a couple of ways - buying that many devices would not only drive up the price but probably exceed the production capacity.  On the other hand, such a large order might qualify for a quantity discount or wholesale pricing.  This attacker might also find it more efficient to license the design and do the manufacturing themselves.)
Running these machines would consume 52000 x 3.4 kW = 177 MW of power.  If the attacker is located in the US, this table shows that the cheapest place to get electricity at an industrial rate is Washington State, where it costs an average of 4.5 US cents per kWh.  At this rate, the attack would cost US$8000 per hour to supply with electricity.
If they are all to be located in one place, there will be additional costs to build / rent and operate a facility to house them all, with appropriate electrical infrastructure.  There will also need to be significant network and server infrastructure to connect them all to the Bitcoin network.  Cooling costs will also be substantial - Google says that their data centers have electrical overhead of about 12% (i.e., on top of the electricity used by the equipment itself, an additional 12% is used for cooling, power supply losses, etc).  They say that the industry average is more like 70%.  You would also have to hire an IT staff to maintain everything.
This overhead might be reduced if the devices were to be distributed (e.g. each of 52000 people keeps one in their house) but then you start to incur administrative costs to keep all those people organized.  (Just picture the communications department to tell them what to do, accounting to make sure they all get their cut of the proceeds from this evil scheme, human resources to recruit new participants, etc.)

Awesome answer, thx very cool link!! i just modified calculation a little. Its a known fact that they advertise always a little more GH/s than they are able to deliver (reduced by 10%). Gh/s of Network: http://bitcoincharts.com/ so you need:  62.987 machines x 2307$ = about 145 Mill. $ hardware cost.  Thx for that very rich answer and additional valuable info...You are my hero...

Doesn't seem simpler to create zombie machines via a virus or some such with which you can do a short term hack?  Turn the system on, do 51% attack, turn them off and thus keep yourself undetected and then carry out short attacks whenever you feel like it?  I don't know this stuff but that sounds kind of easy for a bot net or something.

@AdamHeeg: Once upon a time that was feasible, today not so much.  Ordinary computers are far less efficient at mining than ASICs.  In this chart you can see that a typical CPU produces maybe 20 MH/s.  You need 20 billion average desktop computers in your botnet to mount this 51% attack.  I don't think there are that many on the planet.  Specialized hardware is really essential.

The cost consists from two parts.

Cost of hardware
Cost of electricity during attack

The market cost of miner which is not able to mine with profit is... zero. Because it is useless. The problem is only to collect such devices and turn them on for an hour or two.
We will see a lot of obsolete hardware for a very cheap price right after the halving the award.

An update as of Feb 2018.
The hashing power of the network is currently 24M TH/S.
The most powerful Antminer costs $1800 and can generate 14TH/S.
You'd need to 24M/14 = 1.7 million of these to control ~50% of the bitcoin network. That would cost ~$3B USD.
Each miner consumes 1.4 kw per hour. The average cost of a kilowatt hour in the U.S. is 12 cents.
So to run all of these miners would cost 12 cents * 1.4 kw/h * 1.7M antminers = $285,000/hour.
So that's $3B up front for hardware plus $285,000/hour to control the network.
Granted that leaves out a lot of practical considerations like how one could obtain 1.7 million ant miners, how much work it would take to get those all up and running, where you'd get that much electricity, etc.
This also is considering the cost of launching an attack for an entity that currently controls 0% of the existing mining pool.

authors: Александр Беликов


text:
What is the precise definition of "witness program"?
BIP 141 uses the term "witness program" extensively without, apparently, adhering to a consistent definition.
From the heading "Witness Program":

A scriptPubKey (or redeemScript as defined in BIP16/P2SH) that consists of a 1-byte push opcode (for 0 to 16) followed by a data push between 2 and 40 bytes gets a new special meaning. The value of the first push is called the "version byte". The following byte vector pushed is called the "witness program". [my emphasis]

https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#witness-program
In other words, a "witness program" is a byte sequence 2 to 40 bytes in length. In P2WPKH authentication, the witness program is the 20-byte hash value of a public key. In P2WSH authentication, the witness program is the 32-byte hash value of the serialize "witness script" (last element of witness data).
At least, this is what I gather from reading the definition under the heading.
However, BIP 141 makes other references to "witness program" that seem to suggest something else. For example:

"In addition, opcodes within the witness program are counted identical to as previously within the P2SH check script."
"The P2WPKH witness program is then executed as described in the previous example."

Also, headings seem to suggest that "witness program" means something else:

"P2WPKH witness program" (describes a new authentication template) https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#p2wpkh-witness-program
"P2WSH witness program" (describes a new authentication template) https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#p2wsh-witness-program

What is a precise definition for the term "witness program?"

The usage of the term "authentication" above might be replaced with "identification" or removed altogether.

Thanks for your comments. This is the proposed fix: https://github.com/bitcoin/bips/pull/416

Thanks - those changes are consistent with the definition in the paragraph I quoted, and clear up all of my questions. In other words, a witness program is a hash value. Still, I'm uneasy about using the term "witness program" to refer to something that isn't actually a program or even Script. What's the origin of that term and the compelling reason to use it rather than something more consistent with function?

The witness program is still a script, just a trivial one, and one that follows a fixed structure that is given a new meaning.

@PieterWuille, the current BIP-141 staes "The value of the first push is called the "version byte". The following byte vector pushed is called the "witness program"." Yet "witness program" is clearly identified as a hash value elsewhere in the BIP. A hash value is not a script in any way I can decipher. It's a hash value of a script. Am I missing something?

See it as a continuation of P2SH. P2SH scripts are clearly programs (they're executed, and contain opcodes); however, their only substance is the script hash they contain. Witness programs just continue that trend - the encoding as script bytes is vestigial, but there are actual semantics involved (P2WPKH and P2WSH have different semantics, for example).


text:
Restarting Vanitygen
I want to create a bitcoin address which starts with a certain passphrase (1mathias, case insensitive). That idea came from this question, and I quite liked it. After some trouble making the file on my Mac, it finally worked.
mbpssd2:vanitygen-master mathias$ ./vanitygen -i -t 4 1Mathias
WARNING: Built with OpenSSL 0.9.8y 5 Feb 2013
WARNING: Use OpenSSL 1.0.0d+ for best performance
Difficulty: 26838491360
[235.42 Kkey/s][total 2888131518][Prob 10.2%][50% in 18.5h]

It is running for quite some time now, and I want to stop it, and continue with finding an address tomorrow. For what I understand, is 1 in that number addresses that fit my passphrase. So if I would choose '1' as passphrase, there would be 1. The percentage showing in terminal is the current generated (and rejected) addresses, compared to the total amount. So reaching 100% doesn't have anything related to finding an address. I can happen at 0.01%, or at 70% or at 8012%, if you are really unlucky (right?)
From the creator of vanitygen I found the following:

If I stop vanitygen when it reports 60% complete, how do I have it restart where it left off?
You don't need to.  The percentage displayed just shows how probable it is that a match would be found in the session so far.  If it finds your address with 5% on the display, you are extremely lucky.  If it finds your address with 92% on the display, you are unlucky.  If you stop vanitygen with 90% on the display, restart it, and it finds your address with 2% on the display, your first session was unlucky, but your second session was lucky

But that does not make sense. If I reach 100%, I am not completely sure that an address has popped up, fitting my passphrase. Is this correct? If I let the program run, and generate a billion addresses, not stopping when (or if) it hit my passphrase, it is even likely that it finds a correct one in the first thousand, as in the last thousand?
I'm quite sure I am right, but I might be missing something. I tried to bold the two areas where I am not sure of.

Vanitygen works like this:

Generate a random 256-bit integer to use as an ECDSA private key
Compute the corresponding public key
Compute the hash of the public key to find the address
Check if it matches the requested pattern (1Mathias in your case)
If yes, halt and output the private key; if no, start over at step 1

Notice that there is no state saved in this process, so you lose nothing in stopping and starting as much as you want.  Each random private key has an equal probability of success; it doesn't matter how many you have already tried.
For a given number N of random private keys tried, one can compute the probability that (at least) one of them would succeed.  This is the "percent" number that Vanitygen reports - it's not a percent completion!  In the excerpt you show, it says that it has tried 2888131518 keys, and that mathematically, trying 2888131518 keys has a 10.2% chance of finding one that works.  It also says that in 18.5 hours, it will have tried enough keys that the chance of success is 50%.  This does not scale linearly!  If you are unlucky and don't find a key for 37 hours, it won't say 100%; it will say 75%.
As an analogy, suppose you have an ordinary 6-sided die, and you want to roll it repeatedly until you get a 6.  Your chances of succeeding with one roll are 1/6 (16.6%); your chances of succeeding within 10 rolls are 83%; your chances of succeeding within 100 rolls are 99.9999987%.  But this number never gets to 100%; there is no number of rolls that will guarantee success.  There is always some chance that, of all the rolls you made, none of them came up 6.
So the "percent" number reported by Vanitygen is never going to reach (much less exceed) 100%.  It is simply intended to give you an estimate of how long the process might take, but since it is random, there can be no guarantees.  If it gets very close to 100%, all you know is that you have been very unlucky; but your odds of success with each new key are exactly the same as they always were.

Thanks for this long explanation. My error was in the linear scaling I see now. Well, better start running the program again, otherwise I will never get an nice address :)


text:
If you confirm others' transactions, what do you do to earn 25 bitcoins per block?
I was a bit surprised to learn that you can earn 25 bitcoins, just by confirming a block worth of transactions. If I've done the math right, at $493 per bitcoin, that's $12,325.
Does one do a lot of work (beyond a few mouse clicks) to earn those 25 bitcoins? Does that constitute "rent" for the use of the resources of your computer (which probably cost a lot less than $12,325)?
Or is it just the case that 25 bitcoins are issued per block, and by confirming  a block of transactions, you get those those 25 bitcoins.

If confirmation was easy, then everyone would just confirm conflicting transactions and the Bitcoin system wouldn't work. For Bitcoin to work, confirming a block must be exceptionally difficult, and it is.

The difficulty is automatically adjusted to try and keep an average time of 10 minutes between blocks. The average amount of work it takes to create a block is the work done by all the miners in the world for 10 minutes. That's a lot of work.

Just to give some specifics in addition to David Grayson's answer:
At current difficulty levels, mining a block requires computing an average of

29,973,900,941,385,007,104

hash operations.  An ordinary computer can perform perhaps 10,000,000 such operations per second.  At that rate, such a computer would take about 95,046 years to mine one block, on average.  If the computer draws 100 watts of electricity, it would use 3,469,201 kilowatt-hours of electricity over that time.  Electrity prices are somewhere around US $0.10 per kWh, so that would cost US $346,920 in electricity alone - much more than the $12,325 of the block reward.
For obvious reasons, most miners today don't use ordinary computers, but rather specialized ASIC hardware that is considerably more efficient (and more expensive) than an ordinary computer.

It is a lot of work and it requires a lot of computing power.  To get the 25 BTC reward for a block (also known as the coinbase reward), you have to create the block in the first place.  It is difficult to create blocks.  A valid block will have to meet a large number of conditions, including that its header has a 256-bit hash whose numerical value is under a certain target.  The target generally gets lower (more difficult) over time as more people try to create blocks.
Since the hash function is hard to reverse, you basically have to brute force it, trying many different possible variations on the data in the block and computing the hash of each one, until you find a block whose hash is low enough.  If you are lucky, you will find such a block.  Then you would broadcast that block to the world, and since you created the block it will contain a transaction giving the coinbase reward to your own address.  This process of calculating hashes and making new blocks is called mining and it is almost impossible to make money doing it yourself these days, so you would have to join a mining pool.
A miner confirms transactions by creating a block and including transactions in them.  The new block contains a hash of the previous block, so it also serves as an extra confirmation for all the previous blocks in the chain and all the transactions in them.

"A miner does not confirm a block."
A miner do confirm a block. Every block which has been mined confirms every acestor block. (Even in the original BitcoinQT each block increments confirmation count.)

Yeah, you're right.  I changed my last paragraph.

Joining a pool does not make making money via mining any easier (or possible), just less sporadic.

Besides confirming the transactions in the block (which prevents the corresponding funds from being double-spent) the new block also adds to the security of all previous blocks since altering any block in the chain requires altering it and all subsequent blocks.
In my mind that it what justifies the reward.


text:
Is "Ring Signature" used in "Confidential Transactions" of the Bitcoin?
According to the Ring Confidential Transactions research paper of Monero (Link to the paper), in section 1.5. Ring Confidential Transactions Overview, it is mentioned:

"We describe a modification to the Monero protocol, a proof-of-work
  cryptocurrency extending the original CryptoNote protocol. The
  modification is based on Confidential Transactions which are used on
  the Elements side-chain in Bitcoin, except it allows for their use in
  ring signatures  [cited to this article as reference]. Therefore, the modification is given the obvious
  name of Ring Confidential Transactions (Ring CT) for Monero."

However, in the cited article (Link), it is mentioned that the Ring signature is used in Confidential Transactions of Bitcoin too.
If so, why in Monero's paper it is mentioned that "except it allows for their use in ring signatures" as its difference with Bitcoin Confidential Transactions ?
Is "Ring Confidential Transactions" used in both Bitcoin and Monero?

Bitcoin does not have confidential transactions.

I mean this feature: https://people.xiph.org/~greg/confidential_values.txt
where, it's talking about Confidential Transactions as a cryptographic tool to improve the privacy and security of Bitcoin. Apparently, it's written by you :)

@Questioner Yes, a writeup of a technique exists which could be used in theory, but it's not even a proposal, much less in use, so the question makes no sense.


text:
"bitaddress.org": It generates a BTC or BCH address?
(1) Is the address generated by www.bitaddress.org a BTC address? Or BCH address (Bitcoin Cash) ?
(2) Is there a general method to recognize BTC address from BCH address?

1) A Bitcoin address/private key is the same as a Bitcoin Cash address/private key.
2) To prevent confusion, one year ago Bitcoin Cash started to use a new address format called CashAddr. They can be used interchangeably if the wallet/service doesn't support the CashAddr format, using the official address translator or mine. Today, most of the services accept both types of the BCH addresses.
To sum up, Bitaddress is compatible with Bitcoin and Bitcoin Cash, but you should convert it to CashAddr before receiving Bitcoin Cash so that they won't send you bitcoins by mistake. (Both 1 and CashAddr addresses are accepted by BCH services while BTC services don't recognize CashAddr, intentionally)
BTW, there's Bitaddress fork named cashaddress.org that generates CashAddr by default.

Thank you, Just at the beginning of a CashAddr, always there is the word of "bitcoincash:" for example: "bitcoincash:qzzyq...". Do we need to include this this word when for example we want to set a BCH address in a mining pool or any other place? Thanks

It may be omitted, it won't have any side effects.


text:
How to generate the digest from a raw bitcoin transaction for verifying signature of specific input?
I'm writing a stand alone process that needs to verify that a known UTXO is part of a new transaction with a valid signature.
Inputs [ UTXO, raw transaction, input_number ]
How do to I verify the signature for this specific input?
As I understand, depending on the SIGHASH, I would need to parse the entire transaction and replace/remove some data. However, the length bytes seem to make the entire process extremely complex.
Does a segwit transaction make everything easier? Or are there still bytes that need to be removed depending on SIGHASH?
On a side note. in general, will APIs that return "raw transactions" no longer have the signature data for segwit transactions? or are they all appended to the end?

However, the length bytes seem to make the entire process extremely
  complex.

Not very complex. Here is a piece of my code for generating digest for standard non-segwit transactions and sighash_all inputs (I do not need and have not tested other hashtypes).
const MyKey32 Transaction::getDigest ( const int n, const QByteArray& scr ) const
{
  MyByteArray data;                                 // create empty array
  MyStream stream ( s );                            // source transaction is a stream
  data.putInt32 ( stream.readU32 ( ) );             // version
  data.putVarInt ( stream.readVar ( ) );            // input count
  for ( int i ( 0 ); i < inputs; i++ )              // copy all inputs
  {
    data.putArray ( stream.readAdvance ( 36 ), 36 );// copy 32 byte hash as is + copy 4 bytes index
    data.nop ( stream.skipVarData ( ) );            // skip original script and do nothing
    data.putPrefixedCond ( i ^ n, scr );            // script replacement: empty or given in param
    data.putInt32 ( stream.readU32 ( ) );           // sequence
  }
  data.putVarInt ( stream.readVar ( ) );            // output count
  for ( int i ( 0 ); i < outputs; i++ )             // copy all outputs byte-by-byte
  {
    data.putInt64 ( stream.readU64 ( ) );
    data.putPrefixed ( stream.readVarData ( ) );
  }
  return data
      .putInt32 ( stream.readU32 ( ) )              // lock
      .putInt32 ( SIGHASH_ALL )                     // append hashcode
      .sha256d ( );                                 // double-sha256
}

Yes, I agree this base case is simple. And I too only use non-segwit sighash_all transactions coded in QT! however, my issue is trying to prove that a known UTXO was already "spent". I want to do this offline, without any access the Bitcoin network. A signed byte string that contains my UTXO in the digest is considered "spent". This is the final piece of my custom atomic swap code in a new blockchain.


text:
What Opcodes are used to store a file within Bitcoin?
At a block-to-block level, what is actually encoded at a byte[] level to encode a file stream?

Store files? That’s not a thing in Bitcoin.

The coinbase transaction?

For details of the specific byte structure of a block, see resources like the Bitcoin Wiki article on blocks. For a transaction, see the article on transactions.
The actual data storage happens within the transactions, within their intput and/or output scripts. Theoretically, any script could be made including arbitrary data, but due to network standards, only certain types of scripts are allowed.
For an in-depth look at data storage techniques, see this paper. (Full disclosure: I am one of the authors.)
Note, when I talk about pushing data to the stack:

PUSHDATA(N) (where 0 <= N <= 75): Push the next N bytes onto the stack. The byte value for this is dec: N
PUSHDATA1: The next byte indicates the number of bytes after that to be pushed onto the stack. The byte value for this is dec: 76, hex: 0x4c
PUSHDATA2: The next two bytes indicate the number of bytes after that to be pushed onto the stack. The byte value for this is dec: 77, hex: 0x4d

Also, each chunk of data pushed with a PUSHDATA element cannot exceed 520 bytes, so bear in mind that any file will necessarily be broken up into chunks of 520 bytes or fewer.
Some ways of storing data include:

Using the coinbase (or generation) transaction (if you're a miner) to store a small amount of arbitrary data in each block you mine. This data takes the place of the inputs that would normally appear in a transaction. The coinbase transaction allows up to 100 bytes of data; however, some of this must be used for special uses, such as the block height and extra nonce.
In outputs with OP_RETURN. Each transaction may have one OP_RETURN output. Such an output may have a value of zero (since otherwise you're burning money that can never be recovered). The script looks like OP_RETURN <up to 80 bytes of data>. OP_RETURN is byte value dec: 106, hex: 0x6a, and the data must begin with a PUSHDATA element.
In outputs that pay to an address, etc. that recipient address/key/etc. may be replaced with arbitrary data. In that case, take the regular script and replace the address/key/etc. with your data. This creates an output which you cannot spend but which must be tracked in the UTXO set, so it is not advisable to do. An example of this would be to take the P2PKH script OP_DUP OP_HASH160 <Public Key Hash> OP_EQUALVERIFY OP_CHECKSIG and replace the 20-byte public key hash with 20 bytes of other data. (Note that the hash is pushed onto the stack with a PUSHDATA(20) element. As bytes, this looks like: 0x 76 a9 14 [your 20 bytes of data] 88 ac.) If you're replacing e.g., a public key, it may be detected that you're not using a real public key (if it doesn't start with 0x02, 0x03, or 0x04, for instance), but a hash should be indistinguishable from arbitrary data.
In inputs, using P2SH scripts. Then the data may be stored in the redeem script itself or in the inputs to the redeem script. There are multiple ways to do this, but generally the arbitrary data will be included in a PUSHDATA element, which the redeem script will somehow operate on. One notable method involves the redeem script including OP_HASH160 <hash of the data to be included> OP_EQUALVERIFY, and the inputs to that script including the data to be stored. This method ensures that the data must be included for the script to return true. Another method is pushing data to the stack, then using OP_DROP or OP_2DROP to remove it from the stack. This is efficient, but it would be possible for an attacker to tamper with the data in a transaction malleability attack.
You could also store data in e.g., the value field of your outputs, but this is highly inefficient.

Is it 80 bytes minus op_return, or is the size of that 1 or 2 bytes, bringing the effective size down to 79 or 78 bytes??

The maximum size for an OP_RETURN is actually 83 bytes by default. (This is a network "standard" and actual miners can choose for themselves what they will choose to mine.) This gives you effectively 80 bytes of data at most: 1 byte for OP_RETURN, 1 byte for OP_PUSHDATA1, 1 byte to indicate 80 bytes of data to be pushed, then 80 bytes of data. This is defined here.

You can store arbitrary bytes in a Bitcoin transaction which are not validated but can be confirmed in the blockchain given sufficient fees.
op_return is a Bitcoin script op_code used in output scripts and which, when executed on the script interpreter will return the script run as invalid, thereby rendering the output "unspendable".
Now, because the script-run is aborted, subsequent data in the same output script are never evaluated and can be arbitrary. A valid, confirmed Bitcoin transaction can contain unspendable outputs.
In theory an arbitrary size of data can be appended to op_return as long as the transaction is still valid (consensus), but node propagation policy usually limits this to 80-bytes. A miner could confirm larger data sizes of course.


text:
Why can’t the genesis block coinbase be spent?
According to the bitcoin wiki:

The first 50BTC block reward went to address 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa, though this reward can't be spent due to a quirk in the way that the genesis block is expressed in the code (this may have been intentional).

But where is this quirk? How would you change it to allow it to be spent?

One has to mind at that point of time 50 BTC was costing like.. literally 0 cents. I doubt he has given any thought to make this intentional or not.

Maybe it is because the 50 BTC reward is technically premined since the code was released 6 days later. So technically it would have been unfair if Satoshi could spend those coins. IMO that's another beauty of Bitcoin.

When a node starts up it initializes its copy of the block database alongside the genesis block and then begins the synchronization process. For some reason, Satoshi decided not to add the coinbase transaction from the genesis block to the global transaction database. Thus all the nodes in the network would reject the block.
I'm not sure if this was done on purpose or if it was simply an oversight. In any event, it is forever bound to 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa.

How would you change it to allow it to be spent?
Add this to the hardfork list

How do we know of it if it's not in the database?

We know it's not in the database because if you do getrawtransaction 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b via RPC calls it returns an error, even though you can go to a block explorer (like here) and see that this is the genesis block coinbase transaction.

(Even when -txindex=1 is enabled)

How would you change it to allow it to be spent?

In order to make the coinbase spendable, the following changes have to be made to validation.cpp (v0.16.2). Note: as mentioned this would be considered a hard fork.
Step 1 - Disable skipping the genesis block (which is intended to keep the bug as part of consensus), Line 1818:
// Special case for the genesis block, skipping connection of its transactions
    // (its coinbase is unspendable)
    if (block.GetHash() == chainparams.GetConsensus().hashGenesisBlock) {
        if (!fJustCheck)
            view.SetBestBlock(pindex->GetBlockHash());
        // return true; <- comment this line out
}

Step 2 - Skip assertion of previous block for genesis block, Line 1874:
if (block.GetHash() != chainparams.GetConsensus().hashGenesisBlock) {
    assert(pindex->pprev);
}

Step 3 - Skip writing undo data for genesis block, Line 1989:
if (block.GetHash() != chainparams.GetConsensus().hashGenesisBlock)
{
    if (!WriteUndoDataForBlock(blockundo, state, pindex, chainparams))
        return false;
}

At least with current versions of the Bitcoin Core client, the Genesis block is actually hard coded into the client.
The part of the code that builds this block is located here and I have included a JSON dump of the coinbase transaction below for reference.
{
    "txid" : "4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b",
    "version" : 1,
    "locktime" : 0,
    "vin" : [
        {
            "coinbase" : "04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73",
            "sequence" : 4294967295
        }
    ],
    "vout" : [
        {
            "value" : 50.00000000,
            "n" : 0,
            "scriptPubKey" : {
                "asm" : "04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f OP_CHECKSIG",
                "hex" : "4104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac",
                "reqSigs" : 1,
                "type" : "pubkey",
                "addresses" : [
                    "1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa"
                ]
            }
        }
    ]
}

Reference Gist

This answer could be improved by addressing why the Genesis Block's output cannot be spent.


text:
About Bitcoin Core
I have just downloaded the Bitcoin Core from https://bitcoin.org/en/download
I would like to ask the following since I have read the following article:

https://blockgeeks.com/guides/best-bitcoin-script-guide/

https://blockgeeks.com/guides/bitcoin-script-guide-part-2/

Is that downloaded Bitcoin Core features the same as the above 2 articles? Am I able to create my deposit and send transactions to include the fee and select peers?
Appreciate your kind guidance. Thank you.

If you are using the GUI (the visual window interface), you should be able to do all of those things. If you only installed the command line version, type bitcoin-cli help into your terminal to see a list of commands. bitcoin-cli help <command> will give you info on what each command does.

Thanks for the command line version.


text:
Problem with Greenaddress 2of2 Recovery
I'm encountering an unforeseen problem with 2o2 Recovery procedure.
I followed all the instruction at https://github.com/greenaddress/garecovery, I've correctly installed Ubuntu for Windows, I've correctly run through all the steps until:
$ garecovery-cli 2of2 --nlocktime-file /path/to/downloaded/nlocktimes.zip -o garecovery.csv

I've passed the correct nlocktimes.zip, I've entered the right mnemonic, but the output I see is the following:
Traceback (most recent call last):
  File "/home/rene/.local/bin/garecovery-cli", line 7, in <module>
    sys.exit(recoverycli.main(sys.argv))
  File "/home/rene/.local/lib/python2.7/site-packages/garecovery/recoverycli.py", line 86, in main
    recovery = get_recovery(clargs.args, mnemonic, seed)
  File "/home/rene/.local/lib/python2.7/site-packages/garecovery/recoverycli.py", line 61, in get_recovery
    return TwoOfTwo(mnemonic, seed, options.nlocktime_file)
  File "/home/rene/.local/lib/python2.7/site-packages/garecovery/two_of_two.py", line 25, in __init__
    zipdata = gacommon._unzip(self.compressed_zip, chaincode)
  File "/home/rene/.local/lib/python2.7/site-packages/gaservices/utils/gacommon.py", line 35, in _unzip
    all_data.extend(_unzip(_fernet_decrypt(key, encrypted), key))
  File "/home/rene/.local/lib/python2.7/site-packages/gaservices/utils/gacommon.py", line 11, in _fernet_decrypt
    assert wally.hmac_sha256(key[:16], data[:-32]) == data[-32:]
AssertionError

Can anybody help me?
Many thanks in advance for any suggestions.

It seems that you have entered a valid mnemonic, but it cannot decrypt the nlocktime.zip file. It could be that the mnemonic you entered is not the one associated with the wallet (which can be used to decrypt the nlocktime.zip).
I replicated your error by using another mnemonic in one of the examples (garecovery/examples/example_2of2.sh):
$ garecovery-cli --network=testnet --mnemonic-file garecovery/tests/test_data/mnemonic_2.txt 2of2 --nlocktime-file garecovery/tests/test_data/compressed_1.zip
Traceback (most recent call last):
  File "/tmp/recovery/venv/bin/garecovery-cli", line 7, in <module>
    sys.exit(recoverycli.main(sys.argv))
  File "/tmp/recovery/venv/local/lib/python2.7/site-packages/garecovery/recoverycli.py", line 86, in main
    recovery = get_recovery(clargs.args, mnemonic, seed)
  File "/tmp/recovery/venv/local/lib/python2.7/site-packages/garecovery/recoverycli.py", line 61, in get_recovery
    return TwoOfTwo(mnemonic, seed, options.nlocktime_file)
  File "/tmp/recovery/venv/local/lib/python2.7/site-packages/garecovery/two_of_two.py", line 25, in __init__
    zipdata = gacommon._unzip(self.compressed_zip, chaincode)
  File "/tmp/recovery/venv/local/lib/python2.7/site-packages/gaservices/utils/gacommon.py", line 35, in _unzip
    all_data.extend(_unzip(_fernet_decrypt(key, encrypted), key))
  File "/tmp/recovery/venv/local/lib/python2.7/site-packages/gaservices/utils/gacommon.py", line 11, in _fernet_decrypt
    assert wally.hmac_sha256(key[:16], data[:-32]) == data[-32:]
AssertionError

For sure, the error message will have to be improved.
If you need further assistance and you feel you may reveal too much information about your situation, please send an email to info@greenaddress.it.


text:
When "lock time" was added to Bitcoin?
Since when lock time exist in Bitcoin transactions?

You may be thinking of the CLTV opcode (which allows putting requirements on the nLockTime of spending transactions), which was added in BIP65 (activated in 2013).

There was no mistake :)

Since the very beginning. Transactions have had the nLockTime field since Bitcoin 0.1.0.

Though interestingly, it worked differently until a soft fork. It used to be signed, and was changed to unsigned.


text:
Replace-by-fee Problem
Good Day. Please i have an Account with BlockChain but i notice my account has a withdrawal of all my BTC which was not done by me. It has Replace-By-Fee
What might have happened?
How can I get my money Back?
Sent BTC         May 21 2020 @ 2:22 AM     Replace-By-Fee
To:              bc1q52vem2cnzps34reymhw0v07wgzme8gq92dzc5p
From:            My Bitcoin Wallet
                 $3,461.91        0.38223108 BTC
Description      Add a description
Value When Sent  $3,645.37
Sent From        159qFcZvv46Vz861PFxUNLPzjpTZw2oiPj
                 17BoVBrrkZ13DWNEBdew8QL3CCq6mv3722
                 1PnBQwZhiMMtb2XptpTBzBFa658iWm4gzd
                 1ahi6h2WMaGCpbrs2d7cr2o9Fo1m2Mu4J
                 1LcXKTF7TwNBw9jH4pTMHJRTMWGxo55syD
                 1CkJkCBVJt11Cj41SY9SQ7hu8318tcc19s
Received By      bc1q52vem2cnzps34reymhw0v07wgzme8gq92dzc5p
Status           Transaction Confirmed
Transaction Fee  0.00113524 BTC    $10.28

Please i have an Account with BlockChain but i notice my account has a withdrawal of all my BTC which was not done by me. It has Replace-By-Fee
  What might have happened?

If you did not initiate this transaction, then it looks as if your account was somehow compromised. Have you ever shared login details for the wallet with anyone else, or did someone create the wallet for you? There are common scams which employ these tactics.
Otherwise, without more information, it isn't really possible to discern how your account was compromised. In any case, that wallet (and possibly compute you used to access it) should be considered compromised, and should not be used for any further BTC transactions.

How can i get my Money Back?

You likely cannot. Bitcoin transactions are not reversible, your only hope would be to find the person who stole your coins, and ask for them back.
Sorry for your loss :(

I created the Account and have 2 FA to login and Secondary Password Withdrawal. The Laptop is Always at home and i stay alone.

Here is someone else  complain  https://bitcoin.stackexchange.com/questions/96099/replace-by-fee-issue

Did you ever share the account login / private details with anyone else? (for example, you did this, and then changed password, added 2FA, etc)


text:
How would we know the real Satoshi?
Should Satoshi decide to reveal his or her true identity, how can one know the person is the real creator of Bitcoin, rather than a person who hacked the forum login, email address or the like? In other words, what methods of authentication did Satoshi use that could clearly identify him or her?

While this is not strictly a Bitcoin question, it does lead to discussion of techniques that are related to Bitcoin in terms of proof of identity.

He has a PGP public key which he can use to sign things.

Let's hope he didn't lose his hard drive on some electricity hiccup or something, then.

@AviadBenDov I'm sure he had it backed up.

If anyone understands that data doesn't exist unless it's in more than one place, it's Satoshi Nakamoto.

He can prove that he has the private key matching the address used in the genesis block.

Isn't that used to sign the Alert messages by the current developers?

@ThePiachu No. That's a different key.

The way it works is by the public/private key cryptography
Satoshi has shared his public key used to verify signatures here: https://bitcointalk.org/Satoshi_Nakamoto.asc
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.7 (MingW32)

mQGiBEkJ+qcRBADKDTcZlYDRtP1Q7/ShuzBJzUh9hoVVowogf2W07U6G9BqKW24r
piOxYmErjMFfvNtozNk+33cd/sq3gi05O1IMmZzg2rbF4ne5t3iplXnNuzNh+j+6
VxxA16GPhBRprvnng8r9GYALLUpo9Xk17KE429YYKFgVvtTPtEGUlpO1EwCg7FmW
dBbRp4mn5GfxQNT1hzp9WgkD/3pZ0cB5m4enzfylOHXmRfJKBMF02ZDnsY1GqeHv
/LjkhCusTp2qz4thLycYOFKGmAddpVnMsE/TYZLgpsxjrJsrEPNSdoXk3IgEStow
mXjTfr9xNOrB20Qk0ZOO1mipOWMgse4PmIu02X24OapWtyhdHsX3oBLcwDdke8aE
gAh8A/sHlK7fL1Bi8rFzx6hb+2yIlD/fazMBVZUe0r2uo7ldqEz5+GeEiBFignd5
HHhqjJw8rUJkfeZBoTKYlDKo7XDrTRxfyzNuZZPxBLTj+keY8WgYhQ5MWsSC2MX7
FZHaJddYa0pzUmFZmQh0ydulVUQnLKzRSunsjGOnmxiWBZwb6bQjU2F0b3NoaSBO
YWthbW90byA8c2F0b3NoaW5AZ214LmNvbT6IYAQTEQIAIAUCSQn6pwIbAwYLCQgH
AwIEFQIIAwQWAgMBAh4BAheAAAoJEBjAnoZeyUihXGMAnjiWJ0fvmSgSM3o6Tu3q
RME9GN7QAKCGrFw9SUD0e9/YDcqhX1aPMrYue7kCDQRJCfqnEAgA9OTCjLa6Sj7t
dZcQxNufsDSCSB+yznIGzFGXXpJk7GgKmX3H9Zl4E6zJTQGXL2GAV4klkSfNtvgs
SGJKqCnebuZVwutyq1vXRNVFPQFvLVVo2jJCBHWjb03fmXmavIUtRCHoc8xgVJMQ
LrwvS943GgsqSbdoKZWdTnfnEq+UaGo+Qfv66NpT3Yl0CXUiNBITZOJcJdjHDTBO
XRqomX2WSguv+btYdhQGGQiaEx73XMftXNCxbOpqwsODQns7xTcl2ENru9BNIQME
I7L9FYBQUiKHm1k6RrBy1as8XElS2jEos7GAmlfF1wShFUX+NF1VOPdbN3ZdFoWq
sUjKk+QbrwADBQgA9DiD4+uuRhwk2B1TmtrXnwwhcdkE7ZbLHjxBfCsLPAZiPh8c
ICfV3S418i4H1YCz2ItcnC8KAPoS6mipyS28AU1B7zJYPODBn8E7aPSPzHJfudMK
MqiCHljVJrE23xsKTC0sIhhSKcr2G+6ARoG5lwuoqJqEyDrblVQQFpVxBNPHSTqu
O5PoLXQc7PKgC5SyQuZbEALEkItl2SL2yBRRGOlVJLnvZ6eaovkAlgsbGdlieOr0
UwWuJCwzZuBDruMYAfyQBvYfXZun3Zm84rW7Jclp18mXITwGCVHg/P5n7QMbBfZQ
A25ymkuj636Nqh+c4zRnSINfyrDcID7AcqEb6IhJBBgRAgAJBQJJCfqnAhsMAAoJ
EBjAnoZeyUihPrcAniVWl5M44RuGctJe+IMNX4eVkC08AJ9v7cXsp5uDdQNo8q3R
8RHwN4Gk8w==
=3FTe
-----END PGP PUBLIC KEY BLOCK-----

Keys are created with
gpg --gen-key
gpg --list-keys

name.asc is the file file format for public key export you can get it like this
gpg --export --armor yourname > publickey.asc

He can then encrypt some file with
gpg --output document.sig --sign document.pdf

And all of us can check with his public key
gpg --import Satoshi_Nakamoto.asc
gpg --output document.pdf --decrypt document.sig

But only the he can encrypt files


text:
Why can't I connect to bitcoind on localhost?
The initial question asked was as follows, but it turned out to be nothing to do with keypools:

I had keypool=1000 before. Now I started bitcoind (the daemon version)
  with keypool=10000 option, and it is 2 hours already and bitcoind
  didn't start up yet. I.e. I still get error: couldn't connect to
  server when I try to do bitcoind getbalance.
Its a quite fast machine AMD 64bit 4000+ CPU with 10 GB RAM, how long
  the start-up time can be? And will it be so long every time I start
  the daemon, or only the first time?
Will future start-up times increase in any noticeable way if I keep
  keypool=10000 in comparison with 1000? Or any other performance
  degradation, except this first startup?

Edit: In the end it had nothing to do with keypool=10000. For some unknown reason my local interface was down. I fixed it with:
ifconfig lo up

I killed the bitcoin daemon with kill $PID, started it again and within a minute I could do bitcoind getbalance.

I don't know the answer. But I guess the slower startup is only the first time; after 10000 keys are generated, starting up should be quick.

I would believe it would slow Bitcoin down a bit when each block is validated, as the program will probably have to check each transaction for whether or not it matches every key in the wallet. I don't know how much slower it would go though...

@ThePiachu: If there is a hashset of all addresses, scanning the block for relevant transactions should take the same time no matter how many there are. Unless the addresses in the block itself are indexed.

My "Intel(R) Core(TM)2 Duo CPU     T6600  @ 2.20GHz" laptop just took 80 seconds to create 1000 new addresses, so I'm surprised you're seeing over 2 hours for 10 times that.
One thing I noticed is that the address creation is noticeable faster now than I remember it - so perhaps upgrading to a recent version of the client will speed things up for you.
Run "tail -f ~/.bitcoin/debug.log" to see a log of which key number it's currently creating.
Either way, the start up should only be noticeably slower the first time, when the pool is initially created.
Edit: (in response to miernik's comment)
The debug.log output will end with lines like the following while it's populating the keypool:
keypool added key 41, size=41
keypool added key 42, size=42
keypool added key 43, size=43
keypool added key 44, size=44
keypool added key 45, size=45
keypool added key 46, size=46
keypool added key 47, size=47
keypool added key 48, size=48
keypool added key 49, size=49
keypool added key 50, size=50

The stuff you're seeing is what happens while bitcoin is running normally.  It's receiving and responding to messages on the P2P network.  I don't know what to suggest as to why it isn't accepting RPC connections.  Could it be a firewall issue, or some other configuration problem unrelated to the keypool argument?

I've put the last 200 lines from debug.log here: http://dpaste.com/748342/plain/ Can you tell me which is the key number? How does such a line look like, so I can grep for it? BTW: its 18 hours already and still running.

In the end it had nothing to do with keypool=10000. For some unknown reason my local interface was down. I fixed it with:
ifconfig lo up

I killed the bitcoin daemon with kill $PID, started it again and within a minute I could do bitcoind getbalance.

For others that might be encountering a similar problem, here are some other issues that I ran into:
1) IP ports not being opened:
/sbin/iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT

2) Make sure that your cloud instance security settings allow for TCP connections on the appropriate ports.
3) If you have ssl enabled in the server, make sure that you created an ssl certificate:
https://en.bitcoin.it/wiki/Enabling_SSL_on_original_client_daemon
4) Make sure to kill processes as others have described:
ps -A | grep bitcoind
kill [PID]


text:
Vulnerability of Bitcoin Network
Hi all I was wondering if I am doin a wrong assumption here: Let's assume a dezentralized peer to peer network and the bitcoin protocol. If a full node changes a transaction within a block and then start looking for a suited nonce to fulfill the requirements and than win the competition: All other nodes would verify the block, due to the correct hash requirements. This would result in the fact that nodes can change transactions within a block after receiving them and than start their proof of work. All the other nodes would accept that block if the node is the fastest. Is this correct?
To conclude the question more precisely: after the fastest node has found a nonce for its false transaction block, will the other nodes verify only the hash value (which fulfills the requirements) or do they also verify the transactions in the block again?

Bitcoin funds are locked to a specific private key. In order to spend them in a transaction, the transaction needs to be signed with the private keys corresponding to each input. The signature commits to the exact content of the transaction. If another user changes the transaction, the signature is no longer valid. Other users cannot produce another signature as they're not privy to the private key.
Therefore your scenario fails in one of two ways: One, the attacker creates a fake transaction with an invalid signature. Every other node that verifies the block's content notices the invalid signature and rejects the block. Two, the attacker attempts to create a valid transaction with a different outcome than the original. He cannot, because he doesn't have the correct private key to produce the signature.
Remember that every node checks all details of each transaction and each block independently. Editing your node's database locally or changing the code that your node is running does not impact the behavior of other nodes.

Thank you for the more detailed explanation. What about an attacker is changing a transaction of his own, where he has the appropriate private keys of the inputs?

That is called a doublespend. If the original is already confirmed, it'll be invalid for trying to spend non-existent funds. If it's not confirmed, only one, the original or the doublespend can be included in a block.

I understand. Can you explain how or who is going to make the transaction invalid? Assuming all transaction have been confirmed and now the node is changing it afterwards with the appropriate keys and saying it is valid. Does the changed transaction again get verified  by the other nodes, or only a hash requirement is checked? (assuming the malitous node won the competition) This was btw my original question

Every node validates all information for themselves. If you change your code or database locally that doesn't change what everyone else is doing. Nodes validating transactions check whether the unspent transaction outputs (UTXO) consumed by the inputs are available and then mark those UTXO as spent. A second transaction using the same funds fails because the UTXO are unavailable for spending, they are already spent.

But the actual process is as follows: all nodes get every transaction, than the start mining the block. All nodes the same one. The first node that finishes mining will be the winner and send the block to all the other nodes which then validate the hash and the send block will be set into the blockchain by every node locally. Now the question is, if the other nodes check the transaction of the new arrived block again.

@frosk Yes, as you've now been told 3 times: every node checks every transaction in every block fully. The other nodes treat the incoming block as a new block they have not seen, so they fully verify it. There is nothing special about miners receiving blocks created by other miners: miners are nodes, and every node checks every block fully. Miners could choose to not do this by modifying their software, but it would be silly: they'd just risk building on top of an invalid block and see their energy spent on mining go to waste.

Note that different miners working simultaneously do not actually work on the same block. Each may have a (slightly) different set of transactions (as propagation of transactions is not perfect), and their coinbase transaction (the one that pays themselves the subsidy/fees) is of course different. Each has their own candidate block, but they have full discretion over what goes into it. Once they solve their candidate's PoW, they broadcast it, and hopefully for them, the network's nodes (including other miners' nodes) accept it after validating it.

Thank you guys for clarifying that. It really would be helpful if there is a clear procedure Diagramm of the life cycle of a block. Or the procedure of doing transactions, collecting transactions, mining blocks and committing block to blockchain. With at least several nodes.

after the fastest node has found a nonce for its false transaction block, will the other nodes verify only the hash value (which fulfills the requirements) or do they also verify the transactions in the block again?

Every full node fully verifies every transaction in every block independently. This is even true for non-mining nodes. If a block contains an invalid signature, it will be ignored by the entire network.
Miners do this too (including blocks produced by other miners), but not only because the protocol prescribes it. Miners serve the network, and if they mine blocks the network does not like, their efforts are wasted. Thus they are incentized to validate everything, and not risk building (or building on top of) invalid blocks.

Thanks pieter, it seems to me now you are facing my question. So can you tell me maybe a little more about the verification process in the cycle of a new block generation. So if the transaction arrives on every note it gets verified and kept in memory. After enough transactions have been collected they get promoted to the next block. Now every node is competing in finding the nonce. Here now a malicious node could change a transaction and try to find the nonce for this block containing an invalid transaction.

Will the new block again be verified according to its transactions or only according to its generated hash value before committing it

Please read my comment again and could you tell me when in the creation process the block gets verified?

And not just say it gets verified...

Every transaction in every block gets verified by every node. This has nothing to do with mining. Miners can build whatever blocks they like, but if they build a block with invalid transactions, their efforts are wasted. So they are incentivized to build valid blocks, and also build on top of valid blocks.

I am asking about the procedure: new transaction arrives at the node, then verified.... When the next block will be mined all transactions from memory will be taken to the new to be mined block and then mining starts. Now will there be a new validation afterwards by the other nodes or only the generated hash value check of the node that won the competition

Every transaction gets fully validated by every node. Not just their hashes: all the transaction details, including digital signatures. That includes miners. If they didn't, they could be tricked into building on top of an invalid block, which would make their electricity that went into hashing wasted.

If a block is in any sense invalid, no honest node will ever accept it, period. So producing a block that is invalid is pointless, a waste of effort.
Now say a block is just produced right now. Someone could, if they got lucky, quickly produce another block with the same block number as that block that has different transactions in it. This can even happen without anyone being malicious.
At this point, the network wouldn't know which of those two blocks to treat as valid. This is why exchanges wait for several more blocks to be produced before crediting anyone for deposited bitcoins.
Pretty quickly, it will be clear which of those two blocks wins. Nobody wants to mine on an alternate chain because they will never get to keep any of the rewards or fees. So every honest miner quickly cooperates to pick one of those chains and lengthen it sufficiently to ensure that their mining rewards do stick.


text:
Is it possible to reach same address in HD wallets?
Is it possible to reach same address (same private key) with different mnemonics and different derivation paths in an implant based on BIP32,BIP39 & BIP44 combination?

In theory it is possible to have a collision in this way. However in practice, doing so is basically the same as randomly generating new private keys and hoping for a collision.


text:
Get balance for an array of addresses with bitcoin core
I am searching for a command to get balance for imported addresses in bitcoin (not my wallet addresses) and I don't wanna do this with blockchain explorer API's. Is it possible to do this through bitcoin core? if not, is there any alternative option like bitcore?

You can use the scantxoutset command. This will scan the utxo set and return the utxos and the total balance for the addreses that you specify. Because it scans the utxo set, you won't have the transaction history for those addresses. But it does get you the balance and a list of utxos that can be used in a new transaction.


text:
How to get the time when a block is received at a node?
Is there any variable in the bitcoind code that records the timestamp when a block is received for the first time by a particular node? To be more precise, for transactions, transaction information returned by Bitcoind JSON RPC API contains timereceived. Is there similar field for blocks in the API?
There happens to be similar existing questions in stackexchange but none of them has been appropriately answered.

I don't believe this is exposed via the JSON-RPC API.
The easiest method would likely be to have a program monitoring debug.log and look for the best height update messages - they will be a few milliseconds off, since I believe those are only logged after block validation has succeeded, but it is likely the closest you can get to a per-node block receipt time, at least without monitoring the network traffic.

Thanks. In that last line you mention "without monitoring the network traffic". It would be great if you could elaborate on how to determine the timestamps when a block is received by monitoring the network traffic.


text:
Given OP_VER was never used, is disabled and not considered useful can its meaning be stripped and it be made OP_SUCCESS?
Given OP_VER (0x62) was never used onchain, is disabled and is not considered useful can its meaning be stripped and it be made OP_SUCCESS for the purposes of introducing a new different opcode in future?
As Andrew Poelstra describes "..there was an opcode called OP_VER, OP version. I can see some grimaces. It would push the client version onto the stack. This meant that when you upgraded Bitcoin say from 0.1 to 0.2, that’s a hard fork. Now script will execute OP_VER and push 0.1 onto the stack for some people and 0.2 onto the stack for other people. You’ve forked your chain. Fortunately nobody ever used this opcode which is good. "

BIP 342 does exactly this. (Thanks Pieter)

Since it was set to an error by Satoshi and not a SUCCESS, this would be a hardfork for all clients in-between no matter if this was already used onchain before.
Just imagine a miner with the new software (which redefines VER as SUCCESS) mining a transaction containing such an OP. All the clients between 0.3.5 and the new one would refuse the block, while all the updated ones would accept it: chain split.

This would be true if disabled opcodes were being made OP_SUCCESS for SegWit v0 spends but we are only making them OP_SUCCESS for SegWit v1 spends and future SegWit versions. Assuming Taproot is activated, unupgraded clients will treat SegWit v1 spends as anyone-can-spend whether they include a previously disabled opcode or not.

Yeah i assumed you were not talking about Segwit but raw Script OPs


text:
How are Bitcoin Core GUI nodes properly connected and disconnected in regtest mode?
I'm trying to set up a private Bitcoin network using Bitcoin Core in regtest mode. However, there are two problems:

the port reported by the Bitcoin Core GUI doesn't match the one the node is running at; and
when a peer is disconnected (or even banned) it re-connects automatically.

Here's what I did. I create two folders, alice and bob. I then launch the GUI from the OSX Terminal:
# start Alice node
$ open -n /Applications/Bitcoin-Qt.app --args -regtest -datadir=/Users/{username}/Desktop/alice/ -port=18444

# start Bob node
$ open -n /Applications/Bitcoin-Qt.app --args -regtest -datadir=/Users/{username}/Desktop/bob/ -port=18445

From Alice's Console, I do:
addnode 127.0.0.1:18445 add

This creates a connection to both nodes.
I want to disconnect both nodes from each other.
From Alice's Console, I use:
addnode 127.0.0.1:18445 remove

On Alice's node, the peer is:
127.0.0.1:18445
However, on Bob's node, the peer is
127.0.0.1:57594
but I expect it to be:
127.0.0.1:18444
I try to remove Bob's node from Alice with:
addnode 127.0.0.1:18445 remove
Console returns null but doesn't remove the node.
When I try this from Alice's node:
addnode 127.0.0.1:57549 remove
I get Error: Node has not been added. (code -24)
I then try to disconnect Bob's node from Alice's node using the the Peers tab. Right click on peer (Bob) and choose disconnect.
The node is disconnected for about 45 seconds, then reconnects.
To summarize, I have two questions:

Why doesn't the port number on Bob's node match the port number I gave it?
How can I keep regtest nodes permanently disconnected for arbitrary periods of time and then reconnect them?

I want to disconnect both nodes from each other.
From Alice's Console, I use:
addnode 127.0.0.1:18445 remove

This is incorrect. This command will only remove Bob's node from the list of addnode'd peers. The correct command to actually disconnect Bob's node is
disconnectnode "127.0.0.1:18445"

On Alice's node, the peer is:
127.0.0.1:18445
However, on Bob's node, the peer is
127.0.0.1:57594
but I expect it to be:
127.0.0.1:18444

Outbound connections are not made from the P2P port. Rather a random high numbered port is chosen to bind to and the outbound connection is made from there. IIRC this is done by the kernel and not the software itself. This behavior is standard for most software that make outbound connections.

I then try to disconnect Bob's node from Alice's node using the the Peers tab. Right click on peer (Bob) and choose disconnect.
The node is disconnected for about 45 seconds, then reconnects.

A connection is still being made because you did not remove the other node from both nodes (i.e. one node still has the other one in its peers database).
The proper way to do this would be to use the onetry option as that means that the node is not actually added to the peers database but rather tried once. To disconnect, you should be using the disconnectnode command.

0.15.1 has no disconnectpeer command. It does have a disconnectnode command. Using it, together with the onetry option for connecting did the trick.

Oh that's a mistake, I meant to write disconnectnode.

https://github.com/bitcoin/bitcoin/issues/6901
I found this issue, could be helpful
if you are not being able to remove address what about "setban {bob's ip} add {bantime}"

I also found that issue. It was helpful in that it shows how to disconnect/ban through the GUI. However, the peer always reconnects when I do so.

since thats a regtest, you can delete the alice and bob node and recreate again

Well I think a big problem might be in the lack of detail:
addnode 127.0.0;1:18445 add

Try 127.0.0.1:18445 instead you have a semicolon before the last 1.
Also have you tried editing this in bitcoin.conf? Try adding the nodes in conf.

Edited typo in post. No I have not tried adding nodes in bitcoin.conf. Why would doing so change the outcome?

Also added nodes in bitcoin.conf using both addnode and connect. No difference in behavior.


text:
What block had the most transaction fees? Why?
What block had the most transaction fees? Why? How big can transactions be? What's the largest transaction (size, in bytes)?

To this date (2024-05-31), the block with the highest transaction fees in bitcoins has been 409,008 which collected 291.533 ₿ in fees. This was caused by transaction cc45…c570d creating only one output worth 0.1 m₿ and failing to collect the change while using 14 inputs worth more than 291 ₿.
The block with the highest transaction fees in USD was 818,087 collecting 85.216 ₿ in fees at that time worth about 3,189,221.5 USD, which again was caused presumably by someone not collecting their change output in transaction b5a2…f9aa.
Transactions are limited to 100,000 vbytes by standardness rules, and to slightly less than 1,000,000 vbytes by consensus rules, i.e. a whole block minus the at least 145 bytes occupied by the coinbase transaction.
The largest transaction by weight is bb4…3e08 with a weight of 3,998,628 WU in block 364,292.
The largest transaction by raw size is ab03…2dad with a raw size of 3,992,821 bytes in block 839,842.

I am not sure which block it is, but you can see it on this graph from blockchain.info. It was ~305 BTCs in transaction fees. The blockchain will not tell you why the transaction fees are so high. It is probably an accident or a joke.
I believe the largest size a block can be is measured in terms of bytes, and it is 1MB. So the largest transaction can be as large as 1MB of data will let it be.

Okay... My question was which block, and which transaction...

I just found one by random searching. Over $1000 tx fee: http://blockchain.info/tx/70958529f1663c7c0e65176e719182f1d825ae6803aec4b18f7642c54fc9e4c5