text:
Non-standard transaction scripts broadcasting
I'm developing an application on Bitcoin blockchain, and I use output transaction scripts that are not standard according to the classic payment methods.
However, even so, on Tesnet everything works fine but I recently read on Bitcoin site the following:

So, appearently, Tesnet may relax some restrictions on transaction scripts, but it doesn't specify much more. So, now, I have no way of knowing if such output transaction scripts could be accepted on the Mainnet, except by buying some Bitcoins with money that I really don't have, and I'm also starting to wonder what is the purpose of the Testnet if its behaviour doesn't reflect the one of the real net and, even worse, what is the purpose of having a script language with such multiple instructions when you can actually use just a few of them.
Is someone able to give me more informations about all this?
Thanks in advance.

Standard output scripts are defined by IsStandard() (which calls Solver() to perform the actual script matching). The standard output scripts are as follows:

P2PKH
P2PK
P2SH
P2WPKH
P2WSH
A script beginning with an OP_RETURN and only pushes at most 80 bytes data to the stack
Bare multisig up to a 3-of-3 multisig

Any other script will be non-standard and the entire transaction will be rejected as being non-standard.

Instead of trying to include a non-standard output script, you can instead use P2SH or P2WSH. Your output script will become the redeem script or witness script which can be anything. P2SH and P2WSH allow you to do exactly the same things as if the script were in an output script.
If you still insist on wanting your non-standard script to be in the output, then for your transaction to be broadcast and mined, you will need to find a miner and give them your transaction through some other means. Non-standard transactions will not be relayed and most nodes will not accept them. You will need to give your transaction to a miner who is accepting non-standard transactions, and it is highly likely that you need to do this out of band, i.e. over some form of communication that is not the P2P network.

Thank you very much for your exhaustive answer. The fact that I can't use P2SH is because this requires the redeem script to be known by the sender (so he can include the hash in the output script) and the receiver. In my setting, instead, the redeem script is known only by the sender.

That doesn't really make sense. How does the receiver know he's being paid if he doesn't know what output script to look for?

@AndrewChow you are saying just use P2SH instead of any non-standard script... but then the redeem script will be non-standard, right? Or is ANYTHING considered valid in a redeem script?

@ZMitton Any redeemScript is valid. There are no standardness checks on the input script type.

You can always wrap your non-standard output scripts in p2sh/p2wsh output scripts, which will be recognized for standardness and propagated by nodes on the network.

The fact is that I can't use P2SH, because I need my non-standard script to be placed into an output script. With P2SH I have to place it into an input script.

What do you mean saying "I need my non-standard script to be placed into an output script"??? You can not today put your arbitrary script into the transaction outputs. But you can achieve the SAME goals using p2sh/p2wsh - they were designed/implemented for this case!

Yeah, I figured as much. However, Testnet allows me to do that.


text:
How to determine how many transactions are being processed by the lightning network?
Is there a way to get an estimation of how many transactions are being currently (last hour or last 24h) processed by the lightning network? And by a specific node?

Yes, that is possible. If you operate all nodes in the network :)
If you are interested in a specific node, performing an effective sybil attack will also allow you to determine number of transactions which are routed through or initiated by that specific node.
Other than that, there is no way to accurately determine transaction rate of the network, as only channel capacity is publicly broadcast.

No. You can only estimate some bounds on that number, but they will be nowhere near reality. You can only say how many transaction your node processes. But you cannot say anything about other nodes, unless you are participant in all of their channels as well (or at least some, to get better bounds estimations). So, you can ask the node owners to give you that information. But they can lie to you. It is also unlikely that many owners would share such an information to protect their privacy.

source: Stack Exchange

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

sort: votes


text:
get extended public key from extended private key in python
Can anyone tell me how I can get the extended public key from an extended private key in python. I know that I need to get the public key from the private key and that the public key + chain key = extended public key. I already have the public key in multiple forms but I don't know which one to use.
Extended Private Key:                    961901f50868df03db40e0a29d40092b3fc26f47a1c20540d1440be1cd70edbef9c82ec85c4f90a24a1f7a4f1de97ddf762bcb20142b12e9b6c3e348e5519b74
Private key:                             961901f50868df03db40e0a29d40092b3fc26f47a1c20540d1440be1cd70edbe
Chain Code:                              f9c82ec85c4f90a24a1f7a4f1de97ddf762bcb20142b12e9b6c3e348e5519b74
PREPENDED:                               80961901F50868DF03DB40E0A29D40092B3FC26F47A1C20540D1440BE1CD70EDBE
PRIV_UNCOMP+CHECKSUM:                    80961901F50868DF03DB40E0A29D40092B3FC26F47A1C20540D1440BE1CD70EDBE223FDFAE
Private_key_WIF_uncompressed_Base58:     5JxPdEGBsaP14hBpr3swh2GZeXctQdLn9ZvjyFEj6diN742em4R
PRIV_COMP+CHECKSUM:                      80961901F50868DF03DB40E0A29D40092B3FC26F47A1C20540D1440BE1CD70EDBE0151EA0003
Private_key_WIF_compressed_Base58:       L2FUruY2zEL7HJNnBVhrPebh6e9PuHQJGpLCfFqaos3a9eeosKVL
('5JxPdEGBsaP14hBpr3swh2GZeXctQdLn9ZvjyFEj6diN742em4R', 'L2FUruY2zEL7HJNnBVhrPebh6e9PuHQJGpLCfFqaos3a9eeosKVL')
Private key hex string:                  961901F50868DF03DB40E0A29D40092B3FC26F47A1C20540D1440BE1CD70EDBE
Private key bytes:                       b'\x96\x19\x01\xf5\x08h\xdf\x03\xdb@\xe0\xa2\x9d@\t+?\xc2oG\xa1\xc2\x05@\xd1D\x0b\xe1\xcdp\xed\xbe'
Verifying key, x and y points (bytes):  b'E.1\xc8Z\x02\xf6\x1e$\x9d\xf1\xcf\xc3\x10\x8ff\x06\x14U\xceL3\xf8\xabO\xbf\x1cr\xe4\xf6\xf1\x1cm\xb9\xc3\x16\xed6\xbb\x0c\xe4\xeaQ\x1b^W\xde\x8d\xd5\xac\x822Z\xea\xcb#\x82\xf1\xda\xb8\x12\xfd\x8f\xa9' <class 'bytes'>
Uncompressed private key (hex):          04452E31C85A02F61E249DF1CFC3108F66061455CE4C33F8AB4FBF1C72E4F6F11C6DB9C316ED36BB0CE4EA511B5E57DE8DD5AC82325AEACB2382F1DAB812FD8FA9
Compressed private key in (hex):         02452E31C85A02F61E249DF1CFC3108F66061455CE4C33F8AB4FBF1C72E4F6F11C
Public compressed key (hex):             13w1yEAhhMGk6E5UU2wGQyy7pP14K1q2tg
Extended Public Key:                     ?

Thanks!

From BIP32:

We represent an extended private key as (k, c), with k the normal
private key, and c the chain code. An extended public key is
represented as (K, c), with K = point(k) and c the chain code.

point(p): returns the coordinate pair resulting from EC point
multiplication (repeated application of the EC group operation) of the
secp256k1 base point with the integer p.
ser256(p): serializes the integer p as a 32-byte sequence,
most significant byte first.
serP(P): serializes the coordinate pair P = (x,y) as a byte
sequence using SEC1's compressed form: (0x02 or 0x03) ||
ser256(x), where the header byte depends on the parity of
the omitted y coordinate.

Extended public and private keys are serialized as follows:

4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)
1 byte: depth: 0x00 for master nodes, 0x01 for level-1 derived keys, ....
4 bytes: the fingerprint of the parent's key (0x00000000 if master key)
4 bytes: child number. This is ser32(i) for i in xi = xpar/i, with xi the key being serialized. (0x00000000 if master key)
32 bytes: the chain code
33 bytes: the public key or private key data (serP(K) for public keys, 0x00 || ser256(k) for private keys)

This 78 byte structure can be encoded like other Bitcoin data in
Base58, by first adding 32 checksum bits (derived from the double
SHA-256 checksum), and then converting to the Base58 representation.
This results in a Base58-encoded string of up to 112 characters.

Thus the extended public key (xpub) can be derived from the extended private key (xprv) as follows:

Convert the xprv from Base58 to bytes and extract the private key from the last 33 bytes (ignoring the checksum).
Calculate the public key from the private key as per point(p).
Serialize the result:

4 bytes: 0x0488B21E (mainnet) or 0x043587CF (testnet)
41 bytes: depth, parent fingerprint, child number and chain code are the same as in the xprv
33 bytes: public key serialized using serP(K)

Add the 4-byte checksum and convert to Base58.

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


text:
Most common derivation Paths, accounts and indexes
can anyone tell me what the most used derivation paths are? Someone on reddit wrote that coinbase use this path: m/44'/0'/0'/0/0. Do other companies use the same path?
Also do big companies always start generating keys/addresses from account 0 and index 0 aka as on the picture from learnmeabitcoin.com the coin type (is default 0 for bitcoin?), account 0, receiving 0 and key generation from index 0?
My last question is what the "Change" structure is used for? As I understand "Receiving" is for receiving coins but I have no idea what the other one means.

BIP44 defines a standard path scheme:
m / purpose' / coin_type' / account' / change / address_index

The BIP defines what coin type, account, change and address index mean. It further specifies that the purpose field is set to 44' when generating addresses and for bitcoin the coin type is set to 0'.
At the time when it was written, the only standard address type was P2PKH (addresses starting with 1). Over the years, more standard derivation paths were added:

BIP49: P2WPKH-nested-in-P2SH (addresses starting with 3). The purpose field for these is 49'.
BIP84: P2WPKH (addresses starting with bc1q). Purpose field is 84'.
BIP86: P2TR (addresses starting with bc1p). Purpose field is 86'.

You can check the website https://walletsrecovery.org/ that maintains a list of wallets and which derivation paths they support. As you can see, modern wallets mostly implement the mentioned standard paths (although apparently the website hasn't been updated for BIP86).


text:
Hardware crashed, Bitcoin core won’t load
I can’t believe this hasn’t come up multiple times.
My hardware crashed (actually locked up and could only be unlocked by a forced (unplug) power off) while Bitcoin core was running. Of course on restart various files will/can not load. Specifically (it seems) settings.json.
Tried to delete the entire Bitcoin-23.0 file but permission denied.
Running Ubuntu OS.

What does it tell, when trying to start Bitcoin?

Settings file could not be written.  (New Paragraph) A fatal error occurred. Check that settings file is writeable, or try running with -nosettings.  <<Show Detail . . .>> " - Error: Unable to open settings file /[path]/Bitcoin/settings.json.tmp for writing"

interesting data directory, where did you get that software copy? you can work around the problem by solving the permissions problem you pasted

I manually set up the directory because that's where the blocks were stored (from a prior install). My question is HOW to "solve" the permissions problem.


text:
Bitcoinqt 2009-2010
Im not asking if you can recover an account without phrase of wallet.dat file
I have several questions however
First what payment service did bitcoin qt first use, i remember i had to use debit and credit cards
My main is question is this, Does bitcoin core wallet have financial records from origination date of bitcoinqt
The leading point is i want to argue that despite policy they must have an actual record of who bought what bitcoin almost positive that i had to enter my name into the payment service and other info when buying
And you know its terrible knowing like 5-8 words of the passphrase 12-13 years later
Btw im not trolling im wondering if bitcoincore is willing to allow queries and tracking down financials would be a lot easier if i knew the third party service
Thanks not here to waste anyones time

Bitcoin Core never had a marketplace or exchange functionality, nor did it ever use a mnemonic seed. You might be thinking of blockchain.com instead.

Bitcoin-Qt didn't exist until the end of 2011, and the name Bitcoin Core has only been in use since 2014.

What you seek does not exist.
Bitcoin is electronic cash. I find it often helps to think about paper cash when considering some aspect of Bitcoin.
The makers of leather wallets, say Gucci, do not maintain records of what paper banknotes you put into the leather wallet or where you spent them. You cannot ask Gucci where you got your money from or where it is now.
SImilarly Bitcoin Core developers do not and can not keep records of what you do with a Bitcoin core wallet. It is actually of paramount importance that they are unable to know what you do.

what payment service did bitcoin qt first use, i remember i had to use debit and credit cards

None.

Does bitcoin core wallet have financial records from origination date of bitcoinqt

No organisation, group or other person has any financial records relating to your use of "Bitcoin Core" software (such as bitcoin-qt).
Your wallet, if maintained continuously, has a record of your financial transactions stored locally on your device.
Each node in the global Bitcoin network has a copy of the blockchain (or access to a copy). Which includes every financial transaction carried out directly using the Bitcoin network. But they don't know which transactions relate to a specific named person.

The leading point is i want to argue that despite policy they must have an actual record of who bought what bitcoin

Untrue. The people who develop an maintain Bitcoin core don't have any special records that are not public and already known or available to everyone worldwide.

im wondering if bitcoincore is willing to allow queries.

The people who develop and maintain Bitcoin core don't have any relevant records. There is nothing to query. All their work is public so far as I know.

and tracking down financials would be a lot easier if i knew the third party service

Knowing where you bought something is usually no help whatsoever in knowing where you put it or where and when you sold it.


text:
How do I find my b64secret from GDAX API?
How did I find the b64secret that is automatically generated by GDAX API? I have a passphrase and API key that I got from GDAX, but I don't know what/where the b64secret is. The documentation says that the secret will be randomly generated and provided to me. I have read the documentation and also the exact same question here, but the answer did not help and only directed me to the documentation. I hit create keys but I never saw the secret.
So for someone that has actually done this before, how do I find/get the b64secret?
I originally asked on SO but it wasn't answered, and I didn't find the same question after a very brief search on here.


text:
Why bitcoind will shutdown after encryptwallet?
As mentioned in the bitcoin-cli document for encryptwallet command, bitcoin daemon will shut down after encrypting a new or unencrypted wallet. My question is about the reason for shutting the node down?
Also, I want to create another bitcoin wallet and it's very strange if I need to start after adding a new wallet. this pull request tried to remove shutdown after encrypting a wallet. is it safe? and what's the best way to deal with this problem?

encryptwallet "passphrase"
Encrypts the wallet with 'passphrase'. This is for first time
  encryption. After this, any calls that interact with private keys such
  as sending or  signing
will require the passphrase to be set prior the making these calls.
  Use the walletpassphrase call for this, and then walletlock call. If
  the wallet is already encrypted, use the walletpassphrasechange call.
  Note that this will shutdown the server.

This behaviour has been resolved by 12493. As stated by Andrew Chow in the pull request, this was previously done to:

...prevent the BDB environment from
  writing unencrypted private keys to disk in the database log files, as
  was noted here. This PR replaces the shutdown behavior with a CDBEnv
  flush, close, and reopen which achieves the same effect: everything is
  cleanly flushed and closed, the log files are removed, and then the
  environment reopened to continue normal operation.
To ensure that no unencrypted private keys are in the log files after
  encrypting the wallet, I wrote this script to pull private keys from
  the original wallet file and searches for these keys in the log files
  (note that you will have to change your file paths to make it work on
  your own machine).
As for concerns about private keys being written to slack space or
  being kept in memory, these behaviors no longer exist after the
  original wallet encryption PR and the shutting down solution from
  2011.


text:
0.00603581 is in my bit coin wallet how much do I own?
If I have 0.00603581 in my bitcoin wallet who much do I accually own ?

You own every bit of it. Assuming you have the private key for the wallet. As far as the blockchain network is concerned, anyone with the private key is the "owner" and will transfer those funds if the correct private key is provided in the transaction request.
As long as your private key remains private and you know what it is, you own it.
Now, to send that Bitcoin somewhere else, you'll have to pay a fee. That's why miners mine the blocks. So while you (assuming above conditions are satisfied) "own" every Satoshi inside that wallet, you'll need to pay to move it somewhere else.
Note: Nuances, subjective considerations and opinions have all been crushed for the sake of brevity.

You own the same 0.00603581 BTC or 603,580 satoshis
1 BTC= 100,000,000 Satoshis


text:
Transaction Relay and trickling in Bitcoin
If a node has 100 connections to other nodes and receives a new transaction using a getData request, it sends an inv message to it's 100 connecting peers correct?
Does it also send the inv message to the peer that it just received the transaction from as it is still one of it's connecting peers?
'Messages, in general, are flushed periodically about every
100 ms. However, transaction relaying takes place by “trickling” messages out. Bitcoin randomly selects with a probability
of 1/4 the transactions for an inv message and stalls the remaining transactions. Every neighbor gets a different set of randomly
chosen transactions, each about 1/4 of the currently available
set. Only the randomly selected “trickling node” (cf. addr
message relaying) gets all transactions immediately. The other
neighbors either get it later or already got it from another neighbor. Trickling reduces the overhead and at the same time makes
traffic analysis more difficult, in a similar manner as mixes do
in mix networks.'
I'm having a bit of difficulty understanding how trickling works in terms of transactions. I believed that the process was when a transaction occurs, the node responsible for the transaction would send INV messages to its peers and send the tx if the peers respond with getData.

If a node has 100 connections to other nodes and receives a new transaction using a getData request, it sends an inv message to it's 100 connecting peers correct?

No. It depends on what nodes have sent an inv stating that they have that transaction. When an inv is received, the node will remember what has been inv'd to them by that node so that it does not attempt to send it something it already has. At most, there will be 99 inv messages sent. Since we already know that the peer that sent us the transaction already has it, we don't send them an inv. At minimum, there will be no inv messages sent because all nodes could have already sent us an inv for the same transaction.

Does it also send the inv message to the peer that it just received the transaction from as it is still one of it's connecting peers?

As stated above, it does not. While there is no rule the explicitly prevents this, it is sensible to not send an inv to someone who has already sent an inv to you for the same thing. This saves bandwidth costs.

I'm having a bit of difficulty understanding how trickling works in terms of transactions.

For each peer, the node keeps a list of transactions that it is going to inv to it. It sends inv's for transactions periodically with a random delay between each inv. Transactions are selected to go into the inv message somewhat randomly and according to some metrics involving fee rate. It selects a limited number of transactions to inv.

I believed that the process was when a transaction occurs, the node responsible for the transaction would send INV messages to its peers and send the tx if the peers respond with getData.

The node the creates a transaction treats that transaction like any other it received over the network. For every peer that node is connected to, it adds that transaction to the list of transactions that it will send to that node eventually. Then everything else is as usual. At the next time it is to send an inv message for a particular peer, it chooses transactions to inv, and the transaction it created may or may not be one of those. Once the inv is sent, the other node will respond with a getdata for the things it wants, which may or may not include the transaction it created. Then your node responds to the getdata with the transactions themselves.

Thanks a lot for your detailed answer. So if I understand this correctly, nodes will not sent an INV message to peers that it knows already has the transaction (i.e the peers that have already sent this node an INV to the same transaction). And when a node wants to send an tx INV to it's peers, it adds it to an already existing list of transactions that it wants to send to that specific peer. When it does send eventually, does this INV message contain multiple txID hashes or is it an INV per txid hash?

When it does send, the inv should contain multiple txids. However, it is possible (and perhaps likely), that by the time it does send an inv, there are only one or two txids for it to send.

It may be worth pointing out that the quotes in OP's question are outdated (they refer to the old trickling mechanism which was replaced with poisson-distributed batches a few major releases ago in Bitcoin Core).

What happens to txs that don't fit local mempool, everyone keeps them circulating (receiving and transmitting again because they are not seen)?

@VincentAlex Transactions that are not added to a node's mempool are not relayed by that node. Transactions that are added to a node's mempool are not relayed more than once. So transactions that cannot get into mempools just do not get relayed. They do not keep circulating unless someone intentionally rebroadcasts it.

it sends an inv message to it's 100 connecting peers correct?

to 99

Does it also send the inv message to the peer that it just received the transaction from

it is allowed, but there is no reason to do it

the node responsible for the transaction would send INV messages

no one is responsible for anything

Why does it send only to 99 instead of the 100 peers? If I'm a node who just retrieved a transaction, I send an INV to all my peers about it don't I - even the one who just sent me the data unless there was a way I kept track of who sent it to me so I won't send the INV to that node

This does not answer the question, which is about the practical implementation of the tx relay protocol, not about what modification nodes are allowed to make to it


text:
Possible better peer-to-peer protocols for Bitcoin?
As we know, bitcoin uses flooding in order to propagate blocks and transactions across all the nodes in the network. As it was launched in 2009, it's been almost 10 years since it's launch and I was wondering if it was launched today, would it be able to use a more efficient P2P protocol/algorithm then the flooding mechanism employed today? As flooding can cause multiple transactions, albeit inv transactions, to be sent to the same node multiple times which is information that the node does not need and is unnecessary. Are there any better state-of-the-art p2p protocols that could be a better fit for bitcoin today?

The network used today isn't actually the same as the original design, which did not have an inventory system at all, every transaction and every block was sent to every peer indiscriminately. Compact Blocks was also added to remove redundancy in block transmission and reduce latency, as blocks predominantly contain transactions which have already been forwarded around the network previously. Fee based filtering was added to allow nodes to request that peers to not send transactions which will be rejected regardless, which saves bandwidth.
The P2P protocol, while not ideal, is relatively functional in its current state. It is an unusual set of requirements (flooding, censorship resistance, sybil avoidance) which doesn't have much simularity to many other systems.


text:
Monitor bitcoin transaction confirmation timestamps
Well, i'm planning on developing a graph that shows bitcoin transaction average confirmation time per hour , but i have no clue where i can get transaction confirmation timestamps.
I'm running bitcoin core node with whole blockchain and sync up to date.
Any ideas ?

The time at which a transaction was confirmed can be found in the 4B timestamp in the block header (POSIX time encoding)
To compute average transactions confirmed/hour, you can consider the header timestamp and the number of transactions in each block in your considered timeframe. The first byte following the header represents the number of transactions in the block. However, you may want to exclude the coinbase tx from the transaction count for your purposes.
If you wish to compute the time between broadcasting and confirmation of a given transaction, you must have knowledge of when a transaction was specifically broadcast. Since this is only the case if you broadcast a tx yourself, you cannot compute this exactly. You can however, determine when a tx was first accepted to the mempool of your local node, and use that as a proxy. Bitcoind offers a tx subscription service which publishes newly accepted mempool txs over a zmq interface. By indexing these with local timestamps(time of mempool acceptance), your application can later determine the time passed to the confirmation of a previously indexed tx from a block which includes this tx and the block header timestamp.

Worth to note that the 4 byte timestamp in the block header isn't really an accurate description of when the block was actually broadcast to the network.

True though variances should average out over a large enough timeframe. Difficulty adjustment also based on timestamps.

Yea I was only mentioning because the required window in OP was one hour which is pretty short for relying on block times.  But I guess for historical data and less accuracy it's not bad.

Well guys this isn't quit what i was initially looking for, i was looking for a way on getting a bitcoin transaction confirmations timestamps, i.e. the first three confirmations timestamps, so i can analyse the avg time for each confirmation and monitor it network wise.


text:
Watch a BitCoin account for incoming payments
I want to watch a set of BitCoin addresses and be notified (preferably by email) when they receive a payment.
I prefer me not to write my own software for this and not to install it on my own server, but programming suggestions are welcome.

Without installing software on your own servers, the only way to accomplish this is with 3rd Party services. Some offer Email notification of payments via email.
blockcypher.com is an example of this.

You need a server which indexes by address. Libbitcoin-server provides this index. All tx’s to or from an address of interest will trigger a notification to your subscribing client.
https://github.com/libbitcoin/libbitcoin-server/wiki
Of course you can always build your own address index.


text:
Old Bit Coin Wallet Failing to Pass 180 Weeks
I have an old laptop that I have bitcoin wallet on. I left the computer alone since early 2015 and when I try to sync the bitcoin wallet, the wallet gets stuck on 180 weeks. the bitcoin wallet sync process just eats way at hard drive space and stays at 180 weeks. I free up over 70 Gb and it still just just eats at hard drive space.

What version of Bitcoin Core?  Older versions may not be compatible with the current blockchain.  I would back up your wallet.dat file, upgrade the software, and try again.

Note that the blockchain today is about 184 GB, and you will need more than that for the chainstate index, etc.  So 70 GB will not suffice.  However, with newer software, you can enable pruning to reduce disk usage.

First of all, backup your wallet.dat even if you are not going to do anything to the wallet.
I don't know if you are open to using other wallets, but you could recover your bitcoin by following these steps:

Unlock your wallet
Use the command dumpprivkey "YOURADDRESS" from the Bitcoin Core console
Import the private keys on a lightweight wallet such as Electrum (Warning: There was a scam message being shown in Electrum sometime ago)


text:
How to send bitcoin without any fees to different btc address?
Now I am using regular client wallet to spend my btc amount. but it charges me miner fee, sometime it pretty high. I dont want to pay fees anymore.
My friend heard about a way to send btc without any fees. In this point my questions are:

what is the demerits if I want to send btc without fees?
And Finally, How could I send btc to different address without paying any fees?

Ok, I am going through the post details


text:
What does the Sender of a Transaction include in the Input that allows the Recipient to Unlock/Redeem?
I have been struggling to grasp what exactly is included in the input of a Transaction that allows the intended recipient to then redeem/unlock that UTXO when they are ready to do so.
I understand that a transaction contains a Digital Signature created by the Senders Private Key on the message.
I become confused when trying to understand what data the sender includes in the Transaction that allows the recipient to unlock that UTXO and turn it into a subsequent input when they choose to do so. Is the Sender including the Recipients Public Key in the Transaction allowing them to use a scriptSig to unlock that UTXO?
Thanks for taking the time out help

The transaction output has a property called the scriptPubkey that is executed with the scriptSig when the output is spent in a transaction. An understanding of Bitcoin script would help.
Bitcoin Script
Bitcoin uses it's own stack-based scripting language with a set of op-codes. This scripting language is used to determine whether an unspent transaction output (utxo) can be spent. When you send Bitcoin, you are really just assigning a Bitcoin value to a script, which can be spent only if the script executes successfully and results in a single true value on the stack. The script that is assigned to the Bitcoin transaction output is called the scriptPubKey. To satisfy the script, you must provide the correct scriptSig, which is also a script, which is prepended to the scriptSig and executed to test if the spending succeeded. Let's look at an example:
scriptPubKey (raw): 76a914306e2ea1eed91bf66dfe5d94f3957d4ba63bde8488ac
scriptPubKey (assembly): OP_DUP OP_HASH160 306e2ea1eed91bf66dfe5d94f3957d4ba63bde84 OP_EQUALVERIFY OP_CHECKSIG
In plain english, this script, when executed will do the following:

OP_DUP: Duplicate the top item on the stack (place a copy of it on the stack)
OP_HASH160: Pop the top item off the stack, calculate it's HASH160, i.e. the  RIPEMD160(SHA256()), and place that on the stack
OP_EQUALVERIFY: Pop the top 2 items off the stack, and if they are not equal, it will exit immediately and fail, otherwise nothing
OP_CHECKSIG: Pop the top 2 items off the stack, and use the top as the public key, the second as the signature, and verify the transaction signature

In order to spend this output, we must provide a valid signature and public key. We'll just provide 00 for the signature for this example, and not worry about the final checksig op.
Example
Let's visualize this example with a scriptSig. Let's use kallewoof's btcdeb Script visualization tool. After the first command, you can type step once, and then just press enter each time after that to step through each operation:
$ btcdeb '[00 030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046 OP_DUP OP_HASH160 306e2ea1eed91bf66dfe5d94f3957d4ba63bde84 OP_EQUALVERIFY OP_CHECKSIG]'

btcdeb -- type `btcdeb -h` for start up options
valid script
7 op script loaded. type `help` for usage information
script                                                             |  stack
-------------------------------------------------------------------+--------
0                                                                  |
030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046 |
OP_DUP                                                             |
OP_HASH160                                                         |
306e2ea1eed91bf66dfe5d94f3957d4ba63bde84                           |
OP_EQUALVERIFY                                                     |
OP_CHECKSIG                                                        |
#0000 0
btcdeb> step
        <> PUSH stack
script                                                             |  stack
-------------------------------------------------------------------+--------
030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046 |      0x
OP_DUP                                                             |
OP_HASH160                                                         |
306e2ea1eed91bf66dfe5d94f3957d4ba63bde84                           |
OP_EQUALVERIFY                                                     |
OP_CHECKSIG                                                        |
#0001 030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046
btcdeb>
        <> PUSH stack 030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046
script                                                             |                                                             stack
-------------------------------------------------------------------+-------------------------------------------------------------------
OP_DUP                                                             | 030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046
OP_HASH160                                                         |                                                                 0x
306e2ea1eed91bf66dfe5d94f3957d4ba63bde84                           |
OP_EQUALVERIFY                                                     |
OP_CHECKSIG                                                        |
#0002 OP_DUP
btcdeb>
        <> PUSH stack 030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046
script                                                             |                                                             stack
-------------------------------------------------------------------+-------------------------------------------------------------------
OP_HASH160                                                         | 030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046
306e2ea1eed91bf66dfe5d94f3957d4ba63bde84                           | 030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046
OP_EQUALVERIFY                                                     |                                                                 0x
OP_CHECKSIG                                                        |
#0003 OP_HASH160
btcdeb>
        <> POP  stack
        <> PUSH stack 306e2ea1eed91bf66dfe5d94f3957d4ba63bde84
script                                                             |                                                             stack
-------------------------------------------------------------------+-------------------------------------------------------------------
306e2ea1eed91bf66dfe5d94f3957d4ba63bde84                           |                           306e2ea1eed91bf66dfe5d94f3957d4ba63bde84
OP_EQUALVERIFY                                                     | 030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046
OP_CHECKSIG                                                        |                                                                 0x
#0004 306e2ea1eed91bf66dfe5d94f3957d4ba63bde84
btcdeb>
        <> PUSH stack 306e2ea1eed91bf66dfe5d94f3957d4ba63bde84
script                                                             |                                                             stack
-------------------------------------------------------------------+-------------------------------------------------------------------
OP_EQUALVERIFY                                                     |                           306e2ea1eed91bf66dfe5d94f3957d4ba63bde84
OP_CHECKSIG                                                        |                           306e2ea1eed91bf66dfe5d94f3957d4ba63bde84
                                                                   | 030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046
                                                                   |                                                                 0x
#0005 OP_EQUALVERIFY
btcdeb>
        <> POP  stack
        <> POP  stack
        <> PUSH stack 01
        <> POP  stack
script                                                             |                                                             stack
-------------------------------------------------------------------+-------------------------------------------------------------------
OP_CHECKSIG                                                        | 030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046
                                                                   |                                                                 0x
#0006 OP_CHECKSIG

You can play around with this using any of the opcodes listed at Script.


text:
Do you really need more than 50% mining power in order to attack Bitcoin blockchain?
My question is about concept, so code is not related, however, do you really need 51% of the mining power in order to attack/replace the real bitcoin Blockchain?
For example, a blockchain has a length of 8, A, B, C, D, E each represent a individual with 20% of the total mining power, let's say person A and B decide to work together, but that's only 40% of the total mining power (less than 51%), for illustration purpose, miner C, D, E will always mine alone, so by the time miner C, D, E each finished mining the 9th block, A and B have already mined the 11th block (assuming they mine faster, since they work together and have a total mining power of 40%), so longest chain wins right? and now the 9th block that miner C, D, E just mined becomes invalid and their chain will be replaced to the longer blockchain, does this mean A and B might have the power to control and manipulate the entire bitcoin Blockchain with only 40% of the mining power as long as the rest of the network don't work together? if so, then bitcoin is not really safe, because most of the time there is no way for small individuals to work together, it's like owning a company, you don't have to be holding 51% shares in order to be in charge of the company, you can do it with just 2% as long as the rest of share holders each hold less than 2% and don't work together against you,
So my ultimate question is, does bitcoin network have a way to force the rest of the share holders to join forces? Therefore you need a true 51% to control/manipulate it or is it like a company?

A majority attack (51% attack) was given this name for a reason: in order for the attack to succeed on average, the attacker needs 51% of the hashpower.
Reading your question, I can see a misunderstanding of how mining works, in that you postulate two miners working together with 40% of the hashpower will outcompete 3 miners with 20% of the hashpower each (ie, 40% > 20%). This is false.
Bitcoin mining is a memory-less process. This means that any single block header a miner creates has an equal chance of creating a valid hash - there is no advantage to having more hashpower, other than being able to make more guesses per second. A miner does not 'make progress' towards finding a new block, each hash is either valid, or not.

An example using dice
As an example of a memory-less process, consider the act of rolling some dice.
Lets consider a situation in which each di has 100 sides, and only 1 of those sides is considered a 'valid roll'. If there are 100 such dice in existence, and each of them is rolled once per second, then probability leads us to expect one valid roll per second.
Now, lets consider your situation, in which 5 people each have 20 of the dice. We can see that, even if two people 'roll together', they will still only roll a 'valid roll' 40% of the time, whereas the other three people will roll a 'valid roll' 60% of the time, regardless of whether or not they are 'working together'.

Likewise, in your example we can see that the three miners with 60% of the hashpower will, on average, find more blocks than the two miners with 40% of the hashpower. This is simply because (20 + 20 + 20) > 40.
This may lead you to the question "then why would miners work together?" The answer is that by working together (using a 'mining pool'), a miner can expect less variance in their payout. See this answer for more info, and this answer is relevant as well.

thank you very much for the answer , however, why do u need at least %51 of the total hushing power, could it be less in reality? if you mine an empty block u mine much faster right? and if you mine only the empty blocks secretly without broadcasting it, is it possible for your own secret  blockchain to still be longer than the real bitcoin blockchain with just %40 of the total hashing power? therefore replace the real blockchain once you broadcast it?

my question is, receiving these blocks from the network with all these open transactions take time right? also you need to broadcasting it and solving all these conflicts that could still be time consuming even if u do it asynchronously, but if you mine alone in secret, u don't need to do all that, u just mine one empty block after another, that's much more faster right? and eventually longer chain wins, so in reality is it truly not possible to hack the bitcoin network with only %40 of the hashing power?

back to your dice illustration, i don't think A and B are rolling the same dice as the rest of the network, miner C, D, E are mining the real blocks, miner A and B are mining empty blocks offline, by the time miner C D E each thrown a dice, miner A and B have both thrown the dice twice, because their dice is lighter and different than the real dice, therefore the %40 "doubles" becomes %80, does this make any sense?

@DADI no, mining an empty block is no faster than mining a full block. A & B are indeed rolling the same dice as everyone else. There are also transaction rewards to collect, which provide miners an incentive to fill blocks.


text:
Can The Redeem Script Consist Of Only 1 Public Key In P2SH Transactions:
I have a few questions relating to Bitcoin Signatures And P2SH:
Why is P2SH used as opposed to other forms? Is it still prevalent today - has SegWit made it redundant or less useful, if not, what is the most used signature format?
And mainly:
Can the P2SH redeem script consist of a single public key (hence only one person is creating the redeem script). What even is the redeem script?

Before the adoption of BIP16: Pay to Script Hash, multisig was possible, but only in the form of bare outputs. The multisig would be directly defined in the ScriptPubKey (the output script). This had three disadvantages. There was no address standard for encoding these flexible constructions, the resulting big output script had to be paid for by the sender but was for the benefit of the receiver, and the big output script would also cause the UTXO would be much larger than other UTXOs, which then would need to be stored by all full nodes until it got spent.
BIP16 introduced a level of indirection. Instead of directly encoding the condition script in the ScriptPubKey, the ScriptPubKey contains a P2SH Program which commits to one specific Redeem Script via a hash of it. The ScriptSig (the input script) provides the actual spending conditions in the form of the Redeem Script (matching the hash commitment in the output), and the script arguments to satisfy the Redeem Script.
The Redeem Script can contain any valid Script expression, including one that requires only the signature of a single key to spend. This construction would be less blockspace efficient than using a single-sig output type in the first place, though.
Since the P2SH Program always had a fixed length, it was easy to make an address standard for it, and the cost of the outputs was no longer as burdensome.

About 35% of all transaction outputs today are P2SH outputs with the majority encoding wrapped segwit outputs. We have more blockspace efficient output types now. Using one of P2WPKH, P2WSH, and P2TR it would be able to achieve any equivalent condition script using less blockspace.

Another disadvantage was that the sender had to bear (a significant) part of the cost for a decision made by the recipient (to receive coins on a multisig).

So who creates the scriptpubkey (unlocking script) and scriptsig (unlocking script). Is it the people who are receiving the Bitcoins or is the people who want to transact the Bitcoins?

@AntoinePoinsot: Great point, added

@Jamo: The receiver always decides how they'd like to get paid. They then communicate to the sender instructions how to pay them, usually in form of an address. The sender builds the transaction, so while the receiver defines the content of the ScriptPubkey, the sender creates it.


text:
Are there any blockchain implementations that are not based on the Bitcoin source code?
I wanted to code up a blockchain from scratch using C++. So I got around to looking at some existing blockchain source code to get some ideas. But all I can find is the Bitcoin source or forks of it.
Are there any blockchain implementations out there that are not based on the Bitcoin source code?

Ethereum and EOS jump to mind as largely independent codebases.


text:
Is altering Blockchain Wallet possible even after all the securities?
A man named James Bryan posted an investment plan and took BTC from me. On the day of payout, he asked me to simply fund my Blockchain wallet to receive the money. The minute I fund the wallet, he took all the money out even after all the securities on my wallet. How is this possible?

Did you allow 'James Bryan' to access your wallet, and then you changed the password afterwards? If so, you were scammed. The scammer logged in, and then copied your wallet seed phrase. With that phrase, they can recreate your wallet on another device, without any need to input your password. Do not EVER give your passwords, private keys, seed phrases, 2FA tokens, etc, to anybody you do not trust 100%. There is never any reason to do so, anyone asking for them is almost certainly attempting to scam you. Sorry for your losses.

Additionally, the scammer may have added a watch-only address to the wallet, allowing you to see the deposited coins, but allowing him to withdraw them without any action on your part

Is altering Blockchain Wallet possible even after all the securities?

The key thing to learn is that a scammer doesn't need to alter your wallet. They don't even need your wallet to exist, they can access money that was in a wallet that has even been deleted.

The minute I fund the wallet, he took all the money out even after all the securities on my wallet. How is this possible?

Bitcoin wallets don't contain any Bitcoin really. What they contain is a private-key that gives you the right to spend any Bitcoins that have been sent to a Bitcoin-address that is derived from that private-key.
The money is effectively stored in the blockchain, every "full-node" bitcoin wallet has their own full copy of the blockchain. Any wallet can spend money if they can prove they have the private-key for the bitcoin-address associated with the Bitcoin.
You can prove you own a private-key without disclosing it. That's the mathematical feature that makes Bitcoin possible.

The wallet-password or two-factor authentication only protects access to your copy of a wallet. By earlier giving someone temporary access to your wallet, they can copy from the wallet the private keys (or seed-phrase/recovery-phrase) that they can use to create another copy of the wallet.
Even if you change the password on your wallet, that doesn't affect other copies of the wallet.
If you put money into your copy of the wallet, that money appears in all copies of the wallet which contain the same private key. It doen't even matter if the copy was created before or after you put the money into your wallet.
Any of those wallets can spend the money you put in there. Once one wallet has spent the money, it disappears from all other wallets too.
You may think that calling this thing a "wallet" is misleading since it really contains no money. I'd agree. The inventors of Bitcoin needed a familiar name for a thing that controls access to money, that was the best they could come up with.
Maybe it is best to think of a wallet as a combined key-holder and accounting-ledger viewer.

So never share access to your wallet, even if it is empty at the time.


text:
Totally new to this - am getting tied in knots!
I have purchased £250 worth of Bitcoin - it is now siting in a Coinify account.  I have created my wallet using Electrum - how do I transfer from Coinify to my wallet?  And then what do I do?   Would very much apreciate some help and advice.  thank you

Welcome to Bitocin.SE! I do not have a Coinify account to be specific but if you want the coins in your wallet you need to get a receive address from your wallet and go to Coinify and send them there.

Rhank you for responding - I have resolved this now.


text:
Is www.soloxbit.com a legitimate exchange?
help is needed urgently.
I have been invited to use a crypto exchange called www.soloxbit.com by a telegram group. I signed up as there was a 50% bonus on my first deposit using their referral.
My money is now stuck in the exchange as a verification deposit of 0.02BTC is required to get a "USER" status in order to withdraw.
Can anyone here please tell me if the exchange is legit and if I should make the verification deposit just to take my money out?
Any help is appreciated, thank you.

You got yourself scammed. It's gone. Whatever you do, do NOT send any more as that will immediately be gone as well.

Does this answer your question? How to tell if a cryptocurrency exchange or trading platform is trustworthy?. The same question about soloxbit was asked a few hours ago: https://bitcoin.stackexchange.com/q/114925/13866


text:
Structure of a bitcoin transaction, in particular the link to the previous transaction
I'm reading 'Blockchain and distributed ledgers' by Alexander Lipton and Adrien Treccani.
I'm trying to understand how individual transactions are linked together.
On page 338, they give the 'details of a typical transaction in Block 400,000' (sorry I can't copy and paste text):

When I look at this transaction using https://blockchain.info/tx/928c4275dfd6270349e76aa5a49b355eefeb9e31ffbe95dd75fed81d219a23f8?format=json then this is what I see:
{
  "hash": "928c4275dfd6270349e76aa5a49b355eefeb9e31ffbe95dd75fed81d219a23f8",
  "ver": 1,
  "vin_sz": 1,
  "vout_sz": 1,
  "size": 191,
  "weight": 764,
  "fee": 100000,
  "relayed_by": "0.0.0.0",
  "lock_time": 0,
  "tx_index": 8730617388972831,
  "double_spend": false,
  "time": 1456417484,
  "block_index": 400000,
  "block_height": 400000,
  "inputs": [
    {
      "sequence": 4294967295,
      "witness": "",
      "script": "473044022100a98648381f405a6882989faa500147c7cb9f4ce03e912d18529fb3609e243a47021f798214efe634e8c47e158edae534f5652b98ce1bd3693fa95dcdd2c699d987012102bd63ab2a6215bdd16d554ea3fd5d83843bff9c76e0b8c6c150d58ee6ca7ea525",
      "index": 0,
      "prev_out": {
        "tx_index": 2867663739202288,
        "value": 321000000,
        "n": 5,
        "type": 0,
        "spent": true,
        "script": "76a914c53c08858049dccc686358e05a0371211fc77c5b88ac",
        "spending_outpoints": [
          {
            "tx_index": 8730617388972831,
            "n": 0
          }
        ],
        "addr": "1Jyt2ydxc9uTzHuj8DR8egqbLEwLa6kQPL"
      }
    }
  ],
  "out": [
    {
      "type": 0,
      "spent": true,
      "value": 320900000,
      "spending_outpoints": [
        {
          "tx_index": 8460568020598031,
          "n": 0
        }
      ],
      "n": 0,
      "tx_index": 8730617388972831,
      "script": "76a9142f58e6245481be77894d5f0f0e2641decdafc44788ac",
      "addr": "15KMFpvaHJLf26y7DkTFKjxijfYvAAdU2s"
    }
  ]
}

This seems to be somewhat different. In particular, there's no 'Prev. TXID' field. The previous transaction the book refers to (5180fff4155787703d10f03cca1566794516ac65a67764e571dc9c34931f321d) doesn't even seem to exist.
My question is: is there a way of figuring out which transactions are chained to which?

This seems to be somewhat different.

Blockchain explorers do not show the exact block structure. They usually add extra derived information that they consider helpful. I also find this misleading and often unhelpful.
You might find a different blockchain explorer to be more helpful (or at least unhelpful in ways that don't matter as much to you). For example See For developers Raw Tx in https://blockchair.com/bitcoin/transaction/928c4275dfd6270349e76aa5a49b355eefeb9e31ffbe95dd75fed81d219a23f8.

is there a way of figuring out which transactions are chained to which?

Yes. Each input of a transaction links that transaction to an earlier transaction identified by the previous transaction ID field ("Prev.TxId" in your example) in the data for each input.
So you can, for example, parse the BLK files created by Bitcoin core to list those links between transactions.
> blockchain -file blk02000.dat -block 1 -tx 572

Transaction Details in Hex (Decimal/Symbolic):
  Version:................01000000 (1)
  Inputs:.................04 (4)
  Input:1
    Previous Transaction:.3476B395124F8C339802EDEDBA2FDFE13D28AF4C28E67BABBFCCC27E18EF97C7
    Previous Output Index:0000 (0)
    Script Length:........6A (106)
    Unlocking Script:.....47304402205EE39EA72444ECB77D5448C6742CE17F4887AAFD30FE90E4E20147
                          823803E5AF022067D94E7AEE43C56221B403989D50BE40F1DB5A6073635E100F
                          96D8C2656798960121026B61AC29519038AECC2BB6E2F57FE9310B82D7E7873A
                          C5F4501B823C4D8E5B43
    Sequence:.............FFFFFFFF
  Input:2
    Previous Transaction:.DC9C065A1C610B13604C79925331F9762F08344E9330B11F9F5E938C3F46754B
    Previous Output Index:0000 (0)
    Script Length:........6B (107)
    Unlocking Script:.....483045022100CF78C34E882E39EC2F76FD47218195156030B2FDF93E1D854FD9
                          DA17FEB785AE02200ECBE9A6402F4C597970F3F9CDB8C3FC4A700C1D8B0CA29F
                          07C71A4EF00C372B01210363CFCE0BD0D8BF56AAE3388EF5928E4F2EEB032606
                          A9B17506948CDEB0A5D8A2
    Sequence:.............FFFFFFFF
  Input:3
    Previous Transaction:.EF59C004545977F125CD33905A6AD17A4F7C5E7E55B96B6740C8B850F1AC6705
    Previous Output Index:0000 (0)
    Script Length:........6B (107)
    Unlocking Script:.....483045022100F29055D9A3D8BB9DD5ADEDAE3E2BD071488790F11290866CC5B9
                          08B7738578A402204DBCED4D7787D8D174385BCB7563BC0E7B16016E70E7F1BD
                          C28702F75283AA6A012103F8F5D44539C2679C090034F369B52B1FD309A0520B
                          F6C91F5E0C7E78FE3C30D4
    Sequence:.............FFFFFFFF
  Input:4
    Previous Transaction:.F3BEA54D65FE5E89D77E34C7E1C57D3B00E1C8327AAB0E4B3DA026C9FA7B8A16
    Previous Output Index:0001 (1)
    Script Length:........6A (106)
    Unlocking Script:.....4730440220598BB94163092C90EE14FC96BAD695915254F2FA990BF33F646D58
                          47D0A8EB9A02205893ED21FD19BC912A4D9D14C8B32F85F1C54D246529E5C95D
                          BDB53B90F4F7440121022547351C3502D195472035ACFE58E5D000EAACCF3290
                          4F0BA4057720A81F9D14
    Sequence:.............FFFFFFFF
  Outputs:................01 (1)
  Output 1
    Value:................2434000000000000 (13348)
    Script Length:........17 (23)
    Locking Script:.......A9146B6674CCB5ACA499B2A8F4A27127AD9DB9D6DD1487
  LockTime:...............00000000 (0)

Note that every transaction is identified by a Transaction ID that is a hash of selected data in the transaction (it excludes SegWit data for compatibility with non-Segwit nodes)
See

Bitcoin Protocol Documentations - TX
In what format does a block store the transaction data?
Is blockchain.com the only place where you can see the blockchain?
How can I take a "snapshot" of the bitcoin blockchain and analyze it?


text:
What is a decent value for Time Lock Delta on a lightning network node?
Looking at the settings of some nodes on 1ml.com, I noticed the Time Lock Delta variable could vary a lot. How does it affect a node, and what is considered to be a decent value for it?

How does TimeLockDelta affect a node?

TimeLockDelta (or cltv_expiry_delta) is the minimum number of blocks a node requires to be added to the expiry of HTLCs. In other words, this value represents the required gap between the timelocks of the incoming and outgoing HTLC to this node. Once an HTLC times out, it can either be fulfilled or timed-out which means the node must take care to be around this transition and fulfill both the offered and received HTLCs. If the node does not fulfill this in due period of time, the peer will be able to get its funds back by spending the time-out transaction.
To illustrate this with an example, say your peer that you forwarded the HTLC to (outgoing HTLC) sends you the pre-image of the HTLC that was added sometime back. You make a payment to your peer for providing the pre-image successfully. Now it is up to you to redeem this payment from the peer through which you received the HTLC (incoming HTLC). If you wait long enough such that the expiry times out, then you are at risk of losing your funds because the peer who sent you the HTLC will use the time-out transaction to get its funds. So you are in a scenario where you have paid the outgoing HTLC, but you cannot claim the funds from the incoming HTLC.
So the value of the TimeLockDelta should be chosen in such a way that it is not too large such that other nodes do not send payments through you, but also not too small that you might risk losing your funds because you did not have enough time to satisfy the incoming HTLC. The below calculation shows the various cases that can crop up when fulfilling HTLCs and the optimum value that needs to be chosen for it.

what is considered to be a decent value for it?

Below is the text from BOLT #2 which has the calculations and various cases needed for determining what the cltv_expiry_delta a node should set for itself.
The worst-case number of blocks between outgoing and incoming HTLC resolution can be derived, given a few assumptions:

a worst-case reorganization depth R blocks
a grace-period G blocks after HTLC timeout before giving up on an unresponsive peer and dropping to chain
a number of blocks S between transaction broadcast and the transaction being included in a block

The worst case is for a forwarding node (B) that takes the longest possible time to spot the outgoing HTLC fulfillment and also takes the longest possible time to redeem it on-chain:

The B->C HTLC times out at block N, and B waits G blocks until it gives up waiting for C. B or C commits to the blockchain, and B spends HTLC, which takes S blocks to be included.
Bad case: C wins the race (just) and fulfills the HTLC, B only sees that transaction when it sees block N+G+S+1.
Worst case: There's reorganization R deep in which C wins and fulfills. B only sees transaction at N+G+S+R.
B now needs to fulfill the incoming A->B HTLC, but A is unresponsive: B waits G more blocks before giving up waiting for A. A or B commits to the blockchain.
Bad case: B sees A's commitment transaction in block N+G+S+R+G+1 and has to spend the HTLC output, which takes S blocks to be mined.
Worst case: there's another reorganization R deep which A uses to spend the commitment transaction, so B sees A's commitment transaction in block N+G+S+R+G+R and has to spend the HTLC output, which takes S blocks to be mined.
B's HTLC spend needs to be at least R deep before it times out, otherwise another reorganization could allow A to timeout the transaction.

Thus, the worst case is 3R+2G+2S, assuming R is at least 1. Note that the chances of three reorganizations in which the other node wins all of them is low for R of 2 or more. Since high fees are used (and HTLC spends can use almost arbitrary fees), S should be small; although, given that block times are irregular and empty blocks still occur, S=2 should be considered a minimum. Similarly, the grace period G can be low (1 or 2), as nodes are required to timeout or fulfill as soon as possible; but if G is too low it increases the risk of unnecessary channel closure due to networking delays.
There are four values that need be derived:

The cltv_expiry_delta for channels, 3R+2G+2S: if in doubt, a cltv_expiry_delta of 12 is reasonable (R=2, G=1, S=2).
The deadline for offered HTLCs: the deadline after which the channel has to be failed and timed out on-chain. This is G blocks after the HTLC's cltv_expiry: 1 block is reasonable.
The deadline for received HTLCs this node has fulfilled: the deadline after which the channel has to be failed and the HTLC fulfilled on-chain before its cltv_expiry. See steps 4-7 above, which imply a deadline of 2R+G+S blocks before cltv_expiry: 7 blocks is reasonable.
The minimum cltv_expiry accepted for terminal payments: the worst case for the terminal node C is 2R+G+S blocks (as, again, steps 1-3 above don't apply).

The default value for cltv_expiry_delta in BOLT #11 is 9, which is slightly more conservative than the 7 that the above calculation suggests.

In LND, the default value for bitcoin.timelockdelta is 80:
https://docs.lightning.engineering/lightning-network-tools/lnd/optimal-configuration-of-a-routing-node#channel-defaults
and in clightning cltv-delta the default is 34:
lightning-cli listconfigs | jq '.configs."cltv-delta"'

@northben please suggest an update. That's a good point since this answer is 5 years old

The timelock value can be up to 14*144 = 2016 or the expected amounts of blocks to be mined with 14 days.
Generally the cltv delta is a trade of:
The higher you choose this value the longer your node can be offline without you rising to lose funds. However other nodes might select not to route payments through you as the routing process if hiring the chain can technically last as long as the cltv delta.
The reason why you will see various values in the gossip update_channel messages (which 1ml depicts) is probably implementations use different default values and have also changed the defaults with various versions. I think it was 144 for one of the implementations and it came down to 6 or 9. Eclair mobile wallet which mainly creates private channels that you don't see on 1ml users 2016 because mobile phones might have longer downtimes


text:
Problem with data redundancy in block chain
Since the copy of same data is storedon each node in network. Does it use storage space to store same data on each node?
If yes then how the data is decentralised. It is just a large network of centralised database.
Any help would be appreciated.

In Bitcoin every (full-)node stores every full block. In Ethereum, what you're referring to is called Sharding (though I don't know if it's active on the main Ethereum network). https://ethereum.stackexchange.com may inform you about that.

Since the copy of same data is stored on each node in network. Does it use storage space to store same data on each node?

Yes, but what matters is the validation of the data. Therefore you can use pruning to validate the block chain data without the storage overhead.

If yes then how the data is decentralised. It is just a large network of centralised database.

What can be called decentralisation in the case of Bitcoin is the ability of being able to retrieve the current state of the network without having to trust a central source of validation (/truth). This is accomplished through the validation of the block chain.

Thanks, however since same block is store on every node it will going to occupy storage space on each block. Right? What is pruning?

@siddharthshah Pruning is decribed in  Satoshi Nakamoto's whitepaper. See also https://bitcoin.stackexchange.com/search?q=pruning

@siddharthshah pruning is the action of erasing the block data once validated it and filtered out what you needed to update your state. In addition to the above links, https://github.com/bitcoin/bitcoin/blob/v0.11.0/doc/release-notes.md#block-file-pruning .

Understood, but it's storing same data on all the node in the network too much residency? In the age of big data I can be a major issue

If yes then how the data is decentralised. It is just a large network of centralised database.

When people use the term decentralized, they mean that there is no central point of authority; no heirarchy to the network's nodes.
Each bitcoin full node validates the full network state, which allows them to participate in the network without having to trust any specific peer to provide them with truthful information. This is an important property of the network.
What you seem to be implying is that the blockchain history data itself should be stored/communicated in a decentralized way. But if each node was not able to fully verify the entirety of the data itself, then it would have to trust that other nodes in the network have verified the info it is missing. This is an issue, since now every node will have to trust third party nodes to provide truthful updates. Under this model, we lose the very important aspect of trustless participation, and instead end up with a Byzantine mess.

Understood, but it's storing same data on all the node in the network too much residency? In the age of big data I can be a major issue

Why would that be an issue? I'm not sure I understand your worry, can you elaborate?


text:
Exchange Confirmation Requirements
What does the minimum confirmations required for a deposit mean for the security of exchanges? For example, Coinbase requires 3 confirmations for Bitcoin deposits. Suppose an adversary deposits 10 bitcoins into an exchange and has his account credited.
What stops an adversary from mining a private chain with a transaction that conflicts with his previous deposit transaction. What would this mean for the exchange? Would the user have the ability to sell the Bitcoins credited to his account and defraud the exchange?

Does this answer your question? Why is 6 the number of confirms that is considered secure?

Coinbase probably requires even more confirmations for a deposit of that high a value. According to https://www.crypto51.app at this moment, it would cost some $600,000 to attack the Bitcoin blockchain for one hour. That means sustaining a 51% attack and potentially (not definitely) double-spending a deposit to Coinbase that had several confirmations.
If you are a merchant that accepts Bitcoin you must take this risk into account given the value of the transaction. A $1000 deposit to Coinbase is probably safe after three confirmations, because it would cost so much more than $1000 to reverse three blocks.

I thoroughly understand double spending in the context of a buyer and seller transacting, but I am unsure how the mechanics of a double spend would work against an exchange. For example, could an attacker "trick" an exchange into crediting his account and then take financial advantage of the exchange by reorganizing the blockchain? Couldn't the exchange just "remove" the Bitcoin that they credited the adversary with?

This answers my question: "A party like an Exchange may accept large deposits automatically, allow the user to trade into a different coin quickly, and then withdraw automatically. This is why they are targeting Exchanges."


text:
Move p2pk with addresses
This is strange for me that there exist over 30 000 of p2pk with addresses mainly with very high balance and these funds weren't moved yet. There are Linux tools to scan blockchain for them and note in one text/csv file.
If we have p2pk public keys and addresses for them (I have list of over 30k of them) why we can't just hash the public key and move the balance from all the addresses with p2pkh?
Or even simpler one: move these funds with only public key?
What is missing here, private key?

It takes a digital signature produced with the corresponding private key on a message committing to the spending transaction to move the funds. Since you only have the public key, you will find it challenging to produce such a signature.

Even with SIGHASH_SINGLE?

You can’t spend a UTXO without fulfilling the spending conditions defined in its output script. The transaction commitment created for SIGHASH_SINGLE still commits to all inputs, by the way, but even with SIGHASH_SINGLE+SIGHASH_ANYONE_CAN_PAY the input would need its own signature.

Isn't it that way, that spending p2pk with SIGHASH_SINGLE is possible for second somebody's else output by only public key which has been already used?

No, you cannot spend a UTXO without fulfilling the output script of that UTXO. And P2PK requires a signature made using the corresponding private key. I have no idea where you are getting this from. This would be completely unsafe and basically would mean that anyone can spend pretty much any funds.

The security design of Bitcoin ensures that only the private key owner can move the funds. This is a fundamental aspect of Bitcoin's security and trustlessness. Without the private key, the funds remain secure and under the control of their rightful owners.

I don’t understand why you would consider it “seemingly logical” that someone could spend coins using only public information.

The foundation of bitcoin, the thing that makes it possible, the reason people trust it with their money is that
You cannot spend money without knowing the private key.


text:
How long does it take to update all nodes that have the blockchain so that they are identical?
Beginner questions...
I understand that everybody has their own copy of the blockchain.
If one person makes a change, for example a transaction, I assume that it has to propagate to all other nodes. How long does this take?
How does a node know that the update process is complete throughout the blockchain?
What algorithm is used to synchronize and what is its order (O())?

The Blockchain is never changed only extended.
As I understand it, nodes do not explicitly check or care whether other nodes have identical copies. They just verify what they receive against what they already have in their copy of the Blockchain.
Synchronisation isn't exactly the right word to describe what happens but it effectively occurs as a consequence of nodes applying the same "consensus" rules. Nodes follow the longest chain, the one with most proof of work.

Thanks. How do the nodes discover the 'longest chain'?

The blockchain is an append-only data structure.  The only changes that happen are appending to an existing chain or rolling back blocks to switch onto a better chain that forks off earlier.
Nodes always attempt to be on the valid chain with the most proof of work.
To accomplish this they synchronize block headers with their peers.  Synchronization of headers uses locator messages:  You send your peer a list of block IDs that you know going back to the initial block, and your peer finds the highest point in the list that they know and sends you headers after that point-- which you probably don't know.  To make this efficient, the space between headers in the locator list doubles every entry after the first few. This causing the header synchronization process to be O(log n).
Once the node has a connected set of new headers that are a candidate for the most-work chain it starts fetching blocks along that chain of headers-- from peers that claim to have those block according to their header announcements-- and validating them.  If it encounters an invalid block, disconnects the origin, marks it and all headers in the chain after that block as invalid, and figures out where the new most work tip would be disregarding all the headers for invalid blocks and begins fetching and validating blocks towards that new best tip.

Thanks. How many pees does a node have? How does a node discover them?

Correction: pees = peers

Nodes usually make 8 outbound connections and normally have up to 125 connections in total.  They find out about them from other existing peers, from dns servers that they can query if they are having trouble finding any peers, and from a built in list.


text:
What is industry standard solution for trustless self custody?
I'm exploring self custody using hardware wallets. The intention is so that I don't have to keep the Bitcoin on centralized exchanges, anf I don't loose the Bitcoin if the exchange goes bust or runs away.
Hardware wallets promise to solve the problem of having to trust an external party (an exchange in this case) by providing self custody.
However, the more I research about this, it seems like we must trust the hardware wallet manufacturer.
Let's take an example of Ledger hardware wallet. Ledger firmware is closed source, and they are quite open about the fact that they have closed source firmware and are able to export the keys (if user chooses to opt for that feature). So there's nothing for users to verify whether the hardware wallet is maliciously:

Generating pre seeded keys
Exporting keys

So technically it doesn't solve the need to trust an external party. Therefore it isn't self custody in the real sense.
What is the industry standard approach for trustless self custody?


text:
can i check a Bitcoin payment is valid before I pay for exchanges? can I check the receipt number and the transfer number somewhere or with anyone?
i am due to receive a Bitcoin payment  i earned i would like to chat or speak by phone with a broker or a management account specialist and references the receipt number and the transfer number provided to me to make sure the exchange is satisfied with both parties before i pay for the transfer fees

It sounds like you might be getting scammed and the "transfer fees" is just a trick to get money from you. What company is this and how did you earn bitcoin with them?

Hi ejessejamz, I voted to close as a duplicate since I had the same thought as Vojtěch immediately. If we got that wrong, please edit your question with more information so that we can reopen your topic.


text:
Blockchain API not sending subscribed info
I'm having trouble receiving WebSocket messages for address-related events. Here is the code that I'm using (trackAddress gets called externally and I'm sure it sends the right thing). I also tried from an online WebSocket client (as seen in the photo) and the response to ping_tx is not the right transaction (the docs state that if you are subscribed to an address it would be that address's last transaction), instead, it returns the most recent on the whole network. It's really frustrating but I do not understand what it is that I am doing wrong. It's as if I'm never really subscribing to it...
You can see the transaction here: https://www.blockchain.com/explorer/addresses/btc/1P8wXFz6F7UdqnfsByZUf6tBxukcp9bJE9
import { WebSocket } from "ws"

const ws = new WebSocket("wss://ws.blockchain.info/inv")

setInterval(() => {
    ws.ping()
}, 30000)

ws.on("open", async() => {
    console.log(`Listener connected to ${ws.url}`)
})

ws.on("close", () => {
    console.log("Listener disconnected")
})

ws.on("message", (data => {
    const res = JSON.parse(data.toString())

    console.log(res)
}))

export const trackAddress = (address: string) => {
    console.log(`Tracking address ${address}`)
    ws.send(JSON.stringify({
        op: "addr_sub",
        addr: address
    }))
}

I faced the same problem and the solution is to listen to all transactions and to detect the transaction sent to our address in this way, I tried a method and it works fine.
ws.addEventListener('open', () => {
    ws.send(JSON.stringify({
        "op": "unconfirmed_sub"
    }));
});

ws.addEventListener('message', (res) => {
    let data = JSON.parse(res.data);
    let outs = data.x.out;
    let out = outs.find(o => {
        return String(o.addr).toLowerCase() == receiver.toLowerCase();
    });
    if (out) {
        setTimeout(() => {
           startCallback(data);
        }, 6000);
    }
});


text:
suspicious transaction from a cold wallet to cold wallet
Dears,
Please help me to understand what happened with a bct transaction I made from one cold wallet address to another.
In short:
I transferred the correct amount in the receiving address and when I check the status, it appears another transaction with a similar but smaller amount to a total unknown btc address. This unknown transaction appears on top of my correct transaction. The transaction(s) is pending since one hour and in the explorer it shows that the transaction will be completed in 12 hours.
Can someone please explain what happened?
Best regards,
g

Hi, when you say “another transaction”, do you mean that your transaction has two outputs or that there are actually two transactions? Which wallet software/hardware did you use?

i used trezor and sender and trezor as well for receiver. and yes, it apeears two outputs.

If your transaction has two outputs, very likely you are looking at a recipient and a change output. The change returns the remainder of the funds from the inputs to yourself. You can read more here: https://bitcoin.stackexchange.com/q/736/5406. If that was the issue, please let us know so we can close your topic as a duplicate, otherwise please follow-up with more information how your problem differs. :)

it seems clear for me now :). However I still don't understand why the validation of the transaction will take more that 12 hours?

What feerate did you send it at? The next block currently takes 15+ ṩ/vB, the second next block still 12+ ṩ/vB


text:
Bow to know how much amount my wallet sent with Bticoin-core API
I have updated bitcoin-core from version 0.16 to 0.17 and found that there is no way to see how much amount I sent only (excluding received amount) from my wallet.
With bitcoin-core version 0.16, I set account "rec" for receiving addresses only and segregate incoming and outgoing amounts. Then
bitcoin-cli getbalance ""
showed the amount sent from my wallet.
But I do not know how to see sum of amounts sent with bitcoin-core version 0.17. Is there anyway to see it?


text:
ThreadRPCServer incorrect password attempt from 127.0.0.1:34810
I am reading Mastering Bitcoin book, and on:
https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch03.asciidoc#full_index_node
there is a call to bitcoin node:
$ curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getblockchaininfo", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/

when I submit this command on a terminal, it asks for a password, which I copy and paste from .cookie
but there is an error on the bitcoin node cli:
ThreadRPCServer incorrect password attempt from 127.0.0.1:34810

A .cookie file is key value pair:
__cookie__:xxx

I tried copying both key and value as well as just value as a password, but still got the same error. Please help.

Are you using __cookie__ as the username? Or something else? In general though, you shouldn't be using the .cookie file as it will change between restarts. You should define your own username and passphrase using the rpcauth option in the bitcoin.conf file.


text:
I can't find my funds on my bitcoin wallet
I can't find my funds on my blockchain wallet after saving for over 1 years. My blockchain account show (00) total when i have saved 3 BTC what should i do ? please help

what should i do

It depends whether you have a Blockchain.com account or a Blockchain.com wallet.
If you have a Blockchain.com account, contact Blockchain.com support.
If you have a Blockchain.com wallet, check the transaction history and find the Bitcoin addresses which held your money. You can then check those addresses in several different  blockchain explorers to see if money has been removed from those addresses. If not you may be able to regain control by  re-creating your wallet from your recovery phrase or wallet backups.


text:
How does a perpetual futures contract affects the actual price?
I kind of understand how a perpetual futures contract works, but I don't see how it affect the price of the underlying asset, such as Bitcoin.

The majority of volume is traded via perpetual swaps, hence the majority of belief of the commodity price must lie in those perpetual swaps.  For this to be true, it would mean that the perpetual swap affects the spot price in the first place.
As the perpetual swap is a derivative of the actual commodity they share the price changes with each other by the no-arbitrage constraint as per answer here.
https://qr.ae/pNaIuG


text:
How does tax work with crypto Debit cards?
There are plenty crypto debit cards, like Crypto.com's or Binance's. I can easily use my fund to purchase goods and services without taking profit out of an exchange, and just simply use the funds on it.
If I purchase coffee with a debit card like that, is it taxable?
And if it is, how do I even know or calculate my taxes?
Is there a specific rule on this in the EU?

Is there a specific rule on this in the EU?

According to https://nomoretax.eu/bitcoin-taxation-developed-countries/

The fiscal treatment of Bitcoin for tax purposes differs depending on EU country.

how do I even know or calculate my taxes?

By consulting material published by the tax authorities in the country in which you are resident (and US as well if a US citizen resident outside the US).
By consulting a tax adviser.
By contacting the local tax authorities and asking them for advice. (In my country at least, they are friendly and helpful to people seeking advice).


text:
Run lightning-charge on c-lightning regtest
I'm trying to run lighting-charge (https://github.com/ElementsProject/lightning-charge) on top of one of my 2 lightning (https://github.com/ElementsProject/lightning) instances. I am running 2 nodes using the script here: lightning/contrib/startup_regtest.sh. This file will start a bitcoin instance as well as 2 lightning nodes (/tmp/l1-regtest, /tmp/l2-regtest)
I then tried to run lightning-charge with:
$ NETWORK=regtest charged --api-token super_secret_1 --ln-path ~/.lightning --db-path ~/charge1.db --port 9112

Which gives me this error:
Lightning client connection error { Error: connect ECONNREFUSED ~/.lightning
    at Object._errnoException (util.js:1022:11)
    at _exceptionWithHostPort (util.js:1044:20)
    at PipeConnectWrap.afterConnect [as oncomplete] (net.js:1198:14)
  code: 'ECONNREFUSED',
  errno: 'ECONNREFUSED',
  syscall: 'connect',
  address: '~/.lightning' }
events.js:183
      throw er; // Unhandled 'error' event
      ^

Error: connect ECONNREFUSED ~/.lightning
    at Object._errnoException (util.js:1022:11)
    at _exceptionWithHostPort (util.js:1044:20)
    at PipeConnectWrap.afterConnect [as oncomplete] (net.js:1198:14)

I've also tried running it with ln-path set to /tmp/l1-regtest/
with ps aux I can see lightning is running with this command:
~/git/lightning/lightningd/lightningd --lightning-dir=/tmp/l1-regtest
and
~/git/lightning/lightningd/lightningd --lightning-dir=/tmp/l2-regtest

Does anyone know how to get lightning-charge to connect to my regtest lightning node?
There are instructions on how to do this in docker in the readme file (https://github.com/ElementsProject/lightning-charge/blob/master/README.md), but it doesn't seem to work outside of docker.

Does lightning charge connect via a port to lightning? I just realized that the regtest lightning doesn't use the default port 9735 but actually uses 6060 and 9090

I guess I could just run it on docker and mount the lightning and Bitcoin dirs. It does explain how to do that in the readme. It's pretty complicated though so I was hoping to avoid using docker. I'll report back after I've tried that.

the problem is in your call of charged there you are passing the argument --ln-path ~/.lightning assuming that you run lightning in your home directory thus you have to set ln-path to /tmp/l1-regtest/.
Now you say that this also did not work. So before I give you a solution let me explain what is actually going on. charged talkes to lightningd via an rpc-interface on an UNIX Domain socket. In older versions of lightningd there was a file called lightning-rpc in the folder that you specified as lightning-dir however lightningd has switched its API recently to to have subdirectories in lightning-dir for mainnet, testnet and regtest. (the reason was that in particular in the default directory people wanted to have different configs for mainnet, testnet and regtest)
Thus I assume that you will find lightning-rpc when you do ls /tmp/l1-regtest/regtest which means that you should pass the tmp/l1-regtest/regtest in --ln-path when you call charged. If that is not the case I would have to see another error message.

It works! thank you and thanks for making all those yt videos!


text:
How does the bitcoin network use public and private keys when one wants to transfer funds?
I am familiar with Public keys, private keys and addresses. But, I don't understand how they are used when I want to transfer funds to a different wallet.
For example, what is the process that is actually happening under the hood when I click the 'transfer Bitcoin' button of my wallet in terms of the keys?

Does this answer your question? How are public and private keys related to the wallet?

what is the process that is actually happening under the hood when I click the 'transfer Bitcoin' button of my wallet in terms of the keys?

Your wallet selects from available coins (UTXOs for which your wallet knows the private key) a sufficient number to cover the amount being "sent" plus the selected transaction-fee.
These selected UTXOs form the input side of the transaction the wallet constructs. The output side has at least one output that contains a locking script derived from the "address" provided by the payee. The locking script is sometimes called a scriptpubkey for historical reasons.
For each coin being spent, your wallet then creates a cryptographic signature of most of the transaction data using the corresponding private key and the ECDSA algorithm.
This signature data is put into the unlocking script for each UTXO. This unlocking script is sometimes called the scriptsig. It proves to the rest of the nodes in the network that you have the right to spend those UTXOs. The exact contents needed in the unlocking script obviously depend on the specific type of locking script in the prior transactions in which those coins were sent to you (i.e. came under your control)
The unlocking scripts are part of the created transaction but obviously cannot be part of the transaction data that is signed because their contents are not known until after the signature has been created.

The above applies to the simplest types of transactions. There are complicated types of transactions, such as n-of-m multisig, which I have not attempted to describe here.

How does the bitcoin network use public [...] keys [...]

In at least the simplest forms of transactions, nodes in the Bitcoin network use the public key provided to verify that the cryptographic signature in a transaction is a correct cryptographic signature of the transaction data.
Putting it very loosely:
bigint signature = ECDSA.sign(data, private-key)

boolean validity = ECDSA.verify(data, signature, public-key)

Things must get more complicated at a detailed level when you compare P2PK vs P2PKH let alone P2SH, segwit outputs and multisig transactions.


text:
What stops someone from tampering with node software and hence would be able to disrupt the blockchain?
For example, if someone was running a full node and somehow re-wrote the software so that blocks and transactions which did not abide by Bitcoin's consensus rules would be able to be relayed, what would stop these blocks from joining the Blockchain?
Is it the fact that these blocks are broadcasted to other nodes that stops the invalid block from joining. For instance, if the invalid block is relayed to a non-corrupt full node and this full node rejects it, then it won't be added <-- is this true?

Other nodes would not relay or accept invalid blocks that were produced by the modified node.
Each node creates their own copy of the blockchain. Each node checks (verifies/validates) all the data it receives to the fullest extent possible. No node trusts any other node. It is because each node applies the same set of rules that they all end up with the same data in their copy of the blockchain. Nodes that apply different rules end up forming a separate "forked" network with a different "forked" blockchain.

You are correct, when the new block is broadcasted, all the other nodes would reject it if it doesn't follow the consensus rules, would not add it to the blockchain nor will they transmit it.
In fact, the "software" itself is not important (there are multiple Bitcoin node clients), just like many software pieces can create JPEG photos (ranging from your phone, computer, camera, etc.), the protocol itself depends on what the nodes agree on.
You would be essentially creating a hard fork, and if for any reason all the nodes and miners use your "re-written software", and is accepted by everyone, then at that point that new Bitcoin probably becomes... Bitcoin.


text:
Does The Bitcoin Network Have A Way To Alert Nodes Of A Network Issue/Bug?
I know that the Bitcoin Network would send an alert message which follows:
int32_t nID
The alert identification number - this allows nodes to identify double-messages.
int64_t nExpiration
The alert-expiry time.
int64_t nRelayUntil
Instructs nodes to cease rebroadcasting of the message.
int32_t nMinVer ---> int32_t nMaxVer
The range of bitcoin protocol versions that this alert applies to.
std::setstd::string setSubVer
The current client software update that this alert message applies to.
int32_t nPriority
  The priority of the alert message - however, this function has been rarely used.

However, this was later abandoned in 2016 where the public and private keys of the message were released to the public.
Does the Bitcoin Network still have a way of notifying nodes of a potential fatal bug/error? If not, what is done if the Bitcoin Network is compromised?

Does the Bitcoin Network still have a way of notifying nodes of a potential fatal bug/error?

No.
After all, it is a peer-to-peer network without any central control. Either no-one can issue alerts or everyone can, including the malicious. Changing this would go against the founding principle of Bitcoin - avoiding any need for trusted third-parties. It seems to me the removal of the alerting mechanism moved the Bitcoin network closer to its founding principles.
The discussion of this feature is illuminating

The alert system was a frequent source of misunderstanding about the
security model and 'effective governance', for example a years ago a
BitcoinJ developer wanted it to be used to control fee levels on the
network and few months back one of Bloq's staff was pushing for a
scheme where "the developers" would use it to remotely change the
difficulty-- apparently with no idea how abhorrent others would find
it.
The system also had a problem of not being scalable to different
software vendors-- it didn't really make sense that core would have
that facility but armory had to do something different (nor would it
really make sense to constantly have to maintain some list of keys in
the node software).
It also had the problem of being unaccountable. No one can tell which
of the key holders created a message. This creates a risk of misuse
with a false origin to attack someone's reputation.
Finally, there is good reason to believe that the key has been
compromised-- It was provided to MTGox by a developer and MTGox's
systems' were compromised and later their CEO's equipment taken by the
Japanese police.

If not, what is done if the Bitcoin Network is compromised?

Presumably lots of different people do different things while attempts at coordination are managed through media popular with Bitcoin developers.
You could look at what happened in earlier crises such as the Value Overflow incident of 2010. Nowadays it would probably be much harder as there are a greater variety of software applications in use. I don't know if it can be argued that the Value overflow incident was a bug in one software application rather than a bug in the network protocol. In which case it isn't a good example. Another example might be the removal of vulnerable or unused opcodes from Bitcoin script because of the OP_LSHIFT bug
See https://www.cvedetails.com/vulnerability-list/vendor_id-12094/Bitcoin.html. This is perhaps a clue to how discovered vulnerabilities are handled. There may be little advantage in having a network specific mechanism. Certainly the history suggests that securely embedding an alerting mechanism in a purely peer to peer network protocol is a difficult problem to solve.


text:
Building a Bitcoin IPN. Need unique identifier
I am building a Bitcoin IPN to poll bitcoind every 5 minutes, find new payments with at least 1 confirm, and notify a server.
It looks like I am going to have to load them all up with 'listtransactions' every time and parse out new ones.  Inelegant, but I don't see any other option.
So the next problem is that I need a unique identifier of payments so that I can see if it has already sent a notice.  I have read that txid can change?  Well, that is not a bloody ID then, is it?!  How can I identify a payment?  sha1(address . amount . time) ?  What is the difference between 'time' and 'timereceived'? Are they static?
The best discussion I found about this is here but it doesn't look like it went anywhere;
https://bitcointalk.org/index.php?topic=3092.0
Cheers.

Where did you see that txid can change?

TXIDs cannot change. TXIDs are simply hashes of the transaction. It is possible for two different transactions to have the same TXID - that's called a hash collision. However, the chances of that happening are so low and I believe you will actually win prize money if you find a collision.

I am building a Bitcoin IPN to poll bitcoind every 5 minutes

Investivate -blocknotify, which will turn your system from pull to push. Any command given to blocknotify will be executed when a new block is encountered, and you can use this to update your internal systems with the newly confirmed data.

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