text:
Why is Ripple's base58 alphabet so weird?
In this answer I found out that Ripple uses a different base58 alphabet from Bitcoin. There aren't many materials on what that alphabet is, but I managed to find this reference:

The base58 dictionary for ripple is: rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz

I am wondering - why is Ripple's alphabet so bizarre in comparison to Bitcoin's base58 alphabet:

123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz

I understand that for some branding reasons one would want to put "r" as a letter for 0 and use 0 as network byte for Ripple (thus making every address start with "r"), but the same could've been accomplished by simply shifting the alphabet like so:

rstuvwxyz123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopq

What is the logic behind the odd alphabet letter order?

Interestingly, if you look at just the capital letters they are almost in ascending order, as are just the small letters.

I don't know about the rest of the string but I think the leading bytes are ordered that way to make the types of "addresses" be human reconizable.
From a quick look at the source I think the leading characters, rpshnaf map like so:

r = public Ripple address
p = node private
s = Ripple secret
h = ?
n = node public
a = address family generator or seed ?
f = address family generator or seed ?

Of these, wallet owners have seen the r* and s* "addresses" and those running ripple will be have seen the n* and p* ones.


text:
Can new types of transactions be included the current block chain?
I was putting an answer for this question together when I realised my idea would require a new type of transaction to be invented and included in blocks.
Then I wondered how that could work. There are many mining rigs out there which would have no way of validating my transaction type.
Even if some miners do recognise my transaction and even included it in a winning block, all the other miners would not accept that winning block and instead continue mining on the previous block.
What would happen if we wanted to devlop Bitcoin this way? Would we instead have to establish Bitcoin2 with a new block chain?

Miners will accept block with transactions they don't understand, so long as the transactions don't attempt to create Bitcoins out of thin air. They won't include transactions they can't validate in their own mined blocks though.
There is active effort at the top levels of the Bitcoin developers to get new transaction types into the client. M-of-N transactions (transactions that require a set of signatures), for example, are close to obtaining a consensus.

Has any consensus been made?  Who are those developers (so I can follow their responses in more detail)

Short answer:
Technically possible? Yes.  Likely? No.
It would be possible to modify the protocol to include other types of transactions -- such things have been proposed for a wide variety of issues, including being able to lockdown stolen coins, timestamp messages, etc.
It is highly unlikely they will ever make it in, at least not anytime soon, because changing the blockchain is a Big Deal and we are already dealing with "block chain bloat" and many of them have other possible solutions that don't involve modifying the block chain.
Your particular suggestion (in the other thread) seems incredibly unlikely to ever make it as part of the protocol since there is just no need for it to be. Trading exchanges can easily implement futures, options, and all sorts of derivatives if they want - no changes to blockchain necessary.

Granted, but what if there was something important that we haven't thought of yet. Could it happen with the current block chain or would we need to start again?

Sure, you would just have to have quite a bit of planning, and get the mining pools to agree to it. For most things it seems like a third-party service or something at the client level would be best, somethings would prob be pushed to a bitcoin fork, but there is no inherent reason why changes couldn't be made to the data the bitcoin block chain stores given enough consensus and lead time

The key issue here is opcodes. If your transaction does not require any new script opcodes, you should be able to create these and have them make it into the block chain without any trouble (they won't get relayed because they won't pass the isStandard check, Eligius mining pool, for one, will relay non-standard transactions. Any miner will /accept/ them into their block, they just won't relay them which makes it harder for your transaction to propagate.
But the key is, if you don't need any new opcodes, this does not require any changes to the core bitcoin in order to work.

Actually if you jump into Bitcoin as being an implementation of Blockchain, and new transactions leading to a Blockchain 2 is possible which is actually known as a fork (can be soft or hard fork).
The case which you are telling about is Soft fork as in case of Bitcoin network, which literally creates a new branch of transactions on a running chain and the point from where the new branch emerges accept the new kind of transactions being made. But they cannot bypass the basic fact of creating bitcoin out of thin air.
When a hardfork occurs, it renders the new transaction being seen as useless and Infact can be taken as a new coin/blockchain/alternate coin.

A soft fork does not make two chains, it's by definition a backwards compatible change.

Very true but I have mentioned of Soft fork behaving as a connected branch rather than non backward compatible branch.

source: Stack Exchange

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

sort: votes


text:
Public key from private key generation problem
I met some problems, when I was trying to write function able to create Bitcoin public key from private key. I was using the tutorial: http://procbits.com/2013/08/27/generating-a-bitcoin-address-with-javascript ---> "Public key" part is most important.
Part of my code looks like this:
public String generatePublicKey(String privateKey)
{
    BigInteger privKey = new BigInteger(privateKey,16);
    X9ECParameters ecp = SECNamedCurves.getByName("secp256k1");
    ECPoint curvePt = ecp.getG().multiply(privKey);
    BigInteger x = curvePt.getXCoord().toBigInteger();
    BigInteger y = curvePt.getYCoord().toBigInteger();
    byte[] xBytes = this.removeSignByte(x.toByteArray());
    byte[] yBytes = this.removeSignByte(y.toByteArray());
    byte[] pubKeyBytes = new byte[65];
    pubKeyBytes[0] = new Byte("04");
    System.arraycopy(xBytes,0, pubKeyBytes, 1, xBytes.length);
    System.arraycopy(yBytes, 0, pubKeyBytes, 33, yBytes.length);
    return this.bytesToHex(pubKeyBytes);}

There are also two functions:
final protected static char[] hexArray = "0123456789ABCDEF".toCharArray();
public String bytesToHex(byte[] bytes) {
    char[] hexChars = new char[bytes.length * 2];
    int v;
    for ( int j = 0; j < bytes.length; j++ ) {
        v = bytes[j] & 0xFF;
        hexChars[j * 2] = hexArray[v >>> 4];
        hexChars[j * 2 + 1] = hexArray[v & 0x0F];
    }
    return new String(hexChars);
}

private byte[] removeSignByte(byte[] arr)
{
    if(arr.length==33)
    {
        byte[] newArr = new byte[32];
        System.arraycopy(arr, 1, newArr, 0, newArr.length);
        return newArr;
    }
    return arr;
}

However I used bytesToHex() earlier and there weren't any problems. So the thing is that generatePublicKey() does not work properly. I tried to insert private key known from bitcoin wiki:
18E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725
(from https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses)
It should create long public key (even before all hashing) - step 2 on wiki:
0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6
Unfortunately the answer is wrong. Could you Guys look at this and point my mistakes?
Ofc, programming language is Java and cryptographic provider was Bouncy Castle.
EDIT:
I accidentally solved my problem. When I was writing this function, Eclipse told me function getX() (and getY()) is depracated. So I used getXCoord(), because I thought its result is the same. In feeling hopeless I used getX() instead getXCoord() and whole function magically worked!
What's the difference between getX() and getXCoord() ?

Did you take a look at how bitcoinj does this?

For the difference between getX() and getXCoord(), you could look at the source.  The difference seems to be "normalization", whatever that may be.

You should really say in the first few sentences of your question what language you are writing your code in, and what libraries you are using to do the ECDSA.

I accidentally solved my problem. When I was writing this function, Eclipse told me function getX() (and getY()) is depracated. So I used getXCoord(), because I thought its result is the same. In feeling hopeless I used getX() instead getXCoord() and whole function magically worked!
What's the difference between getX() and getXCoord() ?

The last question would likely get a good answer at stackoverflow.

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


text:
What's the formula giving the % of succesfully maliciously messing the blockchain?
With the recent (early 2014) GHash.io concerns about that particular mining pool getting too big, many people have talk about what a powerful miner could do if it wanted to "harm" bitcoin or double-spend, etc.
At one point someone pointed on that if you have 40% of the mining power, you have a 50% chance of reverting 6 blocks.
I'd have expected it to be (0.4 exp 7) (6 blocks + the next one) or something like that and not 50%.
What is the formula to use to compute the "harm" that a malicious miner could do and how many blocks he could revert?
EDIT
Here's a page containing the formula:
https://people.xiph.org/~greg/attack_success.html
Don't put too many blocks otherwise the code will have a numeric overflow.
But normally it's using the formula in the bitcoin paper and that page has been written by the person who came up with the concept of deterministic wallets (if I'm not mistaken). So I tend to think he knows what he's talking about.

Whoever said 50% chance at 40% hash power is wrong, each block makes it exponentially harder. The chance to mine 6 blocks consecutively with 40% is - .4^6, or ~0.004% chance.

@jtorba: Your math doesn't make sense. By that logic, a 51% miner has a .51^6 = 0.0176 chance.

@GregHewgill: I think technically it's "50% + 1 miner", not "51%"  : )    But, yup, that's basically my question: I had the same intuition as jtorba and people told me it was all wrong: I'd like to understand how it works.

The formula is directly from the original paper by Satoshi Nakamoto. Check pages 6-8. The paper has C code to easily compute the values, and that page you linked to is just that C code converted to javascript.


text:
Effect of byte length of r and s on DER encoded signature
As described in this answer to What is the maximum size of a DER encoded ECDSA signature? the DER encoded signature for a given ECDSA signature (r, s) has format:
0x30 = 1 byte constructed sequence type
L = 1 byte length of the following bytes (excluding SIGHASH byte)
0x02 = 1 byte primitive integer type
LR = 1 byte length of integer r
R = integer r in big endian
0x02 = 1 byte primitive integer type
LS = 1 byte length of integer s
S = integer s in big endian
SIGHASH = 1 byte

where r is prepended with a byte 0x00 in the case where it has a highest bit of 1, and likewise with s.
However how is the case where r has a byte length less than 32 handled?
Suppose for example we had :
r = 0x83e1ed5c6298a2dfb3e98f2d8963575487c888ac02483045022100ec6ab2

which is 30 bytes.
Do we
(1) prepend this with 0x00 because of the highest bit (ie. bit 239) being 1, so we put :
0x0083e1ed5c6298a2dfb3e98f2d8963575487c888ac02483045022100ec6ab2

in the R field above, or :
(2) write it in full 32 byte format :
0x000083e1ed5c6298a2dfb3e98f2d8963575487c888ac02483045022100ec6ab2

and therefore do not prepend it with 0x00 because the highest bit (ie. bit 255) is zero, so we put :
0x000083e1ed5c6298a2dfb3e98f2d8963575487c888ac02483045022100ec6ab2

in the R field above?
Can anyone point to any example blockchain transactions illustrating how these shorter r, s values are handled?
Is there any possibility of malleability here, ie. both options (1) and (2) are accepted by Bitcoin Core, assuming (r, s) is a valid signature?
Or are leading zero bytes always stripped away from r and s before considering whether their highest bit is 1 (noting zero is not a permissible value for r or s)?

One example on the blockchain with s at 28 bytes long is TxId = 3419cbc51cec42d4f55d4147d0c1cef54fbdabddf4384270e6e93970b2496f74, also described here.

The r and s values are prepended with 0x00 if their highest bit is 1 even when they are shorter than 32 bytes. For example, if the r-value is just 80, it will be serialized as 0080. Additional padding zeros are not allowed, so for example 000080 would not be valid.
You can find all the rules strict for DER encoding in BIP66, or in the implementation in Bitcoin Core. There's also an online DER signature decoder/encoder that I've created which you can use to test if a signature is valid.

Great tool, many thanks. So would Bitcoin Core reject the option (2) above which has the extra zeros and would thus consider such signature as invalid even though the integer values (r, s) are correct? Could you provide a link to the Bitcoin Core source code where DER signatures are created and validated?

Yes, as I said additional padding zeros are not allowed. I've added links to BIP66 and the implementation in Bitcoin Core.

Great help, thanks.

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


text:
Input and Output of all funds in the same block?
Hope, someone can clarify this problem to me.
Please have a look at the btc address: 1CRTSXJXa3LsaHwjTA5yTbqbyi6QituztX
There have been 2 transactions so far. 1 input and 1 output.
BUT: According to the blocktime and height, these transactions happend at the same time. How is this possible, as I can't transfer funds, that I haven't received in advance?

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


text:
building a multisig transaction using RPC
I´m trying to build a multisig transaction using RPC. Till now my code looks similar to this:
At first I get the unspend outputs calling listunspend()
With those UTXOs I´ll try to create the rawtransaction:
createrawtransaction
'[
{"txid":"03a4ffcc792525b4ddaecc05054114f2ad8aff8b7563cd41cdb496e2177d0117","vout":0},
{"txid":"03a4ffcc792525b4ddaecc05054114f2ad8aff8b7563cd41cdb496e2177d0116","vout":0}
]'
'{"mwCwTceJvYV27KXBc3NJZys6CjsgsoeHmf":0.05}'

The result of this call I use for signing:
signrawtransaction
020000000117017d17e296b4cd41cd63758bff8aadf214410505ccaeddb4252579ccffa4030000000000ffffffff0100b4c404000000001976a914ac19d3fd17710e6b9a331022fe92c693fdf6659588ac00000000
'[
    {"txid":"03a4ffcc792525b4ddaecc05054114f2ad8aff8b7563cd41cdb496e2177d0117","vout":0,"scriptPubKey":"a91421ce1507d06ed2742be0bf18a018bbcdd812a26487","redeemScript":"00149835f2e0dff9d7f6a4060140696bc7e00b12edd5"},
    {"txid":"13a4ffcc792525b4ddaecc05054114f2ad8aff8b7563cd41cdb496e2177d0116","vout":0,"scriptPubKey":"b91421ce1507d06ed2742be0bf18a018bbcdd812a26486","redeemScript":"10149835f2e0dff9d7f6a4060140696bc7e00b12edd6"}
]'
'["cMahea7zqjxryy6NWaKxmhDyb1JzuNKCZAg8sxaJoXSBkRXjnib9"]'

At this point I get the error Missing amount and I can´t figure out why.
I´m not sure which values to use for the signrawtransaction() call. Should I use the same txid and vout values as for the createrawtransaction? Where do I get the correct scriptPubKey and redeemScript values from?
Note: the provided txid´s and addresses are only samples (maybe not valid) and not the ones I´m using for my code.
UPDATE:
Latest unsigned raw transaction in BTC live net:
020000000195b96fa7fff141564feba34cb669bdeb94953c98ae864465623def3fbe9e9fb10100000000ffffffff01e87a0100000000001976a914d05bddfbc9059d06168b7bf08bd20d5f1fdaf79588ac00000000

if you are on testnet/regtest, it is completely ok, to provide "correct" data (no need for masquerading). There is the famous 2-of-3 multisig from Gavin, which provides a step by step approach using RPC. This should give you the idea behind.
Generally you are correct, you would search for listunspents, take one of the transaction numbers, and see in the transaction, which unspent output you can use (usually it is a 0 or 1 for the first or second). And for sure this transaction should have some amount, that you can spend. Use "decoderawtransaction" to see the details of the tx. When you have created the tx with "createrawtransaction", then it returns a string of data, that can be used as parameter to the "sign" call.

Thanks for the link, I´ll go through it. decoding my rawtransaction it should have an amount, but this amount (why ever) seems not to be available while performing the signrawtransaction process. And my question would still be Where do I get the correct scriptPubKey and redeemScript values from? to correctly perform the signing step?

After reading parts of the linked source it gets a bit clearer how multisig addresses seem to work. So the redeemScript seems to be the one of the initial multisigaddress. you know if there is any way to recover this data while only haveing access to 2 of the 3 private keys?

Basically you have three steps: 1) create redeemscript and address, 2) fund this address; 3) spend from this address. The redeemscript is created out of three public keys. The "createmultisig" call would be provided with the parameters, and returns a hash of it (which is the new multi-sig address). And this hash is not reversible. So if you created such a multisig address, and lost the corresponding keys, you cannot easily re-create it. With highly sophisticated knowledge and effort, you could go through all the keys of involved wallet(s), and create appropriate combinations manually...

after reading the guide I still get an error while trying to sign the rawtransaction. The decoded rawtransacion looks fine but while I try to sign it I get "Missing amount" even if in the decoded raw transaction the correct amount is displayed. For my approach I use the folling parameter: signrawtransaction([hex_from_createrawtransaction], [inputs_used_for_createrawtransaction(txid, vout, scriptPubKey, redeemScript)],[one_privateKey]). Anything wrong or missing?

I try to follow each step: I looked up the tx, that you want to spend from - the second line in the signrawtransaction example above. This tx ID cannot be found on testnet. Same for the tx ending with "116" in createtransaction (testnet.blockchain.info). Only the tx ending with "117" has funds on it. The numbers in the (second) lines seem to be "to close", they are just incremented by 1 at specific positions - it might be correct, but I haven't seen this before. Can you try to go with a single input and output, using only the tx ending with "117"?

(Well, more precisely transactions don’t have funds... but the tx shown by blockchain.conf has funds associated with the addresses shown)

Thanks for the help. As told in the OP the txids (...) only have been samples from a tutorial I started with. I´ve updated the OP with a unsigned raw transaction from the live net. Aufter the first signing step it tells me "Operation not valid with the current stack size" which seems to be okay for a multisig tx, the second signing tells me "Signature must be zero for failed CHECK(MULTI)SIG operation" (no matter which of the 3 private keys i use for the first or second signing step)


text:
How Is Block Assembled?
I think I understand mining well enough, but what I don't get is how the blocks of transactions are assembled. According to this post - What exactly is Mining? - the miners assemble the blocks and then solve for the difficulty.
So, once a block is solved and the miners need to create a new block, how do the miners decide how many transactions to put in the block? Could the miner just assemble a block with a single transaction? Could certain blocks contain more or less transactions than another? Thanks!

Technically a block with just one transaction in it would be valid. However miners have an incentive to add more transactions to the block they are currently mining because they receive the transaction fees attached to those transactions.

another question... could miners ignore transactions that didn't pay fees?

Yes; and they are actively doing that as well. Giving priority to higher fees and omitting none/lower fees.

could miners ignore transactions that didn't pay fees?

yes. bitcoin is voluntary system. each miner has a right to include or skip any transaction.
(not asked questions)

why do miners include free transactions?

Why not? The system is for people, not people for system.

do miners include all free transactions?

No! There are some recommended rules
https://en.bitcoin.it/wiki/Transaction_Fee


text:
How to receive newly broadcasted transactions immediately with bitcoin-core RPC?
With getrawmempool it gets me txids, however it just dumps the whole mempool on me. This isn't convenient if I want to quickly detect new transactions. Is it possible to only get newly broadcasted transactions?
Is there another way to sort of stream them from bitcoin-core into my program?

You can use the ZMQ interface to receive a ZMQ notification when a new transaction is received. You can have it give you the txid, the raw transaction, or both.

I think what you are looking for is walletnotify. You can set on bitcoin.conf file.
For example

walletnotify=/home/process_tx.sh

That will call /home/process_tx.sh passing as parameter the transaction hash
Or you can also run bitcoind with using -walletnotify

bitcoind -walletnotify=/home/process_tx.sh

As far as I understand, walletnotify only notifies of transactions made to the address that belong to that wallet. I'm interested in collecting all transactions that are broadcasted.

In that case, you should use ZMQ as sugest by @Andrew Chow


text:
Lightweight command-line client?
I need to be able to generate addresses and receive bitcoins to them, then send them somewhere else - and do it on a server via some command-line interface. Is it possible to do so without downloading the whole blockchain, as bitcoind requires? That is, is there a lightweight client, but for the command line?

I think your real question is that you want to write a program that can detect when it receives bitcoins. Am I correct?

Electrum has a text-only version, although I found I had to set it up first time using the gui. Here's my write-up on running it on a Raspberry Pi via SSH though, which sounds like it might do what you need:
http://bitcoinlife.wordpress.com/2013/05/29/running-electrum-on-a-raspberry-pi/


text:
Bitstamp streamline API: how to get all contents of the ordebooks?
I've been trying to work with Bitstamp streamline API, which uses Pusher.
So I managed to connect to some channels, specifically to 'orderbook' and it even returned me 6 items. However it looks like some kind of limit. Does anybody know how do I get the full contents of the orderbook (that is, all orders) throught this streamline API? (I know you can do it via regular REST api, but due to some limitation, I really have to use Websockets and Pusher in this case).

I haven't yet used Bitstamp's streaming API but I think it's fairly safe to assume that you will only get real-time changes via those pusher channels. That means you need to make at least one initial call to their official REST API to get the full orderbook, and then keep it updated by applying the changes that you receive from the streaming API.
If you are really stuck with websockets only (care to explain why?), you may need to build your own proxy middleware that can make that initial REST call and feed your client with the full orderbook via websockets.
Either way, be extra careful about relying on an unofficial and unsupported API which Bitstamp can change at any moment without prior warning.


text:
Bitcoind becomes non-responsive over JSON-RPC, have to manually restart all the time
I run bitcoind on AWS on Ubuntu. The machine has 4Gb of memory and free shows some of it remains free. Enough disk space too.
Yet, I have to manually restart bitcoind quite often, because sending JSON-RPC requests returns a timeout error. That is, at first they do work, but then they don't. No matter what kind of request.
Has anyone ever come across this? Why does it happen? Does anybody have a plausible theory?

What version of bitcoind are you running? Also, is the blockchain caught up? (You can tell what block you're on by running bitcoind getinfo or bitcoin-cli getinfo respectively)

Does increasing rpcthreads cause the problem to stop?

Some HTTP client software does not deal with the persistent connection feature that bitcoind offer. Persistant connections are off by default in 0.10 again, but can be re-enabled with -rpckeepalive.

Upgrade to the very latest stable version. We saw alot less memory leakage with .10 on ubuntu
run a cron job to restart it every night around 4:00 am est when there are fewest ransactions. This will cut down on memory leakage
make sure your box has at least 4 gigs of ram and a 2 gig swap partition.
give us some more info here. like linux distro, machine stats and what kind of rpc calls u often do.

I have observed that if the HTTP client sending the JSON-RPC request does not send a Connection: close header then the bitcoind RPC server stops responding after a number of calls.

Indeed, there seem to be some problems with certain clients and persistent connections. 0.10 disables persistent connections by default.

authors: Ольга Великая


text:
Claiming Bitcoin Cash - where did I go wrong?
I read multiple guides on how to 'claim' the BitcoinCash I'm apparently entitled to as a BTC holder.  I outline below the steps I took; but at the end of this process my Electron Cash default_wallet shows a 0 mBCC balance.  Please suggest where I might have gone wrong and what I can do about it:

In Bitcoin-Qt, generate a new receiving address
Send all my coins to the new receiving address

I started with 1.13BTC.  Now my Bitcoin-Qt wallet shows a balance of 1.129BTC and under 'recent transactions' it shows the Fee for the transaction.  The 'type' is 'Payment to yourself' and the Amount is -0.0023BTC

From the Transactions tab, I open the Details for this transaction.  It says 'Total debit -1.129BTC, Total credit 1.129BTC, Transaction ID 32...(64-digit hex string)'
At https://blockchain.info I entered the Transaction ID and see all the details.  I can see 4 Addresses on the Left and 1 Address on the Right (1JC...)
In Bitcoin-qt I go to Debug > Console and run dumpprivkey 1JC... with the full address.  It outputs a private key (50 characters, alpha-numeric)
I download and run Electron Cash 2.9.2, create a new default_wallet and 'Import Private Keys' pasting the 50-character private kay from the Bitcoin-Qt Debug output

Electron Cash shows the Public Address (1JC...) in the Addresses tab, with Balance 0, Tx 0
Bitcoin.info says the following about the transaction:
Inputs and Outputs
Total Input
1.13157047 BTC
Total Output
1.12926194 BTC
Fees
0.00230853 BTC

You had the 1.129 BTC in the wallet before August 1st? You can verify on blockdozer.com if the address has funds which are unspent (UXTO). Then you should see them in your BCC wallet as well.

In addition maybe this helps:
https://bitcoin.stackexchange.com/questions/57607/why-did-my-bcc-disappear-from-my-electron-cash-wallet

yes, I've had the BTC for over a year.  Blockdozer returns There are no transactions involving this address. for my 1JC... address - which is odd?

changing the Electron Cash server hasn't made a difference

so do you see the funds in the address  on blockchain.info from before Aug 1st?

yes, updated the question with this info

I would suggest you check the funds of your addresses based on the private key entered on the bip39 page in this description: https://bitcoin.stackexchange.com/questions/57422/how-to-sweep-private-extended-key-from-mycellium-into-coinomi-for-bitcoin-cash-c/57971#57971. This also provides an alternative way to sweep your funds. BTW: if the BTC chain shows different info from the BCC one - what is the date of the related transactions which have latest UXTO. This info is missing.

send my private key info to the website of this guy on github?  Um. No.

Sure about your concern. That's why you should transfer your BTC before. If you like you can download the bip page. Still the date info is missing as per above to understand the difference between BTC and BCC chain.

The problem was in this step:

run dumpprivkey 1JC...

What I should have done was to run dumpprivkey on the

4 Addresses on the Left

In the Blockchain.info output - instead of the receiving address.
After doing this, and importing the private keys into Electron Cash, I now have my BCH balance available.

You may have gone wrong by exporting the private key of your /new/ wallet. You want to export the private key of the /old/ wallet and import that into Electron Cash. It isn't clear from your description if you got this right, and that would be one explanation.

I think it's clear from the description of my steps that I ran dumpprivkey on the old wallet

Dan was correct, you dumped the destination key rather than the old keys.  You should move funds to a new address to be safe as that 1JC... private key has now been copied around.


text:
Bitcoin difficulty re targeting in case of catastrophic hashrate drop?
I do understand that the mining difficulty changes every 2016 blocks :
next_difficulty = (previous_difficulty * 2016 * 10 minutes) / (time to mine last 2016 blocks)
But how is difficulty changes if suddenly 90% of hash rate disappears* ?
I would be very grateful if someone could kindly point me to the class in sources.
*recent BCH fork had difficulty adjusted quicker than 2016 blocks.
P.S.
Should I be looking at
unsigned int CalculateNextWorkRequired(const CBlockIndex* pindexLast, int64_t nFirstBlockTime, const Consensus::Params& params)

in pow.cpp ?

But how is difficulty changes if suddenly 90% of hash rate disappears* ?

It will change as it normally does, after 2016 blocks. There is no provision for adjusting the difficulty if the hashrate suddenly drops.

*recent BCH fork had difficulty adjusted quicker than 2016 blocks.

As part of their hard fork, they added a provision for cases where blocks are taking too long (i.e. sudden hashrate drop). This extra difficulty changing rule is not present in Bitcoin.


text:
Is this an ok "poor man's 2 out of 3" key solution?
In the situation that you want no individual to have the complete private key, but you do want  to share the complete key between 3 individuals, of which any 2 can construct the complete key, what is the downside from doing something like this:
Orig key = 1 2 3 4 5 6 7 8 9 (abbreviated for demo)
key 1 = 1 2 _ 4 5 _ 7 8 _
key 2 = 1 _ 3 4 _ 6 7 _ 9
key 3 = _ 2 3 _ 5 6 _ 8 9
obviously any 2 keys would construct the entire key again.
Apart from the decrease of key strength to 1/3 of the original, are there any other potential issues ?
This would be used for "short term" escrow accounts where, in the case of a "winner takes all", the escrow would just communicate their key to whichever counterpart won. If the escrow failed to send, then the counterparties could choose another (trusted) escrow and transfer the funds to them.

There are two problems with your approach. The second one's more difficult to solve than the other.
Problem 1
While it would take me a 100 million years to brute force the key 1 2 3 4 5 6 7 8 9, if I know two thirds of the key, it doesn't take just 1/3 the time, but a cube root of the time, meaning that I might actually be able to guess it.
Giving everyone a part of the key without making bruteforce faster

Instead, you generate 3 totally random strings of bytes as long as the key. We'll call these R1, R2, and R3.
We'll call the private key K, and the clients, C1, C2, and C3.
To C1, you give R1, and R2 ^ K. (^ is shorthand for XOR)
To C2: R2, R3 ^ K
To C3: R3, R1 ^ K

Example: If C1 and C2 put their heads together, they could combine R2 and R2 ^ K. This is important, because R2 ^ R2 ^ K = K
Space requirement: Given that n = number of people, and m = maximum number of people  abstain, you need n!/m!/(n-m)! ciphertexts. Okay for 3 people, starts to get unwieldy for 10.
Problem 2
When generating the key in the first place, somebody needs to know the full private key before they split it up. In other words, you need a trusted third party. To get around this, you need to do something called Distributed Key Generation. I'm not sure if this can be done for ECDSA. This paper looks encouraging based on the abstract, but I can't see the whole article.
Multi-signature transactions
This is a much more scalable and secure system. Unfortunately, it's not really ready for real-world use yet.

Thanks for going into the detail and providing an alternative better method. I'm waiting for multisig but wouldn't mind having something in the intertim and get the rest of the stuff around it done and then just replace with multisig when it hits prime time.

Your proposed solution would now work without a third party knowing the complete key. It is impossible to derive a valid public key from three partial private keys in the way you described.
On the other hand, it is possible to create n-out-of-n multisig addresses using split-key vanity addresses. However, this can have an issue with coins getting lost and one party being malicious and stealing all the coins once they get their hands on all N keys.

You should follow Gopoi's advice and use multisig. There are a few problems with your system. The first problem is how two people share their password. One of them could lie and get the whole password. Even if they share the right values, they need to agree to send a transaction which divides the funds. The user sending the transaction could cheat and send it all to his/her account.
Also, notice the security is much worse. I'm not sure what you mean by 1/3 of the security. If you refer to bits/digits this is right, but this is much less security. In your example, instead of trying all values from 0 to 999999999, any of the participants can guess the password with only 1000 attempts (they just need to fill three gaps). In Bitcoin, instead of a key with around 256 bits, you get about 86 bits of security. This seems decent enough for short times, but is much less secure.
With multisig the users will only sign a transaction they agree with. They know what they get, the key is as strong as in any other transaction and it is easier to scale to more than three users.

The way you address this you should use the script CHECKMULTISIGVERIFY with 3 different key provide within one transaction each party having his own key.
See here for an example that resemble with what you were asking.


text:
Any reason not to buy bitcoins using a bank card?
If I'm new to bitcoin and I want to buy coins at an exchange like mtgox solely for the purpose of seeing currency value increase and selling at a profit, is there any good for reason for me to not simply buy bitcoins by entering my visa number on mtgox in the same way I buy anything else online? As opposed to say meeting someone in person and giving them cash in exchange for bitcoins?

It's unclear what you are asking. I strongly doubt Mt. Gox accepts CC funding, so you can't do that because they don't allow you to.

That is done to prevent fraud (in other words, people could "pay" with CC, get their bitcoins, and then dispute the transaction).

Well, an obvious reason would be if you were concerned about anonymity and not leaving an audit trail, in order to conceal your funds from tax authorities, for example.


text:
What does Bitpay's {"error": "Invalid token"} mean?
I'm creating a web app that uses Bitpay for payments. I'm writing it in ruby (but that shouldn't matter), and have a class method bitpay_client with the body BitPay::Client.new('mYs3cretAPIkey').
Anytime I do BitcoinInvoice.bitpay_client.get("invoice/#{invoice_id}") I get the JSON {"error": "Invalid token"} back from the server. In Bitpay's documentation there's no mention of this message. I'm using the right api key, and I'm sure this is a real invoice. What does this message mean?

The error was my client connected to the wrong endpoint. This feature was undocumented at the time, but is now clearly documented. Kudos to Bitpay!

This isn't quite fair. First, Bitpay support was available to you for help. Second, the old API did still work if you used the right endpoint, and that was not something hardcoded into the library. Third, both the version 1 and 2 libraries are available on RubyGems. https://rubygems.org/gems/bitpay-client/

You're right, that was unfair. I beg your apologies and  made an updated answer. Thanks for providing a great service!


text:
What happens to a transaction once generated?
I'm trying to understand how bitcoin works technically. I understand the blockchain, digital signatures etc ... I'm more interested in what happens to a transaction once it's "created".
Suppose Bitcoin only contains one transaction per block (to simplify). Basically:

someone create a transaction using its wallet
this transaction must be validated (check inputs, digital signature etc ...
a proof of work must be computed on the block hash
the the block is added to the blockchain

So I know miners are responsible to come with the proof of work. My questions are:

how does one node broadcast a transaction to miners ? Is it part of the P2P protocol ?
does miner check the transaction (digital signature, available inputs etc ...) ?
does miner directly submit blocks to the blockchain ?

This part is still confusing to me any help pointers to article would be great :)
Update:
In a P2P network, nodes are not connected to every other nodes. So let's say the network looks like this:
node1 <-> node2 <-> node3 (1 and 2 are directly connected and 2 and 3 are directly connected. 1 and 3 are connected through 2)
When node1 wants to broadcast a transaction for validation, it will only broadcast it to node2. Then node2 can eventually broadcast it to node3 to give him the chance to validate node1's transaction.
But, because we are in an untrusted network, nothing prevent node2 to validate the transaction without never transmitting it to node3 and thus, keeping mining fees for himself.
We could also imagine that node1 never broadcast it's unconfirmed transaction, do the mining work himself and only broadcast the validated block so it get "merged" into the blockchain.
How does Bitcoin deal with this situation ?

Regarding your update:
It's true that when a node receives a transaction, there is nothing forcing them to relay it.  They can just sit on it if they want.
But the network won't look like the picture you drew.  If Node1 actually wants his transaction to be confirmed, he wants to distribute it to as many other nodes as possible.  In particular, if Node2 is the only miner that knows about the transaction, then it can't be confirmed until Node2 successfully mines a block.  Assuming that Node2 only controls some fraction of the network's total mining power, this may take a (very) long time.  Node1 would prefer for his transaction to be included in the next block to be miner, no matter who mines it.
So for that reason, Node1 won't send the transaction only to Node2, but to many different nodes.  Bitcoin Core, for instance, will by default try to connect to at least 8 different nodes. If at least a few of those nodes are honest, they will relay the transaction to many more nodes, and so on. This also means that Node2 has less incentive to be greedy; it only helps to be greedy if no other miners know about the transaction (or very few), and Node2 knows this is not likely to be the case.  On the other hand, if Node2 is a miner, then she has a slight incentive not to be greedy: having invested in Bitcoin mining equipment, Node2 has an interest in having Bitcoin keep a high value, which will only happen if people continue to use it, and having their transactions confirmed fast would tend to encourage that.  So at some point, the incentives fall on the side of not being greedy.
(Keep in mind, too, that not all nodes are miners.  Many nodes on the Bitcoin network are run by people who don't do any mining, and just run a full node for fun, or to support the network altruistically, or because they installed Bitcoin Core with default settings and don't really know or care what it's actually doing.)
As for your second scenario, if Node1 is a miner himself, he can certainly keep its own transactions to include in his own blocks, rather than transmitting them on the network.  This also means that he won't have to pay fees for that transaction (or, equivalently, that he pays the fees back to himself).  There are two tradeoffs: (1) as mentioned above, the transaction will take longer to be confirmed; (2) if there is a high volume of transactions on the network, enough to keep all blocks filled, then by including his own transaction in his block, Node2 is giving up the ability to include someone else's transaction which would pay him a fee.  So it's up to Node1 to decide what is best for him. But this has no impact on anyone else, so it isn't really a problem for the network either way.

Great thank you for your explanation that's great and make things clear for me :)

Regarding your final sentence, won't it be possible for the miner to fill up the blockchain with their own nonsense transactions? Sure they miss fees but they don't have to share their made-up transactions and risk wasting computing time.

@jiggunjer: A miner can put any valid transactions they want into their own blocks, and sure, they could fill their blocks with their own transactions.  I can't see how this would benefit them.  I don't understand what you mean about wasting computing time; can you explain what you have in mind?

The way I see it completing a block doesn't mean it gets into the blockchain if another block includes a transaction it used. By just mining your own you can 1) avoid long waiting times for a low fee transaction. 2) Your blocks won't ever be rejected by the blockchain.

Oh, I see what you're saying.  But that's not a real concern.  Blocks are strictly ordered in the blockchain since each contains the hash of the previous block. So when you go to mine a block, you know exactly what blocks, and hence what transactions, are in the chain up to that point, and you can avoid with certainty including any transactions that are already there.  If another block, later in the chain, tries to include a transaction already in your block, they get rejected, not you.

It could be that two blocks mined simultaneously (both with the same block as their previous) contain the same transaction.  But in such a case, only one block can become part of the chain, simply because of the strict ordering requirement, and this would be true even if they didn't contain any of the same transactions.  So avoiding other people's transactions doesn't give any benefit here.

how does one node broadcast a transaction to miners ? Is it part of the P2P protocol ?

yes, the P2P protocol has for one of its role to ensure the transmission of new transactions and blocks amongst the participant in it.

does miner check the transaction (digital signature, available inputs etc ...) ?

yes, should a miner mine an invalid transaction, the block itself would be invalid and all the work expanded by the miner would have been useless and costly.

does miner directly submit blocks to the blockchain ?

miners submit blocks to their P2P protocol peers (but nowadays, specialized networks such as FIBRE exist between miners to speed it up). Once a node receives a valid new block from a peer, it is stored locally on disk and extends the existing blockchain, it is also forwarded to peers that didn't receive it yet.

Thx for your answer :) I updated my question with more details


text:
Algorithmic efficiency for transaction lookup in blockchain
Since bitcoin uses binary Merkle trees (just learned that), I want to know what would be the algorithmic efficiency for transaction lookup in the blockchain.
I don't know exactly how the data structure underneath the blockchain is organized.
AFAIK, each block contain a single Merkle tree, which can be related to the previous block tree by the prevId field in its own block header.
Given all that, I was wondering if, given a TXID, I would be able to locate that transaction in the blockchain in logarithmic time (O(log2 n)) as just a simple tree traversing, or if there are some hidden details I'm not considering.

Just to clarify: Are we talking about transaction lookup or UTXO lookup?

@Murch I meant transaction lookup

Just to clarify a possible misunderstanding: "binary Merkle trees" (in Bitcoin blocks) are not used for looking up transactions. They're used to construct proofs that a transaction is contained within a block, in as few bytes as possible.

No, you can't. The block chain is a linked list of blocks, and each block contains an array of transactions. Block headers commit to a Merkle tree of the transactions in them, but they are sorted chronologically, not by txid, so you need a linear search. If you want to find a transaction in a block quickly, you'll need an external index data structure.
There is however also no need for that in normal operation of a Bitcoin node or wallet.
For verification, a set (which is internal to the operations of a node, and not part of the block chain) of unspent transaction outputs is maintained, indexed by txid (the so-called UTXO set). This set represents the 'state' of the ledger at a given point in the block chain, and blocks can be seen as 'patches' to the UTXO set: transaction inputs remove ("spend") entries from the UTXO set, and transaction outputs create new ones.
Wallets maintain their own set of transactions relevant to the user's balances. These are typically indexed, but much smaller than the set of all transactions in the blockchain, and often just kept in memory.

So, Might I say that the algorithmic efficiency of a transaction lookup is O(k*log2(n)), where k is the blockchain length and n is the number of nodes in the tree?

@HenriqueBarcelos I think it's O(n) where N is ALL transactions ever. You may want to look at the -txindex option to bitcoind. I think that should create an index on all transactions making it (I assume) O(log n) or better.

For example: given a transaction id, starting from the head of the chain, I'd lookup for the transaction by traversing the Merkle tree. If I don't find it, then move to the previous block and so on... Would this be possible?

There is no Merkle tree for you to traverse. The Merkle tree is not in the block chain, it's just how some of its hashes are computed.

The time is O(n), with n the number of all transactiins ever, if all you have is the block chain.

@HenriqueBarcelos: To put it in another phrasing: The transactions are not ordered in any specific way in the blocks, they are just a linear list. If you don't know where to find the transaction, and only have the id, you'd have to look at all transactions until you find it.


text:
How to build bitcoin from source on Arch Linux 2012.10 64bit?

Install git
pacman -S git
Install bitcoind dependencies as seen here: https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.txt
pacman -S boost boost-libs miniupnpc openssl db
Install arch-linux base development packages so you can use make
pacman -S base-devel
Download and install bitcoind from the github source
su daemonuser
cd /home/daemonuser
git clone https://github.com/bitcoin/bitcoin.git
cd /home/daemonuser/bitcoin/src/
make -f makefile.unix USE_UPNP=- USE_IPV6=0
bitcoind -daemon

Do you have a file called "classification.hpp" anywhere on your system? What version of boost did you install? (It looks like you may need a -I flag to tell the compiler where boost/algorithm/string/classification.hpp is.)

I don't know that much about arch linux, but it looks like you're installing boost-libs, which suggests that it only has the libraries. You need to install boost as well.

boost was all that was needed, thank you both!


text:
How does a Wallet Create a Transaction when a Public Address Is Provided?
Given a public Bitcoin wallet address 1BdYVvwoxTWMGqJS2Pg6NkVD7RnENVjSac; is pasted into a wallet to send Bitcoins to.  How does the wallet create an output to send coins to the public key associated with this address since it is impossible to derive from the public address?

Does this answer your question? Why is it impossible to derive public key from address?

"how do wallets determine where to send Bitcoins?" -- Remember, money isn't really sent to addresses, wallets don't really contain money.  As you know, those are just metaphors.

I rephrased the question to hopefully be more clear.  I'm really trying to understand how to create an output given only the public address.

@m1xolyd1an It seems unrelated to the OP question.

There are currently 3 types of addresses defined, and each directly encodes a specific scriptPubKey.

1... addresses. These are P2PKH addresses. To construct their scriptPubKey, use Base58Check decoding, verify the first byte of the result is 0, and then construct the script OP_DUP OP_HASH160 <byte 1-21 of the Base58Check decode> OP_EQUALVERIFY OP_CHECKSIG.
3... addresses. These are P2SH addresses. To construct their scriptPubKey, use Base58Check decoding, verify the first byte of the result is 5, and then construct the script OP_HASH160 <byte 1-21 of the Base58Check decode> OP_EQUAL.
bc1... addresses. These are native segwit addresses. To construct their scriptPubKey, follow the procedure documented in BIP173 and BIP350.

The prefixes characters/bytes are different for other networks, such as the Bitcoin testnet.
Ideally, you don't need to reimplement this yourself. There are several Bitcoin libraries out there that can do this for you, in various languages.

Yeah, this is exactly what I was looking for, thank you very much for the response.  Just so I'm clear, the purpose of doing the base58 check is to determine which of the 3 types of address you are working with indicated by the first byte (byte 0), then subsequent bytes are used as the hash in the output? Do I have that correct?  I am trying to write this logic myself for educational purposes.

Base58Check encoding also includes a checksum to detect typos.


text:
Creating a lightning invoice without running a full node
I'm trying to build a small website that takes payments using a lightning invoice. I want to do this without running a full node (or pruned node if possible) on my server to keep costs down. I'd be happy with any of three types of solutions:

Install a custodial lightning wallet on my server with a CLI or REST API to generate and check the status of a lightning invoice. Electrum could work, but I didn't see invoice generation in the docs.
I already run a full node on Umbrel, but I'm not sure how to securely expose lnd's http api to the internet.
Use someone else's full bitcoin node to back lnd on my server, or use a custodial lightning wallet with an api.

I'm open to suggestions, I'm very new to the space and learning lots all the time.
Ongoing research:

lightning-charge uses c-lightning, which requires a full node.
FeatherLight looks like it would do what I want as a standalone service, but again, I'd have to host a full node.
LightningHub API Seems like it could work if I set up a BlueWallet.
LND Hub provides multiple users access to a single lnd instance.

I can suggest also the following tools https://github.com/clightning4j where you can run c-lightning on a machine of 30 $ for a month. This is a demo https://bruce.bublina.eu.org/. The idea is to use the rest API with Nginx on docker so you can hide the API from the public, and talk with your website. A microservices architecture. P.S: it can support BOLT 12

The approach I've ended up taking for this project is to expose my Umbrel's LND gRPC REST API.
My home network doesn't accept incoming requests, and I don't want that for my entire Umbrel anyway, so I'm using ngrok to proxy requests to LND. LND only accepts TLS connections, so bind_tls has to be true, and proto should be set to tls. Ngrok has its own tls setup, so it doesn't bother to check the validity of LND's self-signed cert, and so doesn't need the path to the certfile.
I'm also using a restrictive macaroon for authentication — this is essential for security, since if the admin macaroon were leaked you'd be up a creek. In my case, all I had to do was generate and check invoices; ./umbrel/bin/lncli bakemacaroon uri:/lnrpc.Lightning/AddInvoice uri:/lnrpc.Lightning/LookupInvoice was sufficient for that.
To make requests against my lightning node, all I have to do is something along the lines of curl -X POST https://my-app.ngrok.io/v1/invoices -H "Grpc-Metadata-macaroon: my-macaroon" -d '{"amount":1000,"memo":"my-memo"}'. This translates nicely to a python requests invocation from my application server.

I will try to explain my comment in an answer. There is no clear way to host a lite ln client only to revive payment and show it, without hosting an ln node on the server, with the bitcoin core backend. Maybe with lnd you can do some things (or rust-lightning), but I'm not an expert of both implementation.
However, I worked on this problem in the last months, because I was searching for some things to make my c-lightning node a little bit more lite. With c-lightning, there is the opportunity to run custom code inside it, and I override the bitcoin backend with a custom plugin called btcli4j that is able to run c-lightning with the pruning mode, and also with rest API compatible with esplora API by default it uses Blockstream API.
There are a couple of tools that I developed to run c-lightning in a lite way for business and all the code is under the repository clightning4j.
There is also a docker image that packs all together (include also a rest API documented with open API)
I think it is a really lite way solution because it can be run in raspberry with a default config (without 1TB of space). Off curse, the tools are under dev, but there is a open discussion where you can make a feature request.
A demo available here
Running over


text:
Do I have to worry about endian swapping when calculating ECDSA public key values, Creation & Signing of transactions and verification of signature?
Do I have to worry about endian swapping when calculating ECDSA public key values, Creation & Signing of transactions and verification of signature?
This question is more of a straightforward yes/no kind of question because as far as I can tell Bitcoin endianness swapping madness will make you feel like your logic & algorithm are incorrect... Which in a way is true when considering that the algorithm requires bit swapping on almost every turn...
So let's say I have functions
string CreateTransaction();
string SignTransaction();
bool VerifySignature(string Signature, vector<string> PublicKey);
string GeneratePublicKey(BigInteger PrivateKey, vector<string> &PublicKey);

// Takes input parameters like amount in Satoshi, receiving address
// and other necessary data as required by bitcoin protocol
string CreateTransaction(); // returns raw transaction hash

// Signs transaction as instructed by BIP rules | DER format
string SignTransaction(); // returns signature string

// Verifies received signature via parameter
bool VerifySignature(string Signature, vector<string> PublicKey); // returns true is signature matches given x point of publicKey

// Generates publicKey via ECDSA Secp256k1 protocol
string GeneratePublicKey(BigInteger PrivateKey, vector<string> &PublicKey); // updated PublicKey address but returns compressed or Uncompressed public key value (Decimal or hexadecimal)

I know for certain that the CreateTransaction(); requires endian swapping
But I'd just like to confirm if there is any point in time during the secp256k1 ECDSA curve calculation that I need to swap endianness of any data.
Because I don't require swapping endianness when carrying out HASH160() on a privateKey value to get an accurate hash.

All values required for your calculations are stored in big-endian format in the transactions. Where 'big-endian' basically means: you write it as you are used to writing down numbers, starting with the highest value digits.
This goes for:

The x-coord and y-coord of publickeys
The r and s value of signatures
Also the result of the sha256(sha256(...)) when calculating a transaction hash.
Also the result of the sha256(sha256(...)) when calculating a message hash, to be used for signing.

Also, the hashes stored are in the 'normal' order, as what is specified in the original sha256 algorithm.

The source transaction hash used to reference the output.
The parent block hash.
The merkle root.

That is the sha256 algorithm as it is used outside of bitcoin.
This also holds for the ripemd160(sha256(...)) algorithm.
And the way you convert an address hash to it's base58 representation uses big-endian numbers. The address itself is the big endian representation of the hash.
Only the way block and transaction hashes are commonly displayed is with the bytes of the hash reversed.
So the 'real' hash of the genesis block is:

first step:  af42031e805ff493a07341e2f74ff58149d22ab9ba19f61343e2c86c71c5d66d
second step: 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000

So basically, you only worry about swappig the endianness, when you print the transaction or blockhash for a person to view. Otherwise they stay as they are.


text:
Is the coinbase automatically generated by the getblocktemplete rpc call?
I'm working on a mining script and i just want to really be certain for sure as I wouldn't want to waste Time & resources.
Q1 - Is the coinbase transaction automatically generated by the getblocktemplate or do i have to implement it myself.
Q1(b). If the inclusion of the coinbase transaction is not done automatically and as such is not the first transaction on the list of transactions returned by the getblocktemplate (as it should be)...... How would I go around generating the
coinbase? Is there a function in the main bitcoin source code that handles this, something I can crop out and make a portable function?

Q2. Assuming coinbase transaction has been provided via blockchains protocol to ensure empty blocks are never created again, Is it safe to assume that the coinbase has been generated with the bitcoin address linked to my full node?
Q2(b). If it has been created and my address set to recieve the rewards, what happens when I currently have more than 1 btc wallet address linked to my wallet?? Is there a way I can specify the address to be used for mining within my bitcoin.conf  file ?

"The hashing/mining tests to be carried out are being spearheaded by a CPU System. To be more specific, A Custom Dynamic Multi-Processor Mining Rig, being fed data and instructions via CPU. The CPU does a bit of mining itself using a different merkleHash generated."

Q3. The generate=1 option within the bitcoin.conf file, does it mean that my cpu begins mining internally or is it an option that has to be turned ON if a user(miner) intends to mine with their CPU(either alone or with mining rigs handling the hashing process)??
What I'm asking is.. If the generate parameter is not defined or is  = 0 within bitcoin.conf, does that mean that all mining efforts are wasted ?? or is it only related to the internal mining script deemed to be inefficient?

And lastly.....
Q4. Miners are advised to use different addresses for a level of privacy and anonymity. The question,  Would I have to manually create new addresses at every successful block mined or is there an option to automatically handle that or a button that toggles such a feature off/on within the GUI?
I do hope these questions can be answered by someone.... It's extremely important.. Thanks so much in advance.

UPDATE !! 10/12/2021   01:10AM
Hamita successfully answered Questions 1,2 & 3.
Question 4 remains unanswered but since majority of questions have been answered, I'll accept Hamita's answer as a valid answer to my posted question.

The coinbase transaction is not generated automatically from bitcoin core, you need to generate it yourself with the createrawtransaction command.
For the setgenerate is no longer available in the options and you can't use it.

So once I generate the coinbase using the createrawtransaction command, is it safe to assume that it has been added to the list of transactions unique to my getblocktemplate rpc call??  And if that's the case, would I have to redo the entire step each time I attempt to mine a new block?

when you generate your coinbase transaction you will need it to build your merkleroot,  with getblocktemplate you will receive other data to build your blockheader

@Hamita Thanks a great deal. This answers my first 2 questions. I would love to select this as the answer but it only solves half of it. What do you think I should do?

And If you wouldn't mind helping your greenhorn friend overhere....... How do I insert the height of block to mined into the coinbase transaction?? I know its stored in hex format and is the starting point of the coinbases's scriptsig -> Your Answer To a question relating to the creation of the coinbase

For the actual block height The scriptsig begin with 0350e40a, the 03 for the next 150 years will remain the same, 50e40a The height of the block in little endian, note that you must include the size before that, and it can't not be greater that 100 bytes

It would be great if you could combine these comments into your answer @Hamita :)

Regarding question 4, you need to manually create/request a new address each time you need one.

Thanks for taking the time to answer my question


text:
One address 2+ private keys. Bitcoin future
Since bitcoin uses cryptography algorithms to create private and public keys there is a possibility it could repeat.
Person 1:
L54w...KraG -> bc1...kq4
Person 2:
L3mV...JU8G -> bc1...kq4
So could person 2 single handedly sent bitcoin from bc1...kq4 to a different address. My question is would both of the private keys work to change the funds. If so how will his affect bitcoin as a whole.

Does one of these three answer your question in full? https://bitcoin.stackexchange.com/q/8804/5406, https://bitcoin.stackexchange.com/q/43609/5406, https://bitcoin.stackexchange.com/q/22/5406

The size of the key space in Bitcoin is just shy of 2256. There are a few different output types with different address schemes, but for most of these, the address space is a lot smaller than the key space. Let's assume you're inquiring about P2WPKH. There are about 2160 unique addresses for P2WPKH outputs, so about 296 keys map to each address.
You are therefore correct that hypothetically two users could each discover a different private key that map to the same address. If that were the case:

There is no registration of addresses or other mitigation for key collisions. Simply, either user could spend funds received to the address.
From a protocol perspective, there would not be a problem at all, as a transaction signed with either key would be valid.
If they both notice in time, the users might get into a bidding war, creating conflicting transactions with higher and higher fees to claim the funds.
If transactions from both users surface, other people might notice and be concerned about the key collision. Most likely this would lead to a loss of confidence in the method the corresponding keys were generated, but some users could lose confidence in Bitcoin instead due to misunderstanding the cause of the situation.

2160 is an extremely large number. As long as key generation uses reasonable entropy sources, it's unlikely that we'll ever see any two addresses collide no matter how long Bitcoin will get used.

Suggesting that two users could hypothetically generate the same address and to infer implications for spend-ability of the coin is really just a thought experiment. What really needs to be understood is the sheer scale of 2^256. Without analogies the human brain has trouble comprehending the scale. This video from 3Blue1Brown youtube.com/watch?v=S9JGmA5_unY gives a good explanation of the scale and security of 2^256.

@stackaccount: Perhaps you could add another answer that focuses on highlighting the magnitude of 2^160, if you feel that "it's unlikely we'll ever see any two addresses collide" doesn't stress this aspect sufficiently for your taste.—I chose to answer the way I did, because the question was about what happened when the situation occurred, and linked to a prior answer that covers how unlikely that is.

@Murch But isn't 2^256 the maximum amount of hashes that can be generated. A collision could and probably would occur before 2^256. So in theory couldn't a collusion occur today or tomorrow or next week?

Most addresses that involve a hash function (P2PKH, P2SH, P2WPKH) have a RIPEMD160 hash step. So while there are just shy of 2^256 keys, there are only 2^160 addresses. This is still plenty that we don't ever expect to see a collision.

See the post I linked in the last paragraph for calculations on that matter.


text:
What's the easiest way to gather/collect statistics on the bitcoin network?
Basically, how does a site like bitcoincharts.com gather its statistics? I like coding in python if you want to offer code examples.

Welcome to Bitcoin.stackexchange! Your question is probably too inspecific to get a very good answer. You're best to start by stating what your end goal is, such as a chart of price history, and then asking a question on how to get there.

BitcoinCharts doesn't show much from the bitcoin network.  The market data comes from the exchanges.
Bitcoin Charts shares freely their markets and trade history data:

http://bitcoincharts.com/about/markets-api/

The original source for the data is accessed from the exchanges themselves.  Most exchanges do share their data but the API methods are not standard nor consistent between exchanges.
As far as statistics on the blockchain data, the method will vary on which statistic you are trying to get at as some are stored (confirmed transactions), and others are not (e.g., memory pool contents, double spend transaction attempts, etc.)
If you like python, then Armory provides access to the blockchain.  See the Sample Armory code in the extras::

https://github.com/etotheipi/BitcoinArmory/tree/master/extras


text:
what are vin_sz and vout_sz in tx part?
I am trying to understand the raw blocks better:
vin_sz and vout_sz are some of the unknowns. does this values (sz=size?) have something to do with a number of confirmations?
example:
https://blockexplorer.com/rawblock/00000000000008d11f13eed2e13f2765eceaf00de36e0ec040a10cc3738bdc74


text:
Is there a limit to how long a wallet can be offline?
I have a wallet file I backed up June 2011, and has been offline for over a year now. When I copied it back into where the files are stored with the official client, it says my balance is 0, with no transactions.
Does it take a long time for my balance & transactions to get updated correctly, or is my wallet considered corrupted, and the coins lost forever?

Which version of the client are you running now? Has the blockchain download completed?

Worry not, unless you messed up when backing it up, which I believe you didn't, your funds are safe. 2. Please post exactly what steps you took in restoring the wallet / installing the client, so people can better help you. Post OS, file locations, client versions ... the more details the better.

Any unspent bitcoins against addresses in your old wallet should be retrievable.
The client won't show transactions that haven't been downloaded to your copy of the blockchain yet. There should be an icon in the lower right corner of the Bitcoin-QT client that indicates progress on downloading the blockchain. It can take a few hours (there's around 2.5GB to download, and it downloads them slower than you'd expect because the client verifies the blocks as it goes).

There is no limit to taking the wallet offline. The blockchain, which is shared by all users, contains all the information on who owns the bitcoins. Your private key identifies the ownership.
Now the reason why you may see a balance of 0 is because the official windows client doesn't seem to store the wallet inside the application folder, but in your OS user profile. It may still be reading the wrong wallet.
If you see your old transactions, but a balance of 0 - then you should worry.

I think the problem is that the Bitcoin-Qt client doesn't know that you have changed the wallet, and for performance reasons doesn't rescan the blockchain for transaction relating to the new wallet.
It's easy solved by starting Bitcoin-Qt with the -rescan parameter.


text:
Relation between Network Hash-Rate & bitcoin value?
how is the relation betweeen network hash rate to healthyness of bitcoin, such as bitcoin value compared to USD, or the growth rate of this currency?

The network hash-rate is mostly reflective of Bitcoin's exchange rate.  If the exchange rate goes up, then mining's hash rate will follow.  It will lag, but it will mostly follow the direction and to a lesser degree, the magnitude of the change in the exchange rate.
While there are some who will mine regardless of profitability, each additional bit of hashing has the effect of lessening profitability -- displacing those who are mining for economic gain.
So as a whole, the network hash rate itself doesn't say much about the currency's health.  Now for each individual that goes and spends $20K worth on mining hardware, you can assume that one individual believes in bitcoin's future enough to risk that kind of an investment, if profit was the reason for pursing such a venture.

You can find graphs charting this relationship at http://bitcoinx.com/charts/. (scroll down)
Network hash rate and exchange rate are certainly correlated, but the relationship is very complex, I think it would be inaccurate to say that one depends on the other. In general, if price increases due to an outside factor (eg. new adopters buying Bitcoins) hash rate will go up, as you can see in the chart at the above link around July 2011, when price spiked and hash rate followed.
Impact of hash rate changes due to outside factors on price is harder to predict. Hash rate increases can lead to increased investor confidence in the currency (which would increase price), but they can also drive miners on the edge of profitability out of mining and potentially even Bitcoin, decreasing the price. (less participants in a market generally leads to price decreases, though not always)

Well put.  I would add that the marginal cost of acquiring a Bitcoin, has a floor set by the current hash rate using the most efficient source of computation (energy costs).  A rational actor will choose to mine for Bitcoins rather than purchase them, if the cost of mining is lower than the cost of exchange.
But getting involved in mining has rather large fixed costs that make it difficult for most individuals to choose mining over purchasing; so one can expect the cost of Bitcoin to be at a premium over energy costs of mining for the near future.

Bitcoin hash rate is:

25 BTC / (physical cost to perform one hash in BTC) / 10 minutes.

There are two factors in this formula which are subject to change:

The physical cost to perform one hash in BTC is obviously linked (linearly) to the healthiness (trade value) of the currency. It's also subject to change with hardware improvements, but this has no effect on the overall security of the system. (Attackers would also benefit from it.)
Last, 25 BTC is in fact not fixed: it's an approximation of today's block reward + transaction fees miners get mining one block.
In particular, every 4 years this reward is scheduled to be divided by two. Therefore, if the trade value of bitcoins is not multiplied by two every four years, the total effort spent on mining (to secure the chain) could decrease.


text:
Why is syncing the last 5000 blocks so much more CPU-intensive?
I deleted my block chain and I'm currently syncing again. Just as I did last time, I noticed that from a certain point, my CPU usage raises to almost 100% and stays so for much longer than the usual peaks before this.
I think it's around the last 5000 blocks.
It also sometimes just stops, I don't know if that is for saving resources or something else, but sometimes it just stops (both CPU and network traffic go to nearly nothing) and almost no new blocks are added.
Is there a reason for this different behavior while syncing the last 5000 blocks?

Did you find out more about this? I'm experiencing the same thing

Up until the last checkpoint, your client knows that all transactions are properly signed. After the last checkpoint, your client has to validate each input to each transaction by matching it against the corresponding output and executing the script, typically involving an ECDSA verify.

And how are these checkpoints defined?

They're included in the source code. Whoever provided you the source code vouches that all blocks prior to the last checkpoint contain only valid transactions.

Is that what this is? : 2016-03-20 17:49:12 Pre-allocating up to position 0x1000000 in blk00437.dat 2016-03-20 17:49:19 Pre-allocating up to position 0x2000000 in blk00437.dat 2016-03-20 17:49:22 Pre-allocating up to position 0x3000000 in blk00437.dat 2016-03-20 17:49:24 Pre-allocating up to position 0x4000000 in blk00437.dat 2016-03-20 17:49:25 Pre-allocating up to position 0x5000000 in blk00437.dat

Might be that there's a lot more transactions in later blocks.

I considered that, but I think it's not that. New blocks are also coming in faster than the ones before (the very early sparse blocks not taken into account).
It calmed down now, but blocks are added really slow.
Maybe it was just imagination or coïncidence


text:
if a Bitcoin mining nounce is just 32 bits long how come is it increasingly difficult to find the winning hash?
I'm learning about mining and the first thing that surprised me is that the nounce part of the algorithm which is supposed to be randomly looped until you get a number smaller than the target hash .. is just 32 bits long. Can you explain why then is it so difficult to loop an unsigned int and how come is it increasingly difficult over time? Thank you.
Edit: It's been suggested this is a duplicate, this is not. The other question asked if you could run out of nounces, that's nothing to do with my question. My question is about the difficulty of Hashing the exact same 4 billion unsigned int entry loops.

Short answer: With high probability, none of those 2^32 nonces will result in a hash smaller than the target.  So then you change something else in the block header and try again.  For instance, you can increment a number in the coinbase transaction, which results in a new value for the "Merkle root" hash in the block header.  The smaller the target, the more times you are likely to have to do this before success.

@NateEldredge It looks like you are saying that you do not really need  to change the nounce since there is the possibility that none of the 4 billion different values may lead to a winning hash. What makes then a valid 'source material' to hash while attemting to discover a right answer? if you can point me to updated literature about it I will accept that as a right answer. Thanks

No, I'm not saying that.  What you need is a valid 80-byte block header whose hash is below the target value.  So you have to keep changing things in the header until you find something that leads to a winning hash. The easiest thing to change is the nonce, so you fix everything else and then try all possible nonces.  If you are lucky then one of them works and you win.  If not, which happens most of the time, then you change something else in the header and try all nonces for the updated header. Repeat indefinitely until you win.

There isn't any need for "updated" literature; the block format and hashing algorithm hasn't changed in any relevant way since the initial introduction of Bitcoin.  It was always possible that, with everything else in the header fixed, none of the 2^32 possible nonces wins, and this case always had to be handled; it already happens about 36% of the time even at minimum difficulty.

It is not the looping that is difficult, it is generating a hash for each iteration of that loop.  Furthermore, as @Nate pointed it, a miner will likely have to change more than just the nonce.  As more transactions are coming in from the network, a miner will add/swap them into the block they are hashing, presumably based on maximizing transaction fees.  Each time the transaction set is modified, all tried nonces can be tried again.
As for why it gets more difficult over time, that is a core part of the protocol.  Every 2,016 blocks, the target hash re-adjusts so that blocks will take about 10 minutes.  As more hashing power enters the network, the faster blocks are found, which in turn will trigger the re-adjustment after 2,016 blocks.

You say the target Hash readjusts every 2016 blocks, is that 2016 transactions on the network? And: readjusted how? as in: recalculated so all the previously calculated nounces need to be retried?

@Pol, if you are confused about a block vs a transaction,  it's going to be hard for anyone to give you a satisfactory answer to your question.  I recommend reading up a bit more.  Here's a great place to start, and should give you the context you need to understand these answers:  https://bitcoin.stackexchange.com/questions/148/what-exactly-is-mining

Agreed, plus there is a question that matches my concerns already. Thanks for your help.


text:
Create addresses in bulk; and check balance
I am new to Bitcoin; our company wants to use bitcoin for payments.
We need to create a address for each transaction. so we need to create many public address.
First, I need to generate many public and private key-pairs. This is going to be very hard to do in a secure way!
I read another question that said with hierarchical deterministic wallets we can do something like creating one key-pair and generate many public address from it (means one private key can have many public key).
So if it really do!: Do we need to keep all of public keys or just can use private key for transaction bitcoins or checking balanced? or the other public keys are child key and i should keep the first mother public key?

Can someone else see how much bitcoin we have earned?

just with child-address?
if she/he get the master public key, can they check our balance?

We want to use Lazy_API and show user an address to use it for transaction and after that check it with blockchain.info json api or blockexplorer, if transaction done after number of confirmation we proceed invoice and they can access to what they want.
Something else: some mobile wallet(like Breadwallet.com for iOS) said that they change public address after current get received bitcoins! Does they create new key-pairs or just do something like above?

To many questions. This is a one question system. Get an android phone and install mycelium (test if you don't want to use real coins) and mytrezor lite. With these apps you can play around with HD wallets to get a feel. Then buy a few trezors for your company to keep the private key safe. The private key should never leave the trezor.

i know there is one to one way question system. but i try to asked my questions once because the related to each other.

and im not using android and i am on ios devices. but recently i saw that mycelium  have ios version. but as i see in app details on bitcoin.org, "This wallet relies on a centralized service by default. This means a third party must be trusted to not hide or simulate payments." and it also requore ios 8 that i am 7. but does the app crate multi address for one key-pair?

As you found out already; private and public keys are not necessarily paired 1-to-1. In fact, using the original Bitcoin client you can just run the getnewaddress to generate a new address belonging to your wallet, which is controlled by only one private key.

That's not true. bitcoind keeps one private key for each address. getnewaddress generates a new keypair (or gets one from the keypool) and derives a single address from it.

as i knew The hd-wallet using a master key-pair and then using the public key to generate address and each address have a child key-pair too that can be used like a separate wallet! but with master public key we can see all transaction for child public key and address! https://d3qlb4e6ron71v.cloudfront.net/blog/wp-content/uploads/2014/02/derivation-500x308.png


text:
Good way to sell Bitcoins online?
I'm interested in selling Bitcoins online, probably through LocalBitcoins, but worried about getting scammed. Does anyone have  techniques to share regarding what worked well for them to sell BTC online?
I've looked at the OKPay, PerfectMoney, and MoneyPak payment methods. They seem like a hassle to setup. Do they work well?

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

The most important to secure online transactions in bitcoin trade is that you use irreversible payment methods. Otherwise, the disparity between irreversible bitcoin transactions and reversible soft money transactions opens the bitcoin seller up for fraud. Reversible - irreversible payment method scale is called "money hardness".
The safe online payment methods include

Cash deposits (thus far the safest, popular in US)
OKPay (advertises itself to be irreversible, not available in US)

Experienced traders are trading with very fraud sensitive methods like PayPal. However, they usually do identification checks or similar to further have guarantees against spammers.

Some tips how to avoid fraud with bitcoin and PayPal (applies to all other payment methods too)

Also if possible open up a separate bank account for holding the money related to bitcoin trading. Sometimes banks freeze accounts related to trading because of their own policies and hostility towards such actions. Though the risk may be low, you don't want to get your only credit card, etc. for hold.

Is OKPay only for US?

There was a mistake: fixed that OKPay is not available on US


text:
Why is such a large int (uint32) used for the transaction version field
The transaction version field is a unsigned 32 bit integer. [Source Code] [Docs]
This will allow for 0 through 4,294,967,295 (2^32 − 1) versions. So far, only versions 0, 1, 2 have been used. It seems that the amount of storage for this field is wasteful. Surely unsigned 8 bit integer would be more than enough. What was the rational for using such a large integer?
Could this be reduced with a new block version? Could this be done without a hard fork?

What was the rational for using such a large integer?

Because Satoshi did not care about it. Bitcoin transaction serialization is not optimized for size.

Could this be reduced with a new block version?

No

Could this be done without a hard fork?

No. But you can implement new way to serialize data on disk and on network and encode/decode transaction contents on-the-fly. In fact nobody cares about these bytes.


text:
How to fork Bitcoin with ease
I want to create a fork of Bitcoin which I can mine and have a wallet to send to another address to learn more about how Bitcoin works. Is there a very easy way to do this? Like can I just fork the github repo and change some lines and compile it all? Or is it a more intensive process?
A lot of the tutorials no longer work because they are very old.

You could simply use Testnet or Signet.

Why is this question marked as already answered. The OP wants to know how to develop a new and different   coin (also known as altcoin) but the question related if about how to develop an app based on bitcoin blockchain. Can the community please reopen this question as this question is not asking about the testnet but how to hard fork bitcoin.

@VarunW.: Hi Varun, the asker here wanted to have a chain to play around with to "learn more about how Bitcoin works". I think that can be achieved with a new Signet. Besides, questions about altcoin creation are not on-topic here.


text:
Where in this web can I post what I think rather than ask about bitcoin
I would like to know where can I post What I think and have a discussion on Bitcoin issues rather than ask/answer questions, or is this just an ask and answer area?

There's forum just google 'bitcoin talk'

Stackexchange is a question&answer platform. So, you can write what you think in answers that fit the questions asked. ;) Check out [about] for a quick overview what Stackexchange is.

I’m voting to close this question because questions about this web site should be asked on [meta]

Forums I participate in
bitcointalk
cryptocointalk
cryptocrypt
Bitcoin Reddit
Bitcoinfoundation forum
Google Search
bitcoinforum
ecoiner
coinboards
bitcointrading forum
coinforum.ca
There's bucket loads of forums out there, not to mention IRC Channells where you can find People 24 hours a day to talk live to about bitcoins
IRC channels
I think the harder question will be where to start ;) good luck


text:
bitcoin private key usage
My next question is how Private Key needed to spend coins. According to my understanding for transaction needed below steps:

A wants to send 10 coin to B
A make transaction example: from: A, to :B coint:10
A signs with its private Key: from: A, to :B coint:10,  sign:qwertyasdfzxcv

So the result is B gets 10 coins on its public key (wallet address) and sender Public Key is enough to verify sign of Sender.
what is the usage of the private key to use this ? is this is transaction also getting encrypted by B public key (in this case only B's private key can be decrypted)
if like that then noone can read transacrion to valite it ?
So, what is the technical usage of the private keys to use coins?

The usage is a digital signature. It is a form a cryptography, but it is distinct from encryption. In fact, nowhere in Bitcoin's protocol does any form of encryption get used.
A digital signature, formally, is a collection of 3 functions:

key generation: randomly construct a keypair (i.e., a private key and its related public key).
signing: given a message and a private key, construct a signature.
verifying: given a message, a public key, and a signature, output true (if that signature was created with the private key corresponding to the provided public key, for the provided message), and false otherwise.

While certain signature algorithms are based on encryption algorithms (e.g. for RSA it is the case that private and public key are sort of interchangeable, and you can see signing as "encrypting with the private key"), this is not true for all of them. The specific signature algorithm used in Bitcoin (ECDSA) cannot be used for encryption purposes.

Yes, that part is clear. My question is what does mean in technically "private key needed to spend coins", since private key is used for  singing only, and public key is needed to verify sign.  If someone sent me 10 coin, what is my private key role to use these 10 coins ?

I don't understand what you mean by "role". Its role is signing the transaction to authorize the spending.

Let's put it this way. 1) Fariz sends money to Pieter.  2) Fariz signs the transaction with Fariz's private key. 3) Pieter or miners verify the transaction by Fariz'z public key.  So the question is what is Pieter's meaning private key of Pieter to use that coins?

If I want to construct another transaction to move the coins further to someone else, I'd sign that new transaction with my private key. Everyone can verify this, because the output (of your transaction) says "can be spend by public key P", and the input of the next transaction spending it contains a signature that can be verified against that same public key P.

FWIW, I'm just trying to find out where the hole in your understanding is, so I can write an actual answer addressing that.

Looks it is clear. But still, I am not confident until the transaction is not encrypted (I don't mean signed). Yes, other nodes will make strong immune to reject altered block. But I am still wondering the miner node (hacker) can mine a block first and change the transaction signing (decrease coin and sign with own private key). yes, hackers will lose money, but target wallet under risk. Until transaction can be read by anyone means can be changed (before sharing with other nodes). Still, cannot udnerstand security

If the transaction is changed, the signature is invalidated. The message being signed is (a variant of) the spending transaction itself. The signature is not valid for any other message.

Let us continue this discussion in chat.

how Private Key needed to spend coins

A transaction spends some previously unspent transaction outputs (UTXOs) from one or more previous transactions.
Each UTXO has associated with it, in the transaction data, a script.
This script (sometimes called a locking script) is a small computer program written in a very small programming language that is called the Bitcoin scripting language. It is a bit like a very primitive stack-based assembly language.
This language has operators such as OP_CHECKSIG which use ECDSA to check a signature and return TRUE or FALSE.
This script determines who can spend the associated UTXO. prospective spenders do this by providing data which can be prepended to the locking script and then the whole evaluated using a Bitcoin scripting language interpreter (or compiler). The result will be true or false (any non true value). If the provided data and the old locking script evaluate true the spending transaction is regarded as valid.
There are some standard scripts such as pay to public key hash (P2PKH).
Typically the script requires as inputs a number that is calculated using the private key. Others can then use ECDSA etc to verify that the number was produced from a private key that corresponded to the public key used when creating the locking script.

As Pieter noted in his answer, no network or blockchain data is encrypted in a normal Bitcoin transaction. All transaction data is completely readable by anyone.

in this case, the private key is only for signing. So, verification of message is going to use Public key. So, if you lost your private key technically it is still possible to construct a transaction with pub key verification. Only you cannot make a new transaction, am I right? But still can access to get balance.

Assume a transaction is composed of two parts:
[proof of ownership] [new owner public key]
Bitcoins are born in coinbase transactions, which are special because they don’t have proof of ownership, and they belong to the miner:
[ ] [miner public key]
When the miner wants to spend this coins (send to Alice), he generates a new transaction, where he needs to prove he owns them, so he signs it with his private key:
[ ] [miner public key] => [signed with miner private key] [Alice public key]
Everyone can check if the signature is valid, without knowing the miner’s private key, thus verifying the proof of ownership. If it is valid, the transaction is accepted and soon will be confirmed in the blockchain.
Alice is now the owner of some coins. When she decides to spend them, she will repeat the process:
… => [signed with Alice private key] [Bob public key]
And so on.
Note: for simplicity reasons, I only used public keys to identify the new owner, but there are more types of transactions.


text:
How/When is mining reward given in the presence of forking / orphan chain?
I am aware this is related to this question. However, I am specifically curious about what would happen to the mining rewards, not the transactions, under a forking condition.

As shown in the picture. Suppose at some point the blockchain starts branching. Each new block on each chain gets appended at the same time, until eventually the blue chain gets longer than the green chain due to G being mined faster. Then the green chain becomes invalid.
Does this mean the miners for A, B, C and D, E, F don't get mining rewards at all until a longer branch (in this case, the blue branch) is determined, then miners for D, E, F, G get rewards?
If so, what if a selfish miner releases two new blocks on the green chain after G is being appended? (As shown below) Does that mean the rewards get reversed again?

Thanks!

Edits:
Following up with one of the answers, suppose what we have in the following is a GLOBAL view of all the blocks on the whole blockchain system:

So apparently the colored blocks become orphans. However, block #1 and block #3 seem to still get rewarded, except they can never spend those rewards. So does that mean the total number of bitcoins on the market will practically be smaller than 21 Million (after all the coins are mined), due to these orphan blocks? I.e., some coins are rewarded to the orphan blocks but they can never be used by anyone?
And do block 2, 4, and 5 also get rewarded (but can't spend those rewards)?

You have to distinguish between nodes' local view of the chain, and your global view when discussing here.
Every chain (meaning: a block together with all its direct and indirect ancestors) is a version of history. Within that chain, the block pays out to whomever mined the block. As far as miners on that chain goes, they are extending the chain they believe to be legitimate, and see themselves as being paid in the process. So B's miner believes it is being paid by B, and believes A is being paid by the parent block. Similar with C, seeing A and B being paid.
However, when the reorganization occurs, A, B, and C's miners, along with any nodes which saw those blocks first, realize they were working on a version of history that the network will (probably) not accept, and they switch over to the D-E-F-G chain, in which they are not paid.
Now, there is a rule in Bitcoin called maturity, which prevents the coins minted in blocks from being spent until 100 blocks have been mined on top. This prevents a situation where many transactions are invalidated because of a reorganization that removes the coinbase that formed the initial credit. After 100 blocks, it is highly unlikely a reorganization will still occur.

Thank you. So in the first picture, where the blue chain gets to be the longest chain: 1. Does C get a reward at all? 2. Is it true that A and B still do get the reward, but they will never be able to spend them because the green chain doesn't satisfy maturity? 3. If 2 is true, does that mean the total amount of bitcoins will practically decrease, because the nobody can ever spend the rewards on orphan chains?

Within the A-B-C chain, yes; within the D-E-F-G chain, no. If you assume D-E-F-G is eventually the one that wins, and thus ~all nodes accept, in the long term, no.

Sorry could you please refresh and get the latest version of my comment? :P I pressed enter thinking it would give me a new line but instead it posted my comment before it was done writing

You have to realize: nodes don't see or care about the whole picture; the network rules don't consider the entire tree, they function within one chain, and thus the answers to all these questions are "it depends on which chain your local view currently accepts", which can change over time.

A and B do get their reward, within the chain they are building. If that chain is extended by another 100 blocks, they will eventually be able to spend the coins within that chain.

What the total number of coins in circulation is depends on which chain you accept. In a reorganization, that chain changes, and thus the number of coins in circulation can also change.

Nodes accept among all otherwise valid (i.e. no invalid signatures etc.) chains, the chain with the highest total proof of work in it. If there are multiple, the one with the first-seen tip is accepted. Thus which chain a node accepts depends on aspects such as how close they are to miners, and their connectivity. There is no global consensus: nodes are never sure about any block that it will eventually be accepted by the rest of the network. It just becomes less and less likely to change, as more and more blocks are built on top.

From the perspective of nodes that accept a chain which does not include blocks A and B, blocks A and B don't exist. They aren't part of history. They don't get to consume any subsidy, and thus they don't affect the 21 million limit.

The coinbase (or output with the mining reward) can only be spent after COINBASE_MATURITY has been reached which is set to 100 blocks. Hence a miner spending a coinbase that is later reversed is only a problem if there is a greater than a 100 block re-org. The chances of this happening on Bitcoin mainnet is infinitesimally small.


text:
Can a miner open a Lightning channel with a coinbase output?
Assuming that the funding transaction uses a P2WSH output, can we open a channel by providing that standard 2-of-2 multisig as the coinbase output?

After thinking some more about it: it would be impractical to open a channel with a coinbase output.
For one, there is the maturation period for coinbase outputs. Since coinbase outputs can only be spent after 100 confirmations, any attempts to close the channel would be delayed accordingly.
The bigger issue is that the channel opener's capability to refund themselves depends on a transaction presigned by the channel partner. As the refund is a child of the coinbase transaction, the channel opener would need to renegotiate the channel open with the channel partner every single time the coinbase transaction's hash changes. This happens for example every time the extranonce is incremented or the transactions included in the block are updated, because of the witness commitment stored in an output of the coinbase transaction.
This would lead to the channel needing to be renegotiated multiple times per second even with a small mining operation, unless the miner used special strategies to minimize coinbase transaction updates (e.g. time-rolling, overt ASICBOOST) in lieu of updating the extranonce in the coinbase which would only reduce the frequency but not mitigate the problem entirely.

So assuming the 100 confirmation maturity issue is acceptable to both channel parties...
the further impracticality is that for each failed attempt at mining the block containing the coinbase channel open (someone else mines that block first), you would need to reacquire a refund transaction after recreating a new funding transaction that recommits to a new set of wtxids (due to the BIP141 commitment structure requirement)

Yeah exactly. Every time the coinbase transaction is updated, the refund transaction would need to get resigned by the channel partner.