text:
Is it possible to store data privately into the bitcoin blockchain?
Given that Bitcoin is a public and permissionless blockchain, does this mean that any data stored in it will be free for anyone to see?
Is it possible to store documents such as screenshots etc.?

Possible duplicate of Is blockchain really secure to store sensitive data?

You can encrypt your data before you store it. However anyone would have access to the encrypted data and, if the encryption is broken (either now or in the future), the encrypted data will be revealed.


text:
Unable to createrawtransaction - “Input not found or already spent”
I need help. I have createrawtransaction as per the screenshot but then, unable to signrawtransactionwithkey, I have insert WIF Private Key and it state that "Input not found or already spent" - how do I overcome this?
Your thoughts?

You're trying to spend a 25.04826416 BTC output that was created by mining in May 2015, which was spent a few days after its creation: https://blockstream.info/tx/45fd1c838a56798fe027f61bdfdab83845399175a3b9cced397c5a38e669bb49?input:14
Even if you have the private key for the address that output used at the time, the coin can't be spent again.
I don't know what you're trying to do - but spending the same coin twice isn't allowed.

thanks for your feedback and checked on my behalf. First of all, that TxID was generated when I run the Blockhash in Console (Bitcoin Core), which is why I use that TxID to createrawtransaction in the first place. Well, I really have No Idea that it was created and spent on May 2015, maybe because of this, that my Bitcoin Core was still "running to connect" with peers it stated here that "Last Block Time: Fri May 8 00:29:33 2015 - I gues that explains why. How should I know what happen to this Txid in the past? But then, really thanks to you.

source: Stack Exchange

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

sort: votes


text:
How to create a transaction input from tx id of UTXO?
I'm in the midst of working this github --> https://github.com/karask/python-bitcoin-utils/blob/master/examples/spend_p2sh_transaction.py
Sorry as I'm not that good in this. I would like to ask the following:

Where can I create this "transaction input from tx id of UTXO"?  This is for Bitcoin UTXO.

I mean is it using bitcoin node? vscode? python in Gitpods? I just want to know where I can run this and able to provide me the TXID along with the Transaction value in it. Like for example snapshot below:

Care to guide me? Please.. Thank you in advance.

You don't create it; you have it. It's the txid of the transaction that created the output you're trying to spend. Without it, you don't have any coins.

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


text:
How to Create or Generate a New UTXO in Bitcoin Core?
I know how to use Console in Bitcoin Core but not that expert. I would like to ask is there possible for me to generate or create a new UTXO in Bitcoin Core?
All I have with me are the list of TxID which I have yet to use it. I don't know much about the right code for this.
Anyone can advise?
Thanks

Are you talking about creating UTXOs for testing purposes or how new UTXOs come into existence generally?

"Creating a UTXO" is the side effect of transacting. It's an abbreviation of "unspent transaction output"
A transaction in Bitcoin consumes a number of UTXOs, and creates a number of new ones, possibly assigned to new owners.
So the answer is: send BTC somewhere (possibly to yourself).


text:
BTC - Mining Vulnerability and Future Consesus
In order for changes to the Bitcoin protocol to be made, 95% consensus must be achieved, otherwise a hard fork would need to occur? Is this the primary reason why changes to the core protocol are so difficult to make?
With regards to consensus mechanism, moving aside whether PoW/PoS/Other is the proper solution, since the vast majority of voting belongs to large mining pools why would they ever vote for PoS or another non-mining solution? It seems even if a superior consensus mechanism exists it is highly doubtful BTC would ever deviate without a hard fork?
I've seen charts online breaking down the mining pool ownership percentage of BTC. I also know some pools have committed to cap their hash power and operations so as not to gain 51%. However, is it possible that a 51% attack could already be occurring and we have no idea? How do we know the mining operations aren't in collusion already and have not already been double spending, etc? If fraudulent activity occurs would we actually ever know?
Thanks!

In order for changes to the Bitcoin protocol to be made, 95% consensus must be achieved, otherwise a hard fork would need to occur? Is this the primary reason why changes to the core protocol are so difficult to make?

Not really - most recent changes have been made by using miner activated forks, which requires miners to vote on proposed changes. Only once a certain threshold is hit (which is very much configurable, and not fixed to something like 95%), the changes are activated.
That said, it is entirely possible to create upgrades without such voting - many other blockchains do it all the time. It's simply a matter of the community agreeing that those changes are valid and not an attempt at an attack.
Even with 95% of miner support, if the broader community feels that recent changes are not in their best interests (such as the somewhat contentious segwit changes), they may choose to fork the chain at a point before the changes (as done by Bitcoin Cash).
You may find the answers to How is Bitcoin governed by mathematics? to be of interest here. Consensus is very different from governance, and one does not imply the other.

With regards to consensus mechanism, moving aside whether PoW/PoS/Other is the proper solution, since the vast majority of voting belongs to large mining pools why would they ever vote for PoS or another non-mining solution? It seems even if a superior consensus mechanism exists it is highly doubtful BTC would ever deviate without a hard fork?

Personally, I'd agree with that - any attempt to reduce the power of miners may result in them attempting to protect it.
However, at the end of the day, if the broader community moves to a different fork, the value will follow it. Any miners left on the other chain will be subject to vastly reduced economic incentives (BCH vs BTC price and adoption being a good example).

However, is it possible that a 51% attack could already be occurring and we have no idea?

One could potentially be happening right now, and our ability to detect it would be limited.

How do we know the mining operations aren't in collusion already and have not already been double spending, etc? If fraudulent activity occurs would we actually ever know?

There are many research groups, exchanges, coin tracking firms, and other entities actively tracking such things - it is fairly easy to detect a double spend after the fact, especially if you were on the receiving side.
Additionally, a double spend attack on BTC would be very detrimental to the BTC price, which is not something most miners would be able to absorb. It is in their best interests to secure the chain, not attack it.


text:
transaction parts and identification
I'm making a reference document for bitcoin transactions using this transaction (its a random transaction).
hash:
it contains

I would like to add detail to each of the addresses but I'm not sure what all the parts are. What the components and how do I mark them like that bit at the beginning in red.

Isn't this a repeat of https://bitcoin.stackexchange.com/q/106798/13866 ?

yes but that was to see if I missed an all ready made document or similar and could simply use that rather than making my own. When I made this I had seen nothing that fit what I needed so Im making it, but I'm not confident that I'll do it right so I'm asking for some help on the specifics. To answer your question in the other page, word others need to see this and I don't trust them to be able to use anything else.  They are not very computer savvy.

So, are you really asking how to mark text in red in MS Word???? Surely not. It's hard to help as I find  the question a bit vague. Sorry.

exactly what Prayank said.

so I have used learn me a bitcoin quite a bit, but I have a problem. I think that I need just that last 8 characters for both p2pkh and p2sh's checksum, however I can't check that as I need the hexidecimal notation for everything I can find I don't have a means of converting it back. I think I just don't know where to find the hexidecimal version of the address. Which I could then use to generate the checksum for confirmation. I would then label both the main address and check sum in blue and green respectively along with descriptions


text:
how do bitcoin nodes detect a transaction?
I have a number of question about bitcoin but I was ask to do specific research on two questions and I figured this would be a good place to start. The first I have answered already the second is: "what is the protocol or code used to identify BTC addresses from other activity on the web?". I'm honestly not sure this question even asks for the correct information but if any of you could answer or point me in the right direction that would be much appreciated.

Does this answer your question? How transaction happen in blockchain?

It clarifies the question. How does the internet/nodes/ISP know where to send and what is a bitcoin transaction? specifically if you have a paper wallet you need software to write down and store the information to be printed and then translate that back into something the system understands. what is that? what is it called and how does it work? I think its just regular internet protocol but i don't know. relatedly, your wallet is listening for after you make a transaction for those that are "published" how does it disseminate between bitcoin communications and other internet chatter?

Does one of these answer your question: https://bitcoin.stackexchange.com/q/3536/5406, https://bitcoin.stackexchange.com/q/32237/5406, https://bitcoin.stackexchange.com/q/70621/5406


text:
What are the best practices for managing empty, unwanted wallets?
If I have a deterministic wallet which previously held bitcoin but is now empty and is no longer needed, what information should I keep? I think there are three options:

keep nothing
keep the master public key only
keep the seed phrase

I can think of some implications of the options:

If I don't keep the seed phrase, any funds accidentally sent to an address associated with the wallet will be lost forever. This becomes even more likely if the master public key is kept, as new addresses can still be generated for the wallet.
If I keep anything at all there is a potential privacy leak waiting to happen if the details I kept fall into anyone else's hands, so over time I'm stuck with an increasing quantity of mostly useless information to keep secure.
If I may need to prove the wallet was mine later on (e.g. to a tax authority claiming I sold coins when I was really just moving them around between my own wallets):

I probably need the seed phrase to show this unambiguously.
Having just the master public key might provide convincing if not bulletproof evidence the wallet was mine.
Pointing to a chain of transactions terminating in non-empty wallets I still control might prove what's necessary without needing any information about the old wallet at all.

What are the best practices here? Does it make a difference how much bitcoin was held in the wallet and how long for? Compare, for example, a cold storage wallet which is being retired vs a wallet created with a negligible amount of bitcoin to play around with a new piece of software.

First off, you should consider if you actually need to abandon your current seed phrase. Reasons for that include:

Your seed phrase has been compromised. In this case you need to move your funds to a safe wallet as quickly as you can before someone steals them.
Your master public key has been leaked. This means any past and future transactions done using this seed phrase will not be private anymore. (Wallets using hardened derivation do not permit a master public key, some permit account-level extended public keys which only generate addresses for a single account. If an extended public key leaks then you can usually just stop using that one account.)
You are moving to a higher-security solution (e.g. from a software wallet to an air-gapped hardware wallet) and thus need to also replace your seed phrase that was previously generated in a less secure environment.
You are moving to a wallet or backup system that is incompatible with the previous seed phrase (e.g. from a single BIP39 seed phrase to a 2-of-3 Shamir backup).
You've sold all your bitcoin and have no plans of coming back.

If you've determined that you will not be using this seed phrase going forward, then I would argue you should either keep the seed phrase or keep nothing at all. Keeping just the master public key will not protect you from any dangers compared to keeping the seed phrase, as the knowledge of either is now (with the wallet empty) merely a privacy leak and does not conclusively prove ownership. And as you've mentioned, keeping just the public key increases risk of accidentally burning funds.
So here are some reasons that come to mind to keep the seed phrase:

One or more of the associated addresses is or was at some point publicly available (like a public donation address). Even if it has been taken down, it's still possible that someone has saved it or reposted it elsewhere and in case it receives some coins you will want to be able to spend them.
You want to keep a backup of all transactions that have happened in the wallet. Again, this is mostly just for you, as a seed phrase does not conclusively prove ownership (especially for an empty wallet).
There are local laws and regulations that might at some point require you to submit a non-conclusive proof of ownership for that wallet. (Some countries currently require such "proofs" for withdrawal addresses.)

Personally I would hold on to any retired seed phrase unless it was only used to play around with a few sats. The storage requirements for a seed phrase of an empty wallet are much lower than for an actively used wallet, and you are probably safe keeping them all in one place, so it shouldn't take much effort.

You bring up issues I had not considered.
Which lead me to conclude the Seed Recovery phrase (mnemonic + passphrase if used) should be retained.
If non-standard derivation paths, big address gaps etc were used (bad idea) then also keep notes of those to save the efforts required to recover. Also dates and wallet client(s) version#s.


text:
How can I reproduce the output of lightning-cli newaddr?
If I do:
lightning-cli newaddr

I get an on-chain address I can send funds to. How can I see the same address again, if (for example) the terminal gets closed by accident before I've finished with it?
A motivating example: I do a newaddr and create a transaction to transfer funds to that address. I spend five minutes messing around with my hardware wallet to sign it. Before I actually broadcast the signed transaction, I'd like to double-check the destination address is correct, but it's no longer visible.
As a more general follow-on question: is there any way to see the on-chain addresses for Core Lightning's wallet and their balances? Something a bit like Electrum's "Addresses" tab, for example.

If you build CLN with the developer options (most likely you did), then you have the dev-listaddrs command that you can use to list all addresses that have been generated.
It's a developer only command for now, since the format hasn't been formalized yet, but it has remained stable for quite some time:
https://github.com/ElementsProject/lightning/blob/f158b529d3e4c56b70c44aaebc821c1f15477fa2/wallet/walletrpc.c#L226-L234

As a more general follow-on question: is there any way to see the on-chain addresses for Core Lightning's wallet and their balances?

To see the balances, yes, you can. When funds arrive, you will see that balance change. But in terms of the on-chain addresses, no, technically, core-lightning wallet doesn't have that feature AFAIK.
Then, based on your question how do you check the addresses?
Here is something useful.
Here's a link!
In short, it is different from any common BIP standards implementation.
I encourage you to check that article out and play around with the https://iancoleman.io/bip39/
Hope that answers your question.

Thanks, that's a really interesting thread!


text:
How can Bitcoin Cash be blocks ahead of Bitcoin SV
After the Bitcoin Cash & Bitcoin SV fork, Bitcoin Cash is happy to be "ahead" of Bitcoin SV, but how is this possible? aren't blocks supposed to be mined constantly every 10 min?

Solutions to the proof of work are found randomly (by guessing until you find a valid block hash). So, the difficulty is adjusted in order to set an average block time of 10 minutes, but that is not always how it happens in practice.
Also, when the total network hashpower grows before the difficulty is recalculated (which happens every 2 weeks on Bitcoin), blocks can (and are) solved at a faster rate than every 10 minutes. The same applies in reverse, less hashpower will cause block times to increase above 10 minutes (until the next difficulty retargeting).

I think the Bitcoin Cash DAR adjusts faster than 2-weeks (more of a rolling avg of the last 12 hours).


text:
Where should I get rpcuser.py from?
I am following the instructions in my bitcoin.conf file, it writes:
It is set at intialization time
# using the output from the script in share/rpcuser/rpcuser.py after providing a username:
#
# ./share/rpcuser/rpcuser.py alice

However, I can't finde any rpcuser folder or rpcuser.py file. Am I supposed to have them? Is this normal? I already ran
sudo apt-add-repository ppa:bitcoin/bitcoin
sudo apt-get update
sudo apt-get install bitcoin-qt

So, if I don't have the file, where should I get it from? Does this mean my bitcoin installation is incomplete? I havent synced all the blockchain yet..
Anyway, any advice is welcome.

There is no rpcuser.py script anymore, it is now named rpcauth.py (the ppa may not be up to date). This file can be found in the Bitcoin Core source code repository: https://github.com/bitcoin/bitcoin/blob/master/share/rpcauth/rpcauth.py


text:
Validate Bitcoin address using Javascript
I know there is a similar question but its 7 years old and the answer doesn't work. Now, many things have changed, including the addresses themselves. So, is there a js library I can trust that can validate addresses on 2021

Use bitcoinJS's https://github.com/bitcoinjs/bitcoinjs-lib/blob/27a840aac4a12338f1e40c54f3759bbd7a559944/src/address.js#L101 toOutputScript function in a try-catch block

Looks fine but I can't load the script address.js Uncaught ReferenceError: exports is not defined. Have you used it before?

Here's an example: https://github.com/ilyavf/tx-builder/blob/4185f6c9614832b67d087eb561237e4dd3883e76/src/tx-builder.js#L9-L84


text:
What is the actual Bitcoin block size? 2mb or 1mb?
I am not asking about block weight. I hear many people saying that the actual Bitcon block size is 2mb. However, in any block explorer, I can see that blocks are around 1200kb. This is very confusing, where is the cap?

In actual block explorers you can also occasionally see blocks larger than 2MB.

The cap on the block size excluding witness data is 1000000 bytes.
There is no cap on block size including witness data. Instead, there is a limit on the block weight at 4000000 weight units. Depending on the composition of the block, 4000000 WU can correspond to anything from 1000000 bytes to close to 4000000 bytes (including witness data).
But a block with 4000000 WU is "full" - regardless of whether it's 1 MB or 3.8 MB of data.

Why at 4000000 specifically? If that was chosen by consensus fork, why that number?

The factor 4 for weight/ood byte was chosen as a tradeoff between encouraging UTXO consumption and enabling more network bandwidth. The limit 4000000 must be exactly the chosen factor times the old 1000000 limit, or it wouldn't be a soft fork (we must guarantee that every valid block without witnesses still stays below the limit).


text:
Transactions without signatures?
Do all transactions require a siganture to be broadcasted and signed or is it possible to have a unsigned transaction be mined?
Could you not just use op codes to allow a transaction to be validated without a signature?
Such as making the scriptsig OP_true?

Transactions do not require a signature to be valid. Signatures are just a way of ensuring that the transaction is not going to be spent by anyone, but just by the person who holds the correct private key and therefore, is able to perform a valid signature.
Here you have an example of a transaction spent without signature. tx1 is a transaction spending from a P2PKH address and creating a P2SH output that requires an OP_TRUE to be spent. tx2 is a transaction spending from tx1 by just providing that OP_TRUE (51)

Do all transactions require a siganture to be broadcasted

No. Bitcoin does not require that valid transaction must have signature verification.

So why would you get an error like script not push only if you try to broadcast a unsigned transaction?

The fact is: some transactions do not contain signatures and still valid. This does not mean that arbitrary transaction without signature is valid

Could you give me an example of a transaction like that which has been mined?

https://blockchain.info/tx/fdce158d8d9ef51b3fc53d7569f5448ffaa8a28be25992fbb060a36a4715a34c?show_adv=true

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


text:
How can I calculate how long it took a transaction to be confirmed?
Is it possible to calculate - or even reasonably estimate - how long it took for a transaction to be included in a block after it was first created?
I'm asking about already confirmed transactions which are already included on the blockchain - and all transactions - not just ones that belong to me.
I am currently building a project which scrapes a given blockchain for whatever info/attributes a user desires. You can check it out here - be warned it's no where near ready for production and not even at version 1 yet - but the develop branch is getting close.
As I understand from the docs and the answer to this question the time received attribute is not, as some may think, the time a transaction was "received into a block" but rather the time when my client first noticed the transaction - this attribute is also not available when using getrawtransaction. So that's a no-go.
Ideally, I'm looking for the time that a transaction is created (sent) and the time it is included (confirmed) on a block.
Based on the above info my idea is:

for new (unconfirmed) transactions we record the time that my node
first notices the transaction
then we record the time that my node
notices it is confirmed

This would at least give me an indication as to how long it takes newly created transactions to be confirmed. Of course latency adds a huge amount of noise here, but it's at least a step in the right direction!
I would like to do this for existing, confirmed transactions if possible.
Thanks for your time.

I have been running a full node for some time now to extract a proxy for this information by keeping a real time tracker of transactions going through the raw mempool, adding a time stamp when my node first saw the transaction ID and then computing the time difference after the transaction has been included in a block...I do not see another way which would make it possible to determine the waiting time ex-post, e.g. after the transaction has been included in a block without tracking the raw mempool.

Unfortunately, at least for bitcoin and litecoin (and likely most bitcoin derivative block chains), the only way to get this information is to have a node/client listening at the time the transaction appears on the network.
Otherwise your client will simply use the block's timestamp for each transaction.
This design means that getting this information is only possible if using a third party who was maintaining a copy of the blockchain at that time, or potentially getting a dump of a trusted source's blockchain which should (I believe, although I haven't tested it myself) maintain the original client's timestamps.
Would be great if someone could confirm this. I will myself if I get the chance to test it but that might not happen any time soon.

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


text:
What is the relationship between the Digital Signature and the Public Key
So, I can see this is in the unlocking script:
<Cafe Signature> <Cafe Public Key>

Taken from mastering bitcoin. What is the difference between the two? I don`t find it easy to google.

They are very different. If you look at their byte values, you will notice that they are different lengths and have different formats.
In essence, public keys are identifiers and signatures are cryptographic proofs.
A signature is produced by taking a private key and a message and performing a signature algorithm with those two pieces of data as inputs. For Bitcoin, we use the Elliptic Curve Digital Signature Algorithm (ECDSA). In Bitcoin, the message is a modified version of the spending transaction.
A public key is derived from a private key and can be broadcast publicly. It is used in the verification algorithm for ECDSA to verify that the private key for that public key was the one that produced a signature for a given message.
So the signature is a proof that the private key for the specified public key endorses are particular message. In Bitcoin, it means that the owner of the private key approves that spending transaction.
Additionally, signatures are generally one time things. They change with the message. You can also get two different signatures for the same message and private key combination. Those two signatures will still be valid and are valid independently. Conversely, public keys (and private keys) are permanent. They don't change unless you replace them.


text:
Can a miner just download the blockchain once and then delete it (don't have a full node)?
I am wondering if all bitcoin miners need to be full nodes. Or is it possible for a miner to just download all the blockchain once, do all necessary computations to start mining and then delete the complete blockchain and only work on the "last blocks". I.e can a miner don't be a full node?
This is not a duplicate question.

no - he can't. A miner would want to receive transactions from other clients, to create new blocks. He would need to verify these tx, and therefor the blockchain is required.

If miners delete the blocks data, someone can fool them by sending a transaction that spends money it shouldn't be able to. In principle, some of them could do that and trust the other miners to validate transactions, but the more people do that, the more the whole network is vulnerable to fraud.
The same can be said for non-miners. If you don't run a full node, you're not actually running Bitcoin, but trusting people that run it to verify transactions for you.

Of course that's possible. A miner may be using SPV / keeping only the block headers*. The downside of this is that such a miner won't be able to include transactions of people s/he doesn't trust (i.e. not a trustworthy friend of the miner)
If that miner wants to take risk, s/he can verify the transactions that were relayed to him using online block explorers.
*: A miner doesn't even need to keep block headers. If he knows the previous block's hash, timestamp and network difficulty, that's enough.

I'd like to vote this answer up but I can't cause I have no reputation. One question, what is SPV? If you can please vote up my question.

https://bitcoin.stackexchange.com/a/4651/38618


text:
How much does it cost to depend a transaction to another one?
How I can depend on a transaction to an unconfirmed transaction?
How much does it cost?
Do I need to use a specific API or application?
Thank you

What do you mean to "depend on a transaction"? To create a transaction that is child of another?

See OP's previous question for clues to what OP might mean.

How I can depend on a transaction to an unconfirmed transaction?

In order for a transaction to "depend" on an unconfirmed transaction is simply the act of creating and broadcasting a transaction that uses UTXOs that are unconfirmed and not yet in a block. Most wallets don't let you do this.

How much does it cost?

There are a lot of factors that can affect the cost of a transaction, but assuming you aren't doing anything weird the cost of the transaction should be roughly the same as any other transaction.

Do I need to use a specific API or application?

I don't believe API's will let you do this... The action you are describing is usually done by developers who build the raw transactions to test wallets and other cases.


text:
transaction layout
I want to make a reference document that shows a full bitcoin transaction with brackets or lines to indicated each different part of the transaction. Then add a description of each part below the image and how you determine where each part begins (ie. address and checksum). I'm sure most (maybe all) of this has already been done but Im having trouble find them. Could anyone point me in the right direction?

Does this answer your question? Why raw Bitcoin transaction are in hex format? Answers there point to resources such as https://bitcoin.org/en/developer-reference which break down the raw transaction format

not really. I was thinking something more like a block explorer image but with something that breaks up the address for more details. those might be useful for the description but mostly i need the overview right now.

Take a look at https://learnmeabitcoin.com/ maybe

What tool are you using to make your reference document? Notepad?, Word? an HTML5/CSS3 editor? Wordpress, some PDF toolchain? Markdown? PHP? C# ?


text:
Explanation of "Timestamp Server" section in original bitcoin paper
I'm trying to understand the "Timestamp Server" section in the original bitcoin paper. It feels overly short for someone without an understanding of cryptography.
Is it saying?

A block includes:

The block itself
The time the block was created
A hash of the previous block

When a new block is created:

This block includes the current time and a hash of the previous block
The hash of this new block is broadcasted to all nodes

There is little information online trying to research the concept of "timestamp server".
Apologies if this is a silly question. As a software developer I'm trying to understand how this works on a granular level.
Source:
From the original paper, Bitcoin: A Peer-to-Peer Electronic Cash System.
3. Timestamp Server
The solution we propose begins with a timestamp server. A timestamp server works by taking a
hash of a block of items to be timestamped and widely publishing the hash, such as in a
newspaper or Usenet post [2-5]. The timestamp proves that the data must have existed at the
time, obviously, in order to get into the hash. Each timestamp includes the previous timestamp in
its hash, forming a chain, with each additional timestamp reinforcing the ones before it.

Is it saying ...

I think you have it right except that for 2.2. the whole new block is broadcast not just the hash.
Actually "broadcast" isn't exactly the right term really. I believe the node transmits the new block to a small number of peers (e.g. ten or so other nodes). These other nodes then pass on the new block if it looks OK to them. Eventually the new block reaches all nodes in the network.
In a comment below, Pieter Wuille has clarified some of the details, "Blocks are announced to all peers. Those peers then fetch the actual block from (typically) the first peer that announces from them."
I haven't found an explicit detailed description of the exact sequence of network actions, but if you read The Bitcoin Wiki's Protocol documentation you'll see that there are many message types and one of them is inv  (inventory)

Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to getblocks.

The inv payload includes an array inv_vec[] which contains a code for a type of data available (e.g. block) and a hash of that data.
So the recipient of that message could presumably see that the sender has one or more blocks that the recipient doesn't and could presumably then issue a getdata message to obtain that new data. As I said, I haven't yet found a detailed explanation of the exact sequence of operations but I imagine the reality is along these lines. So my description of this as broadcasting new blocks is a simplification.

There is little information online trying to research the concept of "timestamp server"

As you evidently know, but others might not, what Nakamoto was describing, under section 3. Timestamp Server, is an activity that we would now refer to as mining.

Blocks are announced to all peers. Those peers then fetch the actual block from (typically) the first peer that announces from them. This can be done through a number of mechanisms, but new blocks announced at the tip, modern Bitcoin Core nodes (0.13 and up) use compact blocks, see BIP152.

@Pieter, thanks for the clarification. I have accordingly updated the answer a little and might do so again when and if I think I understand the details better.


text:
Unconfirmed btc transactions
Reason - Due to unconfirmed inputs.
Can someone please explain what this means and could the sender do this intentionally. In other words to scam someone.

If there are three addressess A, B and C and someone sends a transaction tx1 from A -> B and another one tx2 from B -> C that spends the exact same coins (tx2 input is tx1 output) then tx2 cannot be confirmed until tx1 is confirmed.
Yes someone could trick you to accept an unconfirmed transaction as final and then send the same coins elsewhere (with a higher fee). That’s why you should not consider transactions final unless they are confirmed with at least a few confirmations (6 used to berecommended)


text:
How can government "seize" bitcoins?
Last year the U.S. Department of Justice posted this press release claiming U.S. "law enforcement seized several thousand Bitcoins on November 3, 2020."
How is it possible for anyone to "seize" BTC?
My understanding is that it is technically impossible to transfer BTC without the private key for the wallet holding BTC.  And likewise that anyone with the private key can transfer the BTC if they can transmit the transaction.  I.e., short of coercing whoever has the private key to disclose it, is it true that no amount of force or authority can cause or prevent the transfer of any particular BTC?
Or am I missing something?

Informally: the same way they "seize" cocaine or other non-bureaucratically-administered property?

This article suggests they just "convinced" the person who had the key to hand over the funds: https://www.wired.com/story/feds-seize-billion-stolen-silk-road-bitcoin/

UK answer: https://wiki.openrightsgroup.org/wiki/Regulation_of_Investigatory_Powers_Act_2000/Part_III you can be compelled to disclose the key, or jailed.

They can convince people to give the private key: https://xkcd.com/538/

"with guns".  how else does a government convince anyone to do anything?

Does this answer your question? How did the FBI "seize 260000 BTC"?

It is not necessarily true that no amount of force or authority can cause or prevent any transfer of Bitcoin. The protocol does not allow arbitrary seizures or blocking, but there are still human factors involved.
Bitcoin is decentralized, so there is no central authority that governments can go to (or coerce) to force or disallow transactions. However Bitcoin is still owned by people, and people can be forced to perform certain actions that they do not necessarily want to do. While a government cannot command the Bitcoin network to make a transaction to happen, they can go to a particular individual who owns Bitcoin and coerce them to make a transaction
Furthermore, governments often have the power to arbitrarily seize assets owned by people. They can do this by force and physically taking things away. This is often how Bitcoin is seized - the hardware that contains the private keys is physically taken by the government. Once they have access to the private keys, the government can perform any transactions that they wish. There is nothing that Bitcoin can do to prevent this; it is up to the individual to ensure the security of their private keys.

For disallowing transactions, this is much harder. However, as before, there is still a human factor involved. In this case, it's miners who produce blocks. A government could mandate that miners operating in their jurisdiction are not allowed to create blocks containing certain transactions. If all miners were to follow such mandates, then a transaction could remain unconfirmed indefinitely and thus be effectively disallowed.
However this is much harder to do. The decentralized nature of mining means that miners who are in other jurisdictions that do not require censoring certain transactions can mine those transactions. Furthermore, miners who can protect their anonymity and are willing to break some laws can mine those censored transactions too.
Even if no current miner is willing to mine a censored transaction because their governments threaten them, more people could simply begin to mine who do not necessarily follow the same censorship requirements. Mining being decentralized allows anyone to be a miner, albeit at a high initial cost currently. Governments could also try to snuff out the non-censoring miners through force, possibly through seizure or destruction of mining hardware. But even so, people will still be able to mine, and there will inevitably be some miner out there who is willing to make a block that includes a transaction censored by every other miner. So in the end, it really is not possible to disallow a transaction.

"willing to make a block that includes a transaction censored by every other miner. " I smell fork.

Which is also a good reminder to never keep your private keys unencrypted and never give them "obvious" names. Multiple distributed fully encrypted hard drives with plausible deniability Veracrypt volumes is probably the best option.

I guess if you convince enough miners of censoring, you can have them also censor blocks by non-compliant miners which contain such transactions, i.e. don't build more blocks based on such censored blocks. (Which might result in a fork, depending on the distribution of miners.)

@JonathanReez The people who are most likely to have coins the government would like to seize are the people least likely to be able to do this. Governments are typically most concerned by people who are actively involved in illegal transactions, and actively transacting requires keys to be readily available at the time of transaction. Law enforcement have been known to choose the time they arrest suspects to be precisely when they know them to be transacting, to maximise the chances that keys are available.

A lot of bitcoins reside in a trading platforms or online wallets. These bitcoins are (in the particular bitcoin sense) controlled by the platform. The government (provided the platform/wallet is in a favorable jurisdiction) may simply issue an order that requests the funds to be blocked or transferred to a government-controlled account.
The ordinary bank accounts are seized in the same manner.
In a lot of other cases there is a hardware / storage / printed paper containing the key that the government puts its hands on. The funds are quickly moved to a government-controlled wallet in order to prevent the previous owner transferring them elsewhere using another copy of the key.
p.s. I know of at least one government that obtained the keys and failed to move the funds in a timely manner. The funds disappeared.

Can you give more information regarding your anecdote?

Bulgaria, few years ago. I don't seem to find English sources, but use your favorite machine translator https://bivol.bg/mvr-zdoi-bitcoins.html. Some of the info here https://www.selec.org/a-total-of-8-4-tons-of-marijuana-seized-following-a-joint-investigation-supported-by-selec/?highlight=bitcoins . It is not absolutely clear if the money amount (BTC 200000) is grossly overestimated in the first place, stolen by a corrupt police employee, or just repossessed by the criminals using a copy of the key.

That's $10bn worth! Holy cow!

Other answers have covered how/if this is possible in theory, but you may be interested in how it actually happened in the specific case you mentioned. The press release links to a PDF of the Complaint For Forfeiture, which includes these paragraphs (bold added by me):

Individual X, whose identity is known to the government, was determined to have been involved in a transaction that related to
1HQ3.
According to an investigation conducted by the Criminal Investigation Division of the Internal Revenue Service and the U.S.
Attorney’s Office for the Northern District of California, Individual
X was the individual who moved the cryptocurrency from Silk Road.
According to the investigation, Individual X was able to hack into
Silk Road and gain unauthorized and illegal access to Silk Road and
thereby steal the illicit cryptocurrency from Silk Road and move it
into wallets that Individual X controlled. According to the
investigation, Ulbricht became aware of Individual X’s online identity
and threatened Individual X for return of the cryptocurrency to
Ulbricht. Individual X did not return the cryptocurrency but kept it
and did not spend it.
On November 3, 2020, Individual X signed a Consent and Agreement to Forfeiture with the U.S. Attorney’s Office, Northern District of
California. In that agreement, Individual X, consented to the
forfeiture of the Defendant Property to the United States government.

A person who the government is not publicly identifying gained control of Silk Road's private key and used it to steal cryptocurrency. Then in 2020 that person voluntarily turned it over to the US government.
What coercion made have been applied we can only speculate, but it's clear there was no special technical means of seizure applied in this case.

You said yourself: " I.e., short of coercing whoever has the private key to disclose it..." And that's exactly how a government can seize bitcoin, or how an unscrupulous criminal can get hold of your bitcoin.
And a government may just be happy destroying your wallet. If they catch a drug dealer who has a million dollars in bitcoin, few governments would need the money. Taking it away from the criminal might very well be enough.

If you just "delete" a wallet (e.g. by destroying a notebook), you can't be sure  that it's actually destroyed – there might be a backup copy somewhere else. If you actually get the private key, you can either get the bitcoins, or at least transfer them into a black hole (if you don't want them yourself).

@PaŭloEbermann: what is a "black hole"?

A bitcoin address for which no private key exists (or at least, none is known). This way the money is actually "destroyed". I'm not sure whether this is recognized terminology, I just made it up.

Two possibilities have already been discussed:

If the bitcoins are in a wallet on your computer, the government must acquire your private key, e.g. by

physically seizing your laptop and forcing you to disclose the password
physically or remotely installing spyware on your laptop to get your wallet and password
forcing Microsoft to install such a spyware through Windows Update
...

If a third party is managing the bitcoins for you (e.g. a trading platform), the government can seize the bitcoins from there without needing to interact with you

But there is a third, much more general possibility: The government controls the interface points where bitcoins are traded for goods or other currencies, and can simply forbid them from accepting your bitcoins.
The government can publish a list of seized addresses and declare that any address that receives seized funds will be automatically added to the list, and anybody who accepts seized bitcoins in exchange for goods, currency or crypto will be charged with money laundering.
The blockchain is by its very design a public ledger - this means that every single transaction that has ever been recorded is visible online. This is a dream come true for the government. They can completely monitor the flow of funds and automatically tell whether a transaction includes seized funds. They can publish free tools that tell anybody who receives a bitcoin transaction whether those funds were legitimate, and if not, to transfer those funds to the government.
Currently, the amount of money that is being laundered through bitcoin is relatively minuscule, so no government has implemented such a system yet, but I'm convinced that they will once this becomes a significant problem.
The government is serious about money laundering, and cryptocurrency just provides the ideal technical basis.
Once a government system like this is online, I predict that seized bitcoins will still circulate and be traded among users. They will be exchanged and traded on a "black market" that ignores the government rules (probably because they're in some tax haven jurisdiction outside of EU/US influence), but these seized bitcoins will be traded at a much lower value.
The government can also discourage miners from processing transactions that involve seized addresses by automatically seizing the mining reward of blocks that include such. It will be economical for miners to occasionally process seized transactions, but the confirmation times will be much higher.
The legal frameworks of various jurisdictions may or may not allow this form of seizure, but they will be adjusted according to the technological development.

I'm a final-year law student.
In order for government to seize your Bitcoin, firslty there has to be some kind of legislation that recognizes Bitcoin as property;  secondly, seizures normally occur in cases of fraud, insolvency, and tax evasions where the Taxman attaches tax owed to your valuables.
Currently most countries only have policy issued by the central banks.  Those policies are just persuasive sources (you can disregard them if you like)
In short, your Bitcoin cannot be taken by the government if not recognised firstly by government as property that can be bought and sold, only the proceeds or profit made when selling bitcoin for i.e. dollar or buying company shares, even exchanging it for material things, i.e., a car, shoes, house, can be taken but not the Bitcoin.
Check your country's legal stance on Bitcoin with respect to proposed bills or legislation that is already in force. That will answer you better.

Your answer is about the legal aspect, but I think the question was more about the technical one.

Possibilities revealed in How the FBI Got Colonial Pipeline’s Ransom Money Back (published 11 June 2021 in the WSJ):  On May, 8 Colonial Pipeline Co. paid a 75 BTC ransom to the Darkside hacking cartel.

Over the next 19 days, court records show, a special agent watched on a publicly visible bitcoin ledger as hackers transferred the 75 bitcoins to other digital addresses. A May 27 transfer of nearly 64 bitcoins landed at a virtual address to which the FBI gained access, providing an opportunity to get a warrant and pounce.

The FBI said in its request for a warrant Monday that its investigators had in their possession the private key for that address. Officials didn’t elaborate on how it obtained the information....

The remaining funds from Colonial that haven’t been recovered by the FBI were consolidated with other crypto tied to ransom payments in a wallet that now holds about 108 bitcoins.  “Everyone has their eyes on it to see if those funds are transferred.”

So, apparently, when a government wants to seize someone's BTC, it can follow the money until it is either transferred to a wallet to which the government has access (though the list of wallets the government can access – and how – remains secret), or to the wallet of a known entity.

“We’ve effectively developed a map of hundreds of millions of bitcoin addresses associated with illicit actors all around the world,” said David Carlisle, director of policy and regulatory affairs at blockchain analytics firm Elliptic.


text:
Query regarding Central Wallets and Sub Wallets
Is it possible to develop a wallet system with a central wallet and sub wallet system for Bitcoin and other cryptocurrencies. Is there any wallet system available with such features. Any guidance or pointers would be much appreciated.

Hardware wallets generally use a master seed from which they generate wallets for each cryptocurrency. One particular specification for this use case is BIP44 (which builds upon BIP32 and BIP43).


text:
What does a double spend (CVE-2018-17144) look like if I gettransaction it?
Just wondering what the output from gettransaction (or should I be using getblock?) would look like if I passed it a txid(or blockhash) that contained a set of transactions that exploited the double spend bug CVE-2018-17144? Is it distinguishable from a normal, non double-spend? Does the wallet being queried have to know about both the addresses spent to, in order to show anything out of the ordinary?

You could use $ getblock <blockhash> 2 or $ getrawtransaction <tx-hash> 2.
Here is a transaction that exploited this bug on testnet: fb7a8658ec015133e36e2cf7ddf7e8c887c3a5becec2f30f24ebfe43e72f4b59
$ bitcoin-cli -testnet getrawtransaction fb7a8658ec015133e36e2cf7ddf7e8c887c3a5becec2f30f24ebfe43e72f4b59
    {
      "txid": "fb7a8658ec015133e36e2cf7ddf7e8c887c3a5becec2f30f24ebfe43e72f4b59",
      "hash": "fb7a8658ec015133e36e2cf7ddf7e8c887c3a5becec2f30f24ebfe43e72f4b59",
      "version": 1,
      "size": 403,
      "vsize": 403,
      "weight": 1612,
      "locktime": 0,
      "vin": [
        {
          "txid": "6a08723bc717e1ddf91fa60fde25784ef66952e8687f3bffe391fc2c819dbfd9",
          "vout": 1,
          "scriptSig": {
            "asm": "3045022100e412610b2e2b8370f2eda0cf29fe19c2a4ea35191d8b42656e81bc97026b229e022046ff1df7293f8dbc3efd95b125ebf679a4a68e8de2265990ef7553f1060dc9e3[ALL] 0455fd1c1a6cbfb25b5bba1cf6f850de00d79852be3de51e50c0da683613303c533d079e147dfe07ce4d40df2b776b35184698d14fa107a61e0976b0d9416880c8",
            "hex": "483045022100e412610b2e2b8370f2eda0cf29fe19c2a4ea35191d8b42656e81bc97026b229e022046ff1df7293f8dbc3efd95b125ebf679a4a68e8de2265990ef7553f1060dc9e301410455fd1c1a6cbfb25b5bba1cf6f850de00d79852be3de51e50c0da683613303c533d079e147dfe07ce4d40df2b776b35184698d14fa107a61e0976b0d9416880c8"
          },
          "sequence": 4294967295
        },
        {
          "txid": "6a08723bc717e1ddf91fa60fde25784ef66952e8687f3bffe391fc2c819dbfd9",
          "vout": 1,
          "scriptSig": {
            "asm": "304402206fa6ef6c0727ecf8d40b2b4648a93b084396c9819d20a3300e83ac4d110589e8022060c78d44db1d5b5babd1629c55d8058643d11a14da933b4bc5f7a8a2a7da3773[ALL] 0455fd1c1a6cbfb25b5bba1cf6f850de00d79852be3de51e50c0da683613303c533d079e147dfe07ce4d40df2b776b35184698d14fa107a61e0976b0d9416880c8",
            "hex": "47304402206fa6ef6c0727ecf8d40b2b4648a93b084396c9819d20a3300e83ac4d110589e8022060c78d44db1d5b5babd1629c55d8058643d11a14da933b4bc5f7a8a2a7da377301410455fd1c1a6cbfb25b5bba1cf6f850de00d79852be3de51e50c0da683613303c533d079e147dfe07ce4d40df2b776b35184698d14fa107a61e0976b0d9416880c8"
          },
          "sequence": 4294967295
        }
      ],
      "vout": [
        {
          "value": 0.09900000,
          "n": 0,
          "scriptPubKey": {
            "asm": "OP_DUP OP_HASH160 c8b876680fef08df5278a9df92df7e30b83cbb71 OP_EQUALVERIFY OP_CHECKSIG",
            "hex": "76a914c8b876680fef08df5278a9df92df7e30b83cbb7188ac",
            "reqSigs": 1,
            "type": "pubkeyhash",
            "addresses": [
              "mypGR6pDS85nidXk3DoHZCNBuYd6WBhzgU"
            ]
          }
        }
      ],
      "hex": "0100000002d9bf9d812cfc91e3ff3b7f68e85269f64e7825de0fa61ff9dde117c73b72086a010000008b483045022100e412610b2e2b8370f2eda0cf29fe19c2a4ea35191d8b42656e81bc97026b229e022046ff1df7293f8dbc3efd95b125ebf679a4a68e8de2265990ef7553f1060dc9e301410455fd1c1a6cbfb25b5bba1cf6f850de00d79852be3de51e50c0da683613303c533d079e147dfe07ce4d40df2b776b35184698d14fa107a61e0976b0d9416880c8ffffffffd9bf9d812cfc91e3ff3b7f68e85269f64e7825de0fa61ff9dde117c73b72086a010000008a47304402206fa6ef6c0727ecf8d40b2b4648a93b084396c9819d20a3300e83ac4d110589e8022060c78d44db1d5b5babd1629c55d8058643d11a14da933b4bc5f7a8a2a7da377301410455fd1c1a6cbfb25b5bba1cf6f850de00d79852be3de51e50c0da683613303c533d079e147dfe07ce4d40df2b776b35184698d14fa107a61e0976b0d9416880c8ffffffff01e00f9700000000001976a914c8b876680fef08df5278a9df92df7e30b83cbb7188ac00000000",
      "blockhash": "00000000eba3f43a8624750f39e4520a1678c0dbdf8707bfa4854a12fbf086c5",
      "confirmations": 0,
      "time": 1537995498,
      "blocktime": 1537995498
    }

Is it distinguishable from a normal, non double-spend?

You will notice the input is listed twice in the 'vin':
"txid": "6a08723bc717e1ddf91fa60fde25784ef66952e8687f3bffe391fc2c819dbfd9",
"vout": 1,

That is considered a double spend.

Does the wallet being queried have to know about both the addresses
  spent to, in order to show anything out of the ordinary?

The wallet would have to be watching the associated addresses or it probably wouldn't have that transaction stored. Even if it's a full node, you can only get the tx by txid if you have indexed the blockchain using -txindex flag.

You see in that json where you have vin.vout twice, and theyre both 1. Is it always this way? While idly browsing the block explorer rich list for a coin I've got some old hodlings, I noticed this: https://chainz.cryptoid.info/funk/tx.dws?1211915.htm - is that also this same exploit? The txid is repeated over and over, but the vout is different, unlike your example

If only the vout is different, then it is a different output from the same transaction

So I need to chase the transaction outputs back to find ones with the same vout?

If you're looking for a double spend, yes. A transaction output is identified uniquely by it's txid and vout together. This is because transactions can have multiple outputs.

Ok, so in that tx I linked (https://chainz.cryptoid.info/funk/tx.dws?1211915.htm) all those vout are different so they’re legitimately different inputs to that transaction.. BUT if I go back another step and view the transaction they were outputs in (https://chainz.cryptoid.info/funk/tx.dws?1211349.htm) this one has tens of identical txid/vout so THAT is the transaction that exploited the bug?

Yes, it appears so


text:
confirmations: 0 vs confirmations: -1?
I'm looking at a bitcoin clone, not sure what codebase it was cloned from, but I've noticed that the listSinceBlock output sometimes includes:

a receive that has 0 confirmations
a send that has 0 confirmations
a send that has -1 confirmations

What is the significance of these counts? Does 0 mean that the transaction was never mined (too low fee?) versus the -1 meaning that that transaction has only ever been seen in a now-stale block? (chain reorg, new best chain doesn't include the block that held these transactions)
These transactions are fairly old (months) so if something was going to happen with them by now, i think it would have..


text:
Does listsinceblock list all transactions, or only transactions my wallet is interested in?
Wondering if I call listsinceblock "", will I get all transactions that ever occurred on the blockchain regardless of whether my wallet was party to it, or will it only be a list of transactions relevant to my wallet (things I've sent/received/have a private key for at least one side of) ?

Possible duplicate of How can I list my mined coins using RPC? And spend them?

... from all accounts within your own wallet, see here https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list: "listtransactions" Returns up to [count] most recent transactions skipping the first [from] transactions for account [account]. If [account] not provided it'll return recent transactions from all accounts.

Can you please clarify why you posted the help file text for listtransactions when I asked about listsinceblock ?

Oops, yup, I see, I have mixed things up. The previous line on the same page refers to listsinceblock. Another link would be here: https://bitcoin.stackexchange.com/questions/25103/listsinceblock-parameter-target-confirmations, and also here: https://bitcoin.stackexchange.com/questions/32748/monitor-non-wallet-bitcoin-addresses-for-new-transactions/32755#32755. in general: if you set “txindex=1” in bitcoin.conf, then also foreign (non wallet addresses) can be seen.

listsinceblock will only list txs your wallet is interested in i.e. transactions involving as input or as output an address A such that:

either A is an address whose private key is known to your wallet and consequently can sign transactions that spend UTXOs of A
or A is an address your wallet is following as watch-only i.e. does not know A's private key but A was added to the wallet using importaddress

listtransactions will also only return transactions your wallet is interested in but with different criteria. It returns count most recent txs of interest (as per above criteria) and you can also define to omit most recent skip txs and also filter by label (or account for older versions which is not deprecated).
All in all, following two should both return all txs your wallet is interested in:
bitcoin-cli listsinceblock <hash_of_genesis_block> 1 true

bitcoin-cli listtransactions "*" <a_number_greater_than_your_wallet_total_tx_count> 0 true

There is no direct way through CLI to return all txs in the blockchain afaik.

In the second case (i.e., A is imported as watch-only address in the wallet), will listsinceblock also show any coinbase transactions that used "A" as an output?

@Shobit I can't think of a reason why not. In that case "category" value would be "immature" or with > 100 confirmations "generate".

@ThalisK. is it true that “deposit” transactions are only the ones with “receive” as category? And how to consider receive transaction with 0 as amount? A deposit amount of 0 I think that is not a deposit

@AlfonsoSilvestri Also a coinbase transaction is a "deposit" (type "immature" and after 100 confirmations becomes "generate" and is spendable). A tx with amount == 0 can safely be ignored IMO.


text:
Was the "sideloaded" data verified by bitcoind during the value overflow bug?
As a response to the overflow bug 2010, Satoshi wrote this post asking people to download the blockchain (blk****.dat and blkindex.dat) from a specific user.

Patch is uploaded to SVN rev 132!
For now, recommended steps:

Shut down.
Download knightmb's blk
files.  (replace your blk0001.dat and blkindex.dat files)
Upgrade.
It should start out with less than 74000 blocks. Let it redownload
the rest.

If you don't want to use knightmb's files, you could just delete your
blk*.dat files, but it's going to be a lot of load on the network if
everyone is downloading the whole block index at once.
I'll build releases shortly.

I'm trying to understand from the code whether knightmb's blockchain data would be verified on startup or not, but couldn't easily determine that.
Was the blockchain data that people downloaded verified by the code in subversion revision r132 (imported to git commit d4c6b90ca3f9b47adb1b2724a0c3514f80635c84)?

I'm trying to understand from the code whether knightmb's blockchain data would be verified on startup or not, but couldn't easily determine that.

It would not be.
blkindex.dat back then held the equivalent of what is now called the UTXO set (and more). If you'd copy a malicious one, it would be accepted without verification (as it is the outcome of verification itself).

Haha, that's fantastic. Those were different times... Thanks a lot!


text:
Why hash witness script instead of pubkey script in signature?
When a segwit input is signed, the signature will commit to the witness script (or a p2pkh-like script in case of p2wpkh). This is specified in BIP143:

For P2WPKH witness program, the scriptCode is 0x1976a914{20-byte-pubkey-hash}88ac.
For P2WSH witness program,

if the witnessScript does not contain any OP_CODESEPARATOR, the scriptCode is the witnessScript serialized as scripts inside CTxOut.
if the witnessScript contains any OP_CODESEPARATOR, the scriptCode is the witnessScript but removing everything up to and including the last executed OP_CODESEPARATOR before the signature checking opcode being executed, serialized as scripts inside CTxOut. (The exact semantics is demonstrated in the examples below)

What's the rationale behind this? Why doesn't the hash commit to the pubkey script as in legacy (p2pkh and p2sh) payments? This difference complicates signing/verification code a bit, so I suppose there must be some good reason for it.
Maybe my question should be: Why does the hash commit to any script at all for segwit inputs? In legacy signatures, putting scriptPubkey in scriptSig for the current input is a (complicated, see below) way to avoid signature reuse between inputs. But in segwit, this is accomplished with the outpoint part of the hashing algorithm. So couldn't we just skip the scriptCode part?
It seems to me that there is another reason for why we hash the scriptPubkey for legacy signatures and the witness script for segwit signatures, since there are simpler ways to avoid signature reuse:

Legacy: We could just have added a dummy byte somewhere in the current input
Segwit: Current input's outpoint already solves the problem.

I'm just guessing, but by having the transaction commit to the scriptCode, we ensure that the signer knows what script they're signing for.  A hardware wallet, for example, can only be certain that outpoint 1234...cdef:0 pays a particular script if we give it the transaction that created that outpoint (so that it can hash that transaction, verify the txid, extract the scriptPubKey, and compare that to a provided witnessScript).  Because a transaction (without witness data) can be up to almost a megabyte in size and a spending transaction can refer to thousands of previous transactions, we create a situation where low-resource devices such as hardware wallets have a hard time verifying what they're signing.
By contrast, with BIP143, we need only tell the wallet each of the scriptCodes it's supposed to sign for.  BIP141 allows these to be up to 10,000 bytes, which is just 1/100th the maximum size of a transaction.  The wallet can examine these scriptCodes, ensure they agree with what the wallet expects, and commit to them in its signature knowing that if the person sending them the scriptCode lied about the actual scriptCode, the signature will be invalid.
This is the same reason the BIP143 signature format commits to the value of each input.  Before it had to process previous transactions in order to get their output amounts; now it just accepts whatever data it receives and signs it knowing that, if someone lied to it about the amount, the signature will be invalid.

"... knowing that if the person sending them the scriptCode lied about the actual scriptCode, the signature will be invalid."
I'm in deep waters here, but I think the signature would be invalid even if it didn't directly commit to the scriptCode, because the signature already indirectly commits to the scriptCode via the outpoint->WSH->scriptCode path. So this doesn't really answer the question, I'm afraid.

You're correct that commiting to the outpoint commits to the prevout scriptPubKey and that the prevout scriptPubKey commits to the script, but the point of the answer is that proving to wallet that a particular outpoint corresponds to a particular witnessScript requires up to ~1 MB data plus the witnessScript.  By commiting directly to the scriptCode, now the only data required for the proof is the scriptCode (which is the same as the witnessScript in normal usage).

Consider a transaction with a single p2wsh input. The hardware wallet gets an unsigned transaction (Tx), the supposed input UTXO (U), and the supposed witness script (WS). It also probably gets a key derivation path, but that's irrelevant for this discussion. This information, [Tx, U, WS], doesn't itself prove that the outpoint commits to WS. Further, if the input is signed based on [Tx, U, WS], and if U and WS are false, the signature will be invalid regardless whether the signature commits to scriptCode or not. Am I wrong here? Thank you for your patience.

Yes, I'm wrong here. Private conversation with @David made me realize that the signature would not be invalid if BIP143 omitted scriptCode. Slip of mind. So yes, we must commit to scriptCode.


text:
How much on-chain activity is to and from exchanges?
Are there any data services which provide metrics that show how much of the transactions on the Bitcoin blockchain are to and from exchanges?

Glassnode offers this metric, though it is paid.
https://studio.glassnode.com/workbench/btc-exchange-transaction-dominance
cryptoquant also has this
https://cryptoquant.com/asset/btc/chart/exchange-flows/exchange-netflow-total
https://cryptoquant.com/asset/btc/chart/exchange-flows/exchange-inflow-total
https://cryptoquant.com/asset/btc/chart/exchange-flows/exchange-outflow-total


text:
Historical Price API in AUD
I'm looking for an API that displays historical data for cryptocurrencies. I have a list of requirements, in rough order of importance:

Price in AUD (I don't care about other currencies)
Multiple cryptocurrencies (at least the major ones, but the more the better)
Returns historical data, not just current price (just the last week/month is fine)
Updated hourly or more

I've found a bunch of APIs and they all do two, maybe three of my requirements if I'm lucky, but never all.
I'm going to be graphing this data in Python/Django website, so I could either use a native Python API, make an HTTP request to get a JSON or CSV response, or display someone else's graph in an iframe like this API I found that shows a pricebox for BitCoin:
    <iframe src="https://cryptocoincharts.info/webmasters/priceBox/btc/aud" style="width: 300px; height: 200px;" frameborder="0" />

Does anybody know of an API that would suit my needs?

For anyone stumbling upon this is the future, I ended up going with the Poloniex API. It has everything apart from prices in AUD. From there I convert USD to AUD for values as I need them.

Binance API combined with the Blockchain.info AUD to BTC conversion might be what you're after.
Worth mentioning that you don't need to register for some silly API key (yet)
e.g
AUD TO BTC
BTC TO USDT


text:
Litecoin query re Wemineltc
Wondering if you can help me out with question..
I was mining litecoin with WemineLTC some years ago...  I am aware that they have now disappeared from the market.. I have or had 10 coins which were transferred into my wallet on my PC and have sat there for the last few years doing nothing..  Have these been lost or can they still be redeemed.
Thank you in anticipation

Find the seed phrase you used for your wallet, or open your wallet and transfer them to an exchange.
The actual coins are still on your computer - they are just some strings.
So you need to open your local wallet or restore it using the seed phrase.
Sell the LTC to convert to something else. LTC just isn't worth it.


text:
Is it smart to just create wallet and then delete it, writing down the address?
What are possible downsides of practice where I download a bitcoin wallet on my phone, write down the seed and the address, purge the app into nonexistence and continue my happy life, sharing my address, using it like, for example, a savings account?
I would then check the balance every few years.

If you only generate a limited set of addresses before you delete your wallet, it is likely you will run out of fresh addresses to receive funds on, meaning multiple spendable transactions will be linked together via the receiving address. This is a privacy disadvantage.
Secondly, your mnemonic key phrase back-up follows an off-chain deterministic key derivation standard (BIP32/43/44), and even if all consensus rules do not chain, there is no guarantee that wallets continue to implement the same key generation method that they currently do (depending on your timeframe). If you cannot use a wallet application with the same key derivation standard later, you will have to derive your used keys yourself using the BIP32/43/44 standards.

This is a good answer. I liked the part about privacy. Can you please explain more the second part? I'm not sure I follow.

Your mnemonic key phrase is used to derive the actual private keys and addresses which u receive find on. This derivation path happens entirely in your wallet and hs nothing to do with the Bitcoin network, it is simply a standard method adopted by wallet makers. If your wallet maker no longer supports this and updates to sth else, it could be that your mnemonic phrase results in different key/addresses in the future. It is unlikely that a wallet wouldnt continue to support older mnemonic phrases in the future, but there are no guarantees. In that case u would have to derive your keys manually.

If this reply answered your question entirely (and only if it did), a checkmark would be kindly appreciated!

I will gladly do so if no other, better, answer comes up in near future.

@IgorV. i suggest writing down the name of the wallet software you used and the version number along with the seed backup. this will help you restore your wallet in future.

If security is your primary concern, the best practice would be to generate all private keys offline. (Ideally you would do it on a device that will never be connected to the internet or manually e.g., with dice.) If you generate the keys on your phone, even if you delete the app, you would need to make sure nothing slips out before you delete the app, and that you completely wipe all traces. A rogue program running on your phone could compromise you when you generate your private key.

You don't even need to install an app for that purpose.  There are a number of tools available online which allow you to generate (both randomly and not-so-randomly) BIP39 seed words (12-24 word variants) and list your resulting private and public keys, as well as addresses.  The Ian Coleman BIP39 generator is a great example.  It can be saved and used offline, and if you don't trust his RNG implementation, you can generate your own random number(s) using a variety of options, including just rolling a (presumably fair) 6-sided die multiple times, shuffling and drawing cards, or plugging in hexadecimal, binary, or base-10 numbers generated from the RNG of your choice.


text:
Bitcoin RIPEMD160 purpose
Bitcoin uses RIPEMD160 on top of SHA256. Is its sole purpose to make public key address shorter or does it strengthen security in any way?

Possible duplicate of Why does Bitcoin use two hash functions (SHA-256 and RIPEMD-160) to create an address?

The question you mentioned has slightly different meaning where it asks  why double hashing instead of simple SHA256. My curiosity was why use RIPEMD160 with SHA256, for ex: why not SHA256d.

RIPEMD160 was designed in the open academic community and not like SHA2 by a NSA competition... one may see this as security advantage.
160bit hashes do also have less space requirements (then sha256) on the blockchain as well as in indexes, etc.

Thanks Jonas Schnelli, does it also give advantage for being used together with SHA256 in terms of double hashing?

Most hashes in bitcoin are using double sha256. But an additional RIPEMD does protect against possible weakness in SHA256 since addresses are hashed with SHA256 and RIPEMD160.


text:
Bitcoincashjs generates dust output with 0 amount
I am using bitcoincashjs (Bitcore fork) library to make BCH transaction (actually it is an exchange with ChangeNow API). Source wallet has only one UTXO:
[
  {
    "address":"bitcoincash:qpde96gh8j9hd9jewzdu6rfme725vpm0mqc2wzyque",
    "txid":"422defba3dce33a55bf84650848a2fa971907ec6b6ce156fa414254d2e5b45a4",
    "vout":1,
    "scriptPubKey":"76a9145b92e9173c8b769659709bcd0d3bcf9546076fd888ac",
    "amount":0.02880688,
    "satoshis":2880688,
    "height":531325,
    "confirmations":3
  }
]

So, then I build the transaction
const bitcoreTransaction = new Bitcore.Transaction()
  .from(unspentOutputs)
  .to(toAddress, fromFunction(data.amount)[toFunction]())
  .fee(fromFunction(fee)[toFunction]())
  .feePerKb(this.getFeePerKb()) // 4000
  .change(fromAddress)
  .sign(privateKeyForSign);

and check for serialization error, which says: Dust amount detected in one output. When I debug resulting tx object, I see two outputs and one of them has 0 amount. Skipping of dust check on client does not help as it is checked on API side while publishing the transaction and error is returned.
Any ideas how to avoid this?

Try if it also happens with bitcore-lib. If not, report it.


text:
asic mining with different cryptocurrencies after it is no longer profitable
If I have an Asic to mine bitcoin and I mine to the point that it no longer becomes profitable to mine them anymore, Can I use the Asic to mine a different cryptocurrency and will the difficulty needed to mine it be higher than if I just bought a new Asic?

An ASIC is an "Application Specific Integrated Circuit".  In the case of a Bitcoin miner, the specific application is performing the SHA256 hashing algorithm.  That is the only thing the ASIC knows how to do.
So long as the cryptocurrency you want to mine uses SHA256, you should be able to use the ASIC on that currency.

so once i start mining the new cryptocurrency, will kind of reset the difficulty and act as if it had never mined it before or will it still be hard for it to mine since everytime it mines one, it becomes harder to mine?(Sorry im not being super precise)

It depends on the altcoin and how their difficulty adjustment algorithm works.

@AviAssouline, I think you are a bit confused.  You, personally mining does not have a significant impact on the difficulty.  It's the total network hashing power as a whole that changes the difficulty.  Whether you are involved or not is unlikely to matter.  You simply don't have enough hashing power to effect the whole network.


text:
Are my BTC now BCH?! What happened?! Is my money lost?
i don't know if i made a big mistake. I start from the beginning:
I wanted to transfer my BTC (worth 350$) to kraken. Accidently i sent them to a BCH address. You can see it here:
https://blockchain.info/tx/45c843c767b5ff8543adacb900c13fc03289639216c9de0862cb5ee8b41a863b
It got enough confirmations and so I wrote the kraken support whether they could help me to get my btc back. but then i realized that blockchain.info now showed that i would have the amount i sent to kraken now as BCH which was of course much less (50$) . I couldn't find out on which address i got the money because blockchain.info wasn't able to show on which address i got the money, it only showed that i have 50$ in total as BCH.
I read about how to get my money back to BTC, so I transfered my money to my wallet in EXODUS as BCH (blockchain.info only offered this transfer method) to a BCH address. It again got confirmations:
https://blockdozer.com/insight/tx/63be7ff8d38e648c19a1d0a9dc66a87ee64ae1359888ac8404b017d82c607dc4
I now have the 50$ on my BCH address in exodus, but this tool wasn't able to get my money back to BTC. I used this tutorial:
http://support.exodus.io/article/189-ive-sent-bitcoin-cash-to-my-bitcoin-address
is it possible to get the money back to BTC or is my money now forever BCH? Please help me. The one to help me get my money in BTC back, gets a little donation.

If what you're saying is true, this sounds like a big problem.
BTC and BCH are two completely separate blockchains.  It's impossible to send bitcoin from one to the other.
If you send BTC to an address, then it's always going to be an address on the BTC blockchain, not the BCH blockchain.
So if you sent your BTC's to address X, then you sent them to address X on the BTC blockchain.  If you don't own address X on the BTC blockchain, then you no longer have access to those funds.


text:
Unconfirmed transaction why
My transaction stays unconfirmed. I've paid a normal fee I quess. The transaction is here:
https://blockchain.info/nl/tx/b8cacc71fba15b4dfee234cd037ba4729a15e573243440257777044f7ed8f101
What can I do to let it through?
Thanks in advance!
Rick

This is because miners are spaming the network, stay calmed, maybe cancel it and try it later.

How can I cancel it?

It depends on the wallet, but it will be automatically cancelled if it stays unconfirmed for a long time. So, do not worry, if the spam ends soon, it will be confirmed, if not it will be cancelled and you will be able to try later.

As a final advice, I would recomend you to use a wallet that has segwit enabled, it will allow you to pay lower fees and to get confirmed faster

To add - bitcoins are never lost, or in transit, when a transaction is unconfirmed. The bitcoins are in your wallet, UNTIL the transaction is confirmed and then they are in the recipient's wallet. There is no limbo-state, like there is in traditional banking.

Aaargh, still not confirmed. I did pay the normal fee. Would have paid more if i knew this. This is not good for the bitcoin in general. Can I pay more fee somehow?

Yes you can, (if your wallet allows it). But right now the Blockchain is quite crowded, so you would have to pay a higher fee than usuall. I would wait until the mining difficulty adjustment (every two weeks). After that, mining will be more profitable again, and fees will go down.

Bitcoin is the only truly descentralized cryptocurrency. Miners want to replace it with "Bitcoin Cash" becouse they have total control over it.

Is there someone here that can push it through for a small fee?

Fees are going down now https://jochen-hoenicke.de/queue/#2d. With segwit wallets fees are lower. And if the transaction is not urgent, you should time it at the times when fees are low.


text:
I have bitcoin core wallet with missing btc
I have a bitcoin core wallet with out me sending transactions it sent out several times sent to the same address ..will it come back in my wallet

Have a look at the transaction ID, try entering it into a block explorer and checking they really were moved. If they were, then no, it's unlikely you can get the coins back, your computer may have been compromised

It's saying it's going in one large account and it was sending small amounts back but stop 3 days ago...I'm still missing 90%

If you don't own that address and don't know who owns it, chances are you will never get the coins back, as I said. Perhaps they have been stolen, sorry :(

are transaction address link to IP address

@JoshuaNa no, https://bitcoin.stackexchange.com/questions/41086/how-to-identify-the-owner-of-a-bitcoin-address, and please don't ask new questions in the comments section here


text:
Which file is the source codes of regtest net located?
I try to compare the source codes between main net and regtest net of bitcoin. I am not sure where the source codes of regtest located. Would someone help me, please?

Because regtest is supposed to be test network, it has to be pretty similar to mainnet. Thus there really isn't separate code for regtest only, most of the code is shared between the two networks. The differences are really only defined by a few parameter changes which can be found in chainparams.cpp.

Thanks Andrew. What I really want to know is the miner part for Regtest. I believe what original Satoshi Nakamoto told. So, how to reduce the system cost, specially the mining cost is the biggest issue. I think the two basic functions of mining can be separated into two parts;  one for find the data recorder, another for system safety. I think the getwork is better than getblocktemplate for unti-concentrated, maybe only internal miner is ever better.

There's no mining in regtest. Regtest was also made half a decade after Satoshi left.


text:
Which values are GetValueIn() and GetValueOut() calculate?
In Transaction.cpp, there is a function CAmount CTransaction::GetValueOut() const.
In Coins.cpp, there is a function CAmount CCoinsViewCache::GetValueIn(const CTransaction& tx) const.
My understand the GetValueIn() is calculater all vin value for a Tx.
But what the GetValueOut() calculate - all vout for a Tx?

But what the GetValueOut() calculate - all vout for a Tx?

Yes, it calculates the total value of all the outputs in the transaction. It also makes sure that the value is not out of range of the total supply of Bitcoin (21M).

JBaczuk, thank you so much for all your help.


text:
What is the relationship of ckeypool and ckeystore?
In the source, there are ckeypool and skeystore. I wonder what is the relationship of them and why need both.

CKeyStore is a class for storing keys. It provides the functions for storing and retrieving keys.
CKeyPool is a class for a key that is in the keypool. It is specifically a database object for storing a public key and its location inside of the keypool.
CKeyStore and CKeyPool are two different things and are largely unrelated.
The keypool is the set of keys that are unused. It is separate from CKeyStore and has an entirely different purpose. CKeyPool objects are specific to a CWallet which is a subclass of CKeyStore.

Thanks. If the keypool store only store public keys, where is the related private keys located and how the pair related?

If refill keypool, where the new private keys go?

The private keys, along with their public keys, are stored in the keystore. When new keys are generated, they private keys and their public keys are added to the keystore. At the same time, public keys are added to the keypool. There are other information that is stored to.

One more thing, I am not sure, when new keys are generated, the public keys are added to both keystore and keypool, or just added to the keystore's keypool only?

A keystore does not have a keypool. The public keys are added to many different places, including the keystore and the keypool. Public keys are used as identifiers for many things, so they end up being duplicated in many different places.


text:
Which source code to make "checksum bits appended"
Can anyone tell me the specified source code to make "checksum bits appended", before doing Base58 conversion? Thanks very much!!!!

See src/base58.cpp Line 124:
std::string EncodeBase58Check(const std::vector<unsigned char>& vchIn)
{
    // add 4-byte hash check to the end
    std::vector<unsigned char> vch(vchIn);
    uint256 hash = Hash(vch.begin(), vch.end());
    vch.insert(vch.end(), (unsigned char*)&hash, (unsigned char*)&hash + 4);
    return EncodeBase58(vch);
}

As you can see, the data vch is hashed, then the first 4 bytes of the hash are appended to the end of vch before base58 encoding.

Thank you so much for your answer. Stupid me, I ask the wrong question, what I want ask is the source code to attach the prefix not checksum. would you please tell me which source to attach the prefix before do Base58?

I think you may be looking for these lines: https://github.com/bitcoin/bitcoin/blob/v0.16.2/src/base58.cpp#L226. Note this has changed in the latest 0.17 release candidate to https://github.com/bitcoin/bitcoin/blob/v0.17.0rc3/src/key_io.cpp#L29


text:
Anyone could teach me more detail about version prefix
In this post Does the version prefix of an address force the type of transactions the address may treat?, I saw "the version byte doesn't actually appear in the final transaction."
I don't understand why? Could anyone can help to tell more detail about that?

The address prefix determines how a wallet will interperet the address. Let's look at an example.
Generate a P2PKH address

Take a public key, e.g. 023cba1f4d12d1ce0bced725373769b2262c6daa97be6a0588cfec8ce1a5f0bd09
Apply HASH160: 3a38d44d6a0c8d0bb84e0232cc632b7e48c72e0e
Prepend the version prefix for P2PKH (0x00): 003a38d44d6a0c8d0bb84e0232cc632b7e48c72e0e
Base58Check encode it: 16JrGhLx5bcBSA34kew9V6Mufa4aXhFe9X

See How to Generate a Bitcoin Address — Step by Step for command line steps.
Prefixes
Bitcoin has 2 main address prefixes (mainnet):
P2PKH (Pay to Public Key Hash): 1
e.g.: 17VZNX1SN5NtKa8UQFxwQbFeFc3iqRYhem
P2SH (Pay to Script Hash): 3
e.g.: 3EktnHQD7RiAE6uzMj2ZifT9YgRrkSgzQX
Addresses are just representations of the information necessary (scriptPubKey) to create a transaction output, which is part of the transaction and which is validated and stored on the network. It is only used by wallet application software, addresses are not stored on the Blockchain in this format.
The wallet will determine, based on the address prefix, when it is decoded, how to construct this scriptPubkey. For P2PKH this would be in this form:
OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
Where you will notice, the only info it needs is the pubKeyHash which is contained in the decoded address (step 2 above). However, the format for a P2SH scriptPubkey is OP_HASH160 <scriptHash> OP_EQUAL. If you used the wrong prefix, the wallet would create the wrong script and a tx will most likely burn those coins because no one will be able to guess keys/scripts that will successfully satisfy the scriptPubkey.

Thank you so much for the explanation. As you said "It is only used by wallet application software, addresses are not stored on the Blockchain in this format."  would you please show me what format address stored on the Blockchain? Using blockchain.info we can see the address prefix of 1, 3, bc1, where are they came?


text:
How to determine the coin amount needed for vin?
At first I believed the coin amount of vin just based on what the send thinking. but after read some source code, it seems the coin amount of vin calculated from vout. Is anyone clear about this and please explain how the determination process is in source code. Thanks.

it seems the coin amount of vin calculated from vout.

It is. vin just references a vout from a previous transaction. Each output (vout) are referenced with the txid and an index (e.g. 0 or 1, because there can be multiple outputs in the same tx).
For more information about how transaction inputs and outputs work, see In getrawtransaction, what is the vout integer in the vin list?


text:
Does eltoo require trusting watchtowers not to close channels?
The way Lightning Network works now, watchtowers maintain a list of penalty transactions to broadcast in case one party attempts to close a channel with an outdated channel state. The watchtower cannot on its own initiate the closing of a channel.
With eltoo, watchtowers instead need to store the most recent update transaction to override any outdated update transactions that might be published. However, doesn't that mean the watchtower can unilaterally force close a channel by publishing an update transaction?

I was intrigued by your question and tried to figure out whether any trustless solutions have been proposed.
I found a [Lightning-dev] mailing list thread positing a rough idea by ZmnSCPxj. Z-man drafts a scheme in which the watchtower payload is encrypted to the message signed in the witness program of the trigger transaction. As a reminder, the trigger transaction initiates the unilateral closing process and is necessary to protect against the funding transaction's refund condition becoming valid prematurely. Hence, the trigger transaction MUST precede publishing of any update transaction (see Eltoo paper section 4.2). While the attacker could modify their own signature on the trigger transaction by re-signing with a new r value, they cannot modify the message digest that was signed without invalidating the counterparty's signature. Thus, the message signed in the trigger transaction is an unconditionally available and immutable datum that can be used to encrypt watchtower payloads. Under this scheme, the watchtower would not have the trigger transaction and thus would be unable to initiate unilateral closing.
Z-man further describes how the watchtower would check whether an older update transaction has been submitted to the network, to evaluate whether its payload is demanded. One downside of the proposed scheme is that the watchtower can correlate all payloads for the same channel once the trigger transaction has been published which allows the watchtower to learn more about the channel's history and activity level in the case of a unilateral close. However, the update transactions are all semantically identical, simply spending the channel funds in a single input to a single output that stages the corresponding settlement transaction which encodes the actual final state of the channel. The update transactions may differ in additional inputs and outputs however.
The proposal only elicited two further messages to the mailing list, and I wasn't able to find more discussion of the concept. I'm not sure whether it is viable and would be actively pursued if/when the Eltoo update mechanism would get rolled out.

I didn't notice that the process of closing a channel is not initiated by publishing an update transaciton but with a trigger transaction. And watchtowers don't need to store the trigger transaction, right? It seems you tried to answer much more than what was in the original question.

Yeah, maybe I went overboard. I actually reread the Eltoo paper almost completely, heh. But yeah, the Watchtower wouldn't have the trigger transaction, because their action would only be necessary when an outdated update transaction had been published. Necessarily, the trigger transaction would have to have preceded an update transaction. In other words, Eltoo watchtowers would not be able to unilaterally initiate a channel closing, but they could publish one or more outdated states if either party initiates unilateral closing.

Well, first I read Z-man's proposal three times, because I didn't grok it. I figured I'd explain my understanding of it while it's fresh so others that try to parse the proposal would get a running start.

I believe your answer will be very helpful to people trying to understand eltoo. Thanks a lot!


text:
How could I make my own API to query the blockchain
I'm looking to access transaction history for some specific coins directly from the blockchain. The main reason is that most of current API are not free or don't provide information for the coins I want.
I'm interested in the Bitcoin block chain but in the BSC as well. And for both I'm having issues understanding if I need to run a node myself in order to retrieve transaction or if some "public" node allow people to query them for information.
On top of that, I can't find any information related to what would be the way to request information from the node, like using REST or something.
Same goes in the case I want to run the node myself, not much information on what the exposed interface would be etc...
Doesn't anyone already tried to build his own API on a chain ?

You could use www.tatum.io to do all of that. We provide blockchain infrastructure and a simple, unified REST API that supports over 20 blockchains. You can do everything with a free plan, and upgrade to a paid plan when you need more that 5 API requests per second.

You could sync a Bitcoin Core node, and run a JSON-RPC server to request new addresses, and check for payment status, etc. You can use SSL and restrict connections only to localhost for added security.
https://en.bitcoin.it/wiki/API_reference_(JSON-RPC)


text:
Actively display wallet funds on web page - how?
I am working on a project where people can contribute to the project in Bitcoin or Ethereum. For each I need a way to be able to display an active balance in each currency's wallet. Something along the lines of this:
You have elected to contribute in BTC to the project. Thank you. Your contributions are most welcome. Please send your BTC to 123abc456def. This wallet currently contains X Bitcoins, while Y have been contributed in total, and the contributed funds have been used for the purposes listed below.
And each time the person accesses the page, X and Y will reflect that wallet at that moment. I'd really prefer not to run a full copy of the blockchain for this. I already have bitcoind running with a 4GB pruned database, and I'm hoping that will be enough.
I need to do all this in PHP. Is there a good PHP toolkit/library/whatever that I can use to call the info?
Thanks!

I already have bitcoind running with a 4GB pruned database, and I'm hoping that will be enough.

It is! By running bitcoin-core, you can pull this data in an easy, trustless way.
I would recommend creating and displaying a new address to your patrons each time a new donation is received (so as to avoid address reuse, which is detrimental to your privacy, and perhaps more importantly your patron's privacy), but otherwise you should be able to accomplish your goal without much issue. You could perhaps look at something like btcpayserver to help automate the payment flow on your website.
Here is a general workflow:

Generate a private key that will be used to receive funds, using your wallet of choice (ideally, this would be done in an offline environment)
Import the address(es) that are derived from the keys you generated in step one, into bitcoin-core. You can use bitcoin-cli importaddress to accomplish this step. Note that if the address is brand new and you know for certain it has never received funds before, then you can set rescan to false, to save a fair bit of computational time.
Use the command bitcoin-cli listunspent to return a list of UTXOs that are locked to addresses that the wallet is watching. You can optionally filter the returned info by address, see bitcoin-cli help listunspent for more info.
(Alternatively, you can use bitcoin-cli getreceivedbyaddress, which may be easier if you're re-using a single receiving address)
From there, you'll just need to parse the JSON data returned, and sum up the relevant address balance(s), to be displayed on your webpage.

I often wonder about multiple addresses. The issue I see with using multiple addresses is the extra transaction fees each time the funds need  to be used. If I get a donation of 50mBTC from user 1, and 60mBTC from user 2,each sending to a different wallet, then I somehow need to consolidate all the funds before they can be used. That would seem to lean towards using a single address. Now if there's a free way of doing that I'm all ears. But that is a concern.

@DanEgli you misunderstand how bitcoin fees work. Each received transaction create a UTXO, the cost of spending each UTXO as input in another transaction does not depend whatsoever on whether the coins are locked to the same address, or different addresses. There is absolutely no difference in terms of fees.

Maybe I am misunderstanding. If so please correct me. But my impression was this: USER A sends 40mBTC to Address 123abc. User 2 send another 40mBTC to address def456. Now, I have 80mBTC but it's split in to two chunks. To consolidate into one spendable lump, I need to maybe send the funds in wallet 2 to wallet 1. But that's an extra transaction, thus incuring extra transaction fees.

@DanEgli you are assuming that bitcoin uses an 'account' model to keep track of coins, but that is incorrect, it uses a 'UTXO' model. Even if you use the same address, multiple payments will still create multiple UTXOs, which will incur the exact same fees as you would spending multiple UTXOs that are locked to different addresses. Needlessly consolidating funds is never a great idea though, just spend the UTXOs when you need to, no need to consolidate first. See this question for more info: https://bitcoin.stackexchange.com/questions/49853/utxo-model-vs-account-balance-model

I think I understand you better. But this still leaves me with a quandry. Let me suppose that I have received 600mBTC, but in six increments of 100mBTC each. So I have six UTXOs, that's great. But if they are in six wallets, then how do I send say 450mBTC to someone? Near as I can tell, I'd have to send all 100mBTC from wallets 1-4, then the balance from wallet 5. And each of those would generate a transaction fee.Unless there's a way to make various addresses aliases for the same wallet? I don't care if I use 200,000 addresses as long as I don't have to take the funds from multiple wallets.

As to btcpayserver, I looked at it. I kind of like the idea, but I can't seem to figure out how I could download the software or anything. They talk about hosting on various servers, but almost all of them seem to be hosting services. We already have the VPS. It's been running other things for months now. So obviously we don't want to move the entire setup to a new server. So, how do I obtain the software for download to our server, and how do I actually install that software? That's what I can't seem to figure out.

@DanEgli comments are not intended for discussions, if you have further questions you should use the search function/create new posts. But in brief: a wallet will contain many, many addresses (keypairs). Receiving to a new address (which is from the same wallet) each and every payment is the standard and highly recommended workflow, your wallet software will manage all of the keys and transaction creation in the background. Installing btcpayserver isn’t too difficult, but it does require some technical skills. See https://docs.btcpayserver.org/Deployment/

Do you want the balance shown to be specific to the user viewing the page, or the total balance contributed from all users?
The former requires more work, the latter is trivially simple.
You can use something like the blockstream API, called via cURL in PHP
https://blockstream.info/api/address/AddressHere
"chain_stats" contains information for confirmed transactions that you can use to calculate the balance of the address

Not per user. Just overall. If the wallet has, say 0.5 BTC, then that's what it shows, regardless of who looks. But as soon as 0.1 BTC was transferred out, then people should see 0.4 BTC in the wallet. The actual list of transactions can be manually created easily.