text:
Why would you need a mining pool?
Why didn't the creator didn't manage to allow people to be able to mine without needing a mining pool ?

Bitcoin was and still can be mined by an individual that is not part of a mining pool. In fact, the network does not actually know about mining pools nor does it care about them. In the beginning, Bitcoin was mined by individuals using their own CPUs. Then, as more and more people wanted to mine Bitcoin, miners began using faster and faster hardware, moving from CPUs to GPUs, and then to FPGAs, and now to ASICs.
Unfortunately the rapid growth of mining meant that it was harder for an individual to be able to find a block. So people began pooling their resources together. A bunch of individuals would mine as a group and the block reward would be split up among themselves. That group would have a higher chance of finding a block than just one person mining by himself, and while each would be paid less, they would be able to earn Bitcoin more consistently as they have a higher hashrate than just one person. And thus mining pools were born.
So it isn't that Bitcoin was designed to be mined at mining pools, but rather that mining pools were a natural evolution from the increased overall hashrate of the network.

Mining pools allow miners to reduce the variance of their income. It is possible to mine without a pool. This is known as solo mining.

I think, that was exactly Satoshi's intention.
But nowadays, it would be hard for you to mine 1 block because you don't have much mining power if you are alone.
So the people decide between Do I want x$ per day (irrelevant wheather I mine a block) or Do I want 25*15,000$ + fees (if I mine a block what happens maybe 0-1 times) Most people want(ed) the permanent money.
And that's the reason why there are only a few big mining pools instead of millions of separate miners.

There are many advantages of joining the mining pools. For now, i will just only focus on increasing the overall hash rate percentage. We all know that if the probability of success is p then prob. of failure is (1-p). Lets assume a miner controls fraction "p" of overall mining power and has prob. p to mine the new block then (1-p) prob. of not mining the new block.
I hope you know about bernaulli's distribution in probability so according to that variance = p*(1-p).
so How many blocks are mined in a year ?
every 10 min = 1 blocks
one hour = 6 blocks
one day = 24*6 blocks
one year = 365*24*6 blocks
we find that the miner who has prob. p of mining the new block is expected to mine 365*24*6*p blocks per year.
then variance = 365*24*6*p*(1-p).
Now we will calculate the standard deviation (in blockchain, it is the deviation that how much this miner's reward is going to be deviated from the expected reward). I hope you know about the reward system for miners.
standard Dev. = [sqrt]Variance / expected return
variance = 365*24*6*p*(1-p)
expected return = 365*24*6*p
so std. dev = [sqrt]365*24*6*p*(1-p) / 365*24*6*p
now suppose a miner owns 0.01% of hash rate in network i.e prob. p=0.0001
std. dev = 0.4364 or 43.64 % deviation for hash rate 0.01%. (by putting the value in the above formula)
The solution to decrease this deviation and variance is to join mining pools and work together to increase the overall hash rate percentage, which is exactly working now a days.

If you don’t want to invest in the blockchain technology and looking for any third party who help to mine your favorite cryptocoin. Than the Mining pool is the best option for you.
In Bitcoin mining or any other digital currency mining, hardware plays a very important role. Initially, CPU was the only hardware device which miners used to mine bitcoins. The total mining depends on the hardware that is to be used for mining. Here, Mining does not need any special hardware other than GPU. A GPU is the Graphic Processing Unit that allows the miner to mine cryptocurrency with a good hash rate. The hash rate totally depends on the hardware that is to be used for the mining of cryptocoins.
Also the ASIC chip is specially designed to perform mining activities. An ASIC model cannot be remodeled to perform other duties.


text:
Can I transder USDT to either ERC20 or TRC20 addresses?
I have some USDT in an exchange and I want to deposit it to another, I have 2 options of depositing to either an ERC20 or TRC20 addresses, does it matter to which I send it to? Will I lose my funds if I send it to the incorrect address?

Those addresses belong to other, non-Bitcoin blockchains. ERC20 is the Ethereum blockchain, and TRC20 is the Tron blockchain.

Will I lose my funds if I send it to the incorrect address?

It is possible to lose your funds like this, so be very careful with the address - you must create an address for the particular blockchain where you wish to receive your USDT, and have a wallet that can receive and send assets on that blockchain.
Note that originally, USDT existed as a token on Omni Layer which is a protocol that uses the Bitcoin blockchain to record special transactions:

Omni is a platform for creating and trading custom digital assets and currencies. It is a software layer built on top of the most popular, most audited, most secure blockchain -- Bitcoin. Omni transactions are Bitcoin transactions that enable next-generation features on the Bitcoin Blockchain. Our reference implementation, Omni Core is an enhanced Bitcoin Core that provides all the features of Bitcoin as well as advanced Omni Layer features.

However, most exchanges don't support USDT-Omni, and I'm not sure if even the issuer (Tether) anymore mints/redeems USDT-Omni for USD. So, if you're using USDT it is most likely NOT on the Bitcoin blockchain.

Thanks for the quick reply. All I know is that I have tether in my account, and I can generate 2 addresses as a deposit for tether on the other exchange, I just don't know how my tether were "minted" and which blockchain they are on, do I need to know that before I input an address, or would both work?

Your exchange "balance" is really an IOU (I-owe-you) from the exchange, it doesn't matter how the USDT you had deposited or traded for was originally minted since it should all be redeemable for USD with the issuer (Tether). Anyway, just pick one of the 2 blockchains, find a reliable wallet, generate the address, and then withdraw. Ethereum (ERC20) has its own SE site where you could ask for help with the wallet: https://ethereum.stackexchange.com/

Thanks for the clear answer.

source: Stack Exchange

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

sort: votes


text:
How to findur Bitcoins and wallet
lababyblue32@yahoo.com
Amanda glenn
I'm new to this got an email stating I needed withdrawal my cash I made off Bitcoin bonus so I did but I don't know where it went I need to know how to receive it or recover it or if I even got anything

This all just sounds like a scam to me. Did you expect this email? Have you owned any bitcoin before?

Welcome to bitcoin.stackexchange.com. It looks to me like a scam. See this other similar question about "Bitcoin Bonus"

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


text:
How do nodes communicate through tcp over different networks
It is said that the nodes communicate over tcp but how is that acheived across networks over different Nats

different networks

Ordinary plain IP routing.

different Nats

The Bitcoin network protocol uses standard TCP sockets with a typical destination TCP-port number of 8333.
The use of Network Address Translation (NAT) by many last-hop routers makes it harder to connect to Bitcoin nodes that use IPV4 private addresses behind a router. In theory the use of IPV6 addresses should make this issue go away.
I believe the NAT traversal  for Bitcoin IPV4 TCP connections probably uses whatever features are provided by the underlying network libraries and/or are configured in the OS by the end-user.
So far as I know, there isn't a Bitcoin-specific solution for this. There are a lot of general solutions that may be appropriate to use.
See

What is the NAT traversal technique used by bitcoin - which has answers mentioning specific support for UPNP if configured.
Can exist bitcoin network with all nodes behind NAT?
How does bitcoin core establish a peer to peer network
Running a Bitcoin node (behind Firewall / NAT or anything else? disallowing inbound connections)

Yes, there is nothing special about Bitcoin in this regard compared to e.g. a Minecraft server. It's just plain old TCP/IP. NAT traversal is another matter; if a node behind a NAT wants to be accessible on the public internet, the NAT needs to be configured to forward traffic sent to a particular port on the public address to the node.


text:
scriptsig-not-pushonly (code 64) during send transaction in regtest
I create a transaction in regtest without send it, I have transaction data signed.
I modified a little bit the scriptSig in order to replicate transaction malleability, I add two operations (2 OP_DROP) and increase the scriptSig length from 6A to 6C.
this is my final result.
0200000001b6a6018077d7e817c13074f4127a641a3225b44e56318ef61d2b746b0271e308000000006c527547304402205fa24c98406b9f18732a586a2d5a5cf8ed5e033afca89dda772963f87bff457d022020c796be2fd4c6c47733214293263e244828211a51f044872090e610d5e1e8820121024f29076388ac6ed18b281a149e88043be7e78f72e138f3498853d8918f7f5448ffffffff01606b042a010000001976a914f1edb261a91e7cb03737708d718b2c47b7aa5c8e88ac00000000

When I try to send rawtransaction I receive this message:
error code: -26
error message:
scriptsig-not-pushonly (code 64).

I'm using bitcoin-core 0.19.0.1

One of the standardness rules (relay rules) in Bitcoin Core is that the scriptSig must contain only operations that push data to the stack. Since you have actual opcodes that do non-push things, this transaction is non-standard so your node is not accepting it.
On regtest, you can disable standardness checks by adding -acceptnonstdtxn to your startup command.

Thanks for reply. The similar transaction (with same procedure) works on testnet in the same node without use acceptnonstdtxn.

Tests (https://bitcoin.org/en/release/v0.19.0.1#miscellaneous-cli-changes)
The regression test chain enabled by the -regtest command line flag now requires transactions to not violate standard policy by default. This is the same default used for mainnet and makes it easier to test mainnet behavior on regtest. Note that the testnet still allows non-standard txs by default and that the policy can be locally adjusted with the -acceptnonstdtxn command line flag for both test chains. (#15891)

Yes, that is expected behavior. Testnet defaults to -acceptnonstdtxn=1 while both mainnet and regtest default to -acceptnonstdtxn=0. On mainnet, this cannot be changed, but on regtest, it can.


text:
How to Verify P2SH Signature
I am trying to debug an issue where i believe i might have a bad signature but i am trying to figure out how to approach it.

What is this a signature of. Private key + what (redeem script? entire raw hex?)
How can i verify that this is a correct partial signature (N 2 of 3) P2SH transaction.

I have 3 signatures. I want to test each signature separately to see which are bad or good. How would one approach that? I have read through many posts here but i have not found any solutions.

To answer your first question:
A P2SH transaction activates a special rule in Bitcoin nodes. When a Script_Publick_Key comes with this pattern:
OP_HASH_160, <HASH>, <OP_EQUAL>
 then the node runs the information in a different way.
First, it runs as it usually does. It puts the ScriptSig on top of the Script_Public_Key. The ScriptSig must follow this form:
OP_0
<Signature 1>
<Signature 2>
...
<Signature (m)>
<SerializedRedeemScript>

Due to Script rules of evaluation, the first item to be evaluated is going to be the <SerializedRedeemScript>. If the hash160 of this serialized script matches the hash in the Script_Publick_Key then the first round is valid and older nodes would stop here. However, BIP0016-compliant nodes will later interpret the serialized version of the redeem script (<SerializedRedeemScript>) as actual Script commands, and the process will repeat this time with the redeem_script commands and the ScriptSig but without the <SerializedRedeemScript> since it was already consumed during the first round of validation. So, let's talk about this redeem_script.
The redeem script must specify how many private keys can sign a transaction (n), how many signatures are necessary to legitimately sign a transaction (m), and all the public keys that corresponds to the private keys that can sign the transaction. The form of the redeem script is as follows:
<OP_m>
<PublicKey 1>
<PublicKey 2>
...
< PublicKey (n)>
<OP_n>
<OP_CHECKMULTISIG>

Since we have only consumed the <SerializedRedeemScript> in the first round of validation, then we still have our OP_0 and signatures left, and the final stack of commands, which is a combination of the redeem script and what is left from the ScripSig, will look like this:
OP_0
<Signature 1>
<Signature 2>
...
<Signature (m)>
<OP_m>
<PublicKey 1>
<PublicKey 2>
...
< PublicKey (n)>
<OP_n>
<OP_CHECKMULTISIG>

The first OP_0 is necessary although it has no meaning at all. It is necessary because of a bug called Off-By-One bug. This was done by accident by Satoshi Nakamoto.
The signatures and public keys will be evaluated by the <OP_CHECKMULTISIG>.
How can i verify that this is a correct partial signature (N 2 of 3) P2SH transaction.

If you want to check signature by signature, then you can try to do this by first calculating the transaction hash (z) and then checking your single signature with each one of the public keys from the redeem script through OP_CHECKSIG instead of the OP_CHECKMULTISIG. If your signature is valid for a specific public key then your signature is valid. If your signature is not valid for any of the public keys then it is not valid.

Thanks for all the information. THat is a great background on how signatures are operated. I figured out that it's part of the scriptPubKey is what is being signed. I have found some tools to figure out how to generate the signature. But i still am not sure how i can verify that signature against a public key or address ? How would i go about doing that?

You will need to calculate z which is the transaction hash. To calculate this value, you will have to take the raw transaction's hexadecimal and replace all the inputs ScriptSigs with the redeem script + SIGHASH_ALL ("01000000" in hexadecimal). After you do this, you apply a double sha256 (also called Hash256), and that's it. You have your z. With this value you can check an individual signature and evaluate it against all the public keys from the redeem script but one by one. A signature is a pair of values (r,s). The formula you will have to evaluate is:

(z/s)G + (r/s)PublicKey = RandomPoint
G is a point on the cryptographic curve:
x: 0x79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
y: 0x483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8

The x coordinate from the resulted RandomPoint must be equal to (r) from the signature.


text:
ScriptSig raw hex to sign raw tx
i have a p2sh address that is created using an uncompressed public key (from my ledger nano) and a compressed public key (bitcoincore wallet). It requires both signatures to send the funds. When i use my nano ledger to sign i get output:
3045022100b0c80ad5f5db6b790b75156186322b1fd6f9d1da61ff04e47f5a64ca8cdfaf6f02207bce077a537e215d9dd5ccaae72e8af1c4750e67722910c2af1d1f3b6e9357f2
I am using the ledgerjs library to get this and using the signP2SHTransaction function. Normally i just input my private key into bitcoin core's signrawtransaction function but I am pretty sure this is the scriptSig. I just don't know of any libraries that allow me to use this to sign the rawtx. (I looked at python-bitcoinlib but i saw no way to input rawtx information into a readable format.)
Any suggestions on a tool i can use to take this to sign the raw tx hex to the send on the wire?

If I understand correctly, you are signing 2-of-2 multisig, one key in core and one key in ledgerx?

You are correct, that is the scriptSig. I'm not sure if there exists a tool to add this to an unsigned tx, but you really just need to append it to the input you were signing. If you had multiple inputs, you need one of these for each input. Depending on your sighash flags, they may or may not be identical.


text:
difference between signing a message and signing a p2sh
can i use the sign message function to sign the serialized hex for a p2sh transaction? Are the ecdsa functions used the same or are they different? It looks like the output is in a different format than a traditional tx signature? How can one use this function to sign?

You cannot. While both message and transaction signing use ECDSA and double sha256, signed messages slightly modify the message such that it is impossible to create a signature that works for that key in a transaction.
Specifically, bitcoin signed messages are prefixed with the string Bitcoin Signed Message:\n (\n is the newline character, not literally \ and n). This means that the data that is actually signed cannot be for a transaction since the data signed for a transaction cannot begin with that string. This design is intentional so that users cannot be tricked into signing a message which can be used in a transaction to take their money.
The output looks different just due to serialization. If the signatures were compatible, you would just deserialize the signed message signature and reserialize it differently. But because the signatures are not compatible, this point is moot.

Perhaps point out that this is by design: otherwise you could try to get someone to sign a specific message, and then use it to steal their money.

if i have the rawhex that i want to sign. Why can't i construct a message with 'Bitcoin Signed Message:' in front of it and then sign it?

i guess i am asking if the actual ecdsa function and hashing are identical. It seems like adding a string in front of signed data is pretty easy to do ? how is this serialized vs a traditional tx signature ?

@user3554230 Signatures for transactions follow a very specific format. They are, for the most part, just the transaction itself with a couple modifications. The data that is signed is not included in the transaction explicitly, verifiers construct it from the transaction that they receive. So you can't just "add a string in front of the signed data" for a signature in a transaction.


text:
How to change network on BitcoinJS-lib with Coininfo and generate Dogecoin address?
Can't find out how to change network on BitcoinJS-lib with Coininfo and generate Dogecoin address?
In a Coininfo's example I found this: https://github.com/cryptocoinjs/coininfo#want-to-use-with-bitcore-or-bitconjs-lib
But what to do next?

Solved, and here here is my code:
const coininfo = require('coininfo');
var bitcoin = require("bitcoinjs-lib");

generateDOGE = function() {
    var coininfo = require('coininfo');
    var curr = coininfo.dogecoin.main;
    var frmt = curr.toBitcoinJS();

    const netGain = {
        messagePrefix: '\x19' + frmt.name + ' Signed Message:\n',
        bip32: {
            public: frmt.bip32.public,
            private: frmt.bip32.private
        },
        pubKeyHash: frmt.pubKeyHash,
        scriptHash: frmt.scriptHash,
        wif: frmt.wif
    }

    const keyPair = bitcoin.ECPair.makeRandom({ network: netGain })
    const wif = keyPair.toWIF()
    const address = bitcoin.payments.p2pkh({ pubkey: keyPair.publicKey, network: netGain });
}

Theoretically, you would just replace the network argument in the bitcoinjs function calls to the one generated by coininfo. You'll have to figure out the message prefix (don't know if mine is correct) because it doesn't look like that's defined by coininfo.
const coininfo = require('coininfo')
const doge = coininfo.dogecoin.main
const dogeNetwork = doge.toBitcoinJS()
const bitcoin = require('bitcoinjs-lib')

dogeNetwork.messagePrefix = '\x18Dogecoin Signed Message:\n'
console.log('network: ' + JSON.stringify(dogeNetwork));

const keyPair = bitcoin.ECPair.makeRandom({ network: dogeNetwork })
const wif = keyPair.toWIF()
const { address } = bitcoin.payments.p2pkh({ pubkey: keyPair.publicKey, network: dogeNetwork })

console.log('address: ' + address)


text:
Can I use wallet balance in satoshis as input for transaction builder ( bitcoinjs-lib )?
Can I use wallet balance in satoshis as input for transaction builder using bitcoinjs-lib ?
If yes, how?

No. Bitcoins are not kept in addresses, but Unspent Outputs ("UTXO"). You must specify TXIDs and outputs indices ("vout"). Specifying amount to make a transaction is not needed, but BitcoinJS may ask you for it to calculate the change output and the fee.


text:
P2PKH - Sharing a wallet address does not reveal my pub key?
Is it technically correct to say that if I share my address with the network, nobody has access to my pubkey still?
But if I share a valid signature to a P2PKH UTXO, someone can derive my pubkey and consequently spend my UTXO?

Is it technically correct to say that if I share my address with the
  network, nobody has access to my pubkey still?

Yes, if your address is a standard address, then deriving the public key from an address is practically impossible (because it is hashed). But as soon as a transaction is made which spends funds sent to that address, then the public key is in the signature of the spending tx.
A P2PKH transaction contains:
scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

So, once a P2PKH UTXO is spent, one can simply look at the script sig for the pubKey.
This is because in order to verify transaction signatures, nodes need the corresponding public key. For this reason, sometimes users will use different addresses for each transaction to help ensure more privacy.


text:
Does it make sense to design a mutable blockchain?
I work in a large consulting firm which is marketing a mutable blockchain solution to its clients. But I personally fail to grasp any advantage of using a blockchain design if you are discarding immutability. Am I missing something here?

Probably need to provide more context, what are they marketing that the mutable blockchain will solve?

I agree more context is needed to provide a more directly meaningful answer.
But in general: a blockchain allows users to interact without trusting a central authority, instead they verify the system’s state on their own. As a user, I can verify that I own some amount of bitcoin by running a node, and seeing the transactions that paid me as confirmed in the blockchain record. I know that the network’s rules do not allow those coins to be moved unless a transaction is signed by the valid keys (which I control). If the system allows mutability, then how confident can I be that the transaction which paid me will not be changed in the future? With an immutable blockchain, the energy spent on POW mining helps guarantee this, but if mutability is allowed... ??? How can I be sure?
If some form of mutability can be added while preserving this factor of trustlessness, then maybe a ‘mutable blockchain’ is reasonable. But I am yet to see such a proposal. If the user must trust a central authority to not change the system, then using blockchain architecture is superfluous.
In reality, I suspect in most cases a ‘mutable blockchain’ would be an inefficient way to implement a database, albeit one that can be dressed up in marketing buzzwords and sold to customers more easily due to the ‘blockchain hype’.

But I personally fail to grasp any advantage of using a blockchain design if you are discarding immutability. Am I missing something here?

Advantage: customers love blockchain hype, so they’ll be more willing to buy what you’re selling.
I’m sorry to say, but I think your intuition is correct. Frankly, such projects seem either misguided, or scammy to me.
EDIT: perhaps worth mentioning as well: allowing a central authority to alter the blockchain record creates a monstrous security risk. No matter how well intentioned or benevolent the authority is, an attacker targeting their system of control represents a huge existential risk to the network. There is no such thing as a secure backdoor that only ‘the good guys’ can access.

Thank you very much for the answer. From what I know, there hasn't been a specific solution for a specific market yet, just a general proposal of a blockchain with different types of permissions given by the admin and mutable by the admin. What from my perspective is just a terrible data base design.

I can see a potential mutable blockchain being valuable for a number of reasons:

If only 'trusted nodes' are allowed to change the blockchain, and there is significant reputation and financial resources at stake at making a false claim and
The mutability is limited to 'fraud protection'/reversing transactions, so that if someone is genuinely a victim of fraud (or they lose their coins...) the blockchain can be modified to release these funds, rather than permanent loss as is the case with bitcoin/immutable blockchains.

Most block-chains are actually mutable in some way and this has some advantages. This came clear in some incidents where a bug or a flaw in a chain was exploited  resulting in many people losing a large amount of assets. Afterwards people would hard fork a previous state of the chain and continue from there, after getting the consensus of the community.
People usually need immutability to protect the chain from illicit modifications of the network. So having a way to easily modify the history of a block-chain would be very beneficial if you can ensure that the such changes are only done under some kind of consensus and is protected from different attacks.
Examples where this comes in handy is if you want to have a dynamic chain where you keep the current price of stocks for example or a social-media chain where you could edit or remove a post. Of course some workarounds exist in immutable chains, such as creating a new transaction that flags an old transaction removed, but people would still be able to read it and this would add overhead to the chain make the client more complicated. However, that shows how important is the consensus mechanism to decide who has the rights to modify the chain and in which manner.


text:
"tx" array inside blocks contains transactions hashes?
When I use the "getblock " command on my bitcoin core client, it returns, beside other things, an array called "tx" with hundreds of hashes. Are these the individual transactions hashes or something else? If they are really transactions hashes, does the client keep the unhashed transactions in other structure and do I access it through other command?

Read the fine manual!

$ ./src/bitcoin-cli help getblock
  getblock "blockhash" ( verbosity )
If verbosity is 0, returns a string that is serialized, hex-encoded data for block 'hash'.
If verbosity is 1, returns an Object with information about block .
If verbosity is 2, returns an Object with information about block  and information about each transaction.

So if you add a 2 to the end of the RPC request, you'll get the full transaction contents rather than just the hash.


text:
Electrum paper wallet exploit
I want to generate a paper wallet with Electrum using my personal computer that I've been using for a few years now, meaning that I'm online with it daily.
I know that the optimal solution is to use a computer that has never been connected to the internet, but I'm curious if there are any reports of malware compromising this kind of setup.
(I'm considering this setup because where I'm from it is not so easy/fast to get a hardware wallet)

Go offline
Generate seed words
Copy them to paper
Delete wallet from computer

It's more safe to do it on "clean" operating system.
I can propose another solution:

Prepare DVD or USB stick with Ubuntu operating system
Start live session of Ubuntu from DVD or USB stick on your computer
Download Electrum AppImage from official Electrum website
Run Electrum, generate seed
Switch off computer, all data will be lost


text:
What is a good hardware for a lightning network node?
What is the hardware setup you use for your LN node? Is a Raspberry Pi 3 enough for testing and playing with small amount of funds?

Lightning itself is a pretty lightweight protocol and can easily be run on a raspi 3. However without neutrino a lightning node needs to have access to a Bitcoin full node. Most people seem to run the Bitcoin node on the same machine as the lightning node. While a raspi3 can run both the processor is a little week to verify the entire blockchain. So expect a long time (couple of weeks) for initial blockchain sync or run a remote Bitcoin node.

I'm using a Raspberry Pi 3B (with 64GB card) and an external HD that contains the blocks. So far it works fine, CPU temp is around 57°C.
Syncing took a few days (2 or 3). I used the RaspiBlitz image + tutorial. This installs step by step your Bitcoin node and your Lightning wallet.
https://github.com/rootzoll/raspiblitz
As it's hosted at my place and I want to have a public node, I also did port forwarding (n° 9735).

To use lightning you will need a Bitcoin full node.
As hardware you can use:

PC/Laptop
Dedicated Server(VPS Server)
Raspberry Pi 3(With external HD)
...

If you want to use the Raspberry Pi 3 make sure to sync the Bitcoin blockchain on an external more powerful device and then move the blockchain to your Raspberry Pi 3 Harddrive. As Rene Pickard pointed out, the Raspberry Pi 3 is not so powerful and syncing there would take some time.
You can also try Neutrino(experimental) or use a remote full node and connect via rpc.


text:
Create Output with a bunch of input
I want to spend 1 bitcoin, And I can reach this amount with 3 inputs.
for example:
1 input = 0.5 btc
PB mypubkey_1
PK mypkkey_1
2 input = 0.4 btc
PB mypubkey_2
PK mypkkey_2
3 input = 0.15 btc
PB mypubkey_3
PK mypkkey_3
which private key use to Sign this transaction?
I will use mypkkey_1,mypkkey_2,mypkkey_3 or parent private key or something like that?

which private key use to Sign this transaction?

When you have a transaction with multiple inputs, each input must be signed. The general format for a transaction is:
Transaction
{version} {flag (optional)} {input counter} {inputs} {output counter} {outputs} {witnesses (optional)} {lock time}

version (4 Bytes) - Transaction format version
flag (2 Byte Array) - Optional flag, if present, must be 0001, which indicates there is witness data in this transaction
input counter (Variable Length) - Number of inputs in the transaction represented by a Variable Length Integer.
inputs (based on Input Counter) - List of all transaction inputs which will be spent and which reference unspent transaction outputs from previous transactions.
output counter (Variable Length) - Number of outputs in the transaction represented by a Variable Length Integer.
outputs (based on Output Counter) - List of all transaction outputs where the coins will be sent and which will become unspent transaction outputs to be spent in future transactions.
witnesses (variable) - Optional list of all witnesses only if Flag is present, which are used in transaction validation according to specifications for Segregated Witness.
locktime (4 Bytes) - If non-zero and sequence numbers are < ffffffff: it represents either the block height or timestamp when transaction is final.

Inputs
And the general format for each input is:
{previous tx hash} {previous utxo index} {scriptSig length} {scriptSig} {sequence number}

previous tx hash (32 Bytes) - Hash of the previous transaction. This is used to lookup the transaction in order to validate that this input can be spent.
previous utxo index (4 Bytes) - Previous Unspent Transaction Output (UTXO) index. Since transactions can have multiple outputs, in order to specify which output, you can provide a zero-based index.
scriptSig length (Variable Length) - Length in bytes of the scriptSig.
scriptSig (based on scriptSig length)- The first part of the script that is executed before the scriptPubKey from the UTXO. When they are both executed in order, the result must be true in order to be considered a valid spend.
sequence number (4 Bytes) - Used as a relative lock time if transaction version is >= 2. See BIP68.

You can see that each input requires a scriptSig, which is where the signature is (unless it is a segwit tx, then it is in the witnesses field in the transaction above)


text:
Get Master Private Key from BIP39 Seed
I have BIP39 Seed:
5b56c417303faa3fcba7e57400e120a0ca83ec5a4fc9ffba757fbe63fbd77a89a1a3be4c67196f57c39a88b76373733891bfaba16ed27a813ceed498804c0570

I want to get Master private Key
Then I Have to use HMAC-SHA512, I can use this site, which secret I have to add ? I don't have any secret, for test  I choose "mnemonic", the same constant that I use to generate BIP39seed (is it correct? )
the result is:

9744d0d7e168f725b6cc36a73c24dfc91bd6d80bf5a6871ad2c6c0b854e4e281b74049c41d25f0b338b3fc9b053b87b95636c3c94c31f37458fe98a09a4a94c9

and I can get
left 256 bits  => 9744d0d7e168f725b6cc36a73c24dfc91bd6d80bf5a6871ad2c6c0b854e4e281
right 256 bits  => b74049c41d25f0b338b3fc9b053b87b95636c3c94c31f37458fe98a09a4a94c9

And I can Get master private key in this way?
PKM = bx ec-to-wif 9744d0d7e168f725b6cc36a73c24dfc91bd6d80bf5a6871ad2c6c0b854e4e281

result:
  L2Hku6wzwvWnHAct8TmtfvviE4QXBTXtZrae2buXwjq5mRG4doF2

but this result is not in https://iancoleman.io/bip39/ If I import my mnemonic phrase

(army van defense carry jealous true garbage claim echo media make crunch)

Here are the mechanics for "Mastering Bitcoin" Creating an HD Wallet from the Seed using  bitcoin-explorer and this Python HMAC command.
Root Seed:
% echo "army van defense carry jealous true garbage claim echo media make crunch" | bx mnemonic-to-seed -p ""
5b56c417303faa3fcba7e57400e120a0ca83ec5a4fc9ffba757fbe63fbd77a89a1a3be4c67196f57c39a88b76373733891bfaba16ed27a813ceed498804c0570
Master Private Key:
% echo 5b56c417303faa3fcba7e57400e120a0ca83ec5a4fc9ffba757fbe63fbd77a89a1a3be4c67196f57c39a88b76373733891bfaba16ed27a813ceed498804c0570 | bx base16-decode | hmac --algorithm sha512 --key "Bitcoin seed" - | cut -c 1-64
b2a0d576b828b537688b561f2cfa8dac3602d54c62bde619ad5331e6c235ee26
Master Public Key:
% echo 5b56c417303faa3fcba7e57400e120a0ca83ec5a4fc9ffba757fbe63fbd77a89a1a3be4c67196f57c39a88b76373733891bfaba16ed27a813ceed498804c0570 | bx base16-decode | hmac --algorithm sha512 --key "Bitcoin seed" - | cut -c 1-64 | bx ec-to-public
03ca72b45eede592f059b7eaf3da13eb7d8d15aa472b6f79f74820bb22ff596186
Chain Code:
% echo 5b56c417303faa3fcba7e57400e120a0ca83ec5a4fc9ffba757fbe63fbd77a89a1a3be4c67196f57c39a88b76373733891bfaba16ed27a813ceed498804c0570 | bx base16-decode | hmac --algorithm sha512 --key "Bitcoin seed" - | cut -c 65-128
b70d675323c40ec461e0a6af603b1f135fb2af9ae753eeff18922732a73b0f05

Can I  add two secp256k1 keys together with bx ?

For cyclic ordinate “Normalization”, you will want to examine bx ec-add-secrets and ec-multiply-secrets

What is the use of a master public key? Can I see all the the public addresses derived from that HD wallet?

Instead of all of that decoding, hashing and cutting you can just use the bx hd-* commands :). hd-new, hd-private, hd-public, hd-to-address, hd-to-ec, hd-to-public, hd-to-wif.

which secret I have to add ? I don't have any secret, for test I choose "mnemonic", the same constant that I use to generate BIP39seed (is it correct? )

No, that is incorrect. You use the key mnemonic when converting the BIP 39 mnemonic to a seed. You already have the seed, so you don't use the key mnemonic. You should instead be following the steps described in BIP 32.
So you need to use HMAC-SHA512 with the key Bitcoin seed. Furthermore, the site that you used hashes the input as a string, not as the bytes represented by the hex values. This will result in the wrong hash. You need to use a different site. I used https://cryptii.com/pipes/hmac and converted the key Bitcoin seed to it's hex representation using https://www.asciitohex.com/. Setting the input to be hexadecimal bytes and setting the key to be the hex form of Bitcoin seed results in the hash:
b2a0d576b828b537688b561f2cfa8dac3602d54c62bde619ad5331e6c235ee26b70d675323c40ec461e0a6af603b1f135fb2af9ae753eeff18922732a73b0f05

If we look at the master private key we get from your mnemonic (listed as BIP 32 root key on https://iancoleman.io/bip39/), we see that its private key and chaincode are the same as the above hash.


text:
Each full node has different mempool?
I don't understand if each full node has different mempool inside.
With RPC command getblocktemplate I can Get the information about candidate block.
I can Find all transaction verified but unconfirmed
And I can find even bits and target, the value for mining.
My mempool is different from another node?
I have to Update my mempool before build candidate block ?

The getblocktemplate is designed for miners, and is constructed from the local mempool. All miners necessarily need a validating full-node to provide them with unconfirmed, valid transactions.
The mempool differs from one node to the other, and this may not be so relevant for merchants or individuals validating transactions, but this is highly relevant for miners, increasingly so as the transaction fee part of the block reward increases over time.
The sooner your node is able to accept new valid transactions, the more efficiently you can mine for blocks with the highest fees. The blocktemplate function reflects this. A well-connected node will produce block templates optimised with better fees than one that only has a subset of the transaction mempool.
Some may argue that transactions make up only a small part of the miner reward, and in some cases today mining empty blocks may be worth the extra hashing time that would otherwise be idling whilst the most optimal block template is constructed. This may be true today, but the system security rests on the incentive of miners to confirm a given transaction. This is the confirmation fee-market between users and miners.
If miner rewards solely consisted of subsidy (inflation), there would be no opportunity cost to censorship, and therefore the system security would be zero. Therefore, a system that allows data to propagate across mempools as efficiently as possible, facilitating the creation of the most rewarding block templates is highly relevant for the confirmation fee-market to function efficiently.

The mempool of all nodes is different, but this isn't an issue. There will always be some inconsistency due to latency, network conditions, and differing configurations. This doesn't measurably impact your income and won't effect the validity of blocks you produce.

thanks, Im runnung a full node, with command getblocktemplate I get always the same bits o target since 1 week. I have the update the mempool?

The “bits” is the difficulty of the block, which is updated every 2 weeks. This is unrelated to the men pool.

thanks, then the mempool auto-update every 2 weeks? Txs and bits ? or Txs update every time a new block created from the network ?

No the mempool updates whenever a new valid transaction is accepted, which originated from a connected node. The difficulty adjusts every 2016 blocks, to be precise, not every 2 weeks.

Your mempool state will definitely affect your income as a miner, see answer below.

If the difficulty adjustment occured every two weeks, there would never be an adjustment, and hashrate globally would need to be fixed, which is an impossibility.

It’s a close enough approximation though.

I know what u mean, but it masks the reason why the diff adjustment exists. It exists SO that 2016 blocks occur every approx 2 weeks.

@JamesC. the mempool updated means  evend remove transactions confirmed in the tip block and add the new tx unconfirmed?

Correct. All transactions confirmed in blocks are removed from the mempool. And new unconfirmed ones added. Mempool is a misleading term, because it doesnt have to be in memory. The only differentiation needed to be made are confirmed (in blocks of the strong chain) and unconfirmed (valid, not in blocks of the steong chain). You could call the mempool all valid unconfirmed transactions your node has seen so far.


text:
Script and DER in P2PKH
Im trying to figure out the script and DER
In P2PKH, the "first part (scriptsig)" push in stack (<sig><pubK>) because is it DER?
Instead  the "second part (scriptPubKey)" you can map the byte on https://en.bitcoin.it/wiki/Script
Or even the first part you can map with script?

I don't understand the question, please elaborate.


text:
Wallet error ErrorFile=.... /testnet3/wallets/db.log
I want to use two deamon for sync mainnet and testnet.
I Run $ bitcoind for mainnet without problem
After I run $ bitcoind -testnet But I get this error
BerkeleyEnvironment::Open: LogDir=/home/bitcoin/.bitcoin/testnet3/wallets/database ErrorFile=/home/bitcoin/.bitcoin/testnet3/wallets/db.log

When I run the testnet, bitcoind creates testnet3 folder
I'm using bitcoin 0.17.1
My conf
# /home/bitcoin/.bitcoin/bitcoin.conf

# remove the following line to enable Bitcoin mainnet
# testnet=1

# Bitcoind options
server=1
daemon=1

# Connection settings
rpcuser=xxxxxxxx
rpcpassword=xxxxxxx

onlynet=ipv4
zmqpubrawblock=tcp://127.0.0.1:28332
zmqpubrawtx=tcp://127.0.0.1:28333

# Raspberry Pi optimizations
dbcache=100
maxorphantx=10
maxmempool=50
maxconnections=40
maxuploadtarget=5000


text:
Simulate HTLC in regtest c-lightning
I have three nodes in regtest environment l1, l2, and l3
l1 create a channel with l2
l2 create a channel with l3
l3 create an invoice for l1.
l1 can pays it because use the route l1-l2-l3
I presume that here c-lightning use HTLC to accomplish it.
Where can I debug the script?
I'd like to see something like this
IF
  # Payment if you have the secret R
  HASH160 <H> EQUALVERIFY
ELSE
# Refund after timeout.
<locktime> CHECKLOCKTIMEVERIFY DROP <Payee Pubic Key> CHECKSIG
ENDIF

In order for you to see these scripts you'll have to force the channel on-chain, along with the HTLC. Only then will the HTLC be swept using the script, otherwise you'll only see the P2WSH output for the HTLC being added and then removed if the payment succeeds or fails.
Under normal operation you wouldn't therefore see the HTLC. When testing c-lightning we do however force this case, to verify that it is being handled correctly. There are two ways to force on-chain settlement:

Write a small plugin that simply holds on to the incoming HTLC on either l2 or l3 depending on which channel you want to observe the script.
If you compiled with DEVELOPER=1 you can also provide a file with instructions to disconnect if certain messages are seen. This is a bit more involved, but here's a test that shows how that works. It instrucs the l1 to disconnect as soon as it gets a WIRE_REVOKE_AND_ACK message which completes the addition of the HTLC.

Once the HTLC is stuck at some point you can generate a number of blocks until the HTLC timeout approaches, at which point the nodes will publish a unilateral close. Once the channel is closed, and the HTLC timeout expired, the nodes will sweep the HTLC output with the script you're looking for.

Thanks for reply. I already installed on my mac, i tried again ./configure --enable-developer and then make DEVELOPER=1, but I get an error: tools/mockup.sh: line 12: syntax error near unexpected token ;;'I tried even with justmake` but I get the same error

That sounds a lot like the bash on Mac isn't really compatible with the script. Can you maybe file an issue and we can see how we can fix it.


text:
Cheat Lightning network (c-lightning)
I want to understand how cheat lightning network using c-lightning.
I understand that if a participant of che channel send not last commitment transaction, it means that he tries to cheat. I'd like to replicate this scenario.
I tried to dump commitments, and I found these informations.
    $ ./hsmtool dumpcommitments 022f495a897360fdd287f7a823302479e62856e47727c0c8c9688faf45f4a92aac 1 2
/tmp/l1-regtest/regtest/hsm_secret mypass
    shaseed: 14d384a3757ea8c750d1325997ed7c0761b1cf2a8845ae0aaf5b6c783bcbe8ef
    commit secret #0: 9d202a2c4df2792d4d77583b969d407dc0b31e9ff38bb9121932ac55e536202e
    commit point #0: 039f4232478aa0629637ba2d8fd9808bd3d06342b5fbc67699d2f09bc1a9c844ad
    commit secret #1: 8cf246e819e78d34ce331f897652909bdc7104b6eac173a4180be1bbcfc46f37
    commit point #1: 03cacc020bcc3a322c41854a3b0337643b5e9b10af79f96ba14ccf4637cd56ba8f

Where can I find the first transaction in order to try to cheat?
Because I want to understand how penalties work and i'd like to decode all commitments transaction

c-lightning doesn't store old versions of the commitment transaction, exactly in order to avoid accidentally cheating. If you compiled with DEVELOPER=1 you can however call lightning-cli dev-sign-last-tx {peer-id} and it'll spit out the fully signed commitment transaction (that's why dev-* commands are dangerous and should not be used if you don't know exactly what you're doing, which is the case here).
Once you have the signed commitment, just perform some other action that creates a new commitment (feerate adjustment, send or forward a payment) and then send the now invalidated commitment transaction you got from dev-sign-last-tx to the network using bitcoin-cli sendrawtransaction and confirm it by generating a block. Both nodes should see the unilateral close and identify it as a cheat transaction. The cheating node will give up, since there's nothing it can do, and the cheated node can punish the cheater by claiming all the funds.


text:
Review of multisig funds protection strategy
I want to protect my bitcoin and my threat model is that one of the two paper copies of the seed is accessed to recover the wallet and steal the funds. To mitigate this risk I am contemplating the options of a 2-out-3 multi-sig wallet. My first strategy is as follows:

I have therefore 4 geographically separate and secret locations (excluding myself). In terms of hardware wallets with me, I only have 1 which means if the main device is stolen, my bitcoins are safe as one more key is needed. The same is true if locations 1 or 2 are uncovered and a hardware wallet devices were to be stolen (as just one hardware wallet is there). However, taking the seed perspective, two seeds would be compromised.
My first question is whether an attacker can steal the funds with the two seeds uncovered or if 3 seeds are a must in order to recreate the wallet and take the funds? (I am assuming that if the attacker would have access to the 2 seeds to recreate private keys and the multisig wallet that was set up on my personal computer is not possible). I think that is the case, because recovering multisig wallet on Electrum requires 3 seeds (or 1 seed and 2 public keys of the co-signers), but wanted to double-check with the community that indeed no bitcoin can be moved with just two seeds uncovered. Note that with this setup it is effectively cold-cold storage as moving bitcoin, in this case, requires going to either location 1 or 2 to take either hardware wallet 1 or 2 to co-sign with the hardware wallet 3.
The other option is to create a hidden wallet with a passphrase using just one wallet. In that case 2 copies of seed and 2 copies of the passphrase can be stored in 4 geographically distinct locations. If the seed is uncovered then the hidden wallet can't be accessed and if the passphrase is accessed then the hidden wallet can't be recreated too. The only vulnerability in the latter case is if the hardware device was stolen and used to move the money (either by tampering with it physically or by directly using it although usage can be restricted with the device PIN).
My second question is whether the first option gives a significantly higher entropy for the protection. Note that in terms of costs of storage the cost would be the same as in both cases we must make use of 4 locations.

My first question is whether an attacker can steal the funds with the two seeds uncovered or if 3 seeds are a must in order to recreate the wallet and take the funds?

With a 2-of-3 multisig 2 of the 3 private keys are needed to sign the transaction to move funds from it (and knowledge of the third public key but this shouldn't be used as a protection against attackers). I suspect from reading your question that you don't understand what a seed is for a HD wallet. A seed doesn't offer any additional protection, the seed is used to generate more private keys (and public keys). If an attacker gets access to this seed it can generate all the private keys from this seed that you can.
If you have three independent seeds for three independent HD wallets and you use a private key generated from each seed then an attacker would need to access two of the three private keys (or two of the three seeds, these can be used to generate two of the three private keys) to move funds from a 2-of-3 multisig.

The other option is to create a hidden wallet with a passphrase using just one wallet. In that case 2 copies of seed and 2 copies of the passphrase can be stored in 4 geographically distinct locations. If the seed is uncovered then the hidden wallet can't be accessed and if the passphrase is accessed then the hidden wallet can't be recreated too.

This offers no additional protection to a 2-of-3 multisig (an attacker still needs to access 2 locations) and it requires an additional geographical location (4 rather than 3 in the 2-of-3 multisig case). A passphrase also typically has less entropy than a seed depending on its length. The shorter the passphrase the easier it is to brute force. The advantage to this particular scheme would be that today it is easier to implement as most (all?) hardware wallets support encrypting a seed with a passphrase. Hardware signing support for multisig schemes is less widespread.

My first question is whether an attacker can steal the funds with the two seeds uncovered or if 3 seeds are a must in order to recreate the wallet and take the funds?

They can steal funds if they have:

The keys
The multisig descriptor

You should put your multisig descriptor at each location and/or somewhere that can securely store it. The threats from a leaked multisig descriptor is only a loss of privacy.
Please don't rely on your wallet descriptor being secret and instead assume 2-of-3 security with one key being leaked being safe.

In that case 2 copies of seed and 2 copies of the passphrase can be stored in 4 geographically distinct locations.

Having 2 copies of a seed increasees the chance of compromise. If you want more copies, use 3-of-5.

Thanks for that. OK correct me if I'm wrong but what I get from what you say is that with 2-of-3 multi-sig wallet, the loss of two seeds AND descriptor will not compromise the safety of funds (only privacy) because 3 seeds are needed to reconstruct the wallet and steal the funds. Correct?


text:
Wasabi Wallet 2.0 coin control. How secure / private are sent coins now?
I have a wallet which contains several small coins each with a different level of privacy (Coin Join rounds) which generated in the Wasabi 1.1
I wish to send an amount which I would like to remain as high private. Now there is no coin control how can I be sure that the most mixed coins are used rather than ones that are unmixed in my wallet ?

I wish to send an amount which I would like to remain as high private.

If that is truly your goal, then just use the wallet normally. From a privacy point of view there were significant improvements to the send process:
There are 3 kinds of coins in your wallet:

private: coins reached your anonscore target
semi-private: coins those reached at least anonscore 2
non-private: anonscore 1 coins

When your wallet is in a half-mixed state,

then Wasabi 2.0 will first try to make the transaction from your private stash.
If it cannot, then it'll try to combine your private and
semi-private stash.
If it still cannot make a transaction, then
it'll pop up an option for you to select the clusters that you want
to make the transaction from. This is a more advanced form of coin
control, in the sense that you aren't selecting individual coins
here anymore, but you're selecting a cluster of coins, identified
though labels, created by intra-wallet blockchain analysis:

For completeness it must be also noted that, you can still view your coins and selectively spend them by clicking CTRL+C+D.

As stated in the answer, 1 and 2 only happens when the tx can be made solely from private UTXOs. If the tx can be made only by involving non-coinjoined coins, then the user is required to do cluster control.

@nopara73: I've edited your answer to remove the insult, leaving your response to the comment intact. Just to set some expectations: we don't condone insults and unsubstantiated accusations here. People can be skeptical of your product without being treated as enemies. Please engage with content, do not disparage other users. If you see egregious errors in other people's content about your product where it amounts to misrepresentation, raise a flag and we'll look at it.

Although I don't think remarking the account not being a real one classifies as an insult, I do think using the flag button would had been more appropriate. I'll do that next time!


text:
can MITM read my metamask seed phrase when I click "Reveal Secret Recovery Phrase" in the wallet?
I worry someone is leaching my WiFi and potentially trying to do a MITM attack. If I click "Reveal Secret Recovery Phrase" in my metamask wallet extension, will they be able to read it via WiFi?
Or is it revealed just locally on my machine and no plain text is sent over the router?
I'm no computer expert so I'm not even sure if this question makes any sense.
I have a wifi extender paired with router via qss.

No a MITM won't be able to see it unless you transmit it in plaintext across the wire (e.g. into a personal web app using HTTP instead of HTTPS).
You should be more worried about man in the browser (e.g. malicious extension), or malware on your device. In this case an attacker could retrieve local data, see your clipboard, or take screenshots which may reveal your seed phrase.
An attacker might also switch out a transaction about to be signed with a malicious transaction (one they crafted), and when you sign it you end up signing their transaction (e.g. to empty your wallet).
This is unlikely - but possible. The more you download pirated software or go on malicious website the more likely you are to be infected with something that has access to your machine and can do the above.

Your secret key is locally placed in your system it won't be send through your router


text:
What makes a valid scriptSig in coinbase?
Per BIP 34, the scriptSig should contain the height number in little endian.
Suppose the target height is 777888, which is a0de0b in little endian.
And, the extra data I want to append is a 5-byte world "hello", which is 68656c6c6f in hex.
Concatenate (encode) the height and extra data, resulting in:
03a0de0b0568656c6c6f
Does this make a valid scriptSig in the coinbase transaction?
Do I need to add other op-codes so that the evaluation of the ScriptSig is valid?
Thank you.

Related: https://bitcoin.stackexchange.com/q/20721/5406


text:
C-Lightning Gossiping and Channel announcements
I am super new to lightning development and just starting to play around with stuff and wanted to execute some circular rebalancing payments, but was confronted with problems coming from the getroute method
My problem: I setup a regtest graph consisting of 3 nodes
A<—(25Ksat)-(40Ksat)-(15Ksat)—>B<—(35Ksat)-(65Ksat)-(30Ksat)—>C<—(60Ksat)-(90Ksat)-(30Ksat)—>A.
From the node A I execute
lcli getroute <C_ID> 5000sat 0 <TRIED_ALL_VALUES> <A_ID> 100.0 ["<C_ID>"]
excludes contains C_ID to avoid showing direct connections. When excludes contains <A_ID> the direct connection is proposed. I hope to see the A—>B—>C route, but only get A—>C.
Now, all the channels I created are publicly announced, but if I try to execute lcli listchannels on any of my nodes, I end seeing only my channels. What did I miss? Additionally, if I execute lcli listnodes I only see my direct peers, not the other nodes on the network. As if the announcements on the gossip network do not come though.
I am super grateful for any hint or thought!
Every node has the same config. Here are the configs from lcli listconfigs (except the plugins section, which is quite large and would be distracting):
{
   "# version": "v0.12.1",
   "conf": "/root/.lightning/config",
   "lightning-dir": "/data/lightning",
   "network": "regtest",
   "allow-deprecated-apis": true,
   "rpc-file": "lightning-rpc",
   "plugins": [...],
   "important-plugins": [...],
   "always-use-proxy": false,
   "daemon": true,
   "wallet": "sqlite3:///data/lightning/regtest/lightningd.sqlite3",
   "large-channels": false,
   "experimental-dual-fund": false,
   "experimental-onion-messages": false,
   "experimental-offers": false,
   "experimental-shutdown-wrong-funding": false,
   "rgb": "03dac7",
   "alias": "IRATEGENESIS-v0.12.1",
   "pid-file": "/data/lightning/lightningd-regtest.pid",
   "ignore-fee-limits": true,
   "watchtime-blocks": 6,
   "max-locktime-blocks": 2016,
   "funding-confirms": 1,
   "cltv-delta": 6,
   "cltv-final": 20,
   "commit-time": 10,
   "fee-base": 0,
   "rescan": 30,
   "fee-per-satoshi": 0,
   "htlc-minimum-msat": "0msat",
   "htlc-maximum-msat": "18446744073709551615msat",
   "max-concurrent-htlcs": 483,
   "max-dust-htlc-exposure-msat": "50000000msat",
   "min-capacity-sat": 10000,
   "disable-ip-discovery": false,
   "offline": false,
   "autolisten": true,
   "disable-dns": false,
   "encrypted-hsm": false,
   "rpc-file-mode": "0600",
   "log-level": "info",
   "log-timestamps": true,
   "log-prefix": "",
   "log-file": "/var/log/lightning/lightningd.log"
}

And here is the result of lcli getinfo:
{
   "id": "03dac78928a90839c2e7a4ba1e5a1567466f944ba1345cfe1fee9da226f1a34aef",
   "alias": "IRATEGENESIS-v0.12.1",
   "color": "03dac7",
   "num_peers": 2,
   "num_pending_channels": 0,
   "num_active_channels": 2,
   "num_inactive_channels": 0,
   "address": [],
   "binding": [
      {
         "type": "ipv6",
         "address": "::",
         "port": 19846
      },
      {
         "type": "ipv4",
         "address": "0.0.0.0",
         "port": 19846
      }
   ],
   "version": "v0.12.1",
   "blockheight": 162,
   "network": "regtest",
   "msatoshi_fees_collected": 0,
   "fees_collected_msat": "0msat",
   "lightning-dir": "/data/lightning/regtest",
   "our_features": {
      "init": "08a000080269a2",
      "node": "88a000080269a2",
      "channel": "",
      "invoice": "02000000024100"
   }
}

Which node implementation are you using? I could not guess from the lcli name (LND client is usually lncli, C-lightning client lightning-cli).

From the syntax of getroute I infer it is C-lightning.

Since the issue was present on regtest environment only, I found out that the channel establishment didn't collect enough confirmations. In the environment I have been using, it was enough to change the behaviour of the mining nodes to mine new blocks more frequently, while on polar for example I did quick mining for several times. For other ways to simulate mining refer to Bitcoin regtest mining.
I found out that the channel get announced after at least 6 confirmations

The exclude parameter is a channel ID, not a node ID. You should specify the ID of the A<->C channel (in the right, or in both directions), in order to exclude the A->C direct path.
See the documentation of getroute in the help of lightning-cli (of C-lightning): lightning-cli help getroute.
"exclude is a JSON array of short-channel-id/direction (e.g. [ "564334x877x1/0", "564195x1292x0/1" ]) or node-id which should be excluded from consideration for routing.  The default is not to exclude any channels or nodes. Note if the source or destination is excluded, the command result is undefined."

Thank you for you answer! If you take a closer look at the very same piece of documentation you provided, you will see:
or node-id which should be excluded from consideration for routing
Additionally, I copied this behavior from one of the most supported plugins in the lightning environment - rebalance.py.


text:
bitcoin-core building disabled binaries
good day,
I have just tried upgrading to core 24. As I am looking for a purely headless bitcoin-core, my process was the following
rm -rf bitcoin
git clone https://github.com/bitcoin/bitcoin.git
cd bitcoin
./autogen.sh
/configure --without--gui --disable-wallet --disable-tests --without-miniupnpc  --enable-fuzz-binary=no --disable-man --without--gui --without-natpmp --disable-bench
make && sudo make install

My understanding is that this should not build bitcoin-qt as well, which is, however, built as well?
Any ideas would be appreciated.

You have --without--gui instead of --without-gui, could that be the problem?

"make" only the targets you need, instead of the default target


text:
Why aren't bitcoin transactions sent this way?
I am currently studying how bitcoin works and the motivations behind the design decisions. I understand that the way transactions are sent works essentially like this (correct me if I'm wrong)

Each transaction needs a sender address, receiver address and signature (for authorization)
Each transaction needs a list of unspent transactions sent to the sender address in order for the sender to prove he has enough coins to be able to afford the transaction he wants to send.
In order for the miners to verify the transaction, they need to confirm that the unspent transactions are real by looking for them in the blockchain. This can be made effective by storing transactions in merkle trees, otherwise it would be very expensive for the miners to find the unspent transactions.

It seems to me that a better way of accomplishing the same task would be for each miner to seperately store a list of all addresses coin-balances which are used to verify that the sender has enough coins to afford the transaction. The balances would have to be updated everytime a new block is mined. This method would make the protocol a lot simpler because transactions wouldn't need to come with a bunch of unspent transactions, and each block wouldn't need to generate or store any merkle trees.
Are there any severe disadvantages to the method I described above? Is there some security risk or would it somehow be very expensive for the miners?

correct me if I'm wrong)

Happy to help!

Each transaction needs a sender address, receiver address and signature (for authorization)

There are no addresses in the transmitted data.

Each transaction needs a list of unspent transactions

A transaction input is a pointer to one output of an older transaction

sent to the sender address

Addresses are not used as message destinations.

in order for the sender to prove he has enough coins to be able to afford the transaction he wants to send.

No one cares about the total amount of money the sender has. They only check that the money spent is genuine.

In order for the miners to verify the transaction

Everyone verifies transactions. Not just miners

they need to confirm that the unspent transactions are real by looking for them in the blockchain.

Usually nodes look up the inputs in a list of unspent transaction outputs that the node maintains.

This can be made effective by storing transactions in merkle trees, otherwise it would be very expensive for the miners to find the unspent transactions.

So far as I know, Merkle trees are not primarily used to speed up data retrieval of transaction data.

a better way of accomplishing the same task would be for each miner to seperately store a list of all addresses coin-balances which are used to verify that the sender has enough coins to afford the transaction.

Moving Bitcoin from being cash to being a bank-account is a pretty big conceptual change.
The main problem I see is having each of potentially 8 billion nodes keep track of the balances of 8 billion people. Is my phone more powerful than the computing centres of the worlds largest banks combined?
Currently each node typically keeps track of the total amount of money controlled by only one person. Currently no one needs to know how much money anyone else has. Currently no-one needs to trust miners or any other third party.

I think you nitpicked my description of how transaction are sent unecessarily, the addresses come in form of in- and out transactions. I think I described how it ESSENTIALLY works quite well. I also don't think the fact that the nodes would have to store a lot of balances would be a problem since they already store the entire blockchain which would be reduced by the fact that transactions are smaller.

The main problem with my idea I think is that it would need some gritty checks to make sure that transactions aren't spent twice in two different blocks. Not impossible, but maybe not as efficient as the current system. Didn't think about that while asking the question.


text:
Use hdseedid to give all addresses in bitcoin
I'm using bitcoin core version 0.18.1 and I'm studying Hd Wallet.
I can see the value hdseedid, and I understand that it's HASH160 of my hd seed.
Can I use this seed to retrieve all my keys?
I tried to put this value in https://iancoleman.io/ like entropia, but I don't find the same address that I can find in dumpwallet.

No, you cannot use that value for that purpose.
Bitcoin Core does not support publicly derivable addresses at all (at this point).


text:
Keep getting wrong bitcoin addresses
I'm trying to write a script that can generate a private key and the compressed and uncompressed addresses. It seems to work however the private key doesn't correspond to the addresses generated. Can't seem to find where I'm going wrong though...

import hashlib
import base58
import secrets
import ecdsa

# generate private key using secure random number generator
private_key = secrets.randbelow(2**256)

# convert private key to hexadecimal format
private_key_hex = hex(private_key)[2:]

# generate public key using private key and Elliptic Curve Digital Signature Algorithm (ECDSA)
public_key = ecdsa.SigningKey.from_string(bytes.fromhex(private_key_hex), curve=ecdsa.SECP256k1).verifying_key

# convert public key to hexadecimal format
public_key_hex = public_key.to_string().hex()

# generate uncompressed bitcoin address by hashing public key with SHA-256 and RIPEMD-160
uncompressed_address = hashlib.new('ripemd160', hashlib.sha256(bytes.fromhex(public_key_hex)).digest()).hexdigest()

# add prefix "00" to uncompressed address to indicate it is an uncompressed address
uncompressed_address = "00" + uncompressed_address

# generate checksum by hashing address with SHA-256 twice
checksum = hashlib.sha256(hashlib.sha256(bytes.fromhex(uncompressed_address)).digest()).hexdigest()[:8]

# add checksum to address
uncompressed_address += checksum

# encode address in base58 format
uncompressed_address = base58.b58encode(bytes.fromhex(uncompressed_address))

# generate compressed bitcoin address by adding prefix "03" to public key if it is odd, or "02" if it is even
if public_key_hex[-1] in ["1", "3", "5", "7", "9", "b", "d", "f"]:
    compressed_address = "03" + public_key_hex[:66]
else:
    compressed_address = "02" + public_key_hex[:66]

# hash compressed address with SHA-256 and RIPEMD-160
compressed_address = hashlib.new('ripemd160', hashlib.sha256(bytes.fromhex(compressed_address)).digest()).hexdigest()

# add prefix "00" to compressed address to indicate it is a compressed address
compressed_address = "00" + compressed_address

# generate checksum by hashing address with SHA-256 twice
checksum = hashlib.sha256(hashlib.sha256(bytes.fromhex(compressed_address)).digest()).hexdigest()[:8]

# add checksum to address
compressed_address += checksum

# encode address in base58 format
compressed_address = base58.b58encode(bytes.fromhex(compressed_address))

print("Private key:", private_key_hex)
print("Uncompressed address:", uncompressed_address)
print("Compressed address:", compressed_address)

Some key points here:

The private key cannot reach 2**256 because you must respect the order of the curve, which is n = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141. Set the interval to [1, n).
"add prefix "00" to uncompressed address to indicate it is an uncompressed address". It's not because of that. It's to indicate that the address is used for mainnet. If testnet, use 0x6f. (Only p2pkh)
The uncompressed public key has the format '04' + x + y = 65 bytes = 130 hex characters. I haven't seen any mention of it in your code. Make sure the variable public_key_hex follows the format.
The compressed public key has the format '02' + x or '03' + x, depending on the y is even or odd, respectively. (33 bytes = 66 hex chars)


text:
Has anybody ever got email in their doc saying they have funds from BTC Bitcoin bonus giveaway
So I got an email from in my docs saying that I had to go to this page and I had all mining earnimgs everything that I hadn't withdrawed from a year ago on on a platform I let them use my IP to mine saying I have a bonus is this a scam or is it for real it's BTC Bitcoin bonus giveaway. I do remember somewhat going on a site and them using asking the question to use for Mining and me saying yes but I never heard nothing else about it I never went back in there so I don't know if it's from them or what but I will need to know if this is a scam or not

that's how scams work


text:
Why does everyone talk about the blockchain being a record of transactions if it’s just a hash?
I’m trying to get to know how cryptocurrency works and everyone treats the blockchain like an active record of every transaction, like if someone wanted to reuse the same bitcoin with the same code identifier thingy specific to that bitcoin then they can’t because it has been used to create a hash that people have and are trying to create a new hash with? I really don’t get how a blockchain provides any security if it’s just a hash of all the transactions in the past with some additional metadata

Related: https://bitcoin.stackexchange.com/q/12427/5406

It's not just a hash. Though you can use a single hash to "represent" or "cryptographically fingerprint" the entire blockchain so that in just a glance you and everyone else in the network can verify the entire history on your both hard drives is identical.
There is an actual blockchain. It's a giant datastructure, today about 500 GiB in size, that holds every transaction ever made and confirmed in the Bitcoin network. But imagine comparing such a record with someone else. That would take maybe an hour if you could put a cable between you and the other person's computer and many hours if the other person was on another continent. Now try to do it with everyone that you try to interact with.
So, instead, we can use cryptography to fingerprint a piece of data. It's "cryptographically secure" which means it's astronomically hard for someone to cheat the fingerprint system. How it works is that each transaction itself, gets hashed. This hash is the fingerprint. Then for each block, each transaction fingerprint is built into a hash tree, resulting in a fingerprint of all the block's transactions. That fingerprint is then inserted into the "block header", a piece of data that contains some metadata of the block, like a timestamp and such, together with this fingerprint of all transactions, to form itself a fingerprint of the block. So we have a single fingerprint that identifies the block and all transactions in it.
Now, every block also contains the fingerprint of the previous block, that's why we call it a block chain. So if every block, mentions the fingerprint of the previous one and is itself again fingerprinted, that means that the fingerprint of the very last block indirectly fingerprints all the previous block and hence all transactions that have occurred inside those blocks.
So a single 32-byte (64 alphanumeric characters) can actually fingerprint the entire history of Bitcoin transactions.
Now of course, you wouldn't know the transactions as such. You would have to ask people about them. But you could both (1) once you have the fingerprint, validate that the history people are telling you about actually matches the fingerprint and (2) once you have all the history, compare your fingerprint with everyone else's to see if they match up.
I guess this answers your question.

I'd like to make a really small additional remark, though. As, of course having a fingerprint to compare with doesn't help if everyone in the room has a different fingerprint. Then all you can conclude is that they don't match, but what then? That's where Bitcoin mining's proof-of-work comes in. Bitcoin mining attaches a certain amount of computational work to a block. Apart from the crucial property that producing this work is hard, it also is easily mathematically quantifiable. This means that in a pretty fast and straightforward way, you can calculate the total work that has gone into a given fingerprint.
This way, in a room full of non-identical fingerprints, if everyone agrees on the mathematical formula to calculate the work and everyone agrees that they will concede to use the fingerprint with the most work condensed into it, this gives us a very efficient way for all the people in this room to agree on which fingerprint they're going to accept as the one they're going to take home as the real history of Bitcoin.

Thank you, i think maybe I can’t word my questions well but this was basically exactly what I wanted thanks


text:
Is it bad for a Bitcoin regtest address to have 1 as it's prefix
From the link below i read that it is dangerous for a Bitcoin regtest address to have 1 as it's prefix can someone explain why
The link :
Address starting with 2, what mode I am in?

i read that it is dangerous

You seem to have misread.
The accepted answer states that it would be, not that it is.
Having different prefixes for addresses in the different networks  makes it less likely that someone accidentally mistakes valueless test "money" for real money or vice versa expensively.

https://bitcointalk.org/index.php?topic=5146108.0

I think the reason why it is dangerous for a Bitcoin regtest address to have 1 as its prefix is because it could be confused with a mainnet address. A mainnet address is an address that is used on the real Bitcoin network, where transactions have real value and are irreversible. If someone accidentally sends real bitcoins to a regtest address that starts with 1, they would lose their money forever. Regtest addresses are meant for testing purposes only, and they should have a different prefix to avoid such mistakes.

I think Bitcoin regtest addresses should have a different prefix than testnet addresses, to avoid confusion and potential mistakes. Regtest addresses are used for local testing and development, while testnet addresses in cryptex are used for global testing and experimentation. If they both start with the same prefix, it is easy to mix them up and send coins to the wrong network. This could result in loss of funds or security issues. A distinct prefix would make it clear which network the address belongs to, and prevent such errors. I suggest using the prefix bcrt for regtest addresses, as proposed by BIP01731. This would make them compatible with bech addresses, which use bc, tb, and bcrt prefixes for mainnet, testnet, and regtest respectively.

I don’t think it is bad for a Bitcoin regtest address to have 1 as its prefix, as long as you are aware of the difference between regtest and testnet. Regtest addresses are the same as testnet addresses, except they use a private network for local testing. You can use any prefix you want for regtest, as long as it is valid for testnet. However, you should never use regtest addresses on the mainnet, as they will not work and you may lose your funds.


text:
Is there a way to identify exchanges in the blockchain?
Is there a way to identify transactions that occur on exchanges (such as Mt. Gox) in the blockchain?

To expand a bit on the above answer, blockchain.info provides information about several APis and exchanges here:
https://blockchain.info/api/3rd_party_apis

You can likely get a lot of trade information directly from the MTGox API, and match results up with the blockchain if needed.

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


text:
What does "Unable to decode output address" mean?
On BlockChain.info, I have noticed a few transactions which send money to "Unable to decode output address".
For example, here is one:
https://blockchain.info/tx/624928439d2f668bab9f4cc1d9c4d2bc62a9603d8109d73d4fff8cf3043b68bd
All of the ones that I have seen with this message have 0 Bitcoins associated with that transfer and then some other greater than zero amount of Bitcoins sent to a valid looking address.  These weird addresses also have their money marked as "unspent".  Do they ever get marked as "spent"?
What does this message mean and why are people sending Bitcoins this way?

If you look at the output script for that output, you can see it looks like this:
 RETURN PUSHDATA(32) [some garbage]

This script, beginning with OP_RETURN, is called a null-data output, and is used to store arbitrary data in the blockchain. These outputs can never be spent, there is no way to make the script ever evaluate to true. Because of this, they will always show up as unspent on blockchain, and can be pruned from full node UTXO sets.
In general it's required that these outputs are accompanied by at least one 'normal' output. Any bitcoins in an OP_RETURN output are destroyed forever because they cannot be redeemed, that is why they all have 0 value

Are you saying bitcoins could be in an OP_RETURN but that it would be silly to do so since they can never be redeemed?  To be honest, I got lost when you said "can be pruned from full node UTXO sets".  Thanks for your answer.

The UTXO set is the set of all unspent bitcoins in the whole blockchain. Full nodes use this set to check whether new transactions are spending valid outputs. These OP_RETURN outputs do not need to be stored there because they can never be spent

Click "Show scripts and coinbase" to see what that output really is. In this case it's RETURN PUSHDATA(32)[8013...]
RETURN (or OP_RETURN) causes the output to be unspendable.  The PUSHDATA then is just a way to insert the 32 bytes 8013... into the blockchain.
The significance of that data is not necessarily known to anyone except the person who created the transaction.  But one possibility is that it's a hash of some other piece of data, which the creator wants to be able to prove was in existence on the date of the transaction.  This has a number of possible applications: the data could be an unpublished scientific discovery, or a nonce used in a provably fair random number scheme, or many other things.
See op-return for other questions about this.

Wow, [tag:op-return] is a complicated area, thanks for the link, I'll have to read up more.

Unable to decode output is what Blockchain.info displays for any output that does not conform to a set of standard output script templates. Such outputs do not have associated addresses so there really isn't anything that a block explorer can show about them.
As stated by other answerers, the specific reason that this output could not be decoded is because it is an OP_RETURN output. There are many other things that could result in that message. Essentially any script that is not one of the standard templates will result in that message being shown.

Is there a list of standard templates or names for these templates?

Some of the templates and all of the names can be found here: https://github.com/bitcoin/bitcoin/blob/master/src/script/standard.cpp#L21

It's possibly omni data, such as tether, which blockchain.info can't decode, see https://www.reddit.com/r/omni/comments/5zs411/i_cant_receive_btc_unable_to_decode_output_address/ - used for coins like tether, safex, etc.
It's like ERC20 tokens on ETH, but on the BTC blockchain instead - these coins, e.g. tether, don't have their own blockchain, instead they are sent as data in a btc transaction, where the small amount of BTC sent with it is used as miners fee. For omni coins, data encoded with Omni Protocol is stored in OP_RETURN field, to decode this data it needs to be viewed with a compatible block explorer, e.g. http://www.omniexplorer.info, otherwise "Unable to decode output address" is displayed.

Are you saying that if I look up this address in particular on something like OmniExplorer that I should see some proof of it having Omni data associated with it?  Perhaps this proves this one isn't Omni data since nothing appears here.

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


text:
Solar Flare wipes all hard drives... What happens?
Imagine, for a moment, that a massive solar flare wipes out all hard drives on planet Earth.  All hard drives are wiped clean and with them all records of the Bitcoin blockchain.
Would we be able to recover?  Is there some alternate backup of the blockchain?  Do we hope that at least one computer is protected beneath ground?
I assume everyone's personal wallets would be lost unless they used paper wallets.  Certainly a big blow to the Bitcoin community.

This will never happen

Thank you for that link.  Could we still imagine, for the thought exercise, that it still happens?

All hard drives are wiped clean and with them all records of the Bitcoin blockchain.
Would we be able to recover?

Recover what? You stated all hard drives are wiped clean, so obviously we would not have a backup to recover the network from.

Is there some alternate backup of the blockchain?

Perhaps someone has printed the blockchain out onto paper. In an event like the one you've described, we should hope that there are many copies of this paper format blockchain, so that we don't have to trust that one person to have provided us with a copy of the blockchain history.

Do we hope that at least one computer is protected beneath ground?

If there was, then your premise of all hard drives being destroyed would be violated. Same as above, we should hope for many independent copies to surface, stored underground (or whatever) all around the world.

I assume everyone's personal wallets would be lost unless they used paper wallets.

Even if you used a paper wallet, if every record of the blockchain history was destroyed, your paper wallet would be useless. A paper wallet simply holds the private key capable of spending the bitcoin stored at it's corresponding address. If the blockchain record were lost completely, there would be no network to agree upon how much bitcoin is stored at that address. So a paper wallet that held 100 BTC before the catastrophe would be no different than one that held 0 BTC. With no blockchain to make a claim against, they would both be effectively worth 0 BTC.

Certainly a big blow to the Bitcoin community.

Sure, but any event catastrophic enough to knock the bitcoin blockchain out would be devastating FAR beyond that. Bitcoin is highly distributed, to destroy it would take an event of unbelievable magnitude. While I believe Bitcoin is important, there are many other systems more critical to our everyday life that would be affected also.

Thanks for entertaining the question.  I wonder how many pages it would take to print the blockchain out onto paper, but that's another question.

Also, good point about the paper wallets becoming useless even though they themselves survived the solar flare just fine.


text:
What is the way that fee is calculated in post-segwit bitcoin?
In pre-segwit bitcoin, process of calculating transaction fee was easy. Actually everything was based on the fact that the byte has its own value/price (estimated by network) and then fee is obtained as number_of_bytes * proce_of_single_byte. So, for example, if the price of one byte is 10 sats, then the fee for a transaction of 250 bytes is 2500 sats.
But what about calculating a fee in post-segwit Bitcoin?
In post-Segwit Bitcoin, bytes have a different value/price depending on the type of byte. So, if the byte is segwit then it is worth 4 times less than a non-segwit byte, that is its price is 4 times smaller. The question is: how is the transaction fee calculated in this case?
Is it done by not using bytes now, but vbytes and then they have a value (price)? And at that, each byte of non-segwit is one vbyte, while each byte of segwit is 0.25 vbyte? So, for example, if the price of one vbyte is 10 sats, then the fee for a transaction of 250 bytes (150 non-segwit, 100 segwit) is (150 * 10 sats) + (100/4 * 10 sats) = 1750 sats. So, in post-segwit bitcoin for calculating transaction fee we use (number_of_nonsegwit_bytes * price_of_single_vbyte) + (number_of_segwit_bytes / 4 * price_signle_vbyte)
Is this how software and miners calculate transaction fee?
I'm asking because here
Pieter Wuille said that vsize has no meaning except for humans, while bitcoin uses weight because of integer numbers. If this is true and vbytes are not actually used in softwares for calculating fee, how is the fee then calculated?

Related: https://bitcoin.stackexchange.com/a/84006/5406

@Murch I saw it, but still not clear to me whether weight or vbyte are used for calculating fee. In the second answer to the question you left the link for  zono said the following Miners consider fee(in satoshi) **per weight** of each transaction in order to maximize their profit. However, you said the following The virtual size corresponds to the blockweight which determines the fees. Pieter Wuille (I linked in question) said that vsize has no meaning except for humans and that Bitcoin uses weight because of integer numbers. So what does bitcoin softwares use?

If Pieter Wuille said "Bitcoin uses weight because of integer numbers", I would assume that is what Bitcoin core software uses.

So far as I can tell, it doesn't matter whether some software uses vbytes or weight to calculate a fee.
Neither the network nor the blockchain store fee rates. Even fees per transaction are implicit rather than explicit.
I believe some fee related rules such as minimum fee for relaying are node specific and don't affect consensus.
Fee rates are not fixed, each node is free to make its own estimates. Fees are simply a bid in a repeating auction of  block space so rounding errors don't matter much.
That auction is conducted by miners who want to maximise revenue while keeping within block size limits. If those size limits are expressed in weight units (WU), that is what I presume miners would be wise to use in calculations.
I don't know of any broader problem that would arise if some software estimates fee rates using floating point arithmetic based on vbytes while other software estimates fee rates using integer arithmetic based on weight.

Related:

What's the blocksize limit after segwit and how do legacy nodes deal with segwit transactions?

Before the activation of segwit, the block was limited to 1,000,000 bytes. This limit got replaced by a blockweight limit of 4,000,000 weight units (WU) with the activation of segwit.

Yes, the blockweight limit is forward compatible to the blocksize limit. I think it’s easier to sum up integers to 4,000,000 than it is to sum up fractions to 1,000,000, though.


text:
Off Line wallets
I am using Armory .96.4 with bitcoin core of .16.3
I have three wallets which two are encrypted ant the other is watching only. The watching has several bit coins and when I try to do a transaction from the offline wallet I get an error that says that
The wallet is watching only. Do I need to transfer to one of the encrypted wallets to get it to work with the offline wallet.

I would be willing to pay for help.

A watch only wallet means that your wallet contains only the addresses, but not the keys for those addresses. You need to sign the transaction using whichever wallet contains the keys. If you no longer have the keys, and have just watch only wallets, your BTC is inaccessible.

I am trying to help a friend that her husband passed away. I have armory.96.4 and bitcoin core .16.3 and it is synced and connected and online. I have two wallets that are encrypted and one that is watching only. The watching only has several bitcoins. So I try to do an offline transaction from the watching only and try to take it offline to sign. When I get it to the offline computer and try to sign it says that the wallet I am using is an offline wallet. Help needed.

In armory I am able to get the keys for the encrypted wallets but not for the watching wallet.

Very helpful. The two encrypted wallets have the root keys. I have even found one that has hex and base 58 numbers on it.  Do I need to try to send bitcoins from the watching wallet to the encrypted wallet?  I will try this evening and report my findings.

I have two wallets that are encrypted and one that is watching only. The watching only has several bitcoins.

Then you don't have the private keys that control the Bitcoin. They are not in the Watch-Only wallet.
Your friend's husband may have written down the private key on paper somewhere very very safe. It might look like this (hexadecimal)
E9873D79C6D87DC0FB6A5778633389F4453213303DA61F20BD67FC233AA33262

like this (WIF)
5Kb8kLf9zgWQnogidDA76MzPL6TsZZY36hWXMssSzNydYXYB9KF

or like this (minikey)
SzavMBLoXU6kDrqtUVmffv

Your friend's husband may instead have written down on paper a seed-phrase that looks like
witch collapse practice feed shame open despair creek road again ice least

From a private-key or seed-phrase you can create a Wallet that will give you control over the Bitcoin.
Do not ever give the private key or seed phrase to anyone else. Especially not to anyone claiming they can help you.
Somewhere between a fifth and a third of all Bitcoin have been lost forever, partly in circumstances like this. Without the private-key they are unrecoverable. That represents billions of dollars woth of money, if it were possible to recover lost Bitcoin we would know about it.
You need the private-key or the seed-phrase.
If the encrypted-wallets have a wallet-password you do not know, and you suspect those wallets contain the private-key (and therefore control the Bitcoin), you can try looking for a written-down copy of the password or try guessing the password based on what your friend knows about her husband's other passwords. People spend months or years and considerable amounts of money trying this approach.

Do I need to transfer to one of the encrypted wallets to get it to work with the offline wallet.

No, there is nothing useful in the watch-only wallet.

I would be willing to pay for help.

You'll get dozens or hundreds of offers to help, but I'd imagine they will almost all be from thieves and confidence tricksters.

Related questions:

Recovering bitcoins after the owner's death
Are there Bitcoin password crackers I can use to recover forgotten passwords?


text:
Could a network described below function and how well?
I have an idea I am working on for some time, it would be using blockchain technology. However, although I know something about blockchain as it stands today, I am lacking a more deepened knowledge about cryptographic primitives. So, because I couldn't find a definitive answer anywhere, I thought I will try here. As I am completely new to this forum, please inform me if my questions should be posted in another category.
So here are the questions:
Let's presume that in a peer-to-peer network there is a big volume of information going from one node to the other, however most of this info is private. So, a node:
1) signs his message (to authenticate source)
2) then encrypts it using symmetric cryptography
3) then encrypts the symmetric key (which will be used to decrypt the message) using public key of the recipient
4) and then on top of that he signs using his key both the message encrypted and symmetric key
So, finally, we have 2 things:
1) Message -> Signed by his private key -> Encrypted using symmetric cryptography -> Finally signed again (so the nodes on the network will know from which node it is coming from)
2) Symmetric key that will be used to decrypt message -> encrypted using asymmetric cryptography by intended recipient's public key -> and finally signed by sender's key, so the nodes will know the source of message.
The benefits of this is that we can send information over the network, no node relaying this info will know the content of it, and still every node will be able to confirm the identity of the sender and intended recipient will be able to finally decrypt message and also confirm the source of this message (as it is signed) even in decrypted form.
1) Are there any technical reasons why something like this wouldn't work?
2) Could such a way of privately send messages be used on a big network (size of bitcoin for example), where every node "pools" messages and sends to his peers? The problems I see is size of messages (it grows bigger by signing and encrypting like that).
3) I am sure of that, but I want to ask anyway - could node compare two messages it received, even if they are different, and find every two or more messages that were signed by the same public key (from same source)?
Of course there is a problem that as nodes "pool" messages, they won't know if the message was delivered or not. But that is not part of this question.
If there some expert who have time to answer such basic questions on this forum, I am deeply thankful.


text:
Will every message x reach all connected peers in time t?
I've asked similar question here:
Is gossip protocol in Bitcoin perfect?
But I didn't get an answer to my question really. I am ideating a consensus algorithm and I need definitive answer.
Can we take for granted that if in time period t there were 10,000 connected peers (no new peers connecting, no peers disconnecting), all with good internet connection and hardware, then if every of those 10,000 peers originated one transaction (or any kind of message) to his peers, can we take for absolutely granted that eventually every single one of those 10,000 connected peers have in his mempool all 10,000 transactions, including his own and those of 9,999 other peers and absolutely no transaction will be missing in mempool of any of those nodes (they will all have same set of data)? If yes, and would could be estimated time (seconds, minutes, hours)?
And now: things like double-spends, transaction correctness, peers connecting and disconnecting from network, etc. that happens in real cryptocurrency systems are not relevant here - this is a theoretical question and a theoretical situation.

If you drop all the practical reasons why propagation may not be perfect, then yes of course the result will be perfect. I don't understand what the answer is supposed to mean in that case. For example, the whole point of a cryptocurrency is resolving double spends - if you assume there aren't any, why do you care?

Related: impossibility result distributed systems with only 1 malicious process: https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf

Can we take for granted that if in time period t there were 10,000 connected peers (no new peers connecting, no peers disconnecting), all with good internet connection and hardware, then if every of those 10,000 peers originated one transaction (or any kind of message) to his peers, can we take for absolutely granted that eventually every single one of those 10,000 connected peers have in his mempool all 10,000 transactions, including his own and those of 9,999 other peers and absolutely no transaction will be missing in mempool of any of those nodes (they will all have same set of data)?

If you also include that no one is acting maliciously, then yes, under these perfect conditions with no malicious actors, you take for granted that a transaction will reach all nodes within some unknown time t. However, if there are malicious actors, then no.

If yes, and would could be estimated time (seconds, minutes, hours)?

This is impossible to know. It depends on the hardware, what the transactions consist of, the internet connection, etc. At best, it would probably take a few hundred milliseconds. At worst, likely a few minutes. Without more specific parameters, it is impossible to know.

Thank you. You said that in order for that perfect conditions to work, we need to include that no one is acting maliciously. So, given that a part of network would work maliciously, say 10%-30% of entire network, what effect on scenario presented above would it have? Would the effect (all messages reaching all nodes) be reached even with some malicious nodes in network, just with more time, or would malicious nodes completely prevent this? Or maybe it's just that malicious nodes themselves can pretend that they didn't received them that your speaking about?

I'm asking because as far as I understand the only thing that a malicious node can do in this given scenario is NOT to relay message. Maybe I need also to clarify that in this scenario all messages are asymmetrically signed so no malicious node can change the message, if that's what you think about. Thank you.

@user84415 If the honest node is only connect to malicious nodes, a message could be delayed indefinitely. Also keep in mind that not all nodes keep mempools, etc. It is generally more realistic and useful to assume adversarial conditions, than ideal.

A malicious node can broadcast conflicting messages. If they themselves originate the message, then they can broadcast one message to half of their peers, and another message to the other half. This means that at least some nodes will receive one message before the other and thus result in different mempools.

Thank you for answer. That is exactly what I was thinking about. But, even if malicious node will send one message to a half of his peers and different to other half, provided there is at least one honest node in each half, two messages will reach the network anyway, just some nodes will take one as the first (which they received first) and others will take the other one as the first. That is (messages deduplication and ordering) the double-spend problem that blockchain solves. For me, those answers are enough. Thanks.