text:
BOLT #3: Shouldn't timeout be included in the script of "Offered HTLC Outputs" for the local node?
According to the BOLT #3 documentation, the offered HTLC output has the following script that allows the remote node to claim the funds with the payment pre-image and the local node to claim it after a HTLC timeout.
1.  # To remote node with revocation key
2.  OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
3.  OP_IF
4.      OP_CHECKSIG
5.  OP_ELSE
6.      <remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
7.      OP_NOTIF
8.          # To local node via HTLC-timeout transaction (timelocked).
9.          OP_DROP 2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
10.      OP_ELSE
11.         # To remote node with preimage.
12.         OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
13.         OP_CHECKSIG
14.      OP_ENDIF
15. OP_ENDIF

If you see the output that sends the funds to the local node (line 7-9), it is not timelocked in the script. A local node after signing the commitment transaction, which includes the HTLC he offered, can broadcast the commitment transaction that claims the money from the HTLC-timeout (he already has the signatures) and pays to an address with to_self_delay.
Although the delay exists in the 2nd stage (CSV locked with to_self_delay), nothing stops me from offering a htlc to my peer node, sign the updated commitment transaction and a second later broadcast the commitment transaction on mainchain and spend the HTLC to an address locked with CSV. The remote node will still forward the htlc because from its viewpoint it is still within the bounds of the cltv_expiry as specified by BOLTs. Now, when the remote node gets the pre-image it doesn't have any transaction to settle with. Where is the shortcoming in my though process and isn't timelock expiry something that should be included in the script itself?

Pierre answered my question on the lightning-dev list and there is a pull request in order to make it more explicit. So the answer is that although the timeout is not addressed in the script, it is enforced in the HTLC-timeout transaction with an absolute timelock in the nLocktime. When the local node tries to spend the HTLC output, it has to explicitly set the nLocktime to cltv_expiry which prevents it from broadcasting the second-stage HTLC-timeout transaction until that time has reached.


text:
Why is the value field 8 bytes in transaction output when it can be achieved with 7 bytes?
Bitcoin uses a 8 bytes value field in the transaction output. However, the total supply of bitcoin is capped at 21M. Theoretically, even if all the 21M bitcoins are transferred to a single address, the output, after converting to satoshis, can be effectively represented with 7 bytes of data. This means, we are adding at least 2 bytes of redundant data (one for the spend address and other for change address) for every transaction stored in the blockchain. Is there a particular reason why a size of 8 bytes was chosen or was this a design flaw that was overlooked by Satoshi? Is it possible to bring a change to this via a soft-fork or does changing this require a hard-fork?

Is there a particular reason why a size of 8 bytes was chosen

Probably not.
In the original Bitcoin source code, many of the primitives used in data structures were simply the in-memory representations of those primitives. For integers, this is a 32 bit (4 byte) little endian integer. However 32 bits is not enough to represent all of the satoshis that exist in Bitcoin. The next primitive that can be used is a long, aka a 64 bit integer. Since this was just serialized as it is represented in memory, the amounts end up being 64 bit little endian values.

Is it possible to bring a change to this via a soft-fork or does changing this require a hard-fork?

The serialiation format used for computing the weight and hashes can only be changed via a hard fork.
However you can transmit a transaction using whatever serialization you want so long as that format contains all of the necessary information to construct the serialization necessary for computing weight and hash. This would not require any fork because it is not a consensus change.

Yes, transaction format has unused bytes. One other example is encoding utxo index in four bytes. Nobody cares. We can not change the format without hard-fork. And we do not want to do it. Live with it.

I disagree on UTXO. 1MB block limit was sneaked in later by Satoshi in July 2010. So before that you could have had number of outputs. So the number of outputs that could have been possible would be capped by the 4 bytes of vout index.

I disagree that we don't care, or can't change it without a hard fork. It's trivial to design more efficient ways to store and communicate transactions and blocks; only the data fed to hash functions for txids and other commitments needs to remain consistent without forking.

@PieterWuille If you change the output value size to 7 bytes, won't the nodes that are running an older version of Bitcoin Core consider those transactions as invalid, resulting in a fork?

@UgamKamat You'd just negotiate a newer protocol version in which the 8th byte is gone. This protocol would only be used between two peers which support it. It's important to realize that while transactions and blocks are often thought of a bytes, they're really just abstract structures, and you can encode them anyway you like - as long as all participants in the communication can still compute the correct hashes (which are defined in terms of one particular serialization).

@PieterWuille That was a good explanation as to how we can reduce it to 7 bytes. Is reducing redundant sizes on the roster in future releases? We can reduce a good percentage of the blockchain size going forward.

@UgamKamat There are many more redundancies in the protocol (sizes, DER encoding for sigs, predictable locktimes and sequence numbers, standard script templates, redundant scripts in P2SH-wrapper segwit spends, ...), which could be avoided using a specialized compression scheme. I have done some work on this, but it's not very high priority. Also, it's mostly a bandwidth savings; if the blockchain size is an issue, just run a pruning node.

source: Stack Exchange

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

sort: votes


text:
Can I send/receive payments but prevent forwarding payments in Lightning Network?
Say I am using a very computationally constrained device (eg. a sensor) and it uses Lightning Network to send/receive payments. However, being computationally constrained it doesn't want to forward incoming payments that are actually meant for other nodes. The reasons could be that forwarding a payment will require it to forward the htlc, fulfill it as well as compute the onion for routing to the next node which might be computationally draining. However, sending an error would be just one operation after parsing the onion.
Every time the sensor node parses the onion and sees that the payment is not meant for it, it will send a temporary_node_failure or temporary_channel_failure error message. In situations where the lightning software uses some data analysis tools like autopilot, other nodes might completely eschew this sensor node out from forwarding the payments due to its high failure rate.
Is this something that can be implemented with a slight tweak to the current lightning implementations (like LND or c-lightning)? If the failure rate is too high, is there something like a banscore that is being kept by other nodes that might prevent this sensor node from receiving/sending payments in the future?

Is this not the use case for private channels. (Channels with announce set to 0 in the open_channel message)? If you are not routing payments, there is no need for your channels to be public.

@MarkH Check my comment on Christian's answer.

Yes, there are basically two ways to avoid becoming a forwarding node:

Do not announce your channels, and keep them private
Reject any incoming HTLC that is not destined for you

The first is supported by the protocol itself, and is a proactive measure against forwarding any payment that is not destined for you, while the latter is a reactive measure and would allow you to decide on a per-HTLC basis whether you want to forward it or now.
The protocol allows channels to remain private and not be announced in the wider network:

Only the least-significant bit of channel_flags is currently defined: announce_channel. This indicates whether the initiator of the funding flow wishes to advertise this channel publicly to the network, as detailed within BOLT #7.

This means that the channel is not going to be included in the gossip, and nodes won't learn about the channel's existence. In order then to receive payments, which requires the sender to compute a route to you through that unannounced channel, you selectively tell the sender about the channel in the invoice using route hints, i.e., the r field in the invoice.
The second method mentioned above involves instrumenting the node such that it accepts HTLCs, but immediately rejects any HTLCs for which you are not the destination. This is has several downsides, among which the fact that you are announcing channels that are fundamentally not operational for forwarding, and you still have to process all HTLCs since you can't filter them out ahead of time. This corresponds to the scenarion that Rene Pickhardt mentioned. The computational overhead consists of:

More messages to process, including the wire encryption/decryption, potentially waking your CPU up if you run on a low-powered device
Decrypting the onion, which is a really expensive operation since it decrypts/encrypts 2600 bytes of data by generating a pseudorandom stream. In addition the onion gets prepared for an eventual next hop.
Need to process the HTLC itself (DB lookups, ...)

Both methods are implemented in some implementations: the mobile version of eclair does not announce its channels by default, lnd is planning to implement a bias against (though not a complete exclusion) channels and nodes that have proven to be unreliable and c-lightning allows you to implement any forwarding policy you'd like as a plugin using the htlc_accepted hook. Furthermore it is trivial to modify lnd and c-lightning to make the announcement of channels configurable.
(Disclaimer: I am one of the spec authors and work on c-lightning)

But if I operate a private channel, i would not be able to send/receive payments to/from the rest of the world. Consider my sensor to be one that wants to use the benefits of lightning to receive payments from anyone, but does not want to spend any extra computational effort if that onion is not meant for it (you know what we would call that sensor if it was a person). Is my understanding correct that private channels would not work in this case? Also as you mentioned, if generic softwares will now not use my node, I just need to reject a few payments and the software will do the for me.

@Ugam. Private channels can still interact with the larger network. Sending payments is done as normal, by sending an update_add_htlc to your local peer using the local channel_id which is known only to you and your peer. Receiving is done by adding the short_channel_id, cltv_expiry_delta and your local peer's node_id inside the r field of the invoice - this allows a sender to reach you without knowing anything about your node, as long as they can discover your peer over the gossip network.

The TL;DR answer is: Yes it is totally possible, but as far as I know not implemented in any lightning node software at this time.
However I wish to elaborate a little bit. In your question you wrote:

The reasons could be that forwarding a payment will require it to forward the htlc, fulfill it as well as compute the onion for routing to the next node which might be computationally draining

When I accept a payment I have to go through all of these steps! I have to accept an incoming update_add_htlc message which contains an onion. Then I have to decrypt the onion and if I have the preimage release the payment_preimage to settle / fulfill the onion.
I can safe a little bit on computing the next onion but that is not more complex than decrypting the incoming onion which I would have to do in any case. So the savings might be tiny here.
you also asked:

If the failure rate is too high, is there something like a banscore that is being kept by other nodes that might prevent this sensor node from receiving/sending payments in the future?

I believe Alex Bosworth from lnd announced that starting with the next major version (I guess that should be lnd 0.8) they want to start keeping track of who are good and poor routing nodes and create an internal score which will be used in route computation. In that way they plan to go a way from the cheapest routing fess but rather to metrics like realiability and uptime.
The BOLTs actually do not specify how pathfinding is supposed to be computed, so any implementation can do what ever they wish on this end.
One last thought. There are people working on hardware wallet for lightning one policy for those wallets is to be the other way around of what you ask. Have the private keys on the node for allowing routing of payments but if a new payment is supposed to be send have an air gaped device that helps to sign the messages which are needed.
All that being said it is totally possible that a node decides to only implement part of the protocol. However sending and receiving are exactly the messages and parts of the protocols that are needed for routing anyway (since a payment is coming in by accepting an htlc) and a payment is going out by offering an htlc. It is actually the ability to send payments that currently make the maintenance of a lightning node expense since they need to participate in gossip (which is the most costly operation) in order to participate in source based routing which is needed to initiate a payment.
If you just want to be a routing node you can totally opt out of gossip and just maintain your payment channels and state which comes at extremely low cost.

The gossip operation point was a good catch, I hadn't used that in my calculations. But assume, we use some data analysis tools to make sure that we avoid erring nodes. So if I reject a couple of payments coming through me, the generic software will ensure that it does the rest of the work for me by not routing payments through me anymore.?

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


text:
How does Bitcoin Core know the progress of blockchain without connecting to peers?
I restarted my Bitcoin Core node after a gap of about a day and when seeing the console log, I noticed that it calculated the progress of my blockchain even before  connecting to peers. The log information is pasted below. If you look at the last line, it says the progress=0.999577.
2020-02-03T09:02:15Z init message: Loading banlist...
2020-02-03T09:02:15Z Cache configuration:
2020-02-03T09:02:15Z * Using 2.0 MiB for block index database
2020-02-03T09:02:15Z * Using 8.0 MiB for chain state database
2020-02-03T09:02:15Z * Using 390.0 MiB for in-memory UTXO set (plus up to 286.1 MiB of unused mempool space)
2020-02-03T09:02:15Z init message: Loading block index...
2020-02-03T09:02:15Z Opening LevelDB in C:\Users\ugamk\AppData\Roaming\Bitcoin\blocks\index
2020-02-03T09:02:15Z Opened LevelDB successfully
2020-02-03T09:02:15Z Using obfuscation key for C:\Users\ugamk\AppData\Roaming\Bitcoin\blocks\index: 0000000000000000
2020-02-03T09:02:21Z LoadBlockIndexDB: last block file = 1951
2020-02-03T09:02:21Z LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=79, size=71688771, heights=615600...615678, time=2020-02-02...2020-02-02)
2020-02-03T09:02:21Z Checking all blk files are present...
2020-02-03T09:02:21Z LoadBlockIndexDB(): Block files have previously been pruned
2020-02-03T09:02:21Z Opening LevelDB in C:\Users\ugamk\AppData\Roaming\Bitcoin\chainstate
2020-02-03T09:02:22Z Opened LevelDB successfully
2020-02-03T09:02:22Z Using obfuscation key for C:\Users\ugamk\AppData\Roaming\Bitcoin\chainstate: f5c820df867e2ff2
2020-02-03T09:02:22Z Loaded best chain: hashBestChain=000000000000000000034ff79a0c7ec61ea44e59514172d2a8d83033aaf9416b height=615678 date=2020-02-02T17:29:57Z progress=0.999577

I was appalled because my node hadn't connected to any peers until this point of time. The only reasonable explanation in my opinion is that Bitcoin Core calculates the "estimated" progress assuming 10 minute block time and when it last received the block. Is my assumption correct, or is there something else that allows Bitcoin Core to know the progress.

The progress number is the ratio between the total number of transactions in the active (validated) chain, and the expected total number of transactions at the current point in time. The latter is estimated based on statistics that are hardcoded in the Bitcoin Core source code, and updated every major release.
For example in version v0.19.0, the source code, you find:

chainTxData = ChainTxData{
    // Data from RPC: getchaintxstats 4096 00000000000000000005f8920febd3925f8272a6a71237563d78c2edfdd09ddf
    /* nTime    */ 1569926786,
    /* nTxCount */ 460596047,
    /* dTxRate  */ 3.77848885073875,
};

Which implies that at timestamp 1569926786 (Tue Oct  1 10:46:26 UTC 2019), the total number of transactions in the chain was 460596047. After that point in time, 3.7785 transactions per second are expected.
The total number of transactions at present is then estimated as:

If last_block_time < nTime, (current_time - nTime) * dTxRate + nTxCount
If last_block_time > nTime, (current_time - last_block_time) * dTxRate + last_block_total_tx_count


text:
How to securely update and verify C-Lightning release?
Recently, a new version (v0.7.3) of C-Lightning was released. The GitHub page has detailed instructions on how to build the software from source, but does not provide much details as to how to update the software from the pre-built binaries from the release page.
I'm looking for instructions as to how to update the C-lightning software from the pre-built binaries for different OS (Windows, Linux, Mac etc.)
How do I verify the release signatures of the C-Lightning pre-built binaries?

I have divided this post into three sections: Download, Verification and Installation to make it easier for people needing help with specific sections. The installation steps have been reproduced using Ubuntu 22.04 but can easily be used for other versions as well. Just make sure to download the specific pre-built binaries from the release page for the OS you are using.

Download
C-lightning implementation is designed to work effectively only in Linux environment as of now. All the c-lightning releases gets posted on the GitHub’s release page. You can download them directly from the browser or use the below terminal commands:
# Download the Ubuntu release of C-lightning from the release page
ubuntu@user:~/Downloads$ wget https://github.com/ElementsProject/lightning/releases/download/v22.11.1/clightning-v22.11.1-Ubuntu-22.04.tar.xz

# Download the SHA256SUMS file that contains the hashes of the release
ubuntu@user:~/Downloads$ wget https://github.com/ElementsProject/lightning/releases/download/v22.11.1/SHA256SUMS

# Download the digital signature file SHA256SUMS.asc
ubuntu@user:~/Downloads$ wget https://github.com/ElementsProject/lightning/releases/download/v22.11.1/SHA256SUMS.asc

Verification
Before installing the software it is a MUST to check the signatures of the release. This ensures that the software has not been modified by a third party on the release page or has been tampered during the download process via a man-in-the-middle attack.
Following steps are followed to check the authenticity of the file:

Compute the SHA256 hash of the main file
Check that the hash matches that in the SHA256SUMS file we downloaded
Verify that this hash has been signed by a trusted developer

The first step is to check whether the SHA256 hash of the file that we have downloaded matches the hash produced in the SHA256SUMS file. Since SHA256 is a one way mathematical function it helps ensure that the downloaded file has not been modified as its hash matches that in the SHA256SUMS file.
# Calculate the SHA256 of the file that we downloaded in the last step
ubuntu@user:~/Downloads$ sha256sum --ignore-missing --check SHA256SUMS
clightning-v22.11.1-Ubuntu-22.04.tar.xz: OK

As you can see above, the hashes matched. However, just matching the hashes is insufficient. An attacker could have modified the zip file, and reproduced its changed hash in the SHA256SUMS file. Thus we need to ensure that the hash that is in the SHA256SUMS file has actually been signed by a trusted person. For this, we need to verify the signatures.
You can do that by using gpg. First we will need to import public keys of the developers who sign these releases. Download the files found in the repo here. Be sure to change to the correct tag of the release you have downloaded to ensure the keys have not changed between branches, as shown in this screenshot:

# import Rusty Russell's key
ubuntu@user:~/Downloads$ gpg --import rustyrussell.txt

# import Christian Decker's key
ubuntu@user:~/Downloads$ gpg --import cdecker.txt

# import Lisa Neigut's key
ubuntu@user:~/Downloads$ gpg --import niftynei.txt

The below step checks the signatures against the hashes in the SHA256SUMS file. If the SHA256SUMS file is missing you will get a can't hash datafile: No data error.
ubuntu@user:~/Downloads$ gpg --verify SHA256SUMS.asc
gpg: assuming signed data in 'SHA256SUMS'
gpg: Signature made Fri Dec  9 17:35:28 2022 UTC
gpg:                using RSA key B7C4BE81184FC203D52C35C51416D83DC4F0E86D
gpg: Good signature from "Christian Decker <decker.christian@gmail.com>" [unknown]
gpg:                 aka "Christian Decker <decker@blockstream.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: B731 AAC5 21B0 1385 9313  F674 A26D 6D9F E088 ED58
     Subkey fingerprint: B7C4 BE81 184F C203 D52C  35C5 1416 D83D C4F0 E86D

Installation
Now that we have verified the authenticity of the file, we can safely extract the zip file using the command tar xf clightning-v22.11.1-Ubuntu-22.04.tar.xz. The extracted folder will have folders bin, libexec and share as its contents. Paste the contents of these folders in the /usr/ directory (or /usr/local/). Note: Just replace the files within these folders. Do not directly replace these folders as these folders generally contain binaries of other critical software as well.

In general you can verify the SHA256SUMs with sha256sum --ignore-missing -c SHA256SUMS instead of manually comparing them, but that doesn't work as well with this release because SHA256SUM expects the files to be in the release/ directory.

C Decker key is now B731AAC521B013859313F674A26D6D9FE088ED58


text:
How can you calculate the inverse of S component of signature, while you cannot do it in ECC to calculate private key from public key?
When verifying the signature in bitcoin, we calculate S^(-1) * hash(m) * G + S^(-1) * R * pub_key and verify that this is equal to the temporary public key. Given the same logic, why can't we use it to calculate private key from public key?
for example: pub_key = priv_key * G. Modify it to: priv_key^(-1) = pub_key^(-1)*G and then take get the priv_key by taking inverse of LHS.
I just want to understand the math that makes us calculate S^(-1) in the first case, but does not allow us to do it in the second case.

The semantics of multiplication are different in your two equations.
As for the first equation. The s-part of a signature is an element in a group (represented by a number) so the inverse exists and is easy to compute (or even well known)
In the second case you take the numerical value of the private key and compute the multiple of this with a base point. With that notation the "inverse" becomes equivalent to finding the discrete logarithm in this additive group. In ecc it is not known how to compute the discrete log efficiently
I guess this answer is somewhat frustrating. I recommend learning about Groupe theory to understand the differences in notation.

Thanks for the answer. I was hoping that was the case, but just wanted to confirm. But say given a signature, how do you calculate the inverse of it?

A signature doesn't really have an inverse. It consists of two distinct elements, r and s. r is a point on the curve so finding it's inverse would mean solving the elliptic curve discrete log problem. However s is just an integer in the group. Finding the inverse of this is easy, as stated in this answer.

Thanks Andrew I fixed my answer. Since the question was about S^(-1) I was sloppy naming that the signature. I know you know that but for the other readers I want to emphasize that r and s are both elements of groups. Just very different ones. While s comes from a prime field r comes from the elliptic curve.

That's a good point. It was my bad to call the signature as S. I'll update the question to reflect S component of the signature. Thanks guys. Looks like I have some reading I need to do.

Note we write points in uppercase (G, Q) but numbers (or for F_2^m field elements) in lowercase (a, b, n, h, d, k, r, s) to help keep this distinction clear. @AndrewChow: in ECDSA r is actually the x-coordinate of a point (kG) mod n. But a given r corresponds to usually 2 and very rarely 4 points, and yes inverting those is equivalent to DLP.


text:
Why CHECKLOCKTIMEVERIFY and CHECKSEQUENCEVERIFY opcodes have to be succeeded with DROP Opcode?
Opcodes that end in VERIFY generally do not leave anything on the stack. What's so different and the reasoning when designing these opcodes that CHECKLOCKTIMEVERIFY and CHECKSEQUENCEVERIFY opcodes leaves something on the stack and hence has to be succeeded with the DROP opcode?

This is because CSV and CLTV are NOP opcodes that were redefined in a softfork.
As a softfork can only change the validity of transactions from valid to invalid, the only effect this redefinition was allowed to have is making the script abort in some conditions, and keep acting like NOP otherwise.
NOP does not pop anything off the stack, and as a result, neither can CLTV and CSV. Otherwise a script like "0 n CSV 0 EQUAL" would go from invalid to valid.


text:
How to capture c-lightining logs?
Where does c-lightning save its debug.log file? I know you can run the lightning daemon with --log-level=debug and access the logs in the terminal. But, I run my node on a remote server and I access it via SSH and sometimes when my internet connection goes off for a second on the machine which I am accessing through, my SSH client times out. I was wondering if there is a location where c-lightning saves all these logs just like how Bitcoin-core saves its debug.log file in ~/.bitcoin folder.

C-lightning does not save logs by default. One can ensure that the logs are saved to the drive by including log-file=<file_name>.log in the config file. When staring lightningd you can include the level of logs that the file has to capture by including --log-level=LEVEL, where LEVEL can be io, debug, info, unusual, or broken.

As all command line arguments to lightningd these can also be stored as key value pairs in a config file which is either called config and stored in your lightning dir (by default at ~/.lightning) or is passed as an argument to lightningd


text:
How Lightning Networks protect itself from 'Selfish Mining'?
It is a well accepted fact that mining pools do engage in 'selfish mining' by not broadcasting a block to the network when they find a PoW solution, but building on top of that block so as to maximize revenue. Now from the point of view of lightning nodes that are creating a HTLC, assume that the blockchain height is 'h'. A HTLC is forwarded by the origin node and each node on the way uses 1 block of CLTV_expiry_delta (say there are 5 intermediary nodes). But soon after the final node reveals the pre-image to its peer, 3 blocks gets relayed simultaneously. Now, it may be the case that even after including a buffer, some nodes along the path can get exposed as its peer can relay the transaction to the blockchain due to timeout. Is there a protocol in place to stop intermediary nodes from getting vulnerable due to selfish mining?

Your question seems very similar to the 51% attack vector on the lightning network which I described on the lightning dev mailing list. I am not aware of any protocol to prevent this nor do I see any way of preventing what you and what the mailinglist post describe. The timeouts depend on blockheight and the Bitcoin protocol has the consensus rules that the longest proof of work chain wins.
I think it is a generally accepted assumption that Bitcoin will only operate in a secure way if at least 51% of the mining power comes from honest nodes (which are following the rules) on the plus side any secrete mining operation would statistically speaking only be harmful if the operation has at least 51 percent which is hard to achieve and probably also more expensive than the gains from winning such an attack.

Thanks, I just got myself added to the mailing list (few days back) so I was oblivious that this issue was raised earlier.

But considering it, over the long term I'm not saying that the blockchain will face a 51% attack, but on short term even say couple of blocks, nodes can get vulnerable

Yeah but timelock are usually more than a couple of blocks. I think the recommendation is 144 blocks per node / hop on a path. Even 9 blocks which is the standard in some implementations is already very unlikely. For example a pool having 40%mining power will statistically only with every 10,000 blocks achieve to secretely mine the largest pow chain of 10 blocks. Compare that with all the list mining rewards. I guess noone has an incentive to do that

That is helpful. My question was based on the premise that implementations just use one or two block deltas per hop.


text:
Timer-based consensus algorithm in blockchain
Assume that there is an algorithm that ensures:
1- That a full node chooses an honest random wait time.
2- That the same node has waited the specified amount of time before proceeding to mine a block.
Would there be any need for mining using PoW and Why?
Note that I said an algorithm and not a central entity like  Intel Software Guard Extensions (SGX).

Keeping block time at 10 minutes is only one of the many benefits that PoW provides. Other important ones include preventing double spending and transaction censorship. Most of the PoW alternative consensus mechanisms out there simply fail to ensure this level of security. There is an interesting conversation on the Bitcoin mailing list that dives into Proof-of-Stake and its inefficiencies in ensuring the above.
Double Spending: PoW ensures that a node has spent electricity and compute power in order to find a hash that matches the current target. This ensures that there is a cost involved in case any one wants to 'rewind' the blocks and make a separate transaction that double spends the previous one. This would also mean, that the person who wants to double spend would need to amass more hash power (and hence investment) than rest of the network combined, an almost impossible feat.
Transaction censorship: In cases where you do not have PoW, an attacker will bootstrap millions of nodes to ensure that he is the one that gets chosen to form the block. In that scenario, he can ensure that certain transactions do not enter the blockchain, aka censorship. Censorship attacks cannot be prevented except by ensuring that no single entity can claim 51% control of new block creation. By ensuring this, we can ensure that at least some other entities are unlikely to keep a transaction out of the blockchain, and in particular that no entity can make a short-ranged history rewrite if a censored transaction does get into the blockchain from the efforts of another block producer. This is trivial under proof-of-work, and is ensured by asking people to make huge investment to get the hash power needed to mine block. Since it is non-trivial to acquire energy PoW prevents censorship attacks.


text:
What is the difference between listpeers vs listnodes commands?
In c-lightning implementation, what is the difference between the listpeers and listnodes commands of lightning-cli?

listpeers
listpeers returns data on nodes that you have connected with OR the nodes with which you have an open channel. If you have an open channel with a node, but the connection with that node has been lost, then the node will still appear in the output, with "connected": false. If you are connected with a node but do not have open channels, then it will return the output with "channels": [].
If you want to get information about a particular peer and not all of them, then you can add the node id of the peer like: lightning-cli listpeers <node_id>. You can also query log entries related to the peer by passing the command: lightning-cli listpeers <node_id> <level> where level can be io, debug, info, and unusual. Log levels can only be queried if a node id is supplied.
listnodes
listnodes will return the information of all the nodes in your local network view. This information is collected via the gossip network. If you pass the listnodes command without a node id, then the RPC will return information of ALL the nodes in your view. If you are interested in the information of a particular node id, then you can do so by passing the command: lightning-cli listnodes <nodeid>.

listpeers show current peers, which means your node has been peered to other nodes that are shown in the command. It also means you are ready to fund channels with these nodes.
listnodes show nodes in your local network information.


text:
Why is it necessary for Multi-Path Payments in Lightning to be Atomic?
One way of achieving multi-path payments in lightning is by having the sender use the hash sent by the receiver to send multiple payments along different paths.
The mailing list entry proposing atomic multi-path payments describes a downside where

the sender fails to
  actually satisfy all the payment flows, then the receiver can still just
  pull the monies (and possibly not disperse a service, or w/e).

But if I understand correctly, if the receiver pulls any flow before all paths are complete, the sender will still end up with the invoice and pre-image which they can use to prove the payment went through, and if the receiver refuses to provide some service, the sender has the same recourse as in the case where the payment was a single-path payment paid in full. Why then, is it necessary to have this atomic multi-path scheme, which makes use of unused bits in the lightning protocol that could potentially be used for something else?

You are pointing out trust issues that exist with any payment mechanism. You can pay for your coffee at Starbucks and still be denied your coffee. That is exactly the case you are pointing out. But, the protocol that is listed provides other benefits that help honest people make payments without having their funds stolen by straddling intermediaries, avoid headaches of refund or use balances across multiple channels to make payment. The concept of sound money transaction involves sending money to other party in a trustless way involving as little friction as possible. This protocol exactly achieves that.

Partial payments: Assume payments along some routes completes while payment along others fail to go through. The receiver, assuming he is honest, now has only two alternatives. Request the remaining payment, or refund the amount. In case of refund, you will again have to pay fees to route the payment which means loss of money in fees. The protocol provides way in which either the entire payment goes through or none of it goes through.
Straddling Intermediaries: Assume a malicious party has channels open with multiple people. Suppose you send your payment along multiple paths with the same payment hash, then this malicious intermediary might use the payment pre-image he learns in the channel he operates along the first path to settle transactions in the channel along the second path.
Use multiple channel balances: Assume you have channel opened across multiple people but none of the channel balance is sufficient to make the payment that is requested. Your only way of sending payment now involves on-chain transaction (either direct Bitcoin on-chain payment, or opening a new channel) which incurs significantly higher fees. With this protocol you can make use of multiple channel balances with fraction of the fee cost involved in an on-chain transaction.


text:
Why does a same transaction signed separately have different witness values?
I signed a bitcoin testnet transaction using nbitcoin library and got an output:
 02000000000101853b6bcbc78cf4cd621abb7edca78383ce15a34b6617347258d72d13ecb8fcbc000000001716001487463af228c128aad9371c3df1236d0518c32f44ffffffff01604898000000000017a9141b16cfd66b7f084bf95baf36d14df67f03ef230487024730440220376c73ba8bacbc791fc45ed596c8f973fe79ef0c1bb37a16fb2043dc0998ea62022027c7135359a103f243d865d89eb913e180ea751669b7a2f910b08eb3edcc76f5012102739a2f893507714c7e1b37510dede5aad15862b018f6ad9e9402e0b7290a133300000000

then I signed the same transaction with bitcoin-core and it returned an output :
  02000000000101853b6bcbc78cf4cd621abb7edca78383ce15a34b6617347258d72d13ecb8fcbc000000001716001487463af228c128aad9371c3df1236d0518c32f44ffffffff01604898000000000017a9141b16cfd66b7f084bf95baf36d14df67f03ef23048702473044022015499aee1e03fc9dd853abf3a9307ebd19dfd9e4f5209a7810be48dfed1c698002205d6c0da0a26918ca38d5aaf9629f7dd71119334e168aafd9f3363f05cb06c967012102739a2f893507714c7e1b37510dede5aad15862b018f6ad9e9402e0b7290a133300000000

On comparing the outputs, the txwitness stack value differs.
bitcoin-core witness data
"txinwitness": [
                "3044022015499aee1e03fc9dd853abf3a9307ebd19dfd9e4f5209a7810be48dfed1c698002205d6c0da0a26918ca38d5aaf9629f7dd71119334e168aafd9f3363f05cb06c96701",
                "02739a2f893507714c7e1b37510dede5aad15862b018f6ad9e9402e0b7290a1333"
            ]

nBitcoin witness data
 "txinwitness": [
                "30440220376c73ba8bacbc791fc45ed596c8f973fe79ef0c1bb37a16fb2043dc0998ea62022027c7135359a103f243d865d89eb913e180ea751669b7a2f910b08eb3edcc76f501",
                "02739a2f893507714c7e1b37510dede5aad15862b018f6ad9e9402e0b7290a1333"
            ]

But still, I'm able to send the transaction signed by nBitcoin.
So my questions are:
1) what are the values in witness stack?
2) why the same transaction have different txwitness value?

Bitcoin signatures have two components: s and R. To sign a Bitcoin transaction with private key k, the signing algorithm generates an ephemeral private key r. The R component of the signature is the x-coordinate of that ephemeral public key. The s component of the signature is calculated in the following way: s = r-1 (Hash(m) + k * R) mod p; where Hash(m) is the hash of the transaction data m.
Since, s changes with r, as shown in the equation above, the signature component will be completely different when you compare two transactions signed if their ephemeral key generation algorithm differs.
Most softwares uses RFC 6979 to deterministically but securely generate the ephemeral key used to sign transactions. So for two identical transactions, the ephemeral key should be the same and that is the reason you are seeing the same signatures on different Bitcoin Core software. However, RFC 6979 algorithm also allows the usage of other additional optional data while generating the ephemeral key. This additional optional data might be different for different softwares and as a result you are seeing different (s,R) signature from Bitcoin-Core and nBitcoin.

What is P in this equation s = r-1 (Hash(m) + k * R) mod p ?

If S changes with R, why bitcoin core, even on different machines produce the same signature?

@AkshayDev I have updated my answer to make it more clear. The mod p (modulo prime number p) indicates that the Bitcoin curve (secp256k1) is over a finite field of prime order p.


text:
Transaction malleability
I have been reading about transaction malleability a lot still doesn't make sense to me.
Is there a script I can use to test it out ?
If the transaction that is malleable is changed by the attack, how is it possible that the two transaction are still in the blockchain and the miners still pick the attackers TXID over the legitimate one?
Why our legitimate transaction not seen by the miners?

The transaction that you submitted and the transaction that was malleated in-flight or by a miner are both legitimate (valid) transactions. Transaction malleability means that a valid transaction can be modified in-flight, without invalidating it and without access to the relevant private keys. Even if changing the components of the transaction doesn't make it invalid, it changes the txid of the transaction. So if you plan on creating two transactions together, where the second spends the outputs of the first transaction, then you can be a victim of transaction malleability. This is especially important in Lightning Network where you create commitment transaction prior to signing the funding transaction.

Is there a script I can use to test it out?

The easiest one to try out is ECDSA signatures as ECDSA signatures are by themselves malleable. You can just change the S component of the signature to -S and it will still produce a valid signature verification check. This was fixed by SegWit by moving the signatures from scriptSig to a separate witness component. Although the signatures are still malleable, the txid calculation does not include hashing the witness component (wtxid includes the witness component and hence is malleable).

If the transaction that is malleable is changed by the attack, how is it possible that the two transaction are still in the blockchain and the miners still pick the attackers TXID over the legitimate one? Why our legitimate transaction not seen by the miners?

Many miners still follow a first seen policy which means they will use the transaction that they see first. Bitcoin operates a gossip network with best effort basis. If you broadcast your transaction to nodes directly connected with you then it might possible that one of them malleates your transaction and is able to send that directly to a miner before the honest nodes are able to do it. Thus the miner will keep the first transaction received and discard the second transaction as a double spend. The miner has no way of knowing which transaction was the one that was directly relayed by you. Only one of them will enter the blockchain, not both after the miner mines the block. It might also be the case that it is the miner you malleates your transaction.


text:
Signature digital algorithm in bitcoin, to what will it change in the future?
in follow-up to the question: 85202
There, @Ugam Kamat wrote ""ECDSA is the first thing that can get vulnerable with quantum computer. signature will need to move to post quantum world much before quantum PoW.""
My follow-up to that:
to which signature concept are experts thinking on moving to in the future, any ideas circulating right now?
thx

There's no consensus about the best post-quantum crypto encryption/authentication algorithms, but NIST has a competition to choose the best post-quantum crypto algorithms that are asymmetric (where public key and private key different). Surely there's enough time to wait for the competition to end before spending any effort on post-quantum cryptocurrency (Exceptions: qBitcoin, which is impractical, and Bitcoin Candy, which has no progress)


text:
Can signature be re-used to cash out everything in the address?
I Know for the P2PK locking script it was like this
[pubkey] <OP_CHECKSIG>
and then an unlocking script is provided as simple as this:
[sig]
But if it works like this, others can simply grab the [sig] and cash out everything in your address!
Is there some misconceptions I have?

When you sign the transaction with your private key, you include the hash of the entire transaction data as a message. This means the signature which is generated is specific to that transaction itself and any modification to the transaction will render the signature invalid. In this case, the user who has signed the transaction has already specified the address to which the bitcoins have to be sent. Any modification in the address will change the message digest, thus invalidating the signature.
Moreover, Bitcoin operates on an UTXO model rather than an account/address based model. Everytime you send bitcoins you consume previously unspent outputs in its entirety and create new unspent outputs. For example, let us say you have 1BTC UTXO. When you want to spend for a 0.1 BTC coffee, you will consume the entire 1 BTC UTXO, send 0.1 BTC to the coffee shop and 0.9 BTC back to yourself. This 0.9 BTC output is different from the 1 BTC output that you controlled previously.
In a transaction, these unspent outputs are specified in the transaction with the identifiers: txid and vout. After the user's transaction gets confirmed, the txid which was referenced in the previous transaction no longer remains unspent. Thus, it is not possible to re-use the same signature even if you are sending to the same addresses again.

But from here https://bitcoin.stackexchange.com/questions/92504/do-transactions-need-to-be-signed/92505#92505 I got the point that transactions don’t need to be signed, to be signed (the signature Is usually in unlocking script) is the previous outputs. Btw, as OP_checksig only deals with two parameters (pub key and sig) what operations is used to check if the sig does match an entire transaction?

OP_CHECKSIG takes as input a signature and a public key from the stack, and replaces them with either a 0 or a 1, depending on whether that signature is valid for that public key, with (simplified) the spending transaction as message. If a script without OP_CHECKSIG (or similar) is used, then indeed the input can be copied to spend any coins on that address. However, this is not under control of the attacker: the receiver would have needed to accept coins on an address that did not have any signature checking operations.

@PieterWuille does the OP_CHECKSIG check if the signature's signed message is the transaction?

Your question is poorly phrased, as that is not how signatures work, but for all intents and purposes: yes. Signature verification is a function that is given the public key, the signature AND the message (so the message has to be known ahead of time to the verifier, it is not contained in and cannot be extracted from the signature), and returns false or true. In the case of OP_CHECKSIG, the message passed to the verifier is computed based on the data in the spending transaction.

To elaborate on this part of Ugam Kamat's excellent answer: "When you sign the transaction with your private key, you include the hash of the entire transaction data as a message."
The function that turns the transaction into a hash to be signed is not just any hash function; in the code it's called a "sighash" or "signature hash". Each signature contains encoded flags called "sighashflags" which answer the question: "
Which parts of the transaction shall be hashed, and which parts shall be ok to modify without invalidating the signature?"
The way signature hashing works pre-segwit is a bit messy, and I don't remember it well enough to lay it out in detail, but you can find it in the source code for the class CTransactionSignatureSerializer.
Post-segwit, there is a specification for the signature hash function in BIP 143: https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki . (It also describes some of the issues the old version a bit, under "motivation")
The SIGHASH_NOINPUT proposal (see e.g. https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki , although I'm not sure how current that is) would allow a new type of signature hashing, which does not include the transaction inputs into the signature. This would, in fact, allow the same signature to be reused multiple times to cash out coins from the same address! HOWEVER, there are still restrictions that would make it not as bad as you fear: (1) The outputs are still signed, so the person replaying the signature can't change the destination of the coins. (2) The signer has to CHOOSE to use this mode; an attacker can't change the sighashflags of a signature.
Even despite those restrictions, there were concerns that people could be harmed by using this mode without understanding all the possible consequences. I'm not sure what the current state of the proposal is.


text:
Is a bitcoin UTXO divisible?
In this video Andreas Antonopolous says an output is indivisible and therefore if a transaction smaller than the output is done, the rest is used as change and returned to your different address of same public key.
Is this true? How does lightning work with microtransactions then?

Small correction: there is no such thing as a different address of the same public key; if the key is the same, the address is the same. Change is usually sent to a different address, with a corresponding different key, but belonging to the same wallet.

Is this true?

Yes, it is true. In very very simpler terms, think this to be in a way wherein someone sends you a coin worth that amount. In other words, if someone sends you 10 BTC, they are sending you a coin that is worth 10BTC, while when they send you 5 BTC, they send you a coin worth 5 BTC. So, while you are spending that money, you have to spend the entire coin. This is exactly the concept with UTXO. When you need to send some bitoins, you have to consume the entire UTXO amount and send the difference back to yourself through a change address.

How does lightning work with microtransactions then?

Lightning transaction works in the same way. When forwarding a HTLC you subtract the amount from your own balance and lock that in the HTLC. Eg. Alice and Bob have a channel. in the present state, the commitment transactions of the channel consumes their channel funding transaction and outputs to (1) Alice_pub_key and (2) Bob_pub_key. Say Alice wants to send X satoshis to Dave. Alice creates a commitment transaction with Bob that consumes the entire bitcoins from the funding transactions of Alice and Bob's channel, and outputs to (1) X satoshi to htlc; (2) Alice's balance - X satoshi (3) Bob's balance.
Similarly when Bob forwards to Charlie, he will be deducting X satoshi from his balance in his commitment transaction with Charlie. Same with Charlie and Dave. When Dave provides the preimage, he will claim the amount in HTLC output in the commitment transaction with Charlie. Charlie will then claim that amount from his commitment transaction with Bob and Bob will claim the amount from the htlc output in the commitment transaction with Alice.


text:
Upgrading Fees in Bitcoin Trading
I would like to know what "upgrading" fees are? The guy who's mining my account says I need to pay him $1005.50 more in Bitcoin before they can go on. I only invested $300.00. Does it sound correct?

You are being scammed.
Individual accounts do not need mining, mining is required to secure the network as a whole.
This is a common scam, where they ask you to "invest" a certain amount into mining, and then string you along by asking you to pay more to unlock better returns, or unlock your keys, or whatever other nonsense they can come up with.
Cut your losses and write of the $300, do not send them any more funds.


text:
Chicken and Egg confusion over Bitcoin generation
If Bitcoin is rewarded through mining, and mining is the process of packing some transactions in a block(and adding that block successfully to the blockchain), and on the other hand, a transaction itself is sending Bitcoins to someone else, then isn't this a chicken and egg issue? How could a transaction(say the first one) take place at all when there's no Bitcoin yet? Just getting myself familiar with the basic concepts of Bitcoin.

A valid Bitcoin block has to include a minimum of one transaction, which is the coinbase transaction that pays out the block reward. Most of the early Bitcoin blocks did not include transactions that sent bitcoins from one party to other, but included only the coinbase transaction that paid out the newly minted bitcoins.
In fact, the first transaction wherein an exchange of coins occurred was in block #170, when Satoshi sent 10 BTC to Hal Finney

So first Bitcoins were generated merely because of the proof-of-work reward. (I hope I get it right) I think it has fixed my confusion. thank you.

@Moytaba to be more technically correct, all bitcoins are "generated" from proof-of-work reward. It is only through other transactions (non-coinbase) that they change hands.

The block with the first transaction was in block 170 https://www.blockchain.com/btc/block/00000000d1145790a8694403d4063f323d499e655c83426834d4ce2f8dd4a2ee. The output that was spent was from block 9.

@JBaczuk Meh, you are right. it was my oversight. I should have double checked.


text:
BOLT 11 - Why is the description field limited to 639 bytes?
Why is the description field in a Lightning Network invoice limited to 639 bytes?
https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md#tagged-fields
https://github.com/lightningnetwork/lnd/blob/95502da7e87d7f1ae96e9d69fcdb2f1b038d6497/channeldb/invoices.go#L85 (LND limits it to 1024)
I would like to send data over the lightning network using the description field for the anonymizing aspects of onion routing in conjunction with the economic incentive for honest nodes.

Why is the description field limited to 639 bytes?

Every field in lightning invoice is of the form:

type (5 bits)
data_length (10 bits, big-endian)
data (data_length x 5 bits)

The data_length indicates the size of the data that is to be followed. Since data_length itself has a size of 10 bits, it can represent a number up to 1023 (210 -1). Thus the size of data can be at most 1023*5 bits or 639.375 bytes. This puts the upper limit of 639 bytes on the description field.

Ah thank you for your answer, I understand now, it is due to the number of bits on data_length.


text:
Can the blockchain be imported into wallets of different brands?
Can I import the block chain that bitcoin core downloads to use in any of the other full node PC wallets? Are the formats the same or inter-convertible?

What other full node wallets?

Any listed (here) https://bitcoin.org/en/choose-your-wallet under desktop.

Those aren’t full node wallets. They’re relying on remote services in one way or another.

The description of half state that 200gb is required and full validation

Bitcoin Knots
Bither, msigna

Knots is a rebrand of Bitcoin core.


text:
Probability an honest node finds the next block vs. probability the attacker finds the next block
I am trying to understand Satoshi's paper [1]. On page 6 of the paper, he calculates the probability that someone can attack the blockchain from z blocks behind. He begins by defining:

My question: The mining of a block i.e., solving the hash puzzle is a completely brute-force trial-and-error process in which one keeps trying a random nonce until one gets a hit. No one has an upper hand in this process. So shouldn't p and q be equal to each other?
EDIT: since comment would have been very long. Responding to the comments, in that case it gets even worse. q can be greater than p. Let the Bitcoin network be composed of M mining pools with their compute power be given by p_i. Then all an attacker needs to do is to form a pool whose compute power is greater than max(p_i). Am I missing something? In other words, the pool with max compute power can attack the blockchain already.
In an ideal design, if I want to attack the blockchain, I should be pitted against the sum of p_i not the max of p_i.

not if they are dependent on the hashpower of the attacker vs the hashpower of the honest node

My question assumes the hashpower are equal. I think its a safe assumption.

@morpheus That's not a reasonable assumption. Why would the attacker have exactly half of the hashrate?

Help me understand. Given N miners each having same computer, everyone has equal chance of finding the next block, no?

The attacker may have multiple computers. Or a datacenter. Or be the NSA.

related: https://bitcoin.stackexchange.com/q/36192/5406

"No one has an upper hand in this process. So shouldn't p and q be equal to each other?" is not accurate. The chance of succeeding follows the number of tries each participant is making.

@Murch, yes I get that. I had made an assumption that an attacker would be able to assemble same hash power as the most powerful mining pool. In that case wouldn't p be equal to q? And why is that not a safe assumption? (think of the most powerful pool as the one who wants to attack :)

The reason p and q are not equal is because the attacker is indeed pitted against the cumulative power of the entire network vs. being pitted against one miner.
If there was just one miner to compete with, then both the attacker and miner would have equal chances of finding the next block and p is indeed equal to q in that case (assuming identical hardware and hashing power). But when there are n miners, each of them working independently, then the chances that one of them finds the next block increase dramatically. The rate factor becomes $n \lambda$ instead of just $\lambda$. See https://en.wikipedia.org/wiki/Exponential_distribution#Distribution_of_the_minimum_of_exponential_random_variables and so now p/q=n.
Another way to get above result is to recognize that mining a block is like winning a lottery where everyone has equal chances (again assuming identical compute power). So if there are n miners plus 1 attacker, then p/q=n
Bitcoin is pure genius.

"If there was just one miner to compete with ... p is indeed equal to q in that case". The probability of finding the block is proportional to the number of tries, which means that it is proportional to the hash power that you have. Even if there are two miners, one could be using a huge datacenter, while the other might be mining on his 10 year old laptop. Their hash power would not be the same, and hence p and q will also not be equal to one another. Hash rate is the metric to be used to find out the probability of a miner finding the next block.

This is very confused. Even if there was just one attacker and one honest miner, there is no reason to assume they have the same hashrate. Hashrate depends on how much hardware and electricity each has at its disposal.

No one has an upper hand in this process. So shouldn't p and q be equal to each other?

The chances of finding a valid block header that meets the target requirement increases proportionally to the number of tries. This means that it is proportional to the hash power that you have. Even if there are two miners, one could be using a huge datacenter (the size of United States), while the other might be mining on his 10 year old laptop. Their hash power would not be the same, and hence p and q will also not be equal to one another. Hash rate is the metric to be used to find out the probability of a miner finding the next block.

Then all an attacker needs to do is to form a pool whose compute power is greater than max(p_i). Am I missing something? In other words, the pool with max compute power can attack the blockchain already.

What you are describing is a 51% attack. With the current hashrate of the Bitcoin network, it would require HUGE investments (billions of dollars) from the entity who is planning to do such attacks. At that investment level, the economic incentive to launch such attacks may be tiny, unless it's a state actor who is trying to annihilate the confidence of the network. Even if a fraudulent miner amasses >50% of the hash rate of the network, full nodes MAY try to patch themselves to reject such blocks (for example: if that attacker tries to broadcast a longest chain that is > 6 blocks different than the original chain, to prevent double spends).


text:
How does bitcoin core save raw transaction data?
I had a few questions. I've looked extensively online and can't seem to get answers right on point.
I just started a full node using bitcoin core and it is currently syncing/validating the past blockchain and catching up. I understand that the default setting in bitcoin core is that non-wallet transaction data is not stored on your harddrive in the blockchain data. My questions are then:

Is transaction specific data (ie: bitcoin address, time, inputs/outpus, etc...) stored in any of my raw data (eg: blk.dat file)?
How does my node verify/validate the past blocks without knowing the transactions from that block? I'm assuming other nodes don't store the transaction data so how is it that my node obtains the transactions to do a full validation of the particular block?
If the transactions are not stored on my computer, how do I have a full copy of the blockchain? I thought this was one of the points of running a node - you have a full backup of the entire blockchain. How could I reproduce the entire blockchain (if needed) without having the transaction data within each block?
If transaction are not stored, what exactly is stored in the block data and how is that useful? Is there a way to decode or use a mechanism to obtain the transaction information from the raw block data files?
If transaction data is not stored in the block data of your computer (ie: txindex=0), how can you reproduce all the transactions if needed without having to download anything or connect to intenet to get it from other nodes if say you were the last node with a copy of the blockchain (eg: in case of an emergency if say, theoretically, all blockchains were somehow deleted and mine was the only one left)?
Do I need to enable txindex=1 to have raw transaction data stored on my node? Or is it stored and accessible if needed without this enabled?

would really appreciate your help!!

I understand that the default setting in bitcoin core is that non-wallet transaction data is not stored on your harddrive in the blockchain data

Actually the default is that it is stored, in the blk.dat files. There is another database for unspent outputs, in the chainstate folder. Your wallet will also index transactions for which you have imported the keys to either spend, or just watch.

Is transaction specific data (ie: bitcoin address, time, inputs/outpus, etc...) stored in any of my raw data (eg: blk.dat file)?

Yes. Except that addresses are not stored, as addresses are an external format for specific types of scriptPubkeys, and timestamps are only in blocks, not transactions.

How does my node verify/validate the past blocks without knowing the transactions from that block? I'm assuming other nodes don't store the transaction data so how is it that my node obtains the transactions to do a full validation of the particular block?

It does know the transactions from that block because it downloads the blocks from other nodes. The blocks contain the transactions.

If the transactions are not stored on my computer, how do I have a full copy of the blockchain? I thought this was one of the points of running a node - you have a full backup of the entire blockchain. How could I reproduce the entire blockchain (if needed) without having the transaction data within each block?

They are, see above

If transaction are not stored, what exactly is stored in the block data and how is that useful? Is there a way to decode or use a mechanism to obtain the transaction information from the raw block data files?

They are, see above. You can get the information with RPC commands using the cli such as:
$ bitcoin-cli getblock
$ bitcoin-cli getrawtransaction <tx-id>

If transaction data is not stored in the block data of your computer (ie: txindex=0), how can you reproduce all the transactions if needed without having to download anything or connect to intenet to get it from other nodes if say you were the last node with a copy of the blockchain (eg: in case of an emergency if say, theoretically, all blockchains were somehow deleted and mine was the only one left)?

txindex=0 does not mean that the transaction data is not stored, it only means that it is not indexed. This means you can only get raw transactions by txid using the getrawtransaction command for transactions in the mempool, see getrawtransactions

Do I need to enable txindex=1 to have raw transaction data stored on my node? Or is it stored and accessible if needed without this enabled?

Only to index the transactions, see above

Thank you so much, very helpful. Two follow ups:

So basically, if I ever needed to, I could use the raw data saved on my hard drive (with txindex=0) and (with tools mentioned above) create my own blockchain explorer detailing every transaction (inputs, outputs, etc...) without needing to obtain that information from any other nodes? I'm just thinking the hypothetical/theoretical situation where my computer has the only copy of the blockchain left and people rely on me to propagate all the transaction information.

Related to the above, isn't not having timesamps per tx an issue?

yes you can.
no because all transactions are included in a block, which is timestamped

Thank you. Ok one final question re: #1. You mentioned above the bitcoin addresses aren’t stored so how do you recreate the transactions without the bitcoin addresses?

My pleasure. There are only a few types of addresses, and they are just encoded versions of scriptPubkeys in each transaction output, so you can detect these scriptPubkeys and encode them into addresses for the explorer. I suggest reading up on what an address is.


text:
Help get specific address private key
I want to know if someone can help me with this situation:
Two years ago I changed the password of my Bitcoin-Core wallet and forgot it.
I sent my wallet.dat to some person, who claimed that will crack it down and return my coins with some fee.
In the wallet there were only 2 addresses, and after some time the coins dissapeared, but only from one of them. I saw in the blockchain that they were "mixed" or split, in a way not to be traced.
Here is the address they went to: https://www.blockchain.com/btc/address/1PFygtEEhi4spjHJ3DHEBvgVpNp8oBY4A2
Coins from the other address are still in the wallet, and I found my password for the core wallet, but I don't know how to use it for that specific address with the coins left.
There are 1.3 BTC inside / still 8.30 stolen / but it will be a little relief for me if I can get them.
I have my original wallet.dat file also - so if anyone can help me, I will be very grateful.

It isn't clear why your "helper" would have missed 1.3 BTC at a separate address in the same Bitcoin-core wallet. Did you use the "Account" feature that was recently removed from Bitcoin-core?
I would do the following
Prepare a new empty wallet using your choice of hardware wallets or software wallets (1). Make a careful note of the seed-phrase/recovery-phrase or private-keys. Practice restoring this wallet from only that noted secret information.
Download and install the latest Bitcoin-core onto a clean PC and reinstate the old wallet.dat file into it (2), then use the newly found password to open it
Let it synchronise (may take days or weeks)
Immediately any money is visible, transfer any money into the other wallet.
If no money is visible, try to find out the status, in the wallet, of the address you say holds 1.3 BTC. Note that the command line interface(3) may be helpful in listing addresses the wallet is keeping track of.

References

https://bitcoin.org/en/choose-your-wallet
Import wallet.dat into a new Bitcoin-Qt client
https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list

You can get access to all the addresses in that wallet.dat file if you found your password.
In order to actually spend your coins or move them to another address, you have to install a bitcoin wallet. I recommend to always use the official wallets if possible. Github is a great place to look. Bitcoin source code is here and the releases are here.
The binaries for bitcoin (installation files) are found on the bitcoin core website. This link currently points to bitcoin-0.18.0 so make sure to check for the newest version at Github.
After you have installed bitcoin wallet on your system, you will have to download the blockchain - the wallet does this on its own if you allow it to connect to the internet. The bitcoin blockchain is more than 200GB big so make sure you have enough space. If you don't have enough space, you can run the bitcoin wallet in prune mode.
After the wallet synchronizes with the blockchain, you can send your bitcoins (from every/any address in the wallet) to another wallet.


text:
How to find out if LND opening pending channels has a confirmation onchain?
After typing lncli pendingchannels I get a channel_point number, and when I put channel_point txid to check if it was confirmed onchain
by typing:
bitcoin-cli gettransaction "txid insert"

I get an error:
error code: -5
error message:
Ivalid or non-wallet transaction id

How can I  see if whoever opened (pending state) channel to me has a confirmation on chain?

lncli pendingchannels gives a pendingChannelRespnse which might have the pending_open_channels parameter. This contains an array of  PendingOpenChannel objects.
According to the documentation they should have a parameter confirmation_height which is the height of the blockchain at which the funding TX has enough confirmations (the max of your and your channel partners threshold)
See

So from bitcoin-cli you figure out the current height and take the difference to see how many confirmations are still needed.
I guess if you don't get a pendingopenchannel object you don't have confirmations yet.

Thank you I see "confirmation_height": 0,

its just I've been waiting for several days for someone opening channel to me but its always pending.I looked at the mempool and its empty therefore if a person who opened a channel to me set 1sat/byte then it should be confirmed but I cannot even see the transaction onchain. I am confused.

I have been contacted by another person running c Lightning having a similar issue. and I have the idea that you have a power that does (deliberately?) not follow the channel establishment protocol. Can you see from the logfiles at which state of the channel establishment protocol you are in? Which BOLT 02 messages have been exchanged so far? Maybe your node did not send funding _signed message?  (obviously I am guessing here as I don't have full information)

I don't use BOLT

I have no idea what BOLT means my misunderstanding. So I don't know how to do all that Rene.

Well I was asking for your logfile and in particular the entire that concern the channel opening protocol. I have just released a video about channel closure on my channel that might help you to understand the channel protocol BOLT 02 https://youtu.be/Gyt4nxRHy04. BOLT stands for basics of lightning vtechnologies and is the protocol specification that all implementations are following. This I am pretty sure you unknowingly are using the BOLTs (:

To get the TX, using

lncli pendingchannels

You'll get a JSON document and the channel_point is your TX (Minus the :1 at the end)


text:
I had someone offer to mine bitcoin for me, I am a beginner
I had someone offer to mine bitcoin for me. I pay for the bitcoin on cash app and he mines it for me. With messaging him I started to feel like he didn't really know what he was talking about when telling me to sign up for cash app and coinbase. I followed what he said but during signing up on the 2 sites but it was like he didn't know what he was talking about during the time I had to wait for both account to be verified with 2 small cents deposits into my bank account. But he was telling me miss information on what to do an it didn't make any sense. Cause the sites were basically saying I can't move forward until i enter in the 2 amounts. But had to screenshot the pages to show what they said and had to write it all out for him exactly how it showed on the sight. and after a few minutes he finally understood me. But it feel like he didn't even know how to sign up process went which is suspicious to me an I don't want to get caught in a scam

Yes, this is a scam. Do not follow the scammers advice, do not send them any more information, and definitely do not send them any bitcoin. If you're interested in Bitcoin, this is a good starting point: https://bitcoin.stackexchange.com/questions/22796/i-am-new-to-bitcoin-how-can-i-get-started

The "small deposits" thing is often a way to authorize another bank account to be "linked" with yours.  It's very likely that the scammer now has the ability to withdraw money from your bank account, even if your intention was only to let him deposit money.  You should notify your bank of what happened and close the account immediately, and hope that the scammer hasn't yet had a chance to take all your money out.

Sadly there are a lot of scammers around. Don't pay to anyone you don't know (and before you sign up on an exchange, make sure it's a reputable one).
There are also some services which allow you to buy "a miner" which mines for you, but generally, you would be better off just directly buying whatever coin you want yourself.
Be careful, don't trust strangers.


text:
Someone is using a bitcoin account to blackmail me
Someone using a bitcoin account is trying to blackmail me. The account number is 1Mtsd3wXgkJnApaNpqaSSWLC6gCLBBxuaGG.
I still have the email they sent me. I can also provide that email if needed, or I can provide full detail.
I wasn't sure where to email or how to report this, can you direct me to the right place?

The answer by @RedGrittyBrick is correct and the Bitcoin address is not really traceable, however, an email certainly might be.

Blackmail should be reported to your local police.
This is a question and answer website where ordinary people like you and I share helpful information on a voluntary basis. We don't run bitcoin (no one does).
The number is not an account number, it is a bitcoin address. Those are not really traceable to any specific person, computer or place. People like the FBI may be able to eventually track down criminals using bitcoin on a large scale but we can't.


text:
Pay with Bitcoin?
I want to add Bitcoin payments on my website. I've found some PHP library, but as far as I understand it's using only one wallet for incoming payments, and possibly just tracking for confirmations. Is that how all of the payment gateways work? If that's the case, how does it recognize which payment is from whom? For example, if two customers buy the same thing on the same time, and only one pays for it, how would it know which one paid? Thanks!

how it recognizes which payment is from whom?

I believe you need a system, based on an HD wallet, that generates a new receive address for every order and keeps track of which receive addresses were assigned to each order number and customer ID (or other unique identifiers)


text:
Transfering Bitcoin from India
Since BTC is illegal in India, can someone from India who still have the bitcoin transfer to my Coinbase account in US?
Is there any transfer fees or exchange fees that we need to pay in either countries and is it legal to transfer?

Bitcoin is not illegal in India.

can someone from India who still have the bitcoin transfer to my Coinbase account in US?

At a purely Bitcoin protocol level, yes - Bitcoin does not differentiate between users, locations, individuals, companies, or any other thing. All Bitcoin transactions are equal.

Is there any transfer fees or exchange fees that we need to pay in either countries

You will incur the network fees for the Bitcoin transaction, which vary on the network state and transaction size.

and is it legal to transfer?

You should consult a lawyer in your jurisdiction.


text:
To what extent does asymmetric cryptography secure bitcoin transactions?
Is there a specific attack or bug which asymmetric cryptography prevents during bitcoin transactions?

Is there a specific attack or bug which asymmetric cryptography prevents during bitcoin transactions?

asymmetric cryptography is not really something that was added on top of Bitcoin in order to prevent some specific attack or fix some specific bug.
asymmetric cryptography is one of two fundamental foundation stones, one of the two primary building blocks on which the Bitcoin concept is based. Without asymmetric cryptography and one-way hash-functions the whole idea of Bitcoin would not have got started at all.
asymmetric cryptography underlies almost everything that is important in Bitcoin. Without asymmetric cryptography there could be no Bitcoin.
If I had to identify one thing that asymmetric cryptography provides it is that it prevents 7 billion other people being able to remove money from your wallet whenever they want and you being powerless to stop them. Its the difference between putting your cash in a safe only you know the combination for and leaving your cash on a park bench in the center of a crowded city while you go elsewhere for a year.
You might enjoy watching the two videos at https://anders.com/blockchain/ (watch both and in the right order) They are very easy to follow and reasonably brief. The first sets the scene, the second builds on that to answer your question (but you have to watch the first before the second)

Can I share you my research work? so that i get my primary resource who can verify whether my informaiton correct or no. I am 17 and this is my school work. Help is needed

More fundamentally (not specific to bitcoin/cryptocurrency), asymmetric crypto is what makes it possible to exercise any form of "control at a distance". Without it, there is no evidence to a person or machine carrying out your instructions that they're actually your instructions and not a misrepresentation by some party involved in conveying them.

Without asymetric cryptography, there wouldn't be information asymmetry: in other words, everyone knows exactly as much as everyone else. If everyone knows equally much, there is no way to distinguish a legitimate sender from a malicious one.
More specifically, if a symmetric construction like an HMAC was used to authenticate a transaction, miners would learn the key from legitimate spending transactions, and be able to instead mine an (indistinguishable and also legal) transaction that steals the coins.


text:
How to find where coin was picked up
I just recently sent two transactions at $2,500 a piece to a wallet I was given to transfer the money to. The money was transferred and the person has disappeared. I'm wondering how to find out where the money was picked up at.

how to find out where the money was picked up

You can't.
Bitcoin was designed with privacy in mind.

If you're working for a police agency, you may be able to.  If you're working for the CIA or an equivalent national intelligence service, you probably can.  Bitcoin was designed with pseudonymitiy in mind, not anonymity, so you can freely track the flow of money through the network.  You generally need government-level investigative powers to track money as it enters or leaves the network.


text:
No menu in Ubuntu bitcoin-qt
When I run bitcoin-qt on Ubuntu 12.04, I see this:

As you can see, there is no menu on the top menu bar.  There is the "beginning" of a menu with the word "Bitcoin" but there are no "File", "Settings", or "Help" menu titles.  Clicking on the word "Bitcoin" in the menu bar does nothing.
According to this it seems there should be a menu.
How do I get the menu to work?

This happens with many Ubuntu Apps. The simplest solution is to tap Alt any type the name of the menu item you wish to find.

Alternatively, hit Ctrl-Alt-F2, log in, type DISPLAY=:0.0 unity --replace hit Enter, and then do Ctrl-Alt-F7. The menu bars and the windowing system will reload.

This solved it on Ubuntu:
sudo apt-get remove appmenu-qt5

and the menu was visible when bitcoin-qt (bitcoin-0.13.0rc1, compiled from source) restarted.

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


text:
Why do I have to deposit BTC as missing turnover
I accidently transferred BTC to a non existing wallet. The wallet is now being created and I have to activate and verify it. To activate and verify I have to deposit 4,9 BTC. Is that how it works? Why do I have to deposit so much BTC? There are already 7,3 BTC on that wallet when it is created.

who or what said that you have to deposit BTC into a wallet before being able to use it ? please clarify and be careful it seem like a classic scam

Did someone ask you to transfer money to this address and then later claim that it was the wrong one? Where did the address you transferred to come from in the first place?

You are almost certainly being scammed.
Bitcoin wallets do not require activation.
In any case, even if you were dealing with some entity that does require verification for using their services, the amount you claim is stored with them exceeds the amount they are asking for - a sane, legitimate business would just charge the amount against what they already have and send you the balance.
Do not send any more funds to these people.

You are being scammed! Don't send any BTC to them.
Proper Bitcoin wallets are generated on your computer / phone, they contain bunch of private keys, each of one has corresponding address, to which you or others can send BTC. There is no concept of "activation" in Bitcoin.
If you accidentally transferred BTC to a wrong address, either it's from somebody else's wallet, then he can send you BTC back (if he wants to), or, it is possible to send BTC to addresses to which nobody has private keys and such bitcoins are most likely gone forever, it is practically impossible to recover them.

I accidently transferred BTC to a not excisting wallet

If you did that, the money would be gone forever and no-one would ever be able to gain control over it.
Bitcoin wallets make special checks to prevent this. Bitcoin-addresses have checksums. It is very hard to accidentally create a Bitcoin-address with a valid checksum.

The wallet is now being created

Bitcoin transactions involve sending money to a Bitcoin-address. These addresses are created by wallets from a private-key. It is not possible to create a private-key from an address. If it were possible, the whole Bitcoin system worldwide  would be destroyed and all Bitcoin valueless.
Most likely you were tricked into sending money to an address created by a criminal.

To activate and verify I have to deposit 4,9 BTC. Is that how it works?

No that is not how it works.
It is completely free to download Bitcoin-wallet software to your computer or to your phone and to install and run that wallet software. There are no charges for doing this.

Why do I have to deposit so much BTC.

You don't.
The thief wants your money and so wants to convince you that this is necessary. The thief is exploiting your lack of knowledge of how Bitcoin really works - in order to steal money from you.

There are already 7,3 BTC on that wallet when it is created

It is almost certain that this money is gone and that you will never get control over it. You can, and should, report this crime to your local police. Awareness of the extent of this sort of crime can help guide allocation of police resources. Do not expect them to be able to recover your money though - it is most likely in the control of someone in a far away country.


text:
How can a 51% attack be successful?
In the paper by Nakamoto, miner can accept the mined block only if all transaction are valid.
Assume that there are 5 miners in the world. 4 of 5 are honest that have 10% of 100% hash power and 1 of 5 is malicious that has 90% of all hash power.
Let's say group A consists of honest nodes (4 of 5).
Let's say group B consists of malicious node (1 of 5).
Group B wants to create a block which has a fraud transaction (e.g. Alice wants to spend 1000 BTC but she actually does not have it).
Group B is successively creating and propagating some blocks with huge hash power, but Group A does not accept these blocks because transactions in blocks are invalid.
Yes, 51% attack is not accepted with only hash power. So, length of chain of group A is short but group B is long. But group A does not accept chain of group B.
So my conclusion is that 51% attack makes a mess in the network, not coin control.
I'm confused. Please help me understand where I am wrong.

A 51% attack does not allow the attacker to spend coins they do not own; the usual rules of validity still apply for transactions and blocks. If those rules are broken, the block/transaction will be ignored by the rest of the network, no matter how much hashpower the miner making invalid blocks has.
This question has a more complete explanation of what a 51% attacker can, and can not do.


text:
Bitcoin goes Zero?
If the Bitcoin goes zero in value, Many crypto holders an investors will jump off the bridge i guess. Because they earn in Bitcoin now and planning to earn more in the future. But what if the Bitcoin goes zero in value? Just want to know some of the perception of others xD
My friend recommended this site to me yesterday and I found it very useful, a lot of trading sessions and tips. Just visit MTBIT Academy

The price only goes down if there is more supply than demand. So more people that want to sell then those that want to buy. Like any market, as the price drops new investors will see it as an opportunity to enter a market and start buying, creating new demand. This stabilizes the price and finally will start increasing the price as more and more people feel confident to buy. This is a reoccurring phenomena you see on every stock / commodity and bitcoin market.
Holders of big amounts of bitcoin (or any other market asset) are usually careful by not flooding the market to such level it can create its downfall. On traditional markets this is even illegal in some cases. In crypto currency they might use this power to create sudden price drops, to be able to buy back cheaper. This would be conspiracy theory, as I'm not aware of real prove of such thing happening.

Wow you gotta be professional one sir @@ Although this is really a fundamental basis in stock / commodity and bitcoin market, but your answer is truly a fascinating one sir ~~ Thanks for having paid attention to my post

Well, many people forget that Bitcoin is an investment as anything else(like stocks, bonds, real estate etc).
If Bitcoin goes to zero, only the guys who invested everything in Bitcoin will be hit hard. If they diversify, and have lets say 10% of their capital in Bitcoin- it won't be such a big deal, as 10% isn't really that much :)

Well, that depends on how much money they've invested in Bitcoin as well as Altcoins. But who the hell on earth "all in" one sector right ? LOL


text:
Where do you buy Dogecoin from?
Interested in putting 10$ on a few random coins of the more popular variety, just for the fun of it.
Never had any connection to crypto, so absolutely no idea how this works.
Where can I go, create an account and grab some Dogecoin, without getting scammed or landing on dubious/malicious websites/apps ?
I have zero interest in Bitcoin.

Here is the list of Doge exchanges: https://coinmarketcap.com/currencies/dogecoin/markets/
Google some of them and add "credit card" to your query.
It may involve buying BTC and selling your BTC for Dogecoin on the same website.


text:
Get the historic circulated suppy
I'm looking for the historic circulated supply of Bitcoin.  I'm aware I can get the current supply by creating my own node.  But I need the supply at a given date.
Does anyone know of an API to get it.

Does this answer your question? How can I verify the BTC supply with my own node?

@Saxtheowl No, I can find the current supply, I need the historic suppy


text:
To be more energy efficient, wouldn't be a consensual fork - right now - without the reward of new mined btc for each block helpful?
As the reward is lower, less effort is spend in mining new bitcoins. How the transactions fees will evolve would be quite crucial the get the miners activity down (and their energy consumption). I would assume that the transactions fees would stay at very low levels, because every miner has always an incentive to add any transaction with a positive fee.
Additional question: For sure there are some cryptocurrencies which reached that state (of no mining new coins). How did the transaction fees evolve after mining the last coin?

I would assume that the transactions fees would stay or converge to be very low levels, because every miner has always an incentive to add any transaction with a positive fee.

Block space is finite, so users are bidding for their position within the next block. Miners will always choose the transactions which have the highest feerate because it makes their income the highest. Today the fee rate often makes up a significant ($100k+ USD) portion of the total block reward.

https://mempool.space/

How the transactions fees will evolve would be quite crucial the get the miners activity down (and their energy consumption).

Mining activity would reduce naturally if there was less reward, but there's no opportunity for changing core principles of Bitcoin like this.
As a valuable currency Bitcoin needs to be predictable and justifiable, if the rules dramatically changed it would make a fairly lousy currency. You wouldn't be able to invest in mining hardware for example, if you couldn't model even the base income a couple of months into the future. Making even small changes to the economics of the system opens the floodgates for others. ultimately.

For sure there are some cryptocurrencies which reached that state (of no mining new coins). How did the transaction fees evolve after mining the last coin?

There's no useful comparisons to be made, nothing has the scale, maturity, and properties of Bitcoin.

You are right, finite block size means that the not any positive fee would be enough for miners to put the transaction into the block, but that's already the case right now. Still the reduction of the reward would have a negative effect on miners activity. No price change in fees would be expected.

Great reply, still I wont accept it as  answer, you are right in pointing out the boundedness of transactions in a block and the price implications thereof. Still, reducing the reward would reduce the effort spend on the creation of new blocks, without harming transaction flows or the incentive system, which was the base question.

I wasn't sure what the question was in the beginning, it's been updated.

What this means is that going forward the cost of securing currency will keep increasing and it will be difficult to transact in smaller denominations, it will turn into asset that just can not be transacted at smaller sizes, will not really be a payment instrument.
I think to keep security but allow for higher transactions by increasing block size to allow significantly large transactions, possibly 65K per block, should make it viable for longer term.
Right now it is very difficult to confirm small transaction unless fee is more than transaction value.

Ignoring the practical difficulty of making any such radical change to bitcoin, there would be profound negative consequences from such a change. Eliminating the block reward would almost certainly make mining less profitable.
After all, the block reward is a huge part of mining revenue. Eliminating the block reward would eliminate that portion of the revenue. There doesn't seem to be any obvious reason to expect it to be possible for transaction fees to be able to increase to compensate.
Bitcoin's security is dependent on how much it would cost to create a longer chain. If miners make less money in aggregate, they will do less hashing in aggregate. That means it would cost an attacker less money to outmine the miners. This means bitcoin would be more vulnerable to 51% attacks.
Now, consider two numbers:
X = The cost to attack bitcoin
Y = The amount of money you can make by attacking bitcoin
If Y ever exceeds X, bitcoin breaks. You are suggesting reducing X. That necessarily means that either somehow Y will have to be reduced as well, something else will have to be done to increase X, or both.
How can X be increased? Probably only by waiting for more confirmation and slowing down the blockchain. But that won't be enough by itself.
So how can Y go down? Effectively, it has to mean that the value of bitcoin and the value of the transactions that occur on the chain have to go down. If the whole bitcoin ecosystem is only churning $1 million a day, an attack will be much less lucrative than one that is churning $1 billion a day.