text:
What is sigop (signature operation)?
I've seen the term sigop in many places frequently. I've tried to figure out what does it mean by searching, and found that it's abbreviation of signature operation. But it's still not clear to me the meaning. I guess every opcode of scriptSig is considered to be a sigop. Am I right?
I would appreciate any explanation.
Edit:
I think this question is completely different than this. My question is clearly about what is the sigop, while the other question is about calculation of sigops.

Does this answer your question? How are sigops calculated? -- note that there is a sigop limit for a block.

A sigop is script opcode which performs a signature check. That includes OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG, and OP_CHECKMULTISIGVERIFY.
This concept matters because of a consensus rule in Bitcoin which limits the number of sigops per block. How they are counted depends on the context:

In the scriptPubKey of outputs, and in scriptSig of inputs (the latter happens ~never, but if it did, it would be counted):

OP_CHECKSIG and OP_CHECKSIGVERIFY count as 4
OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY count as 80

In P2SH redeemscripts:

OP_CHECKSIG and OP_CHECKSIGVERIFY count as 4
OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY count as 4n when preceded by OP_n, and as 80 otherwise.

In P2WSH witness scripts:

OP_CHECKSIG and OP_CHECKSIGVERIFY count as 1
OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY count as n when preceded by OP_n, and as 20 otherwise.

In P2TR taproot scripts:

Sigops are not counted.

A valid block cannot have more than 80000 sigops (so roughly 1 per 50 bytes of block data), as counted by the rules above. Note that this is checked before actually executing any scripts. So it doesn't require these opcode to actually be executed (e.g. they also count sigops that are surrounded by OP_IF ... OP_ENDIF in unexecuted branches, or in coinbase scriptSigs which are never executed).
In taproot, a different mechanism is used. Instead of having a global per-block limit, there is a per-transaction-input limit, proportional to the size of that input. Also only actually executed checks for claimed-to-be-valid signatures are counted.

Thanks for your answer.
Sigops count matter because they're expensive to execute? Am I right?

Yeah, they make it illegal for blocks to contain so many signature checking operations that the block would be excessively slow to validate.

To add to Pieter's answer:
The sigops limit and how sigops are counted changed with the activation of SegWit in 2017. The sigop count in pre-SegWit scripts (P2PK, P2PKH, ...) was quadrupled. The block limit was increased from 20000 to 80000. See the sigops section in BIP-141: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#sigops


text:
Comparison between CPFP and BIP125 for fee bumping
As far as I understood so far, CPFP and BIP125 are both designed to help spenders to make new transactions using an input of an unconfirmed transaction by paying the cost. The most well known use case of them are when the spender wants his/her transaction confirm faster by raising the transaction fee.
In BIP125 the node accept the new conflicting transaction if the newer one pays enough fee. But  in CPFP method, the spender should construct a new transaction spending an output of the low-fee (parent) transaction, to encourage miners to include both transactions in the block they're mining.
Can someone explain the most important differences between these two approaches? Mentioning pros and cons of each one and which one is now more acceptable in the community.
The differences I can see:

I believe BIP125 is easier to implement rather than CPFP. Because calculating overall fee of a chain of transactions, we should see them as packages and I think implementing packages have some challenges.
On the other hand CPFP is not introducing any new rule or alteration in the protocol. I think it doesn't need any change in the protocol, but BIP125 is changing the way nodes are interpreting transactions.
Using BIP125 is more space saving, because it doesn't include 2 transactions (or more), it will throw the older transaction away and replace the new one. But in the CPFP both transactions are consequently included in the blockchain.

I appreciate any idea of how these two approaches differentiate each other.

First off, note that BIP125 does not prescribe any network ("consensus") rule. A Bitcoin node may not follow this replacement policy. In fact most nodes on the network are running Bitcoin Core, which implements relay rules close to but different from what is described in BIP125 when it comes to replacement, and allows some of those to be configured (for instance see -mempoolfullrbf regarding BIP125 signalling). Part of the policy implemented by Bitcoin Core by default is described here.
If most nodes didn't enforce mandatory BIP125 signalling, RBF would be superior in all aspects to CPFP from the perspective of the emitter of transaction. CPFP is much less efficient, and not always possible: you need the transaction to have a change output and (at least at the time of writing [0]) the parent to pass policy checks on its own, for instance if it's below the minimum feerate of most mempools on the network you won't be able to CPFP it at the moment.
From the perspective of the recipient of a payment, CPFP is the only alternative that doesn't require coordination with the sender.
Your second point seems to assume RBF requires a change in the protocol. It doesn't, it works today. If anything it is going to be made easier to use in the future (through various protocol improvements, and the push for having nodes allow to also replace transactions that didn't explicitly signal for BIP125 beforehand).
[0]: package relay would fix this.

Related questions and answers:

What are the arguments in the mempoolfullrbf debate?
What are packages in bitcoin core and what is their use case?
A question about CPFP relaying policy

source: Stack Exchange

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

sort: votes


text:
How is it possible to bypass bip125#2?
I was reading this github gist about rbf improvements written by glozow. I had difficulty understanding parts of it.
The main confusion I have is for this paragraph:

BIP125#2 can be bypassed by creating intermediary transactions to be replaced together. Anyone can simply split a 1-input 1-output transaction off from the replacement transaction, then broadcast the transaction as is. This can always be done, and quite cheaply. More details in this comment.

The BIP125#2 is:

The replacement transaction may only include an unconfirmed input if that input was included in one of the original transactions. (An unconfirmed input spends an output from a currently-unconfirmed transaction.)

Which from what I deduce, it basically means that a replacement transaction can only have one input of an unconfirmed transaction output. Is my understanding correct?
I also have taken a look on the comment glozow mentioned in the gist, but that doesn't helped me understanding how is it possible for one to bypass the restriction. Can someone explain it in simple language to me?
Thanks in advance

Replacement transaction using unconfirmed inputs

Which from what I deduce, it basically means that a replacement transaction can only have one input of an unconfirmed transaction output. Is my understanding correct?

The phrasing of BIP125#2 may not be the clearest. The short answer is that, no, this is not correct; specifically, a replacement transaction can have more than one unconfirmed input[1].
However, BIP125#2 requires that each of those unconfirmed inputs must be one of those that the transaction(s)[2] you are replacing has as an input.
Bypassing BIP125#2 with a 1-input 1-output transaction
Reproducing the scenario from the comment in question:
A and B are unconfirmed transactions in a mempool.
A user wants to replace A with a transaction C by spending at least one of the UTXOs that A is attempting to spend[3].
Case 1
The user wants C to spend an unconfirmed output from B, perhaps to assist with increasing the fee-rate of C compared to A. However, according to BIP125#2, C can not have an unconfirmed input that is not one of the inputs of A. So C can not spend the unconfirmed output of B.
Case 2
Knowing the limitations in Case 1, the user instead creates a new intermediate 1-input 1-output transaction C* that just spends an unconfirmed output from B. Now, the user can construct a transaction C that replaces both A and C*. Supposing that the fees are sufficient, this is now possible to do as the only unconfirmed inputs of C are from the transactions it is replacing, namely, A and C.
Once replaced, we have the effect of C having replaced A and spending an unconfirmed output of B.

[1]: An unconfirmed input is any input spending an unconfirmed UTXO. (Stated in parentheses in BIP125#2).
[2]: You can replace more than one transaction with a single transaction.
[3]: Not one of its outputs as this wouldn't be a replacement. We're talking about actually "double-spending" A here. At the end of a replacement, A should no longer be in the mempool as the two transactions conflict.

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


text:
what is the CValidationInterface class in the Bitcoin Core?
There is class here in the Bitcoin Core, I tried to learn about it and what is its job but couldn't figure out anything useful.
/**
 * Implement this to subscribe to events generated in validation
 *
 * Each CValidationInterface() subscriber will receive event callbacks
 * in the order in which the events were generated by validation.
 * Furthermore, each ValidationInterface() subscriber may assume that
 * callbacks effectively run in a single thread with single-threaded
 * memory consistency. That is, for a given ValidationInterface()
 * instantiation, each callback will complete before the next one is
 * invoked. This means, for example when a block is connected that the
 * UpdatedBlockTip() callback may depend on an operation performed in
 * the BlockConnected() callback without worrying about explicit
 * synchronization. No ordering should be assumed across
 * ValidationInterface() subscribers.
 */
class CValidationInterface {

This class was inherited by the abstract base class PeerManager:
class PeerManager : public CValidationInterface, public NetEventsInterface

What are subscribers of the CValidationInterface? I read the comments but that wasn't much helpful for me.


text:
How to ignore ResourceWarnings during running tests?
I was trying to run python tests in order to test a PR. I used this command to run p2p tests:
[amirreza@localhost bitcoin]$ ./test/functional/test_runner.py test/functional/p2p*

It produces lots of ResourceWarning warnings. And the result of the tests is this:
TEST                            | STATUS    | DURATION

p2p_add_connections.py          | ✖ Failed  | 7 s
p2p_addr_relay.py               | ✖ Failed  | 18 s
p2p_addrfetch.py                | ✖ Failed  | 2 s
p2p_addrv2_relay.py             | ✖ Failed  | 1 s
p2p_block_sync.py               | ✖ Failed  | 1 s
p2p_blockfilters.py             | ✖ Failed  | 17 s
p2p_blocksonly.py               | ✖ Failed  | 10 s
p2p_compactblocks.py            | ✖ Failed  | 6 s
p2p_compactblocks_blocksonly.py | ✖ Failed  | 2 s
p2p_compactblocks_hb.py         | ✖ Failed  | 9 s
p2p_disconnect_ban.py           | ✖ Failed  | 2 s
p2p_dns_seeds.py                | ✖ Failed  | 36 s
p2p_dos_header_tree.py          | ✖ Failed  | 2 s
p2p_eviction.py                 | ✖ Failed  | 5 s
p2p_feefilter.py                | ✖ Failed  | 7 s
p2p_filter.py                   | ✖ Failed  | 4 s
p2p_fingerprint.py              | ✖ Failed  | 1 s
p2p_getaddr_caching.py          | ✖ Failed  | 21 s
p2p_getdata.py                  | ✖ Failed  | 1 s
p2p_i2p_ports.py                | ✖ Failed  | 3 s
p2p_ibd_txrelay.py              | ✖ Failed  | 2 s
p2p_invalid_block.py            | ✖ Failed  | 2 s
p2p_invalid_locator.py          | ✖ Failed  | 2 s
p2p_invalid_messages.py         | ✖ Failed  | 50 s
p2p_invalid_tx.py               | ✖ Failed  | 8 s
p2p_leak.py                     | ✖ Failed  | 7 s
p2p_leak_tx.py                  | ✖ Failed  | 2 s
p2p_message_capture.py          | ✖ Failed  | 2 s
p2p_nobloomfilter_messages.py   | ✖ Failed  | 3 s
p2p_node_network_limited.py     | ✖ Failed  | 11 s
p2p_permissions.py              | ✖ Failed  | 11 s
p2p_ping.py                     | ✖ Failed  | 2 s
p2p_segwit.py                   | ✖ Failed  | 131 s
p2p_sendheaders.py              | ✖ Failed  | 16 s
p2p_timeouts.py                 | ✖ Failed  | 2 s
p2p_tx_download.py              | ✖ Failed  | 38 s
p2p_unrequested_blocks.py       | ✖ Failed  | 5 s

ALL                             | ✖ Failed  | 449 s (accumulated)
Runtime: 188 s

So I think the tests are failed due to my computer limited resources. Is this correct?
If yes, is there any way to suppress these kind of failures and don't count them as failing test?
As @PieterWuille suggested, I tried running one single test file. So I did this:
[amirreza@localhost bitcoin]$ ./test/functional/p2p_filter.py

And this is the result:
/usr/local/lib/python3.12/configparser.py:733: ResourceWarning: unclosed file <_io.TextIOWrapper name='/home/amirreza/git_repos/bitcoin/test/config.ini' mode='r' encoding='UTF-8'>
  self._read(f, source)
ResourceWarning: Enable tracemalloc to get the object allocation traceback
2022-08-14T15:45:45.288000Z TestFramework (INFO): Initializing test directory /tmp/bitcoin_func_test_e4o2s8j6
2022-08-14T15:45:46.149000Z TestFramework (INFO): Test filter size limits
2022-08-14T15:45:46.149000Z TestFramework (INFO): Check that too large filter is rejected
2022-08-14T15:45:46.204000Z TestFramework (INFO): Check that max size filter is accepted
2022-08-14T15:45:46.309000Z TestFramework (INFO): Check that filter with too many hash functions is rejected
2022-08-14T15:45:46.361000Z TestFramework (INFO): Check that filter with max hash functions is accepted
2022-08-14T15:45:46.413000Z TestFramework (INFO): Check that max size data element to add to the filter is accepted
2022-08-14T15:45:46.465000Z TestFramework (INFO): Check that too large data element to add to the filter is rejected
2022-08-14T15:45:46.568000Z TestFramework (INFO): Test BIP 37 for a node with fRelay = True (default)
2022-08-14T15:45:46.622000Z TestFramework (INFO): Check that we receive merkleblock and tx if the filter matches a tx in a block
2022-08-14T15:45:46.634000Z TestFramework (INFO): Check that we only receive a merkleblock if the filter does not match a tx in a block
2022-08-14T15:45:46.659000Z TestFramework (INFO): Check that we not receive a tx if the filter does not match a mempool tx
2022-08-14T15:45:46.782000Z TestFramework (INFO): Check that we receive a tx if the filter matches a mempool tx
2022-08-14T15:45:46.839000Z TestFramework (INFO): Check that after deleting filter all txs get relayed again
2022-08-14T15:45:47.378000Z TestFramework (INFO): Check that request for filtered blocks is ignored if no filter is set
2022-08-14T15:45:47.461000Z TestFramework (INFO): Check that sending "filteradd" if no filter is set is treated as misbehavior
2022-08-14T15:45:47.513000Z TestFramework (INFO): Check that division-by-zero remote crash bug [CVE-2013-5700] is fixed
2022-08-14T15:45:47.672000Z TestFramework (INFO): Test BIP 37 for a node with fRelay = False
2022-08-14T15:45:47.776000Z TestFramework (INFO): Check that a node with fRelay set to false does not receive invs until the filter is set
2022-08-14T15:45:47.895000Z TestFramework (INFO): Check that we receive merkleblock and tx if the filter matches a tx in a block
2022-08-14T15:45:47.908000Z TestFramework (INFO): Check that we only receive a merkleblock if the filter does not match a tx in a block
2022-08-14T15:45:47.936000Z TestFramework (INFO): Check that we not receive a tx if the filter does not match a mempool tx
2022-08-14T15:45:48.059000Z TestFramework (INFO): Check that we receive a tx if the filter matches a mempool tx
2022-08-14T15:45:48.116000Z TestFramework (INFO): Check that after deleting filter all txs get relayed again
2022-08-14T15:45:48.639000Z TestFramework (INFO): Check that request for filtered blocks is ignored if no filter is set
2022-08-14T15:45:48.720000Z TestFramework (INFO): Check that sending "filteradd" if no filter is set is treated as misbehavior
2022-08-14T15:45:48.772000Z TestFramework (INFO): Check that division-by-zero remote crash bug [CVE-2013-5700] is fixed
2022-08-14T15:45:48.927000Z TestFramework (INFO): Check that a node with bloom filters enabled services p2p mempool messages
2022-08-14T15:45:49.189000Z TestFramework (INFO): Stopping nodes
2022-08-14T15:45:49.291000Z TestFramework (INFO): Cleaning up /tmp/bitcoin_func_test_e4o2s8j6 on exit
2022-08-14T15:45:49.291000Z TestFramework (INFO): Tests successful
sys:1: ResourceWarning: unclosed <socket.socket fd=10, family=2, type=1, proto=6, laddr=('127.0.0.1', 43502), raddr=('127.0.0.1', 15831)>
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/usr/local/lib/python3.12/asyncio/selector_events.py:835: ResourceWarning: unclosed transport <_SelectorSocketTransport fd=10>
  _warn(f"unclosed transport {self!r}", ResourceWarning, source=self)
ResourceWarning: Enable tracemalloc to get the object allocation traceback

Try running with -j1 to only run once test at a time.

@PieterWuille  Thanks, but there's still lots of failed tests after running with one job.

What kind of system is this? OS/CPU/RAM?

@PieterWuille core i3 cpu, 8 GB ram, on fedora 31

Can you post the actual errors you're getting? Have you tried running the individual tests (not through test_runner.py)?

@PieterWuille I edited the question. Tried an individual test.

@PieterWuille Today I run all tests in a different machine and all of them passed without any warning. So now I'm sure the problem is with my system.


text:
How does bitcoin wallet's backup restore forwarding transactions?
I've installed bitcoin wallet on my phone and had some transactions. I backed up my wallet and after backing up did some other transactions. I supposed that the back up just would restore my wallet state until the back-up time. But when I restored my back-up the later transactions were loaded.
My question arises by noting the fact that for every time I want request bitcoin, my wallet generates a new address randomly (in fact it generates a randomly private-key and then using that private-key constructs the public-key and address). So my back-up should Only have private-keys which were generated until the back-up time. How it predicts the later private-keys?
I guess that it may have a fixed seed for generating random numbers and using that fixed seed it has a chain of random numbers but if this is true, it's not secure because by just stealing that seed, one can have all private-keys I would ever have in the future.
Though I'm not sure my background knowledge about bitcoin is correct or not. So if I have wrong assumptions let me know. Thanks in advance.

The wallet is a Hierarchical Deterministic (HD) wallet. This means that the keys it generates from the initial seed are pseudo-random, they look completely random but the sequence of keys can be completely replicated by starting with the same seed.
After restoring a wallet from backup, the software will generate keys and corresponding addresses in sequence and check each to see if it was involved in any transactions. They typically do so until they find a series of addresses with no transactions. The length of this is called the gap limit. After the number of unused addresses exceeds the gap limit the wallet will stop generating addresses.
This is why the restored wallet was able to find later transactions affecting your balance.
So you are completely right, the security of your money is completely dependent on the security of that seed number. The only truly important data in the wallet is the seed number. All other significant data can be recreated or obtained from other nodes.
See

BIP-32
Bitcoin Wallet for Android - -source code
LinuxSecureRandom (Java)
/dev/urandom

how is that seed generated? is that really random? (I'm aware that truly random doesn't exist, I mean does it uses some other resources such as microphone or webcam to generate an unpredictable seed)

Typically the software will use libraries which provide a method of collecting randomness from a variety of sources available to the device. it might include noise from a microphone, fractional seconds since last power-on, or since last input device use, or any other essentially unpredictable events available on a specific device.


text:
How to calculate trading fees ahead of time?
I'd like to determine what trading fees to expect before placing an order.
According to https://www.bitstamp.net/fee_schedule/ Bitstamp's trading fees depend upon the USD total of a customer’s last 30 days worth of transactions.
How can one calculate this amount using the Bitstamp API? It doesn't seem to be possible.

From the API documentation available at https://www.bitstamp.net/api/
The private endpoint https://www.bitstamp.net/api/v2/balance/ includes the fees for all pairs.
The private endpoint https://www.bitstamp.net/api/v2/balance/{currency_pair}/ includes the fee for the specified pair.

Are you saying that the fee returned by the balance api adjusts the fee in response to the 30 day trailing volume?

@Gili It's a private endpoint so I would assume so

Those are Bitstamp trading fees, not Bitcoin transaction fees. Trading fees are automatically calculated and deducted by Bitstamp when executing a trade.
For choosing the right Bitcoin fee, use bitcoin-cli estimatesmartfee or one of the many web services.

That's not what I meant. I need to know what the Bitstamp trading fees are before placing an order in order to estimate the profit of a trade. It doesn't make sense for a service to charge you a fee without letting you know what it will be ahead of time.

Every exchange has a predetermined fee structure for any financial transaction that you perform on the exchange. Also this fee is subject to the volume you have traded.
From the links you have provided, the API documentation page contains the user transactions section which would return the list of all transactions you have done.
You can filter out the last 30days transactions and get the USD volume from that.

That's nice but you didn't answer my question.

I'm sorry I did not check the links provided by you. I have updated the answer. @Gili

also the api returns the fee rates as well.

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


text:
Why does my incoming HiddenService IP (Whonix) occasionally showing up on the ban list?
Using Whonix, just recently running a full bitcoin node (v0.15.1; Qt v5.3.2), on my peers list my incoming connection(s), HiddenService IP (10.152.152.10/xx) occasionally shows up on the ban list effectively killing my node status, why on earth under what circumstance(s) would this be occurring?
As of this most recent edit for example, I was working on my laptop this am where the node is running, had 5 inbound and usual 8 outbound then I went to check and what do I see? my 10.152.152.10 IP is on the ban list, wth?

It sounds like this "ban list" is a part of (or associated with) your desktop operating system (whonix) -- Not sure this is answerable here.

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


text:
Bitcoin Transaction was sent to me with low fee and I used unconfirmed funds?
I was sent 0.29 btc to my wallet lastnight (bitpay) but it said the sender used low fees so it could take very long or be dropped? I'm not familiar. But I needed these funds in coinbase so I transferred some there and the rest topped off my bitpay visa card. I really need access to these funds, please help what can be done? Thank you.
The bitcoin address is.
18V9wQDAesH64XTDN6UJYw7DDzs8e92LtW

That is an address not a transaction.

18V9wQDAesH64XTDN6UJYw7DDzs8e92LtW     ....yes it's the address it was sent to, it currently shows it unconfirmed on blockchain and also blockcypher?

I don't see a 3 BTC transaction for that address. Do you have the txid?

Yes I just found the TXID number please help me someone.    fa9cd3945061cd715c56ff51e58cb941ec9897cc4e6dbaf5484315dd4f5e1fad

The fees were 18$. That's not very low. So it could be confirmed within a few days.

that's nuts, its never taken me longer than a few hours from this same sender. Now if I sent the money to coinbase and one other place before the money was confirmed, what happens now? Am I at risk of losing any money here? Thanks in advance.

Still no confirmations. What am I to expect here? Can someone help?


text:
Bitcoin transaction has been unconfirmed for over 24 hours... What should I do?
I'm pretty new to Bitcoin and although the technology is pretty exciting, I feel as though the sluggish confirmation times are letting it down...
On 18th December I instructed a Bitcoin transaction (5314fb75a5d08caf563cd6f6aaf40f448e9a9c6e0ba6affa499accd3534b97f6), admittedly with a pretty low fee, but I still wasn't expecting it to take days to get confirmed... Will this soon be dropped from the mempool or is there a way I can accelerate the transaction confirmation process?
Yours,
citygent

It will be dropt from the mempool if it stays unconfirmed for a long time. If the fee is low, it takes more time to get confirmed. And just now the Bitcoin network is getting spamed by Bcashers. I would wait until the spam is over, and then put a fee in acordance to the time you are willig to wait until the confirmation.

Thanks Ander - do you know roughly how long I should expect to wait for the transaction to drop from the mempool?

Around three days

To add - bitcoins are never lost, or in transit, when a transaction is unconfirmed. The bitcoins are in your wallet, UNTIL the transaction is confirmed and then they are in the recipient's wallet. There is no limbo-state, like there is in traditional banking.

If you liked my answer, mark it as accepted, it will give me reputation.

As a final advice, I would recomend you to use a wallet that has segwit enabled, it will allow you to pay lower fees and to get confirmed faster

Have accepted your answer Ander! Also what's the best way to speed up the confirmation process once the transaction has been executed. I'm still waiting for it to be confirmed... :(

It is a trade-off, the only way to speed up the confirmation time is to increase the fee you are paying. If you are not in a hurry I would suggest you to patiently wait. Right now there is an orchestated spam attack by miners who support Bitcoin Cash. They want to slow down Bitcoin network and try to replace it with their centralized fake Bitcoin imitation. I do not think they will suceed, so I would suggest you to wait until things get back to normal.


text:
"Shared wallets will not work correctly."
One satoshi bones rule states:
SHARED WALLETS WILL NOT WORK CORRECTLY.

What is a shared wallet? Why would shared wallets not work correctly with satoshi bones?

A shared wallet is often what online services and exchanges often use. They aren't fully functional wallets, and rely on a backend service to manage funds across users, this is the "sharing".
The reason you can't send from a shared address is because shared wallets only allow 1-way transactions due to technical limits. Satoshi Bones sends back bitcoins to the address it receives from after betting from what I'm assuming.
You're using a shared wallet if your sending from an exchange, Coinbase, and most online wallets or websites. The only web wallet that is not a shared wallet that I know is blockchain.info. Else just use wallets you install like Bitcoin-qt, Armory, or Electrum. I recommend Electrum.

I think you are misrepresenting these as not fully functional wallets. Using the input's consumed coins' previous address as this (and other) sites do, is a hack, cannot be guaranteed to work, and relies on the discouraged practice of reusing addresses. Bitcoin transactions simply don't have a reliable "from" address, and if you want to send coins somewhere, you should first ask where to send it to.


text:
Why did I pay 8.7% in miner fees?
Yesterday I did my first Bitcoin transaction for something physical. I bought a couple of drinks at a pub.
I was shown a QR code which I scanned with my Blockchain.info iPhone app. What caught my eye in the transaction were the miner fees of 0.5 mBTC / 5.7 mBTC = 8.7% (much larger than the 2-4% fee for credit cards).
Is it standard to pay such high miner fees for physical items to expedite confirmation? Did the QR code dictate the miner fee I had to pay, or was it the iPhone app?

I don't think the QR code would say how much of a transaction fee to give. (in the bitcoin URI scheme format no fees can be specified) Your app probably just chose a large number.

Your app's transaction fee is set to 0.0005 BTC.

The cost the network incurs is per transaction and not proportional to the amount of money you transfer, so it's only natural to have fee be an absolute not a relative value.

The fee is based on the transaction size, not on the amount of money being sent.  Making a transaction works by spending money you've previously received; the Bitcoin client looks for unspent incoming transactions and links those together to form a new transaction that uses up the money from those old transactions.
If this number of input transactions is particularly large (for instance, if you've received a lot of very small amounts of money), this means that the transaction size becomes larger, making the required fee larger as well, since it is a bigger burden on the network.  I believe some Bitcoin clients do have a tendency to try and use up small transactions first, which further contributes to creating larger transactions.
If the transaction you're trying to make is particularly small, the fee may seem disproportionally large.  This is why Bitcoin is often not considered to be great for microtransactions.
According to the Bitcoin wiki, the fee used in the reference implementation (as of 0.8.2) is 0.0001 BTC per thousand bytes.
Of course, the specifics of calculating the fee depends on the client, and this is configurable in any decent client.  I've gotten away in the past with using a fee of 0.

It was the suggested fee that your app set, I believe you can also customize fee size on most apps, but the suggested fee is for confirming the transaction ASAP. I believe POS stuff like that doesn't really care for confirmation time so you can safely set a lower fee.


text:
Is there a fast way to send bitcoins to an address on a web page?
I'm looking for something like a browser extensions that makes it possible to easily send bitcoins to an address on a web page.
I don't think a bitcoin:[address] URI protocol already lifted off, otherwise it would be ideal. But as long as it doesn't, a browser extension would be good enough...

bitcoin: links open in multibit automatically for me. (Using chrome.)

Does the original Bitcoin client supports that as well?

@StevenRoose Yes.

Oh, just found this one. See my related question: http://bitcoin.stackexchange.com/q/10863/4975


text:
Can Bitcore decode a raw tx?
I have a serialised transaction in raw hex format that I want decoded in JavaScript. Can Bitcore do that for me?

Bitcore makes it very easy to do this. Just use the Transaction constructor.
var bitcore = require('bitcore')

var txHexSerialized = "010000000...00000000";
var txDecoded = new bitcore.Transaction(txHexSerialized);


text:
what is SERIALIZE_METHODS macro in the Bitcoin Core?
 * Implement the Serialize and Unserialize methods by delegating to a single templated
 * static method that takes the to-be-(de)serialized object as a parameter. This approach
 * has the advantage that the constness of the object becomes a template parameter, and
 * thus allows a single implementation that sees the object as const for serializing
 * and non-const for deserializing, without casts.
 */
#define SERIALIZE_METHODS(cls, obj)                                                 \
    template<typename Stream>                                                       \
    void Serialize(Stream& s) const                                                 \
    {                                                                               \
        static_assert(std::is_same<const cls&, decltype(*this)>::value, "Serialize type mismatch"); \
        Ser(s, *this);                                                              \
    }                                                                               \
    template<typename Stream>                                                       \
    void Unserialize(Stream& s)                                                     \
    {                                                                               \
        static_assert(std::is_same<cls&, decltype(*this)>::value, "Unserialize type mismatch"); \
        Unser(s, *this);                                                            \
    }                                                                               \
    FORMATTER_METHODS(cls, obj)

This macro is used frequently in the Bitcoin Core. As an example in CBlockFileInfo:
class CBlockFileInfo
{
public:
    unsigned int nBlocks;      //!< number of blocks stored in file
    unsigned int nSize;        //!< number of used bytes of block file
    unsigned int nUndoSize;    //!< number of used bytes in the undo file
    unsigned int nHeightFirst; //!< lowest height of block in file
    unsigned int nHeightLast;  //!< highest height of block in file
    uint64_t nTimeFirst;       //!< earliest time of block in file
    uint64_t nTimeLast;        //!< latest time of block in file

    SERIALIZE_METHODS(CBlockFileInfo, obj)
    {
        READWRITE(VARINT(obj.nBlocks));
        READWRITE(VARINT(obj.nSize));
        READWRITE(VARINT(obj.nUndoSize));
        READWRITE(VARINT(obj.nHeightFirst));
        READWRITE(VARINT(obj.nHeightLast));
        READWRITE(VARINT(obj.nTimeFirst));
        READWRITE(VARINT(obj.nTimeLast));
    }

Can someone explain in simple language what does this macro actually do? I tried to figure out what it does by reading the comments above it and its implementation but didn't understand anything useful.

They are part of Bitcoin Core's custom serialization framework.
Serialization is the process of converting objects to byte arrays, for the purpose of storing them on disk, transferring them over the network, or computing their hash.
Deserialization is the reverse process, where an object is reconstructed from a byte array.
It is implemented using a number of classes, helper functions, and macros, in serialize.h.
Specifically the code you cite for CBlockFileInfo simply means:

To serialize a CBlockFileInfo object obj, do the following:

Serialize obj.nBlocks in VARINT format
Serialize obj.nSize in VARINT format
...
Serialize obj.nTimeLast in VARINT format

To deserialize, do the same (but with deserialize instead of serialize).

This approach makes it possible to have a single definition in the class on how to serialize/deserialize is, without needing to duplicate the code multiple times.

Thanks for your explanation. So by adding this macro to the class, we implicitly define Serialize and Unserialize member functions? Now the class CBlockFileInfo has these two members?

@AmirrezaRiahi Exactly, along with a few others.


text:
Can I recover missed phrase on p2sh wallet?
I have a wallet from past with p2sh format, also I know my private key but I just lost 4 character of that, I tried few apps to recover that but no one works(they work on another wallets prefectly), I think cause of p2sh they cant find my lost characters.is there any way to find and recover my private key?(it has +1000btc i really need to recover that and I give very good award if someone help me) sorry for my bad english :)

if i understand it correct: do you have 1 p2sh address and with the 1 privkey recovered you can access all of the funds?

a bitcoin private key is in base58 format (right?), so for bruteforcing 4 characters you need to check 11316496 (11.3 million) private keys... (can take a while)

maybe your coins are already gone. if one of the tools you tried had evil thoughts about your private key there is no way to get them back

a private key has checksum bytes, right? the last 4 characters can be made using the 256 bit priv key

check out this, maybe it helps

https://en.bitcoin.it/wiki/Wallet_import_format

https://en.bitcoin.it/wiki/Base58Check_encoding

It may too late to answer your question but if you still can't recover your wallet. try this method.
There are some questions to ask before coding.
1. The private key
There are many format type of private key, for example

Hexadecimal private key (64 length key combination from '0123456789abcdef' letters, case insensitive)
Base58 WIF (51 - 52 length key start with L or K or 5, case sensitive)

for 4 missing char, there will be 65,536 (16x16x16x16) key to test in first scenario and 11,316,496 (58x58x58x58) in second scenario
So, What format of your private key?
2. The missing position
Do you know where the missing position is?
If you know, It will be easy to find the key that match with your address, but if not, you must try all possible position and the possible key to test will be very huge
3. The address of damage private key
Do you know the address of that key?
According to your post, there is a p2sh wallet. So the address will start with '3' right? if you know the address, you can loop all possible key above until it match with your target address
the code below is in python. it create on scenario that your private key is hexadecimal format, missing first 4 characters, and you know the address of that damage private key
import hdwallet
import itertools

from hdwallet import HDWallet
from hdwallet.symbols import BTC
hdwallet = HDWallet(symbol=BTC)

#key = 'f79495fda777197ce73551bcd8e162ceca19167575760d3cc2bced4bf2a213dc'

corrupted_key = '95fda777197ce73551bcd8e162ceca19167575760d3cc2bced4bf2a213dc'
Target_address = "3GQVUFePz517Hf61Vsa9H2tHj5jw5y6ngV"

Possible_missing_key = list(itertools.product('0123456789abcdef', repeat=4))

for i in Possible_missing_key:
    Missing_part = ''.join(i)
    privateKey = Missing_part + corrupted_key
    hdwallet.from_private_key(private_key = privateKey)
    if hdwallet.p2sh_address() == Target_address:
        print(privateKey)
    hdwallet.clean_derivation()

You can adjust the code above to suit your case. Hope this help.
if you have any question, there's an email and telegram contact in my profile, feel free to ask.


text:
bitcoin-cli WIF from xpriv, descriptor outputs clarity
Questions

Is it possible for the bitcoin-cli command to extract WIFs from a ranged descriptor with a derivation path?

If a descriptor is ranged it must have a xpriv key?

If a descriptor has a xpriv it must have a derivation path?

If yes to 2,3 than the only other type would be a simple desc(wif) which would have neither a derivation path nor range?

I understand this is probably a bad idea (defeats the purpose of descriptors), but for curiosity reasons I'm asking.
Goal
My goal is to learn more about descriptors/WIFs/etc for testing alongside with the bitcoin-cli.

As far as Bitcoin Core is concerned, WIFs are the way private keys are encoded. If you're talking about "from" private keys, you must have some other encoding in mind. I don't believe any other encodings are supported besides WIF (and xprvs).

I think my confusion is/was mainly around descriptors. You typically wouldn't be able to grab a single key or wif from a descriptor output (or at least you typically wouldn't want to do this because then you lose what makes a descriptor a descriptor)?. I was given a key for a tr descriptor which now seems unusual I guess?. I'm wondering how you would one start with descriptor and then give someone a wif to a tr output? (updated question)

Yes, it is possible to create a Wallet Import Format (WIF) from a private key using the bitcoin-cli command. Here's an example of how you can do it:

[step.1] Generate a new private key:

bitcoin-cli -regtest getnewaddress
bitcoin-cli -regtest dumpprivkey <address>

[step.2] Convert the private key to WIF format:

$ bitcoin-cli -regtest dumpprivkey <private_key>

Replace <private_key> with the actual private key you generated in step 2.
The dumpprivkey command will output the corresponding WIF for the given private key. The WIF can be used for various purposes, such as importing the key into a wallet or performing other operations.
Using the bitcoin-cli command with the -regtest flag ensures that you are operating in the regression test mode, which is suitable for testing purposes.
By following these steps, you should be able to easily generate regtest WIFs for testing without relying on external programs or libraries.

@PieterWuille There was a typo in the text, I fixed it, what does it have to do with Ai?


text:
Best Practices with Multiple CPFPs & CPFP + RBF
Problem:
In times of escalating fees and a growing mempool, multiple prioritizations may be necessary if the initial Child Pays For Parent (CPFP) transaction fails to offer a sufficient fee. However, determining the next course of action can be challenging, given the ambiguity surrounding the execution of a second CPFP and the potential pitfalls arising from the modification of the original transaction through Replace-By-Fee (RBF).
Questions:

If doing a 2nd CPFP should you boost the original tx, or boost the last boost?
What happens to CPFP txs that are already in the mempool and the original tx gets RBF'd?
Would it be more cost-effective to perform several CPFP txs, or should you consider replacing your original CPFP tx with RBF?

Bonus: Which blockexplorers/softwares/mining pools are able to understand these potential complexities when prioritizing transactions?

Unfortunately, I'm not sure there are great answers to these questions right now, but I'll try to explain how things work today.

If doing a 2nd CPFP should you boost the original tx, or boost the last boost?

I think it depends on what you're trying to accomplish. If you're ok with the first CPFP attempt taking a while to confirm and you just want the very first transaction to confirm soon, then you might want to just CPFP the original transaction again (assuming you have another output to use?), so that you only are paying for two transactions to quickly confirm, rather than 3.
If instead you need the first CPFP attempt to confirm quickly as well, then you could spend one of its outputs and try to fee bump both the first and second transactions when you create this third one. Transactions are selected for mining based on their "ancestor feerate" score, which is the total feerate of a transaction along with all the unconfirmed parents that must be confirmed as well in order for the transaction to be valid to be mined. So this would do exactly what you want, I think.
Alternatively, you could also try to RBF the first two transactions at the same time, by issuing a transaction that conflicts with the first one and includes the outputs you want to include from both those transactions. Whether this is more economical will depend on what other transactions are in the mempool that spend outputs of these two transactions (see below).

What happens to CPFP txs that are already in the mempool and the original tx gets RBF'd?

Any transactions that depend on the original will be removed from the mempool when the original transaction is RBF'd. Generally, RBF is more efficient (lower required fees) than CPFP if the goal is to fee-bump.  However, for anti-DoS reasons, if there are child transactions in the mempool, then RBF's of the parent are required to not only pay for the parent to be evicted (a higher fee and higher feerate than the parent), but they're also required to pay for all the children being evicted, too (so the new transaction must have a higher fee than that paid by all transactions that are removed from the mempool).  This is described in BIP 125.
So, if you have a transaction that someone else has already chained a CPFP onto, then it might be more expensive for you to RBF your original transaction than it is for you to chain your own CPFP transaction, because the RBF would not just pay for replacing the parent but also the child that someone else created.
Also, a limitation of the current mining algorithm is that in a situation where a parent transaction has two different children trying to CPFP it (ie "sibling transactions" that each only depend on the parent, and not each other), the priority with which the parent will be mined will be at the higher of the two ancestor feerates of those children -- even though it's possible that the best feerate would be the one that includes all children taken together.

Would it be more cost-effective to perform several CPFP txs, or should you consider replacing your original CPFP tx with RBF?

In the absence of other transactions that would spend outputs of your original transaction -- which can lead to RBF "pinning", where a transaction is difficult to replace due to the rules requiring replacements to pay more total fee than all transactions that would have to be removed -- it should always be cheaper to RBF than CPFP, because you have to pay for more total bytes of transaction data to be mined when you generate new transactions than when you replace a transaction.
However, RBF can be tricky as well, because if you RBF a transaction repeatedly you have to be careful about how you manage your inputs,
so that if you are generating multiple replacements for a transaction, then each one should conflict with everyone that you signed before, or else you might end up issuing a payment twice. So some thought is needed in designing how a given application or wallet is designed to make sure that this is used properly.
In the future, the pinning issues related to RBF may be mitigated by new policy rules, such as the "v3" transaction relay policy that has been proposed, which would limit RBF pinning by limiting the size and number of child transactions that transactions opting-in to that policy are permitted.  However, that's not something that has been deployed yet.


text:
How to confirm custom transaction with solo mining?
I'm looking to cgminer software (https://github.com/ckolivas/cgminer) for understand that how mining works. It is difficult to understand and there are lots of codes. For this I'm asking this question here.
Is it possible that can I confirm a specific transaction? For example I sent a bitcoin from my address to other address and it generates a transaction ID. Can I pass this transaction id to my custom solo miner and it confirms it. Is it possible?
Is there a software that mines custom transaction seems like:
myOwnGPUorCPUMiner -tx [my custom transaction id]

It will confirm my transaction and finished or continues to mine other transactions. (This code is just an example)

Possible duplicate of https://bitcoin.stackexchange.com/q/16867/5406

It question seems like to mine but I'm actually asking that how to write codes for this purpose.

I agree with Murch. Code or no code, this is not a question of confirming a transaction but mining a full block that includes said transaction. Current difficulty does not allow for such activity by mining solo.

In Bitcoin, it is the miners' task to order the transactions. Thus, it is possible for a miner to pick which transactions they want to confirm. By default, they pick the ones that will provide the largest mining revenue to them, but often they will pick transactions to prioritize out of band.
However, you can only confirm a transaction by mining a block. That's what a confirmation is, a transaction being included in a block and thus being committed to on the blockchain.
However, it is infeasible for you to mine a block at home. Whatever minig power you may be able to acquire and run at home will likely not help you mine a single block in the next 1,000 years. I've elaborated here: In the ASIC-age, is it worth starting mining Bitcoin at home?

Can I put my own transactions first? For example I want to tell to my miner that mine this transaction first?

Yes. If you was the miner, you could modify the default source code and so you can: (1) Pick your transaction out of the meme-pool first (2) Put only 1 transaction - your own transaction in a block....But as Murch said: You don't have any chance to mine a block yourself.

I don't want to mine all block. Only my own transaction. Is it possible?

You can only confirm a transaction by mining a block. That's what a confirmation is, a transaction being included in a block.

Miners can build custom blocks?

Yes, miners can build custom blocks, but they still need to conform with the difficulty requirement specified by the protocol.— Maybe this will help clear up some things: https://bitcoin.stackexchange.com/q/148/5406

Bitcoin network is secured by two powerful protocols both of which are attack proof.
First of all for not allowing anybody adding arbitrary transaction in the blockchain; you should do a proof of work calculation which takes 1000 years on a single PC. doing such an intense calculation is so expensive and does not defer between accepting one transaction or thousand of transaction. so miners prefer to put as much as they could in a single mined block to gets more bitcoin from overall transaction fees. dont forget: you cannot 'mine' a transaction without putting it in a block, and you cannot mine a block without doing the proof of work calculation.
secondly and more importantly, generated block should be accepted by other full nodes of the network. so if you generate a block containing a transaction without enough evidence from signature of sender; they would refuse from accepting your block and that block would be worthless.
these two things helps bitcoin philosophy to secure its independence from being raped by any kind of filtering boycott or sanctions.

I'm downvoting this answer, because it doesn't address the main concerns of the question it is posted on.


text:
Can old coins be banned by a soft fork?
Satoshi Nakamoto is supposed to own 1.000.000 bitcoins on a thousands of wallets, and most of them are untouched since early blocks. This stake can potentially flood the market, so miners could probably be interested in banning them.
So, is it possible to create a soft fork (protocol update, approved by most of hashing power), that will deny any future transaction with early block coins? It is not really fair, but miners are greed and they should probably approve it. Is it a possible scenario?

this sounds like a communistic approach to a redistribution approach. Bitcoin was defined in a way, that it is censorship resistant... And greedy - who is not? Bitcoin is no social support tool, it's pure capitalism, with pure egoism of the majority. Exceptions to this are very rare. Satoshi (as far as we know) has created the system, and deserves all the fruits from his early invest. Also: I propose to close this question, cause the discussion will go mostly into opinion based statements, and not (technical) q&a.

Yes, since blacklisting a set of UTXOs would be done by adding more rules and thus restricting the set of allowed transactions, technically such a change could be introduced as a soft fork by the miners.
However, I would sincerely doubt that censoring Satoshi from spending her coins would find broad community support. I suspect that such an endeavour would quickly escalate the already existing tensions between community and miners.

Does the community have real power? Can't miners just develop and accept any update they want?

@BagdanGilevich: It's somewhat fuzzy, but if you want some examples, I suggest that you research e.g. the timelines and events around Litecoin's segwit activation, UASF, and NO2X.

"Satoshi from spending her" is the identity of Satoshi currently known?

Censorship is the inevitable power that (a collusion of) miners have - it comes at the price of having them decide the order of valid transactions. However, without community (=full node users) support, they can only keep it up as long as they maintain a hashrate majority.

@SalvadorDali: I'm sure you would have heard if she had been found out. ;)
— Pieter: Of course any miner could delay a transaction by not including them in their own block, but if the blockchain got reorganized away from blocks not participating in the cabal multiple times, it would become obvious very quickly what's happening.

@SalvadorDali so no one bats an eyelid on this site when they refer to Satoshi as a 'he', but when someone refers to Satoshi as a 'her', they gawk and question the probability Satoshi could be a woman...

@HamishGibson There is a difference here. The person who created bitcoin in his profile on P2P Foundation introduced himself as 37 years male from Japan (wayback machine: https://web.archive.org/web/20120529203623/http://p2pfoundation.ning.com/profile/SatoshiNakamoto) . So yes, it is a little bit surprising to see 'she' here. If the person would have introduced as a 35 years old female from Kenia, it would be strange if people would be writing 'he'. Or would you be fine if people would refer to you with a different sex that you selected (just because there is a probability you got it wrong)?

Others have commented on the technical possibility of this, so I'll address the economics:
I don't believe any smart miner would do this. Why? Because it would destroy confidence in the network. If the miners were willing and capable of blacklisting the coins stored at Satoshi's addresses, then who's to say they won't do the same to the coins stored at any other address? The value of the network is very closely tied to its security. Give users a reason to doubt this and they will flee, and prices will crash.

This could be implemented theoretically, but this idea will certainly never be implemented. It's because:

You don't know which addresses exactly are owned by Satoshi Nakamoto.
This idea is against all Bitcoin-principles. If you have Bitcoin, nobody should be able to steal it unless he has your private key. Bitcoin would become unreliable if you can't be sure that your funds will stay on the address where you send them.

(Hint: at the time when Satoshi Nakamoto got his Bitcoin, the bitcoins were nearly useless. And caused by the fact that he didn't touch the bitcoins yet many people assume that he lost his private keys, but this is only guesswork)

@fredsbend: Satoshi is on record suggesting that one should never delete a wallet. Based on her otherwise excellent opsec, I'd surmise that she still has the wallet given that she sent funds from block 9— if she's still alive.

@fredsbend: No, it simply amuses me to do so.

Yes, this idea is against all bitcoin-principles, but does the community have real power? Can't miners just develop and accept any update they want?

Or do you mean that even miners simply don't want bitcoin to become unreliable?

@BagdanGilevich: The value of currencies is based on trust. In olden times, currencies used to be backed by actual tangible assets (usually gold). In modern times, currencies are backed by trust that the government that issues them will take action to ensure that it keeps its value. This is no different for a cryptocurrency such as Bitcoin. Purposely devaluing certain Bitcoins in a targeted manner would completely destroy that trust, and consequently destroy the value of all Bitcoins, including the ones the miners are mining.


text:
Why do compressed and uncompressed public keys have to produce different addresses?
I am reading through the "Mastering Bitcoin" book. I understand that in the beginning the public key was both the x and y on the elliptic curve. Then it was optimized to only contain the x, and the y could be derived by solving the curve equation.
In practice wallet A and wallet B may generate different public key (assuming one uses the compressed and the other uses the uncompressed algo)
Different public keys will hash to different addresses and this is a problem - wallets don't know where to look for coins when importing private keys. That is fixed by adding stuff to the private key to designate which version is used.
I hope I understand correctly up until this point.
My question is: Why can't you just uncompress the compressed public key (effectively making it an uncompressed public key) and then derive the address. That way even if you use the compressed key, address will be exactly the same as the uncompressed one?

My question is: Why cant you just uncompress the compressed public key (effectively making it an uncompressed public key) and then derive the address. That way even if you use the compressed key, address will be exactly the same as the uncompressed one?

You certainly could, but you don't want to. At spending time, the public key is revealed in the spending transaction. That revealed public key must match whatever the address's embedded hash demands. If the address was computed off a compressed public key, the compressed public key must be revealed. If the address was computed off an uncompressed public key, the uncompressed public key must be revealed.
The point of switching to compressed public keys was using less on-chain chain space, and thus indirectly paying less fees (as fees scale proportionally to used on-chain space). If you'd derive the address by decompressing the compressed keys, you'd lose out on the point of using compressed keys in the first place.
Note that uncompressed keys are very rare these days. Almost all wallet software written since ~2012 exclusively uses compressed keys. BIP32 (a common mechanism form generating wallet keys deterministically, introduced in 2013) only supports compressed keys. When using segwit scripts (BIP141, introduced in august 2017), only compressed keys are supported (using uncompressed keys in segwit will cause transactions to not be relayed). The confusion between the two is mostly a non-issue nowadays.
Disclaimer: I'm the author of BIP32, and a co-author of BIP141.


text:
Is it possible to watch the chain to count the number of Lightning channels?
I know it's possible to get number of public Lightning channels from Lightning Network gossip and some implementations offer network graph and it can be queried. But it's not possible to see private non-routing channels there.
Can channel opening transactions be identified checking the blockchain? if not, what's the best way to estimate?
This is more of a theoretical query to understand the structure of messages used in lightning network channel opening bitcoin transactions.

They can only be detected when force closed and there are still pending htlcs otherwise they look like a spend from a 2-2 multisig wallet. I've been told some people try to do chain analysis and machine learning to predict private channels. I highly doubt that this is reasonably possible.
Although there is one thing to consider. If a node has public and private channels the funds get mixed. Implementations currently do not do separate bookkeeping of those outputs which is a privacy issue and an attack vector for what you want. However if a new ln node is set up and it only has private channels it will be hard to detect those on chain (unless the Chanel partners later reuses / mixes the outputs with some fire public channels.

can't companies do some analysis based on lightning invoices which contain a path to the private channel? Just to give you an example, let us say I own a node with provider A and you provide me an invoice which contains the private channel info I would need to include in the onion. My provider detects that and uses it to enhance the data of the known private channels.

A private channel does not need to exist on chain. It is not even possible to prove that a private channel's short_channel_id points to a correct channel because you don't have access to the funding public keys in order to recreate the redeem script, and there are no signatures to prove that the transaction referred to by the short_channel_id is indeed owned by the recipient and the forwarding node specified in the BOLT11 invoice. It is best to assume that the short_channel_id specified in an invoice is just some arbitrary identifier which tells the last hop how to forward the payment.

@MarkH that's a very valid point.

I'd argue it is possible to get some estimate, when doing a time series analyses of 2-to-2 multisig spendings. Number of occurrences (or gowth rate) likely changed, when lightning got live.
Question is how accurate such an estimate can be.


text:
Hyperledger fabric vs Sawtooth lake which platform is appropriate for Supply chain management?
I am planning to build supply chain management system with Blockchain. I have read many blog posts related to the topic, and eventually, I get Hyperledger as a right choice for Blockchain Network. but now I have two more option in that.Hyperlegder fabric & Sawtooth lake, now I am confused about the platform so can you please suggest me which platform is better for our Domain.

There is not a definitive right answer here. Fabric and Sawtooth both designed towards a similar end goal: building a general-purpose, enterprise-level, permissioned blockchain. As a result, many of the core features are pretty similar, and there is no reason you couldn't build a supply chain on either of them.
That said, there are some reasons you might want to choose Sawtooth over Fabric in general (full disclosure, I am a Sawtooth maintainer, and might be a bit biased):

You can develop for Sawtooth in a variety of languages, including Ethereum's Solidity smart contracts (with Fabric you must develop in Go)
If you need Byzantine Fault Tolerance, Sawtooth offers PoET consensus which is hardware assisted resulting in trivial CPU usage (Fabric does not yet have any BFT solution)
I would argue that Sawtooth does a better job of isolating application logic from the core blockchain logic, making development easier
As Ferg mentioned, there is already a supply chain implementation on Sawtooth, which you could use as a starting point: https://github.com/hyperledger/sawtooth-supply-chain

As for reasons to use Fabric . . . you may find there are more external tools available. For example, Hyperledger Composer is pretty nifty, and though there has been some talk of porting it to Sawtooth, currently it only works with Fabric. That's all I can really think of, but obviously I am much more familiar with Sawtooth, so I might ask around before making a decision.
UPDATE: Sawtooth now offers PBFT consensus in addition to PoET, RAFT, and PoET-simulator. This is a BFT algorithm which does not have hardware dependencies.

Thanks, Zac,  I am a bit late. But if I am talking about Sawtooth PoET consensus it is based on Intel’s Software Guard Extensions (SGX) which is a kind of special Instructions set, so it will work on AMD or any other vendor.

@VivekSharma Correct, PoET-SGX consensus relies on Intel hardware, so it will not work with AMD machines. However, Sawtooth features a non-BFT PoET-simulator, and RAFT consensus which is BFT without hardware dependencies.

Sawtooth includes an example supply chain application which may accelerate your development / evaluation process. https://github.com/hyperledger/sawtooth-supply-chain

Both Hyperledger Fabric and Hyperledger Sawtooth are permissioned distributed ledgers used for Enterprise Blockchain. Hyperledger Fabric demonstrates practical Byzantine Fault Tolerance (pBFT) based leader based distributed consensus with faster finality and block commit time compared to prominent public permissionless Blockchain platforms. Hyperledger Sawtooth provides a scalable enterprise blockchain environment for a permissioned distributed ledger. Sawtooth demonstrates Proof of Elapsed Time (PoET) consensus. As I have understood from discussions on recent implementations, Hyperledger Fabric does a good job in providing product provenance and supplychain track and trace for a limited number of nodes. When the number of nodes goes beyond 20, it seems to be having issues with respect to the performance and consistency. Hyperledger Sawtooth Lake is built with a randomized approach to consensus and a trusted execution environment. It has demonstrated good transaction throughput and finality with good security in place. It also provides interoperability with smart contracts written in solidity and ethereum virtual machine. However it is coupled with an Intel SGX based Trusted Execution Environment which could be an upfront cost for production deployments.

Thanks, Gokul, For sharing the information. have you implemented Fabric in a real-time environment in any project?

Yes Vivek. I have deployed Hyperledger Fabric 0.6 for a Diamond Trading Ledger. It was not a smooth implementation as Hyperledger was just evolving in 0.6. Now I am working with a few Sawtooth Lake related proof of concepts as well.

Thanks for reply Gokul, And it is very interesting to implement anything in the real environment. I have also started as POCs. hope your experience will help me.

To update info on the previous answer....
Hyperledger Sawtooth now supports multiple consensus algorithms...

PoET SGX ... Intel specific
PoET CFT ...without SGX
RAFT
PBFT .... Soon to be integrated


text:
Need a cold wallet. Segwit, Lightning, Fees?
I have all my coins on exchanges. I'd like to keep some in cold storage. I know I can create one at walletgenerator.net. But I'm scared because I think there might be a better way or it may not be worth it at all. If I'm going to lose 20% sending it there and 20% sending it somewhere else it's not worth it. What fees could I expect sending .1 BTC from an exchange to that wallet and the fee sending off there? I hear about segwit and lightning all the time, but have no idea how that works.
I don't think the wallet from walletgenerator.net is segwit or lighting, so is there a better wallet to use? Is it even worth it, or am I better off with LTC? Can you recommend an exerciser I can do with a small amount to quell my stress? Trading advice is everywhere, but finding reliable answers to wallet and security questions is near impossible.

As a side-note: do not use an online resource to generate a 'cold wallet'. A true cold wallet must be generated on a computer that never connects to the internet, thus keeping your keys offline, and more secure against attackers. There are good resources online about how to securely store coins, it is worth doing the research :)

Fees are not based on the value that is being transferred but rather the size of the transaction in bytes. The fee is to pay the cost of storing the data that makes up the transaction itself, not for the amount that is being transacted. Thus giving the fee as a percentage of a value will be completely inaccurate and giving a fee estimate for the cost of spending a given value will also be completely inaccurate.
When you are sending from an exchange, the exchange will usually pay the fee for you or they will tell you how much the fee will be when you send.
When you use a desktop wallet, the wallet will also tell you how much you are paying in fees. You can choose to also set your fee manually. Keep in mind that setting the fee to something very low can result in your transaction taking a long time to confirm.
To reduce fees when spending, you will want to use Segwit. Segwit effectively reduces the size of your transaction when you spend from segwit outputs. Segwit is completely backwards compatible (except for the new address format) and you can send to and receive from non-segwit addresses when you use segwit.
To use segwit, you must use a wallet that is capable of creating segwit outputs and addresses. There are two types of addresses, bech32 (begin with bc1) and p2sh nested (begin with 3) addresses. Bech32 addresses are new and not all wallets support sending to them, so it is better for you to use the p2sh nested addresses.
I recommend that you use Electrum. However Electrum does not support creating a new wallet with p2sh nested addresses. You can still use Electrum to do so by following these instructions: https://www.reddit.com/r/Bitcoin/comments/7mvw0m/psa_contrary_to_popular_belief_you_can_create/.
You should not use a paper wallet (like the ones created by walletgenerator.net) unless you aren't planning on moving your Bitcoin for a very long time. Paper wallets are, in general, more difficult to use and easy to get lost or damaged thus resulting in coin loss.

Lightning is unrelated to this.

I have a Tezor and a Ledger Nano. Should I send it there? Are those addresses Segwit? Lighting doesn't have to do with fees?

You should use one of those two devices. You can use both with Electrum. They will allow you to create P2SH nested segwit addresses. Lightning does have to do with fees, but is unrelated to your situation.

@AndrewChow to the top! Great comment again! Cheers

As stated, the exchange and wallet should both tell you the fee. Right now, the fee is around $10 in Fiat.
Strongly recommend using a paper wallet with multiple copies to store BTC long term!  Take those coins off the exchange!!
Always generate keys offline, preferably on a LiveCD. Lots of easy tutorials!
Lightning and segwit are solutions to the issue of Bitcoin scaling. At first, when there were relatively few transactions per minute, any old laptop could run a Bitcoin node. However, as more and more users jump on the network, and the number of transactions per minute increases, regular computers are having problems keeping up with the load.  That's what is slowing things down and causing these high fees.
To solve this issue, Segwit takes a lot of data off the main block chain, and outsources it to a secondary chain, Lightning. This allows the main chain to process large numbers of much smaller transactions, with only a tiny reference back to the Lightning chain present on the main chain.  Segwit is active, Lightning is still in development.  Once Lightning is active, fees should drop and speed should be restored.
(As an aside, this is what caused the Bitcoin cash fork.  Bitcoin cash decided to increase the allowable amount of data per block instead, a move which allows it to scale very well, but makes it depend upon large servers instead of everyday laptops.)


text:
Implementing NiPoPoW algorithm
Hello,
We, a small team, have implemented about 95% of a breakthrough scientific proposal that is describing the NiPoPoW Non-Interactive Proofs of Proof-of-Work. You can find our source code implementation of the NiPoPoW algorithm on our GitHub
During the implementation, we have got a few questions that we were not able to figure out from your breakthrough paper:
I. The WebDollar uses the Mini-Blockchain scheme ( Ethereum alike ) by using Patrica Merkle Trees to store the Balances of every non-zero addresses and Smart contracts. So, in order to validate a balance, we need only SPV hashes from the Patrica Merkle Tree and proofs based NiPoPoW of the last block (which is the last block from the blockchain)… so we believe we don’t require the infix proofs. Am I right? Or do we need the infix or velvet NiPoPoW algorithm?
II.  Algorithm 2 Verify
a)  We guess that the function validChain will validate π and χ in order to check the interlinks that they point to the genesis block and the hashes are correctly calculated.
b) My first technical question is that we were not able to understand what is the Q predicate used in the Verify Algorithm 2. Is it a “function” that checks and validates the χ (validating a PoW blocks based Target (T), interlinks. I am right? ) or how Q predicate will look like ? What else will the Q predicate do differently than validChain (π, χ)

III. MultiLevel Property
We are not very sure we got the order correctly.
We iterate u' from [0 to all u] and we will check that every u' must hold the property that for any C* included in C that has the property   |C∗↑µ'| ≥ k1, C* must have also the last equation. in case C* fails the last equation we return false;

IV. Badness
We were not able to understand the marked C* from the badness function
a. What is the correct order to calculate the expression C↓↑µ−1… first we calculate C↓ and then we calculate based the previous result ↑µ−1?
b. How do we calculate C↓? We couldn’t find any idea of how to calculate  C↓ only C’↓ which is downchain definition C’↓ C is defined as C[C’[0] : C’[−1]].
c. Isn’t it C’↓ and not C↓ ?

Thank you!

I. This is almost correct. The only difference is that you still need the χ suffix mentioned in the paper, which includes the most recent |χ| = k blocks of the blockchain. This is because the “last block” is not stable and may be withdrawn (in case another block of the same height happened to be mined at a similar time). You can only deduce the “current” balances as of k blocks ago.
II.
 a) This is correct.
     b) The predicate “Q” is application-specific. In your case, it could be, for example, a statement that the balance of a specific account holds a certain amount of money at a certain point in time. i.e. Q would be that “Alice holds 5 Ether at block #4,000,091”.
III. This is correct. Generally, unless there is a serious attack against the whole blockchain, this property will not fail to hold (for appropriate δ).
IV.
a) Yes.
b) c) You are correct. The C↓↑µ−1 should in fact be C’↓↑µ−1 instead. I have corrected the error and we will update the paper in the newest version. Many thanks for pointing this out!
Answer credits: Dionysis Zindros


text:
Why many classes in the Bitcoin Core prefix with a `C` while it is prohibited in the developer notes?
It's part of the developer notes in the documentation of Bitcoin Core:

Class names, function names, and method names are UpperCamelCase
(PascalCase). Do not prefix class names with C. See Internal interface
naming style for an exception to this convention.

Link
But I've seen many places in the codebase classes' name starting by C.
Such as:

CBlock
CTransaction
CTxIn
CTxOut
COutPoint

And many other examples. Is there a progress currently for changing these names? Or this rule is not apply to some classes?
Note that there's no description for this inconsistency in this part of the doc.

Related question: https://bitcoin.stackexchange.com/questions/106558/what-do-the-classes-chainstatemanager-cchainstate-cchain-and-blockmanager-do-i

These classes predate the coding style guidelines. Guidelines are a recommendation for newly added code and refactoring patches for the purpose of only changing the coding style are discouraged.
In the plain words of the introduction of the document you link:

Various coding styles have been used during the history of the codebase, and the result is not very consistent. However, we're now trying to converge to a single style, which is specified below. When writing patches, favor the new style over attempting to mimic the surrounding style, except for move-only commits.
Do not submit patches solely to modify the style of existing code.


text:
Can I use my Coinbase address to receive bitcoin? Why is it shorter than a normal address?
In my Coinbase account, in Manage your profile > Crypto addresses, I can find a Bitcoin address which is 34 characters long. Can I use this as a public address to receive bitcoin from other wallet, e.g. Electrum? Why is this address shorter?

Normal (old) P2PKH addresses (1...) and P2SH addresses (3...) are 34 characters long. The newer native segwit addresses (bc1...) are longer, because they're case-insensitive and (in some cases) use stronger hashes/cryptography.
Whether you can use these to receive payments from others is a question for your agreement with Coinbase. While any address can inherently receive coins from anywhere, Coinbase can in theory ask you questions about their origin, or even refuse to let you withdraw.

There are a number of different standard output types for Bitcoin transactions. Most standard types use addresses as shorthand to encode the spending conditions.
The output types and the corresponding types are:

Pay to Public Key (P2PK) – no address standard
Pay to Public Key Hash (P2PKH) – addresses start with 1… and are up to 34 characters long
Pay to Multisig (P2MS) – no address standard
Pay to Script Hash (P2SH) – addresses start with 3… and are up to 34 characters long
Pay to Witness Public Key Hash (P2WPKH) – addresses start with bc1q… and are exactly 42 characters long
Pay to Witness Script Hash (P2WSH) – addresses start with bc1q… and are exactly 62 characters long
Pay to Taproot (P2TR) – addresses start with bc1p… and are exactly 62 characters long

The older types (P2PKH, P2SH) use the base58check encoding. As the name implies, it uses a set of 58 characters to encode log 58 ≈ 5.85 bits of information per character.
The native segwit types (P2WPKH, P2WSH, P2TR) use bech32/bech32m to encode addresses. Each character encodes only log 32 = 5 bits of information, but addresses no longer mix uppercase and lowercase. Since each character encodes less information, these addresses are longer.

Oh oops, thanks Vojtěch


text:
How to Sign Bitcoin Transaction from two or more children wallet in HD wallet
How can I handle a situation where I have bitcoin on two or more different wallets with a single phrase, how can I sign the two transactions to a friend.
Example:
I have 2BTC in a wallet address that is at path m/44'/0'/0'/0'/0
I also have 1BTC in another wallet address that is at path m/44'/0'/0'/0'/1
How can I sign the 3BTC to a friend.
Thanks!

If by wallet you mean address, there is no problem. You can create a 3 BTC transaction and submit it. The wallet itself will handle joining different coins in different addresses to make a single 3 BTC coin. But if you really have 2 coins in two completely separate wallets, you can send one of your coins to another wallet, in order to put both coins in a same wallet. Then you're able to create a 3 BTC transaction.


text:
Help explaining some C++ code I haven't seen before
I'm studying for the upcoming pr review club.
        if (!m_foreign_outputs.empty()) {
             std::string s(m_foreign_outputs.size(), 0);
             for (auto i = m_foreign_outputs.size(); i--; ) {
                 if (m_foreign_outputs.at(i)) {
                     s[i / 8] |= 1 << (i % 8);
                 }
             }
             mapValueCopy["fout"] = s;
         }

What is that for loop doing? and how is it not stuck forever?
Also what is happening here:
s[i / 8] |= 1 << (i % 8);
Thanks!

I understand the loop now, I haven't seen that before, I guess it walks through the vector from the highest index to the lowest and exits the loop after zero. That's cool. I'm lost on the string, it looks like it is creating some sort of unicode values?

Thank you, I guessed that when I woke up today but definitely wasn't sure.

I’m voting to close this question because it's better asked in the review club, or on the PR.

I'm voting to close this topic, because it's a question about the C++ programming language.

It's creating a string where each character value is composed of bits representing 8 booleans from m_foreign_values packed together.


text:
How to understand Bitcoin source code
I am not a C++ pro. I read C++ as a part of my undergrad school course. I am very passionate about the future currency i.e. Bitcoin.
But I don't understand the source code structure. How to read the source code? As I already told I am have very basic knowledge of C++.
However, I can google on the way if don't understand something(functions, libraries, headers).
The actual problem I am facing is inside src/ directory. I don't understand the flow of files and directories in src/. Which is the first file that I should probably start reading. Can any one explain me all of flow of all the project in some sort of tree like structure?
~/GitHub/bitcoin/src
❯ ls                                                                   ✔ master
Makefile.am     coincontrol.h       miner.h         script
Makefile.bench.include  coins.cpp       net.cpp         secp256k1
Makefile.qt.include coins.h         net.h           serialize.h
Makefile.qttest.include compat          netbase.cpp     streams.h
Makefile.test.include   compat.h        netbase.h       support
addrman.cpp     compressor.cpp      noui.cpp        sync.cpp
addrman.h       compressor.h        noui.h          sync.h
alert.cpp       config          obj         test
alert.h         consensus       obj-test        threadsafety.h
amount.cpp      core_io.h       policy          timedata.cpp
amount.h        core_memusage.h     pow.cpp         timedata.h
arith_uint256.cpp   core_read.cpp       pow.h           tinyformat.h
arith_uint256.h     core_write.cpp      prevector.h     torcontrol.cpp
base58.cpp      crypto          primitives      torcontrol.h
base58.h        dbwrapper.cpp       protocol.cpp        txdb.cpp
bench           dbwrapper.h     protocol.h      txdb.h
bitcoin-cli-res.rc  hash.cpp        pubkey.cpp      txmempool.cpp
bitcoin-cli.cpp     hash.h          pubkey.h        txmempool.h
bitcoin-tx-res.rc   httprpc.cpp     qt          ui_interface.h
bitcoin-tx.cpp      httprpc.h       random.cpp      uint256.cpp
bitcoind-res.rc     httpserver.cpp      random.h        uint256.h
bitcoind.cpp        httpserver.h        rest.cpp        undo.h
bloom.cpp       init.cpp        reverselock.h       univalue
bloom.h         init.h          rpcblockchain.cpp   util.cpp
chain.cpp       key.cpp         rpcclient.cpp       util.h
chain.h         key.h           rpcclient.h     utilmoneystr.cpp
chainparams.cpp     keystore.cpp        rpcmining.cpp       utilmoneystr.h
chainparams.h       keystore.h      rpcmisc.cpp     utilstrencodings.cpp
chainparamsbase.cpp leveldb         rpcnet.cpp      utilstrencodings.h
chainparamsbase.h   limitedmap.h        rpcprotocol.cpp     utiltime.cpp
chainparamsseeds.h  main.cpp        rpcprotocol.h       utiltime.h
checkpoints.cpp     main.h          rpcrawtransaction.cpp   validationinterface.cpp
checkpoints.h       memusage.h      rpcserver.cpp       validationinterface.h
checkqueue.h        merkleblock.cpp     rpcserver.h     version.h
clientversion.cpp   merkleblock.h       scheduler.cpp       wallet
clientversion.h     miner.cpp       scheduler.h     zmq

I think the good starting point would be take an online course in C++. Otherwise you would be reading foreign language you have no idea of.

I am aware of C++. I am also update with C++, C++14. Its just that I never worked on a big project so I don't know the workflow. @MikkoOhtamaa would you suggest me a good resource which doesn't cover the language basics and cover the advance features of the language itself? Currently I am counting on videos posted on on channel9.msdn is that fine?

All Microsoft sources are pretty decent what comes to advanced C++. I also suggest you getting a good IDE which does autocompletion, code insight and such that you can get around in code tree according to code flow.

Well, this is not a complete answer, but there is a lot of stuff in main.cpp to look at. I would start there.

Recently I was in a situation where I had to work on Bitcoin-core c++ code base. Being from c# background, I had the same problem which you faced. I also looked into the solutions which everyone is suggesting, still, I want to give you a more precise solution for this question:
Pre-requisites

You need to understand the basic of c++ project structure.
something like this:

root\
    lib\
        submodule1\
        submodule2\
        MakeFile.am
    src\
        component1\
            comp1.cpp
            comp1.h
        component2\
        main.cpp
        Makefile.am
    .gitmodules
    .gitignore
    Makefile.am
    configure.ac
    autogen.sh

This the very a basic project structure and it can go to a very complex one, but just to give an idea let's bear with it. I won't give you details of these files but you can always checkout out my dedicated repository for c++ boilerplate. Files like, Makefile.am, configure.ac etc. are there for Autotools or GNU Build Tools. Basically, Autotools is a set of tools, Autoconf, Automake, make utility and Libtools, used to build c++ project.

Get the basic of Autotools

Let's start

Download Bitcoin-core and open /src/Makefile.am.
The Bitcoin code base is a combination of several programs like bitcoind, bitcoin-cli, bitcoin-tx and bitcoin-qt . You can see these programs mentioned in src/Makefile.am file, search for bin_PROGRAMS macro.

if BUILD_BITCOIND
  bin_PROGRAMS += bitcoind
endif
if BUILD_BITCOIN_CLI
  bin_PROGRAMS += bitcoin-cli
endif
if BUILD_BITCOIN_TX
  bin_PROGRAMS += bitcoin-tx
endif

It is important to know which executable you want to debug? - I am giving an example of bitcoind
Bitcoin's developers have converted modules (consensus, server, cli, wallet, common, crypto etc.) into static libraries (.a files) so that they can be shared and used across all these programs. In order to understand how these files are managed, as I said, start looking into the Makefile.am, present inside src directory. For example:
In the bitcoin's src/Makefile.am file, we have bitcoind right? Let's search this text in that file.  You will get bitcoind_SOURCES and bitcoind_LDADD macros for the source file of that program (basically the file where main() is defined) and linked static libraries (.a files) to bitcoind program respectively.
Now let's look for one of the linked libraries, say libbitcoin_server, you will find libbitcoin_server_a_CPPFLAGS, libbitcoin_server_a_CXXFLAGS and libbitcoin_server_a_SOURCES macros. In libbitcoin_server_a_SOURCES macro, you have all .cpp and .h files defined there.

I hope these would have given you some insights to start with. Soon I will be writing a blog on this topic. Will edit this answer once done.
EDIT: here is a blog on this topic which I have written. Hope that will help.

The link to your blog seems to be broken. Can you please update it?

I'm in my final year of college and I remember being in your exact situation 2 years ago. In my view you can adopt 2 strategies at this stage.
You need to understand the protocol first, and reading Satoshi's orginal paper, or any of the easier options is essential. It also helps a lot to understand the conceptual differences between bitcoin and other currencies like Ripple and Peercoin.
If your intention is to learn as much about the bitcoin implementation as possible, I would suggest you give up on bitcoin-core and shift to one of the python implementations. Now, there are a few quirks about the python implementations, but your learning would be much faster and you'd be in a much better position to understand the cpp code later.
If you want to stick to bitcoin-core, and are willing to tolerate a steep learning curve, there are still a few resources to sweeten it. You need to understand that it's not just cpp that you need to master to understand bitcoin core, but a lot of the GNU build system, the makes and the autoconfs and such stuff.
Now to help you understand the structure of the code in src, you could check this out.
Edit (7:7:2016):A lot of the new discussions in the bitcoin:core world, revolves around the CPP language itself. CPP itself undergoes considerable change every 4 years and there are many discussions around which CPP language features can be implemented/ incorporated into bitcoin-core. So it is required that you have a thorough understanding of CPP along with new language features that keep getting added, and their relations to the previous features.

Bitcoin Core is switching to C++11 in the upcoming 0.13 release. Meanwhile, C++14 is already standardized and C++17 is well underway. Stating that Bitcoin Core always uses the latest features seems like a strange statement.

I changed that statement to something more moderate I hope :). I'm not going to argue with Einstein about relativity. :)

I have a different approach to it. You can use this too.

Bitcoin uses Doxygen comments to explain the code.
You can take the most recent copy of the code, build class hierarchy yourself using Doxygen, and then navigate through the various classes.
The next step would be to build it and run it in -regtest mode.
Use gdb to add breakpoints, and inspect the flow.
You can start with init and util files and then go through others. They have generic code, logging and files. And then get to the net.cpp, validation.cpp to find the more detailed logic.
In my opinion, diving into the code, getting messy is a much better approach rather than reading more. Get dirty into the code, write some of it, get errors, and understand on the way.

The Bitcoin-qt source code grew out of the original code written by Satochi. The latter, in my opinion, is much cleaner and easier to read. I have a new book that analyzes the Statochi's original source code at lulu.com: A Dissection of Bitcoin


text:
socket send error Bad file descriptor (9)
The log file goes back quite a few weeks but this error started to appear today. Any ideas why?

I am seeing that a lot too. I've stopped receiving blockchain information; I don't know if this error is associated with not receiving blockchain information. Any progress on figuring this out?


text:
Idea on how to keep my altcoin private, make it impossible for others to mine even if they have my altcoin's source code
I've been doing freelance to create an altcoin and my client wants this new coin to be private which means only authorized users can mine and use the coin. What I've been doing so far is to make a new altcoin, keep it in a private repo, implement mobile wallet apps with authentication gate that requires user to enter his credential info (I have a server to contain this kind of info), etc. Everything seems to work well 'til yesterday when I see a strange IP in the output of getpeerinfo command. So I was wondering how could someone get my code and whether he was able to mine my altcoin.
So my question is: Has anyone of you had experiences in such situation of creating private coin? And do you have any ideas or suggestions on how I can stop someone from mining my altcoin or only allow certain machines from certain IP addresses can connect to my network and mine even if they have my altcoin source code?
Thank you in advance and have a nice day!

I've been doing freelance to create an altcoin and my client wants this new coin to be private which means only authorized users can mine and use the coin. What I've been doing so far is to make a new altcoin, keep it in a private repo

Bitcoin sounds like a poor fit for your application for two reasons. First, Bitcoin is designed to keep working even if some people tamper with the inner workings of their client. If you're willing to give that up, you can build something a lot simpler. Second, it's designed to process transactions in a decentralized way, which sounds like the opposite of what you want. If you give that up, and use a central clearinghouse, you can build something much simpler.

So I was wondering how could someone get my code and whether he was able to mine my altcoin.

I don't know whether this person has the source code of your altcoin; I don't know what security measures you've taken. However, having the source code of your altcoin is not nessesary to connect to it. As long as a peer can fake its way through a version message, that's good enough to make it into getpeerinfo. The two clients don't need to be running the same code.

And do you have any ideas or suggestions on how I can stop someone from mining my altcoin or only allow certain machines from certain IP addresses can connect to my network and mine even if they have my altcoin source code?

Bitcoin's design is going to make that quite difficult. Bitcoin uses a gossip network to move blocks around. If I mine a block, and I tell you about it, then you will tell all of your friends about it. They will in turn tell all of their friends about it too, until everyone knows.
This means that if a single node is misconfigured, and allows external blocks, it broadcasts those to every other node on the network.
It would make more sense to modify the client so that blocks must be signed by a key that is only held by your client.

Thank for your response, Nick! In fact, I don't want to give up the feature which keeps the database consistent and reliable even with distorted data nor the decentralized one. What I've done for the project is to make it like a hybrid one, centralized & decentralized at the same time. The server will only keep the credential data for users to sign in, mnemonic code which then will help to backup their transactions. The rest will be still the altcoin core's responsibilities. A signed key or an authentication protocol with a token are good ideas but I'm thinking how to implement them feasibly.


text:
How can I run bitcoind and bitcoinclassicd on the same server?
I want to run full nodes for Bitcoin (bitcoind) and Bitcoin cash (bitcoinclassic). Here are the commands I'm using to run these nodes (I've renamed bitcoin classic tools to bitcoinclassic* and moved the executables to the /usr/bin):
$ bitcoind -daemon -dbcache=3072 -rpcthreads=10
$ bitcoinclassicd -daemon -datadir=.bitcoinclassic/ -dbcache=3072 -rpcthreads=10

They are both starts OK, but when I'm trying to use the bitcoin-cli and bitcoinclassic-cli, for some reason I'm getting information only for bitcoinclassic
$ bitcoin-cli getinfo
{
  "version": 1030300,
  "protocolversion": 80002,
  "walletversion": 130000,
  "balance": 0.00000000,
  "blocks": 479637,
  "timeoffset": 0,
  "connections": 19,
  "proxy": "",
  "difficulty": 115459053827.9121,
  "testnet": false,
  "keypoololdest": 1502885275,
  "keypoolsize": 101,
  "paytxfee": 0.00000000,
  "relayfee": 0.00001000,
  "errors": ""
}

$ bitcoinclassic-cli getinfo
{
  "version": 1030300,
  "protocolversion": 80002,
  "walletversion": 130000,
  "balance": 0.00000000,
  "blocks": 479637,
  "timeoffset": 0,
  "connections": 19,
  "proxy": "",
  "difficulty": 115459053827.9121,
  "testnet": false,
  "keypoololdest": 1502885275,
  "keypoolsize": 101,
  "paytxfee": 0.00000000,
  "relayfee": 0.00001000,
  "errors": ""
}

How can I fix it? Maybe I should use more flags at the start, e.g. specifying configuration file or something else?
UPDATE: I forget to say, that they are not using the same port, here's the configs:
$ cat .bitcoin/bitcoin.conf
rpcuser=USER
rpcpassword=PASS
rpcbind=127.0.0.1
rpcport=8332
server=1
$ cat .bitcoinclassic/bitcoin.conf
rpcuser=USER
rpcpassword=PASS
rpcbind=127.0.0.1
rpcport=8432
server=1
bind=0.0.0.0:9222
maxconnections=10

Are they using the same RPC port?

@NickODell no, check question's update

Are you using -conf to tell each cli tool where to find the configuration for that daemon?

@NickODell No, I thought that they will try to find configuration files in their datadir folders (.bitcoin and .bitcoinclassic). Should I do it?

Let me rephrase - are you using -datadir to tell each cli tool where to find the configuration for that daemon?

@NickODell As I wrote in my question, I'm using -datadir option with bitcoinclassicd (-datadir=.bitcoinclassic/). I'm not using this flag with bitcoind, so it's using default folder (.bitcoin).

Are you passing the -datadir option to bitcoinclassic-cli?

@NickODell nope. I've tried - didn't help.

Sergey, have you found what caused the trouble?

authors: Королев Евгений


text:
Why transaction is signed with locking script from the input transaction?
Finally, I've successfully made a raw transaction with Python and this is the last thing, which is totally mistic for me.
In my case, here's the input transaction and it's locking script is:
OP_DUP OP_HASH160 dab3cccc50d7ff2d1d2926ec85ca186e61aef105 OP_EQUALVERIFY OP_CHECKSIG

Why it's necessary to set up the unlocking script to the input's locking script before signing? In my understanding, all the stuff should work well even with blank locking script, because in fact we're signing only other parameters. Unlocking script and unlocking script lenght will be changed anyway, so what's the reason?

There is no definitive answer here, and you'd need to ask the system's creator to be sure.
My guess is that it was due to interaction with a feature that we're now calling 'delegation': the ability for someone to presign a transaction, and add a new unlocking script- effectively delegating the right to sign to someone else under certain circumstances.
Elements of the script language that point in this direction include the existence of OP_CODESEPARATOR, and the original execution model of running scriptSig + scriptPubKey in one go, rather than separately as is done now.

But what about security - am I right, that before the transaction will be included into the block, miner can edit unlocking script + unlocking script lenght, and transaction will still be valid?

Yes, that's called malleability, and it is possible. However, it cannot be avoided, as we can't have signatures that sign themselves (as they are in the unlocking script). A way around it is the Segregated Witness proposal, which does not prevent malleability, but makes the unlocking script not contribute to txid calculation.


text:
blockchain api missing file?
https://github.com/blockchain/api-v1-client-php <== php files im working with.
When i do my first test with this new api i start off with the inits
<?PHP
// Include the autoload.php from its vendor directory
require 'vendor/autoload.php'

// Create the base Blockchain class instance
$Blockchain = new \Blockchain\Blockchain();

// Needed before calling $Blockchain->Wallet or $Blockchain->Create
$Blockchain->setServiceUrl('http://localhost:3000');
?>

But when i do this it says...
"Parse error: syntax error, unexpected '$Blockchain' (T_VARIABLE) in C:\xampp\htdocs\bitcoin\index.php on line 6"

Composer package was compiled correctly and in the root folder.

U run the composer already right and under the same folder that the php file is on?

It looks like you just haven't installed it properly, there is definitely a blockchain file (https://github.com/blockchain/api-v1-client-php/blob/master/src/Blockchain.php)

yes i went to my bitcoin folder with src, examples, doc, etc...i held shift and open command window there typed in "composer install" and that was the errors i was getting. check picture of composer error https://imgur.com/a/JAEgV

well it looks like i was using a different bitcoin PHP. but the issue is still there, the composer was able to compile fine and i see the blockchain folder and blockchain.php But when i run the script with the same inits its still giving me the exact error for $Blockchain