text:
How does bitcoin's price volatility compare to commodities/stocks with comparable market capitalizations?
Bitcoin's long term (after 21 million units have been created) market cap is about $102 million.
Price volatility of individual commodities/stocks is inversely correlated with their market cap, so price volatility is to be expected with bitcoin, but relative to commodities/stocks with similar market caps, does it have a volatile price?
I'm guessing that price volatility for bitcoin would be low relative to commodities and stocks with comparably sized markets because it has lower transaction costs allowing for a more liquid market, and I'd like to know if the data shows this to be the case, but I don't know where to start looking as I'm not very familiar with commodity and stock markets and trading.

I don't know of any data but I would guess it is higher, since its valuation has a more significant speculative component. I also don't think the costs of -trading- bitcoins is lower than for other assets.

Good point on the speculative aspect of it. The cost of trading bitcoin I think is quite low though. Mtgox's fee is maximum 0.6% per trade. The commissions I've seen on stock trading sites have been $5 per trade and up. I would guess commodities trading has an even higher minimum fee per trade.

I compared the standard deviation of (USD-denominated) price of bitcoins and the Russell Microcap Index Fund (IWC) which is an ETF (read: basket) of 1359(!) stocks with ca. 300million USD in market cap (each). This is a total apples to (buckets of) oranges comparison, but the results are as follows:
IWC std dev:            3%
MtGox BTCUSD std dev:  12%
FWIW, over the last 6 months, the USD-denominated price of bitcoins has been 4 times as volatile as a basket of approx. 1000 stocks with similar market caps.
For a slightly better comparison, the volatility of BTCUSD is about 10x that of EURUSD.
In my opinion, bitcoin is quite stable, especially considering the ubiquitous press of it being so unstable.
Regarding trading fees:
Mt Gox's lowest fees are very high (~0.4%) compared to competitive stock brokers, such as Interactive Brokers (~0.1% max). This is similar for commodity futures.
Regarding the speculative nature of bitcoins and market depth:
Stocks (esp. "microcap" stocks) are very speculative too, so stocks and bitcoins are similar in this regard. Similarly for any depth of market argument for stocks vs bitcoins, both can be moved by relatively small orders and have only a percentage available for trading on an exchange.

a basket of securities which are not perfectly correlated (such as the IWC) is necessarily going to be less volatile than the individual securities comprising it. So rather than looking for the stdev of the IWC, the more relevant metric would be the average stdev of each individual IWC component. otherwise you're not comparing apples to apples when you compare with bitcoin. do you happen to have access to the individual component data?

I wholly agree and tried to imply that with by saying "apples to (buckets of) oranges." I do have the data, from yahoo.com or google.com, e.g., http://www.google.com/finance/historical?q=NYSEARCA:IWC . You can get a list of microcap stocks (used in IWC, here: http://us.ishares.com/product_info/fund/overview/IWC.htm)

Great analysis, though on trading fees, while you're correct that those of discount brokers can be lower than MtGox's, these brokerages also place much more arduous conditions on traders, like IB's required deposit of $10K to open an account, and on trades, like IB's minimum fee of $1 per trade (so if you make a trade worth $10 of shares, you'll pay a commission totalling 10% of the value of the trade) which makes their fees in some circumstances much higher.
MtGox lets any one get in, and let's them trade very small amounts at a time without being heavily penalized with higher fees.

You wrote: "Price volatility of individual commodities/stocks is inversely correlated with their market cap". There is just a coincidental correlation between the two. Instead, I would say that there will be price volatility when investors are unsure about the value of an asset. You can see this with the value of for example Facebook. It is just very hard to judge the value of their assets, regardless of their huge market capitalization. Similarly, the value of Profit Points (which I invest heavily in at the moment) will heavily depend on the expectation of future profits of Open-org.com. On the other hand, one has government bonds, which have a very stable value, because it is relatively easy to calculate their value and there is usually not large risks involved.
Just to be clear about the value of Bitcoins...
If you buy Bitcoins you get a share of the future output of the Bitcoin economy.
You can see the master himself (Warren Buffet) explain this here. I believe that it is hard to judge what the future output of the Bitcoin economy will be, but it will be easier and easier the bigger the market capitalization of the Bitcoin economy, so for Bitcoins there will be a correlation between the two, but other factors like risk of government crackdown will also affect the volatility.

The size of a commodity/stock's market affects the certainty investors have about its future value. A smaller market means faster price changes are more likely since it requires a smaller percentage of the economy to buy or sell the asset to affect its price.

Theoretically, not a single trade needs to be made for an asset to increase or decrease in value. Let's for example say that Wal-Mart filed for bankruptcy today. It would not require any trading of their stocks to for them to have lost their value. I think that stability and large size is a general rule, but it is not the reason for a stable price.

You also need to consider the size of the holdings of individuals. If one individual holds a big proportion of the total capital, then they have the power to cause a large drop in the price by flooding the market. Similarly, anyone holding a large amount of cash can cause a spike in the price by purchasing many bitcoins. How much volatility is caused by both these cases depends more on the depth of the market than the total capitalisation.
The key thing to remember is that the current market value only applies to the number of coins available for sale at the current price. There are likely many bitcoin owners who won't sell for anything less than $20 or more, despite the current price of around $5. You couldn't buy all the bitcoins for $102 million, or even $200 million (even if the 21 million coins were actually already available, which they're not).


text:
Can I use opcodes traditionally used for verifying keys to verify payment sizes?
Can I use binary opcodes usually used for verifying keys to verify payment sizes?
It looks like these opcodes like OP_EQUALVERIFY and OP_NUMEQUALVERIFY are used for checking signatures or keys, rather than bitcoin amounts.
Example:
For an example use case, say my brother and I run a partnership, and all Bitcoin payments to our invoices go to a specific address.
The client would pay their invoice to a P2SH address, but any further spending from that invoice would have to go to my brother and I equally.
Conditions:
I want to lock outputs for a given input such that:

The bitcoin input can only be spent to two specific outputs*, my brother's address and mine
The amounts paid to these specific outputs must equal each other

*aside from change addresses
In the example above, could I use OP_NUMEQUALVERIFY or even the non-binary operator OP_GREATERTHANOREQUAL enforce that any client income was paid to me in an equal or greater amount than my brother?

This isn't possible.
You can use those arithmetic operators to compare any numerical values that you can get onto the stack - they are not inherently restricted to signatures and keys. But you would have to get the relevant data (output addresses, output amounts) onto the stack in the first place, and there is no opcode  to do that.   The script doesn't get to see that information, so you can't  restrict the spending of a transaction in such ways.
Related: Can an account define conditional tags to blockchain

// , Ouch, I think this puts it squarely in the stupid question category, since I asked based on incorrect assumptions about the way Bitcoin scripting worked in the first place

source: Stack Exchange

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

sort: votes


text:
What is the current growth rate of the bitcoin blockchain size month by month in 2020?
I'm looking to get a VPS to host a btc full node and would like to know how much space I should get and what is the current Bitcoin blockchain growth rate on a monthly basis?

Ok nevermind. Currently BTC blockchain takes up 300GB of space. Any online VPS would cost at least $50-$70 a month for just the 300GB space this isn't accounting for the growth of the btc blockchain of about 25% a year or 30GB or so a year. As an application developer this doesn't make sense to spend so much on building on top of BTC just for fun that requires a full node. I've finalized and just decided to just go with blockchair.com for the time being.

You can run a node in pruning mode, reducing the storage costs dramatically.

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


text:
Are coinbase.com purchases effectively bitcoin futures?
I just purchased 0.1 BTC from coinbase with a bank transfer. Coinbase informed me that the transaction would take 4 business days to complete.
So I don't have any bitcoins yet, but Coinbase promises to deliver 0.1 BTC to me in 4 days.
Coinbase probably didn't purchase the bitcoin now because my payment hasn't cleared, but if they make the purchase in 4 business days from now and the price has gone up from $330 to $500, how will Coinbase cover the difference when the coins need to be purchased?
Or does Coinbase just regularly purchase bitcoin and then just transfer some into my account when my funds clear? Or do they not actually give me the bitcoin until I decide to sell it?

One they credit your account you can transfer your bitcoin out to another wallet, you do not have to sell it through them, but you could at a later time if you wanted to.
Unfortunately Coinbase is also known to just cancel an order if the price sharply rises between you placing it and them delivering the bitcoin, your US dollars are then returned to your bank.

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


text:
How many unique Taproot addresses (eg pubkeys) are possible?
Given that Taproot (SegWit v1) addresses are basically equivalent to a public key -- does that mean that there are a full 2256 possibilities?  Or is the overall number of possible addresses reduced in some way?

Taproot outputs contain x-only (tweaked) public keys. Due to the lack of Y coordinates, the number of valid keys is halved.
The exact number of possible x-only keys is 2255 - 216210193282829828426210433197484072800.

The other half can still be made into valid SegWit v1 outputs (and therefore addresses), even though they would not be spendable, right?

That's right. The address format can encode X coordinates that don't have corresponding public keys, but any coins sent to such an output are irrevocably lost.

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


text:
Are there really Bitcoin Core nodes running in space that were launched by Blockstream?
I've read about Bitcoin core being powered in space inside a satellite and streaming down the bitcoin blockchain back down to earth. What has been discussed so far and timeline for this to go live for Blockstream?

Blockstream launched a satellite service. It did not launch a satellite.
Bitcoin blocks are being broadcast by Blockstream, by contracting with several existing several satellite systems. These satellites are primarily designed for broadcasting  TV signals, and thus don't run their own full nodes; the broadcast is dependent on ground stations that uplink the data.
The data is freely available from (nearly) every place on earth (excluding oceans and polar regions). You do need your own satellite dish and some other hardware, but the system is designed to keep the costs as low as possible.
For more information, see https://blockstream.com/satellite/

"(nearly) every place on earth", -- nearly every landmass, by large the oceans are not covered.

The satellites being used are designed for, and mainly used for TV broadcast. https://en.wikipedia.org/wiki/Eutelsat_113_West_A

@G. Maxwell, Anonymous: updated my answer

Unfortunately this seems to be pretty commonly confused. Press articles from blockstream about “launching blockstream satellite” seek to be intentionally deceptive.


text:
Is 30,000 rounds really needed for PBKDF2?
In the browser, I'm using AES-256-CBC with 128bit IV & PBKDF2 to encrypt the mnemonic
"tell file snow green proof evil six squeeze budget various orbit clock"

with a password
"s0mesuperl0ng!password@!"

with 30,000 rounds it's taking roughly 22 seconds. It feels too long, but I don't want to make it insecure.
Can I safely reduce the rounds to make it a bit faster? and if so what would be the minimum?
Could I get away with 10,000?

Why do you need multiple rounds of AES? Is this some form of key strengthening? Also 1400 rounds of AES is extremely slow, what software are you using?

This is just with JavaScript in the browser, the reason for the multiple rounds is to slow down a brute force attack and the use of PBKDF2 is to strengthen the password.

But the 30000 rounds is for PBDKF, not for AES, I assume?

yes we are passing in the password, iv, rounds and key size to PBKDF2, sorry if I wasn't clear

I'm editing the title.

I'm not an expert here, but AFAIK there isn't a bright line between "secure" and "insecure" and there's no well-defined minimum that is "safe".  Increasing the number of rounds causes a proportional increase in the amount of work a brute-force attacker would have to do, but also means verification will take longer.  It's simply a trade-off and you have to balance the patience of your users against the amount of resources you think an attacker might be willing to commit.

Nate, I totally agree, I was looking for some opinion on this gray area, I found 10,000 rounds at about 8 seconds reasonable, but I was looking for a reaction, like "hell no" or "10k seems cool" or the lowest I'd go is "x"

Can I safely reduce the rounds to make it a bit faster? and if so what would be the minimum?
Could I get away with 10,000?

Anyone trying to crack your encrypted data is not going to be limited by the speed of javascript executing in a browser. They'll be running FPGAs or something much faster than that. So 20,000, 10,000 or 0 doesn't make any sort of difference here.
Where I learned this

So your saying PBKDF2 is a waste of time and I shouldn't even bother? Should I be looking at Scrypt or Bcrypt?

That's not what i mean at all. I mean a low number of key stretching rounds isn't worth anything. You can't get a high number because javascript is slower than C compiled code and much slower than FPGAs. If you see that link G Maxwell talks about how Core does 200,000 rounds using just one CPU core. That's possible because its coded in C++.

So your saying 10-20,000 rounds in a browser isn't worth doing. As I'm stuck in the browser for this project, I guess I shouldn't bother with PBKDF2 or should I approach this problem differently?

Maybe AES-256-CBC is enough? if it is enough why is PBKDF2 thrown into the mix?

a key derivation function is used to derive a random number from a password. you run a kdf multiple times in order to make it harder for someone else to try and bruteforce your password. AES is an encryption algorithm. You use the output of the KDF to encrypt your file using AES. that's how the two fit in. My suggestion is to leave it at the default settings or if that is too slwo then lower the number of rounds. The most important thing you can do is just use a good password. Everything else is fluff.

Thank you Abdussamad, Is 30,000 or 10,000 rounds "the default settings"

if I force the user to enter a 9+ character password with upper, lower and special characters, would 1000 rounds be enough?


text:
What is preventing segregated witness from being activated
Segregated witness has been around since 2015 with good publicity and proponents since early 2016. It seems to have the benefits of solving transaction malleability, creating a good foundation for the Lightning Network, implementing script versions and most importantly a temporary transaction scaling solution.
Is the main reason for the slow miner adoption (https://coin.dance/blocks) because it means lower transaction fee's for them? And is a soft fork being avoided because a hard fork is preferred?


text:
How are off-chain transactions handled by bitcoind?
I'm trying to figure out how transactions are actually handled by bitcoind.
I'm looking at the full list of RPC methods and there are missing documentation for some most interesting methods.
move
I know there are two methods of moving bitcoins between addresses either via direct p2p transaction or via the so-called off-chain transaction. If I believe correctly, the built-in wallet of bitcoind allows us to send off-chain transactions via the move method. Sadly, it's not very well documented, but I want to know exactly how it works.
Here's the documentation for it:
move <fromaccount> <toaccount> <amount> [minconf=1] [comment]

Move from one account in your wallet to another

So, if account A has one BTC and account B has zero. What will happen if I first move one BTC from A to B using off-chain transaction and then issue a direct transaction of 1 BTC from B to C?
Also, what minconf parameter is for? As far as I understand, off-chain transactions doesn't require confirmations.

sendfrom
Here's the documentation for the sendfrom method:
sendfrom <fromaccount> <tobitcoinaddress> <amount> [minconf=1] [comment] [comment-to]

<amount> is a real and is rounded to 8 decimal places. Will send the given amount to the given address, ensuring the account has a valid balance using [minconf] confirmations. Returns the transaction ID if successful (not in JSON object).

It requires an account to send bitcoins from.

What if I have multiple addresses/transactions for the specified account? What strategy bitcoind uses to determine from which addresses to make a transaction and how much bitcoins to use from each?
What minconf parameter is for?

sendtoaddress
sendtoaddress <bitcoinaddress> <amount> [comment] [comment-to]

<amount> is a real and is rounded to 8 decimal places. Returns the transaction ID <txid> if successful.

The account is not specified for this call. What account bitcoind will use? The default one?
Why there is no minconf parameter for this one?

Many pages in the wiki are outdated, you might want to also check out the Bitcoin Developer Reference. This wiki page is deprecated, but explains Bitcoin Core's accounts functionality. As Shabahat M. Ayubi explained below, the accounts feature in Bitcoin Core is deprecated.

First of all, there are many types of off-chain transactions. Any movement of value in BTC that does not directly correspond to a blockchain transaction can be classified as one. This includes:

giving someone a computer/phone that has a wallet witg BTC on it
giving someone a private key/physical bitcoin.
giving someone access to a shared webwallet account
sending money from one account to another within the same service (which simply decrements one person's balance and increments another's balance)
payment channels, including Lightning, which negotiate a small number of transactions that correspond to the net effect of many more value transfers.

The move command in bitcoind does not result in an off-chain transaction; it simply increments one internal counter and decrements another. It is off-chain for sure, but it's hard to call it a transaction. All you've done is changed how you're counting the money you already have control over.
A service (like #4 above) could potentially use bitcoind's move command to implement a (simple) off-chain transaction system. But it at least requires having a setup where multiple people have accounts on your system, and them treating you as a custodial for their money.
As for the questions you're asking:

Accounts are a completely independent concept from addresses. From bitcoind's perspective, there is no such thing as an address balance. There is the wallet balance (how many coins the wallet has control over in total), and account balances (which are simply internal bean counters, with no relation to anything on the blockchain). When a new transaction sends M money to address A, and address A is associated with account C, the wallet balance goes up M, and the account balance for C goes up. When you send money with sendfrom, the named account is debited. But the actual on-chain transaction created always uses any coins the wallet has control over. Again: there is no relation between on-chain coins (transaction outputs) and account balances.
The move command used to do a balance check on the to-be-debited account, and fail if it did not have enough counting only transactions with at least minconf confirmations. This functionality was removed a long time ago, and the minconf parameter is ignored now.
Bitcoind treats the whole wallet as owning the coins, and it will use any coins available for any transaction it creates. There is no relation between coins and accounts. sendfrom simply allows you to specify which account balance to decrease.
sendfrom does a balance check on the debited account, and will fail if it would make the account balance negative, counting only crediting transactions with at least minconf confirmations. This feature is not very reliable, as fees can make the account go negative despite the balance check before.
sendtoaddress always debits the "" account, and does not do a balance check on it, so the "" account balance can go negative (as long as the wallet balance - the sum of the account balances - is positive). Again: it does in no way restrict which coins are used to construct the transaction.
Because sendtoaddress does not do a balance check, there is no way in which a minconf parameter would have an effect. Normally, all coins with 1 confirmation (if they come from other wallets) or 0 confirmation (if they come from yourself) are spendable, though for example the spendzeroconfchange setting modifies this).

As already pointed out, the account balance system and the move command are deprecated because they are very hard to understand and use correctly. If you need accounting, implement it yourself on top.

Thank you Pieter for an elaborate answer. This really cleared things for me now. Also, we've decided to implement our own accounting system and to treat Bitcoin wallet as a single shared account for all customers, as you suggested in the last sentence.

An off-chain transaction means in simple terms that the parties involved in the transaction basically exchange their private keys. Say you want to pay your friend 1 BTC. You would just give the private key to your address holding the 1BTC. Go through this link for more details.
Now coming to your questions.

Firstly, note that accounts and the move api have been deprecated an no longer used. Just for explanation sake, accounts are nothing but a set of addresses in your bitcoind wallet. Now the move command actually transfers the BTC from the addresses in one account to the other. There is no way you can convince the bitcoind client to share the private key and not move the funds(because it already has all the private keys). So the scenario you have given doesn't make sense.
The minconf is for the client to know to use only those transaction outputs which have as many mnimum confirmations as you have provided.
sendfrom is also deprecated since accounts are deprecated. What the bitcoind wallet does is that it combines the funds in all your addresses to send the money to the address specified (if the value you wish to send is not available in a single address)
same as point 2
As I said accounts are deprecated, so it will use the address which has more than the value specified and if not, combine addresses to send the money to the recipient address.
same as point 2

Edit: Point 1: The move command simply decrements one accounts virtual internal virtual balance, and increments another and does not move the BTC's.
As corrected by Peter Wuille

Thank you for your answer. It clears this for me a bit. Also, how do I know what features or API calls are deprecated or not? It looks like documentation is poor and severely outdated.

Through the terminal try typing the api without the parameters it requires, for example, just type move and read the output, you would see there it is written that it is deprecated, but can still be used.

The move command does not move funds from one address to another. It simply decrements one internal virtual balance, and increments another. Accounts are not addresses. They are indeed scheduled to be removed in a future version (partially because they're very hard to understand).


text:
Is offline Bitcoin transaction signing safe?
How can offline transaction signing ever be safe? I'm relativly new to bitcoin and this is one part that I cannot understand.
Lets say I create a transaction at my watching-only wallet. Then I sign it on my offline wallet. That means I just "toggle something"/"add some data that says signed" when I'm signing my transaction at the offline wallet.
Isn't that easily hackable so that everybody can easily sign transactions without knowing the private-key? I mean the watching only wallet has no clue of the private key so there must be some information that is != private-key in the data that comes back from the offline wallet.
Even if I sign it at the online-wallet somebody could just change the sourcecode of the client that he does not need the private-key to sign something.

Lets say I create a transaction at my watching-only wallet. Then I sign it on my offline wallet. That means I just "toggle something"/"add some data that says signed" when I'm signing my transaction at the offline wallet.

That is not how Bitcoin or digital signatures work. By your logic wallets (online or offline) wouldn't work in general. Private keys are not broadcast to the network or given to anyone unless the person who generated them (and thus owns them) does something.
Digital signatures work via mathematics to generate a proof. With a specific message and public key, only the person who controls the private key that corresponds to the public key is able to generate a valid proof. That proof is the signature, and that is what is added to a transaction. Signatures do not require the signing device to be online. Signing is an entirely offline operation that only does math, nothing else.

Even if I sign it at the online-wallet somebody could just change the sourcecode of the client that he does not need the private-key to sign something.

The signature validation operation is a consensus rule. Every must follow that exact rule otherwise you will be forked off of the network. Sure you can make a client that doesn't do that validation, but then you aren't using Bitcoin, and if no one uses your client and its forked blockchain (as that will happen), then your transaction and coins on that chain are completely worthless.

Can you provide more details about the signing process. I suspected that my logic is not how it works. Now i know its math behind but I do not exactly how it works. I read the wiki about transactions but I cannot understand it. Can you explain it for dummies :D

Bitcoin uses ECDSA which you can read about here: https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm

and Chapter 5 of Andreas' Book "Mastering Bitcoin" - "transactions". It is also online available (and in many languages).


text:
Who added the 21 million limit to Bitcoin?
After reading the white paper of Satoshi Nakamoto. The white paper does not mention anything about a limit of money supply.
I think I have read somewhere mentioned the name, but unfortunately I cannot remember it.
If I look in the main resources available online (Wikipedia, bitcoin.org, ..) they all mention Satoshi Nakamoto as the one who added this feature.
If Satoshi was not the one to add this feature, I think it is very important that we know who came up with this, and why the bitcoin dev community at the moment decided to adopt it.

Shady? How is having any limit at all, no matter its numerical value, any more shady than the status quo with normal currencies?

@Tyler If the limit were imposed secretly, that would be shady.

@Nick, you mean like the dollar? (Referring to the process by which the limit is decided, at least.) :)

This is the announcement of Bitcoin:
http://www.metzdowd.com/pipermail/cryptography/2009-January/014994.html

Total circulation will be 21,000,000 coins.  It'll be distributed to
  network nodes when they make blocks, with the amount cut in half every
  4 years.
first 4 years: 10,500,000 coins
  next 4 years: 5,250,000 coins
  next 4 years: 2,625,000 coins
  next 4 years: 1,312,500 coins etc...

It was part of it from the beginning, and it definitely wasn't secret.

In other words, it was part of Bitcoin from the very beginning. At first, nobody had any reason, or any authority, to change it. Now, it's well baked into the protocol such that changing it would severely undermine confidence in the system.

Furthermore, many, many parts of the design of the actual system are not in the paper. The paper explains how it is possible to build a digital currency out of a proof-of-work blockchain. It doesn't specify the entire system.

It was decided by the creator of Bitcoin, the anonymous Satoshi Nakamoto.To know more you can watch Bitcoin the end of money as we know it.


text:
Can anyone give an explaination of what exactly a Bitcoin is and where it derives its value from?
I really just want to grasp how a bitcoin actually is something of value? and how a string of characters equate into something that is worth dollars?

"that is worth dollars" Surely, there is nothing better to describe value than something a nation made up, decided it has value, but retains the right for itself to make more of it at virtually no cost, creating no value in the process of doing so but diminishing the perceived value of the dollar notes printed and given out already, instead.

related: Where do bitcoins come from and what gives them their value?

Proof of work plus utility, and scarcity.
The Bitcoin mining process is what creates new coins in the Bitcoin economy. To add a new block to the network the miner must produce a hash below a specific target. The only way this can be done is through trial-and-error (bruteforce) so miners are constantly competing to produce as many of these hashes per second as possible so that they earn the newly created bitcoins.
This competition requires hardware and electricity, both which cost money. This is the Proof of Work (POW), the only way to create new blocks and thereby new bitcoins is by spending money on the mining process. This is also where the scarcity part comes in. Today, every block created produces 12.5 new bitcoins. Every 210,000 blocks (~ 4 years) this reward is cut in half thereby constricting the supply. We've already had two halving events so far. It started at 50 new bitcoin per block.
Lastly utility gives it value. Bitcoins are useful. They can be used to transfer value across the globe almost instantly, for very little cost, and without censorship. Whether it's used for international remittance or gambling doesn't matter - bitcoins have utility.
So it's not just random string of characters. What appears to be random strings actually represent and mean something. They can be validated by others that can prove that this string of characters represents the money and energy spent creating a valid block.

Well, the technical answer was given correctly above (I think), however the valuation and the acceptance of bitcoin lays somewhere beneath these technicalities. The most probable reasons that a virtual "money" like this could work are greed (the price will go up further), anonymous trust (others will accept it as a money, not just you) and so on and on, but you must look for some sort of greed as a motive.

Long ago, Aristotle defined 5 properties that he felt were needed for something to be used as a currency:

Durablity
Portability
Divisibility
Fungibility
Intrinsic value

An additional property that we have come to agree on is Scarcity.
Throughout history, humans have created many currencies that lack one or more of these properties.  For example, the island of Yap used extremely non-portable, non-divisible Rai Stones.  Currently, most nations use fiat currencies like US Dollars, that lack any intrinsic value.
Bitcoin excels at all of these properties, except intrinsic value.  In terms of intrinsic value, this puts it at the same level as USD...not below it.
However, another property of currency to consider is legal tender.  This means that a currency is acceptable as payment for taxes.  USD is legal tender in the US, but bitcoin is not.  If you get paid and buy all your goods with bitcoin, you will still need to convert into USD to pay US taxes (if that's something you need to do).
If you take all 7 of these properties (including scarcity and legal tender) into account, bitcoin beats USD in 5 of them, ties in 1 of them (intrinsic value), and loses to 1 of them (legal tender).  All in all, that makes it a pretty good currency.
So there's a simple answer to your question about how a data stored on a p2p network can be worth US dollars: dollars aren't worth as much as you think they are.

Long ago, Aristotle defined 5 properties Do you have a primary source for this? I can't find a source for it. Also, some of his writings contradict this: [...] coined money is a mere sham, a thing not natural, but conventional only, because, if the users substitute another commodity for it, it is worthless, and because it is not useful as a means to any of the necessities of life, and, indeed, he who is rich in coin may often be in want of necessary food. which seems to suggest that the use of Bitcoin for money is unnatural, so long as altcoins exist.


text:
Simulator bitcoin miner
I was checking this C++ mining project to start with Bitcoin mining and understand better how mining works.
This is the project: https://github.com/gavinandresen/bitcoin_miningsim
But now i want to experiment with one real situation to verify what will happen. What more do I need to implement? I need to include the connection to my pool and then let the miners work to send the different blocks that they are mining?
I am little lost so if someone can tell me if this a good example for learning or know others that can help me.

For a mining simulator: https://jornc.github.io/bitcoin-transaction-explorer/

ok so this is program is not necessary i think seeing one simulator like you took me it's more clear

The code you are linking to is for simulating network-like effects of various mining technologies and policies. It does not actually mine, and will not teach you about mining itself.
You may look up projects like cgminer of bfgminer for actual mining software.


text:
How to use bitcoin core importmulti
I have some keys obtained from walletdump,
13LJXzFwARH5N2bR1AV38Nf9qDVw53PjiB
1BcBMuEJJzEY36PmKWTFmYRxEF3YaSEiKN
1NeZCnuSW9NG8F147VNf8JSLKWGcVexZ32

8e576cbf85a8f529b8b1704deecd122ec8e542761c81928866af3af5825ec016
be9cf54f7d6aba2ab730f8cb4c61b9ff3587b887f12bb6cbfd0eeb158364ce44
3922ccf671581b81201d18c9258d6e0cd1d2a5ea42f20323692f90bb7ac4e45c
e8ba7c776506a8e774db816d65a90f6cb6c1861bb10edc077bbdace058a8bcad
276f7c05b7a3d92281ee4c6ea1240beb41fda59db1c2ca16cf42a1509ffd9e36
b8b42b10f67c7cc83dd736f183f7a919e6f7a1a73513ad31aabc10fb77866e60

0033598d96cf61c76369f9f3bff2cae0bc54d0375b8fe57d475859d6b8bac3b8
002c15a780f0ce0e0407f75b2afb1d6108e66d528098c5568ada47222b58edac
00d9ba3daf22a3a9febbf25b62c1468c48b85389be52838b5133d3155683d28d

# also private keys

How can I properly use importmulti and put all my keys there?
Any answer would be appreciated.

Here's a basic example of how you can use importmulti:
bitcoin-cli importmulti '[{"scriptPubKey": {"address": "13LJXzFwARH5N2bR1AV38Nf9qDVw53PjiB"}, "timestamp":0}]'

In this example, we are importing a single address. You can extend this to include all your addresses. However, keep in mind that using importmulti with private keys directly in the command line is not secure, as it may expose your private keys to other users on your system.
Here is an example with multiple addresses and their corresponding private keys:
bitcoin-cli importmulti '[{"scriptPubKey": {"address": "13LJXzFwARH5N2bR1AV38Nf9qDVw53PjiB"}, "timestamp":0},{"scriptPubKey": {"address": "1BcBMuEJJzEY36PmKWTFmYRxEF3YaSEiKN"}, "timestamp":0},{"scriptPubKey": {"address": "1NeZCnuSW9NG8F147VNf8JSLKWGcVexZ32"}, "timestamp":0}]' '[{"keys": ["private_key_1", "private_key_2", "private_key_3"], "timestamp":0}]' '{"rescan": false}'

Make sure to replace "private_key_1", etc., with your actual private keys.
it's crucial to handle private keys securely. Storing them in plaintext in commands or scripts is not recommended.


text:
How to get x-only public key from the private key, and what does the obtained value represent?
In ECDSA, the public key is the result of multiplying the private key (some random 256-bit value) with a generic point (G). So the public key would be one of the points (X,Y) of the elliptic curve secp256k1. In this case, the public key represents two 32-byte values (encoded as 65 bytes or 33 bytes in compressed form). However, as I see, with Schnorr the public key is just 32 bytes long (not even 33 where one byte would define whether Y is odd or even), so some other process is used.

What is the way to get the public key from the corresponding private key in Schnor?
What does that obtained value represent? Also point of the elliptic curve? If so, I assume its X coo, so how do we know corresponding Y coo?
Does Schnorr (BIP340) also support a classic key tweaking like ECDSA, where we add some value to the public key and then add the same value to the private key and we would produce a valid signature?

What is the way to get the public key from the corresponding private key in Schnorr?

Multiply the private key with the generator G (like for ECDSA) and then throw away the Y coordinate.
Given the depth your questions go, I would recommend you to just read the relevant BIPs. In particular, BIP340 has a section on public key generation.

What does that obtained value represent? Also point of the elliptic curve? If so, I assume its X coo, so how do we know corresponding Y coo?

Yes, a point on the elliptic curve, of which you only know the X coordinate. Internally in the BIP340 scheme it is treated as the point with given X coordinate and even Y coordinate, but at a more high-level you can also think of the public key as representing "either" of the points.
Given the curve equation y2 = x3 + 7, the corresponding Y coordinates for a given X coordinate can be computed as Y = ±√(X3 + 7) mod p. Note that this is a modular square root modulo the field size p = 2256-232-977. For the specific value p for secp256k1, this is equivalent to ±(x3 + 7)(p+1)/4.
This is not specific to BIP340 public keys. Even for ECDSA, typically public keys are represented in the so-called compressed format, consisting of sign_byte + [32-byte big endian X coordinate], where the sign_byte is 0x02 if the Y coordinate is even, and 0x03 if the Y coordinate is odd. Reconstructing the full point also requires a modular square root for this format.

Does Schnorr (BIP340) also support a classic key tweaking like ECDSA, where we add some value to the public key and then add the same value to the private key and we would produce a valid signature?

Yes, Taproot even critically relies on this tweaking operation for representing script paths: in order to spend a Taproot output with point Q as a script, an internal public key P needs to be revealed together with a script (Merkle root) m such that Q = P + H(P || m)G. Since the Y coordinate of Q is not part of the output, it also needs to be revealed at spending time.

Does this mean that the number of possible points, i.e. the private key-public key pairs, is 2 times smaller than in the case of ECDSA since we only use even Ys?

Yes, but note that this is not a reduction in security (not even a negligible one).

Thanks. Everything clear expect this tweaking. It confuses me that we only take the even Y coordinate. I wrote a question related to that. I hope you can help me. https://bitcoin.stackexchange.com/questions/120434/how-does-tweaking-in-schnorr-digital-signature-scheme-work-and-what-is-not-good

In the scheme described in BIP 340, private and public keys are generated in the same way as for ECDSA in Bitcoin, with an additional step - use only the X coordinate, and assume that the Y coordinate is even.
BIP 340 continues to use the secp256k1 elliptic curve, so private keys are still just an integer, and public keys are points on that curve. As such, any elliptic curve operations that are independent of signing and verifying still work.

Does this mean that the number of possible points, i.e. the private key-public key pairs, is 2 times smaller than in the case of ECDSA since we only use even Ys?


text:
How bitcoin node selects the output unspent transactions when sending bitcoin?
please help me understand the algorithm for selecting UTXO when forming a new transaction in Bitcoin.
For example, my wallet has a lot of incoming transactions (thousands of transactions in amounts of 0.001-0.09 BTC that have more than 70 confirmations and several transactions in amounts of 2-3 BTC that have 2-5 confirmations). When sending a new transaction in the amount of 1.5 BTC, the node for some reason creates a transaction with 500+ inputs for small amounts, thereby the weight of the transaction is 75 kb and, accordingly, the amount of miner's fees increases to enormous values. But if the node sent a transaction from an address that had 2 BTC, the miners's fees to would be minimal.
Please tell me how the node chooses which UTXOs to assemble a new transaction from? What settings on the node can regulate this?
I tried to find an answer on Google, but I couldn't find anything similar.

Does this answer your question? How does the Branch and Bound coin selection algorithm work?

I don't think that's a duplicate of the question about BnB. I think an answer here should describe what coin selection is, what Bitcoin Core is using (and link to the BnB answer for more details, potentially), what options influence Bitcoin Core's coin selection and maybe mention coin control.

By default, Bitcoin Core will only spend foreign inputs that have at least six confirmations, and change outputs that have at least one confirmation. If you want to use younger foreign inputs, you can use the minconf parameter present e.g. on sendmany.
Beyond that, Bitcoin Core will split its UTXO pool by output type, and then for each output type uses multiple algorithms to construct one input set candidate. Among all of these candidate input sets, it chooses the least wasteful per the waste metric.
The algorithms in use in Bitcoin Core v25.1 are knapsack algorithm, single random draw, and branch and bound.

Knapsack will perform numerous random walks on all UTXOs with amounts lower than the target to assemble an input set that overshoots target + min_change the least, or pick the lowest larger UTXO if that is closer to target + min_change.
SRD will shuffle all UTXOs and pick from this shuffled list until it has collected enough funds to fund the transaction
BnB will attempt to find an input set that avoids creating change. If there are multiple solutions, it will prefer the least wasteful.

None of the above algorithms actually minimize the input set weight. Hence, I am proposing that we add an algorithm that minimizes the input set weight in PR#27877, which at the very least should be run at high feerates. The downside of such an algorithm would be that it could bloat a wallet’s UTXO pool when used excessively, but it would ensure an optimal outcome in the short-term. So far, this proposal has not gotten sufficient support to be added to Bitcoin Core.
There are currently no configuration options that directly affect the general coin selection behavior. You would have to perform coin selection manually or externally and build raw transactions to optimize fee expenditure.


text:
What would happen if the non-upgraded node to BIP68 receives block with the transaction where one of its nSequence is different than 0xffffffff?
What would happen if the node not upgraded to BIP68 and relative lock time meaning of nSequence get a block with the transaction where one of its nSequence is not set to 0xffffffff, but to value which relative time still did not pass? (Assume that the nLocktime is 0x00000000 or some value that already pass - for example 3 blocks). Not upgraded nodes will accept the block (since nSequence does not have meaning) and all other (upgraded) nodes will not? How is that solved?

Not upgraded nodes will accept the block (since nSequence does not have meaning) and all other (upgraded) nodes will not?

Yes, that is what happens.

How is that solved?

The answer is the same for every soft fork: the consensus change is only safe to old nodes as long as a majority of the hashrate enforces it. If not, it is possible that a chain split between old and new nodes appears.
Imagine that there is a percentage of the hashrate that produces blocks that violate BIP68. As long as a majority of the hashrate refuses to build on top of such blocks, the chain without BIP68-invalid blocks will be extended faster, and whenever that chain overtakes a BIP68-invalid chain, even pre-BIP68 nodes will switch over to it (because to them, both are valid).
Thus, as long as the majority of the hashrate enforces BIP68 (and thus refuses to build on top of BIP68-invalid blocks or chains), old and new nodes will eventually agree on what the active chain is.


text:
What does "score" mean in the following bitcoin node info printout?
This is the response from a getnetworkinfo command;
"relayfee": 0.00001000,
  "incrementalfee": 0.00001000,
  "localaddresses": [
    {
      "address": "*qd.onion",
      "port": 8333,
      "score": 4
    }
  ],
  "warnings": ""


text:
What do they mean by "12/24 words" or "seed words"?
Having read thousands of Bitcoin threads/questions on Reddit, there's constant references to "your 12/24 words" or "seed words".
They never once refer to wallet.dat.
I have used Bitcoin Core for eons, and to me, the wallet.dat is the thing to keep and secure. Not some "words".
Is this "seed words" stuff something that only applies to other wallets? But even if such is the case, why do they never, ever question or explain this when it's brought up? I'm starting to wonder if my Bitcoin Core is supposed to have a menu item called "View seed words" or something along those lines.
Does Bitcoin Core have "seed words" which I should also back up just in case I somehow nuke all my backups of my wallet.dat file and/or forget the encryption passphrase for it? If not, why do they keep referring to these? Are even people discussing Bitcoin in depth online not using Bitcoin Core?

Bitcoin Core does not support BIP39, or any other seed word standard. You are correct that this implies backing up wallet.dat and keeping it safe directly. This is a good idea in any case, even if there were a seed phrase, as the seed only helps recover the keys, but not information such as labels you may have assigned to transactions, or unconfirmed transactions.
Many other wallets do support BIP39 or other seed phrase standards. Some of these are very popular. I can't tell you why common advice seems to ignore wallets like Bitcoin Core that don't have these. Presumably, in terms of actual non-professional usage, such wallets are a minority.
The primary reason for Bitcoin Core's wallet not supporting seed phrases is simplify because it predates such standards, evolves slowly (by being conservative about many changes), and until recently, introducing a feature for recovery from a seed would have been very complicated. This may well change at some point in the future.
Internally, the wallet.dat file does use a BIP32 seed to generate keys from, but this seed is not something that takes the form of a phrase; it is simply 32 random bytes that are stored in the wallet file (in encrypted form if the wallet is password encrypted).

A memonic seed is used to generate addresses used for Bitcoin, your wallet.dat generated in your config is basically that
For example, a memonic seed phrase would be 24 words that look like:
suffer adapt adult also depart ect. Ect. Ect
You can generate your own and play with it at https://iancoleman.io/bip39/ it uses the bip39 format and explains everything
Hope it helps!

Bitcoin Core does not use BIP39 at all (for now).

Of course, it uses its own format but I'm just explaining what those seed phrases are for,

I understand what you're saying, but I think it's besides the point. OP isn't asking what seed phrases are, but wondering why the common advice is to talk about seed phrase while Bitcoin Core apparently doesn't have any (and indeed, doesn't).


text:
Can everyone see "message signatures" I create & verify?
I need to sign and verify messages on a couple of addresses, and I need to write my full name and address as message. Is there any concern that anyone can read the message(name and address) other than the individual I am revealing it to?
I'm not sure how signing and verifying works other than that it shows proof you own the keys tied to that address your signing for. But is the message when signing and verifying sent out on the blockchain out in the public so everyone can read and see the message?
Any safety/privacy concerns here? Can everyone read my message online afterwards?

Message signing is a purely local operation. No connection to the network is even required for it. Nobody can see the message except those whom you send it to, and whomever else they share the data with.


text:
How does the BIP340 lift_x algorithm work?
Couple questions of code that I'm reviewing trying to learn schnorr sigs.
Why do we want an odd private key? I see even tests on the private key and then subtract it from the SECP256K1 Order to get an odd point?
Schnorr verify seems to need the square root of a point ,specifically this code here, why and what is this doing? I'm confused on what is happening conceptually.
def lift_x(x: int) -> Optional[Point]:
    if x >= p:
        return None
    y_sq = (pow(x, 3, p) + 7) % p #<-the curve
    y = pow(y_sq, (p + 1) // 4, p) # why is this __floordiv__ 4?
    if pow(y, 2, p) != y_sq:
        return None
    return (x, y if y & 1 == 0 else p-y) # make y odd if there is a sqrt?

Thanks

def lift_x(x: int) -> Optional[Point]:

This is a function that given an X coordinate, computes one of the two corresponding Y coordinates on the curve; specifically, the even one.
Every possible value in the field of coordinates (integers modulo p, where p = 2256 - 232 - 977) has exactly 0 points on the curve y2 = x3 + 7, or exactly two. In case there are two points with a given X coordinate, the corresponding Y coordinates will be each other's negation (modulo p), and one will be even, and one will be odd. This lift_x function returns the one with the even Y.
    y_sq = (pow(x, 3, p) + 7) % p #<-the curve

This computes y_sq = y2, using the fact that it equals x3 + 7 (mod p), using the curve equation.
    y = pow(y_sq, (p + 1) // 4, p) # why is this __floordiv__ 4?

This computes the square root y of the value y_sq we determined in the previous now. In general, modular square roots can be computed using the Tonelli-Shanks algorithm, but for the secp256k1 modulus, this algorithm simply boils down to computing y_sq(p+1)/4 mod p. In Python, we need to write this (p+1)/4 as (p+1)//4 because we want exact integer arithmetic. (p+1)/4 would compute an approximate floating point number only.
    if pow(y, 2, p) != y_sq:
        return None

This verifies whether the computed value y is actually the modular square root of y_sq. If the input x value was not a valid X coordinate on the curve, then x3 + 7 won't be a square, and thus won't have a square root. However, the formula y_sq(p+1)/4 always yields a result, even when y_sq doesn't have a square root. So we need to check whether y2 = y_sq. If not, we return None immediately: the input X has no corresponding Y coordinates.
    return (x, y if y & 1 == 0 else p-y) # make y odd if there is a sqrt?

This simply negates y (modulo p) if y is odd, thereby finding the other (even) solution. This guarantees returning the even Y coordinate out of the two solutions.

Thanks a lot. I think I see it now, it looks like it is for consistency. When we do ecc point add, the result will be significantly different for the point that has a 'negative' 7 than the point with a 'positive'? Or does it have something to do with key compression?

Given a fixed X coordinate, the two curve points with that coordinate are each other's negation (in ECC logic, -(x,y) = (x,-y)). So the choice very much matters: point1 + lift_x_odd(x2) = point1 - lift_x(x2) (so it'd be negation instead of addition), where lift_x_odd is a hypothetical variant of lift_x which maps to the odd Y coordinate rather than the even one. Note that it's not a negative/positive 7 (changing the sign of the 7 would be changing the curve equation, rendering it entirely insecure). All we're doing is choosing which of the solutions for Y to pick.

Thanks, that really clears things up for me and furthers my understanding.


text:
How can I determine how much "gains" I've had from Bitcoin?
I bought a bunch of BTC in early 2013. Since then, I've bought very small parts of Bitcoin every now and then up until now, for much larger (and increasing) price.
Many of those "original" coins have been lost. While there was a "hard fork gold rush", I gained some more from the ones I already had by claiming "Bitcoin Gold" and "Bitcoin Diamond" and all kinds of such things and then trading them back to real Bitcoin using various non-KYC/AML webpages which allowed me to do this without registering any account. I can't even remember the name of those services, let alone the exact details of when I did it or how much I got.
I have no idea whether the coins I have left today are all from those original coins, which I bought for next to nothing, or if some of them are part of the ones I bought in later years, at a much steeper price. I have no idea how I'd even figure that out.
With such a messy situation, how can I possibly calculate how much taxes I owe to the government if I were to sell/spend my coins? I seriously don't understand how I can possibly determine how much "gains" I've had considering the messiness of it all.
With this in mind, what am I supposed to do? Assume that all the coins I have left are part of my first batch of coins, even though this will mean that I have to pay taxes on basically the full balance? And even if I go that route, I can't prove how much I paid or when. (It was Localbitcoins pre-KYC/AML.)
I don't understand how I'm supposed to figure this out, and the government's website is (of course) to no help. What would be the most reasonable thing to do? Just "bite the bullet" and pretend that I got all the coins I currently have for free, and thus have to pay taxes on the entire balance?

This sounds like a question for an accountant or tax advisor who is familiar with your local tax code.

Maybe a better question for Money.SE.  You'll have to specify your jurisdiction.

The government's position is likely to be that you were supposed to be keeping those records all along, and if you didn't know you were supposed to, well, ignorance of the law is not an excuse.  So not being able to deduct the actual cost, but only what you can prove (or nothing at all), could be the price you pay for this omission.  Kind of like how if you donate to a charity but don't keep the receipt, you can't take the deduction - if you want the tax benefit, you're responsible for the associated record keeping.

You have to understand your country's tax treatment, I suggest to look it up here: https://cointracking.info/law/

It may be a bit of work, but you should be able to trace on a blockchain explorer (eg blockstream.info) when you acquired the bitcoin with the current addresses you have.
If you can't prove how much you paid for it with a record for each purchase, your tax jurisdiction may accept a historic exchange rate from a well known and reputable public exchange at that time. I suggest asking your government if that is a possibility first, before reporting that you received the coins for free.
To calculate your gains from your purchases and sales, different accounting methods exist (FIFO, LIFO, WAC, etc). If your government is not clear on which method they accept or don't know how to do that, you may need to contact a local tax advisor to help you out further.

THIS IS NOT FINANCIAL ADVICE SPEAK TO AN ACCOUNTANT FOR CONFIRMATION
Because your gains are 'unrealized' you may consider not realizing them and instead finding a way to take out a loan against your known holdings. That way you can mitigate taxes from the liquidation. Don't take my word for it though, it's just something I have heard of before, ask an accountant or do some research on it. Also I do not condone putting the bitcoin into a centralized loan product, there are decentralized permission-less bitcoin backed loan products in development currently which I think would be worth holding out for.
Here is one source discussing what Im talking about: https://law.stackexchange.com/questions/64713/can-you-avoid-capital-gains-tax-by-taking-out-a-loan-and-not-repaying-debt


text:
no output on gettxout method [All Blocks Are Counted]
litecoin-cli gettxout "9d56b3bf179a988873fc2162d70bba44849ef822764c9049a0f722b5fdc9acc1" 1
This is the command im using to get information about a transaction.
litecoind -txindex=1 -daemon -conf=/home/litecoin/.litecoin/litecoin.conf -reindex -rpcuser=cryptosensei -rpcpassword=foo_420 -rpcport=9332 -rpcthreads=1000
This is the command i use for starting up my daemon. with the -reindex it should not re-verify the blocks. So im wondering why im getting null.
If anyone knows what the issue let me know. Also here is the response of getnetworkinfo & getblockcount
getblockcount
litecoin@Debian-913-stretch-64-minimal:/root$ litecoin-cli getblockcount
0

getblockchaininfo
litecoin@Debian-913-stretch-64-minimal:/root$ litecoin-cli getblockchaininfo
{
  "chain": "main",
  "blocks": 0,
  "headers": 526188,
  "bestblockhash": "12a765e31ffd4059bada1e25190f6e98c99d9714d334efa41a195a7e7e04bfe2",
  "difficulty": 0.000244140625,
  "mediantime": 1317972665,
  "verificationprogress": 1.737314343731834e-08,
  "initialblockdownload": true,
  "chainwork": "0000000000000000000000000000000000000000000000000000000000100010",
  "size_on_disk": 2217395400,
  "pruned": false,
  "softforks": [
    {
      "id": "bip34",
      "version": 2,
      "reject": {
        "status": false
      }
    },
    {
      "id": "bip66",
      "version": 3,
      "reject": {
        "status": false
      }
    },
    {
      "id": "bip65",
      "version": 4,
      "reject": {
        "status": false
      }
    }
  ],
  "bip9_softforks": {
    "csv": {
      "status": "defined",
      "startTime": 1485561600,
      "timeout": 1517356801,
      "since": 0
    },
    "segwit": {
      "status": "defined",
      "startTime": 1485561600,
      "timeout": 1517356801,
      "since": 0
    }
  },
  "warnings": ""
}

Assuming this is identical to Bitcoin Core.
This is somewhat confusing, but it simply means that UTXO is spent. It is reporting "nothing" as output.

Yep very confusing. Also yes it is completly identical to bitcoin core actually. What im asking myself is what the exact difference between -reindex & -reindex-chainstate is. Maybe this is the cause of all of that

-reindex scans all block data again; -reindex-chainstate assumes your blocks are fine. It sounds unrelated to your question - there is nothing wrong here. The output you're asking about simply has been spent already.

Ahh okay. So what method is the correct one to simply check a transaction? [Confirmations etc]

gettransaction (only works for transactions in your own wallet), or getrawtransaction (for all transactions, but only works if you have txindex enabled).

gettransaction returns that its a non found method for some reason. Yet i have the txindex enabled and set but it won't work for me for some reason. You see that in my parameters to start the node i have txindex=1

As I said, gettransaction is only for transactions in your own wallet. If you want to query for other ones, use getrawtransaction.

But -txindex=1 is legitimate in the start parameters right? Also is that true that i need to have the -reindex parameter to have -txindex=1 fully functional? I read thats what common explorers use

Since Bitcoin Core v0.17 there is no need to reindex anymore when you enable txindex; the missing part gets rebuilt automatically. Block explorers in general don't use Bitcoin Core (or at least not solely; they use additional software to build an index of blocks/transactions).

I see, yes this is for a school project anyways. But so im right that with an older version -reindex is needed? Also just to be sure. To use -txindex=1 is correct in the start parameters and not something like -txindex 1

Yes, that's all correct. Generally you'd put txindex=1 in your bitcoin.conf file, because you want it to always be enabled. The reindexing is something you want to only do once (so it should not go in bitcoin.conf; if it does, it'll rebuild the entire database from scratch every time you restart Bitcoin Core).

Thank you very much. So if reindex is only used once. When is the appropriate time? The first time running the node?

It's only needed if you previously had a node running without txindex=1, and want to enable it. It is needed because (before Bitcoin Core 0.17) it couldn't build the txindex on the fly; you had to start over. If you run with txindex=1 the first time you run Bitcoin Core, no reindex is needed.

Perfect. So i won't need -reindex if i will re-install the node from scratch right. Also do you recommend the -reindex-chainstate parameter if the node server ever crashes. Also thank you very much for your information. It's an honour to me to get informations from a bitcoin-core contributor :)


text:
Is there a way to change Bitcoin Open Source code to be more Environmentally friendly?
If Bitcoin is open source as proponents mention, why can't make Bitcoin as environmentally friendly as Ripple, Dogecoin, Cardono etc? Elon Musk tanked the market by mentioning Dogecoin is More environmentally friendly. It apparently uses an algorithm that takes less computation and energy consumption.
Source Code reference:
https://github.com/bitcoin/bitcoin

All PoW based systems are equally efficient: what is paid for security goes to miners, who will invest it in mining hardware and electricity. If any of these other systems had Bitcoin's exchange rate/subsidy, they would consume exactly as much. Further, none of these system consume any measurable amount of energy per transaction; they consume energy to secure the system, regardless of how many transactions occur.

Yes, there is a way, by creating a BIP, but an alternative to PoW would very likely not get consensus in the community, and thus its supporters would be forced (and are free to) to create a hard fork, creating a new coin altogether. It is then to be seen which coin the market will choose, but my sense is that the majority of bitcoin investors will still favour the coin with the original PoW mechanism.
Many coins have been created to set out to find a replacement for PoW, yet none of the coins have gained significant market share.
The monetary property that PoW provides for bitcoin is unforgeability, conceptually very similar to the unforgeability of gold. Other proof mechanisms of other coins are believed to be easier to forge/corrupt and more prone to centralisation of a coin. Buyers of bitcoin likely value the monetary property of unforgeability that PoW provides and this is likely the reason why bitcoin remains the most valued coin, despite its reliance on energy.
While bitcoins reliance on energy on the surface does not seem ideal, a currency that can be forged or centralised also has no (long term) value. Users will subjectively value whether the energy spent that safeguards their investments is ‘worth it’, by investing in it, or not. Some journalists or celebrities, like Elon Musk, may consider it ‘not worth it’ or ‘morally unjust’ from their vantage point, or still believe that PoW can be replaced, despite many failed altcoins and a large body of research on PoW. However, if you have suffered through many currency devaluations or disagree with how the ‘petro’-dollar is upheld and the effects it has on the world politics, the energy spent to safeguard the value of bitcoin may -subjectively!- be ‘worth it’ to you.


text:
Transaction incorrect when reading a block from `blk*.dat` files
The problem occurs with block 1,669,774 on testnet (https://blockstream.info/testnet/block/0000000010001cebd3e4f2fe5f2e2cbbe35ba6457554d9e0e6eb100b6f91eaee).
To obtain a block I retrieve the file and the position by reading the key b<block_hash> from the leveldb database and I then parse the block in the usual way. This works well for all blocks except this one which returns me the list of transactions for this block BEFORE the reorganization.
For example the list of transactions contains the hash 6ef0f0d3fcf20aedefa37425ea93e69c7da4d04fd1ce983c5cba613630e775ca instead of the hash f07b4eb879ead12e58742e322878310d4b5bcd48b25c1e4ab781 672a9f44a312.
bitcoin-cli getblock <hash> returns me the correct list of transactions. (of course I use the correct hash in both cases 0000000010001cebd3e4f2fe5f2e2cbbe35ba6457554d9e0e6eb100b6f91eaee).
How to obtain the correct version of the block?
Thanks in advance!
Edit:
Here the function I use to get the file and the position:
def read_raw_block(self, block_hash, only_header=False):
        block_key = bytes('b', 'utf-8') + binascii.unhexlify(inverse_hash(block_hash))
        block_data = self.blocks_leveldb.get(block_key)
        ds = BCDataStream()
        ds.write(block_data)

        version = ds.read_var_int()
        height = ds.read_var_int()
        status = ds.read_var_int()
        tx_count = ds.read_var_int()
        file_num = ds.read_var_int()
        block_pos_in_file = ds.read_var_int() - 8
        block_undo_pos_in_file = ds.read_var_int()
        block_header = ds.read_bytes(80)
        self.prepare_data_stream(file_num, block_pos_in_file)
        block = self.read_block(self.data_stream, only_header=only_header)
        block['block_index'] = height
        return block

SOLVED:
it's a segwit transaction, f07b4eb879ead12e58742e322878310d4b5bcd48b25c1e4ab781672a9f44a312 is the txid and 6ef0f0d3fcf20aedefa37425ea93e69c7da4d04fd1ce983c5cba613630e775ca it's the hash!

What is the block hash you looked up? As in, the one for which you read the b<block_hash> key?

@PieterWuille Yes I look for the transactions in the block '0000000010001cebd3e4f2fe5f2e2cbbe35ba6457554d9e0e6eb100b6f91eaee' and I use the key b'b\xee\xea\x91o\x0b\x10\xeb\xe6\xe0\xd9TuE\xa6[\xe3\ xbb,._\xfe \xf2\xe4\xd3\xeb\x1c\x00\x10\x00\x00\x00\x00', I get the file number and the position of the block and then I parse like everyone else. It's just the one that's the problem. Thanks in advance! I edited my question with the little function I'm using.

Thank you @PieterWuille, just found the solution! edited the question!

Feel free to post an answer to your own question.

I finally found the answer here:
It's a segwit transaction, f07b4eb879ead12e58742e322878310d4b5bcd48b25c1e4ab781672a9f44a312 is the txid and 6ef0f0d3fcf20aedefa37425ea93e69c7da4d04fd1ce983c5cba613630e775ca it's the hash!
for the record here the snippet to fix my problem:
hash_data = data
if transaction['segwit']:
    hash_data = data[:4] + data[6:offset_before_tx_witnesses] + data[-4:]
transaction['tx_hash'] = ib2h(double_hash(hash_data))


text:
Wallet transaction not confirming in blocksonly mode
I sent transaction with bitcoin-cli:
bitcoin-cli sendtoaddress tb1q3qlv7k648hec866a0x395hq0h3sqcg2lrq5r0k 0.001

As an answer I've got transaction Id.
But it still has no confirmation (a few hours).
Bellow are some details:
Network: signet.
Bitcoin core 25.0.0
Blockchain is synced.
Transaction:
 {
     "address": "tb1q3qlv7k648hec866a0x395hq0h3sqcg2lrq5r0k",
     "category": "send",
     "amount": -0.00100000,
     "vout": 0,
     "fee": -0.00014100,
     "confirmations": 0,
     "trusted": false,
     "txid": "f0aaf3aeca4590521557ce20bf12f2f8b4ec2520bebc45ab7958f87f08965c2f",
     "wtxid": "4c053b7ac21b0c86febb427d377d57b5397c4e4884c8a2397d1c3405b6ab7040",
     "walletconflicts": [
     ],
     "time": 1701862331,
     "timereceived": 1701862331,
     "bip125-replaceable": "yes",
     "abandoned": false
}

bitcoin.conf:
    chain=signet
    blocksonly=1
    daemon=1
    dbcache=4000
    txindex=1
    debug=1
    logips=1
    fallbackfee=0.001

What can be wrong?

What RPC did you use, and what error did you receive back?

I've got no errors. How can I check my RPC?

@MikkiUkraine Please update your question to include what you are trying to achieve, how you are doing that, what do you expect to see, and what you are seeing instead? It is entirely unclear from your current question what the problem is.

@PieterWuille Updated

I took the liberty to edit the title of your question to be closer to what was happening. Feel free to suggest edit/revert if that doesn't capture your intent.

You're running in blocksonly mode, which by default disables the broadcasting of wallet transactions. This is for privacy reasons: in blocksonly mode you don't participate in general in transaction relay. If then suddenly your node is seen broadcasting a transaction anyway, it would be very apparent to your peers that the transaction is yours.
Possible solutions:

Disable blocksonly mode.
Forcibly enable wallet broadcasting (walletbroadcast=1 in the config file), accepting the privacy risk.
Manually broadcast the transaction through sendrawtransaction.

There does exist a wallet rebroadcast mechanism, which will occasionally (every 12 to 36 hours) broadcast unconfirmed wallet transactions again (if wallet broadcasting is enabled at all). So if you disable blocksonly mode, or enable wallet broadcasting, and restart, the transaction should eventually make it out. The third option is a lot faster though.


text:
who is the "owner" of a newly mined BTC before its first transaction?
When a miner adds a new block to the bitcoin blockchain, effectively 900 new coins come into existence as I understand it.  the miner gets 6 of them as payment, but who 'gets paid" for the other 894?
What I mean by that is if I want to then purchase one of these new BTCs, with whom am I exchanging funds for my BTC as they are not yet "owned" by a single person - who is the "owner" until that first transaction occurs?

Where do the numbera 900 and 6 come from? The payout for finding a new block is currently 6.25 BTC + fees from that block's transactions. All of it goes to the mimer.

The amount for the block reward is what is created, there is no additional created for any reason. If the block reward is 6.25 BTC, that is exactly what the miner is paid, and nobody else.


text:
problem to compil code addr.cpp
Trying to compile with g++ -o addr addr.cpp -std=c++11 $(pkg-config --cflags --libs libbitcoin) is getting me this error:
/home/user/myprefix/lib/libsecp256k1.a(libsecp256k1_la-secp256k1.o) : Dans la fonction « secp256k1_num_mod_inverse » :
/home/user/build-libbitcoin/secp256k1/src/num_gmp_impl.h:128 : référence indéfinie vers « __gmpn_gcdext »
/home/user/myprefix/lib/libsecp256k1.a(libsecp256k1_la-secp256k1.o) : Dans la fonction « __gmpn_sub » :
/usr/include/x86_64-linux-gnu/gmp.h:2190 : référence indéfinie vers « __gmpn_sub_n »
/home/user/myprefix/lib/libsecp256k1.a(libsecp256k1_la-secp256k1.o) : Dans la fonction « secp256k1_num_set_bin » :
/home/user/build-libbitcoin/secp256k1/src/num_gmp_impl.h:49 : référence indéfinie vers « __gmpn_set_str »
/home/user/build-libbitcoin/secp256k1/src/num_gmp_impl.h:49 : référence indéfinie vers « __gmpn_set_str »
/home/user/myprefix/lib/libsecp256k1.a(libsecp256k1_la-secp256k1.o) : Dans la fonction « secp256k1_num_get_bin » :
/home/user/build-libbitcoin/secp256k1/src/num_gmp_impl.h:34 : référence indéfinie vers « __gmpn_get_str »
/home/user/myprefix/lib/libsecp256k1.a(libsecp256k1_la-secp256k1.o) : Dans la fonction « secp256k1_num_set_bin » :
/home/user/build-libbitcoin/secp256k1/src/num_gmp_impl.h:49 : référence indéfinie vers « __gmpn_set_str »
/home/user/build-libbitcoin/secp256k1/src/num_gmp_impl.h:49 : référence indéfinie vers « __gmpn_set_str »
/home/user/myprefix/lib/libsecp256k1.a(libsecp256k1_la-secp256k1.o) : Dans la fonction « secp256k1_num_get_bin » :
/home/user/build-libbitcoin/secp256k1/src/num_gmp_impl.h:34 : référence indéfinie vers « __gmpn_get_str »
collect2: error: ld returned 1 exit status

What are you trying to compile?

https://github.com/bitcoinbook/bitcoinbook/blob/develop/code/addr.cpp

You should find where GMP object files are installed and add the compile flag -l/path/to/gmp/lib


text:
On a practical level, how exactly is the amount of a Bitcoin transaction fee determined?
Yes, I know that you can actually set the transaction fee to anything you want, but I'm of course talking about a transaction which will actually be "processed" in a reasonable timeframe, "reasonable" being "what the average person would accept".
I've been working for a long time now on a service which exclusively supports Bitcoin for payments. I'm afraid that somebody who is supposed to pay me the Bitcoin amount of $5 USD will feel appalled at the very notion of paying another $5 in Bitcoin just to send my service that actual $5.
I've done numerous Bitcoin transactions, but it has varied wildly in the amount. I can't really figure out how Bitcoin Core is deciding on the amount. (I've never changed it in.)
I'm aware of these "side-chains", but I don't understand how I'm supposed to actually use them in practice. Introducing a bunch of requirements and extra complexity seems even worse than having people "bite the bullet" with large fees (compared to the amount sent).
You might say that I should be having them "deposit" Bitcoin and then hold it on my side, but due to the way that this service is constructed technically, as well as the expected usage pattern, such an "account" cannot be made; they have to get an "invoice" for each time they purchase something, with a unique Bitcoin receive address to which they send the amount. Again, the problem is that I fear that the transaction fees will put people off.
In general, how should I handle this?

Bitcoin transaction fees are usually calculated based on the size (in bytes) that the transaction takes up. This is a number known as 'fee rate', usually written as 'satoshis per byte', and the idea is that you are bidding for space within a block, where most miners will select transactions with the highest sat/byte fee to prioritize for confirmation. The average fee rate according to Bitinfocharts is about 97 sat/byte, meaning for each byte the transaction takes up, you add 0.00000097 BTC in fees. You can probably get away with using anywhere from 50-100 sat/byte and have your transaction confirmed within a reasonable amount of time. The value of the transaction in BTC is completely irrelevant.
If you're handling many withdrawals, often, service operators will batch the withdrawals of multiple users together into a single transaction to save on fees, by generating a transaction that has many outputs, one for each user's withdrawal. Alternatively, you could offer deposits and withdrawals through the Lightning Network to minimize fees.


text:
How do I export an xpub from Bitcoin Core for use in BTCPayServer?
I'm using Bitcoin Core 0.17, and using bitcoin-cli getaddressinfo method to extract xpub for a given address.
This xpub is 66 characters long, and I'm using BTCPayServer which needs this xpub and I've to select one of the following address type corresponding to this:

P2WPKH
P2SH-P2WPKH
P2PKH

What I'm trying to do : I'm trying to link my wallet to BTCPayServer, in order to do so their admin panel needs an input for xpub and it also asks to specify the exact format of that xpub/derivation scheme. I don't want to use a wallet like electrum so I'm creating my own private keys through bitcoin-cli

Maybe first explain what you're trying to do.

I've edited my question, added screenshot where this information is to be input

This is not currently possible, as Bitcoin Core uses hardened BIP32 derivation to compute keys and addresses. This derivation scheme does not have a usable xpub that lets you derive the same keys publicly.
For more background, an xpub (or extended public key) is a string defined by BIP32. Every xpub has a corresponding xprv (extended private key). From the xpub one can derive a large number of child public keys, whose private keys can be derived from the corresponding xprv. This permits watching a large number of addresses without explicitly transferring all public keys.
The downside is that the xpub derivation scheme has a weakness: if an attacker knows the private key of any of the child keys and the xpub, he can compute the private key of all child keys. Because of this corcern, Bitcoin Core does not currently support xpub-compatible key derivation.
This will likely change in a future version with the introduction of descriptor wallets, which are far more flexible in specifying what keys and addresses belong to the wallet.

understood, that makes sense. so now, if I still want to link it to my bitcoin-cli generated xpub. What's the best way to convert that 66 char xpub to one of the desired formats using a tool or wallet ? (I understand it will be less secure)

You can't convert it. This functionality is simply not possible; the keys generated by Bitcoin Core cannot be predicted by an xpub. You can use other wallet software, however.

Time to update this answer? I think with listdescriptors RPC it's possible.


text:
why is BIP 39 unanimously discouraged for implementation and what should I do about that
Let's say I come new to the space and I find these three facts:

Everybody advice against hot wallets unless loose change, telling to use cold storage instead.
Every cold storage device seems to be based on BIP 39 mnemonics.
BIP 39 is unanimously discourage for implementation.

I just came into the space and found three simple facts that together seem make a rather (alarmingly?) inconsistent landscape (or what did I got wrong?). Are BIP commentators stiff condescending nitpick intelligentsia? Are cold storage vendors reckless brick-and-mortar profit-seeking CEO-wannabe grunts? Am I overthinking this or is this a confusing actual source of cognitive dissonance? If so does such cognitive dissonance scare away any newcomers?
Can you try to help me figure it out, I try to reason like this:

Advising against hot wallets seems to make sense as a first measure against exploits.
If every cold storage device is based on BIP 39 mnemonics, it sort of speaks that for some reason cold storage vendors don't care too much on BIP comments.
The unanimous discourage for implementation note doesn't seem to expand much on particular example posts discouraging implementation.

So why is BIP 39 unanimously discourage for implementation (with or without having to look back to the mailing list, does it make sense to write a little summary here...)?.

Did you see the comment section of the bip? https://github.com/bitcoin/bips/wiki/Comments:BIP-0039

aw, geez, it was right there

BIP 2 provides for comments that can be posted on BIPs on the Bitcoin.it wiki. Currently, all comments about BIP 39 are negative, which is what is summarized as "unanimously discouraged for implementation". All that is needed for that summary to change is for someone to post a positive comment.
Now, the comments mechanism seems to be pretty much completely abandoned, making the summary potentially out of date with reality. I do think it'd be better if it was dropped for that reason, but so far, no new BIP has superseded the mechanism of BIP 2.
Lastly, as far as the contents of your own (apparent) opinion goes, note that opinions against BIP 39 are not necessarily opinions in general against all seed phase based mechanisms, and certainly not opinions in favor of hot wallets (because one can have cold wallets that are not BIP 39 based).


text:
How does the network verify previous transactions when transferring BTC between two users?
When transferring BTC between two users, the new transaction will consist of references to previous transactions.
For example, if I user A wishes to transfer 1 BTC to user B, he will need 'n' transactions totaling 1 BTC in order for the transaction to be valid.
If these 'n' transactions occur with large periods of time between them (say 1 year) and for some reason I felt the absolute necessity to verify that these 'n' transactions actually took place.
How would I find the relevant block?
Would I decrypt the block to read it? Is this ever done in actual practice and is it expensive and time consuming to do it?

I felt the absolute necessity to verify that these 'n' transactions actually took place. How would I find the relevant block?

A transaction consumes inputs, and creates outputs (new 'unspent transaction outputs' or UTXOs). For the transaction to be valid, each input must be a valid UTXO that exists on the network. Full nodes keep a continually updated index of all valid UTXOs, that they can check against incoming transactions.
A transaction input will reference the transaction which created it, via the transaction ID and the output index. So a full node will just look up that entry in the UTXO index, ensuring it exists and is being used validly.

Would I decrypt the block to read it?

Blocks are not encrypted, but you will have to parse through the relevant blocks to obtain the relevant transaction data.

Is this ever done in actual practice and is it expensive and time consuming to do it?

Yes, this is done by each and every node, for each and every transaction / block. Checking a single transaction is not a computationally expensive procedure, but there is consideration for the sum of verifications a full node must compute in order to synchronize with the network. In order to maintain a robust and decentralized network (which is integral to the network's properties), it is important that the total resource requirements to run a node remain relatively low, to ensure that a sufficient number of nodes are able to stay online.

You don't need to parse the relevant blocks if you keep all information about UTXOs in a UTXO database (like Bitcoin Core does). In that case, the UTXO set is not an index into the blocks; it is a fully self contained database of all unspent outputs.

@PieterWuille so a node contains the blockchain as well as a database called a UTXO database that contains all unspent transaction points of all nodes (people) on the network? Also what happens when a transaction is spent? Is it removed from the UTXO table or a special column in the DB is updated to specify a spent transaction?

Yes. When a transaction is confirmed in a block its inputs are removed from the UTXO set, and its outputs are added to it.


text:
Should I share my seed phrase to earn airdrop tokens?
Someone on Face Book said I could earn free crypto by appying for an airdrop. He told me to download Blockchain from app store to my phone. I did this and created my account with a password. I also created my 12-word phrase. I was then told to go to: https://www.blockchainairdroptechnology.com/
This site then asked me to type in my 12-word phrase to receive my free crypto. Is this a safe thing to do? Is this a potential scam?

In general, if you have to ask if something is a scam, it probably is :p

No, it is not safe. Never share your 12 word phrase. It is a backup of your private key and allows people to spend your money. They only need your public key or Bitcoin address to give you money, not your private key.


text:
Failed to start bitcoind using Ubuntu 20.10
I keep getting this error when I run sudo systemctl start bitcoind.service
Job for bitcoind.service failed because the control process exited with error code.
See "systemctl status bitcoind.service" and "journalctl -xe" for details.
When I input sudo journalctl -xe I get this.
░░ The job identifier is 6033.
abr 15 16:16:36 sats-desktop bitcoind[7207]: Error: Error parsing command line arguments: Invalid parameter -daemonwait
abr 15 16:16:36 sats-desktop systemd[1]: bitcoind.service: Control process exited, code=exited, status=1/FAILURE
░░ Subject: Unit process exited
░░ Defined-By: systemd
░
░░
░░ An ExecStart= process belonging to unit bitcoind.service has exited.
░░
░░ The process' exit code is 'exited' and its exit status is 1.
abr 15 16:16:36 sats-desktop systemd[1]: bitcoind.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ ░░ The unit bitcoind.service has entered the 'failed' state with result 'exit-code'.
abr 15 16:16:36 sats-desktop systemd[1]: Failed to start Bitcoin daemon.
░░ Subject: A start job for unit bitcoind.service has failed
░░ Defined-By: systemd
░░ ░░ A start job for unit bitcoind.service has finished with a failure.
░░
░░ The job identifier is 6033 and the job result is failed.
abr 15 16:16:36 sats-desktop systemd[1]: bitcoind.service: Scheduled restart job, restart counter is at 5.
░░ Subject: Automatic restarting of a unit has been scheduled
░░ Defined-By: systemd
░░ Support:  ░░ Automatic restarting of the unit bitcoind.service has been scheduled, as the result for
░░ the configured Restart= setting for the unit.
abr 15 16:16:36 sats-desktop systemd[1]: Stopped Bitcoin daemon.
░░ Subject: A stop job for unit bitcoind.service has finished
░░ Defined-By: systemd
░░ ░░ A stop job for unit bitcoind.service has finished.
░░
░░ The job identifier is 6113 and the job result is done.
abr 15 16:16:36 sats-desktop systemd[1]: bitcoind.service: Start request repeated too quickly.
abr 15 16:16:36 sats-desktop systemd[1]: bitcoind.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░
░░
░░ The unit bitcoind.service has entered the 'failed' state with result 'exit-code'.
abr 15 16:16:36 sats-desktop systemd[1]: Failed to start Bitcoin daemon.
░░ Subject: A start job for unit bitcoind.service has failed
░░ Defined-By: systemd
░░
░░
░░ A start job for unit bitcoind.service has finished with a failure.
░░
░░ The job identifier is 6113 and the job result is failed.
lines 1841-1894/1894 (END)

When I input systemctl status bitcoind.service I get this:
bitcoind.service - Bitcoin daemon

Loaded: loaded (/etc/systemd/system/bitcoind.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Thu 2021-04-15 14:13:16 CEST; 21min ago

Process: 5604 ExecStart=/usr/local/bin/bitcoind -daemonwait -pid=/run/bitcoind/bitcoind.pid -conf=/home/sats/.bitcoin/bitcoin.conf -datadir=/home/sats/.bitcoin (code=exited, status=1/FAILURE)
abr 15 14:13:16 sats-desktop systemd[1]: bitcoind.service: Scheduled restart job, restart counter is at 5.
abr 15 14:13:16 sats-desktop systemd[1]: Stopped Bitcoin daemon.
abr 15 14:13:16 sats-desktop systemd[1]: bitcoind.service: Start request repeated too quickly.
abr 15 14:13:16 sats-desktop systemd[1]: bitcoind.service: Failed with result 'exit-code'.
abr 15 14:13:16 sats-desktop systemd[1]: Failed to start Bitcoin daemon.

Some idea how can I solve the problem??

Seems that you have an error in bitcoind starting options, you have -daemonwait instead of -daemon, you can check with systemctl cat bitcoind.service
The file to edit should be /etc/systemd/system/bitcoind.service

Thanks. It seems it works now.

you don't have to add another answer to thanks, you have to accept the answer (if it is correct) and eventually add an upvote with the up arrow above the 0 :)
if you want to add some comment you can do it under my answer using the link "add comment"

Please don't add "thank you" as an answer. Instead, accept the answer that you found most helpful. - From Review


text:
Sending bitcoin to new address using Bitcoin-Qt 0.8.6
I have an old tablet with Bitcoin QT. When I go to set an address to send bitcoins, it doesn't let me fill in the entire address. It allows me 4-5 characters less. How do I allow a longer address? The software is Windows 8, Bitcoin QT 0.8.6

I've taken the liberty to summarize the problem better in the title. Feel free to revert/edit if you disagree.

Bitcoin-Qt 0.8.6 is over ten years old. Based on your mention of "longer addresses", I am guessing that you are trying to send to a native segwit address (starting with bc1…). The segwit protocol upgrade activated only seven years ago. Your software does not support the new address format, because it was released years before the new address format was introduced.
I see three approaches from simplest to more effort that may resolve your issue:

Request a "legacy address" from the recipient
Many wallets and services support generating old address types to mitigate this form of incompatibility. Check if you can get a "legacy address", "Pay to Public Key Hash (P2PKH)", or "Pay to Scripthash (P2SH)" address from the recipient. Your software will be able to send to those.
Forward the payment with a second wallet
You could install a second wallet on your phone or a computer that can generate legacy addresses for receiving and also has support for sending to the recipient. Then you send your funds first from the old wallet to this new wallet and forward it from the new wallet to the recipient.
Upgrade your software
Any version of Bitcoin Core (which Bitcoin-Qt is part of) can import all prior versions’ wallets. Make one or several backups of your wallet, then import a copy of your wallet into a new version of Bitcoin Core on the same or another machine. The new software version will be able to import or migrate the wallet, and will also be able to send to modern addresses.

Either way, I would recommend making a backup of your wallet if you have not made one yet, as you appear to be using a device that may be at least 10 years old.

Is it possible to send to a new address from the console? What are the steps?

Your Bitcoin Core version is older than the segwit soft fork, so it does not support sending to the newer output types.


text:
Fell for crypto Scam, I NEED HELP
I think I am being scammed right now - I have researched (too late) about this operation and a lot of stories seem to match what is happening to me right now. They made me pay a 30% fee to withdrawal with my funds in hostage and then said that my account is suspected of money laundering and I would need to pay 6K USDT deposit with 3 days or else they will be "frozen forever". This definitely sounds like some bull.
However, Becent is has no noise around it and has been around since 2015 so I am not sure... Has anyone else had this happen to them by Becent?
The platform looks exactly like other confirmed scams such as Hydefieco..

This is a scam.

What can i do to get my funds back?

@HannahHowell unfortunately, you most likely will be unable to recover your funds. You can report the incident to your local law enforcement, etc. Best of luck.


text:
Standardness rules related to BIP 16 (P2SH)
I can read in BIP0016 wiki the P2SH Specification

Transactions that redeem these pay-to-script outpoints are only
  considered standard if the serialized script - also referred to as the
  redeemScript - is, itself, one of the other standard transaction
  types.
The rules for validating these outpoints when relaying transactions or
  considering them for inclusion in a new block are as follows:
Validation fails if there are any operations other than "push data"
  operations in the scriptSig. Normal validation is done: an initial
  stack is created from the signatures and {serialized script}, and the
  hash of the script is computed and validation fails immediately if it
  does not match the hash in the outpoint. {serialized script} is popped
  off the initial stack, and the transaction is validated again using
  the popped stack and the deserialized script as the scriptPubKey.
  The rules for validating these outpoints when relaying transactions or
  considering them for inclusion in a new block are as follows:
Validation fails if there are any operations other than "push data"
  operations in the scriptSig. Normal validation is done: an initial
  stack is created from the signatures and {serialized script}, and the
  hash of the script is computed and validation fails immediately if it
  does not match the hash in the outpoint. {serialized script} is popped
  off the initial stack, and the transaction is validated again using
  the popped stack and the deserialized script as the scriptPubKey.
  ...

OP_CHECKSIG and OP_CHECKSIGVERIFY count as 1 signature operation, whether or not they are evaluated.
OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY immediately preceded by OP_1 through OP_16 are counted as 1 to 16 signature operation, whether or not they are evaluated.
All other OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY are counted as 20 signature operations.

But in Antonopoulos's book I can read

Prior to version 0.9.2 of the Bitcoin Core client, Pay-to-Script-Hash
  was limited to the standard types of bitcoin transaction scripts, by
  the isStandard() function. That means that the redeem script presented
  in the spending transaction could only be one of the standard types:
  P2PK, P2PKH, or multisig nature, excluding RETURN and P2SH itself. As
  of version 0.9.2 of the Bitcoin Core client, P2SH transactions can
  contain any valid script, making the P2SH standard much more flexible
  and allowing for experimenta‐ tion with many novel and complex types
  of transactions.

Now, I'm using 0.19.0 and I'm able to create custom script and rely it in my regtest enviroment.
the question is: Can The BIP0016 is obsolete? And if it is, where I can see which BIP is became obsolete?

In general, changes to policy rules are not specified in BIPs. They're up to individual clients anyway.
BIP16 is not obsolete, though its description of the standardness rules in Bitcoin Core is outdated by now. However, its consensus rules (i.e., what is valid in a block, not what will be relayed as individual transactions) are unmodified since it activated in 2012 — anything else would be a hard fork.
As far as policy in Bitcoin Core goes, in version 0.10.0 (2014), relaxed standardness for P2SH spends, allowing any script using up to 15 signature checks. Several later changes to standardness were made (including every script-affected softfork (CLTV, CSV, Segwit) was accompanied with making corresponding spends standard), but none so fundamental.
Today (Bitcoin Core v0.19.0) standardness rules for P2SH spends include:

Max scriptSig size is 1650 bytes including redeemScript (not enforced on testnet)
Max 15 signature checks in the script (not enforced on testnet)
No opcodes intended for future upgrades (NOP3-NOP10) [discourage upgradable nops rule]
No non-DER encoded signatures, or hybrid public keys [strictenc rule]
No signatures with s values in the upper half of the range [low-s rule]
The additional argument popped by OP_CHECKMULTISIG(VERIFY) must be exactly the empty byte array (as pushed by OP_0) [nulldummy rule]
All pushes must use the minimal size encoding (OP_i instead of direct pushes where available, no OP_PUSHDATAi when unnecessary), integers can't have unnecessary zero padding [minimaldata rule]
Execution must end with exactly one non-zero element on the stack [cleanstack rule]
Checksig operations that fail must be passed an empty signature [nullfail rule]
OP_CODESEPARATOR cannot be used (not even in an unexecuted branch).
Signatures that are verified cannot appear in the scriptPubKey (they must come from the scriptSig) [const scriptcode rule]
At the transaction level: no tx version above 2, and the whole tx cannot be larger than 400000 weight units (100000 bytes if no segwit inputs are present).

Thanks so much. According to MCCCS's answer, I can't replicate the rules on regtest and testnet? I don't Use acceptnonstdtxnin my conf.

Regtest is identical to mainnet for everything listed here. Testnet is slightly different (it doesn't have the max scriptsig size or max 15 signature check rule, but all other listed rules still apply).

thanks again for your time! In general, regtest is close to mainnet, testnet is slightly different

Sorry I updated my comment, can you check if u can?

Yes, seems correct.