text:
Idea for zero confirmations transactions using “proof of risk”
I was wondering if the following could be implemented on Bitcoin or other cryptos, or maybe in the future with additional opcodes.
Suppose Alice wants to send small transactions to others, without the lightning network (because the recipients might not support it). She puts 5 BTC in a special transaction with the following logic:

After 1 month, the funds go back to Alice
Given a list of UTXOs (that Alice controls), if the top of the stack contains two different signatures of the same UTXO, the 5 BTC can go immediately to anyone (and will probably go to the miner).

Now Alice meets Bob to buy some product and sends him a low-fee 0.01 BTC transaction that may take hours or even days to be added to the Blockchain, from one of the UTXOs in the last list. Bob publishes the transaction to all the miners, and they will confirm that the transaction is “insured” by 5 BTC. They may even offer a bounty to anyone that gives them another transaction from the same UTXO.
Bob can let Alice leave with the product, knowing that if she tries to double-spend the 0.1 BTC, she’s risking a loss of 5 BTC. Bob won’t earn anything if Alice decides to do so, but he can assume that she is rational.
One problem could be that Alice is a miner herself, and might try to mine the double-spending transaction herself (without publishing that second transaction to the other miners). We could solve this by saying that the 5 BTC transaction won’t go to the miner that mined it, but to whoever mines the later 100th block. Alice must be a really big miner if she can take the risk that she will also successfully mine that 100th block.
What do you think?
-- edit --
Since modern wallets don't reuse addresses, another solution for the "collateral contract" could be:

After 1 month, the funds go back to Alice
Given a list of addresses (that Alice controls), if this contract is used against a redeem-script that has two different signatures made by a private key of a single address from the list - the 5 BTC can go immediately to anyone (and will probably go to the miner).

It is Alice's responsibility not to publish two transactions that use the same address, or any two pieces of information signed by the same private key - or else, she might lose 5 BTC to some random miner.
For privacy and saving space, instead of the contract containing the entire list of addresses, it can contain a merkel-tree root, and when Alice pays Bob she could also publish the paths from each of the relevant addresses to the root.
The disadvantage is that Alice must be careful not to sign two messages (transactions) with the same private key (that its address is in the contract). Not even to fix anything in the payment to Bob, or to increase fees. She could, however, add some extra payment to Bob, and make it a zero-fee transaction, leaving Bob with the responsibility to attach it to another transaction with whatever fee that he chooses (For example, once a week Bob could consolidate many zero-fee transactions to a single address).
-- edit --
A typical use case could be "mid range" transactions. For large transactions, even a $10 fee is insignificant. For small transactions, lightning can be used. But for mid-range transactions, which lightning's inbound capacity problem might disallow, you wouldn't want to pay high fees and you also wouldn't want to wait hours for the transaction to complete.

In general I think there are definitely ways to move forward with zero confirmation transactions, especially when you compare to traditional payment fraud. But I don't understand 2 things. " two different signatures of the same UTXO"? and how does the 5btc insure the transaction? you mean like a way to release the 5btc to a miner, if a transaction comes up short because it was double spent?

Yes, if Alice tries to double spend the 0.01 btc, it will have to publish two different transactions with the same UTXO (assuming she is not a miner herself). Any miner that sees these two signatures could “punish” Alice and claim the 5 BTC to himself.

0.01 BTC is quite a lot for zero confirmations (~$340) and why pay a $2 fee for a $340 transaction to be added quickly to the blockchain, if the merchant is ok with receiving the payment in a delay of 48 hours. This could work for ATMs as well.

I like where this is going, but I think there are a lot of different things you would have to figure out how to solve. 1) when the person puts up btc as collateral, how do you relate future transaction that are insured with that particular collateral?

What's the "top of the stack"? Transactions are immutable and don't expire, so Alice will never be able to issue a second transaction spending the same UTXO, i.e. if fees stay high for a long time, Alice is forced to do a CPFP instead of an RBF transaction and just wastes more blockspace.

@noone392 The future transactions must come from pre-known UTXOs or pre-known addresses, that are specified in the collateral-smart-contract. A merkle-tree could be used here.

@Murch I'm not familiar enough with Bitcoin's technical terms. The idea is similar to lightning's HTLC - once the transaction is on the blockchain for all to see, it can reused with a redeem script that adds two params to the stack. In this case, the two params will be two signatures made by Alice.

@Oren so lets say there is some sort of contract that has some btc as collateral. There are 1 or more public keys/addresses listed that can be used for 0 confirmation transactions. The user sends one of the insured transactions, referencing the collateral transaction id. Then lets say we find there isn't enough to cover that transaction. How would you unlock the collateral? I mean maybe it would be possible to rely on policy if you could prove to future nodes that at that time there was not enough funds...

@noone392 What do you mean by "not enough funds"? Not enough fees for the transaction to be added to the Blockchain at all? Then in my case Alice is not allowed to publish another transaction from the same addresses (and same UTXOs). Yes, this is a disadvantage. On the other hand, she could add 20 cents to the transaction output (Bob's address) and tell Bob "I'm publishing this zero-fee transaction and added 20 cents to the price - it is now your responsibility to chain it to another transaction sometime in the following month".

Ignoring technical implementation details, I'm not sure I see much benefit here. This idea might help stop intentional double-spends (low fee tx spends coins to victim, and then soon after a higher fee tx double spends those coins back to the attacker), but it does nothing to stop low fee txs simply not confirming (which could be seen as another form of zero-conf attack). Worse: it gives less options to a legitimate sender, as they can no longer RBF a stuck tx!

@chytrik The receiver (Bob) could always chain another transaction to himself, with increased fees, if he sees that the transaction takes a huge amount of time. It allows a trusted to "pay and go", leaving the fee optimization to be handled by the receiver. The receiver doesn't even have to run a lightning-node, knowing that the miners operate as "watchtowers", and will punish Alice if she tries to cheat. The receiver can recheck the transaction after a week, and in case it wasn't added, chain it to another transaction with high fee to himself.

By chaining I mean that if we have a low-fee transaction A -> B1 (or even a zero-fee transaction), and the receiver wants it to be added to the blockchain, the receiver can create a high fee transaction to himself B1 -> B2, and the miners now have incentive to add both A -> B1 and B1 -> B2. This is without RBF. There must be a more official term for this practice but I haven't finished "Mastering Bitcoin" yet :)

@Oren yes, it allows child-pays-for-parent (CPFP) to still work, but I think RBF is more preferable in most real-world payment flows, and this proposal would render it unusable. Consider: if I'm receiving money, I just want finality, I don't want to have to pay (potentially unknown) fees in order to receive the payment. ie, "Here is a zero-fee tx, you can CPFP it to get a confirmation if you want" is a terrible UX (and incurs even more fees than just a single tx with a competitive feerate!).

@chytrik I don't think merchants care about immediate finality that much, otherwise we wouldn't live in a credit-card world... If something could guarantee that the money will eventually pass for a low fee, even after a week or two, why not? I agree that RBF is better than CPFP because it takes less blockchain space overall. Another possibility is to have the collateral contract require 3 signatures by the same address instead of 2, and Alice will send Bob two transaction: one with a low fee, and one with high fee but where Bob gets less. For example, the second transaction could have

@Oren its probably best to discuss this further in this site's chatroom, comments aren't well-suited to extended discussions https://chat.stackexchange.com/rooms/8089/mempool

additional $5 fee, where Alice gets $2.5 less to her change-address and Bob gets $2.5 less to his address. The second "RBF" transaction will be sent from Alice to Bob and not published to the miners. If Bob sees that the first transaction takes too long, he can use the second transaction. If Alice tries to cheat with a third transaction to herself, Bob will publish all 3 transactions to the miners and make Alice lose 5 BTC.


text:
Can I recover Bitcoin after security codes lost
My colleague says he still has 50-100 bitcoins on an old hard drive, but he can no longer access them because he does not have the security codes. It is an bitcoin-qt wallet I think. I have read some things about how I can remove the blockchain with the bitcoin core app. But does this also mean that I can get these bitcoins back in a way? Does anyone know what to do? A nice compensation awaits the real helping hand.

If a wallet is protected with a passphrase, it is not possible for someone to spend money in that wallet without knowing the passphrase.
This is arguably the most vital function of a wallet and any established wallet will implement this protection well.
Deleting local blockchain data accumulated by a wallet application has no effect on this aspect of wallet security.
Offering compensation likely leads to a deluge of tempting offers from thieves pretending to be recovery agents. I think it safest to assume they are all fake.

I depends on how secure of a password your colleague picked to secure their wallet. If it's not a very strong one, it may be possible to brute force. In a any case, make a backup of the wallet in case future developments in cryptography may allow the password to be cracked. And be wary of scammers offering wallet recovery services.

source: Stack Exchange

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

sort: votes


text:
How do I get to the bitcoin mining website, I have funds in my account that I need to withdraw!
How do I get to the website for Bitcoin mining I need to withdraw my bitcoins !!

Bitcoin was designed to be used without websites.
There is no single website for Bitcoin or for Bitcoin mining.
Mining Bitcoin nowadays requires special equipment and I don't know of any genuine business that provides mining as a service.
See

I received an email saying I have money from "Bitcoin bonus"
Is it normal to be asked for an advance fee on a withdrawal?

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


text:
Bitcoin dont start sync
My node stopped, bitcoin core does not start synchronizing. I opened the bitcoin log and found this error: Does anyone have a solution??
i2pd_daemon_1  | 05:58:04@64/error - SSU2: RelayIntro unknown router to introduce
i2pd_daemon_1  | 05:58:16@549/error - Garlic: Can't handle .....-......-AEAD-Ratchet message
i2pd_daemon_1  | 05:58:21@64/error - SSU2: RelayIntro unknown router to introduce
i2pd_daemon_1  | 06:02:37@67/error - Garlic: Can't handle .....-......-AEAD-Ratchet message
i2pd_daemon_1  | 06:02:38@67/error - Garlic: Can't handle .....-......-AEAD-Ratchet message
i2pd_daemon_1  | 06:05:06@549/error - Garlic: Can't handle .....-......-AEAD-Ratchet message
i2pd_daemon_1  | 06:07:30@378/error - Tunnels: Can't select next hop for .....-...........-...........-...........-...........-...........-...........-......
i2pd_daemon_1  | 06:07:30@378/error - Tunnels: Can't create inbound tunnel, no peers available
i2pd_daemon_1  | 06:08:17@549/error - Garlic: Can't handle .....-......-AEAD-Ratchet message
i2pd_daemon_1  | 06:15:36@67/error - Garlic: Can't handle .....-......-AEAD-Ratchet message

That looks like logs from the I2P daemon, not Bitcoin Core

CANT handle ECIES is inside the bitcoin log

Bitcoin Core doesn't use ECIES in any way or form.

i do stop and start bitcoin, its ok


text:
How to calculate checksum of Address using Python
Lower Bit Range:      245
Upper Bit Range:      256
The Checksum of address 1H5aq8vssj9fCKdw2mYEn8enzpUMEBsUZ7 is 9ed6e860.

I tried the following but got incorrect result 69e65f22
import hashlib
import base58
def calculate_checksum(address):
    # Decode the Base58 address
    decoded_address = base58.b58decode(address)
    # Get the address without the checksum
    address_without_checksum = decoded_address[0:-4]
    sha256_hash = hashlib.sha256(hashlib.sha256(address_without_checksum).digest()).digest()
    calculated_checksum = sha256_hash[:4]
       checksum = calculated_checksum.hex()
    return checksum
address = "1H5aq8vssj9fCKdw2mYEn8enzpUMEBsUZ7"
checksum = calculate_checksum(address)
print(checksum)

How is it correctly calculated using python?

Instead of adding requested details in comments, simply [edit] your answer with the items.  Take a look at the change I made to your question to see how I was able to format the code you added.

import hashlib
import base58
def calculate_checksum(address):
    decoded_address = base58.b58decode(address).hex()
    print(f"Checksum of {address} is {decoded_address[-8:]}")
    address_without_checksum = decoded_address[0:-8]
    sha256_hash = hashlib.sha256(hashlib.sha256(bytes.fromhex(address_without_checksum)).digest()).digest()
    calculated_checksum = sha256_hash[:4]
    checksum = calculated_checksum.hex()
    return checksum

address = "1H5aq8vssj9fCKdw2mYEn8enzpUMEBsUZ7"
checksum = calculate_checksum(address)
print(f"The calculated checksum is {checksum}")


text:
From a security standpoint, why might a desktop c-lightning user need an additional lightning wallet?
Many c-lightning tutorials on YouTube walk their listeners through
the process of setting up a c-lightning node followed by the installation of a wallet like Spark-wallet. I just don't get it why do I need such a lightning wallet.
My setup
Ubuntu Desktop LTS. Pruned Bitcoin Core with connections over Tor.
To make transacting through my c-lightning node more convenient I wrote this script.
I'm well aware that I could have written something even simpler were I to do it in Bash instead of in C.
I aliased in my .bashrc the path to the script, i.e. to its binary,
like so alias lcli='~/CS/SoftwareDevelopment/MySoftware/C/lcli/a.out'
and  the command to start the lightning daemon: alias ldaemon='lightningd --daemon'
My routine looks like so:
1. cd ~/.lightning/bitcoin && ~/CS/Bitcoin/c-lightning/lightning/tools/lightning-hsmtool generatehsm hsm_secret
I introduce the seed phrase which generates an unencrypted hsm_secret(I use no passphrase to generate it, just the seed).
lightningd.sqlite3 is already there and my pruned Bitcoin Core is running all the time.
2. I type lcli in the terminal and then interact with my script.
3. After transacting I shut down lightningd (through the same script).
4. I backup my lightningd.sqlite3 with another script and remove my hsm_secret.
Why would a user like myself want to use any wallet (other than that of their c-lightning node) at all? Can use of such a wallet offer any security advantages that I'm not aware of?
Is my routine of transacting insecure?

What do you mean with "a Lightning wallet"? Your c-lightning has a wallet already, and you're using it, so it appears you're talking about something else in addition - but I don't know what.

@Pieter I'm referring to software such as fulmo as well as to spark-wallet. I've not tried them yet, but they seem to be something one may use on top of their c-lightning node/wallet.

Just to be clear, is your routine to: start up your node -> transact -> shut down your node? If so, that is a somewhat insecure way to use the lightning network. If your node is not online, it cannot watch for peers attempting to rob you by publishing outdated channel states.

@chytrik Had I any public channels that would be very insecure. But I have only one private channel, so my node is not a routing node - there is only one peer on the opposite side of the channel and it is one of the top capacity nodes. You may think that I put too much trust in the node with whom I have a channel  .. but on the other hand the major advantage of my approach is that when I shut down the node and shred my hsm_secret the balance of the node cannot be confiscated (police raids, thieves, etc.).

Let me clarify some things here with the order

Many c-lightning tutorials on YouTube walk their listeners through the process of setting up a c-lightning node followed by the installation of a wallet like Spark-wallet. I just don't get it why do I need such a lightning wallet.

c-lightning accepts request only through the UNIX socket and this means that you can not use HTTPS to access it. This brings two problems:

You can not have a remote node and control it from outside your local network.
If you expose the API through a Rest API you need to manage the authentication, many tools did it with a js server or a plugin like jrest.

Spark Wallet is a web interface from c-lightning that exposes the API through rest protocol and gives you the possibility to manage the node with a mobile/web interface. So if you love the command line, c-lightning is enough

Ubuntu Desktop LTS. Pruned Bitcoin Core with connections over Tor. To make transacting through my c-lightning node more convenient I wrote this script.

Each run of your node is a lucky run because likely your lightning node asking for a block not yet removed by bitcoin core prune mode. There are plugins that implement safely the pruning mode like btcli4j

My routine looks like so: 1. cd ~/.lightning/bitcoin && ~/CS/Bitcoin/c-lightning/lightning/tools/lightning-hsmtool generatehsm hsm_secret

Super Safe I think so, you backup the node each run, but there is some corner case here. I will also assume that for now there is no "good" way to use a lightning network node, but also here there is another corner case, that I will explore below:
What is a lightning node (November 13, 2021)
There is no difference between lightning nodes right now, but we can make the following distinction:

Node that wants to use the lightning network to pay (only!)
Node that wants to be part of the network, so it pays and helps the other person to make payment (forward payment)

Now, you are in the first subset, so you use the node only to pay to throw a single private node, and it works because you are only one node and you pay directly to this node (A -> B). You can use also a key send option.
But when you could have a problem?
A problem can be when you will add a new channel to your network (aka: C), in this case, your payment can fail because your c-lightning node applies a technique that is called multi-part payment aka MPP, where the basic idea is to split the payment across channels, but if one of your channel capacity it is not enough, and it has not another alternative, it can fail.
Conclusion

Your procedure is it right? Depends on what you want to do, but yes for your use case. However, it will fail for the corner case described above.

In addition, the lightning network node is more from your usage, but it is also true the usage depends on what you want to do with lightning.
P.S: Another corner case is if you are a public channel aka D with another node, but this time id D with a channel open to you (D->A) and you are offline all the time, the node could (or should) want close a channel, because you are locking some funds with your bad uptime.


text:
What are 'accounts.sqlite3' and 'emergency.recover' and why might I want to back them up?
accounts.sqlite3 and emergency.recover are created in my ~/.lightning/bitcoin when I launch lightningd - they weren't created there some years ago.  What are accounts.sqlite3 and emergency.recover and why might I want to back them up?

The accounts.sqlite3 file is managed by the built-in plugin bkpr (the bookkeeper plugin). It tracks each individual coin movement that was performed while the plugin was running, and will give detailed information as to where your funds are at any point in time.
The emergency.recover file was introduced in version v0.12.0 and is equivalent to LND's Static Channel Backups (which is more of a emergency recovery rather than a backup, hence the name change). It contains the minimal set of information to know with whom you had a channel, what the funding parameters where, and how to contact them to ask them to shut down the channel. It requires cooperation from the peer, but in absence of a better backup it can be used to recover some funds. It is by no means a replacement for backups, rather a last ditch attempt at clawing back some funds. This file has to be backed up after each funding of a new channel, so ideally set up a cron job to do that for you.

emergency.recover was not generated back in 2021 when my friend funded their channel. They noticed the file some time in late 2022. Is emergency.recover's creation based on the content of lightningd.sqlite3? Is emergency.recover created for each open channel (even for those channels funded before version 0.12.00)?

It is indeed recreated each time a new channel gets funded from the lightningd.sqlite3, so a single channel opening after the upgrade will create that file.


text:
Is it doable to get the private keys from a Bisq wallet?
I do not mean getting the seed phrase - this I've already backed up. I do not see such a possibility from Bisq's GUI.
Is it doable to get the private key of a particular address of a Bisq wallet (much the same way as one would by executing dumpprivkey with bitcoin-cli)?


text:
Should I use one `hsm_secret` for both the mainnet and the testnet?
When I launch lightningd it generates hsm_secret in ~/.lightning/bitcoin
whereas launching lightningd with network=testnet generates hsm_secret in ~/.lightning/testnet.
These two files seem to be different as confirmed by
diff ~/.lightning/bitcoin/hsm_secret ~/.lightning/testnet/hsm_secret

returning some output.
Having in mind that hsm_secret may get corrupted and being concerned with the security of my funds I decided to generate hsm_secret from BIP-39 words
and back up both the phrase and the file.
After compiling c-lightning from source and generating [the mnemonic with Python, I then followed the documentation and run:
~/lightning/tools/lightning-hsmtool generatehsm hsm_secret

It generated hsm_secret in the current directory.
After trying ~/lightning/tools/lightning-hsmtool generatehsm hsm_secret testnet and finding out that it does not work I decided
to try using the same hsm_secret file for both the testnet and the mainnet, i.e. I
launched lightningd with network=testnet and replaced the auto-generated hsm_secret in
~/.lightning/testnet with the one I generated from my mnemonic and than did the same with network=bitcoin and ~/.lightning/bitcoin/hsm_secret. I was surprized to see that all seems to work fine,
e.g. newaddr generates tb1 addresses when on testnet and bc1 addresses when on mainnet.
What are the pros and cons of using the seperate hsm_secret files vs using only one file for both networks.?


text:
Destination is not reachable directly and all routehints were unusable - how might I remedy that?
After launching lightningd I get following:
2023-07-20T06:54:46.533Z UNUSUAL 038.............................................................8f--connectd: Feature 28 requires feature 20
2023-07-20T06:59:47.735Z UNUSUAL 038.............................................................8f--connectd: Feature 28 requires feature 20
2023-07-20T07:04:48.511Z UNUSUAL 038.............................................................8f-connectd: Feature 28 requires feature 20

Again, I replaced the digits of the amount with dots for the sake of privacy.
For the sake of avoiding privacy leak I replaced the characters of the long string with dots.
When trying to pay an invoice I get following from lightning-cli:
{
   "code": 210,
   "message": "Destination 03d..............................................fac is not reachable directly and all routehints were unusable.",
   "attempts": [
      {
         "status": "failed",
         "failreason": "Destination 03................................................fac is not reachable directly and all routehints were unusable.",
         "partid": 0,
         "amount": "7........0msat",
         "amount_msat": "7........0msat"
      }
   ]
}

My bitcoin.conf is
daemon=1
keypool=2

I get the same message from lightning-cli when lightningd is launched
over Tor.

Is your node new? Did you leave it running for some time after it got a connection? Try running lightning-cli listnodes and see if you get a big list of nodes out. If your node didn't catch-up with the graph, it can't route payments.

@DavidsonSouza listnodes returns two node ids: "02443262a10d7fd82415c428b615c85944e70cbb51504a65387ec50ebda26e9f8a" and "03864ef025fde8fb587d989186ce6a4a186895ee44a926bfc370e2c366597a3f8f".
My node has more than a year and I run it avery two months or so for a couple of days. Before posting this it has been up for four days. My gossip_store has 765 bytes, would removing it change anything?

That's why you can't pay. listnodes should return over a thousand nodes. I don't think there's a way to force lightningd to redownload gossip and deleting generated files isn't wise. You need to leave it running for a while to catch up the gossip announcements it missed.

Okay the following features are regarding the dual funding protocol
2023-07-20T06:54:46.533Z UNUSUAL --connectd: Feature 28 requires feature 20
2023-07-20T06:59:47.735Z UNUSUAL --connectd: Feature 28 requires feature 20
2023-07-20T07:04:48.511Z UNUSUAL 038-connectd: Feature 28 requires feature 20

The change that is breaking your node is this one https://github.com/ElementsProject/lightning/pull/5670 but I am not able to find your node version inside the post description so I do not know what it is happening in concrete. This happens because we are using an experimental feature and we are allowed to break experimental feature
BTW overall what is going on is that core lightning preserves your channel and gives you the opportunity to fix the error (some other implementation will close the channel in this case). So you are not able to pay the invoice because the channel should be disabled and your listfunds should have the connected set to false for the channel item.
To make this work you should fix the funding problem but this depends on your node status and requires more information to support you.


text:
Government disrupting reception of bitcoins. Is it possible?
I was thinking of a very specific scenario: Suppose we have a new organization, let's call it "WikiLeaks2", which receives donnations mostly in the form of Bitcoins. Suppose a national government tries to shut it down by disrupting its reception of funds, so they set up a number of miners with the code modified so they check each transaction against a list of black-listed Bitcoin addresses (among them, that of WikiLeaks2) and automatically reject a transaction coming to/from those addresses.
Let's assume this government has successfully set up moles deep within the organization, so any new reception address is known by its agents after a few minutes. Would they need to control 51% of mining power to make it impossible to send funds to such an organization, or would disruption be possible with a fewer percentage?
Which begs the question: who validates the acceptance/rejection of a transaction, done by the miners, is correct? I.e. who validates the validators?

Government can blacklist few addresses and ask Miners, PSPs and  banks (?) not to process transactions from / to these addresses (?).

Would they need to control 51% of mining power to make it impossible to send funds to such an organization

If you have less than half of the mining power:
You control what transactions go into blocks you mine. You can definitely slow down payments to WikiLeaks2. However, you can't prevent payments from going out forever. Other miners will look at the WikiLeaks2 transactions, see nothing wrong with them, and include them into their blocks. You cannot do a 51% attack because the honest nodes, working together, will simply overpower you.
If you have more than half of the mining power: (51%)
You can now prevent everyone else from getting blocks. This means that you can prevent transactions you don't like from getting confirmations forever.

Which begs the question: who validates the acceptance/rejection of a transaction, done by the miners, is correct? I.e. who validates the validators?

Certain network rules are never voted about - For example, transactions must be signed, a block must have a valid timestamp, you can't spend more bitcoins than you have, that sort of thing.
What bitcoin miners do vote about is what should be on this global, shared, ordered list of transactions.

According to David Schwartz's comment to the other answer, even with just 51% a dishonest miner could forcibly get all the mining rewards. After his explanation of why this is so, I think the same could be said of this case: with just 51% of hash-power, a government could effectively deny any transaction to/from a specific list of addresses, should they will to do so, for the block-chains they'd mine without those transactions would, in the long run, always be larger than those with them. Did I understand this right?

You understand it right. I've edited my answer to make it more clear.

Which begs the question: who validates the acceptance/rejection of a
  transaction, done by the miners, is correct? I.e. who validates the
  validators?

To the best of my understanding, a miner is like a transaction sponge that absorbs all transactions it can find nearest to it as it searches for a proper hash. I suspect it is possible for a miner to write software to reject transactions to a list of addresses. And then following the logic develop a line of ASICs to gain enough hash power to ensure they process the majority of blocks thus increasing the turn around time for transaction approvals to wikileaks.
While this seems like a good attack vector on paper, wikileaks could implement software to generate a new address for each donation making the blacklist impossible to implement in practice. Also this attack would be extremely easy to discover. To reliably slowdown transactions enough to make it worth their time, the government would have to control far more than 51% of the total hash power.
Corrected by David, 51% would be sufficient

They wouldn't need to control more than 51%. With 51%, they can ensure no transactions they don't approve of ever get into the block chain and they can earn every single block reward. All they do is only mine after their own blocks. Their chain will be longer than everyone else's put together.

Why can't I add to their blockchain? A coin slightly biased to heads will still flip tails from time to time

You can, for a few minutes. But since they control 51% of the mining and won't build on your block, eventually they'll produce a longer chain that doesn't include your block. Anyone who relied on a transaction in your block would be a fool and would soon be parted from their money. And since you'll never get your block reward, why would you bother?

That actually makes a lot of sense. It's like a random walk problem with too many steps out of place.

I thought that miners do have some control over what transactions they include - some, for instance, don't bother including transactions for less than 1 centi-Bitcoin, for instance, rather than passively accepting all (valid) transactions sent to them.

Yes, miners can configure their clients to control the transactions they accept, which is why the attack you outlined would be valid. By default however, most miners just absorb all transactions nearest them like a sponge to water.

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


text:
Bitcoin i have been asked to send money for a private key
Hi i have been asked to send money for funds that are nonspendable to receive a private key to unlock it, it's from bitcoin investing. How safe is this as i'm worried i wont receive the payment. It's currently sitting in my blockchain wallet account and it displays the funds as nonspendable until unlocked with a private key

This is a scam! There is no such thing as 'needing to pay to unlock a private key', this is just some nonsense the scammer made up to get you to send them more money. Cut your losses, do NOT send anymore BTC to this person.

Possible duplicate of How can I get a private key for this address - a common scam used for many years to steal money from people new to Bitcoin. Many many examples here. Read these other questions from people cheated in the same way as you.

This is most likely a scam! there have been a similar question recently Why do I have to deposit BTC as missing turnover
There is no need to send bitcoin or money to receive a private key or unlock a bitcoin wallet, be careful.

It's to unlock nonspendable funds says i need a private key to access it

If you need a private key there is plenty of free option to generate one, this site for example https://www.bitaddress.org you should still read and understand how to do it securely though

@Jay39 it's a scam. this is not how bitcoin transfers take place. they won't give you anything even after you send them more money.

It is not sitting in your blockchain wallet account. That's why you can't spend it. It is sitting in someone else's account which you are watching. Whoever set this up is trying to trick you into thinking that you have some claim or ownership over these funds. But you don't. They're not in your account at all, they're in someone else's account.


text:
Help recovering BitPay wallet Reward!
I had money sent to my wallet and couldn’t remember my encrypt password.  I had my 12 word recovery phrase written down but it’s abbreviated. I deleted my wallet which I shouldn’t have done because I’m sure I would have figured out the encrypt password by now and I’m going crazy with this recovery phrase. The way I store is 6 rows 2 words per row. 1st problem is I don’t know the order, it could go: left right left right... left right right left.... right left right...right left left right.  6 of the words I’m 100%.  4 words have 3 possible options. 1 has 2 options and the last could be a number of things.  I have the address that I had the money sent to (probably doesn’t help).  I know the name of the wallet (sure that doesn’t mean shit)     At this point I’m sure if I just knew the first and last word(the order) I’d figure it out.  I’d pay someone if I wasn’t certain they would take it plus how would they figure it out.  I’ve seen people that charge 10% but why wouldn’t they take it all? What can I do?   Is there a way to know which of my first two words are first

What can I do?

You could find tools that automate the trying of various combinations of seed-words. Some are mentioned in similar questions here. For example btctools, btcrecover. Use them or adapt them to your needs.

Lost my Bitcoin wallet and have only 11 out of 12 mnemonic seed phrase words. How can I get my Bitcoins?
Need help to recover blpckchain.info wallet, my wife forgot her password and the brute force with btcrecover is not catching the password

I would

Not involve other people in this.
Not use software I can't build from source code I read and understand.
Not use the software on a computer that is connected to any network.

If I had no success after a solid year of trying every day, I'd consider handing the problem over to a third party I had very thoroughly vetted.
Obviously if the wallet contains $3.65 or some other trivial amount - just forget about it, the time is not worth spending on this.

I looked at that but am not finding where to generate the different combinations

@Ryan. I don't think it will be easy. It may take some hard work on your part over a period of days, weeks or longer. Only you know whether the amount of money at stake justifies you investing more than 5 minutes of your time in looking at the tools and how to use them.

Let me ask you this. Is there a way to know which of my first two words is first? I seen For example, Satoshi Dice would always start with dice

@Ryan: not as far as I know. I believe any of the words in the dictionary can appear in any of the positions in the phrase.


text:
Can I add inputs from different accounts coming from the same Bitcoin HDWallet?
Say I have 1000 users, each one with its own account with paths m/49'/0'/{user.id}', and I am controlling received/sent funds.
Could I collect all the funds (i.e. inputs) in a sole fat transaction output even though they belong to different accounts of the same HD Wallet?

note that since you are using hardened keys at the user level public derivation won't be possible. if you instead use non-hardened keys at that level you can store the xpub for m/49'/0'/ on the server and and derive addresses for user level accounts. it's safer than storing the xpriv on a server which you would need to do for hardened derivation.

It might be, but that'd deviate from the standard, which would make the wallet much harder to export and manipulate in a different scenario, isn't it?

Yes. Each input has its own signature with which to sign, so as long as you possess the private keys (or a master private key above the account level), you can add those inputs into any transaction you want.


text:
How to create signature for the payload (data)using private key in java with bitcoinj?
I have private key as 'cUN9LNcEC54HAbWAwUs6coPSc72TcQYzxf4qSqdHJPVKSapeHzFj' and payload as 'hello', now how to create the signature for this payload using private key in java with bitcoinj library?
public static String createSignature1(String payload) throws NoSuchAlgorithmException {
    ECKey pubKey = ECKey.fromPrivate(publicKeyHash("cUN9LNcEC54HAbWAwUs6coPSc72TcQYzxf4qSqdHJPVKSapeHzFj".getBytes(StandardCharsets.UTF_8)));
    ECKey.ECDSASignature signatureBase64 = pubKey.sign(Sha256Hash.wrap(DigestUtils.sha256(Arrays.toString(payload.getBytes(UTF_8)))));
    Log.info("Signature is : " + signatureBase64);
    Log.info("Base64 encoded Signature is : " + byteArrayToHex(Base64.getEncoder().encode(signatureBase64.encodeToDER())));
    return byteArrayToHex(signatureBase64.encodeToDER());
}

The above code returning invalid signature.

https://bitcoin.stackexchange.com/questions/50562/how-to-sign-raw-transaction-given-a-private-key-and-sha-hash-in-java?rq=1 answer helped me to achieve this.

https://bitcoin.stackexchange.com/a/50579/100550 helped and saved time, thanks a lot @sven-williamson


text:
Can a bitcoin transaction from a specific bitcoin address be banned? (via mining pools)
Can a bitcoin transaction from a specific bitcoin address be banned? (via mining pools)
Suppose Satoshi Nakamoto wants to send some bitcoin from one of his bitcoin address, can the mining pools refuse to process it? (Considering China has 81% total bitcoin hashrate with their pools combined).
I heard that a mining pool could (if they want to) refuse to put your transaction into the mining block, so your tx would be stuck into the mempool, until some other mining pool would put it into the next mining block, but I heard this could not be done forever.
Thoughts?

Yes, miners can censor transactions. A mining pool (or solo miner) can choose to not add a transaction to any blocks that they create. And, of course, this can be done dynamically so that transactions that match whatever arbitrary rules they want can be disallowed.
However this only effects one mining pool or miner. Other miners will not necessarily follow the same rules. So if one miner is censoring transactions, then some other miner will probably include them in a block.
But it is also stupid for a miner to censor transactions. All transactions pay a transaction fee and by refusing to add a transaction to their blocks, they are voluntarily taking a lower payout. The transaction fees are there to incentivize miners to include transactions.

We don't know for sure, but I doubt it.
It's generally believed that the stakeholders of bitcoin (those who pay the miners) consider censorship resistant extremely important, perhaps the main reason for bitcoin to exist. If this is true, they won't pay for mining if it stops producing the censorship resistance the stakeholders want.
Stakeholders could switch to proof of stake or change the mining algorithm, causing the censoring miners to lose the value of their ASICs and be unable to pay for electricity. The next bunch of miners with the new algorithm will know that they must provide strong censorship resistance if they don't want to go broke.
But this is all speculation. We really won't know until and unless someone tries and we see whether the stakeholders tolerate it or not. It seems highly unlikely to me that any significant number of miners would ever take this chance since they would be endangering their own existence.

Or they can become miners themselves.


text:
Are Bitcoin transaction fees competitive?
I was listening today to their conversation about the transcation fees in Bitcoin and Michael Sailor's understanding stroke me as inaccurate.
Is there any direct incentive within the Bitcoin protocol itself to lower the fees?
I've found some people on the Web who claim that including a small number of feeless transactions is incentivized, allegedly in order to decrease the difficulty of finding the nonce.
I'm not sure about this matter - hence the question.
I'm aware of a range of indirect incentives like the incentive to try to keep Bitcoin users away from using other blockchains. There is also the incentive to collect as much with fees as possible in order to reinvest it in ASIC and the infrastructure. Such indirect incentives are outside of the scope of this question.
From what I read, the inner workings of mining are the following:

New transactions are broadcast to all nodes.
Each node collects new transactions into a block.
Each node works on finding a difficult proof-of-work for its block.
When a node finds a proof-of-work, it broadcasts the block to all nodes.
Nodes accept the block only if all transactions in it are valid and not already spent.
Nodes express their acceptance of the block.

First, a miner takes the transactions and their fees (step 2), and only after this step they compute their POW (step 3). However low the block reward, it
is still the fact of solving the puzzle that determines which node is going to confirm their block. I've found nothing
in the whitepaper that suggests that there is any relation between the fees of the transactions that were collected and the likelihood of
computing the POW.
There seems to be nothing baked into the protocol that can directly stop any miner from producing let's say almost empty blocks or blocks with transaction fees of their preference so long as they are winning POW contest and the transactions are valid.
Decades ahead in the world of diminished block rewards any miner's attitude towards the transaction fees does not give them any competitive advantage over another in finding the nonce... is my understanding correct?

There is no advantage or disadvantage for miners to include transactions, except for:

If they don't include transactions they don't receive the fees (which are still dwarfed by subsidy for now, but perhaps not forever), though fees can also be paid out of band.
It takes some time to build a block candidate with new transactions immediately after learning about another miner having broadcast another block. This time is short, but nonetheless nontrivial and may represent a loss of income (through subsidy) if it is wasted. Some miners therefore start working on an empty block immediately (which is certainly valid), and only in a second step switch to a candidate that includes transactions.

Bitcoin's consensus rules have no hardcoded amounts in them besides the subsidy. This means that miners are free to pick whatever transactions they like (as long as they are valid), regardless of fee. Due to block resource limitations (size pre-segwit, weight post-segwit, sigops, ...), the optimally rational choice tends to be to prefer transactions with high fee per weight. This effectively creates a block space market, where transaction creators bid for the rate-limited space available in blocks.
Some protocol rules on the public P2P network have additional rules for relay. For example, there is a minimum relay feerate (1 sat / vbyte), and replacement transactions have to "pay" some feerate for the bytes of the transactions they replace. Their minimum values are not set by the market, but by policies implemented by the network's node software. They can also be bypassed by submitted directly to miners. During times of contention, these rules are mostly irrelevant, as the markets will force transactions to pay higher feerates anyway.
A long time ago, the default mining software that came with the Bitcoin client included a policy that would reserve a small area per block for "free transactions", which were selected based on "priority" (which was defined in function of age and value of the UTXOs spent rather than fee). I believe this was intended to promote cheap transaction usage. It was purely a client-side choice that was uneconomical for miners.

Is the minimum fee of 1 sat/vbyte  in Electrum wallet an example of such an additional rule for relay? Is it is implemented by Electrum software rather than Bitcoin Core?

It is a relay rule implemented in Bitcoin Core. Electrum probably enforces it because of the existence of that relay rule, as its transactions would fail to propagate without it.


text:
Core Lightning: "Ran out of routes to try after 15 attempts [...]" Why aren't my payments going through?
I run a core-lightning node with six active private channels with two nodes (ACINQ, allNice | torq.co) and over last couple of months most of the payments that I attempt fail with the output such as this:
{
   "code": 210,
   "message": "Ran out of routes to try after 15 attempts: see `paystatus`",
   "attempts": [
      {
         "status": "failed",
         "failreason": "failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote)",
         "partid": 0,
         "amount_msat": 50000000
      },
      {
         "status": "failed",
         "failreason": "failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote)",
         "partid": 1,
         "amount_msat": 50000000,
         "parent_partid": 0
      },
      {
         "status": "failed",
         "failreason": "failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote)",
         "partid": 2,
         "amount_msat": 50000000,
         "parent_partid": 1
      },
      {
         "status": "failed",
         "failreason": "failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote)",
         "partid": 3,
         "amount_msat": 50000000,
         "parent_partid": 2
      },
      {
         "status": "failed",
         "failreason": "failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote)",
         "partid": 4,
         "amount_msat": 50000000,
         "parent_partid": 3
      },
      {
         "status": "failed",
         "failreason": "failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote)",
         "partid": 5,
         "amount_msat": 50000000,
         "parent_partid": 4
      },
      {
         "status": "failed",
         "failreason": "failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote)",
         "partid": 6,
         "amount_msat": 50000000,
         "parent_partid": 5
      },
      {
         "status": "failed",
         "failreason": "failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote)",
         "partid": 7,
         "amount_msat": 50000000,
         "parent_partid": 6
      },
      {
         "status": "failed",
         "failreason": "failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote)",
         "partid": 8,
         "amount_msat": 50000000,
         "parent_partid": 7
      },
      {
         "status": "failed",
         "failreason": "failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote)",
         "partid": 9,
         "amount_msat": 50000000,
         "parent_partid": 8
      },
      {
         "status": "pending",
         "failreason": "failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote)",
         "partid": 10,
         "amount_msat": 50000000,
         "parent_partid": 9
      },
      {
         "status": "failed",
         "failreason": "failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote)",
         "partid": 11,
         "amount_msat": 24540318,
         "parent_partid": 10
      },
      {
         "status": "failed",
         "failreason": "failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote)",
         "partid": 13,
         "amount_msat": 24540318,
         "parent_partid": 11
      },
      {
         "status": "failed",
         "failreason": "failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote)",
         "partid": 12,
         "amount_msat": 25459682,
         "parent_partid": 10
      },
      {
         "status": "failed",
         "failreason": "failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote)",
         "partid": 14,
         "amount_msat": 25459682,
         "parent_partid": 12
      }
   ]
}

lightning-cli decodepay lnbc500u1pnsyhulpp52adw3d2e8j7dz865n2j68h0gv25pzfpkrk3n7zmeu9x0e3f6a8qqdqqcqzzsxqrrssrzjq222c0sfnhhs8sf2xl3slefkfvfz8ltqq6vxj9pwl9jcpjzrnshq5rfzngqqzpqqqyqqqqqqqqqqraqq2qsp5q55vex6ghdwey3x0e6mf9xq4yh0g9302j0qppd84vlnfgcrgtj2q9qyyssqrglwd2sk5ergcqrgdf7c9jk9dhqchpr8mg26p5328qw8xd8jg32ythkax933n8ulf2lnwnd7707s3gyw3llcepfx5k5337lqx2y897gp4ttp6u returns
{
   "currency": "bc",
   "created_at": 1728208799,
   "expiry": 3600,
   "payee": "0271173e6139975a9eda1363b47b2a03290e4adc2f89c32fec4737bb4422180a74",
   "amount_msat": 50000000,
   "description": "",
   "min_final_cltv_expiry": 80,
   "payment_secret": "0528cc9b48bb5d9244cfceb692981525de82c5ea93c010b4f567e69460685c94",
   "features": "024200",
   "routes": [
      [
         {
            "pubkey": "0294ac3e099def03c12a37e30fe5364b1223fd60069869142ef96580c8439c2e0a",
            "short_channel_id": "******x****x*",
            "fee_base_msat": 0,
            "fee_proportional_millionths": 500,
            "cltv_expiry_delta": 80
         }
      ]
   ],
   "payment_hash": "575ae8b5593cbcd11f549aa5a3dde862a81124361da33f0b79e14cfcc53ae9c0",
   "signature": "304402201a3ee6aa16a6468c00686a7d82cac56dc18b8467da15a0d22a381c7334f24454022045dedd3163199f9f4abf374dbef3fd08a08e8fff8c8526a5a918fbe0328872f9"
}

lightning-cli getroute 0271173e6139975a9eda1363b47b2a03290e4adc2f89c32fec4737bb4422180a74 50000000 10
{
   "code": -32602,
   "message": "0271173e6139975a9eda1363b47b2a03290e4adc2f89c32fec4737bb4422180a74: unknown destination node_id (no public channels?)"
}

Increasing the fee to 2% has not solved the problem, lightning-cli -k pay maxfeepercent=2 bolt11=lnbc500u1pnsyhulpp52adw3d2e8j7dz865n2j68h0gv25pzfpkrk3n7zmeu9x0e3f6a8qqdqqcqzzsxqrrssrzjq222c0sfnhhs8sf2xl3slefkfvfz8ltqq6vxj9pwl9jcpjzrnshq5rfzngqqzpqqqyqqqqqqqqqqraqq2qsp5q55vex6ghdwey3x0e6mf9xq4yh0g9302j0qppd84vlnfgcrgtj2q9qyyssqrglwd2sk5ergcqrgdf7c9jk9dhqchpr8mg26p5328qw8xd8jg32ythkax933n8ulf2lnwnd7707s3gyw3llcepfx5k5337lqx2y897gp4ttp6u, does not work:
{
   "code": 210,
   "message": "Ran out of routes to try after 4 attempts: see `paystatus`",
   "attempts": [
      {
         "status": "failed",
         "failreason": "failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote)",
         "partid": 0,
         "amount_msat": 50000000
      },
      {
         "status": "failed",
         "failreason": "failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote)",
         "partid": 1,
         "amount_msat": 50000000,
         "parent_partid": 0
      },
      {
         "status": "failed",
         "failreason": "failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote)",
         "partid": 2,
         "amount_msat": 50000000,
         "parent_partid": 1
      },
      {
         "status": "failed",
         "failreason": "failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote)",
         "partid": 3,
         "amount_msat": 50000000,
         "parent_partid": 2
      }
   ]
}

The payments never fail when I am trading on robosats, they almost always fail with kucoin and bitrefill.
I have six active private channels and one inactive private channel (its state is "AWAITING_UNILATERAL"),
listpeers returns:
"peers": [
      {
         "id": "03864ef025fde8fb587d989186ce6a4a186895ee44a926bfc370e2c366597a3f8f",
         "connected": true,
         "num_channels": 6,
         "netaddr": [
            "3.33.236.230:9735"
         ],
         "features": "a0882a8a6981"
      },
      {
         "id": "0326e692c455dd554c709bbb470b0ca7e0bb04152f777d1445fd0bf3709a2833a3",
         "connected": true,
         "num_channels": 1,
         "netaddr": [
            "sioo43tvkudx56ksir3ndwynv2df3356dpjc6s4yy3abjtcmsys6wnad.onion:9735"
         ],
         "features": "80000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a0008a8a51a1"
      }
   ]
}

whereas listpeerchannels returns this.
I use LN over TOR, my config is:
proxy=127.0.0.1:9050
always-use-proxy=true

Am I being censored?


text:
How could pool-resistant mining change the censorship resistance of Bitcoin?
Researching mining centralization in Bitcoin, I came across Wownero's solo-mining only pool resistance. There do not seem to exist any pool
mining Wownero as shown in miningpoolstats.stream.
Let us assume that Wownero's idea of pool resistance gains so much traction that either
1. Bitcoin users upgrade it with a hard fork that requires every mining client to provide the arguments such as --receive-address {YOUR-ADDRESS} --secret-key {SECRET-SPENDKEY} in order to start mining, making Bitcoin pool-resistant
OR
2. Bitcoin users upgrade it with the same hard fork as in 1 but the users also change the mining algorithm to the ASIC-resistant RandomX.
In either of these cases some states now move to the competion stage, attempting to
obtain the majority of hashpower in order to censor.
In case 1 the states do it by operating tax-subsidized ASIC
farms. The states initially confiscate ASICS from exisiting miners,
buy ASICs on the free market, and finally subsidize also the production of
ASICS.
In case 2 some states may force their citizens to use distributions
for desktop computers such as deepin that would come with the mining software
with government receiving address and the corressponding private key hardcoded into it.
The mining process on such computers would be fine tailored to user's activity,
e.g. a script running on in the background on a laptop would detect if the power cable is plugged in.
Mining software would only start mining when not on battery power (this
to avoid public discontent and productivity loss). Desktop PCs that are not laptops would perhaps be obliged
to run more aggressive mining operations. In the West, the governments may force corporate vendors of operating systems to include miners preinstalled, be such systems proprietary (Windows, Apple) or free as in the case of PopOS.
In either of two cases the proceeds from mining (the coinbase transaction and in the case of not
opting for mining empty blocks some whitemarket transaction fees) are meant to be used by attacking states to
subsidize further subsidize the attack. That is not always the case. In case 1 some operators of the ASIC-farms
steal the proceeds (the states may try to counteract this by granting monetary benefits for honest mining-farm operators).
In case 2 every computer savvy individual can just send this Bitcoin to themselves.
My questions:
1. How does the attack surface change for Bitcoin in case 1 and in 2?
What are other strategies of attack that I did not describe?
2. How does security of holding Bitcoin changes for non-attacking black market miners.
Everybody who has enough access to their PC to run "ps aux|grep -i bitcoind" can now get their private key.
They may ,for the sake of saving on transaction fees, use the same wallet for mining and for spending.
3. Given the high variance of reward in solo mining as the result low blockrate of Bitcoin, are
coins such as Kaspa, that have high (1-10 per second) block emission rate, advantaged as being black market money
due to their capability of offering lower variance of reward to their miners?


text:
Force-closure of unknown channel: What do status `Loaded from database` and the state AWAITING_UNILATERAL mean?
I noticed that the majority of my lightning payments fail despite increasing the fee. It's been like this over the last two months.
Investigating this matter, I found an inactive channel in the output of listpeerchannels:
      {
         "peer_id": "03864ef025fde8fb587d989186ce6a4a186895ee44a926bfc370e2c366597a3f8f",
         "peer_connected": true,
         "reestablished": false,
         "channel_type": {
            "bits": [
               12,
               22,
               46
            ],
            "names": [
               "static_remotekey/even",
               "anchors/even",
               "scid_alias/even"
            ]
         },
         "updates": {
            "local": {
               "htlc_minimum_msat": 1,
               "htlc_maximum_msat": 7549746000,
               "cltv_expiry_delta": 34,
               "fee_base_msat": 1000,
               "fee_proportional_millionths": 10
            }
         },
         "last_stable_connection": 1721499560,
         "state": "AWAITING_UNILATERAL",
         "scratch_txid": "991419d10eb2f1f01596e68eac18dafcb34b24ff7a03e21936a739c4128cd460",
         "last_tx_fee_msat": 2888000,  (my note:  Saturday, 20 July 2024 18:19:20 GMT)
         "lost_state": false,
         "feerate": {
            "perkw": 2276,
            "perkb": 9104
         },
         "direction": 0,
         "channel_id": "881895f720246c99b6d4d9278510d37370344239e2e235f5e61c792ec495ea0e",
         "funding_txid": "0eea95c42e791ce6f535e2e23942347073d3108527d9d4b6996c2420f7951888",
         "funding_outnum": 0,
         "close_to_addr": "bc1pv5jzxk7h60ea3wnk4a92yxjufdyj7689fc936yn0ln5d7q4ykwnsc46cgf",
         "close_to": "51206524235bd7d3f3d8ba76af4aa21a5c4b492f68e54e0b1d126ffce8df02a4b3a7",
         "private": true,
         "opener": "local",
         "alias": {
            "local": "740013x9434280x28179"
         },
         "features": [
            "option_static_remotekey",
            "option_anchors_zero_fee_htlc_tx",
            "option_anchors",
            "option_scid_alias"
         ],
         "funding": {
            "local_funds_msat": 16777215000,
            "remote_funds_msat": 0,
            "pushed_msat": 0
         },
         "to_us_msat": 16777215000,
         "min_to_us_msat": 16777215000,
         "max_to_us_msat": 16777215000,
         "total_msat": 16777215000,
         "fee_base_msat": 1000,
         "fee_proportional_millionths": 10,
         "dust_limit_msat": 546000,
         "max_total_htlc_in_msat": 18446744073709551615,
         "their_reserve_msat": 167772000,
         "our_reserve_msat": 167772000,
         "spendable_msat": 16602238000,
         "receivable_msat": 0,
         "minimum_htlc_in_msat": 0,
         "minimum_htlc_out_msat": 1,
         "maximum_htlc_out_msat": 7549746000,
         "their_to_self_delay": 144,
         "our_to_self_delay": 720,
         "max_accepted_htlcs": 30,
         "state_changes": [
            {
               "timestamp": "2024-07-20T18:20:19.887Z",
               "old_state": "CHANNELD_AWAITING_LOCKIN",
               "new_state": "AWAITING_UNILATERAL",
               "cause": "protocol",
               "message": "channeld: received ERROR channel 881895f720246c99b6d4d9278510d37370344239e2e235f5e61c792ec495ea0e: unknown channel"
            }
         ],
         "status": [
            "Loaded from database"
         ],
         "in_payments_offered": 0,
         "in_offered_msat": 0,
         "in_payments_fulfilled": 0,
         "in_fulfilled_msat": 0,
         "out_payments_offered": 0,
         "out_offered_msat": 0,
         "out_payments_fulfilled": 0,
         "out_fulfilled_msat": 0,
         "htlcs": []
      }

I have no use of this channel and so I tried to close it,
sudo lightning-cli close 881895f720246c99b6d4d9278510d37370344239e2e235f5e61c792ec495ea0e returned
{
   "code": -32602,
   "message": "id: Channel id not found: invalid token (see logs for details)"
}

Over the last months I attempted to benefit from low fees by opening
lightning channels paying 2-3 sats/vbyte in fees. I did it over poor, intermittent connectivity, and
I was frequently shutting down my node while the funding transaction was still unconfirmed.
I have private channels, 6 with ACINQ's node and 1 with ALLNICE | TORQ.co.
From what I gathered from the values of last_stable_connection and timestamp (of the last state change)
the channel was force-closed before it was locked-in with six confirmations. Yet,
it has been a week since the inactive channel and there
is no history of any transaction involving close_to_addr.
1. What does status Loaded from database mean and why is the channel referred to as unknown?
2. Can it be that my node was flagged by ACINQ node after this force-closure was triggered.
Might this the cause of the failure of my payments?
3. Should I do anything about it? How much sats am I going to loose with this
force-closure?
4. How could I prevent similar issues from happening in the future?


text:
Should I stop bitcoind when backing up chainstate/ and blocks/ directories?
This is how one might back up their Bitcoin Core data directories in order to save time on syncing in the future:
#!/usr/bin/bash

local_d=/root/btc_db

rsync -av --delete chainstate "$local_d"
rsync -av --delete blocks "$local_d"

Sometimes backups to a remote location take quite a long time, and so there may a lag of many
block in between rsync -av --delete chainstate "$local_d" and rsync -av --delete blocks "$local_d". Will Bitcoin Core sync seamlessly when being fed chainststate/ directory backup that corresponds to a different block height
than blocks/ directory?


text:
There is something wrong with my wallet
I currently have 1,557,166BTC=27.841,23 dollars. And I have a transfer right now at Blockchain. And this is like the sixth time, in the last two months, that I've had a transfer, and was unable to receive none of it. And this withdrawal will be my very first, and I have a back payment that they have been trying to help me complete. But I am unable to because, Everytime I scan the QR code to send the $65 in Bitcoin, whenever the next page pulls up there is always a message at the bottom of the page, that says, I don't have enough coins in the account. And it suggests that I input other numbers. But no matter what I try to do? Nothing ever works no matter what I input? And because I have been unable to withdrawal the funds, now I'm in jeopardy of my account being terminated and I just don't know what to do? I have reached out to the people that has tried to reminds me to make the withdrawal. And I've been in contact with them through email, and I've tried to let them know that my side of my account does not reflect the amount, that I'm told that I have.(1,557,166BTC) Once I scan the QR code the message appears and there is nothing that I can do. I'm in jeopardy of losing my account because I have been unable to complete the withdrawal. I really need some help. I have a transfer right now at Blockchain and I have about 24 hours left to complete the withdrawal, and if I can't withdrawal the funds within the last 24 hours, I just might lost the money and account. I really don't know who to talk to? Who to ask? It what to do? Can someone please help me? Or give me some advice that can and will solve my issue, so I can receive my Blessing? Thanks

Does this answer your question? Is it normal to be asked for an advance fee on a withdrawal?

Have you checked the balance of your address on the block chain ?


text:
Bitcoinsground freeze my account when i asked for withdrawal?
"Hi everyone, I’m having a serious issue with the Bitcoinsground platform. They have frozen my account and are not allowing me to withdraw my funds. They’re asking me to double my funds before they will unfreeze my withdrawals. Has anyone else experienced this? Any advice on what steps I should take to resolve this? Thanks in advance for your help!"

Also see How do I recover from a cryptocurrency scam


text:
Unexpected additional output in transaction
https://explorer.btc.com/btc/transaction/c5069dd52612dd07cfff6a2c587356497a2f8e7489923376a92420850fe27d09
I only did an 0.01 transfer to freebitco.in but somehow it puts an additional 0.027 BTC transfer to an unintended address in there. How can I cancel it, please help fast, I don't understand why this is happening.
I was able to cancel the before this transaction 0.01 with my core, but seems to have no impact to these 0.037 transaction(0.01+0.027), I even am trying to send the remaining from my core wallet to the same intended address, but the option to cancel the faulty transfer is yet not being shown.
v25.0.0 bitcoin-core.exe

Are you sure the filename is bitcoin-core.exe and not bitcoin-qt.exe?

See also Is bitcoin.org or bitcoincore.org the one to trust? bitcoin.org seems to be providing v25 but the latest version at bitcoincore.org is v27.


text:
Withdrawal profits
Ok so let’s say I buy a one bitcoin for 90k it peaks at 94k I withdraw the profit of 4K .if then it drops to 93k does that mean I now have a profit of 3k still or do I have to wait for it to drop back to the original price I paid for it being 90k and for it to peak again to make another profit ?? Need some clarity thanks heaps

You start with 90000 USD.

You have 90000 USD

You buy 1 BTC at a rate of 90000 USD/BTC

You have 1 BTC

The exchange rate rises to 94000 USD/BTC.

You have 1 BTC

You sell the 1 BTC for USD at a rate of 94000 USD/BTC.

You have 94000 USD

The exchange rate drops to 93000 USD/BTC.

You have 94000 USD

Unless you bought BTC again, you didn't lose anything.

The heart of your misunderstanding is "withdraw profits".
Once you have the reality clear in your head, the rest is simple arithmetic, the sort of adding, subtracting, multiplying and dividing you learned when you were a small child.

Lets do some adding, subtracting multiplying and dividing  ...

Holdings
$ value
₿ value

$90k
90,000
1

₿0
0
0

Totals
90,000
1

I buy a one bitcoin for 90k

Holdings
$ value
₿ value

$0
0
0

₿1
90,000
1

Totals
90,000
1

it peaks at 94k

Holdings
$ value
₿ value

$0
0
0

₿1
94,000
1

Totals
94,000
1

I withdraw the profit of 4K.

When you "withdraw the profit" what you are doing is selling some of your Bitcoin for dollars at the current exchange rate. After you have sold some of  your Bitcoin you have $4k but you now have less than 1 Bitcoin!
If the exchange rate is $94k = ₿1 then $4k = 4000 / 94000 = ₿0.042553191
To get the $4k you perceive as "profit" into your hands you have to sell ₿0.042553191 of your Bitcoin.
That means you now have ₿1 - ₿0.042553191 = ₿0.957446809

Holdings
$ value
₿ value

$4,000
4,000
0.042553191

₿0.957446809
90,000
0.957446809

Totals
94,000
1

In reality you also pay Bitcoin transaction fees to Bitcoin miners and probably pay conversion charges to the currency exchange. Most currency exchanges have "spread" or difference between their buying and selling rates. Most probably also have some other fee. It has probably been thus since people started making coins thousands of years ago. This is nothing new or special.

if then it drops to 93k does that mean [confused stuff]

If the exchange rate changes to ₿1 = $93k then

your ₿0.957446809 is worth 0.957446809 * 93000 = $89,042.55
your $4k is worth 4000 / 93000 =  ₿0.043010753

Holdings
$ value
₿ value

$4,000
4,000
0.043010753

₿0.957446809
89,042.55
0.957446809

Totals
93,042.55
1.000457562

Need some clarity

All the above is nothing to do with Bitcoin, the sums would be the same if you were were buying and selling diamonds or carrots. It is nothing to do with complex finance. There is no more to it than simple arithmetic.
"Withdrawing Profit" is not some deep mysterious magic. It just means selling some of something you own.


text:
Where does this 2^32 come from?
Several months ago I was doing research into calculating mining revenue for several crypto currencies. When trying to calculate BTC revenue I found this value 1/2^32 which was described somewhere along the lines of the probability of finding or solving a block. I found this on some website talking about the probability of finding a new block I think investopedia.
But how is this 2^32 found and how much does it change over time?

In Bitcoin mining, there are a few related terms:

The "target" is for a given block candidate the maximum permitted hash value (i.e., if the hash of the block ends up being lower or equal to the target, the block is proof-of-work valid). At the time of writing (block 737759), the target is 862674725460762741916416231468109512880228678412271616 in decimal, or 0x901ba0000000000000000000000000000000000000000 in hex.
The "maximum target" is the maximum value the target can be. There are various rules that govern what the target is for various blocks. It is updated every 2016 blocks depending on the time it took those blocks to be mined. If that time is more than 2 weeks, the target goes up (making mining easier). If that time is less than 2 weeks, the target goes down (making mining harder). The target cannot change by more than a factor 4 up or down. Lastly, the target can never exceed (216-1)2208, which is 26959535291011309493156476344723991336010898738574164086137773096960 in decimal, or 0xffff0000000000000000000000000000000000000000000000000000 in hex. We don't know precisely how this value was chosen, but it is related to how the target is encoded in blocks. It is an absolute upper bound on the target; if the adjustment rule would take it higher, this value is used instead.
The "work" for a block is the ratio between 2256 and the target. It corresponds to the expected number of hash attempts a miner needs to make for a candidate block, and is the inverse of the probability that any hash attempt is valid. If the target has its maximum value, its work equals 2256 / ((216-1)2208) = 248 / (216 - 1) ≈ 232 + 216 + 1. When determining which chain to accept among multiple valid candidates, Bitcoin nodes pick the one with the highest accumulated work (sum of all the work values in all its blocks). The current work value (per block) is 134224506433140884946014.
The "difficulty" of a block is the ratio between the maximum target and its target. It is a value that's only used for human consumption, and doesn't exist at the protocol level. The difficulty is always at least 1, because of the way it is defined. The current difficulty is approximately 31251101365711.12.

Armed with all these definitions, it is easy to see that there is a fixed ratio between the work and the difficulty of a block. That ratio is exactly the work of the maximum target, or the work at difficulty 1: 248 / (216 - 1) ≈ 4295032833.000015, which is slightly more than 232 + 216 + 1. In other words, the probability that any hash attempt leads to a valid block is approximately 1 over 232 times the difficulty. Perhaps that is the number you're wondering about.
If so, the answer is simply that this number is a side effect of how the difficulty is defined, and never changes. It has no relation to how mining actually works, because difficulty is purely a human convenience; the actual protocol works with target values.
Other systems can define difficulty however they want, but that would be off topic here.

Very helpful thank you so much! I may ask questions in the future when I have time to read through it more but it seems you have explained everything very well.

This is most likely probably tied to the difficulty.  If the difficulty level were to be 32, any given hashed block would have a 1/2^32 chance of being a valid block to append to the block chain.
At the time of writing this, the difficulty is 31.25.  It is possible that the article you were looking at was rounding.  It changes roughly every 2 weeks to account for the varying hash power that the miners around the world are putting towards the problem.  If more people are devoting energy towards mining, the blocks come a bit faster than desired, and the algorithm increases the difficulty to slow it down.  If lots of people suddenly stop mining, then the blocks come slower, and the algorithm will decrease the difficulty.
All that being said, this is just a guess.  If you can post a link to the article with context, it will be easier to figure out if that is truly the particular number you want.  There are other numbers out there.  For instance, blocks have a 32-bit nonce at the end of them, so a factor of 2^32 could appear there.

The current difficulty is not 31.25...

@PieterWuille This is the site I was using.  Or, more accurately, I just put "bitcoin current difficulty" into Google.  Did I perhaps misinterpret it?

It says 31.25 T; presumably the T stands for tera. The current Bitcoin difficulty is ~31251101365711.12.

@PieterWuille Ahh, thank you.  Gotta love missing a letter!  I guess that would put the difficulty, log base 2, at 44.83.  I guess that leaves me with my final comment - a number without scope is hard to explain.  It seemed convenient that 31.25 was so close to the number the OP was looking at that I jumped on it.


text:
Someone have stole my BTC
Someone have stole my BTC  is anyway to recover my BTC amount.
I use Copay wallet and someone from Russia has loged in my account and transfered to other account all my BTC.
Is anyway to recover my BTC ?

unfortunately not...you can look up your bitcoin address on the blockchain explorer and see the transaction and the address that received your bitcoins .How do you know it was someone from Russia?Is it someone you know?

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


text:
How do I get imported Bitcoin in my blockchain wallet without having to pay more for the private key?
ich habe Geld investiert anscheinend bei Betrügern, dass lief Alles über Facebook Messenger , ich habe ein Blockchain Wallet erstellt und dummerweise Wallet ID und Passwort rausgegeben, als es um die Auszahlung ging wollten Sie immer wieder Geld und dann war das Facebook Profil gelöscht. Vor ca 2 Wochen, wurde da Profil wieder aktiviert und Sie haben mir versprochen ,jetzt den Gewinn auszuzahlen , aber auf einem neuen Wallet und tatsächlich haben Sie Bitcoin auf das Wallet übertragen , aber nur " watch only" also importierte Bitcoin . Sie wollten wieder Geld für den Schlüssel , einmal habe ich gezahlt , danach wollten Sie wieder Geld und das mache ich nicht mehr , ich habe auch kein Geld mehr . Kann ich irgendwie an den privaten Schlüssel rankommen ? Die Betrüger sagen ja es ist mein Profit . Seltsam ist das diese importierte Adresse bekannt ist .
Bitcoin.org wird von der Community unterstützt: 3FkenCiXpSLqD8L79inRNXUgjRoH9sjXa

Translation by Google:
I invested money apparently with scammers that ran everything through Facebook Messenger, I created a blockchain wallet and stupidly gave out wallet ID and password, when it came to payout [they] always wanted money and then the Facebook profile was deleted. About 2 weeks ago, the profile was reactivated and [they] promised to pay off the winnings now, but on a new wallet and indeed [they] transferred Bitcoin to the wallet, but only "watch only" imported Bitcoin. They wanted money again for the key, once I paid, then [they] wanted money again and I do not do that anymore, I have no more money. Can I somehow get to the private key? The scammers say yes it's my profit. Strange is that this imported address is known. Bitcoin.org is supported by the community: 3FkenCiXpSLqD8L79inRNXUgjRoH9sjXa

You cannot get the private key. Your money is gone and you will not get it back. Report the crime to your local police.
Google's translation:

Sie können den privaten Schlüssel nicht abrufen. Dein Geld ist weg und du wirst es nicht zurückbekommen. Melden Sie das Verbrechen Ihrer örtlichen Polizei.

For more information see the answers to Reg: Watch only Address and the answers to the linked questions there. There are numerous other people who have been cheated in the same way.
Do not use the blockchain wallet you created. Any money you put there will be taken by the criminals who tricked you into giving them access to it. Their access cannot be revoked by blockchain or anyone else.

Actually, blockchain.info watch-only feature is an open door for criminals against bitcoin beginners. They should enable this feature for specific users.


text:
How to obtain transaction-ID for a payment?
I'm trying to create a transaction and send it to the blockchain.
The goal is to get an address from which the money comes and an address to which the money will go, send the transaction to the network, wait for the wallet owner from which the money comes to approve the transaction in his wallet and finally get the transaction address.
I can not understand how to do this without asking the wallet owner from whom the money was sent the private key.
I would appreciate your help,
Thanks!

Are you creating a custodial wallet service? What is the role of what you are creating?

No. What I need is simple, a customer enters a web form, enters his wallet address (from which bitcoin came out), address to which he will send the bitcoin, how much bitcoin to send.
I want to transmit the transaction to the network, the customer in his wallet (Electrum, Exodus Etc.) will confirm the transaction, it will be executed and finally I will receive the TxHash of the transaction.

I still don't understand. Why wouldn't the customer do the whole job in Electrum, Exodus etc. Why would they want to involve a 3rd-party web-page? Is this multisig escrow PSBT or something else?

They need to do the transaction through me so I get their TxHash automatically.

Well what you're asking for is fundamentally impossible. You need the user's wallet to produce the signatures in the transaction inputs. Without those, the transaction is incomplete, invalid, and the network won't relay such transactions.

I want to prepare the transaction for him, send it to the network, he will confirm it in his wallet and finally I will receive the transaction address

I manage to do it on the Etherium network and it works great. In Bitcoin I do not succeed

The Bitcoin network does not relay transactions that aren't valid. You'll need to communicate with the user out of band, using protocols like PSBT, to construct the transaction.

look at this: https://developer.bitcoin.org/devguide/payment_processing.html  By 'Requesting Payments' it is impossible to do so?

You "Request payment" by, for example, showing the customer a barcode (QR-code) that contains the address you want to be paid and the amount. Alternatively you just show them the address and amount in plain text. As that developer web-page implies, the customer creates the whole transaction themselves without any assistance. They might typically use a wallet app to scan the barcode and press "send". See https://bitcoin.stackexchange.com/q/4987/13866

The question is if there is a way I can do that and get TxHash automatically?

When your wallet observes any payment to the given address it will be able to calculate the TxHash.

The process described in the question is not the way normal transactions are created and processed in Bitcoin.
You can request payment by, for example, showing the customer a barcode (QR-code)† that contains the address you want to be paid and the amount. Alternatively you just show them the address and amount in plain text. As a developer web-page on payment processing implies, the customer creates the whole transaction themselves without any assistance. They might typically use a wallet app to scan the barcode and press "send".
When your wallet observes any payment to the given address, including unconfirmed payments, it will,  as part of verification, calculate the TxHash (Transaction-ID, a hash of transaction data).

There is provision for more complex forms of transaction. For example multisignature transactions and partially signed bitcoin transactions (PSBT). There is also Lightning, Liquid etc. However, it isn't clear from the information provided that any of these are relevant to you.

† See Bitcoin URL scheme


text:
How can I calculate the length (in bytes) of the Witness data in a transaction?
I'm trying to parse a bitcoin block.
I took as an example this block from 2019. I'm trying to parse the first transaction.
I don't understand how to calculate how many bytes I have to read for the "Witnesses"?
By "Witnesses", I refer to this table
Here is my result :
magic_no (4 bytes) : d9b4bef9
block_size (4 bytes) : 1236518
version (4 bytes) : 568442880
prev_hash (32 bytes) : 0000000000000000001437c1e52bc699fb299cac6d2a61a88210b995e45d603e
hash_markle_root (32 bytes) : ed3aba45d11a87c888ffb76a6af7cc1fbddd4a299f285379640c29188110fcf3
time (4 bytes) : 1575857336
bits (4 bytes) : 387308498
nonce (4 bytes) : 2292915727
Tx count (3 bytes) : 2735
Version (4 bytes) : [0 0 0 1]
Flag (2 bytes) : [1 0]
Tx In Count (1 bytes) : 1

*----- START TX Inputs -----*

*----- TxIn 1 -----*

Previous Tx Hash (32 bytes) : 0000000000000000000000000000000000000000000000000000000000000000
Previous Txout Index (4 bytes) : 4294967295
Tx In Script Len (1 bytes) : 85
Tx In Script (85 bytes) : 0348440941d77b6b2f7e726e41d77b6b2e3f8d4a2f4254432e544f502ffabe6d6d19437c0ebcb8916cb51c14eccc000373c8c56bac89feca39a132755acf337f158000000000000000e300518d901a000000000000
Sequence no (4 bytes) : ffffffff
*----- END TX Inputs -----*

Tx Out counter (1 bytes) : 3

*----- START TX Outputs -----*

*----- TxOut 1 -----*
Amount (8 bytes) : 1262724620
Tx Out Script Len (1 bytes) : 25
Tx In Script (25 bytes) : 76a914ba507bae8f1643d2556000ca26b9301b9069dc6b88ac

*----- TxOut 2 -----*
Amount (8 bytes) : 0
Tx Out Script Len (1 bytes) : 38
Tx In Script (38 bytes) : 6a24aa21a9ed36e74c1ca41a78209321759be06054f3ae9b3cd9feaa0f3979f5d9b5d02f286c

*----- TxOut 3 -----*
Amount (8 bytes) : 0
Tx Out Script Len (1 bytes) : 38
Tx In Script (38 bytes) : 6a24b9e11b6d04079a724511b5eac6db73004c5326521f1cc7f0104294285aec8a0dd3c59881

*----- END TX Outputs -----*

Here are the 128 next bytes :
[1 32 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 0 0 0 1 82 246 143 178 43 131 54 243 136 69 149 88 83 79 230 217 254 150 64 45 100 31 124 170 90 141 101 98 30 236 144 89 1 0 0 0 106 71 48 68 2 32 3 14 228 13 162 14 179 94 25 153 151 242 101 101 181 13 61 83 105 57 168 195 125 68 13 39 247 201 82 62 126 228 2 32 118 168 227 118 230 74 50 52 141]

The serialization format for witnesses is described in BIP144.
The rough structure is:

For each transaction input (implicitly, there is no separate indicator of how many inputs there are), there is a witness stack structure, consisting of:

A compactsize encoded number of stack elements
For each stack element:

A compactsize encoded length of the stack element
That many bytes for the contents of the stack element.

Applied to your bytes:

The is one input, so one witness stack

The first witness stack consists of:

1: the number of stack elements (1)
For each stack element

The first stack element

32: the length of the first stack element
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0: the contents of the first witness element (32 times the 0 byte)

0 0 0 0: the transaction's locktime

After that, the next transaction starts.

Thx, that's what I needed ! I just have a few questions ;)

Is number of stack elements always 1 byte ? As it must be the same as txIn count which is a VarInt, am I wrong ?

Same question for stack length, does it means a Witnesse can exed exceed 255 byte length ?

The numbers of witness stacks is always equal to the number of inputs (one per input). The number of elements in one stack is variable, and can range from 0 to roughly 4 million in theory. It is compactsize encoded, just like the number of inputs or outputs, and can be 1, 3, or 5 bytes. The length of stack elements also ranges from 0 to roughly 4 million in theory.

Or maybe it's 1 stack / Input => n element / stack (where n is 1 byte) ?

I believe your questions are addressed in my answer. Nothing is guaranteed to be 1 byte, every size/length/count is compactsize encoded, which may be 1, 3, or 5 bytes, depending on the value represented.

Ok I got it, I did'nt make the connection between compactsize and VarInt.. It's clear now, thx so much !

Ah yes, in the Bitcoin Core source code there are two variable-length integer formats, "compactsize" is the original one used in the P2P protocol, and another one "varint" which is only used in the local UTXO set database.

If there is a witness section in a transaction, the transaction must have one witness stack for each input. You therefore will expect the same number of witness stacks as the input counter. Each witness stack begins by telling you the number of elements in the stack. Each element in the stack starts by telling you its length.


text:
How do I correctly specify feerange of [slow,normal] on running lightling-cli close?
I close my lightning channels on Core Lightning with the following Bash script:
#!/usr/bin/bash

close_channel() {
echo -e "${ita}unilateraltimeout${end} in seconds?";read tmt
echo "Give the short channel id of the channel to be closed.";read scid
echo "Destination?";read dst
#lightning-cli -k close id="${scid}" unilateraltimeout="$tmt" destination="$dst" feerange="[slow, normal]"
lightning-cli -k close id="${scid}" unilateraltimeout="$tmt" destination="$dst" feerange="[2000,7000]"
}

close_channel

When feerange="[2000,7000]" is given, the command properly initiates channel's closing. But when given feerange="[slow,normal]" or feerange="[slow, normal]" I get the error message about the parameters being malformed:
lightning-cli: Some parameters are malformed, cannot create a valid JSON-RPC request: { "jsonrpc" : "2.0", "method" : "close", "id" : "cli:close#xxxxxx", "params" :{ "id" : "xxxxxxxxxxxxx", "unilateraltimeout" : 30000, "destination" : "bc1qxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", "feerange" : [slow,normal]} }

For the sake if privacy I replaced identuifying info with x.


text:
How do i I do a mutual close of a channel with a higher fee on Core Lightning after from the state CLOSINGD_COMPLETE?
I attempted to close one of my channels today by running:
lightning-cli -k close id=******* unilateraltimeout=10800 feerange=[1000,4000]
I got the following output:
         # Sending closing fee offer 424sat, with range 151sat-600sat
# Received closing fee offer 424sat, with range 424sat-424sat
{
   "tx": "*******************************************************************************************************************************************************************************",
   "txid": "***************************************************",
   "type": "mutual"
}

After a couple of hours the transaction is still unconfirmed onchain.
I tried to close the same channel again with a higher fee: lightning-cli -k close id=******* unilateraltimeout=10800 feerange=[3000,5000] but I got this error:
{
   "code": -32602,
   "message": "id: Channel in state CLOSINGD_COMPLETE: invalid token (see logs for details)"
}

The log, .lightning/bitcoin/log shows:
2024-12-15T13:54:28.075Z INFO    lightningd: JSON COMMAND close: Invalid parameter id (Channel in state CLOSINGD_COMPLETE): token '"******x****x*"'

Below are the channels state changes and status as show by the output of listchannels:
 "state_changes": [
            {
               "timestamp": "2024-08-14T06:27:46.645Z",
               "old_state": "CHANNELD_AWAITING_LOCKIN",
               "new_state": "CHANNELD_NORMAL",
               "cause": "user",
               "message": "Lockin complete"
            },
            {
               "timestamp": "2024-12-15T08:55:13.190Z",
               "old_state": "CHANNELD_NORMAL",
               "new_state": "CHANNELD_SHUTTING_DOWN",
               "cause": "user",
               "message": "User or plugin invoked close command"
            },
            {
               "timestamp": "2024-12-15T08:55:13.552Z",
               "old_state": "CHANNELD_SHUTTING_DOWN",
               "new_state": "CLOSINGD_SIGEXCHANGE",
               "cause": "user",
               "message": "Start closingd"
            },
            {
               "timestamp": "2024-12-15T08:55:13.952Z",
               "old_state": "CLOSINGD_SIGEXCHANGE",
               "new_state": "CLOSINGD_COMPLETE",
               "cause": "user",
               "message": "Closing complete"
            }
         ],
         "status": [
            "CHANNELD_NORMAL:Reconnected, and reestablished.",
            "CLOSINGD_SIGEXCHANGE:We agreed on a closing fee of 424 satoshi for tx:***********************************************************"
         ],

What could I do to solve this issue? Can the state CLOSINGD_COMPLETE of the channel change to a new state that would allow me to attempt to close the channel with a higher fee?


text:
Can collective mining pools refuse to recognize a mining block mined by a specific miner?
This is a continuation to the question:
Can a bitcoin transaction from a specific bitcoin address be banned? (via mining pools).
Suppose Satoshi Nakamoto sends bitcoins from one address to another, and some mining pools would refuse to add that specific transaction to the mining block (Considering China has 81% total bitcoin hashrate with their pools combined).
However a miner/mining pool adds Satoshi's transaction to the block they mined.
But, other mining pools had a different idea. They would not accept the version of the blockchain where Satoshi's transaction is in that specific block.
Essentially the other mining pools are calling a "fork" where they don't recognize the block where Satoshi did a transaction. Would it be against bitcoin protocol? If they somehow get away with it, considering they have the hashing power, what would happen to the other miners?
Would they accept the fork or just go along with it?

What you are describing is essentially a majority attack. A miner (or group of colluding miners) with a majority of hashpower can censor arbitrary transactions, and blocks that include them. This question has more info about what an attacker can do.
Crucially: a majority of hashpower can create blocks at a faster rate (on average) than the minority. So if the majority decides to not build upon a block that the minority found, they can reliably outrun the minority, by simply mining their own chain, and ignoring blocks found by the minority.

Essentially the other mining pools are calling a "fork" where they don't recognize the block where Satoshi did a transaction. Would it be against bitcoin protocol?

I wouldn't say it is "against the Bitcoin protocol", but it would be against the financial incentives which keep miners 'honest' (ie, not attacking the chain to censor transactions / blocks). Ultimately, the protocol does specify that the most-work chain is valid, so this becomes a tricky question about what the social understanding of the consensus rules really is.

If they somehow get away with it, considering they have the hashing power, what would happen to the other miners? Would they accept the fork or just go along with it?

A majority-attacker can ignore any blocks created by the minority, and if they do so, there isn't anything the minority can really do about it. Enacting the attack is extremely costly though, the financial incentive to attack would have to be unbelievably large in order to outweigh the cost. So I think that simply censoring one of Satoshi's transactions would not be worth the cost of the attack.


text:
Print wallet.dat with base64
I just wanted to ask If it makes sense if I want to print out my wallet.dat to encode it with base64?
I also read that the backup would become useless, if I get any receivements or make deposits and I would have to print out the wallet.dat again?
I would like to encode my wallet.dat with base64, print it and hide it in safe.
when my laptop breaks down and my other backups are also damaged (why every), i could scan my printed wallet.dat with OCR, decode it with base64 and just load it into the normal bitcoin client?
does this sound correct?
or are there any things I'm missing?
I dont want to rely on other software, no other web apps or key/password generators...

You are correct, and this is possible.
To summarise the wiki info on wallets, you can backup the wallet in any form you like in order to preserve the key pairs, transaction history and other useful information. The wallet may become badly out of sync but the backup is still fundamentally usable.
As wallets are often implementation-specific and needn't be distributed in the same handy fashion as Bitcoin addresses, your wallet.dat can be fairly large. The Base64 size of your wallet printout will be 4/3rds of the normal wallet size in bytes.
Six point font is smallest reliable size for most OCR applications. If I assume you are using the A4 standard, an single A4 page of 6pt monospace font can contain approximately 20,000 characters or 15 kilobytes of Base64 data. Duplex would make that 30KB per page.
Alternately you could use Version-40 QR codes, the information density per page could be several times higher. Finding an off-the-shelf open source tool for version-40 QRs could be hard, so you would be relying on third-party software; conflicting your question requirement.
When printing to paper instead of plastic, consider flame retardant paper treated with a safe insecticide to reduce the possibility of losing the key to insects or mild fire. Putting the printed key inside a black envelope inside a tamper-evident bag would also be a good idea.

To elaborate on "your wallet may become badly out of sync", by default, the reference client uses a key pool of 100 future keys. As a new key is used for change any time you create a transaction, your backup becomes useless as soon as you have made 100 transactions + public addresses with it. Deterministic wallets will provide a solution for this in the future.


text:
Bitcoin 0.8.5 - Paper wallet
since some answers seem to be outdated, I ask now explicit for version 0.8.5 of the official BitcoinQT-client.
I want to save my wallet to paper and hide them in a safe - could you tell me if following points look valid?
This topic seems really complex, I dont know why there is not an easy option like "Export wallet to pdf"...
Ok so here we go:
1) I would like to export my private keys to textfile?
(How does it work?) I only see how it works for one single private/public key-pair?
2) Print it out and hide it in safe
3) When I do a transaction or receive something, i should print out again all private keys, because otherwise something can be lost?
Thanks!

As of the 0.8.x series, the reference client does not support paper wallets. You can export individual keys, and print them to paper, but you are very likely to shoot yourself in the foot unless you're familiar with the implementation details.
In particular, change (the difference in value between coins used to create your transaction, and the amount being sent) is sent to a fresh address in order to increase privacy of the system. When you're using a paper wallet, you will likely miss these, as well as key pool entries.
There is support planned for deterministic wallets (BIP32), which means a single backup of a wallet seed will be enough to create the wallet. This may or may not end up in 0.9, though.
The reason why no "Export wallet to PDF" exists, is exactly because in the current model, this would result in many misconceptions and lost coins. Without deterministic key generation, no immutable dump of the wallet can survive (a series of) spends.


text:
Bitcoind Performance for production usage
Lets say we have one instance of bitcoind running on the production server. And our exchange software/application interacts with it using RPC callbacks for:

address generation
withdrawal
notifications

Now the question is
what is the capacity of bitcoind?
What would be the limit for number of transactions per minute?
What is bitcoind performance?
Any suggestions?

address generation

Make sure your using HD here (A wallet created with bitcoin core 0.13 will be HD).
Address generation is pretty fast, make sure your using a large keypool –keypool=5000 in the conf-file maybe.
Also, you can pre-generate addresses and stored them in a cache-database.
But be aware, if an attacker manages to compromise that cache-database, he can probably redirect funds.
Address generation can also be done outside of bitcoin-core. Check BIP32 (HD Wallets) and maybe have a look at public key derivation. If you need performance, have a look at libbtc (C library with CLI, can derive addresses very fast).

withdrawal

At this point, you very likely are stepping into the realm of "hot wallets". Make sure your building a secure environment.
This step involves ECDSA (signing of inputs) which requires the according private keys.
Signing is not very fast (depends on your requirement). But you can perfectly measure this with a regtest setup (sign 1000 transactions and measure performance).

notifications

Don't use -walletnotify (it forks a process = very slow).
Try to use ZMQ (you might need to add some extra code for the wallet).

Best way would be to measure and test this in your environment using bitcoind and testnet.
Keep in mind that if you want to increase your performance it should be possible to run different instances of bitcoind (just change the port number for RPC calls) and then devise a scheme (eg round robin) where you distribute the load between the different instances.