When do the 0.5 BTC appear in Alices wallet?
It depends on the wallet software. Typically wallet software will show the BTC as appeared in her wallet as soon as the transaction is received by that wallet. It will be unconfirmed at that point, so it is potientially unsafe to spend the outputs in that transaction. Does she now posses the Output of transaction A? Because this is an unspent output. Only when she wants to pay her employee, she unlocks this output, such that the input of transaction B consumes the output of transaction A. Then, her empoyee "holds" the output of transaction B.
Is this the correct way? In my understanding, an input only consumes a previous output, when someone wants to make a subsequent transaction. This is why this picture irritates me a little, because it says "Alice receives"... But isn't she already the owner of the output, before the input of transaction B consumes the output of transaction A?
So, in my optionen: Alice won't unlock the 0.5 BTC in order to possess them, but in order to spend them.
Yes, that is correct. Alice does not have to do anything in order to receive the Bitcoin. Once Bob has created an unspent output that Alice can spend, she can say that she has received the Bitcoin. Of course, there is a caveat to this. Bob can't just make any output script that he wants that Alice can spend. There are a lot of output scripts that Alice could theoretically unlock and spent as an input in another transaction. However Alice is not tracking all of those things. Rather she has a specific set of output scripts that she can spend and she gives out addresses that correspond to those scripts. In order for Alice to consider Bob to have paid her, he needs to make an output with a script that corresponds to the address Alice gave him, otherwise Alice will not consider that transaction to be hers. |
|
|
|
|
This thread is so far off topic it is beyond rescue.
/locked
|
|
|
|
How can Nodes protect me from Double spending?
They don't really. What if i have like 10000 and ever more of Raspberry Pis at my home and therefore the maxm. no. of nodes in the network
There is no maximum number of nodes on the network. There is not and cannot be a maximum. wid all of them saying DOUBLE SPENDED transcation is the real one???
It doesn't matter. Double spends are resolved by miners, not non-mining nodes. The number of nodes doesn't matter. Would it mean, if i as i miner, successfully double spended my coins?
If you are a miner, you could double spend your own coins. Note that it isn't really a true double spend. You are not actually spending the same coin twice; rather you are simply spending the same coin in two transactions and only one of those transactions becomes final when it is included in the blockchain, presumably by you. However. double spending as a miner requires a significant amount of hashrate so the initial investment in mining hardware is very large and infeasible for most people. |
|
|
|
This topic has been moved to Trashcan. Duplicate |
|
|
|
you did not quite understand my question
This transaction has 237 bytes. (along with SegWit data)
double sha256 does not give the same result as on the blockchain.info.
But what needs to be done in such a transaction instead of double sha256 ?
Thanks.
PS
your link, unfortunately, there is no described algorithm how to get a hash
You did not quite understand my answer. A transaction is a binary format where each byte has a meaning. If you break up the bytes into the fields that they represent, and then remove the byte for the segwit data, concatenate the remaining bytes, and hash that, you will get the transaciton id. This is specified in what I linked; it tells you what fields need to be concatenated and hashed to get the txid. So with the transaction you provided, it can be broken down as follows: 01000000 - nVersion
00 - Segwit marker
01 - Segwit flag
01 - Number of inputs
0000000000000000000000000000000000000000000000000000000000000000 - coinbase prevtx (must be all 0's)
ffffffff - coinbase prev index (must be all f's)
45 - length of coinbase script
03b5c207fabe6d6de2bf72f174e206a0b32192a50518322f7c58fd1cc2c2f5ebc60a5ca93e7a12450100000000000000626508006c639309c00100bb91182f736c7573682f - Script
00000000 - nSequence
02 - Number of outputs
8180fb5000000000 - Output value in satoshis
19 - Length of output script
76a9147c154ed1dc59609e3d26abb2df2ea3d587cd8c4188ac - Output script
0000000000000000 - Output value in satoshis
26 - Length of output script
6a24aa21a9ed470198ecd62086bfb66b96ccf86004de9e00899b00de495fff200cbb17ba55c0 - Output script
01 - Number of witness stack items
20 - Length of item on witness stack
0000000000000000000000000000000000000000000000000000000000000000 - coinbase witness stack item (must be all 0's for coinbase)
00000000 - nLocktime
So if you remove the segwit stuff, you get: 01000000 - nVersion
01 - Number of inputs
0000000000000000000000000000000000000000000000000000000000000000 - coinbase prevtx (must be all 0's)
ffffffff - coinbase prev index (must be all f's)
45 - length of coinbase script
03b5c207fabe6d6de2bf72f174e206a0b32192a50518322f7c58fd1cc2c2f5ebc60a5ca93e7a12450100000000000000626508006c639309c00100bb91182f736c7573682f - Script
00000000 - nSequence
02 - Number of outputs
8180fb5000000000 - Output value in satoshis
19 - Length of output script
76a9147c154ed1dc59609e3d26abb2df2ea3d587cd8c4188ac - Output script
0000000000000000 - Output value in satoshis
26 - Length of output script
6a24aa21a9ed470198ecd62086bfb66b96ccf86004de9e00899b00de495fff200cbb17ba55c0 - Output script
00000000 - nLocktime
Recombining the bytes results in 01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4503b5c207fabe6d6de2bf72f174e206a0b32192a50518322f7c58fd1cc2c2f5ebc60a5ca93e7a12450100000000000000626508006c639309c00100bb91182f736c7573682f00000000028180fb50000000001976a9147c154ed1dc59609e3d26abb2df2ea3d587cd8c4188ac0000000000000000266a24aa21a9ed470198ecd62086bfb66b96ccf86004de9e00899b00de495fff200cbb17ba55c000000000
When that is hashed, the result is 2e5bdebe7d5a3bda6f173875cae1ffff2d5a6e84257cd9f5cf99f7f31e7741bb which then must be byteswapped because txids are displayed in reverse byte order. So byteswapping this results in a txid of bb41771ef3f799cff5d97c25846e5a2dffffe1ca7538176fda3b5a7dbede5b2e. |
|
|
|
|
I'm pretty sure this is expected behavior. Other versions exhibit the same behavior.
|
|
|
|
This transaction is a segwit transaction (all coinbase transactions for blocks containing segwit transactions must also be segwit transactions). So you need to compute the txid as defined in BIP 144. |
|
|
|
I will like to know is anything that block chain and bitcoin is solving that earlier was unsolved and blockchain technology is first in solving it.
What Bitcoin solved with the blockchain was the problem of other payment providers and digital currency systems being centralized and prome to being shutdown. Using cryptography and hashcash as a Proof of Work system had been used before in Chaumian Ecash and B-money. However those relied on a centralized servers to order transactions and resolve double spends. Bitcoin's primary innovation from those systems was a method to resolve the double spend problem without relying on a central source of truth. |
|
|
|
|
This thread got derailed, so it's being locked.
|
|
|
|
How do you verify such blocks?
You don't and just trust the miners that it is correct. That's the bcash model after all  But actually, to verify such blocks, you could do it in multiple passes. In each pass, you verify the transactions and skip the ones where the inputs are missing from the UTXO set. As you verify, the UTXO set is updated. Then you try to verify the skipped transactions again and so on. You would do this until there are no unverified transactions left, or until the UTXO set is not updated after a pass over the unverified transactions. At that point, all of those unverified transactions are invalid because their inputs are not in the UTXO set and the inputs are not from a transaction that is in the block. |
|
|
|
|
The wallet.dat file is a Berkeley DB file. It is the standard database file that the Berkeley DB library creates. In 2010, the Bitcoin software used BDB 4.7. So you should tell the forensics company that they should look for BDB 4.7 database files.
|
|
|
|
This is a big fat lie or misbelieve.
Bitcoin is carefully modified to only work in:
C++
Boost
Latest GNU C++ compiler.
This is completely untrue. Bitcoin Core does not use the latest C++ nor the latest boost versions nor even the latest gcc. Bitcoin Core currently uses C++11, but the latest is C++17. The current boost version used is 1.64 which was released more than a year ago. But using newer versions of boost should still work. It can also be used with different compilers such as clang and Visual C++. There are even instructions, project files, and a CI system for using MSVC and Visual Studio! Furthermore, building with clang is supported too. |
|
|
|
Thanks for you reply, but everything you said is already explained on my question.
Not really. You had a question about insight. I answered your question about insight and how you can run it locally without a third party service. Answering your last paragraph, yes, there's ABE.
ABE is not maintained. It is missing things like segwit support which makes it difficult to use with modern node software. |
|
|
|
You won't be able to run a block explorer if your node is pruned. Pruning throws away information that isn't necessary for the node to function (old blocks and transactions that have already been verified). However the point of a block explorer is to be able to see those data and explore them, so pruning is inherently incompatible. You will need to run a proper archival node (one which stores the entire blockchain) in order to operate any sort of block explorer. The Insight explorer uses the insight API which uses it's own backend node software called Bitcore. You can run that software, then install the insight API service, then the insight explorer. Otherwise you will need to write your own block explorer as I don't think there are any other maintained (and I'm not entirely sure insight is maintained) open source block explorer software. |
|
|
|
|
Your questions is pretty vague. What part of "going from testnet to livenet" do you need help with? Connecting to nodes? Conecting to bitcoind? Addresses? etc.
|
|
|
|
So litecoin forked coin is safe?
No. Litecoin, and every other coin that was forked from Bitcoin or pulled in new code from Bitcoin are vulnerable, unless they have also pulled in the fix. And if this happened, what solution can be used to fix?
Pull in the changes from Bitcoin Core. Sync a new node with that software. Once it reaches the invalid block, it will reject it. From there, start mining a fork. Once that has more work than the original blockchain with the invalid block, that will become that coin's blockchain. |
|
|
|
I have currently set my Core node to -prune=550, but I see that getblocktemplate returns data, so can one mine on the pruned node?
Yes, you can mine. With only 550 blocks stored, how can/would a pruned node make sure that an input given by user to be signed in a block isn't a double spend? There'd be no way to check that on such a node, right?
(E: Although i think there's probably a mechanism for this, otherwise it wouldn't be able to verify any transactions at all.)
That's not how Bitcoin Core works. Pruned nodes are still full nodes. They have validated every block in the blockchain; they still validate and relay every single valid block and transaction they receive. They are, by definition, full nodes. The difference between pruning and not pruning is whether the node can serve historical blocks to new nodes coming online. Everything else is the same; they can be miners, they will still receive all blocks and transactions, etc. The UTXO data that is necessary for validation is not pulled from the block history, that would be rather slow. Instead, when a block is validated, the UTXOs are copied to a UTXO database and the UTXOs that were spent are removed from that database. Pruning still keeps that database and all of the UTXOs, so validation is still works. |
|
|
|
That is hardly an explanation, we are talking about syntactic correctness here, not semantic.
A scriptPubKey can be preliminarily validated against this kind of mistakes that I described above, I was not expecting it to be run on its own because I know they only make sense concatenated together. However, errors like these can be caught up without actually running the script...
It is up to the transaction creator to ensure that their script is constructed correctly. There are tools available that let you do this. It is not the Bitcoin network's job to be your debugger. Further, any script is syntactically correct, even if it is "wrong". There really is no syntax. |
|
|
|
1) why it worked in the first place, doesn't the scriptPubKey go via the same validation rules as the scriptSig ?
Because the scriptPubKey is only half of a script. It cannot be executed. If it were, it would always fail because a scriptPubKey is just part of a script. Same with the scriptSig; it is just part of a script. On their own, neither can be executed and get a successful result. 2) why would bitcoind even care about the scriptPubKey of the UTXO i'm trying to spend, i thought it was supposed to just first run <scriptSig> then keep the stack and run <scriptPubKey> (which it may already consider valid...?)
The scriptPubKey defines the spending conditions, i.e. what needs to go into the scriptSig. It has to run the scriptPubKey to ensure that the scriptSig is correct. You can think of the scriptSig being the first half of a script and the scriptPubKey being the second half. On their own, they mean nothing and when executed on their own, they will fail. But concatenate them together, and you get a full script which can be executed. That is conceptually what script validation does. Before script validation, neither the scriptPubKey nor the scriptSig are considered valid. The scriptPubKey in an output can be anything, it is not and cannot be validated when it is created. There have been multiple instances of people putting random garbage in scriptPubKeys. Those transactions are totally valid and in the blockchain. It is just that the outputs are not spendable because attempting to spend them would result in an invalid script. |
|
|
|
|
Show Posts
