text:
Does a Block contain the list of transactions? Or only the Merkle Tree?
I was wondering how a block encodes its set of transactions. I know a Merkle Tree is generated, and that it encodes a Hashed version of the transactions. But is the Merkle Tree included in the Block that gets sent to the other nodes for validation?  Is there a list of transactions that it also sent?
In my understanding, when a Node wishes to 'Mine', they will:

Generate a new block
Create a coinbase transaction
Gather a subset of the other incomplete transactions (those that have not yet been put into a block) from its copy of the blockchain.
Generate a Merkle Tree using the transactions from steps 2 & 3
Increment a Nonce repeatedly until the Hash of the <Previous Hash, Nonce, Transactions from 4> begin with a certain number of 0s.

It seems that to validate each individual transaction (to ensure money is not double-spent), it would be good to include a list of transactions. But to check that the proof-of-work has actually been completed, the other nodes need the merkle tree to quickly hash.
It is very possible that there is also a way to obtain the list of transactions from a merkle tree, but I just don't understand what that process looks like.
P.S. I am building my own Python demo implementation of a blockchain currency, hence the more-theoretical/less-practical questions.
Thanks.

You cannot obtain a list of transactions from the merkle tree.
The merkle tree root is part of the block header, which as you said, allows quick verification of the proof-of-work.
After the block header, each block contains a list of serialized transactions in the order they appear in the merkle tree. A complete block is a block header + list of transactions.
When validating a block, nodes will check:

The proof of work (this can be done with just the block header. However, just because the block header validates, it does not mean the block is valid)
The merkle tree - Nodes will take the list of transactions and reconstruct the merkle tree to ensure the root matches what is in the header
Each individual transaction - Individual inputs and outputs are validates to ensure they meet network rules, and that no double spends exist.

Answers my question perfectly.

In order to validate a block nodes must have the actual transactions themselves, even a list is insufficient.
But the question "Does a block contain X" is a bit like asking "What is the sound of one hand clapping?".  It would be valid to say that a "block" is nothing more than its block header or even that that hash of a block is "the block".   You couldn't validate a block from its hash or its header alone, just like you can't validate a block without data you learned from the blocks before it-- but how you get that data is up to you and the part(ies) that are telling you about the block.
This is relevant because today in the Bitcoin network, blocks are usually relayed without sending the transactions according to BIP152-- instead we assume that the regular transaction relay process has already given each node most or all of the transactions and send our peers a compact representation that lets them use their mempools to figure out what was in the block.  If they're missing some of the data they need, they can request it.


text:
How is subscript computed for OP_CHECKMULTISIG?
I'm trying to learn the Bitcoin protocol by implementing it, and I've got OP_CHECKSIG working (following instructions in https://en.bitcoin.it/wiki/OP_CHECKSIG), but I can't get an transaction input using OP_CHECKMULTISIG to pass signature verification.
Specifically, I'm stuck with the second tx_input of transaction eb3b82c0884e3efa6d8b0be55b4915eb20be124c9766245bcc7f34fdac32bccb, and I suspect that the culprit is subscript (the one to replace signature script in current transaction).
Here's how subscript is computed in my implementation.
First, generate the script by concatenating [sigScript][OP_CODESEPARATOR][pubkeyScript] (I understand that script execution has evolved from this).
So a (parsed) script for the input would be like this:

Frame 00: 0(00)
Frame 01:
0000 - 30 44 02 20 27 6d 6d ad 3d ef a3 7b 5f 81 ad d3
0010 - 99 2d 51 0d 2f 44 a3 17 fd 85 e0 4f 93 a1 e2 da
0020 - ea 64 66 02 02 20 0f 86 2a 0d a6 84 24 93 22 ce
0030 - b8 ed 84 2f b8 c8 59 c0 cb 94 c8 1e 1c 53 08 b4
0040 - 86 81 57 a4 28 ee 01 END
Frame 02: OP_CODESEPARATOR(0xab)
Frame 03: 1(0x51)
Frame 04:
0000 - 02 32 ab dc 89 3e 7f 06 31 36 4d 7f d0 1c b3 3d
0010 - 24 da 45 32 9a 00 35 7b 3a 78 86 21 1a b4 14 d5
0020 - 5a END
Frame 05: 1(0x51)
Frame 06: OP_CHECKMULTISIG(0xae)
Frame 07: OP_CODESEPARATOR(0xab)
Frame 08:
0000 - 2a 9b c5 44 7d 66 4c 1d 01 41 39 2a 84 2d 23 db
0010 - a4 5c 4f 13 END
Frame 09: OP_NOP2/OP_CHECKLOCKTIMEVERIFY(0xb1)
Frame 10: OP_DROP(0x75)

Then, I create the subscript from the closest OP_CODESEPARATOR before the OP_CHECKMULTISIG that I am executing till the end of the script. So, I include Frame 03 to Frame 10.
Then, I remove other OP_CODESEPARATORs in the script, which is Frame 07.
That means these frames should compose the subscript:

Frame 03: 1(0x51)
Frame 04:
0000 - 02 32 ab dc 89 3e 7f 06 31 36 4d 7f d0 1c b3 3d
0010 - 24 da 45 32 9a 00 35 7b 3a 78 86 21 1a b4 14 d5
0020 - 5a END
Frame 05: 1(0x51)
Frame 06: OP_CHECKMULTISIG(0xae)
Frame 08:
0000 - 2a 9b c5 44 7d 66 4c 1d 01 41 39 2a 84 2d 23 db
0010 - a4 5c 4f 13 END
Frame 09: OP_NOP2/OP_CHECKLOCKTIMEVERIFY(0xb1)
Frame 10: OP_DROP(0x75)

Serialized, the final subscript looks like this:

0000 - 51 21 02 32 ab dc 89 3e 7f 06 31 36 4d 7f d0 1c
0010 - b3 3d 24 da 45 32 9a 00 35 7b 3a 78 86 21 1a b4
0020 - 14 d5 5a 51 ae 14 2a 9b c5 44 7d 66 4c 1d 01 41
0030 - 39 2a 84 2d 23 db a4 5c 4f 13 b1 75

However, when this subscript is used to replace signature script, and eventually generate hash, the ecdsa_verify function reports that signature verification fails (but the inputs are legal).
Since the same procedure works for OP_CHECKSIG, I probably missed something obvious, but I couldn't figure this out reading the original Satoshi code, the current implementation, or Bitcoin Wiki.
If it helps, my code for OP_CHECKMULTISIG is here:
https://github.com/blaesus/tinybtc/blob/checkmultisig/src/script.c#L687
A more simplistic version (using prevTx.pubkeyScript as subscript) doesn't yield valid results either: https://github.com/blaesus/tinybtc/blob/validate/src/script.c#L344

What are the frames you're talking about?

The main confusion here comes from this :

First, generate the script by concatenating [sigScript][OP_CODESEPARATOR][pubkeyScript]

Then you add :

I understand that script execution has evolved from this

I'm not sure whether you mean "Builds upon this method" or "Has since changed this method", but if it is the former then this might explain the unexpected results that you're getting.  Hopefully my answer can clear this up.
It's true that for a (relatively) short period Bitcoin's script evaluation was done by the way you mentioned, where a CODESEPARATOR was placed between scriptSig and scriptPubkey then the whole thing was concatenated to form a single script which would be executed, but that was changed rather early on in commit 6ff5f718b6a67797b2b3bab8905d607ad216ee21 which dates to July 31st 2010.
After said change, which introduced a function named VerifyScript in script.cpp (today the logic is in interpreter.cpp), scriptSig and scriptPubkey are no longer concatenated with a CODESEPARATOR between them.  Rather they are executed as two separate scripts one after the other, where the stack's contents carries from the first to the second.
The difference is subtle and doesn't really change the flow of standard redemptions, but becomes noticable when a CHECKSIG operation is done within the scriptSig.
Starting from the funding transaction
b8fd633e7713a43d5ac87266adc78444669b987a56b3a65fb92d58c2c4b0e84d

we see that the second output in it is a payment to the following scriptPubKey at index 1 :
14 2a9bc5447d664c1d0141392a842d23dba45c4f13
NOP2
DROP

OP_CLTV is not active yet, so the opcode 0xb1 is still NOP2.
Which is then redeemed by
eb3b82c0884e3efa6d8b0be55b4915eb20be124c9766245bcc7f34fdac32bccb

by the input at index 1 :
0
47
  30
  44
    02
    20 276d6dad3defa37b5f81add3992d510d2f44a317fd85e04f93a1e2daea646602
    02
    20 0f862a0da684249322ceb8ed842fb8c859c0cb94c81e1c5308b4868157a428ee
  01
CODESEPARATOR
1
21 0232abdc893e7f0631364d7fd01cb33d24da45329a00357b3a7886211ab414d55a
1
CHECKMULTISIG

In the short period before commit 6ff5f718, the two scripts would be concated with a CODESEPARATOR placed between them to form the complete script, then execution will start.  We start with an empty stack, and a pointer to the beginning of the script marking the start of what would be the signed scriptCode :

Push 0 onto the stack
Push the signature onto the stack
Execute CODESEPARATOR - mark this point in the script as the start of scriptCode (overwriting the previous value set at the beginning)
Push 1 onto the stack
Push the pubkey onto the stack
Push 1 onto the stack
Execute 1-of-1 CHECKMULTISIG

At this point, we need to construct the scriptCode to be signed.  The rules are :

Take the subscript from the last executed CODESEPARATOR up until the end of the script
Remove all CODESEPARATORS
Remove all occurences of the signature that is currently being verified

Since the signature is actually before the last CODESEPARATOR, rule #3 doesn't come into effect here, but rules #1 and #2 do.  This leaves us with the following scriptCode :
1
21 0232abdc893e7f0631364d7fd01cb33d24da45329a00357b3a7886211ab414d55a
1
CHECKMULTISIG
14 2a9bc5447d664c1d0141392a842d23dba45c4f13
NOP2
DROP

Which is what you initially came up with, but now let's see how the change at 6ff5f718 makes a difference.
Recall that we are now dealing with two separate scripts, but none of the other rules change.  The only difference is that these two scripts are executed separately, one after the other, and that the stack that remains from the execution of scriptSig passes on to the execution of scriptPubkey.
We start by executing scriptSig and go through steps #1 - #7 as before, arriving at the same point of CHECKMULTISIG where we construct the scriptCode.
Since the actual executed script now consists of only what was in scriptSig, scriptCode becomes :
1
21 0232abdc893e7f0631364d7fd01cb33d24da45329a00357b3a7886211ab414d55a
1
CHECKMULTISIG

If this signature check passes (and it does), a value of 1 is pushed onto the stack, and scriptSig execution ends successfuly.  This stack now passes on to the exectution of scriptPubkey (which is very simple) and eventually left as the final value on the stack, which makes scriptPubkey resolve to True.
This transaction is very interesting really shows how non-trivial commit 6ff5f718 actually was.  It's a great example.
Another minor thing to note is that this scriptPubKey by itself is an anyone-can-spend script.  This script's conditions are satisfiable simply by passing a single push of an element which evaluates to True (e.g. 1 - 0x51) and that the signature check in scriptSig actually has no significance and does not secure the funds at all.
Edit :
Actually, looking into this some more, it seems that this transaction is specifically mentioned in BIP-17 (which has since been abandoned).  The 20 bytes in scriptPubkey is actually the hash160 of the 1-of-1 multisig script itself :
51210232abdc893e7f0631364d7fd01cb33d24da45329a00357b3a7886211ab414d55a51ae

This is in fact one of the example bip-17 transactions placed on chain by the bip's author.  Should this bip had been accepted, such a transaction would not be anyone-can-spend.  (you can see more details in the bip itself)

I figured it out myself (by trying all substrings of the script).
The correct subscript is this:

0000 - 51 21 02 32 ab dc 89 3e 7f 06 31 36 4d 7f d0 1c
0010 - b3 3d 24 da 45 32 9a 00 35 7b 3a 78 86 21 1a b4
0020 - 14 d5 5a 51 ae END

In other words, it's frame 03 to frame 06:

Frame 03: 1(0x51)
Frame 04:
0000 - 02 32 ab dc 89 3e 7f 06 31 36 4d 7f d0 1c b3 3d
0010 - 24 da 45 32 9a 00 35 7b 3a 78 86 21 1a b4 14 d5
0020 - 5a END
Frame 05: 1(0x51)
Frame 06: OP_CHECKMULTISIG(0xae)

Contrary to normal subscript generation, this subscript does not go to the end of the script (it doesn't include any part of the public key at all).
I am not sure why this is the case.

source: Stack Exchange

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

sort: votes


text:
How to check if confirmation is done or not yet?
After sending Bitcoin to any address, how can I check if the transaction has at least one confirmation?
Should I poll the transaction repeatedly or is there any event when confirmation is  made.

What software, service, or API are you talking about?

In order to see if the transaction has confirmed, you can search for it in any indexed transaction database. This can include Bitcoin Core running in -txindex mode, or a block explorer such as live.blockcypher.com or blockchain.info, for example. As soon as the transaction has been included in a block, it has 1 confirmation. If it is not found, or is still in the mempool, then it has either not propagated (failed validation checks), or has yet to be mined.

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


text:
How do I interact with Bitcoin Core from NodeJS?
I am new to the Bitcoin world. I have installed Bitcoin Core on a Windows machine and am running the full node. I want to develop a nodejs app that would be running on the same machine interacting with the Bitcoin node for 'balance/transfer funds/create wallet/etc'. I will really appreciate any pointers or sample code to achieve that.

Searching for "Bitcoin RPC protocol" might help you a lot.

I highly recommend looking at Bcoin. It is a full node implementation used by Purse.io but also includes a rich API for interacting with the Node and wallets. All of it running in NodeJS. Documentation is sparse but getting better.
http://bcoin.io/
Otherwise, bitcoinjs https://github.com/bitcoinjs/bitcoinjs-lib is a Javascript library that lets you parse, create, and sign transactions. But it doesn't handle the hard part of querying the network, caching information about transactions and wallets, or picking inputs and calculating fees when you want to spend.

For bitcoinjs-lib, Can I can configure it to connect to my local running bitcoin core full node ?

BitcoinJs does not handle th networking for you. You’d have to do the calls to the Core node yourself and use bitcoinjs to parse the data. I know, not friendly. Hence why I recommend bcoin instead.

My company also builds a mobile wallet Edge. It is built as a JavaScript SDK for React Native and the web, but in theory it runs fine on NodeJS as that’s how we test it. It CAN connect to your node if you run ElectrumX on top of your node. It can fully handle the networking between wallet and node and can even connect to multiple nodes concurrently. Sending and receiving is abstracted out to just a couple JavaScript calls. It may be worth trying out. https://GitHub.com/EdgeApp/edge-core-js

Can you suggest me how I get started with bcoin. I want to run a full node and then write nodejs code to get balance/transfer funds. Any sample code will be really helpful.

Sorry. I can only recommend heading to bcoin.io and looking at the docs. They also have a Slack channel where you can ask questions.


text:
Unable to install Bitcoin Core on my MacOS High Sierra
I'm trying to install Bitcoin Core (downloaded from bitcoin.org/en/download) on my MacOS High Sierra. But, I'm repeatedly getting the error The document "Bitcoin-Core" could not be opened. Finder cannot open files in the "volume" format.

Tried to google about it. But, didn't get any information about this error. Need some help to install this on my machine.
Currently using MacOS High Sierra(10.13.6).

Dammit, what was happening I don't know as a bit new to this MacOS thing. But, rather than double clicking on that stupid drive icon of "Bitcoin-Core" in desktop... I clicked on the drive icon from left-hand side pan from "Devices" section on Finder window & it opened without any error. It's working fine now. Problem fixes guys. What a waste of time. -.-

It wasn't your fault, it's a bug caused by an invalid .DS_Store metadata file: https://github.com/bitcoin/bitcoin/issues/14414


text:
Transaction in orphaned block question
This is a theoretical question. Assuming that a transaction (TX_A) with me on the receiving end gets added to the blockchain, I should be able to spend the amount I received. So I go on and spend it on another transaction (TX_B). What if TX_A gets orphaned due to forks? What happens to TX_B?

What if TX_A gets orphaned due to forks? What happens to TX_B?

It will be considered invalid, and your Bitcoin will not be spent. It will only be considered valid on the other forks, assuming they don't also invalidate the block. Usually the forks, if they are trying to play by the rules of the Bitcoin network, will also invalidate the block because the longest chain is always the valid chain.
Also, this should be referred to as an extinct block, see https://bitcoin.stackexchange.com/a/5869/60443

With all these invalidation of transactions, how do wallets even keep track of your available spending?

First, extinct blocks are not terribly common, though they have and will happen. However, wallets need to account for the possibility of orphaned blocks, if they don't they are putting their users at risk. Also, they typically require a minimum number of confirmations for new transactions before they allow spending.

correction, this terminology is confusing, and should be referred to as extinct blocks. orphans are just blocks with an unknown parent, but not necessarily invalid.

Thanks for the clarification. From what I read about confirmations, outputs can only be spent if the transaction that outputted them are 6 blocks deep in the blockchain. Does this mean that a block is invalid if a transaction's input cannot be matched with any outputs that are 6 blocks away (in the direction of the genesis block)?

The 6 blocks deep is not a rule of Bitcoin, but decided by the wallet or user, so no.

Note that most of the time, competing blocks at the same height will include a largely overlapping set of transactions as almost every miner selects their transactions by picking the transactions with the highest fee rate from their mempool. -- Thus, if there are no shenanigans such as doublespend attempts, your transaction should get included in the other chaintip at the same height or briefly later.

The way I understand your question, you are asking:

Assuming I get paid by a transaction tx_a that gets included in a block. I spend my output in another transaction tx_b. What happens to tx_b if tx_a gets unconfirmed in a reorganization?

When the node reorganizes to another chaintip, all transactions that were confirmed in the block that confirmed tx_a get added back to the mempool. Some of these transactions may already also be confirmed in the chaintip that the node is reorganizing to, but otherwise both tx_a and tx_b are now in the mempool. It is permitted to spend outputs of unconfirmed transactions, so that is not an issue at all, unless another transaction spent some of the inputs of tx_a in a doublespend that made tx_a permanently invalid. In that case, tx_b would of course also be discarded, since tx_a could never be part of the best chain given that some of its inputs were already spent.


text:
When does a blockchain fork resolution happen?
I understand that forks are resolved by largest proof-of-work etc. but when do the miners decide to resolve a fork? Is it a question of network consensus or does each individual miner resolve at their own pace?

Each node will usually resolve and reorganize their local chain as soon as they are made aware of a chain with more work.
If two blocks are mined at block height N, there is a fork. As soon as a single block at height N+1 is mined and broadcasted, any nodes that receive it will keep the block N that the new block builds upon, and orphan the other block as there is now one chain with more work.
This is what makes block withholding attacks possible, as an attack could broadcast several blocks at once, which suddenly present a new, longer, valid chain.

That is assuming that the miners are honest right? If let's say a group of miners are colluding, can they withhold from resolving until they are sure that their chain is longer?

Yes, that's exactly what a block withholding attack is - One or more miners don't broadcast their blocks until they want to, and broadcast entire sections at once

It really shouldn't be called an "orphan" block, because the block's parent is present and doing fine. ;) It's the transactions in the extinct block or stale chain-tip that are orphaned by the block no longer being part of the most-work chain.


text:
Is it technically possible to change the total amount of Bitcoin?
Also, is it possible to change the reward cycle duration or the number of mining- reward coins?

related: https://bitcoin.stackexchange.com/q/38994/5406, https://bitcoin.stackexchange.com/q/161/5406, https://bitcoin.stackexchange.com/q/8439/5406

Technically, yes, yes, and yes.  However, I'm not sure if we'd still call it "Bitcoin" at that point.
Any of these changes would require a hard fork, which means that the underlying rules of the system are changing in a non-backwards-compatible way.  It means that blocks/transactions from after the fork are not guaranteed to be considered valid to nodes running software for pre-fork.
So, to change Bitcoin like this in practice would require convincing the entire rest of the world to agree with the changes.  Anything less, and you will end up with two versions: the original and the one with your changes.  Which one gets the title "Bitcoin"?  I don't know.  That's a non-technical question, and a point of contention.
For an example of this in practice, see Bitcoin Cash.

that means : change is possible technically, but it required to be soft-fork nor it will cause a new hard-fork . thank you for your clear answer. my question was because i have thought about what bitcoin situation will be if its price decreased to a low levels for long years from now and  may its mining rewards will  become uneconomic .so there are many solutions to avoid that .


text:
How do different implementations of the Bitcoin Cash client know which type of coin they're processing?
TL;DR: Where in this code does the SV client figure out that it's not processing an ABC blockchain?

This image prompted my question.
There are a couple different mutually incompatible (I am assuming anyway) implementations of the Bitcoin Cash cryptocurrency client software...

Bitcoin Cash ABC
Bitcon Cash SV

My question assumes that each implementation processes their respective transactions using similar but mutually-incompatible blockchain processing rules.
Is it normal to run a Bitcoin Cash SV client implementation in a Bitcoin Cash ABC network? And vise versa? How, then, does one implementation know that the network it is running in, is (in)compatible with its particular processing rules?

Neither client concretely checks that it's on the wrong chain: BCH and BSV had an unclean split.
Neither changed the network magic, nor did either change their transaction format, so their nodes continued to communicate and transactions remained replayable from one network to the other. As MCCCS mentions, the two networks started following distinct best chains when each side included transactions that were invalid to the other network. At that point, full nodes were still connected to a mix of nodes of both protocols. They'd get announcements for blocks of either chain. As they download the first block with the new op-codes that were only permitted on one or the other protocol (OP_MUL and OP_DATASIGVERIFY), nodes would try to validate the block, and find the other protocol's block invalid. At that point, they'd ban the node that offered the invalid block and replace the peer with another connection. I think that they'd then at least disconnect or outright ban any new peer that also follows the (from this node's perspective) invalid chain when they get connected. This presumably caused peer churning on both sides until every node eventually made sufficient connections to nodes running the same protocol as themselves.
The screenshot you linked was posted about ten days after the split, so the topology reorganization may have still been on-going at that point (or the screenshot was created a few days before it was (re-)posted).
Especially services monitoring node population could also have been running special crawler-nodes that weren't actually running full node software and thus not announcing blocks, so those would have perhaps lagged behind on noticing the topology split.

They don't.
They have different, but sometimes common, consensus rules. There are two competing fork blocks with different transaction ordering rules and some transactions with either OP_MUL or OP_DATASIGVERIFY. One of the blocks are valid for that client, followed by many valid blocks. Sometimes, they process transactions of both network, as the replay protection is optional. They simply process if something is valid, or not if it's not.

„...One of the blocks are valid for that client, followed by many valid blocks...“ — Thanks but that's still unclear to me. Please can you rephrase it to be clearer? Please, bear in mind; I am not an expert like you :) — „...as the replay protection is optional...“ — That too. Please paraphrase? Please can you address these original questions also: „...Is it normal to run a Bitcoin Cash SV client implementation in a Bitcoin Cash ABC network? And vise versa?...“

@algoholic 1) The following blocks are valid to that client, as they use the same consensus rules.2) Transactions made after the fork are valid on both chains by default, unless the different, new added opcodes are used. 3) There's no new network magic. As a result, nodes of different forks can communicate, but not about everything is valid for both. There are different consensus rules which are strictly different. Sorry for the unclear parts, it's definitely my fault.


text:
Install Copay on Windows 7 64 bit desktop
I have windows 7 64 bit.  I need more information.  Step by step, please.
I have reviewed the previous answers but do not understand: (New copay on Windows 7)
1) Exactly what to download from where
2) How to install/ run the download
The windows app store says the download requires Windows 10 + one has to have/ create a Microsoft account. (https://www.microsoft.com/en-us/p/copay-for-windows/9mzgt30hl9df?rtc=1&activetab=pivot:regionofsystemrequirementstab)
From the previous answers, I tried downloading the zip file but cannot figure out how to install it.
Thank you

If you are uncomfortable with the instructions for CoPay, I suggest you consider using a different wallet. Electrum seems moderately popular, though I have no experience with it. See also What types of wallet are there?

You don't need MS Store or any account, the wallet is written in Electron, take a look at this: https://bitcoin.stackexchange.com/a/91138/93288


text:
Bitcoin cash to Bitcoin wallet
Apparently I am not alone in feeling foolish regards this.
I think things are safe, but would so much appreciate advice.
When using Coinbase, I had some small change in my Bitcoin Cash wallet, don't know how it got there, as I always use standard Bitcoin.
Anyways I deposited into my Bitcoin CASH wallet.
I then sent the Bitcoin Cash to a standard Bitcoin address, of which I have access to.
So it has been sent to a one off address which is mine.
Can any of you kind folk tell me what will happen?

Coinbase says its lost, even though I have seen answers that it can be retrieved.

Can someone put me out of my misery please by confirming if this transaction is floating in the aether never to be seen again.

If you sent Bitcoin Cash to a standard Bitcoin address you can still get to it (maybe).
There is too little to give you a fully correct answer. If the address is a wallet you control (not an exchange) then you should have a recovery password. It is possible to restore your BTC wallet into a BCH wallet, then transfer the funds from there.
I'm assuming you didn't accidentally send the coins to a Segwit address.
What would help the most, if you provided the transaction ID and the name of the wallet you use. (provide the path: Eg, Coinbase BCH > Exodus BCH > Coinbase BTC)
I can look into it a bit, make sure the tokens were transacted etc. Beyond that, i'm far more familiar about how to deal with this if you were running a bitcoin core node.

Im walking my dog, Coinbase have told me its a lost cause.

I'd need the the path of transactions first. I need to know who owned the wallet(s) at what point. If the final destination is indeed a Coinbase 1-off, then no. They won't bother with it.

Im going to give my dog the timehe deserves then maybe Ican go into this further with you if you dont mind, i really appreciate your time Cleanmarker

No worries. I'll check back on this. Let your dog do his/her thing. (I have 2 myself!)

Hi cleanmarker,

There is no rush on this, I can access the destination bitcoin cash address my money is sitting in looking into the transaction details in coinbase. Not going anywhere it seems. This is where I think you may be able to help me hopefully. Is there some way I can copy this address and send it to a bitcoin cash wallet. After all it is my address, my money. So you know I am incredibly illiterate when it comes to this sort of thing

Access to the destination via an exchange is not the same as a wallet on your PC or other device. Is the destination wallet on Coinbase? If not, what program/service are you using to service that wallet?

Im sorry Cleanmarker I am not very good at this, I can see the full transaction on coinbase, as that is what I use to buy bitcoins.

It was only a small amount of money, but it was to buy something important. Everything I do is through Coinbase, I use the wallets they have for me, I buy the coins and now Bitcoin Cash and send it straight away to an address that is a one off generated address each time.

No worries James. If it's a Coinbase account that received the BTC in a BCH account then the original statement they made to you stands. Because of security reasons they don't allow programmers access to unencrypted wallet key or recovery codes. This means while they COULD do it in an extreme scenario, they probably have to bug the 1 person they trust to access it (Because they will need at least one person able/trusted to deal with these kinds of things). Unless they can tack on a large fee to warrant all the work the response is simply "it's gone". Wish i could help more. Welcome to BSE.

Thanks for the clarification Cleanmarker.

I have learned a harsh lesson.

Fortunately it wasn't loads of money that affects me. I was just getting too blasé and thankfully as I say its minimal cash in the grand scheme of things. Will never make that mistake again. What I just dont get is I had a couple of pounds sterling in my bitcoin cash wallet in coinbase. I don't why it would be there if I have never dealt with bitcoin cash ever, as I would have made this mistake before. That is the really weird thing. Anyways what kind of dogs you got and where are you based. I live in Scotland, I was born in Glasgow and my dog is a mixed from a rottweiler and bull mastiff

I'm glad you're taking it well. We've all made mistakes. There are some real horror stories on here and the internet in general. People loosing what would be equal to $1.4 million due to a hack for example. (A security mistake, process mistake, address mistake etc). One thing blockchain is not: forgiving. I'm in the north eastern US with 2 white huskies. I just imagined a gigantic rottweiler.


text:
Why is my LND node closing channels?
I have noticed when running lncli closedchannels, that I have some channels that are closed by my node (close_type: local_force_close).
I am quite sure I have not initiated this manually myself. Is there some logic in LND that drops some channels?

Many!
If you look at the BOLTs ( lightning RFC) you will find many situations in which nodes must fail a channel (meaning a force close) if something happens in an unexpected way while communicating with a channel partner. This could be even as easy as an unresponsive channel partner while settling an htlc in which case you have to settle the htlc onchain. But there are many more conditions in which the protocol asks to fail the channel.

Thanks! “Fail the channel” is the term I was missing. Now I am indeed able to look up all the cases in the BOLTs.


text:
What exactly makes altering of data in non-bitcoin blocks hard?
If leading zeros is only bitcoin requirement, then what makes altering of data in blocks hard? Like now its easy to modify a block and generate new hash for every subsequent blocks since generating hash is not as costly compared to bitcoin requirement.

The leading zeroes is what makes altering block data hard. One of the things that makes a block valid is that it's hash is less than some predetermined value. For simplicity, this can be thought of as the hash has to have some predetermined number of leading zeroes. However making such a block meet that requirements is hard and being able to do so proves that you have done some amount of work, hence Proof of Work.
Making a block whose hash has enough leading zeroes is hard because the output of SHA256 Double (the hash function used in Bitcoin) is random. Given some input, you can't predict the output of SHA256d without running the data through it. So the only way to get some block data (the input) to have a hash with some number of leading zeroes is to hash it, see if it meets the criteria, and if it does not, change it and try again. This is what miners do, and the criteria restricts the range of possible valid hashes to such a small percentage of the entire range of possible hashes that it takes the entire network 10 minutes on average to find a hash that meets the criteria.
Iif you wanted to alter the data in a block, you would have to recompute the Proof of Work, i.e. you would need to find a block with your altered data that has a hash with the required number of leading zeroes. Keep in mind that it took the entire Bitcoin network 10 minutes on average to find the block you are changing, so it will probably take you longer than 10 minutes to find a replacement. Then if you want to change a block that has blocks on top of it, you would need to re-mine those blocks too. Otherwise your fork of the blockchain won't be considered the best blockchain as it is not the longest.
While generating a hash is fast, having to do it 25 sextillion (2.5 * 10^22) times on average to find a block is a lot of hashes and is going to take you quite some time.

Thanks @Andrew Chow, i understood everything you've said, but i think i wasn't as clear as i expected. I know that the leading zeros is what makes the altering hard, but happens with Bitcoin, as that's a Bitcoin requirement and not a Blockchain general requirement. So, on other blockchains platforms, that differs from Bitcoin, what makes the altering of blocks hard as there's no need to have leading zeros for the block's hash?

Most other blcockhains do the same thing or something similar, i.e. some value that is randomly produced has to be within some threshold.

Somone once suggested that it would have been more aesthetically pleasing if the value was approaching pi such that the block hashes would starts with 314159265 and become an ever more precise approximation of pi as the difficulty increases.

Altering data in a Bitcoin is hard because it requires a lot of dedicated cost. The confirmation of a transaction or data implies that it is committed to the blockchain with a valid proof-of-work, which is a specific form of a cost-proof. Proof-of-Stake (opportunity cost), Proof-of-SpaceTime (memory) can all be reduced to dedicated cost-proofs.
Let's consider a censoring a specific transaction which already has several blocks of confirmation. In order to do so, one would need to invest capital to acquire 51% or more of the global hash-rate and begin mining a branch at a lower height than the confirmed target transaction.
At some point, this 51% miner will have created the longest chain and successfully reorged the target transaction out. The barrier to such behaviour is the amount of capital to acquire this hash-power.
This capital cost to acquire 51% depends on transaction fees. If fees (confirmation demand) are high, more miners will join the global pool, thereby increasing the cost to acquire 51% mining hash power thereafter.


text:
How do different blockchains communicate?
I've learned that the different cryptocurrencies have their own P2P blockchain networks.
How do exchanges convert coins from one network into a coin on another network?

They don't communicate. Exchanging works in the real world: you send me X of coin1, I send you Y of coin2.

There are ways to swap cryptocurrencies of certain types in an atomic fashion. See atomic swaps: https://bitcoin.stackexchange.com/a/54141/90088

@PieterWuille So why is needed a few confirmations at blockchain when i'm exchanging cryptocurrencies? I'm trying to understand what happens under the hood of a simple exchange of cryptocurrencies.

Cryptocurrency exchanges are generally taking custody of your funds while you are using their service. You send a deposit of fiat to their bank account or cryptocurrency to an address under their control and after this payment has been confirmed, they credit you a balance on their platform. When you trade one currency for another, they only update their liabilities to you in their database. Only when you withdraw, they send you the corresponding cryptocurrency to your address or wire you fiat.
As you see, the exchanges simply accounts for what they owe you and there is no need for various blockchains to communicate beyond the exchange sending and receiving payments in various currencies.

You cannot just exchange two cryptocurrencies with one another that easy.
You will need a middleman like an exchange to do this.
An alternative is Atomic swaps. But it's still more experimental.
You can learn more at it here:

Can someone ELI5 to me for Bitcoin Atomic Swaps?
https://en.bitcoin.it/wiki/Atomic_cross-chain_trading

Atomic Swaps have been implemented in the lightning Network(Just as proof of concept!!)
Nevertheless, it's just a proof of concept and experimental. Exchanging one coin for another is done either by exchange or by communicating on the real world.

Thanks @dvg . Can you elaborate on your answer what's the process taken onto the exchange when exchanging two cryptocurrencies?

I don't know for sure how an exchange works internally. Basically, you deposit some cryptocurrencies there and can change them for another. Like when you exchange Fiat currencies. Technically it's specific to the specific exchange.

The exchanges do not turn a cryptocurrency into another, they just buy and sell them for you to somebody else within the exchange.
For swapping the coins there is the already mentioned experimental atomic swap technology which could be revolutionary and potentially disruptive for traditional exchanges.


text:
Is there a way to distinguish miner nodes from other nodes?
In the bitcoin network, there are many different types of nodes. One of these types are miners and in the bitcoin network, is there any way to distinguish a miner node from a non-mining node? I'm asking because part of some research I'm doing, it would be great help to me if I knew which nodes were the mining nodes

Yes, but only in a probabilistic way: If you run many different nodes and try not to leave any node in the network that isn't connected by any of your nodes, you'll be able to track and visualize the relaying of the new blocks. After a while, you'll have the whole network graph, looking at which might obviously show the miners.
By the way, using the same method, it's possible to find the authors of transactions, which is what Dandelion is aiming to solve.

"looking at which might obviously show the miners"-- might, but in practice often it doesn't.  People have done this in the past in order to DOS attack competing miners, and I've found that connecting to fibre has apparently gotten me DOS attacked, because I was the first origin the attacker saw.  Because I was closer to the attacker than other fibre connected nodes.   Performing this deanonmization attack correctly probably requires nodes actually close to the miners, or compensating for the latency of each link.  A lot can go wrong here. Any error risks tainting research based on it.

My node is listed as the “source IP” of many services transactions as a result of the way it routes transactions as well. These sort of heuristics absolutely suck and seems to result in far higher numbers of people in the SSH honeypot than normal.


text:
Expected use model for PSBT
I want to use Bitcoin Core to create a PSBT for offline signing (cold storage) of a multisig p2wsh-in-p2sh address, such as that created by Glacier. Based on the PSBT doc I assume I want the online node to be the Creator & Updater, and the offline node to be the Signer, Finalizer, and Extractor.
Firstly, what is the expected use model (using RPC)?

I've created privkeys, redemption script, and matching address on an offline node. How do I import this into my online node (presumably as a watch-only address)?
Using the online node, how do I construct a PSBT that spends some of the UTXO(s) for this address?
Using the offline node, how do I sign said PSBT using the privkeys, redemption script, and matching address that I have stored on paper?

Secondly, is this process expected to work in today's 0.17.1 software? Is it expected to change in the near future?
Thirdly, is this secure, assuming a secure offline node but an insecure online node? Can I be sure this isn't funding a too-large miner fee, for example? I understand that hardware wallets sometimes require the entire input transactions in order to verify input amounts.

It is important to note that with this process, you will want to use a wallet that does not have private keys. Otherwise, you could accidentally be sending Bitcoin to an address that is in the online wallet. This especially important with change addresses because change addresses are automatically pulled from the current wallet. By disabling private keys, you won't have any change addresses (or other addresses) in the wallet that has your addresses imported. You can create a wallet that has no private keys by using createwallet "<wallet name>" true.
When doing the following with bitcoin-cli, make sure that you include the option -rpcwallet=<wallet name> so that you are using the correct wallet that does not have private keys.

I've created privkeys, redemption script, and matching address on an offline node. How do I import this into my online node (presumably as a watch-only address)?

Use the importmulti command to import your addresses, their redeemScripts, and their witnessScripts, if any. When you receive coins to these addresses, you will be able to see them in your online wallet's balance using getbalance "*" 0 true.

Using the online node, how do I construct a PSBT that spends some of the UTXO(s) for this address?

You can use the walletcreatefundedpsbt command. Your command will be something like:
walletcreatefundedpsbt '[]' '[{"<recipient address>":<recipient amount>}]' 0 '{"includeWatching":true,"changeAddress":"<change address>"}' true

What this will do is create a transaction with the outputs to your recipients. It will then choose inputs from the wallet, and add them to the transaction. If there is change, it will use the change address that you specify. walletcreatefundedpsbt has other options too. Read the help text for more information.

Using the offline node, how do I sign said PSBT using the privkeys, redemption script, and matching address that I have stored on paper?

Assuming that your offline node has the private keys, you can sign using the offline node by taking the PSBT from the previous step and using the walletprocesspsbt command. Your command will be something like this:
walletprocesspsbt <psbt>

It will give you a PSBT that contains signatures. You can double check this by decoding it with decodepsbt <psbt>.
Then you can finalize and extract using either your online or offline node, it doesn't matter. You will use finalizepsbt <psbt>. If everything is correct, you will get a hex transaction that you can send with sendrawtransaction. If some part of the process failed, then it will fail to finalize and extract, so you will get another PSBT from finalizepsbt.

Secondly, is this process expected to work in today's 0.17.1 software?

Yes

Is it expected to change in the near future?

Not significantly. There may be more commands that are added that are useful, but not necessarily required. The format for the existing commands won't change significantly if at all.

Thirdly, is this secure, assuming a secure offline node but an insecure online node? Can I be sure this isn't funding a too-large miner fee, for example? I understand that hardware wallets sometimes require the entire input transactions in order to verify input amounts.

Yes, it is secure, even if the online node is compromised. When the offline node signs, it does several checks. It will check that the entire previous transaction included for non-witness inputs has a txid that matches the one specified in the transaction being made. This ensures that you are spending what you expect to be spending.
For segwit inputs, part of what you are signing is the value of the output being spent. So you always know what amount you are spending. If the amount is incorrect (does not match the amount that you expect for that output), the signature will be invalid and thus the whole transaction will be invalid.
These checks ensure that what you sign will either be exactly what you expect it to be, or that the result is invalid and nothing moves anyways. Since the transaction includes full amount and scriptPubKey information, you can double check that the amounts are correct, the fee is correct, the inputs are the ones you want to use, and the outputs are the ones you want to create by using the decodepsbt command.

Having trouble with the importmulti: https://bitcoin.stackexchange.com/questions/83102/how-to-import-p2wsh-in-p2sh-multisig-as-watch-only

Once I got the importmulti figured out, the rest worked great!


text:
Can someone please explain the meaning of "neutrino" within the lightning network?
Rene Pickhardt wrote the below quoted comment in another thread about whether a mobile wallet can be both a full lightning node and wallet at the same time.

I have many lightning nodes running but they all need to at least communicate with a bitcoin full node at this time. Most of them share the same bitcoin full node. So yes you could have a lightning node running on your phone that talks to a bitcoin fullnode somewhere else. The game changes when neutrino is fully working (I think it is still not integrated to bitcoin core) – Mar 4 at 22:03

Could someone give more precise explanation -
1)  What is this "neutrino" referred above?
2)  When is it expected to fully work, on what is timeline dependent?
3)  And to what extent/how would this "neutrino" change the "Game" as implied above?  What effects would it have on the way lightning works?

Building on the great answer by Andrew:

1) What is this "neutrino" refered above?

Where as BIP 37 generates a client side Bloom filter including the HD wallet addresses, BIP 157/158 "Neutrino" creates a server side [can be any Bitcoin full node] Golomb-Rice filter including all transactions in a valid Bitcoin block. You are no longer querying if a specific transaction is in a block, which might reveal which transactions you are interested in, but rather you query which transactions are in a block, and then you download the interesting blocks from another node. Every valid block has only one correct BIP 158 filter, and you can thus cross reference against several different nodes.

2) When is it expected to fully work , on what is timeline dependent?

I don't know how fast the core process will integrate BIP 157/8 [probably in two weeks?!], but because this is not a consensus critical change, it can be implemented by individuals much earlier. For example, Wasabi Wallet is creating Golomb-Rice filters on the centralized Wasabi back-end server, the individual wallets are checking which block contains their interested transactions, then the wallet is downloading that block on the Bitcoin P2P network over tor, or from your own full node. This provides great privacy improvements, as neither the Wasabi back-end nor the P2P network know exactly which blocks [due to tor / your own node] or addresses [due to BIP 157/8] you are interested in.
Further, Lightning Labs has a testnet version of their app which is running Neutrino, their implementation of BIP 157/8.

3) And to what extent/how would this "neutrino" change the "Game" as implied above? What effects would it have on the way lightning works?

As Andrew points out, running your own full node and verifying the entire block chain is the best practice for both security and privacy. With SPV proofs you inherently "trust the miners" that the chain with most accumulated PoW is valid. "Inverted" block filters protect wallet privacy and is a great improvement to address filters. I'd say that in all regards: Own full node >>> Golomb-Rice filters > Bloom filters.

1) What is this "neutrino" refered above?

Neutrino is an addition to the Bitcoin P2P network protocol which enables more private SPV wallets. How it works is that nodes will create a "filter" for each block and relay those filters to SPV wallets. Those SPV wallets can then check if any of their addresses appear in the filter. If they do, they can request the entire block and pull the transactions that they want from that block. This protocol is described in BIP 157 and the filter construction in BIP 158.

2) When is it expected to fully work , on what is timeline dependent?

It is dependent on support being merged into full node software. This is a network protocol feature and must be supported by full nodes. Currently the predominant full nodes software in use on the Bitcoin network is Bitcoin Core. There is active and ongoing work to get BIP 157/158 into Bitcoin Core. There are other software that support BIP 157/158 but they are not widely used. There is no current roadmap or timeline for BIP 157/158 inclusion in Bitcoin Core.

3) And to what extent/how would this "neutrino" change the "Game" as implied above? What effects would it have on the way lightning works?

Neutrino would make it possible to run Lightning Network software on lower powered devices such as mobile phones. It makes it possible to not need the Bitcoin blockchain or to not receive every single block and transaction yet still be fairly certain of the security of your Bitcoin and lightning channels. Of course it is not as secure as running your own full node, but for devices where this is not possible, BIP 157/158 would make it possible to run your own lightning wallet without fully trusting a third party.

@max-hillebrand  and Andrew,
thank you a lot awesome!
I totally forgot a very important part of the question , can you answer please:
SO, does it mean with Neutrino implemented into Bitcoin, that one could operate a MINING Node without having to use the entire gigabytes of chain files?

This reddit comment including the links therein should answer your question

Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference.


text:
Lightning - Question about force-closures of channels and its impact on recovering funds
Dear Lightning experts,
someone mentioned in context with lightning channels the following things, and I would like to ask you if this statements are true, and if yes, is this a problem in a future world where lightning becomes mainstream, how would we prevent such scenario of not returning funds`?
"The mnemonic seed will not allow you to recover funds that are off-chain in lightning channels...EVEN if the peer force-closes the Channel! And Static channel backups will not fix this..."
So question is: Why not designing it in this way:  "IF  there is a force-closure by the other party, THEN your funds are DIRECTLY automatically returned back to your wallet."?
Why in the world was the abovementioned automatic solution not in place now (or is it??)? Because of watchtowers or other stuff?
If above statement about not being able to recover... is not true, then pls elaborate kindly what the actual "return mechanism" is in such force-closure scenarios?
Thank you all

Sorry René, it seems you fell into a Bcasher trap here ;) OP phrased his question very vaguely and then proceeded to cry CENSORSHIP when you admitted there might be some truth contained in what he alluded to.
In reality, the case OP is alluding to is a very rare edge case that could ONLY occur, if the following things are ALL true:
1. You don't back up your channel state.
2. You don't give your channel to a watchtower.
3. You lose your channel state.
4. Your channel partner knows this.
5. Your channel partner has an old channel state that is more advantageous to him.
6. Your channel partner is evil.
This particular combination is easy to avoid and doesn't really occur in practice.
In a normal force-close, OF COURSE your funds are automatically returned to you.

great thx! this is awesome news, so just to reiterate : there is an AUTOMATIC REFUND mechanism in case of force closure.

and can you pls provide a link to a correct source  which explains in clear terms your abovementioned points 1 & 2
1-how  to "back up your channel state", or how to back up your seed in lightning?  AND
2-how to "give your channel to a watchtower" ?
-thank u   (and i am not a bcasher, just uninformed-- but the guy whom I quoted may be one:-))

...i guess everyone needs to do his best to spread CORRECT info. if even rene fell (as you imply) for it, there is still much to do

Since last year, there is an optional feature in the BOLTs called "data loss protection", which should be live in all the major implementations now. This allows a fallen behind node to ask its channel partner to close the channel cleanly. This is nicely explained here by eclair: https://medium.com/@ACINQ/adding-data-loss-protection-to-eclair-598c62494096

The central point with regards to this question is put beautifully in this quote from the above ACINQ medium post: "in order to lose money, you would have to lose your data and have a dishonest counterparty and they are willing to bet all their money that you are telling the truth when you say you lost your data."

As for updating your channel state, this is implementation dependent. For example, both eclair (https://medium.com/@ACINQ/enabling-automated-backup-on-eclair-wallet-9f58dc3d8407) and lightning-wallet.com (https://lightning-wallet.com/reimbursing-funds-locked-in-a-lost-payment-channel#reimbursing-funds-locked-in-a-lost-payment-channel) back up your data automatically all the time to google drive (and an Olympus server in lightning-wallet's case). IIUC, LND's plan is to devise a mechanism that allows for static channel backups. The nice thing here is that innovation is permissionless.

Watchtowers are not really live in the network as of now. This is partly because they are not really needed (attacks such as the one you asked about aren't really happening, because the risk of losing all their money in the state seems to be too great for attackers), and partly because everyone is waiting for eltoo, a newer drop-in replacement channel construction which would make watchtowers much simpler and cheaper. So there is no how to I could point you to right now, I guess.

As far as I understand the situation the statement is true and the reason is for you to increase your privacy.
You mnemonic seed is equivalent to some secrete from which you will derive all the keys that are being used in lightning. While the key derivation in principle is deterministic it also uses information about the channel state. c.f. https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#key-derivation
This results in situations like this where previously in c-lightning there was a force close situation where c-lightning forgot about the channel state but also forgot to write down the redeem script and I alost my btc (check out: https://github.com/ElementsProject/lightning/issues/1738 )
So why changing addresses and keys for ever new channel state. The reason is that we don't want to share too much information with watching services (once they are there) Thus channel states are tried to be decorrelated. Also assume the address for spending your on chain btc would always be the same then you would send btc (when closing a channel for a second time to an address which previously received funds and from which you might have already spend in the past)
I think it is an implementation details (quite an important one) to be able to backup your channels / coins / UTXOs properly which will come. So if you look at the bug from above. The protocol actually worked I got my keys back but the implementation I used forgot my private keys for that address. This particular bug is fixed yet but there are still technical difficulties wich backing up channel state in an easy way.

thx. So it is TRUE?! but I dont get it:  everyone can lose their funds if the other party force-closes the channel??? This is the ANTI-definition of a free financial world, this is precisely a CENSORSHIP mechanism, right?!
Or am I misunderstanding here sth??
How can one "force-close" a channel? How can I on the other side make sure I receive back my funds??
What is this for a joke, is this a high-prio on the list for Devs`?    @rene-pickhardt

I dont get entirely the "Privacy" piece of reason. What has privacy to do with returning funds from force-closed channels??? where is the privacy leak?  And also this is highly non-sensical. It is 1000times more important for a person to have his MONEY back instead of any kind of privacy. What does he need privacy for when he doesnt have his funds.
Why not just return the funds automatically ? @rene-pickhardt

generally if you have your lightning node with your seed and your data base that encodes your channel state you don't loose your fund if someone force closes a channel.  The only thing is that people warn users that the seed in lightning works differently than in bitcoin.

great, and can you link to a good explained source  which explains in clear terms how  the seed(backup) works in lightning differently to bitcoin? thx


text:
the client's 'invalidateblock' debugging command - possible prevention against majority attack?
there is a 'invalidateblock' debugging command in the btc client. How can this command be used in a situation of majority attack threat and play a part of countering the attack?
I understand that this command lets nodes 'ignore' blocks generated by the attacking miners. But is that it? What happens with the blockchain, how can it continue to live on without the majority attackers?

If there’s a case of a majority hashrate, human intervention of a single instance can not prevent something that continuous and ongoing. The amount of coordination required to keep the network in consensus would be impossible to obtain if this were a solution.
If Bitcoin fails, it’s time to move on rather than patching it up.


text:
Bitcoin Orphan blocks - short question about the "time lag" factor and proof-of-work "size"

"However, it is possible that two miners produce a block at a similar
  time. This situation occurs because the acceptance of the blocks into
  the blockchain by the nodes of the blockchain network does not happen
  instantaneously.
This time lag in accepting a block may lead to another miner solving
  for the same exact block. But only the block with the larger size of proof of work gets accepted into the blockchain."

This is the background of how orphans are produced and handled.
Can you please explain in short

1) What is this "time lag" ? I would like to understand (detailed) what happens during this time lag, what are the full nodes exactly doing during this time until they decide to accept the block into the blockchain? Is this maybe the moment where the nodes check for all the bitocin protocol rules (refering to https://en.bitcoin.it/wiki/Protocol_rules)? Or sth else
2) What is the "size of the proof of work" exactly? Is it maybe the number of leading "zeros" in the proof of work hash, or the "nonce" number, or sth else? On which parameter must you look to know which block was the result of a more "complex work"?
3) Above mentioned protocol rules: When exactly are the nodes (or the network) checking for them, at which exact step of the bitcoin transaction/consensus cycle?: Before miners receive the transactions, after miners receive the transactions but before they start to work on the PoW hashing puzzle, or after they solved the puzzle and broadcast the block to the nodes?

Thank you

What is this "time lag" ?

When a miner finds a block, they will broadcast it to the network. As with all real-world networks, there is a latency (“lag time”) for this information to be received by the other nodes in the network. Specifically, there will be some amount of latency between the miner that found the block, and other miners on the network. Even if the latency is small (milliseconds), there is still some chance that another miner will find a block within that “lag time”.

What is the "size of the proof of work" exactly?

Nodes will follow what is colloquially referred to as the “longest chain”, but in reality they are following the “chain with the most work” (the difference is subtle, but important). Each valid block is equally valid, so for there to be “more proof of work” on one chain is to say that chain is “longer”, and thus the valid chain.
If two miners find valid blocks at the same block height, it will not be clear which block will become a part of the eventual longest chain, until a miner finds a new block that builds upon one of those two blocks. At that point, the longer chain will become clear, and the network’s nodes will follow it.

Above mentioned protocol rules: When exactly are the nodes (or the network) checking for them

The consensus rules are defined by the source code itself, there is no formal specification.
When a node on the network hears about any new transaction or block, it will run a series of checks to determine that transaction/block’s validity. If it is invalid, it is discarded.
When a miner assembles a block template, they will choose only transactions they have determined to be valid, and carefully craft the block to be valid also. So this is done before they start hashing, otherwise they would be wasting hashpower by creating an invalid block.


text:
How many recipients can fit in a single Ark shared output?
It's the only boundary the taproot/MAST limitation of 128 levels of the tree, ie. 2^128?

MAST isn't really relevant here. As the Ark vtxo trees are just trees of sequential transactions. In theory they can be arbitrarily large.
Some things are to take into account though:

More round participants means more interactivity. Since all participants in the round have to provide signatures for the round to be successful, more participants means higher likelihood a round will fail and will have to be restarted, so the longer a round will take, time-wise. Note that ASPs can limit the number of participants in a round if needed and even run multiple rounds in parallel.

More vtxo tree leaves means a higher cost for unilateral exit. The number of transactions a user has to broadcast (and pay fees for) for a unilateral exit is log2(n) with n being the number of leaves in the vtxo tree. While this scales logarithmically, which is pretty great, it can still become a significant burden for users to participate.

When broadcasting multiple transactions for a unilateral exit, probably using a fee strategy like CPFP (child pays for parent), mempool policy puts an effective limit on the size of the exit transaction package. Currently, Bitcoin Core has a descendent limit of 25 transactions. Current work on cluster mempool will probably change this limitation and replace it with a cluster size limit (IIRC of 100). The way either of these limits affect Ark exit transactions is subtle and depends on how many people are exiting from the same Ark tx at the same time.

Eventually, I think the latter consideration will be the realistic limiting factor on realistic Ark vtxo tree size.
For example, using pre-signed transactions (clArk, i.e. covenant-less Ark) or using OP_CTV, this effectively limits the number of nodes in the entire tree*. With a limit of 25, that would mean a tree with up to 24 leaves and with a cluster limit of 100, that would mean 99 leaves.
However, with more powerful introspection opcodes**, the intermediate leaves could be fee-bumped so that this limit no longer holds.

*: In fact if only one leaf of the tree can confirm, it can make space for other branches. So let's say all nodes except the leaves is the limit. Meaning that for n leaves, there has to be space for n + 1 txs in the mempool.
**: like OP_TXHASH, OP_CHECKTXHASHVERIFY, OP_TX, direct introspection opcodes (or CAT+CSFS)

Considering that you have the limit of 25 descendants in the mempool and that you have to broadcast log2(n) +1 txs when you unilaterally exit, shouldn't the max number of leaves be 2^24?

You'd think so. But nothing prevents others from broadcasting their leaves as well, and then some of the txs in your branch could be dropped. So to make sure your exit branch can't get dropped from the mempool, you need the entire tree to fit. This is with constructions where you can only add fees on the leaves. Using something like TXHASH, you can add fees to intermediate nodes and then it doesn't matter anymore.


text:
Using key aggregation (multsig) in P2TR script path spends
I know that it is possible to create a 2-2 multsig using Taproot by combining both private keys into one public key and defining that as the key path spend. I also know that it is possible to use Tapscript to do the same thing with a script path spend using OP_CHECKSIGADD.
Is it also possible to use key aggregation in the script path spend, by just providing a public key and signature but doing the same key aggregation as in the key path spend? If so, would it ever make sense to use a "normal" OP_CHECKSIGADD operation in the case of multisig (not threshold signatures).

You are right. You could either use a leaf with a single aggregated key or a leaf with a more traditional multisig construction using OP_CHECKSIGADD.
The advantage of the aggregated key is its smaller input saving fees. The disadvantage is that MuSig2 is an interactive protocol with multiple rounds which can be inconvenient if some of the signers are airgapped systems.
The OP_CHECKSIGADD construction on the other hand is a non-interactive construction, but reveals more information on-chain and costs more.


text:
What are the consequences of high orphan block rate?
I know the disadvantages of a high stale block rate include:

More opportunities for double spend attacks
Lower network difficulty making the network cheaper to attack

But I don't know how  even an orphan block could affect the network

Orphan blocks (in that meaning) are not a network-wide condition. They're an implementation detail (and arguably a bug).
Orphan blocks are simply blocks for which a particular node in the network doesn't have the parent yet. It doesn't mean that parent does not exist.
Since Bitcoin Core 0.10, this concept simply doesn't exist anymore. They were a side effect of the old block fetching logic that requested whatever other peers offered. In the new "headers-first" logic, the headers are downloaded and validated first, before blocks are requested. This gives guidance to the node about what to download and in what order. Since that change, blocks are never requested before their parents are known, and if a peer were to send a block unsolicited anyway, it is simply discarded as a protocol error.


text:
Is verification of a blockchain computationally cheaper than recreating it?
One of the advantages of cryptocurrencies like Bitcoin that is often repeated is how hard it should be to manipulate past transactions. The reason that is often stated is that you would have to re-calculate all the headers with all the hash values of the whole chain which is practically un-doable.
My question is: How do you verify the blockchain integrity? Don't you also have to recalculate all the values to see whether they are valid? Or is the complexity class of verification different from creating a new chain? In other words is there some asymmetry at work here and if yes how does it work?

Is verification of blockchain computationally cheaper than recreating it?

Yes, far easier

How do you verify the blockchain integrity? Don't you also have to recalculate all the values to see whether they are valid?

No.
The miner has to find a value for parts of the block they can choose a value for, such that a hash of the block is a number that is not bigger than a target number. This is impossible to predict without actually calculating the hash. So miners have to try a very large number of different choices before finding one that produces the hash with a numeric value smaller than the target.
The verifier only has to recalculate that hash once because they don't need to vary any part of the block.
(note, the above is a simplification but the principles apply)

Reference:

Nonce
What exactly is Mining?

The reason that is often stated is that you would have to re-calculate all the headers with all the hash values of the whole chain which is practically un-doable.

It's not the mere recalculation of new headers: miners currently create about 8×10^19 block candidates every second. However, at current difficulty levels, it takes about 4.8×10^22 block candidates until a valid block is found. E.g. to change the history five blocks back, you have to find six blocks (approximately 2.9×10^23 block candidates) before the whole network together finds one more block.


text:
How will Bitcoin be inflation free?
In the research paper, the author(s) mention(s) the following:

Once a predetermined number of coins have entered circulation, the incentive can transition entirely to transaction fees and be completely inflation free.

What does this mean?
I understand that once the 21M Bitcoins are minted, the incentive will only be to earn transaction fees.
I do not understand the part of fees being inflation-free.

Inflation is newly mined coins added to circulating supply. When block rewards become zero and transaction fees are the only incentives for miners, there won't be any new coins added to circulating supply.
According to https://www.viewbase.com/inflation (In last 24 hours):
1031 BTC mined
Circulating Supply of Bitcoin is 18,504,668 BTC
% of newly mined coins(24h) is 0.006%
Annualized inflation rate is 2.03%

So, inflation means the addition of new coins and it has nothing to do with inflation of transaction fees?

The "inflation free" means inflation of supply, not inflation of price

Transaction fees does not change supply. Alice has 0.25 BTC in wallet with some UTXOs and wants to send 0.1 BTC to Bob. Alice creates a transaction with 0.1 BTC as one output having address shared by Bob, another output with some change if required and a small fee(0.0001 BTC). This fee is not added by creating new coins. It's deducted from bitcoin Alice hold in wallet. Every block mined includes block reward (half in every 4 years) and fees for transactions added in block.

@AviralSrivastava There exist two somewhat related but very different concepts: monetary inflation and price inflation. Monetary inflation refers to the amount of currency in circulation increasing, while price inflation refers to the value of goods/services expressed in currency units increasing. The paper you are referring to is talking about monetary inflation; it's hard to predict what Bitcoin's price will be in the future.

This answer could be improved by incorporating the answers to the follow-up questions from the comments into the answer post.


text:
InvalidateBlock RPC call behavior with Bitcoin Core
I'm currently implementing the rpc call invalidateblock on btcd, an alternate Bitcoin full node implementation. I'm trying to figure out how Bitcoin Core handles branch selection on reorganizations with invalidateblock.
Say there's 3 chaintips like so:
genesis -> 1  -> 2  -> 3  (active)     (chainwork=8)
       \-> 1a             (valid-fork) (chainwork=4)
       \-> 1b             (valid-fork) (chainwork=6)

Blocks at height 1 were received in the order of: 1, 1a, 1b. Block 1 was received most recently and block 1b was received last.
If I call invalidateblock on block 2, which block will become the active chaintip?

The same rules apply as during normal active-chain selection:

Ignore all known-invalid blocks and their descendants
Of what remains, keep only the tips with the most chainwork
If there are multiple of those max-chainwork valid tips, pick the one which was received first.

So in your example it would depend on how much chainwork genesis+1 has. If it's more than 6, 1 would win. If it's less than 6, 1b would win. If it is equal to 6, it will depend on whether 1 or 1b was received first.

Follow up question:
Suppose I called invalidateblock on block 3. genesis+1+2's chainwork is 6. If block 1b's chainwork is 7, would the active chain tip now be 1b?

@kcalvinalvin Yes, the history is not relevant in determining what the new best block becomes, given the set of blocks, their validity, their chainwork, and their time of receiving, you can always determine what the active chaintip becomes.


text:
Orphan blocks explorer
Is there any blockchain explorer that lists orphaned blocks or reorgs?
How often does it happen in general? I only found this site which doesn't show any orphaned blocks after 2017: https://www.blockchain.com/charts/n-orphaned-blocks
Im trying to download all blocks into a database and want to verify I have correct blocks

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


text:
When will the last Bitcoin be mined?
Estimates have been thrown around a lot recently as to the year in which the last Bitcoin will be mined- where are these estimates coming from? Could someone send me to the relevant code?

The code is in the one of the answers to the question I am marking this as a duplicate with. (Nick's to be specific.) The accepted answer goes into more of the algoritm and schedule.

possible duplicate of How many bitcoins will there eventually be?

Actually this was the question I was really looking for. It might be a better dup of this one : http://bitcoin.stackexchange.com/questions/9959/where-in-the-code-in-the-satoshi-client-is-21-million-cap-implemented

The estimate is 2140 based on the block reward halving frequency of four years. According to math and knowledge that there are 32 halving events, in 2136, the block reward will yield 0.00000168 BTC per day, which is 0.00000042 BTC per block. That's 42 satoshis.
It's arguable that there could be one additional halving, to a block reward of 0.00000021 BTC, but that would require a major protocol modification since the number of Bitcoin would then exceed 21 million. Additionally, to go past that, there'd have to be a protocol modification to extend divisibility past eight decimal places. It is far, far to early to worry about either of these, because we're more than a century away from this problem.

What's the variance of the estimate of 2140? Is it plus minus 2 years, 3 years?

The time between blocks is currently 8.57 minutes. That's about 9% faster than the 10 minutes-per-block goal that puts the final block mined in 2140. The time-betwee-blocks varies pretty widely. I can't find a graph of it, unfortunately. I've see it as low as 6 minutes, and as high as 14 in the last few months.

Why does the page you link me shows "time between blocks = 10.00 mins"? Where did you get 8.57?

That value changes constantly.

Any idea how is that number calculated?

It's as simple as (60 min * 24 hrs)/$num_blocks_last_24hrs. If there were more than 144 blocks in the last 24 hrs, then we're going faster than we should, and the difficulty is more likely to increase. If it's less, then we're going slower, and difficulty will decrease.

Would you consider this chart as accurate? : http://blockchain.info/charts/avg-confirmation-time?timespan=1year&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=

Yes, that would be close enough to time-between-blocks, but it doesn't account for outlier situations. E.g., 1,000 transactions broadcast immediately after a block broadcast would skew this chart but not affect the time-between-blocks figure.

@ColinDean: How did you arrive at the 42 satoshis per block? In 2136, I got 2 satoshi per block. According to my calculation, the reward will go from 74 to 37 satoshi in 2116, it never hits 42 satoshis.

“It is far, far to early to worry about either of these, because we're more than a century away from this problem.” Sounds familiar. Actually, this problem might be even worse, because it might require all Bitcoin nodes to upgrade together – whereas the year 2000 problem could be fixed separately in each system.

Bitcoin's reward schedule is implemented in eras of 210,000 blocks. The block subsidy gets halved with the first block of each new era. The 33rd "halving" at block 6,930,000 will reduce the block subsidy limit from 1 satoshi per block to 0 satoshi per block¹ and therefore the last block creating new bitcoins will be block 6,929,999.
At block intervals of 10 minutes, 210,000 blocks translate to about 3.99 years, although blocks have been found faster in average in the past. Under the simplifying assumption that the halvings will occur about every four years, the final block that creates new bitcoins would occur approximately in 2140.
You can find a table with the respective calculations here: Bitcoin Reward Schedule
Really, the mining reward will get minuscule much earlier already. In 2036 99% of the bitcoins will be in circulation, in 2048 it will be 99.9%.

¹Actually, the limit is 0.58207661 satoshi per block at that point, but since only whole satoshis can be paid out, none may be collected by miners.

As per considering mining of any cryptocurrency is calculated by increasing hash rate and difficulty and decreasing block rewards. So time prediction of final block mining is 2145.

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


text:
Mine valid but nonstandard transactions
Is there a way to configure cgminer to accept valid but nonstandard transactions for mining?
If not, where, theoretically, would be a good place to look if I was interested in mining nonstandard transactions into the blockchain, i.e. what must I modify in what node/client code?
Alternatively, would it be enough to modify a client to relay such transactions to cgminer without modifying the mining package itself? Does cgminer also verify that a transaction is standard?

I suggest you go and read about just what cgminer is presented with, in most cases it is just the header which has absolutely no bearing on the content of the block. It does not, and can not in most situations know what the work it has been provided with actually is.
The node providing work must be modified slightly by changing the isStandard checks, which you can find in main.cpp of the Bitcoin core client. There's not really that much interesting you can do at present without making your block invalid, but it's easier just to submit them directly to eligius.st which is a pool that already accepts certain nonstandard transactions. The chance of a user solo mining a block is vanishingly tiny at this point.

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


text:
Is it possible to add a transaction input to a transaction in the mempool?
Is it possible to add an input to a transaction that is in the mempool?
For example, if someone is paying 1 BTC to their friend, I can get the raw hex data of this transaction from the mempool before it is mined.
I can then sign an unspent transaction (Let's say 3 BTC) with my own private key, list it as an input, and get the raw hex data for this. Then, I can add a 3 BTC output to someone else's address (who I want to pay), and re-broadcast this new transaction to the network.
What is stopping this from happening?

Short answer: no, this is impossible.
Longer answer: some transactions allow changing the inputs used (ANYONECANPAY inputs). It is also possible to have inputs which do not sign the outputs being created (SIGHASH_NONE). However, a transaction where all inputs are of this type, are worthless, as anyone could change the outputs to credit themselves instead.
Typically, when normal SIGHaSH_ALL signatures are used, pretty much everything of a transaction is signed (which input coins are used (and in which order), what output scripts are created, what value to assign to them, ... Everything except the signatures themselves really (which is what causes involuntary malleability).
If an input signature is marked ANYONECANPAY, it does not sign the other input coins being used. This means you can create a transaction meaning "i want x and y to be paid, but i don't care who provides the funds to do so". If all signatures in a transactioon are ANYONECANPAY, you could add extra inputs (or remove existing inputs. Just increasing the input funds would just burn them as fee, though.
On the other side, there is SIGHASH_NONE, which makes a signature not sign the transaction's outputs. This may seem to allow what you want to, but in case every signature is SIGHASH_NONE, the treansaction is completely unsafe, as anyone could replace where the outputs go.
So, even if a combination of those would in theory allow what you suggest, it is not true for typical tramsactions, amd would in fact be completely unsafe.

Thanks. I have looked at the code for over an hour and I still don't see where the outputs are signed, though. I am specifically looking here: https://github.com/bitcoin/bitcoin/blob/master/src/rpcrawtransaction.cpp#L703 ... it seems only inputs are signed? Can you point to a line of code that makes it clear that transaction outputs are signed as well?

Also, I can "just believe you", but I don't see anything in the code that prevents the type of behavior I am asking about. Specifically, what is preventing someone from adding an input to an un-mined SIGHASH_ALL transaction? Saying "everything is signed" doesn't fully answer my question, I feel like I am missing something important. Are all inputs signed with every private key that is listed in the transaction? From what I can tell, each input is signed individually and the data of that signature is stored independently from the other input signatures.

Every input is contains a signature, using the key needed by the script of the output being spent by that input. However the data being signed is (a modified version of) the entire transaction. Adding an extra input to a transaction would invalidate any SIGHASH_ALL inputs to it, as the data being signed changes.

These things cannot change:
Usually* a bitcoin transaction includes a signature to confirm the following things:

Input
Output

An input or output specifies both an address and an amount. If either of these things change, then a new signature will be needed, which can only be created by someone who has the private key. Changing the input or the output will invalidate the signature. Only the owner of the private key can make such a change, being the only one who can create the new signature. Even then, this would create an entirely new transaction which could not be mistaken for the original.
The thing which can be changed prior to the transaction being included in the blockchain is the transaction id. Changing this can cause confusion for anyone who accepts unconfirmed transactions, but it cannot change the input or output - it is just a label. For people who only accept confirmed transactions, the transaction will already be in the blockchain, where nothing can be altered so there is no opportunity for confusion.
In conclusion:

Your transaction which hasn't been included in the blockchain yet is safe from having its input or output changed. Neither addresses nor amounts can be changed or added to.
Once your transaction is included in the blockchain** it is safe from having anything changed, so you can safely refer to it by its transaction id without any potential for confusion.

Extra info
I was aiming for a simple explanation so I have not included detail of transactions with multiple inputs with different private keys, but the same applies. No third party can make alterations other than the transaction id, which does not affect what bitcoin amount is transferred or where it is transferred from and to.
The explanation above applies to standard transactions. Producing a transaction to which these protections do not apply would require either specialist software or an in depth understanding. For further detail on transactions see the following:

Bitcoin Wiki page on transactions (technical detail on how the signing process works)
[Bitcoin Wiki page on CHECKSIG](https://en.bitcoin.it/wiki/OP_CHECKSIG (inner workings of a signature)

*While it is possible to deliberately create a transaction which does not specify inputs, or even one which does not specify outputs, I am assuming that the question concerns the usual process of creating a transaction from specified input(s) to specified output(s).
**By "included in the blockchain" I mean included with however many confirmations you consider sufficient for your purposes. If a transaction has only one confirmation then it is still possible that the block it has been included in will become orphaned later. With each additional confirmation the risk of this happening decreases considerably.

You can't, it would create a completely different transaction and the other would get invalidated as soon as one makes it to a miner and into a block.

I'm confused, are you saying this isn't possible, or are you saying that it is possible and it would simply make the first transaction invalid?

My bad, the second paragraph was confusing. I'm saying the second transaction will be invalid because of conflicting inputs.

I was under the impression that transaction malleability was possible due to there being no order of transactions enforced (before a block is mined with that transaction in it). Is it possible for the second larger transaction to be put in a block?

Once a transaction is in a block or even in a miner's memory pool, all conflicting transactions are invalid. There are no input duplicates ever in the blockchain. Transaction malleability creates two TXIDs that point to the same transaction, but only one can be valid and placed in a block. Accepting both as valid is where exchanges lose money.

My question specifically references transactions that are not mined yet. The question is whether or not it is possible to edit the raw transaction to add inputs and outputs before the transaction is mined because each input is signed individually. I am not asking about duplicate inputs, I'm asking whether or not it's possible to add inputs and outputs to a transaction that hasn't been mined yet, with the hopes of re-broadcasting it to pools to have it mined before the "host" transaction is mined. I can't find anything in the protocol that would technically stop this from happening.


text:
Creating Base58 public key & private key in Java?
How can I create a base58 private key and public key in Java? I'm pretty familiar with Java and I have the bitcoinj-minimal code, but it's not clear to me how I can generate a base58 key pair from the code.

com.google.bitcoin.core.ECKey key = new com.google.bitcoin.core.ECKey(); // keypair
byte[] pub = key.getPublicKey(); // byte array

String prv;
prv = key.getPrivateKeyEncoded(com.google.bitcoin.core.NetworkParameters.prodNet());


text:
How to use both CUDA GPUs?
I'm using rpcminer-cuda to have a play around mining some bitcoins.  I have 2 NVidia cards, and I understand this is not ideal for any profitable mining.  I would however like to have them both working at the same time.  Presently the output from rpcminer-cuda when it starts up is:
rpcminer-cuda.exe -url=myurl -user=myuser -password=password

Client will start 1 miner threads
2 CUDA GPU devices found
Setting CUDA device to first device found

How do I make it use both cards at the same time?  Do I need to tell it to start two threads or is there some other commandline switch I need to use?  I've tried adding -gpu=2 but it seems to be ignored.

The -gpu=X command line is telling it which of your CUDA devices it should use, not how many it should use. Like most things written by programmers, the index starts at zero.  If you have two video cards, run it once at the command line with -gpu=0 and then a second time again with -gpu=1.  Once you work out your ideal fine tuning on aggression, gpugrid and gputhreads (if you do at all), it's easiest if you make a batch file (unless you're using GUIMiner, in which case create a new CUDA miner for the second card, same extra flags on both other than gpu=0 or 1).
You can execute it twice without specifying the GPU and it will certainly run, but from the console output it appears it assigns both of them to the first device.

The simple solution is to copy and rename the command so you run 2 separate instances of the same command.  The other option is seeing if adding  -threads=2 ACTUALLY does let you use both cards.  I have had issues where the threads were CPU threads and not cards and times it ' just worked ' on the same system.  running the command twice had it run 2 instances one per card and seemingly random which card was first every once in a while.
I have a XP box for CUDA mining on dual ( not connected ) 8600 GT cards and used GUIMiner Script to find out what batch files were created for each ( as new CUDA miners for litecoin ).  With some tweaking, they can do BTC or LTC mining.  What little time I have used rpcminer ( and hair pulling ) it seemed to ' kinda work ' when I ran it twice to get both cards mining as separate cards.
As to the profitability of GPU mining... I still have a ' day job ' and am looking at investing in ASIC miners for BTC.


text:
Number of transactions and transaction history don't match in XenCoinQt
I am solo mining XenCoin using XenCoin QT v0.6.3.3-g069d718-beta.
The number of transactions shown on the overview tab is 9, yet there are 7 transactions listed in the transaction history.
Also, recently I my cgminer 3.7.2 reported that it had found a block. The number of transactions increased on the XenCoinQT overview tab, but the mining reward didn't get credited to my account.
Can anyone explain what's happening? Is someone stealing my coins?
Additionally, is it possible to track all the blocks that are mined by me (solo mining)?

You say it doesn't match some 'overview page', could you explain to us what website/service/program this is?

I have added images of the respective tabs from Xencoin wallet

You should probably rather direct this question at the developers of the XenCoin wallet or make them aware that you have posted here, if you haven't resolved this question by now. If you have resolved the question, please feel free to post a self-answer.


text:
Only 70Mh/s with good PC! AMD CPU not supported?
I have a AMD 8-Core-CPU with a NVIDA GTX 560 for Bitcoin-Mining but I only get 70Mh/s...
If I start CGMiner without GPU it detects nothing. Why cant I use my CPU to mine Bitcoins? Is that an error by the program? Which Software is the best to farm?
With best regards

CPU and Nvidia GPUs are too slow for mining.
You may be able to make a profit for a while still with AMD graphics cards, if you have cheap or free electricity. But soon Bitcoin ASICs will take over completely. Then the only way to mine that makes sense is to buy specialized Bitcoin hardware.

+1 dr haribo, For my example I bought an NVidia card 1GB DDR3 card from Nvidia and saw a perfomrance along the lines of 8 MHash/S. When I swapped this out for an ATI card that was maybe 10 more expensive but with the same specs, I saw that my speed jumped up to 13.2 MHash/S

Seems odd that the NVidia card wouldn't be detected, though. OpenCL can definitely use NVidia cards.

The GPU is detected. He's asking why the CPU isn't "detected" in cgminer. The answer is that CPU mining no longer makes sense and therefore cgminer removed support for it.


text:
Icarus Detect Failed
I have been running raspberry PI with 4 Erupter modules connected to Pi Hub for 5 days with no problems. Yesterday I checked the modules and the idle lights were on and there was no mining. I restarted my raspberry, and now I am getting this error:
 [2014-04-10 20:23:13] Icarus Detect: Test failed at /dev/ttyUSB0: get 00000000,
 should: 000187a2
 [2014-04-10 20:23:13] Icarus Detect: Test failed at /dev/ttyUSB1: get 00000000,
 should: 000187a2
 [2014-04-10 20:23:14] Icarus Detect: Test failed at /dev/ttyUSB3: get 00000000,
 should: 000187a2

I am running the following command:
sudo ./cgminer-3.1.1/cgminer --config /home/pi/cgminer.conf -S /dev/ttyUSB0 -S /dev/ttyUSB1 -S /dev/ttyUSB2 -S /dev/ttyUSB3

If I connect and run the modules one by one there are no issues. When there are 3-4 I get errors. Those errors change each time I run it, so sometimes its 1 failing other times 2 etc. Also, I am getting this error:
[2014-04-10 20:33:04] Most likely you have input the wrong URL, forgotten to ad
d a port, or have not set up workers

Again, there have not been any changes to the configuration (that I am aware of). Any suggestions as to what might be causing this/ how to fix it?
Update
cgminer.conf

"pools" : [
        {
                "url" : "http://api.bitcoin.cz:8332",
                "user" : "worker",
                "pass" : "pass"
        }
]
,
    "api-listen" : true,
    "api-port" : "4028",
    "expiry" : "120",
    "failover-only" : true,
    "log" : "5",
    "no-pool-disable" : true,
    "queue" : "2",
    "scan-time" : "60",
    "worktime" : true,
    "shares" : "0",
    "kernel-path" : "/usr/local/bin",
    "api-allow" : "0/0",
    "icarus-options" : "115200:1:1",
    "icarus-timing" : "3.0=100"
}

Erupters run from powered hub, and rpi is also running from wall charger.

This sounds like a power problem to your erupters most likely. Can you show me the config file or the options you are enabling? In particular, the -scan option.
Further, you might verify you have a powered USB hub and try using a powered USB port if available; it only takes a little power to run them, but a little power to stop them. I also power my rasp pi through a wall charger also, rather than powering it from the usb hub.
I have had much more success running BFGMiner with Erupters and Antminer U1 USB sticks with a Pi and usb hub to control (and using Minepeon on the rasp pi). The command to start BFGMiner and scan for erupters etc and create a log in case you do have problems is:
bfgminer –o [pool] –u [user] –p [password] –scan-serial erupter:all –icarus-options 115200:1:1 –icarus-timing 3.0=100 2>logfile.txt

I have updated the question. I am not sure what you mean by -scan option, is it the -S? I will be trying bfgminer shortly.

Yes, -S is also scan, I just used the long form notation so you might understand what the options are for and what they do.
You can type the commands that I stated above in BFGMiner, or their abbreviation. Furthermore, I don't think it's necessary to add any options after the --scan (-S), because I think the mining software will automatically set the values once it detects it from scanning. Simply running  "bfgminer –o [pool] –u [user] –p [password] –scan-serial erupter:all" works for me, but you can also replace "all" with the device (Icarus, most likely) name and scan directly for it.


text:
When running a mining pool how many (super)nodes should I connect to?
Is it beneficial to connect your *coind instance to multiple supernodes?  Or Should I connect to more than the 8 standard peers?  Does this potentially improve the amount that could be earned in transaction fees or make found blocks distributed to the network any faster?

If you can distribute your block faster to the network you can win the race to get your block banged out. If you can quickly reach network majority that ensures your block won't be orphaned.

The only downside to more connections is increased bandwidth usage and slightly more CPU usage. Here, it's estimated that 2000 transactions per second is 7.8 megabits/second (average residential connect speed) and Bitcoin operates at the most at 7 TPS currently so you're in the clear.
Why you should connect to more nodes.
The more nodes you are connected to the more up to date you will be on network status and vice-versa. If the network comes up with a new block, you will be one of the first few notified.
If your mining pool comes up with a block, you will want to push your block out to the network as fast and spread as possible. You want as many nodes to know about your new and valid block as possible. Of course a new block incurs a domino effect with nodes, one node that knows of your block will tell other nodes about it. You can reach all nodes faster if you notify many nodes.
Why do I need nodes to know about my block?
Mining is a competition, you are competing against a massive amount of other players who all are probably hashing faster than you. It's very likely that they will also find a block in the time you do, this happens often. But only 1 block can be accept, and block acceptance is based on network majority. If you mine a valid block at the exact same time as another miner, and you can get a good majority of nodes your block, you will get the reward. The other block turns into an orphaned block and the miner who mined it loses all profit.
It's suggested you connect to as many large node as possible, you don't have to necessarily connect to smaller nodes as large nodes will rebroadcast your block to many small nodes. You may see some increased bandwidth usage but it's negligible considering what kind of connections servers tend to have.
Concerning transactions fees
Connecting to more nodes will net you more transactions to put into blocks, but it really won't be much. The 10 minute block time Bitcoin has means your node will have ample time to put together enough transactions for profit.
8 peer connections is not a lot and may mean you aren't receiving any inbound traffic.