text:
How to upgrade Bitcoin daemon in ubuntu 12.04?
I am currently having Bitcoin daemon version 0.9.0 and bitcoind getinfo shows error like "Upgrade required"
{
"version" : 90000,
...
"errors" : "URGENT: Upgrade required: see https://www.bitcoin.org/heartbleed"
}
How to upgrade Bitcoin daemon in ubuntu 12.04 and want to know daemon is sync blocks once again needed?

Update
The Ubuntu PPA has been updated with packages for Bitcoin Core 0.9.1.  Ironically, they make the upgrade warning go away, but they do not fix the problem!
The Bitcoin Core packages for Ubuntu do not include a dependency on a fixed version of the OpenSSL libraries.  Therefore, if you have not upgraded OpenSSL on your Ubuntu system, you will still be able to install the Bitcoin Core 0.9.1 packages.  It runs just fine, and displays no warnings, yet is still vulnerable.
So upgrading to the Bitcoin Core 0.9.1 packages is neither necessary nor sufficient to remove the vulnerability.  The one and only thing to do is to upgrade OpenSSL, and then (other than the warning message) it does not matter whether you use 0.9.0 or 0.9.1.  Bitcoin 0.9.1 has absolutely no functional changes versus 0.9.0 (I diffed the sources).
To summarize:

Bitcoin 0.9.1, new OpenSSL: Not vulnerable, no warning
Bitcoin 0.9.0, new OpenSSL: Not vulnerable, displays warning
Bitcoin 0.9.1, old OpenSSL: Vulnerable, no warning
Bitcoin 0.9.0, old OpenSSL: Vulnerable, displays warning.

I will try to find the proper place to report this as a bug.
Previous discussion
The Heartbleed bug is not in bitcoind itself, but in the OpenSSL system library on which it depends.  The bug is "fixed" in Bitcoin Core 0.9.1, but all they did was to require the use of OpenSSL 1.0.1g, which incorporates the actual fix.
However, Ubuntu has not updated their distributed version of OpenSSL to 1.0.1g; instead, they have patched the version that they are using.  The patched version is 1.0.1-4ubuntu5.12.  Ubuntu's security advisory is posted at http://www.ubuntu.com/usn/usn-2165-1/.
Possibly as a result of this, Ubuntu packages for Bitcoin Core 0.9.1 have apparently not been created; but if you upgrade your OpenSSL libraries, it is not necessary to upgrade Bitcoin Core.
If you have the precise-security repository in your software sources (or in /etc/apt/sources.list), all you need to do is install the updates as you normally would, using either the update manager or aptitude update; aptitude upgrade.  If you have unattended upgrades enabled, this has probably happened already.  You can check the installed version by running dpkg -l libssl1.0.0.
Once this is done, you should restart bitcoind.  (In fact, if possible you should probably reboot the system, to ensure that other potentially vulnerable services are also restarted.)
In general, upgrading Bitcoin Core does not require you to re-download the block chain.

I did all you wrote, but bitcoind still reports an error: "URGENT: Upgrade required: see https://www.bitcoin.org/heartbleed"

The warning will still appear since it only checks the version number of Bitcoin Core, but once OpenSSL is upgraded, the warning can be ignored.

"Error", "URGENT" - Does not sound like a harmless warning that can be ignored. To me this sounds as if bitcoind had detected a really grievous and serious problem. I wish there was a package for version 0.9.1 for Ubuntu 12.04.

Nate, why should I trust you more than the error message?

@Hubert: All of this software is open source; you can verify that all the changes made are as I have said, and I would encourage you to do so rather than taking my word.  Other options include finding another way to upgrade, or to stop using Bitcoin for a while, or find another client you trust more.

@HubertSchölnast: Please see my update.  It appears you can't actually trust the error message at all.

@NateEldredge Added sudo add-apt-repository ppa:bitcoin/bitcoin & sudo apt-get update then install  sudo apt-get install bitcoin gives followin E: Unable to locate package bitcoin

@M.R: the packages are named bitcoin-qt  and bitcoind.


text:
How to install litecoin daemon in AMI
I have cent os in my amazon ec2 instance i try this post to install litecoin daemon after done compilation and run ./litecoind gives the following error
litecoind: key.cpp:134: {anonymous}::CECKey::CECKey(): Assertion `pkey != __null' failed.
Aborted

How to configure litecoin.conf in AMI?

In my personal experience, CentOS is the absolute worst choice of Server OS for compiling altcoins. I have yet to compile and run a single daemon on this Operating System. Cent OS is dead. Instead, use Ubuntu or any other Debian based OS and enjoy the benefits of painless compiling.
If you're in a situation where your main application resides on a centos server, and you don't want to change up your whole operation my suggestion would be:
buy a small vps and put ubuntu on it(install fail2ban and clamav, in addition to dependencies.
then download and configure yaproxy to safely tunnel into the vps(you can make rpc calls from the subnet without outside exposure). now make a database on the main server to store your wallet credentials.
now you need to setup ufw at this point.
you should allow with UFW the following:
connection to the default port of the wallet from any ip or a list of trusted nodes
connection for yaproxy confined to the ip of your main server.
connection to the rpcport from localhost to the subnet address of the main server
anyway, probably went way into left field on this one, but it should be enough to get your headed in the right direction when you inevitably realize why you can't compile correctly on cent os. it's because no body updates the yum package repositories, because cent os is just waning in popularity for various reasons.

when make file use this:  " OPENSSL_LIB_PATH=/usr/local/lib64 "
make -f makefile.unix USE_UPNP=- BDB_LIB_PATH=/usr/local/lib OPENSSL_LIB_PATH=/usr/local/lib64

source: Stack Exchange

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

sort: votes


text:
How does cryptsy.com currency trading works?
I am using cryptsy and i am unclear how cryptsy works, At first i deposited dogecoin to newly generated address and then I made the sell offer for DOGE/LTC, now i am having some LTC but i don't see any Litecoin address in cryptsy
My questions are,

In which address my LTC balance available?
If coins are stored in db level, how it is possible to withdraw that coin?

You do not own a LTC-address (or BTC, or any other altcoin) on cryptsy or any other virtual currency exchange site. You can however see your balance of all crypto currencies in the 'Balance' tab. When you scroll down, you will see the LiteCoin with your current available balance and the balance that is in possible orders. If you want to have your LTC in an address, you should download an LTC-wallet app, and create a wallet in there, and then withdraw (from cryptsy) to that wallet.
And your second question: yes, cryptsy is a crypto currency exchange. So far there is no option to trade in any real currency, but I see that option is coming in a week or so, because this text is above the BTC/USD market
This market is for Verified Accounts Only. The User Verifications system will open within the next week.

Anyhow, what happens when you withdraw LTC to your own wallet, is that cryptsy looks at deposit wallets (for other people) they own. For example person A, B and C have all a different deposit wallet, and they deposited 1, 2 and 3 LTC respectively. You had fun trading, and want to withdraw 2.5 LTC. Cryptsy sends 2.5 LTC from the deposit wallet from person C, so there is only 0.5 LTC left in that wallet and you have (after confirmation) 2.5 LTC in your wallet.
When you trade, there is no 'real' LTC being transferred between wallets, only on withdrawl and deposits. Otherwise you cannot trade that fast (and other disadvantages, like fees and huge blocks)

I don't know much about Cryptsy, but why do you assume you should have an LTC address already?  Maybe the way out works is your LTC balance is just a number in their database.  If you want to use the funds you should look for a "withdraw" option and learn how that works.
And to answer your second question, yes, it looks like Cryptsy is an exchange but you should know that because you already traded doge for LTC on cryptsy.

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


text:
Is bitcoin arbitrage profit varies with BTC market price?
Consider the following scenario,
I have 365 USD in Btc-e and 1 BTC in Cryptsy, now I bought 1 BTC at a price of 362 USD in Btc-e and sell it on Cryptsy with 370 USD, now I made the profit of 4 USD (included txn fee), now the current market price of 1 BTC is 370 USD
Market price I mentioned was 1 BTC = 360 USD

How the market price affect my profit?
Still I have 8 USD profit in Cryptsy or I made a loss/profit with respect to market price?

Note that both of those exchanges will charge you a fee - usually on the order of a third of a percent. (About 1 USD on each end.)

@NickODell, Ok lets take approx profit as 4 USD

There is no one market price. Each exchange has it's own. Also you have made 0 profit until you have either the btc in your own wallet or the money on your back. I have a 10x profit on mtgox too. Other than that I don't understand your actual question.

@Jannes, If there is no one market price then how would you know the profit in USD?

That's my point. You don't. As long as the USD is not in your bank account it's not USD but rather USD-on-Cryptsy or USD-on-BTCE. Or my USD-on-MtGox...

If you want to make money on arbitrage like this, you should have reserves on both exchanges, and at the moment when you are buying in btc-e, you should sell at cryptsy (for example). Otherwise te price can change to "wrong" direction when you are transfering bitcoins from btc-e to cryptsy or vice versa. Also, you should understand how to withdraw/deposit fiat to this exchanges fast with minimal expences, that can be the biggest issue especially for btc-e.


text:
What is "Verifying last 288 blocks at level 3"?
Upon every start of bitcoind, I see the following in de debug log:
Verifying last 288 blocks at level 3

come up. At this point, no new blocks have been downloaded and the block chain was 100% up to date when I last closed bitcoin. Bitcoind does not do anything before it has 'verified' these 288 blocks (the server does not answer until this phase has passed).

Why do the last blocks need to be verified if nothing new has been added since shutdown?
Does this verification make any changes to any files? Does it save anything to the blocks / chainstate / database directories?

bitcoind -help-debug shows these options, not shown in man bitcoind or bitcoind --help:

-checkblocks=<n> : Check the last n blocks.  Defaults to 6, and 0 indicates checking all which would take a very long time.
-checklevel=<n> : Perform the following verification on each block to be checked, including verifications at lower levels: (defaults to 3)

0 : Reads from disk without error
1 : Blocks are valid
2 : Blocks have valid undo data
3 : Look for disconnected tip blocks
4 : Attempt reconnecting the blocks

Since this is a 5 year old question, at that time, I'm guessing it may have defaulted to more blocks, since you mentioned 288 blocks.
You can lower these values to get it to finish starting and respond faster, but you risk things going horribly wrong if something went wrong the last time it shut down, disk corruption happened, or someone maliciously altered the files.
I'm not sure what caused this, but a while ago, I ran into an error saying "Corruption: block checksum mismatch", so this verification did alert me to there being a problem, allowing me to immediately restore from backups.

It is to verify the block database has not been damaged or tampered with. It does not modify the databases in any way.

What does "level 3" mean? Can it be set to a different value to make the verification faster?

@rraallvv see other answer

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


text:
What are the methods for getting an old, used windows P.C. ready for secure Bitcoin usage?
Let's say I am about to set my Grandmother up with a wallet. I have no idea what she has on her computer. There could be a host of malware, keyloggers etc. Let's also say that a complete wipe and reinstall is not an option.
I was thinking of what steps I could use to give the maximum protection.

I could use CCleaner to wipe any temporary files. This will remove any excess past data she has generated.
I could then use a program spybot search and destroy to check for any malware.

What else could I do to check if there are any threats on the computer?

Pave it and start over? If you suspect malware, why do anything less?

Do a backup, then format and reinstall her computer, next install a bitcoin client within a virtual machine appliance and not directly on the real machine's OS. Or better yet: buy her a Raspberry Pi, configure it as a single purpose computer/tablet and install a client onto it. If she can't install sw. nor navigate the web on it she'd be most safe!

Thanks guys I added some clarity, I meant if a total reinstall is not an option also.

This question appears to be off-topic because it is about general virus cleaning a Microsoft machine. It would likely better be asked on another StackExchange site.

If a reinstall is not an option for you then you should do the following:
Requires: CCleaner

Boot in Safe Mode so that any malware start up entries don't get executed.
Use CCleaner to clean up disk space and registry.
Inspect the Start Up list for any suspicious/unwanted entries and
remove them.
Reboot the computer.
Use any anti-virus to remove any present malware and clean infected
files.

This should clean your old pc.
Source: Experience

Terrible advice! Anything short of complete wipe and reinstall is insufficient. And even then you have to hope there's nothing hidden in any BIOS of the PC or the harddisk or any other flash ROMs.

You cant remove BIOS infection by a reinstall. Also the virus on the hard disk  would get removed by using the av but before that safe mode has to be used so that they don't get executed and prevent access to av sites ie ransomware. Why the down votes then?

Bios: that's what i said, and there are many more places where malware may hide. Downvotes: cause you're better off just removing the answer. It's misleading as 'accepted answer'. The whole question is off topic and on hold anyway.

It's not misleading. It's according to the requirement of the question.


text:
How can I make MultiBit go one year back and then replay the blockchain?
Like a year ago, I got a some bitcoins. I was using Bitcoin-Qt back then. Because reading the whole blockchain since then takes a lot of time, I got MultiBit, created a new wallet and imported my private keys from Bitcoin-Qt.
The problem is that MultiBit only goes back a few days (looks like one day before I created my wallet in MultiBit) to replay the blockchain. So the balance shown is wrong. The function "Reset Blockchain and Transactions" doesn't help.
How can I make it go one year back and then replay the blockchain? At least I think that's what I need, I just don't know how.
Thanks in advance.
EDIT:
Thanks for the help. Yes, I have imported them all. I've just reset again. I see that MultiBit goes back to November 2013 and starts replaying the blockchain from there. But that's just too late. It should go back to January 2013 instead. I just double checked one of the receiving addresses on blockchain.info. The transaction took place on 16th of January 2013 and the money from that address hasn't been spent yet.

I think this question is an XY-Problem. If I understand correctly, the main question should be "After importing my private keys to MultiBit from Bitcoin-Qt the balance is shown wrong. How can I fix it?"

Have you imported all Bitcoin-Qt keys or only your main address? Bitcoin-Qt sends change to new addresses by default, so if you send any Bitcoins, some might be on a second address now.

Wre you able to solve your problem? Please share the solution with us so it may be useful to others with the same problem in the future!

When you import private keys, you specify a replay date for each private key. This should be before the earliest transaction involving that address. In your case, it appears that this is not the case. (Or maybe you just need to reset again - their site says it might take up to 3 resets for the balance to be corrected.)
You should reimport your private key with the correct date specified to have the balance appear. Note that having your private key(s) in plaintext on your hard drive makes them an easier target for attackers. To be most secure, you should consider those keys compromised afterwards: securely delete the file when you're done with it, and transfer the coins to a new address and avoid using those old addresses again.
Another way of transferring the balance is to send it from your out-of-date Bitcoin-QT wallet to an address generated by MultiBit. I'm not sure if that's complicated, the wiki makes it appear simple.

I did specify a date that predates all of the associated transactions before importing the keys for the first time. (I tried a few times.) It didn't help.

Is there seriously no other solution than moving everything to a new wallet? Because even IF their ridiculous 3 reset problem works, it happens again after 1 transaction or after restarting the program.


text:
How does Blockviewer work? (tool to discover identities of "anonymous" bitcoin transactions)
I'm trying to follow the logical sequence of how Blockviewer works and only see this one blog entry for the process, but no "part 2".
Can someone describe the techniques to link a wallet address to the owner?

The technique was first described in form of formal study by researchers with the Clique Research Cluster at University College Dublin, blog post: An Analysis of Anonymity in the Bitcoin System, the research paper is here.
Imagine transaction of 1 BTC from address:Alice to address:Bob, blockchain shows that there was transfer of 1 BTC

1 BTC source:Alice, destination:Bob

Now, if a person controlling address:Bob wants to spend the 1 BTC he or she has to construct transaction that shows in blockchain as

1 BTC source:Bob, destination:Charlie

Lets say you see next three transactions in the blockchain:

1 BTC source:Jessica, destination:Alan
1 BTC source:Bill,   destination:Erik
2 BTC source:Alan,Erik   destination:Manhattan

To construct the 2 BTC transaction he or she has to have control over both Alan and Eric addresses in another words the person knows the private keys of it, therefore it's the same person, this is not true for a Bitcoin exchange or web based wallet were many people have limited access to the same private key.
Now if you know for sure, e.g. from forum signature, that address:Erik belongs to Gavin Anderson then you also know that address:Alan belongs to Gavin Anderson.
So far this technique didn't uncover any BTC theft and remains to be a toy. Also, there is many ways to block it, e.g. by using Bitcoin Anonymizer.


text:
A crypto-currency for supporting informal education?
I am involved with Funoon (funoonfoundation.org), a non-profit working to organise informal learning spaces. These informal spaces are basically physical spaces where learning happens on a peer-to-peer basis, guided by a mentor/ tutor.
We are brainstorming on how to incentivise talented people to come in and spend an hour or so weekly with a learning group. We can't pay them (at least not to start with), and without a solid incentive, its hard to get things going.
So I am wondering, if its a possibility to create a crypto-currency that solely exists to pay out a small chunk to anyone who comes along to mentor/ tutor at a learning space. My knowledge on how a crypto-currency works is quite limited, so I am looking to get enlightened  on this.

It's a nice thought, but I'm not sure it's what you want. It would have roughly the same appeal as paying the tutors in Monopoly money, and be a lot more work.

It is possible. However, there are a few difficulties. Normally, cryptocurrencies are based on a proof-of-work (PoW) scheme which involves computing data which is hard to find but easy to verify. A collision-resistant hash function such as SHA-256 or Scrypt is an example of this, and is used as PoW for a majority of existing cryptocurrencies. Unfortunately, there isn't really a cryptographic way to verify that someone has been legitimately tutoring for a period of time, so the currency will have to be issued by a central authority (i.e. you).
This means that you will have to hold a significant portion (perhaps all) of the coins in the beginning (in cryptocurrency circles, this is called a "premine"). If you hold all the coins, then you would be well-advised to choose proof-of-stake (PoS), where people leave their wallets open and are rewarded coins at a rate dependent on their current holdings (called "minting"), which incentivizes people to secure the network. (Otherwise, there would be no miners to process transactions since there's no incentive to do so, and the coin would be dead.) Alternatively, you can premine something like 10% or 50% of the coins, leaving the rest to be mined just like Bitcoin or Litecoin on a decreasing schedule. Here PoW miners are willing to secure the network for you because of the block rewards.
The issue with premined cryptocurrencies is that many people don't trust a single entity with all those initial coins, so they are unlikely to gain much value. Thus your tutors might not be willing to work for essentially worthless coins. And besides, since you're going to have a lot of central control due to your premine, you might as well just create an in-house currency, kept track of on your servers, rather than a cryptocurrency. Maybe eventually have a online store where users can buy stuff using that currency.
Another alternative is to ask for Bitcoin donations (possibly from the students), and then pay tutors with that (or even have students tip tutors directly).


text:
How can I test if a bitcoin address is compressed or not?
I have two bitcoin addresses:
1D8VSXHFAWNhAbruwUMbNp4hsXAnRNkYvX
12T15tvMGaymMX97X9KxVzyLF323r8v6Hg

One is compressed, one is not.
How can I test which is which? (Preferably using python 2.7)
Thanks in advance :)

You cannot determine (from only a base58check address) if the corresponding public key is compressed.
A "normal" pay-to-public-key-hash (P2PKH) is a cryptographic hash of either a compressed or an uncompressed public key. Because hashes cannot be feasibly reversed, you cannot tell if the public key, before being hashed, was compressed or uncompressed.
More specifically, a public key in Bitcoin is a pair integers (x,y). For uncompressed public keys, these integers are encoded as 256-bit unsigned big-endian ints, concatenated together, and then prepended with a single 0x04 byte. The result is 65 bytes long.
For compressed public keys, only the x coordinate is encoded (like above, as 256-bit unsigned big-endian int). It turns out that the y coordinate can only be one of two values, one even and one odd. Instead of prepending a single 0x04 byte, a single 0x02 or 0x03 byte is prepended depending on y's value (0x02 for even, 0x03 for odd). The result is 33 bytes long.
Finally, these bytes (from one of the two paragraphs above) go through the address conversion process described here in the bitcoin.org Developer Guide, which includes taking an irreversible cryptographic hash (actually, two hashes).
Note that in order to redeem a UTXO associated with a P2PKH address, the redeemer must create a transaction which includes the unhashed public key, either compressed or uncompressed. If such a tx exists in the blockchain, it can be connected to its "normal" base58check address. This is one of the reasons why address reuse is discouraged: once you redeem a UTXO, you "reveal" your public key, which is slightly more sensitive than your bitcoin address.

Background info:

What is a compressed Bitcoin key?

Given just the address itself, no, there is no way to tell if it was generated from a compressed or an uncompressed public key. This is calculated from the base58 encoding of the RIPEMD(SHA256(public_key_bytes)). Since the hash isn't reversible, without the public key already in hand, you won't be able to get any more information.
Just look at the base58 decoded data:
$ decodeBase58 12T15tvMGaymMX97X9KxVzyLF323r8v6Hg
000FE302E0D96D9F9AA71738A426A9696EB49AD458679BAFD3

$ decodeBase58 1D8VSXHFAWNhAbruwUMbNp4hsXAnRNkYvX
00850C296420DC9B02CE237ED630B89815E0803EA3BED0F344

The version byte is 0x00 in both, then there's the 20 bytes of the hash, and a 4 byte checksum. None of this reveals any information about what information was hashed.

An address is the hash of the pubkey (plus checksum and versioning).  Hashes are irreversible and randomly distributed so there is no way to determined the pubkey from the pubkeyhash.

As the others mentioned, the short answer is no, but from a WIF(Wallet import format) key you can determine if the address is compressed or not by checking the last byte if it is 0x01.


text:
How do I remove hard coded seeds from the bitcoin source code?
I'm experimenting with blockchains at home and in my debug logs are lots of errors showing that my nodes are trying to get addresses from the hard coded seed nodes, I know I can use connect to turn off this behaviour but I don't want to have to include that in my bitcoin.conf file.
I am using Bitcoin v0.10.
Any hints greatly appreciated :)

If u wanna turn off the hard-coded seeds (or DNS) AND also not give explicitly the topology you wish to connect, how will u even do any p2p communication? U will need to connect to peers in some way right

I intend to add them manually in the config file with addnode but I keep getting annoying connection errors in my debug log. I just want to turn off the feature that tries to connect to the hard coded seeds.

There is a seed vector (for TestNet or Regtest) of hard-coded seeds that gets populated in the source code (vFixedSeeds in src/chainparams.cpp i guess?). U can either comment out them or simply clear the vector to empty it. Then u can explicitly have your topology

I appreciate the help, i have already done that though - https://github.com/derrend/bitcointemplate/blob/master/src/chainparams.cpp
Im looking at src/chainparamsseed.h and share/seeds/, I think these may be what I am looking for.

Please paste the error. I can help u

Thank you viesweshn92 but the mods i made to src/chainparamsseeds have fixed my problem, I will supply a more detailed answer below later. Thanks again :)

Awesome then! Kindly upvote my answer/comment ;)

There are a few ways to do it, I personally went into src/net.cpp and commented out the if condition that triggers the lookup starting at line 1266.
// if (addrman.size() == 0 && (GetTime() - nStart > 60)) {
//     static bool done = false;
//     if (!done) {
//         LogPrintf("Adding fixed seed nodes as DNS doesn't seem to be available.\n");
//         addrman.Add(Params().FixedSeeds(), CNetAddr("127.0.0.1"));
//         done = true;
//     }
// }

Another effective fix was to remove all the encoded seed nodes from the two arrays located in src/chainparamsseeds.cpp

There is a seed vector (for TestNet or Regtest) of hard-coded seeds that gets populated in the source code (vFixedSeeds in src/chainparams.cpp i guess?). U can either comment out them or simply clear the vector to empty it. Then u can explicitly have your topology

the seed nodes are generated in contrib/seeds
curl -s http://bitcoin.sipa.be/seeds.txt > seeds_main.txt
    python makeseeds.py < seeds_main.txt > nodes_main.txt
    python generate-seeds.py . > ../../src/chainparamsseeds.h
just edit seed.main.txt


text:
Can I verify a sub public key came from it's parent public key in a HD wallet without involving any private keys?
I know I can sign a piece of text using a bitcoin private key to prove control over a public address but are there any operations I can perform to know if a public key submitted to me was derived from a parent public key if I do not have any private keys at my disposal?
I have looked at:
https://github.com/richardkiss/pycoin and
https://github.com/jmcorgan/bip32utils
but have not yet found a way to do it.
Thank you for any input :)

Are you asking about BIP32 or deterministic type 2 wallets? See also: http://meta.bitcoin.stackexchange.com/questions/661/what-should-hd-wallet-mean

Yes I am but one specific use case in particular involving public key verification as described above, I'm hoping @Pieter Wuille (sipa) will see this question. Thank you for the link, I will check it out :)

Right, but which one are you asking about?

I'm only asking if it is possible to know that a child private key came from it's parent in the absence of any secret keys and what the method would be to do it. If this is BIP32 deterministic wallet then yes I suppose this is what I am asking about :)

Yes, you can, assuming that the child key isn't hardened, and you know the chain code of the parent public key and the index of the child. (Also known as the extended public key.)
Just compute

CKDpub((Kpar, cpar), i) → (Ki, ci)
Kpar is the parent public key, cpar is the chain code, i is the index, and Ki is the child public key

as defined here and compare it to the child key you were given.

Woohoo, thanks so much :) Needing to know the index is a bit of a bummer though because if I didn't know it then I would be forced to generate each child key from index 0 until I found the matching one, Am I correct in assuming this or could the index number be embedded in the key somehow?

@derrend You're correct. You only need to try 2^31 keys at most, though, so it's not too bad.

reading again over the link you gave me earlier, is there a method of achievig this using 'gmaxwell's proposal' and would it be more efficient?

@derrend 1) Yes 2) It's probably about the same in terms of speed and complexity.

Can you link me to some info if possible, I'd be interested see how it's done :)

@derrend This is the best resource I know of: https://bitcointalk.org/index.php?topic=19137.0


text:
Beginner, how to get bitcoins to invest?
What would be the best way to start from scratch in the bitcoin world without investing capital at first?

If you don't want to invest capital but still want to obtain some BTC, you will either need to earn it or be given it. Bitcoin faucets give a small reward for visiting the site, usually because of ad revenue the site obtains by the visits. The most reliable way to earn larger amounts of BTC would be to sell products or services in exchange for bitcoin (obviously selling products is similar to investing capital, but services such as freelance programming, etc. can pay well)


text:
How can I get the block number of given transaction?
For a given transaction, I have its incoming transactions and I am trying to get the number of the block of those transactions. This seems like something that cannot achieve directly.
I am working on python with Json RPC and I want to work directly on the block-chain on my computer and not to use online API such as blockchain.info.
How can I get efficiently the block number of a given transaction?

you are right, I should have write that: I am working on python with Json RPC and I want to work directly on the block-chain on my computer and not to use blockchain.info.

According to the Wiki, the gettransaction <txid> call return a JSON object with the following information
"amount" : total amount of the transaction
"confirmations" : number of confirmations of the transaction
"txid" : the transaction ID
"time" : time associated with the transaction[1].
"details" - An array of objects containing:
"account"
"address"
"category"
"amount"
"fee"

Now just use getblockcount and subtract "confirmations" of the JSON object.

Thank you Jori, your approach is probably the best. the problem is that getblockcount is not static (changes over time), hence if I have a bunch of transactions SAVED for more than ~10 min I can't work with your method. But maybe that the best way...Thanks!

@slouis "confirmations" isn't static either, but the difference between it and getblockcount should be. This would work even if you have your transactions laying around for a year.

Not if I am saving the whole transaction. But I got the idea. Thanks!

I'm afraid that I don't understand what you mean by that.

If I have 100000 transactions (hash), and I want to know which block each transaction is in: I will need to call "getblockcount" 100000 times - for every time that I call get("confirmations"). Is there a faster way? Furthermore, I might call getblockcount() - transactionx.get("confirmations") and in between there will be new block and the 2 counters (confirmation and blockcount) won't be correlated!

getblockcount() - transactionx.get("confirmations") will stay the same, because for every extra block there will be an extra confirmation counted. If you need to find the block of so many transactions, I'd recommend scanning the block chain and look for them with getblock or so. Then matching those transactions in a simple database to their corresponding blocks.+

authors: Серьожа Химченко


text:
Why doesn't Casa use hardened derivation?
I've noticed that Casa uses non-hardened derivation paths for both their key and my HW keys.
The path is the following m/49/0/1.
Does anyone have an idea of why it's the case? I mean, the risk of exposing their child xpriv or HW's one is minimal but wouldn't it make sense to harden it just to be safer?

Hardened derivation requires knowledge of the private keys to be able to derive additional public keys. Since both Casa and their customer only control a subset of the private keys in the quorum, neither would be able to derive additional addresses without interacting with the other party, overall activating each and every private key in the quorum. This would be arduous given the intended setup with the customer's hardware wallets in multiple locations and one of the keys held by Casa staged in a key recovery scheme. Even worse, if any of the private keys got lost, it would not be possible to regenerate any of the prior addresses: only money from addresses already known would be recoverable, even if the remaining four private keys were available.
It follows that using non-hardened derivation in this setup provides a better user experience and arguably a better risk trade-off.

thanks for the response, but I still don't understand how would hardened path prevent them from generating addresses. If for example they would extract m/49'/0'/1' xpub from my HW, they'd still be able to derive m/49'/0'/1'/0/1..N. Maybe it doesn't make much sense to harden their key, but on the user side it creates a theoretical risk of exposing(by user) e.g. m/49/0/1/0/1 xpriv and being able to derive the master PK doesn't it?

maybe I didn't make myself clear in the question. the addresses they derive are on top of the m/49/0/1, e.g. m/49/0/1/0/5. That's why I don't understand why wouldn't they ask for hardened m/49'/0'/1' instead when you add the key.

Ah good question. I'll have to think about it.

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


text:
BLS signatures vs Schnorr
How do BLS signatures (or other pairing-based schemes) compare to Schnorr signatures in terms of cryptographic assumptions?
Is it faster to verify, say 100 (non-interactively) aggregated BLS signatures than 100 aggregated Schnorr signatures?
Apart from relying on different assumptions, why wouldn't BLS signatures be interesting for Bitcoin?

How do BLS signatures (or other pairing-based schemes) compare to Schnorr signatures in terms of cryptographic assumptions?

BLS needs a pairing-compatible elliptic curve, which imposes additional structure on the curve. The elliptic curve used for cryptography in Bitcoin today (both for ECDSA and Schnorr), secp256k1, is not pairing-compatible.
This additional structure may be concerning. See it this way: normally when picking an elliptic curve for cryptographic purposes, there are a number of "gotchas" to avoid - properties that, if present, are either known or suspected to aid attackers to break its security. One of those properties is having a "low embedding degree":

A very low embedding degree (say, up to 3) gives a trivial way to compute private keys from public keys.
A sufficiently high embedding degree (say, 10 or more) is likely not a problem, in the sense that no way to exploit that is known.
A very high embedding degree (similar in magnitude to the order of the group itself) is almost certainly unexploitable (as otherwise every elliptic curve would be vulnerable).

secp256k1 has embedding degree 19298681539552699237261830834781317975472927379845817397100860523586360249056 (exactly 1/6 of the number of points on the curve).
Pairing-compatible curves however need a relatively small embedding degree; small enough to be tractable for computation (because signature verification actually involves computing this embedding), but also large enough to not result in making private keys easy to find. Currently popular pairing curves use embedding degree 12.
So, BLS requires curves that are from a traditional perspective "risky". It's not that this risk is unmanageable: obviously actual curves are constructed in such a way that there is no way to exploit this structure, but it is walking a fine line. The concern is that perhaps in the future other ways are discovered to exploit it. And us having selected parameters such that all known attacks fail isn't sufficient when new attacks get discovered.
Of course, that's not fundamentally different from other elliptic curve security, or cryptographic security in general. We always select parameters/curves/... in such a way that all known ways of attacking fail, and when new attacks get discovered, those parameters may not be sufficient anymore. But in the case of generic ECC, that's just one set of attacks to avoid. In the case of pairing-based cryptography, there is an entirely separate added newer set of attacks to worry about as well.
As for what this means for Bitcoin: I don't know. The question is just whether the Bitcoin community, as a whole, is ok with this added set of security assumptions that BLS would bring. And it isn't sufficient that it's optional; if (hypothetically) I personally would be uncomfortable with BLS's security outlook, I wouldn't want a large fraction of the BTC supply to become subject to it, as a break of pairing-based cryptography may threaten the currency's value overall, including my non-BLS-encumbered coins. So I believe this means the bar for adding new security assumptions is fairly high.

Is it faster to verify, say 100 (non-interactively) aggregated BLS signatures than 100 aggregated Schnorr signatures?

They're a few times slower per non-batched signature verification (aggregated or not). Batching (the act of verifying multiple pubkey/signature/message triplet simultaneously, only learning whether all or not all of them are valid) with sufficiently large batches however counteracts most of that slowdown.

Apart from relying on different assumptions, why wouldn't BLS signatures be interesting for Bitcoin?

They'd certainly be interesting. Lots of complications around multisignatures (see all the MuSig schemes) and multi-party spending in general are largely non-existent for BLS signatures. They're smaller too. The question is mostly one around acceptability of the added security assumptions, in my opinion.
There is one other (rather weak) argument against them I'm aware of. Schnorr (and ECDSA) signatures support adaptor signatures. These are a construction that makes it possible to use the publication of a signature to trigger revealing a pre-agreed secret, and are the basis for unlinkable atomic swap protocols that are indistinguishable from normal payments, and for PTLCs (a more private replacement for Lightning's HTLCs). BLS signatures however inherently don't support adaptor signatures—there is just no space in them to reveal anything. This means that in a world where everyone has migrated to BLS for nearly everything, these adaptor signature constructions would need to stick to Schnorr/ECDSA, and thus stand out and no longer be indistinguishable from normal payments.

Thanks for the detailed answer. Isn't it possible using taproot's MAST to allow for similar functionality (private atomic swaps, PTLCs, etc) w/o adaptor signatures?

No, because the point is exactly not using those. If the MAST (script tree) is used, you're revealing the script. The amazing property of adaptor signatures isn't just that they're small - it's that all that ends up on chain is just a signature, which looks exactly like every other signature.

AFAIK in the cooperative case all that ends up in the blockchain is a signature too

Yes, that's what I'm talking about. You can't use the script tree to reveal something in the cooperative case, because no script is revealed. If you have to reveal a script in the cooperative case, it's no longer indistinguishable from a single signature.


text:
Could the US government print crypto of its own?
I get very tired of having to walk cash and checks over to my credit union. Why shouldn’t I be able to spend money online without a debit card or an intermediary like PayPal?
An anonymous sort of Bitcoin backed by the US government seems like a good idea, no?

Very much No. We have a lot of paradigms why people's should not use money backed by government's. We should learn from history.  BTW I've disagree with the decision to close this question.

@Pegasus: I've reopened it, please feel free to write an answer.—Anyone answering, I think this can be answered relatively objectively by giving an overview of what governments could do, what governments are currently pursuing to do, how that differs from Bitcoin, and how that might work out. Please try to be heavy on facts, direct observations, and reproducible conclusions, and light on opinion, judgment, rumor, and preference. Also see Good Subjective, Bad Subjective.

Is it possible?

Could the US government print crypto of its own?

This partly depends on how you and the government run institutions define cryptocurrency. This kind of idea is sometimes referred to as a Central Bank Digital Currency (CBDC).
US
The US treasury has published a report on the future of money and payments which

reviews the U.S. system of money and payments, including such recent innovations as
instant payments and stablecoins, and a potential U.S. central bank digital currency (CBDC), and
considers the implications of these developments for key public policy goals including
supporting U.S. global financial leadership, advancing financial inclusion and equity, and
minimizing risks

So the possibility is being investigated, but there is no conclusion about whether it is possible to do this in a way that meets US government objectives.
UK
The Bank of England has published some information about the idea of a CBDC
Note that they say

People sometimes describe this possible UK digital currency as ‘digital sterling’ or ‘Britcoin’.

This creates a conceptual link between Bitcoin and a CBDC. However they also say

A CBDC is different from cryptocurrency (also known as cryptoassets). Cryptocurrencies are not issued by a central bank. These privately issued digital currencies include Bitcoin, Ether (Ethereum) and XRP.

(my emphasis)
This makes it clear that, for them, a key attribute of a cryptocurrency is that they are not issued by a government run central bank.
I think their article is well worth reading. However it seems clear that the Bank of England is not going to introduce a CBDC soon, if it all, and their CBDC might be very different from normal notions about cryptocurrencies.
Venezuela
In 2017, Venezuela announced a government backed cryptocurrency named the Petro.
So you could regard this as evidence that government run central banks can introduce cryptocurrencies.
However it is in doubt whether this is a successful model that other countries would want to follow. The Venezuelan government has had to mandate the adoption of the Petro, for example by requiring all petrol (gasoline) stations to accept it in addition to accepting the Bolivar. Recently they introduced a law that could require a taxation of up to 20% on "large" transactions made using competing cryptocurrencies and foreign fiat currencies.
Readers might like to ponder the likelihood of a US president relishing being seen to follow the Venezuelan precedent.

Is it a good idea?

An anonymous sort of Bitcoin backed by the US government seems like a good idea, no?

It is worth remembering that, Bitcoin, the first successful cryptocurrency, was created by someone who opposed the idea that central banks have any control over people's money.

The root problem with conventional currency is all the trust that's required to make it work. The central bank must be trusted not to debase the currency, but the history of fiat currencies is full of breaches of that trust. Banks must be trusted to hold our money and transfer it electronically, but they lend it out in waves of credit bubbles with barely a fraction in reserve. We have to trust them with our privacy, trust them not to let identity thieves drain our accounts. Their massive overhead costs make micropayments impossible.

- Nakamoto, 2009
I believe it is very clear that Bitcoin was created with the intent of removing the need for banks as intermediaries and without any possibility of government run banks having control over the money supply. These ideas are clearly at odds with any straightforward notion of a cryptocurrency minted by a US government agency.

Bitcoin
Obviously, none of the above can apply to Bitcoin as it exists today. A CBDC would be a separate cryptocurrency. No one national government can take control of Bitcoin globally. Any attempt would fork a parochial altcoin.


text:
I found an incorrect translation in Bitcoin Core, how can I suggest a fix?
In the French version of the Bitcoin Core (v26), a column in the peer tab is called "Age" which means age. It is wrong because Bitcoin Core is using peer which have no age, it is not as people age.
It should be called duration, so in French "Durée".

How would I go about getting this fixed?

To answer "How to contribute to translations for Bitcoin Core?"
Bitcoin Core translations are handled by an open source project called Transifex: https://www.transifex.com/bitcoin/bitcoin/ To add your fix create an account to Transifex, you can edit the translations on the web interface. Though be warned that it looks like the French translations are only accepted from the French team which might require you an application. You can also message in the web app the French team coordinators to suggest your edit.

Thank you Juha and Murch for answers/corrections.
There is no role for people who have a node on Transifex.
Furthermore, it was just a detail.


text:
Could you use RBF to take back stolen funds?
If you saw a transaction from a UTXO you control in the mempool that you didn't sign (i.e. it was stolen), could you use RBF to move it to an address you control before it was confirmed?

The attacker would have needed to access your private key to sign a valid transaction. If that happened and you observed the transaction in a mempool then you could broadcast a competing transaction with a higher fee rate. It would then be a race to see which transaction got mined and included in a block and the attacker's transaction would have had a headstart (it would have been propagated across the network for a longer period of time).
This isn't technically RBF, RBF generally refers to bumping the fee for a transaction spending to the same destination.

RBF is just replace-by-fee, i.e. the policy of preferring the higher-fee variant in case of conflicts. Its primary use case is feebumping, but can it be anything. There have been proposed other policies in the past like first-seen-safe-replace-by-fee (FSS-RBF) which would pretty much only be usable for feebumping.


text:
Looking for Source of an Old Idea About Subdividing Satoshis
I remember seeing an old idea but unfortunately I didn't bookmark it and now I'm struggling to find the source again. Maybe someone will remember it and be able to point me to the source?
It was something like:
Have a consensus (SF) rule that allows swapping 1-sat for a 0-sat UTXO which has the number of fractions recorded as something like <fracSats> OP_DROP appended to the Script, e.g. 1-sat would convert to a 0-sat with 100 OP_DROP for 1/100 subdivision. Then, rules would enforce that these fracs add up correctly within the scope of the TX.
From PoV of old nodes, it would be a bunch of 0-sat inputs creating a bunch of 0-sat outputs, valid by consensus but currently prohibited by relay rules.
When someone collects 100 fracSats on the input side, they'd get a 1 full sat back on the output side, I don't remember how this was supposed to work without violating consensus of old nodes, maybe the UTXO would still be 0 but miners would copy the UTXOs locking bytecode in coinbase TX and credit it with 1 sat.

That doesn’t sound economically viable. Why would you spend dozens to hundreds of sats to create an output worth a fraction of a sat?

Viable or not, I want to find the source of this idea.

I know this is not what you are looking for, but c-lightning implements mili-satoshi: https://bitcoin.stackexchange.com/questions/69700/what-is-a-millisatoshi-i-thought-satoshi-is-the-smallest-unit which is probably a more reasonable implementation of this even though I have heard it causes its own slew of issues.

Perhaps this thread: https://bitcointalk.org/index.php?topic=5330102.0

Nice find, the one I can't find was along the same lines, yeah! I think what I remember seeing was older and I think it tried to specify transitions from/to regular sats to/from subdivided sats.


text:
What wallet or service could this “address” be for?
Located an old crypto address on my old laptop prior to recycling - I have no idea what exchange if any - I have a number of passwords that may be associated with it, but have no idea where to start - any suggestions?  The address / account looks like this (made a few edits).  8fe2e2e3-7f26-46ab-b181-e6831 eee36c8

8fe2e2e3-7f26-46ab-b181-e6831 eee36c8

The only Hexadecimal numbers with hyphens that I recall seeing are the so-called Wallet-IDs provided by custodial services to account  holders.
An example would be
Simplecoin but I'm sure there are many more. I recall blockchain.com have used Wallet-IDs with a similar form.
I can't think of any real† wallets that use Wallet-IDs of that form.

See also

I have lost my wallet, what can I do?

† self custodial, not requiring you to trust any 3rd party service.

Thanks Yes is was a blockchain.com account - - - password worked and my treasure hunt ended with a zero balance in the account. I was hoping to share fee with someone who helped me figure this out but the dream is over!  thanks for the time and response - much appreciated. RP


text:
What is "buying hash rate" and how could it be profitable?
I'm sorry if this question may sounds like a newbie question (well, it is).
Introduction
I'm 23 years old and I would like to generate money with my money to eventually invest in stock market after some time. I was really interested in day trading, and I joined a discord server (Saphire) to gather some knowledge and experience from competent traders. After some time watching (I don't invest anything before I'm sure it's a good idea and before I know how to minimize risks), I discussed with someone who is a crypto trader. He talked to me about hash rate, and about how much it is profitable to buy hash rate (the platform used is xtradeclient). What I understood is the following: I don't have to buy gear such as graphic cards or similar to become part of the chain. I just put money in to contribute to things like fees, and then I get money back according to a fixed interest rate. The daily interest rate he told me about is 2%.
Question
After hours spent on the internet to know what "buying hash rate" is, I didn't find anything relevant. My first question is then what is hash rate, how to buy it, and what it means to buy it?
My second question is what interest rate can I expect from such an investment? And how risky is it? It seems like there is no risk, just getting back my money with interest. This sounds too beautiful to be so profitable.
Finally, are there any taxes I should be aware of about this? (I'm in Belgium.)

It's almost certainly a  complete scam. Stay away from people offering get rich quick schemes

Does this answer your question? How to tell if a cryptocurrency exchange or trading platform is trustworthy?

@RedGrittyBrick I don't think so. I'm not asking if a website or a trading platform is trustworthy, I'm asking about hash rate and "buying it". Furthermore, it looks not like a scam, because this person was not trying to make me invest into something.

Possible duplicate: https://bitcoin.stackexchange.com/a/41088/5406, https://bitcoin.stackexchange.com/q/52166/5406, https://bitcoin.stackexchange.com/q/95182/5406

@Murch You are probably right, it seems that by "buying hash rate" he meant "cloud mining". Thanks, and sorry for the duplicate !

'Buying hash rate' (cloud mining) is pretty much always a scam. A 'daily interest rate of 2%' is the obvious red flag in this case.

"Buying hash rate" is a synonym for a concept called cloud mining. In proof of work-based consensus systems, mining refers to a process of expending computational power to secure the network. As the integral computation is performing a cryptographic hash function, this is also referred to as hashing, and the amount of computation you can perform as your hashrate. To participate in mining, people acquire mining hardware, situate it in the vicinity of cheap power sources, and usually join mining pools to smooth out revenue. A large part of the global hashrate is contributed by specialized businesses that focus on exactly that.
Cloud mining promises to do all the heavy lifting for the miner: instead of acquiring hardware, setting it up, and sourcing power, you only provide investment capital but then get a steady stream of income.

The daily interest rate he told me about is 2%. […] This sounds too beautiful to be so profitable.

Your instinct is exactly right. If their business were that dead-sure, they would get an actual credit or investment at a much lower interest rate, take on the risk to build out a mining facility themselves, and make all that much more money.
So, why would they sell to retail investors instead? Great question. Because more often than not they're not actually running a mining business but a Ponzi scheme. And in the cases where they are legit, more often than not, it's still a terrible investment. Someone promising a 2% daily interest is definitely a huge red flag implying a Ponzi.

Thanks a lot for this great answer ! :)

Note that "vicinity of cheap power sources" must be evaluated based on marginal cost.  In areas using electric heating, the mining hardware produces heat with the same efficiency as a resistive purpose-built heater, so the marginal cost is only running a fan to move the heat, and the electric consumption of the computing system bears no cost since it is 1:1 replacement of electric consumption of purpose-built electric heaters.

@BenVoigt "the mining hardware produces heat with the same efficiency as a resistive purpose-built heater" but no where near as efficient as a heat pump.  Also, there's summer.

@JimmyJames: Right, that's why the caveat "locations using electric heating".  Some locations are only good mining sites during the winter, when they otherwise use electric heat (particularly good where heat pumps fail because the outdoor temperature is too low to effectively extract heat from).  But even where comparing to a heat pump, the marginal cost is still less than the total electricity cost.

@BenVoigt Maybe if you are mining at home.  My understanding is that most of the mining in question is happening in facilities that exist for primarily or solely for this purpose.  More likely they are exhausting the heat away from the equipment i.e. to the outside.

I hear that mining at home is especially popular among people that either do heat with electrical heaters in the winter (e.g. in Finland), or that produce some energy themselves that they alternatively could sell back to the grid at about 4¢ per kWh. It's more palatable now that that the life-cycle of ASICs is getting longer.

Although the particulars involve bitcoin, the central issue in this question is more of a Money SE question. You're being asked to invest in [industry], you just have to put up the capital, and [people] will buy [stuff] with your money which will create income because of [reason]. In this case, apparently industry=bitcoin mining, people=miners, stuff=mining rigs, reason=mining reward.
Two important concepts in investing are alpha and beta. Beta is a measure of risk. Higher beta will generally mean higher returns, as people will accept more risk if they're getting more of a reward. Alpha refers to when one is receiving returns above what the beta of your investment warrants.
Supposed alpha is a big red flag that something is a scam. There are cases where it's possible to get alpha, but it requires special skills or resources etc., and people don't just hand it out to anyone. If the person you're talking to has found a way to generate alpha, sharing it with you is just handing you free money. Why would they do that for someone they just met on a discord server?
2% daily interest compounded over a year is 1277%. That is, if you put in $1000 and let it compound over a year, you'll have $13,770. That's a massive rate of return. That's either a huge alpha, or a huge beta. Investment scams sometimes are beta fraud, where something is sold as being low risk, but in reality the person running the scam is putting your money in very risky investments, and then if the investment tanks they tell you that's just the risk of investment. Mostly, though, they'll just take your money and run.
If someone is offering 20% yearly interest, it's quite possibly beta fraud (the investment does legitimately generate 20% yield, but it's a very risky investment), but at 1277% it's almost certainly pure scam. If you invest your money, you'll probably get back statements showing your money steadily growing, and be pressured to put more in (after all, if you had more money invested, 2% of that would be a larger dollar amount), but if you ask to withdraw your money, there will be roadblock after roadblock until this person just disappears.
It's probably not even a Ponzi scheme; in a Ponzi scheme, early investors are allowed to withdraw their money to make the program look legitimate and entice more people to invest. But here, they're probably not planning on playing a long game. You're probably not able to bring in more investors, and 2%/day is a large interest rate to keep up for a significant amount of time; most Ponzi scheme run in around 20-40% (I think Madoff's was only 10%, but kept that up even in bear markets).

Thanks a lot ! This explanation about alpha and beta is really helpful to get a clear overview of the topic. I'll keep that in mind !

The only legit place which you describe is probably Nicehash.
This is a market place where you can directly buy hash power (hash-rate of somebody else). I'm a hobby miner and for some time i would resell my hashing power in exchange for bitcoin on Nicehash (Reason why somebody would do this is simply mining Bitcoin is only really profitable on ASICs which are a big expense up front and a lot of risk). You can look into that, but my understanding is that usually people buy hash power on Nicehash to strengthen a network and/or to get the coins they mine. The price is sometimes higher to buy the hashing power than you get in coin. So your profitability is not a fixed rate (in crypto no price or return on investment is fixed). And nobody will sell you their hash power if it is a lot below the value of direct mining.
I want to stress that what @Murch said is exactly right. If somebody needs to do this for you it's most likely a scam. There are a lot of scams in crypto be warned. Cloud mining is extremely risky because you trust somebody to run your money printing machine for you, often without being able to verify anything. Also beware crypto is an up and down, everybody who tells you otherwise is not to be trusted.

Thanks for your time writing this answer, this is very instructive! :)

sure thing please consider up voting answers you think are helpful, so people can see that it is worth reading ;-D

people buy hash power ... to strengthen a network - or if they're from the flip side, they can buy hash power to execute a 51% attack on a weak network


text:
Using an unmined Tx as a UTXO
Consider two transactions - Tx1, Tx2. Tx1 is an input of Tx2.
Say Tx1 did not get to any block yet. Can Tx2 get into the mempool of:

a node that holds Tx1 in its mempool
a node that does not hold Tx1 in its mempool. If so, will it ask for Tx1 from its neighbors?

I read some article which says Tx2 is a valid Tx and will get confirmed as a 0-conf Tx in some cases. I understand it might be different with different nodes (they can tweak the implementation) so I ask only for the bitcoin standard source code behavior.

Blocks can contain two interdependent transactions (one transaction spending an output created by another transaction in the same block).
Bitcoin Core will accept to its mempool transactions which spend outputs created by other transactions that are in the mempool already. These transactions may or may not be mined into the same block then.

Thanks!
If Tx1 has low/standard fee and Tx2 has very high fee, will the miners prioritize Tx1 also bexause of the high fee of Tx2?

@michaell_co They will, in fact. Bitcoin Core supports a mechanism called Child-Pays-For-Parent (CPFP), by doing ancestor aware prioritization in the block construction code.

@PieterWuille Hey I'm wondering what happens when taken to the extreme. I noticed that BTC Block times are sometimes over 1 hour. Let's say I do 20 txs in that hour before the Block is mined, where every next tx is based on the former. I would have a chain of 20 txs where only the first tx uses a confirmed UTXO. Does this have negative consequences? Might the miners reject it or something?

@CoderApprentice Bitcoin Core by default has a limit where transactions can have at most 24 ancestors and at most 24 descendants concurrently in its mempool.

@PieterWuille I see, that's great and more than enough :) Do you happen to know if the BTC node's policy to decide up until which tx in the chain of concurrent descendants is included in a Block, is based on a greedy algorithm? Like maybe txs 1-15 would give most profit so it would leave out txs 16-20. Or must it always look at the total average and include the entire chain? (aka maybe I should put the highest fees on my last tx in the chain)

@CoderApprentice The currently used mining algorithm in Bitcoin Core is the ancestor feerate based one. Roughly, for every transaction the average feerate of the tx together with all unconfirmed ancestors is computed. The one with the highest such average feerate is included. Then the process repeats with remaining transactions. This covers "child pays for parent" use cases, but not "children pay for parent", as only one child at a time is considered.

@PieterWuille I see that's really helpful to know, many thanks for this knowledge.

Let me add a few more details on how an unconfirmed transaction is relayed on the network and then you can answer your own question. Let's say there are three nodes. Alice, Bob, and Carol. Alice has Tx1 and just received Tx2, Bob has Tx1, Carol has neither. Both Bob and Carol are peer nodes to Alice.
When Alice learns about the new transaction Tx2, she announces Tx2 to Bob and Carol via the txid. Bob and Carol both don't have a transaction with the txid of Tx2 yet, so they request Tx2 from Alice.
Bob receives Tx2 and checks whether it would be valid to include in a block. As the node sees the input spending an output of Tx1, it finds Tx1 in its mempool. The input is unconfirmed but also part of a valid transaction, so Tx2 could be included in a block, as long as Tx1 is included in the block before it. Bob adds Tx2 to his mempool and announces Tx2 to his peers.
Carol receives Tx2 and checks whether the transaction would be valid to include in a block. As the node sees the input spending an output of Tx1, it realizes that it does not know about Tx1, e.g. because Carol was not online when Tx1 was originally broadcast to the network. Since Carol cannot confirm that Tx2 is ready for inclusion in a block until all inputs are known, Carol puts Tx2 in its "orphan transaction" list. As nodes only forward transactions they consider valid, the node that forwarded Tx2 to Carol should know all the inputs for Tx2. Hence, Carol follows up by requesting Tx1 from Alice. Alice serves Tx1 to Carol. Carol validates Tx1, adds it to her mempool. Now that the inputs are known, she determines Tx2 also to be valid and adds that to the mempool as well. Carol then announces both Tx1 and Tx2 to her peers.
Also, a note on terminology: we consider a transaction confirmed when it is included in a block. However, we consider an transaction valid if it could be included in a block. There can be multiple conflicting (spending the same inputs) valid transactions, but only one of them can be confirmed in the best chain. A node will only hold one out of a conflicting set of transactions in their mempool at a time. Usually that's the first they saw, unless a later transaction fulfills the requirements to replace its predecessor.
Accepting a zero-conf transaction, refers to the practice of a receiver deciding to rely on a (valid) transaction before it is confirmed. Since transactions can be replaced before they're confirmed (and in some circumstances even after they are confirmed), this practice is not recommended. There are however some businesses that have the necessary telemetry and risk mitigation in place to make it work for them.


text:
Addresses to do with illegal transactions
I have been searching for sources to obtain illegal addresses used in high profile incidents such as the Mt. Gox hack, Stone Man Hack etc. It would be helpful if someone has this on hand.

https://bitcointalk.org/index.php?topic=576337
I found this gem of a post for future reference


text:
Lightning channel decrease capacity
Let's say Alice and Bob have a 2BTC channel together. Both have a balance of 1BTC. Can Alice withdraw part of her balance (say, 0.5BTC) from the channel?

I've edited your question to, in my view, make it clearer more to the point. I'm not entirely sure it was what you intended so of course feel free to roll back.

As mentioned by Antoine, Alice and Bob could make a transaction to close the channel, Alice could use her payout to make the payment, and then Alice could use the change of that payment reopen the channel with a lower capacity. Note that unless they collaborate to use both Alice's and Bob's inputs, the new channel would also lack the Bob's prior balance. The same could also be achieved more efficiently by splicing out the payment. Alice and Bob would then collaborate to spend the funding output to create a transaction with two outputs where one is the payment Alice wants to make, and the other output is a new channel's funding output. This would save a transaction reducing the overall blockspace footprint and channel-downtime as well as result in a new channel with higher balance.
Another option would be for Alice to pay someone else on the Lightning Network to execute an onchain transaction for her. If e.g. Carol who has a channel with Bob were to offer this service, and Alice would send a ₿0.5 payment through Bob to Carol (plus maybe a fee), who would then make the expected onchain payment. By creative use of HTLCs, this payment could even be linked with the payment on LN so that the whole chain executes atomically. Instead of reducing the channel capacity, this would shift some of Bob's Lightning balance from his channel with Carol to his channel with Alice (and reduce Alice's balance, while increasing Carol's). This layer-traversing payment type is referred to as a "submarine swap".

Yeah but by using splicing, we cannot create a new channel with greater channel capacity than the parent channel, right?

With splice outs you can make a payment from the channel and immediately create a new smaller channel. With a splice in, you can add another input and create a bigger channel. If the input is unilaterally controlled, you need to wait for confirmations again, though.

I didn't get properly this term "If the input is unilaterally controlled, you need to wait for confirmations again". What does this mean? Like how an input is unilaterally controlled

If one of the two channel partners is contributing the funds by themselves, they would be able to create a conflicting transaction that could cancel the channel open. One way around that would be to put the funds into a 2-of-2 with the channel partner first and wait for confirmations while the channel is still operating, so that when the additional funds are spliced in, both parties know that the source of additional funds cannot be spent in another transaction by the other one alone.

So, here for
1.)getting confirmations for 2-of-2 channel is 1 transaction
2.) settlement of balance, closing the parent channel  and opening new channel is other transaction,
Which is 2 transactions required for splice-in, but how is this efficient when compared to First settling and closing channel ->1 transaction and then
2.) opening new channel -> 1 transaction
This method also takes 2 transaction
How is splice-in method efficient when compared to normal closing and opening channel?

The closing transaction can create the new channel immediately instead of paying out the owners. The staging is optional if you do not want to interrupt channel operation at all, otherwise it can all be done in one tx.

If you mean decreasing the capacity of the channel to 1.5BTC in order to withdraw 0.5BTC onchain, it is possible in theory but not yet part of the Lightning Network protocol nor its implementations. That's called splice-out.
Of course, you can always do that today by closing the 2BTC channel and re-opening a 1.5BTC one.


text:
How are transaction fees split in the network?

How are transaction fees split in the network, do all the transaction fees go directly to the miner or is there any kind of percentage of fee allocation to peers/validators for relaying transactions and validating?

If yes, how and on what basis does they share the transaction fees among themselves?

All transaction fees go to the miner that published the block in which the transaction got confirmed. If the miner is a mining pool, they tend to have some distribution mechanism to pay out to the pool contributors.
Full nodes do not get paid. Users run full nodes because they want to have their own trusted source on the state of the network.


text:
How did SegWit start
My understanding of SegWit is that any non-segwit (legacy) nodes will see a SegWit output as an output anyone can spend (i.e. no signature required). This is currently fine since if the miner mines a block with a transaction that tries (illegally) to spend from that output, it will be rejected by the majority of the nodes because most nodes support segwit and see that there is no witness proof as part of the transaction. But my question is how could a segwit output possibly be used in the beginning when segwit was just launched and the majority of the network where non-segwit? Then anyone could just spend the segwit outputs?
Thanks!

Segwit was activated using bip9. The precondition for segwit's activation was that 95% of the hashrate was signaling readiness to enforce segwit's rules. Also, a majority of the other nodes had upgraded at that point. Quickly after activation, almost 100% of the hashrate was running a segwit-compatible version.

Thank you so much! Are there any good reasons for why anyone would want to run a legacy miner these days? I assume they are open for attacks where someone can send them invalid transactions (with a high fee to make sure they are accepted to the block) and any block mined would immediately be rejected?

I'm not aware of any reason to run a legacy miner except for ideological opposition to segwit. I do know multiple reasons against it: a legacy miner would not include any segwit transactions, since they look non-standard to a legacy miner. As today 5/6 of all transactions use segwit, they would earn less transaction fees (but fees are still only a tiny part of the block reward). Also the last non-segwit version of Bitcoin Core is severely outdated, it has been end-of-life (beyond maintenance patches) for more than four years at this point.


text:
How would you send more than a channel's capacity?
Let's say Alice wants to send Bob 1BTC. So, let's say Alice funded a channel with Bob of 1BTC+some minuscule amount of BTC for fees and let's say Alice transferred the whole channel capacity to Bob.
The next day Alice wants to send another 1BTC to Bob. Since, the channel capacity is 1BTC, if Alice wants to send another 1BTC, how would she send that 1BTC to Bob? Does she close that channel and open a new channel with Bob? Or is there any way to send BTC to Bob through that same channel?

You can only send as much funds through a channel as belong to you in the channel. So, no Alice cannot send the full capacity of the channel to Bob twice, unless the whole capacity had been sent back meanwhile.
If you're sending only in one direction and anticipate making multiple payments, you should open a channel that is a multiple of the sent amount in the first place. If payments flow only in one direction, it may even be more efficient to just send on-chain, especially if you're sending large amounts like 1 ₿ every day.
Alternatively, there may in the future be a way to increase the capacity of a channel by "splicing-in" funds, but that's basically just a more efficient way of opening a new channel with a bigger capacity.


text:
How does Bitcoin prevent double-spending without penalizing miners?
In the network nodes below as shown in picture:

Let's say A is trying to double spend by sending bitcoins to B,C (A->B) and (A->C) and let's say A tried to relay (A->B) transaction to honest Node - 8 and at this point let's assume that current time is 6'o clock(might be any time zone). So at 6:00 A relayed its transaction (A->B) to honest Node-8. let's say at 6:02 (exactly after 2 mins) A tries to double spend that bitcoin and sends that bitcoin (A->C) to honest Node - 5 and at 6:04 let's say honest Node-5 validates all transaction to be valid since A's Input UTXOs are not broadcasted to network until now.
At the same time let Node-8 also validates all transaction in its block to be valid, since A's Input UTXOs still exist. let's say at 6:05 Node-5 and Node-8 are trying to solve hash puzzle to mine a their block and at 6:08 lets say Node-5 solved the puzzle and broadcasted it's block to network. While Node-8 is trying to solve the puzzle with the transactions it has**(A->B)**. Let's say at 6:14 Node-8 solved the puzzle and tried to broadcast its block which contains (A->B which is double spending). Then the peer-nodes will reject the block that Node-8 has broadcasted because it has an invalid transaction(Double spent transaction).
- Here the fault is not Node-8, Node-8 is honest doing its work by following protocol. Even though peer-nodes in this case has rejected honest Node-8's Block and Node-8 has lost a lot of computation power, which is very unfair?
- How Bitcoin protocol solves/help this issue for Node-8?
Correct me if I am wrong...

If two blocks has the same ancestor, we say we have a fork. If a node sees a fork, it assumes the first block it saw as the best one, but keeps the other. As the time goes on, eventually someone will solve the PoW for the next block, and this block will likely extend one of the two chains (i.e. this block will be right after one of the fork's one). The chain with more work'll always win, so whichever chain gets extended becomes the active one.
If Node-8's block gets extended, then the network'll adopt it as the current best chain, even if they see Node-5's block first. Since Node-8's block got through, A will be sent to B, and the other transaction will be invalidated.
That's why some people wait some confirmations until get a payment as final because there's no risk of reorg (reorg means change the current tip, replacing some blocks we considered part of the best chain, and replacing by others).

I'm going to offer a frame challenge. Your scenario makes no sense to me, because you seem to have a wrong perception of how the blockchain works and is propagated on the network.
First problem: at 6:02 Node-5 has already heard about transaction A->B. Transactions are only propagated at best effort but transactions that are candidates for the next block should get to most nodes within 30 seconds. No biggie: we can fix that by making the attacker send at 6:00 in parallel A->B to Node-8 and A->C to Node-5. So Node-5 and Node-8 do have different views on the unconfirmed transactions now and each considers their payment valid. If they see the other transaction, they will reject it because it's in conflict with the one they have already.
Now at 6:08 Node-8 finds a new block which includes A->C. Block propagation has the highest priority and the propagation of blocks is guaranteed. Some nodes might not hear about an unconfirmed transaction, but every node hears about a new block within seconds. If the block is valid and the new best chain-tip, everyone extends their blockchain with that new block. At this point Node-8 realizes that A->C has spent the funds and the transaction A->B is now invalid. Node-8 drops A->B from their mempool. Every miner, including Node-8, switches to trying to find a new block that follows the block that was published by Node-5. The doublespend has been resolved, because only one of the transactions has survived.
Nodes validate transactions before they add them to their mempool. At that point they can only assess whether a transaction would be eligible to be included in a block, and they only keep the first (or best) conflicting transaction they see. Once a block is published the content of the block always supersedes the content of their mempool. Blocks are the shared ground truth of the network and the blockchain has only one block at every height. When the chaintip progresses, everyone starts working on the new height.
If Node-5 and Node-8 had found their blocks at the same time (within a couple seconds of each other), they would have each broadcast theirs to their peers. Every node would stick to whatever block they had seen first until another block were found. Then everyone would converge on the new best chaintip and the other block would become an extinct chaintip, not part of the best chain.

Thanks a lot for your support, it helped me a lot and The time reference that is taken in question is just for representing the sequence of events but not to represent the exact time range that it would take. Thanks a lot again for info :)

I've extended my answer to cover the case that the competing blocks were found at the same time.

... Node-8 has lost a lot of computation power, which is very unfair?

The Bitcoin network protocols do not protect or reimburse a miner for work they honestly carry out mining a valid transaction passed to them by a secretly malicious person attempting a double spend.


text:
Can someone with majority hashing power decide what transactions are included in my block?
I read this paragraph about if a mining pool controls the majority of the hashrate on the network:

Blocking Transactions:
Anyone who controls the majority of the hashing power can decide which
transactions to include in the next block. Due to that, an attacker
can even decide to build a completely empty block, with no
transactions.

Q.) If I somehow were able to mine a block, how could someone with majority hashing power decide which transactions are included in my block?

Does this answer your question? What can an attacker with 51% of hash power do?

If I somehow was able to mine a block, How can someone with majority hashing power can decide transactions to include in my block

Nobody else can influence the contents of the block you are working on.
However, someone with a majority of the mining power will be able to ignore your block, and just work on their own chain instead. Since they have the majority of the hash power, their chain will on average be extended more quickly than the rest of the miners combined, and thus by ignoring your (and all other miners') blocks they will be able to arbitrarily censor transactions. So, it won't matter what transactions you decide to include in your block, since you block will eventually not be a part of the longest (i.e. most work) chain.


text:
Does the transaction fee depend on the transferred amount?

Do transaction fees depend on the amount of bitcoin sent?
On what factors do fees depends?

No.
Fees depend on the size of the transaction (measured in bytes), and can start at 1 satoshi per byte. So. if your transaction weighs 400 bytes, at 1 sat / byte you’ll pay 400 sats.
The size of the transaction depends on its type (P2PK, P2PKH, P2SH, …) and the number of inputs and outputs in it.
Bitcoin transactions can have one or more inputs, and one or more outputs. This will be the major factor determining the size of your transaction.

The transaction weight is not measured in bytes, but in weight units since the activation of segwit. Weight is defined as the total byte length of the serialized transaction + 3× the byte length of the transaction without witness data. See e.g. https://bitcoin.stackexchange.com/a/89418/5406

A Bitcoin transaction is a combination of one or more inputs and one or more outputs. Each input is itself an out put of a previous transaction. So it is not liquid. I think it is good to think of them as paper banks. If you buy something that costs 27 dollar, you probably don't have a 27-dollar bill. you have some other coins and banknotes which sum of them is equal or more than 27. So you may pay 2 20-dollar and one 10-dollar bill and get 3 dollar as change. In this transaction beside amount of the deal, at least 4 banknotes were involved. So this is the factor to calculate the fee.
It's completely possible to have a very small transaction which has high fee, because it is made up of very tiny inputs or it has many outputs. On the other hand, if you try to move only one input to another output (without any change) it would be very cheap beside the amount of the input.

The cost of transactions is independent of the amount transferred. Rather it depends on the weight of the transaction, the current blockspace demand, and the urgency the sender wants to see it confirmed.
A transaction's weight is calculated from the byte count of its serialization. Non-witness data counts at a factor of 4, witness data counts at a factor of 1. Each transaction must have at least one input and one output, transactions with more inputs and outputs will weigh more. (See e.g. this overview of the weights of different output types.)
Transactions compete for the block weight they occupy in a block. Rational miners will prefer transactions with the highest feerate (fee per block weight) to maximize their mining revenue. A transaction's fee can thus be interpreted as a bid for a specific amount of block weight. If there are a lot of transactions waiting for confirmation, a sender might need to offer a higher feerate to see their transaction confirmed quickly.
Nodes generally do not relay transactions that pay feerates lower than 250 sat/kwu (or 1 s/vB), and miners usually do not include transactions in their blocks that pay less than this "minimum feerate".


text:
Is the G in Elliptic Curve same for Bitcoin and Ethereum?
Is the G of the elliptic curve the same for Bitcoin and Ethereum? If yes, then why can't we send bitcoin and ether to same public address? If no, then what's the reason behind implementing it like that? If they use the same method, then one can send both coins to same public address, right?

Is the G in elliptical curve same for bitcoin and ethereum?

Yes Ethereum also uses the secp256k1 curve that is defined using the generator point:
Gx = 0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798
Gy = 0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8

If yes then why can't we send bitcoin and ethereum to same public address?

For a number of reasons. Firstly, Bitcoin and Ethereum define addresses differently. Bitcoin uses the bech32 format starting bc1 and Ethereum uses a hexadecimal string starting 0x. Secondly, Bitcoin addresses contain a checksum at the end of the address (to flag incorrectly typed addresses) whilst Ethereum addresses don't. Thirdly, Ethereum only encodes the last 20 bytes of the public key into the address. Fourthly it is not just a raw public key that is encoded in a Bitcoin address. Bitcoin uses a scripting language "Script" that it uses to outline the conditions needed for the coins to move which generally includes requiring at least one signature associated with a particular public key. These conditions are baked into the address.
So yes don't try sending Bitcoin and Ethereum to the same address, you will lose your coins.

The most important reason is that they are simply separate unconnected systems. Even if they used the same addresses, and the same scripting system, separate systems can't interact. They're just different currencies, protected by similar cryptography.

The way I understood the question was he wanted to send Bitcoin and Ether to the same address so the Bitcoin system told him his Bitcoin "balance" on that address and the Ethereum system told him is Ether "balance" on that address. That is theoretically possible (assuming addresses were defined exactly the same on both systems) if the Bitcoin system wasn't aware of the Ethereum system and vice versa?

Ah, that's fair. I had interpreted the question as "why can't I send my BTC to my ETH wallet, or vice verse, if they use the same cryptography?", but your interpretation may make more sense. We'll need to wait for OP.

Another reason why BTC/ETH transactions can't be intermingled: Bitcoin has a UTXO-based system, but Ethereum doesn't use UTXOs at all and just hardcodes the address balance into the blockchain.

@Zenul_Abidin The difference in accounting models does introduce interoperability challenges but is not specifically related to the Elliptic Curve Generator point relevant to this question.

According to the other answer they do share the same G, however there is a slight difference between the term address and the term public key. An address generally is derived from a public key. The public key is a pair of coordinates that we get from multiplying with the curve Generator. Because that is the case, technically it may be possible for you to use the same public key on both Bitcoin and Ethereum, but this does not imply you can use the same address. That is because an address takes a public key runs it through somewhat of a one-way function. This one-way function is fundamentally different on Bitcoin and Ethereum, because neither network should have to build software to support all the upgrades for the opposing network.
Since they are completely different networks and scripting systems,
simply sending Bitcoin to an ETH address will not succeed. Furthermore since interoperability between the two systems is also not a fundamental focus, there is little effort to create a wallet that would represent a valid address for both chains derived from the same public key, even though it might technically be possible.


text:
What data structure is used to store the bitcoin transactions in the blockchain?
In what data structure are bitcoin transactions stored in the blockchain? That vout and vin thing shown on blockexplorers is in json format. So, in the code, what data structure is used since in the bitcoin node application the details are not serialised?

Does this answer your question? How is data in a blockchain stored? Structure of block and blockchain or What are the components of a raw block

Could you clarify whether you mean how it is stored on disk or how it is stored when loaded in memory?

As the name says, it is a chain of blocks.
These blocks are usually stored in blkNNNNN.dat files, with each block prefixed with a magic value and a byte size.
Each block starts with an 80 byte header, containing:

version
hash of the previous block
the merkle root
the timestamp
the block difficulty
a nonce
The blockhash is the hash of that 80 byte header.
The 'hash of previous block'  is what makes this a chain of blocks.

The block header is followed by a count,
followed by that many transactions.
There are two types of transactions:

legacy
segwit

Legacy transactions are formatted like this:

a version
a count of the number of inputs
the input transactions
a count of the number of outputs
the output transactions
a locktime.
for legacy transactions, the transaction hash is just the hash of the entire transaction.

a segwit transaction:

a version
a byte 0x00
a byte: witnessflags
a count of the number of inputs
the input transactions
a count of the number of outputs
the output transactions
for each input, a witness
a locktime.
for segwit transactions, the hash is excluding the witnessflag and 0 byte, and witness list.

An input is formatted like this:

hash of the source transaction
the index of the output in the source transaction
the input script ( aka ScriptSig )
a sequence number

An output is formatted like this:

a bitcoin value
the output script

A witness is formatted like this:

a count
a number of values

Some values are 32 bit little endian integers:

the sequence number
the versions
the output index
the locktime
the timestamp, nonce and difficulty

The bitcoin value is stored as a 64 bit little endian integer.
The counts are stored as a special compressed 'varint'.
Scripts and witness values are stored as: count + bytes.
hashes are stored as 32 bytes:

the previous block hash
the merkle root
the source transaction hash

In the Bitcoin blockchain, transactions are stored in a data structure called a Merkle tree, also known as a hash tree. In a Merkle tree, transactions are grouped together into "blocks" and each block is connected to the previous block in the chain, creating a series of blocks that form the blockchain.
The "vout" and "vin" fields that you see on a blockexplorer represent the inputs and outputs of a transaction in the blockchain. These fields are typically encoded in a format called JSON (JavaScript Object Notation) for easy reading and parsing by software applications.
In the Bitcoin node software, the transactions are not typically serialized (converted into a series of bytes) because they are stored and processed in the data structures of the Merkle tree. The specific data structures used will depend on the implementation of the Bitcoin node software, but they are typically some combination of arrays, lists, and hash tables.

In the bitcoin-core you can see here. There is a class called CTransaction which has 2 important public members called vin and vout.
/** The basic transaction that is broadcasted on the network and contained in
 * blocks.  A transaction can contain multiple inputs and outputs.
 */
class CTransaction
{
public:
    // Default transaction version.
    static const int32_t CURRENT_VERSION=2;

    // The local variables are made const to prevent unintended modification
    // without updating the cached hash value. However, CTransaction is not
    // actually immutable; deserialization and assignment are implemented,
    // and bypass the constness. This is safe, as they update the entire
    // structure, including the hash.
    const std::vector<CTxIn> vin;
    const std::vector<CTxOut> vout;

As you can see their data type is std::vector of CTxin and CTxout. You can find their declaration respectively here and here.

that is how things are stored inside the bitcoin-core program.  that is not the same as 'how they are stored in the blockchain'


text:
How do I generate master key from the root seed
I created a mnemonics and it is hashed using pbdkf2 function to get a root seed. So this root seed should be hashed again with HMAC-SHA512 to get the master key (Master private key and chain code). So for a HMAC-SAH512 we need a key and data, so in this case what should be the key? Data should be the root seed and what should I give as key in hmac function.
I gave "Bitcoin Seed" as key and generated a hash, but it is not matching the output showed on Ian Coleman's bip39 website.

The BIP32 Root Key described on iancoleman tool is called master node, serialized in base58.

The HMAC function needs a key (the string "Bitcoin seed" encoded in bytes), a data (the seed) and the hash function (sha512).
In python, it looks like:
master_node = hmac.new(b'Bitcoin seed', bytes.fromhex(mseed), digestmod="sha512").digest()

Serializing...

version = '0488ade4'
depth = '00'
fingerprint = '00000000'
index = '00000000'
private = first 32 bytes of master node
chaincode = last 32 bytes of master node

Sum, checksum, encode everything and you'll get there.
Follow the steps of chapter 5 -> https://learnmeabitcoin.com/technical/extended-keys


text:
What does TLV stand for?
I'm reading about the gossip protocol and wanted to know what a TLV is. I can't find what it means anywhere.

TLV stands for type-length-value. It's an encoding scheme used when protocols allow for optional elements in their messages.
The type is a label telling you what field you're looking at, the length tells you how long the field is, and the value provides the actual field data.


text:
Do non-Segwit nodes reject Segwit transactions with invalid signature?
As far as I can tell, non-Segwit nodes receive anyone-can-spend transactions, and thus come with no signature to validate. If a miner included a Segwit transaction to a block with invalid signature, it'd be rejected by Segwit nodes, but not by non-Segwit nodes.
Would the latter consider the transaction valid? If yes, wouldn't this result in a chain split?

If a miner included a Segwit transaction to a block with invalid signature, it'd be rejected by Segwit nodes, but not by non-Segwit nodes.

Indeed. It would have to reach the miner so either sent to them directly or propagated to the miner by non-SegWit nodes. SegWit nodes would reject it and not propagate it.

Would the latter consider the transaction valid? If yes, wouldn't this result in a chain split?

Full nodes enforcing SegWit rules would reject a block with an invalid SegWit transaction in it as would miners enforcing SegWit rules. What would happen in your scenario is the miner would think they've successfully mined a block but full nodes enforcing SegWit rules would reject it and miners enforcing SegWit rules would refuse to mine blocks on top of it. So it can cause temporary confusion amongst full nodes not enforcing SegWit rules but the longest chain with most proof of work would end up not including that block and that is the chain that even the full nodes not enforcing SegWit rules would end up following.
Definitions aren't always clear (e.g. re-org, chain split) but there wouldn't be a lasting chain split unless a subset of miners refused to reject this block that didn't meet SegWit rules and continued to mine in perpetuity blocks on top of it. This would be a very costly endeavor as they would effectively be mining an altcoin and not what is considered Bitcoin.

Right. Isn't that's why they say a soft fork is when previously valid rules are made invalid?

@Angelo: A soft fork is the addition of consensus rules rather than the relaxation of consensus rules (hard fork). With a soft fork unupgraded nodes continue to follow the longest chain with most proof of work. With a hard fork unupgraded nodes reject the relaxation of the rules and are forked off the network when they encounter a "valid" relaxation of the rules

As far as I can tell, non-Segwit nodes receive anyone-can-spend transactions, and thus come with no signature to validate. If a miner included a Segwit transaction to a block with invalid signature, it'd be rejected by Segwit nodes, but not by non-Segwit nodes.

That's all correct.

Would the latter consider the transaction valid?

Yes. Non-segwit nodes will accept transactions with invalid segwit signatures.

If yes, wouldn't this result in a chain split?

Temporary chain (1-2 blocks deep) splits happen all the time; it's what we have a blockchain and proof-of-work for to resolve. Having a sigificant hashrate (say, single-digit percentages) construct blocks that contain segwit-invalid transactions may result in slight increase in such temporary forks. Only pre-segwit nodes would notice these forks however, as post-segwit nodes will ignore the segwit-invalid blocks entirely.
The real concern would however be permanent splits. These can only occur if a majority hashrate is accepting these segwit-invalid blocks, because only those will build on top of it. As long as only a minority accepts such blocks, the majority will keep building on segwit-valid blocks, and thus such chains will in the end always overtake the segwit-invalid ones. Thus, even pre-segwit nodes will in the end only accept the segwit-valid chains. Post-segwit nodes again won't see or care about the segwit-invalid chains.
Note that constructing a block with segwit-invalid transactions (even by pre-segwit miners) requires deliberate effort from that miner. While segwit transactions (valid and invalid) are valid to pre-segwit nodes, they are non-standard, which means that such transactions won't make it to pre-segwit nodes' mempools and not be selected for inclusion in blocks. It's just that if they were to see such a transaction in a block, they'd consider it valid.
Lastly, all of the above applies to every softfork in modern history. Segwit was one example, but by now it's been so long ago (Aug 2017) that almost all deployed nodes (miners and others alike) enforce segwit's consensus rules, so the question has become moot. A more recent example is taproot (which activated in Nov 2021). Before that there were other examples like CLTV and CSV.

So is it fair to say that generally speaking, any soft fork will only remain a soft fork if the majority hash rate focuses on the new-rule-compliant chain, and that otherwise there would technically end up a divergence in node consensus?