text:
How might you detect if two extended public keys have the same root private key?
Say I derive three extended public keys1 (normal mode):
Parent:
Pubkey: 035f743ee7d73d27e8c80f6b2458e6d4e2a45f3d7dd35c4e4d84ff3d939d09f40c
Chaincode 71d145eec8d031b39107cb7cb9641cc1e8169b6a25b489b157a0af2197717970
Children:
Pubkey: 0317365d2ea4aa79e731fd4f0f6d60bf0ef75a35189a647667eebc9c7323d304d0
Chaincode 9cb9a9fe6e57b62f9a7970649d8dc4633fd9d4b5777a1397a275bd30a88c3111
Pubkey: 0230cdc8f7b84c0998ec182777d9d1f35ea45fe7620e979862c7025b18162108cb
Chaincode 44b54106ea0720a1ac226d598b89297dfe8efd2b7abf75c88761aa6df9c2886b

If I have any two of these three (child-child or parent-child (not knowing which is parent)), is it possible to detect that the keys are related? How would it be done?
If not, what extra information would be required. The child indexes? Signatures from a shared root private key?

See also:
Why the normal mode exist in BIP32
ELI5: What's the difference between a child-key and a hardened child-key in BIP32
BIP32

 1: I used this most excellent write up to create these.

A signature created with the root private key can be used to verify the relationship. You would use the root public key to verify the signature.
To detect if two extended keys have the same root private key, you need additional information such as the child index or signatures from the root private key. Without this information, determining the relationship is not feasible.

This is not possible; quoting BIP32:

Given any number (2 ≤ N ≤ 232-1) of (index, extended private key) tuples (ij,(kij,cij)), with distinct ij's, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (kpar,cpar) such that for each j in (0..N-1) CKDpriv((kpar,cpar),ij)=(kij,cij)), cannot be done more efficiently than a 2256 brute force of HMAC-SHA512.

Given that this is not possible for extended private keys, it is certainly not possible for extended public keys.


text:
allowed DER encoding format violations for signatures in bitcoin: implications for libraries?
I have recently changed verification code in python-bitcointx to use libsecp256k1 library.
In the python-bitcoinlib code (that python-bitcointx is a derivative of), openssl functions were used for signature verification.
I want to be able to remove dependency on openssl in the future, and use only libsecp256k1 in python-bitcointx, but there is a problem that I noticed when I re-wrote CECKey.verify() method:
libsecp256k1 function secp256k1_ecdsa_signature_parse_der() only allows strictly valid DER-encoded signatures.
bitcoind uses ecdsa_signature_parse_der_lax() function, copied from libsecp256k1's contrib/ directory. This function is not compiled in a normal compilation cycle of libsecp256k1.
It is expected for bitcoin-focused library to be able to verify signatures that bitcoind will also verify.
To be able to verify non-strict-encoded signatures with libsecp256k1, I see 3 options:

EDIT: I might just implement two verification methods, strict and non-strict, and then use them in tests. openssl dependency will stay because of verify_nonstrict().

get ecdsa_signature_parse_der_lax() function from libsecp256k1/contrib, add it to python-bitcointx repository, compile at python package build time, install with a package.

This is not desireable, because it adds requirement to have C compiler to build the python package. In some environments this may be inconvenient.

re-implement ecdsa_signature_parse_der_lax() in python

I would like to avoid this, to reduce the size of the code (reduce the surface where bug may be introduced). Porting this function correctly will require to invest some time.
It will also make verification slower to some degree, because more operations will be done in python, vs calling C functions.

do a cycle of decode-with-openssl / encode-with-openssl / decode-with-libsecp256k1

This way all encoding violations that openssl allows are also allowed by first decode-with-openssl. encode-with-openssl then creates valid encoding, and decode-with-libsecp256k1 is happy.
The problem with this approach (in addition to this decode/encode cycle) is that it will allow some format violations that bitcoind won't allow, because ecdsa_signature_parse_der_lax() only allows an arbitrary subset of violations allowed by openssl.
python-bitcoinlib was using openssl to decode, too, so I went with the later approach - decode/encode/decode. This means I cannot drop openssl dependency.
My question is: what may be the implications of this choice ?
What I can see is that when someone uses python-bitcointx or python-bitcoinlib to verify inputs in some transaction, and these inputs contain signatures that is accepted by openssl, but not by bitcoind, they might be convinced that tx is valid, but will have unpleasant surprise when they try to broadcast it.
With some protocols that require parties to store signed transactions, that might be relevant.
As this is historical behavior of python-bitcoinlib, I am inclined to just document this in the README.md as a 'gotcha', and leave it as it is now.
But maybe there is some other potential problems that could arise out of this issue, that may be more serious, and the first or second options described above should be considered ?

It isn't clear to me from your question what your goal is.  If you want to accept all transactions and only transactions that Bitcoin would accept, libsecp256k1 alone is what you want. (You may need to use the signature normalize call if you want to match consensus acceptance instead of standardness acceptance).
If you want to validate historical signatures from the blockchain then either openssl or the code in contrib is sufficient. If you use either of these things on current transactions you will accept things that Bitcoin will reject.
We, the authors of libsecp256k1, are currently of the belief that no application should use a lax parser, except for historical compatibility. Unfortunately, no function is likely to be universally compatible with OpenSSL's parser except OpenSSL itself... but for cases where the set of signatures that you need to be compatible with is known a specific alternative lax parser might work, as is the case for Bitcoin's history and the lax parser in contrib.
The contrib lax parser isn't included in the library because it's only provably sufficient for Bitcoin's history. Someone trying to lax-parse a different set of signatures may need to modify that lax parser to accommodate the specific weird signatures that they're dealing with.  We also, in general, don't think anyone should be lax parsing unless its strictly needed since it can result in surprising vulnerabilities.
As an aside, in the current versions of OpenSSL the ECDSA validator attempts to validate signature encodings by checking that the serialization is unchanged under decode and encode and it rejects signatures that aren't.  This likely means they reject any signature that libsecp256k1 (with normalize) rejects.  [And annoyingly, OpenSSL made this breaking change in a security update.]

I mistakenly thought that lax parser may be still relevant, and this question arose out of that. This was because python-bitcoinlib tests also test script evaluation code for historical, lax-encoded signatures. The tests failed after I introduced strict decoding. Now I added handling for STRICTENC flag (that was missing) and do lax verification when STRICTENC is not specified. Tests with historical signatures now pass. I also added a warning to README that people should not use python-bitcointx's VerifyScript as authoritative source on input validity, because it may not be in-sync with core.

Because I thought that python-bitcointx's VerifyScript might be relied upon by someone to check input validity, I was worried that the differences in handling strict encoding might bite them. I thought that this is the only serious difference b/w this lib and the core. The goal of the question was to understand the scope of the differences to decide how to handle this. It turned out that the differences are huge, and all bets are off - so the warning in README is necessary.

It was the case that python-bitcoinlib's script evaluation code did not handle  SCRIPT_VERIFY_STRICTENC flag.
I had to create additional method, verify_nonstrict(), and make the scripteval use it when STRICTENC flag is not specified.
Handled in https://github.com/Simplexum/python-bitcointx/commit/d8ab8ff76de412f90480c3c68addbbb1791d3413

If you want to guarantee strict DER encoded signatures which are accepted by Bitcoind then they need to be bip66 compliant(low s values(ecdsa malleability), remove leading nulls (encoding malleability)). I am not sure you are guarding for that with your decode-encode-decode cycle. These do not enforce r,s value-space constraints.

low s values are enforced separately, with secp256k1_ecdsa_signature_normalize(). This is about DER encoding (https://en.wikipedia.org/wiki/X.690#DER_encoding) that openssl and bitcoind may treat differently

So you need to ensure for bip66 compliant DER encoding, which is a subset of the standard you linked above, no?

looks like the ecdsa_signature_parse_der_lax() is only relevant to the signatures before activation of BIP66, and I can just go with requiring strict DER encoding. There is some tests in that may fail as a result, but since it is irrelevant, I may just disable these tests.

Still, I do not see where secp256k1_ecdsa_signature_parse_der() is used by bitcoind, and only ecdsa_signature_parse_der_lax(). Need to investigate furter.

Peter Wuille could definitely help, he wrote bip66...

It may be the case of just correcting the tests to use special non-strict verification method. python-bitcoinlib test cases seem to ignore STRICTENC modifiers in test data.

note on my previous comment that secp256k1_ecdsa_signature_parse_der() is not used by bitcoind: it does the checking in IsValidSignatureEncoding()

The parsing code used is always the same, before and after BIP66 activated. The difference is in an extra sanity check before the parser is invoked.

If the signature passes  IsValidSignatureEncoding(), it should always be accepted by secp256k1_ecdsa_signature_parse_der(), or there might be corner cases when such signature might not be accepted by secp256k1_ecdsa_signature_parse_der() ?

It seems that checks are slightly different b/w secp256k1_ecdsa_signature_parse_der() and  IsValidSignatureEncoding():
secp256k1_ecdsa_signature_parse_der have check for "Excessive 0xFF padding", but allows negative integers. IsValidSignatureEncoding do not allow negative integers, and checks only for excessive 0x00 padding.

I will need to use ported IsValidSignatureEncoding() to check for STRICTENC, and cannot just rely on secp256k1_ecdsa_signature_parse_der(), to be compatible with bitcoin's script interpreter.

source: Stack Exchange

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

sort: votes


text:
Why is OP_XOR disabled? Are there any forks on which it has been enabled?
Why is OP_XOR disabled?
Are there any forks on which it has been enabled?
Are there any plans to enable it?
Perhaps this is the answer, still perhaps there is another reason for the bitwise logic functions being disabled...

I think the answer you linked does answer your question too.

So far as I can tell:
OP_XOR is not implemented in BTC.
OP_XOR is implemented on BitcoinABC and subsequent forks of that (e.g. BCH, BSV), but P2SH has been depreciated on BSV:

P2SH – Pay to Script Hash (deprecated with the Genesis upgrade after
Feb 4th 2020)

from wiki.bitcoinsv.io

P2SH can be implemented with existing opcodes in the Script https://xiaohuiliu.medium.com/sun-rising-p2sh-7ebfca9283aa.

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


text:
What are the transactions included in the merkle root
I am trying to understand the block hashing algorithm used to generate block.
One of the points mentioned here is

it is (nearly) impossible for two people to have the same Merkle root because the first transaction in your block is a generation "sent" to one of your unique Bitcoin addresses.

How do I specify my unique address? Does it depend on what kind of miner I use and whether I mine in a pool?
Also what is "generation" and how is it different from other transactions that include transfers of bitcoins? What other transactions are included in the Merkle root?

How do I specify my unique address?

You don't need to. Bitcoin will add the coinbase transaction automatically.

Does it depend on what kind of miner I use

No.

and whether I mine in a pool?

Yes, because then the pool gives you a block header to mine, which includes their coinbase transaction. If you put in your own coinbase header, then the pool will reject your shares.

Also what is "generation" and how is it different from other transactions that include transfers of bitcoins?

Just like a normal transaction, it specifies how the money can be spent, but unlike normal transactions, it doesn't need to provide any inputs. However, the amount transferred must be equal to the total transaction fees plus the block subsidy.

What other transactions are included in the Merkle root?

Every valid transaction that your bitcoin client knows about is included.

I suppose that the pool gives different headers which include different transactions to pool members. Right?

I'm not sure what you mean by that - the coinbase transaction is different, because the pool doesn't want multiple miners to duplicate work. But in all cases, the coinbase transaction gives the bitcoins to the pool. Actually solving a block is worth just as much to the individual miner as solving a share.

What happens to the transactions that are not included. Are they included in future blocks?

Sometimes. Maybe those transactions are forgotten. It's called the "memory pool" for a reason - it's forgotten on shutdown.

I suppose that the pool gives different headers which include different transactions to pool members. Right? Maybe that should be a different question but what happens to the transactions that are not included. Are they included in future blocks?

@konpsych I edited my answer to add your questions.

I did not realise that the coinbase transaction is different although it is given by the pool. However, even if the transactions are forgotten by my memory pool are they lost? I thought the purpose of mining is to organise all the transactions into blocks. Am I missing something?

@konpsych This is by design. Transactions that don't make it into a block will eventually be forgotten.

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


text:
Eliminating all private keys records from pc
Suppose I buy a new wifi router and a new pc. I set up both the wifi network (of course, with a password) and the pc.
Now I access the internet for a few seconds in order to download bitaddress.org from GitHub or as an HTML file. Then I turn off the wifi connection on my pc and open the downloaded file and generate many pairs of public and private keys (which I write down on paper). Once I'm done, I clear the web browser history, cache, cookies, etc. and delete the downloaded files.
Would this be enough to make sure no records of the keys of any kind are left anywhere on the pc? Should I restart the pc before turning its wifi connection back on again? Or should I reinstall the operating system just in case? Or would it be a good idea to install Deep Freeze before generating the keys?
I'm planning to continue using my pc for my daily work.
Thanks in advance!!

What you describe has some risks:

The new PC and router likely won't have the latest software updates, which could increase the chance of it being compromised immediately
The bitaddress.org website may have been compromised, in which case it may generate pre-determined addresses that are monitored for stealing coins deposited to them. This is a real and significant risk that you should take steps to avoid.

I suggest that you look at a process like this:

Download a copy of the bitaddress.org page and store it on USB.
Open it from a cleanly booted offline PC, perhaps from a live linux CD, or even better, from a permanently offline PC.
Verify the bitaddress.org code (I'm not going to cover this here; it would make a good separate question perhaps)
Generate your private keys

So, you suggest that I make sure both the router and the PC have the latest software updates before taking any further steps, right? Besides, where can I get the Linux CD from? On bitcoinpaperwallet.com one can buy the CD with bitcoinpaperwallet.com generator pre-installed. Should I just buy it there?

Whatever technology you choose to use, you need to be confident that it hasn't been tampered with. It seems more likely that a Bitcoin-specific tool would have been targeted than one that isn't, such as https://help.ubuntu.com/community/LiveCD but if you trust the developers of bitcoinpaperwallet.com then it could be a good option. Do your homework if you're storing any substantial amounts.

Is the link you've posted where I can get the CD from? Or do you know where else I can get it or if I should make my own CD?

Maybe you can also answer this question, which is about verifying the code and authenticity of bitaddress.org. I think the only answer to that question so far is good but a little too technical. I'll choose your answer as the best if I can understand all these complicated things.

Just deleting your cookies is enough, Or you can use incognito mode on your browser, So when you close the browser all the records will be deleted.

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


text:
How can I verify the PGP signature of https://liteaddress.org on Windows?
Suppose I want to download a copy of https://liteaddress.org in order to run it offline in a safe environment. Then how can I verify that the website hasn't been hacked? How can I verify that the downloaded copy is legitimate and not compromised?
The website explains this:

If you are familiar with PGP you can download this all-in-one HTML page and check that you have an authentic version from the author of this site by matching the SHA256 hash of this HTML with the SHA256 hash available in the signed version history document linked on the footer of this site.

I have just started to read what PGP is because I don't know what PGP and SHA256 hash even are and how they work.
My knowledge of computers is very basic. I mean, I know how to use a computer, but PGP, SHA256, etc. are too technical for me.
Can someone explain to me step by step (assuming my knowledge regarding these topics is zero) how to verify the PGP signature of liteaddress.org?

Well it seems like the devs haven't updated the SHA256 for liteaddress.org since 2015-01-08, so every commits after that date cannot be verified.

@Chak so, does this mean that the PGP signature of liteaddress.org can't be verified?

In this case SHA256 of liteaddress.org cannot be authenticated. PGP acts more like a verification of "messages/emails/text". I would say that downloading from their GitHub repository is more safe/secure than download liteaddress.org, either way we wont know if any of them are compromised. However I checked their last commits since 20/07/15, and found nothing malicious. So I will deem their GitHub repository as safe for now, as long it is used offline.

@Chak thanks! And what's the difference between PGP and SHA256? And what is "commits"?

Well is a bit complicated hmmm....   Simply explained SHA256 is mostly used for hashing, while PGP is more an encryption algorithm. SHA256 is designed so that it's (almost)impossible to turn a hash back into its original string. PGP on the other hand can easily be reversed back into its original decrypted form if you have the public key.

Commits are related to GitHub, for example when codes have been altered or new codes added, programmers have to "commit" it so the current contents get saved. Simply put, it is like clicking "save" after editing a document.

These steps can be simplified if you use UNIX, as most of the tools are already available. However I assume you use Windows.
For PGP explanation, search for videos on youtube.
These steps are for the webpage bitaddress.org.
For the PGP part:
1. Download and install Gpg4win.
2. Go to bitaddress.org and click on the link at the bottom to go to Github Repsitory.
3. On their Github page, click on 'CHANGELOG.txt.asc', then click on the 'raw' tab.
4. Right-click and save as.
5. Run Kleopatra(Gpg4win).
6. Click on Decrypt/Verify tab.
7. Find the CHANGELOG file you just downloaded and 'open'.
8. Now click on the 'search' tab, since you are missing the public key to verify the message.
9. The public key for ninja should have been found, click to import it.
10. Click OK/YES when asked to certify the fingerprints, we know it is the correct ones since the key fingerprint is posted on https://bitcointalk.org/index.php?topic=43496.0 .
11. You will be asked to create a account, click yes.
12. Type whatever you want(not important).
13. Create a simple password.
14. Click 'finish'.
15. Select all the IDs, and then tick the box ' I have verified the fingerprint'and next.
16. Click certify.
17. Enter the password you just created.
18. You will get certification successfull, click finish.
19. Now you will be shown if the contents inside CHANGELOG is valid.
20. If you get "The signature is valid and the certificate's validity is fully trusted." Then we know that the file content is authentic and hasn't been tampered with.
21. So now we know that the file CHANGELOG.txt.asc inside their Github is authentic. We can process to the SHA256 part.
For the SHA256 part:
1. Go to bitaddress.org and right-click and save as 'Webpage HTML only'
2. Download and run QuickHash.
3. In QuickHash go to 'file' tab and select SHA256 as Hash Algorithm.
4. Click 'Select File' and select the html file you just downloaded.
5. A SHA256 HASH value will appear.
6. Now go to bitaddress.org again, and at the bottom of the page click at the link to GitHub Repository.
7. Once in their GitHub, click on the file 'CHANGELOG.txt'.
8 At line 29 you will find
"bitaddress.org-v3.3.0-SHA256-dec17c07685e1870960903d8f58090475b25af946fe95a734f88408cef4aa194.html".
9. Do the "dec17c07685e1870960903d8f58090475b25af946fe95a734f88408cef4aa194" match with the SHA256 you got from QuickHash?
10. If matched, then the HTML you dowloaded is valid and authentic, if not, then something sketchy is going on.


text:
Safely generating Bitcoin paper wallets
I'm new to Bitcoin and I have recently purchased a few fractions of Bitcoin. My BTC are stored on what I understand is an online wallet (a website where I log in using two-factor authentication and where I can buy/sell BTC as well as send/receive BTC). The problem is that my BTC are stored online, which means that they could be potentially exposed to threats like hackers, viruses, technical problems, the website going down, fraud, etc. So, after having searched for other options, I decided that the most secure way of storing BTC would be on a paper wallet.
Creating a paper wallet at bitaddress.org doesn't seem to be that difficult, but of course one has to be sure that the public and private keys are being generated in a completely safe, malware-free environment. Many advanced users employ what are to me very complicated techniques for generating such keys, such as booting the operating system from a pendrive, using Ubuntu, Tails and many other programs and procedures I'm not at all familiar with. Other users just make sure the computer is clean, go to bitaddress.org and then turn off the internet connection before generating the keys. Others save bitaddress.org as an html file and then open that file offline to generate the keys, while others download a copy of bitaddress.org from github and open that copy offline to generate the keys.
Even after having read about BTC, the BTC world is still very complicated to me, so here come the questions:
1) What if I restore my wifi router to factory settings and set it up with a new wifi password and then buy a new computer, access the internet through wifi just for a few seconds just to go to bitaddress.org (and no other web) and then go offline to generate the keys? Would this be a completely safe environment to generate the keys? I can't think of anything cleaner than a recently bought computer. How could I make sure no sensitive information about the keys gets stored anywhere on the computer or web browser after having generated them? This is important because I'm planning to then use my computer for daily work, so I will generate many different wallets at once and then probably never use the same computer again to generate more wallets.
I have read somewhere that one can download a copy of bitaddress.org to a pendrive and then open that website on a computer that "has never touched the internet", but I think that opening bitaddress.org online for a few seconds on a recently bought computer should be a more secure way.
Also, would it be a good idea to connect my computer to the internet by using my cell phone as a router, that is to to say, by using the cell phone's cellular data connection instead of wifi? I think a cell phone's connection to the cellular network should be more difficult to hack than a wifi connection, but anyway cell phones may also have viruses, so I'm not 100% sure what I should do.
2) Why is it that some people prefer not to choose the first generated pair of keys (at bitaddress.org) but instead generate further pairs to choose from?
3) bitaddress.org generates a public key and a private key. Is this public key the same as the BTC address?
4) What are the differences between the different types of wallets offered at bitaddress.org?
5) How can I make sure I'm accessing a legitimate version of bitaddress.org. In other words, how can I make sure no hacker has modified something at bitaddress.org in order to be able to capture generated keys? (I have read somewhere something about computing the "hash" or something like that.)
6) Is there a limit to the number of BTC I can send to/store in a particular address? Can one send any fraction of BTC to a particular address?
Thanks in advance!!

Very good questions, and you've clearly done your research! However, the 6 questions listed need to be asked separately as the collection as a whole is far too broad to make this site's voting system work as intended. For this reason, I'm voting to close this, but I look forward to seeing these asked separately.

Thank you for having taken the time to read all this! I'll post each question separately then.

@Highly Irregular I have posted a few questions separately. Maybe you can help me with your knowledge


text:
How does SpeedyMuSig compare to MuSig2?
This paper (Crites, Komlo, Maller) on the security of Schnorr multisig and threshold signature schemes introduces a new variant of MuSig2 called SpeedyMuSig that includes proofs of possession and faster key aggregation.
As the paper states:

This is because proofs of possession allow the aggregate public key under which the multisignature is formed to be simply the
product of the signers’ individual public keys. It involves group multiplications instead of costly group exponentiations and
remains secure against rogue-key attacks.

What are the downsides or costs of SpeedyMuSig in comparison to MuSig2?

SpeedyMusig requires each signer to collect all n nonce pairs (Ri,Si) as input to the hash which determines how they are combined for the final nonce.  Musig2 allows a single untrusted aggregator to collect the (Ri,Si) for all n signers and send only the aggregate (R,S) to each signer.  So, SpeedyMusig requires O(n^2) communication, whereas Musig2 can be done in O(n) with a dedicated aggregator.
However, I am not sure the security is the same.  SpeedyMusig says the signer much check the list (Ri,Si) to insure that no pair occurs more than once, in order for their security proof to be valid.  If this check is also needed for Musig2, then the O(n) communication pattern would depend on the supposedly untrusted aggregator to do this correctly.
Musig2 uses more complicated public key aggregation, requiring n exponentiations, to solve the rogue key problem, whereas SpeedyMusig has simple key aggregation under Verified Key model.  I am not sure if this interacts with the above issue somehow, or whether there is alternative security proof or some other aspect of operation that doesn't need the "no duplicates" assumption.
For myself, I would really like to combine these 2 approaches, using the O(n) nonce aggregation pattern of Musig2 but with the simple public key aggregation of SpeedyMusig.

(Disclosure: I'm one of the authors of the MuSig2 paper.) I'm pretty sure that the two mentioned drawbacks in SpeedyMuSig (less flexible nonce aggregation and rejecting duplicate nonces) are artifacts of the proof technique used by CKM, and the scheme would be secure with O(n) nonce aggregation and without the check for duplicate keys. Disclaimer: As long as we don't have a proper proof that establishes the security of the modified, "I'm pretty sure" is not a formal proof and there can be dragons. Don't implement a scheme because someone said in comment on StackExchange that it's secure.

Thanks @real-or-random, would you have any thoughts on musig2 + BIP-32 style nonces?  https://bitcoin.stackexchange.com/questions/115036/musig2-with-bip-32-style-nonce-chain

There is a comparison table included in the Crites, Komlo, Maller paper.

The only downsides (included in the table and the paper) of SpeedyMuSig are the additional group exponentiations in the KeyGen phase and KeyVerify phases.
The MuSig2 paper (Nick, Ruffing, Seurin) does address the proof of possession approach:

One way to generically prevent rogue-key attacks is to require that users prove possession of
the secret key, e.g., by attaching a zero-knowledge proof of knowledge to their public keys [RY07;
BDN18]. However, this makes key management cumbersome, complicates implementations, and is
not compatible with existing and widely used key serialization formats.


text:
Why does only one of the two nonce points in MuSig2 have the exponent b?
In MuSig2 R''_i is added to itself b times (in multiplicative notation, it has the exponent b) but R'_i is not (it does not have the exponent b).
Why does only one of the nonce points have the exponent b and not both? I was expecting:
R_i = (R'_i.R''_i)^b
I'm assuming it saves on exponentiations and somehow offers the same security (because b is hashing both R'_i and R''_i)?
(R_i is the generator point G added to itself r_i times where r_i is the nonce. Or R_i = g^r_i in multiplicative notation.)
The following is taken from Tim Ruffing's slides at Real World Crypto 2021:

A slight variant of MuSig2, named MuSig2*, sets one of the coefficients to 1 to make the key aggregation function slightly more efficient. This is described in a draft specification of MuSig2 : ↩

MuSig2* optimization: The specification uses an optimization that allows saving a point multiplication in key aggregation. The MuSig2 scheme with this optimization is called MuSig2* and proven secure in the appendix of the MuSig2 paper. The optimization is that the second distinct key in the list of public keys given to the key aggregation algorithm (as well as any keys identical to this key) gets the constant key aggregation coefficient 1.

I was myself confused by this when writing my blog post about MuSig2.
This trick resembles normalization of a polynomial, which is accomplished by dividing each term by the first terms' coefficient.


text:
Handling 'Has SIGHASH_SINGLE' flag for psbt2 (BIP370)
BIP370 specifies a bit flag (bit 2) in PSBT_GLOBAL_TX_MODIFIABLE field, that "indicates whether the transaction has a SIGHASH_SINGLE signature who's input and output pairing must be preserved" and "If the Has SIGHASH_SINGLE flag is True, then the Constructor must iterate through the inputs and find the inputs which have signatures that use SIGHASH_SINGLE. The same number of inputs and outputs must be added before those inputs and their corresponding outputs"
BIP370 does not specify how to handle this flag in other situations, when the inconsistency of the flag with other fields can indicate some problem and it may be best to somehow react to this problem rather than ignore it.
For example, the code that parses PSBTv2 may find that 'Has SIGHASH_SINGLE flag' is false in PSBT_GLOBAL_TX_MODIFIABLE, but later, when processing the input fields, finds out that one of psbt inputs has SIGHASH_SINGLE.
How the code should react to this ? This is obvious inconsistency, if this situation is ignored, and the 'Has SIGHASH_SINGLE flag' is considered false despite the presence of SIGHASH_SIGNGLE in the inputs, the signatures can be invalidated when moving inputs or outputs.
Likewise, if the flag is true, but there are no inputs having SIGHASH_SINGLE sighash types, should this be taken as an indication of inconsistent PSBT ?
Can we say "this flag is always equal to any(input.has_sighash_single() for input in psbt.inputs)" (1) ?
PSBT_IN_SIGHASH_TYPE is not required to be present, and if it is absent, signer "may use any sighash type they wish". But let's imagine that BIP text would state that PSBT_IN_SIGHASH_TYPE must always be present if SIGHASH_SINGLE is to be used. Will (1) be true in this case ? Would we even need this flag then ?
Should say that 'Has SIGHASH_SINGLE' flag is to be ignored if there are finalized inputs  because any adding of inputs must have been done before finalization ?
How would it be possible to check the finalized inputs for the use of SIGHASH_SINGLE signatures in case of finalized inputs when custom scripts are used with unknown format for the witness data ?
BIP174 says that on finalization, finalized scriptSig and scriptWitness should remain, and "All other data except the UTXO and unknown fields in the input key-value map should be cleared from the PSBT"*. If PSBT_IN_SIGHASH_TYPE is cleared, there's no way to know in general if the witness has signatures with SIGHASH_SINGLE, unless the code can somehow understand the format of the witness.
* By the way, this wording should include not only unknown fields, but proprietary fields, too should be preserved. Should I make PR to add this ?

By the way, the 'Constructor' section in BIP370 talks about looking for 'inputs that have signatures', and at the same time talks about checking timelocks and SIGHASH_SINGLE on the inputs. This seems to be a reference to BIP371 that defines special fields for signatures. But this is a forward reference that cannot be understood without reading BIP371 first, and such checks cannot be done on finalized inputs (because all those fields would be already removed on finalization)

I forgot that there's PSBT_IN_PARTIAL_SIG that has signatures that Constructor can look at.

Figuring out how to handle SIGHASH_SINGLE inputs in PSBTv2 was one of the major problems when designing it. Unfortunately, when this was brought up on the mailing list, there was little to no response, and so the result was that I had to try to come up with a solution myself, which may be slightly deficient.

For example, the code that parses PSBTv2 may find that 'Has SIGHASH_SINGLE flag' is false in PSBT_GLOBAL_TX_MODIFIABLE, but later, when processing the input fields, finds out that one of psbt inputs has SIGHASH_SINGLE.

The expectation is that such an inconsistency would not occur because it is in the Sginer's best interest to make sure that the Has SIGHASH_SINGLE flag is set when they add a SIGHASH_SINGLE signature. There is no need for anyone to be checking that no other signatures are SIGHASH_SINGLE, and so the expected action is that the inconsistency is ignored. This could result in an invalid transaction, but that is an allowed outcome.

Likewise, if the flag is true, but there are no inputs having SIGHASH_SINGLE sighash types, should this be taken as an indication of inconsistent PSBT ?

Yes, but setting when there are no SIGHASH_SINGLE signatures does not necessarily cause harm other than making adding additional inputs slower.

Can we say "this flag is always equal to any(input.has_sighash_single() for input in psbt.inputs)" (1) ?

That is the intention.

PSBT_IN_SIGHASH_TYPE is not required to be present, and if it is absent, signer "may use any sighash type they wish". But let's imagine that BIP text would state that PSBT_IN_SIGHASH_TYPE must always be present if SIGHASH_SINGLE is to be used. Will (1) be true in this case ? Would we even need this flag then ?

There is no real need for the flag other than as an optimization. It exists in order to allow Constructors to skip having to inspect every input, but if the flag did not exist, it could simply have been that Constructors must check every input for SIGHASH_SINGLE signatures. So if PSBT_IN_SIGHASH_TYPE were provided for every input, Has SIGHASH_SINGLE would still be a used.

Should say that 'Has SIGHASH_SINGLE' flag is to be ignored if there are finalized inputs  because any adding of inputs must have been done before finalization ?

No, it is possible that an input is finalized while additional inputs are being added. The use of SIGHASH_SINGLE & SIGHASH_ANYONECANPAY allows for this.

How would it be possible to check the finalized inputs for the use of SIGHASH_SINGLE signatures in case of finalized inputs when custom scripts are used with unknown format for the witness data ?

A script interpreter would be needed. The process would be to execute the finalized scriptSigs and scriptWitnesses with a signature verifier that can report whether it had to verify any SIGHASH_SINGLE inputs. Part of the reason that Has SIGHASH_SINGLE was added was because I thought it was unreasonable that Constructors had to have a script interpreter just to make sure that they weren't breaking any SIGHASH_SINGLE things.

* By the way, this wording should include not only unknown fields, but proprietary fields, too should be preserved. Should I make PR to add this ?

Proprietary fields are generally lumped together with unknown fields because they are unknown to implementations that do not implement those specific proprietary fields. But yes, the text could be clarified.

So if the Constructor that adds inputs does not have a script interpreter, and 'Has SIGHASH_SINGLE' is true, it should treat any finalized input that it cannot analyze, as having a SIGHASH_SINGLE signature.

@DmitryPetukhov Yes, that would be a reasonable thing to do (assuming it is not SIGHASH_ALL, but if it were, then the tx should not be modifiable).


text:
and(older(10),pk(A)) malleable if top-level, can it be top-level? EDIT: not malleable, was mistaken
$ ./miniscript

and(older(10),pk(A))
X    110.0000000000    37 and_v(v:pk(A),older(10)) and(older(10),pk(A))

and_v(v:pk(A),older(10))
      1 scriptlen=37 maxops=2 type=B safe=yes nonmal=yes dissat=no input=1n output=nonzero miniscript=and_v(v:pk(A),older(10))
<A> OP_CHECKSIGVERIFY 10 OP_CHECKSEQUENCEVERIFY

(the last line shows the compiled script because I added printf("%s", Disassemble(ret->ToScript(COMPILER_CTX)).c_str()); to the command line-based tool output)
AFAICT nothing says that this cannot be top-level (but I may be missing something). It also says nonmal=yes, that this is not malleable.
The witness that is needed for this script to be successfully executed in the spending check is [<A_signature>, <any-nonzero>], and of course the CHECKSEQUENCEVERIFY condition must pass. The CHECKSIGVERIFY will consume <A_signature>, and then <any-nonzero> will be checked as the sole item on the stack, that indicates success (after CastToBool())
But <any-nonzero> can be just that, anything, and thus malleable.
What am I missing ?

OP_CHECKSEQUENCEVERIFY is a redefined OP_NOP code, so it cannot manipulate the stack - only abort or continue. In your script, that means it leaves the 10 on the stack, and no <any-nonzero> is necessary in the witness (and adding one would be a violation of the CLEANSTACK standardness rule).

Oh right, my mistake. It seems that I was looking at CHECKSIGVERIFY code that pops the arg, and thought that I was looking at CHECKSEQUENCEVERIFY.


text:
Verifying a legitimate version of bitaddress.org on Windows
How can I make sure I am accessing (online) or have downloaded (as an HTML file or from GitHub) a legitimate, trustworthy version of bitaddress.org?
In other words, how can I make sure no hacker has modified something at bitaddress.org or in the GitHub files in order to be able to capture generated keys?
I have read somewhere something about computing the "hash" and/or "verifying the signature" or something like that. I'm not at all familiar with all this.
I think the same question would apply for bitcoinpaperwallet.com, too.

Are you using Windows? (To verify the hash)

Yes, I use Windows.

1) Google how to verify a PGP signature
2) Import author's PGP sig (from the main Web site), use procedure from 1) to verify contents of
https://www.bitaddress.org/CHANGELOG.txt.asc (and obtain SHA256 sum of the latest release, although you can get that from Github as well)
(If you trust Github and want to use an offline copy, you could skip 1) and 2) and just get the latest release from Github)
3) Download the latest release, unzip and calculate SHA256 sum of the main (bitaddress.org.htm) HTML file, compare with SHA256 sum in the URL or downloaded CHANGES.txt.asc file:
sha256sum.exe bitaddress.org.html
dec17c07685e1870960903d8f58090475b25af946fe95a734f88408cef4aa194  bitaddress.org.htm
If you skipped step 2), you can perform it in step 3 using the downloaded ZIP archive.
For checksum, use a utility you want (or two, in case you don't trust one). One example:
http://www.labtestproject.com/files/win/sha256sum/sha256sum.exe


text:
How to distinguish between change and actual sent amount looking at transaction data
I am building analytics starting from blockchain raw data (blk**.dat files).
I have read in the bitcoin wiki that once the inputs have been chosen for a transaction, they must be all used: so a change is generated back to the original sender (via the same address or a different change one, depending on the client configuration).
While building analytics, I would like to exclude these outputs from any kind of metric, since they let the coin work but do not represent any intelligence at all.
Is there a way to looking at the outputs of a transaction and split them into meaningful sent amounts and change?

The whole point of having change explicit in the first place is making sure people can't (trivially) do this kind of analysis!

There is no way to know with certainty which output is the actual spend, and which is the change, without being involved in the transaction yourself. It is possible to infer this though, consider the following:
Transaction 'X' has 2 inputs (0.5, 0.5), and 2 outputs (0.7, 0.3). Logically, we can infer that the larger output (0.7) is the spend, because if the spend was the 0.3 output, the user could have saved costs by just using one of the 0.5 inputs to send the transaction.
However, it is possible for users to purposefully transact in a less efficient way, in order to obfuscate their spending habits, so you can never be absolutely certain.

Thank you very much, that is was I was looking for - a definite clause. Do you happen to have any external resource for that? This constraint will be included in a paper or similar, and I could use that. Or does it happen to be on the wiki and I totally missed it?

I don't have an external resource, sorry. The system is designed to obfuscate this sort of data though, so if you're looking for a hard reference on how to elucidate this info, I'm not sure one exists. At any rate, even the best inference would not be absolutely conclusive in just about every case, you'll be playing a guessing game within some self-defined confidence bounds.


text:
How to derive segwit addresses from an extended public key?
I tried to use the following code:
    DeterministicKey key = DeterministicKey.deserializeB58(null , "xpub...", MAINNET);

    DeterministicHierarchy hierarchy = new DeterministicHierarchy(key)
;
    DeterministicKey chain = hierarchy.deriveChild(key.getPath(), false, false, new ChildNumber(0, false));
    DeterministicKey index = hierarchy.deriveChild(chain.getPath(), false, false, new ChildNumber(0, false));
    SegwitAddress segwitAddress = SegwitAddress.fromHash(MAINNET, index.getPubKeyHash());

But it doesn't return correct address.
Any help here

Zpub's would be needed for native segwit addresses. And current bitcoinj master branch does not support Zpub, it support xpub and xpub's would always derive to
legacy addresses. Give a try to Segwit branch that may helps. Also take a look at this

Your problem seems similar to the given link:
https://groups.google.com/forum/#!topic/bitcoinj/F7smdvlCbnE
Try to use bitcoinjs for the same extended public key. or try the provided solutions.
Hope this will work in your case.

how to use bitcoinjs for extended public key in java?

You can use this Python library.
from btctools import Xpub

>>> extended = Xpub.decode('xpub123...')
>>> child = extended/0/0
>>> child.key.to_address('P2WPKH')
'bc1q0xedk29m3z0ja0l5xl2avclrhkd8y9z5au5wyt'

how can use this python lib in java ?


text:
How to Send BTC from my address to another using private key
I am working on project of ICO where i am generating dynamic address for Bitcoin receive purpose, I have private key for my account how i can send it to other address which API will be helpful to me.
I am not using any bitcoin wallet, I don't think wallet is required for this.

I am not sure about this, can anyone guide me on this. I am a new to
  bitcoin.

I have worked with this hard and come to the conclusion that we can achieve this by block monitor. This will be easier than all other options.

What is block monitor? How is it easier than other options?

If you don't want to use any wallet software, you could install bitcoind on your local host and
https://stackoverflow.com/questions/38493893/heres-how-to-send-raw-transaction-btc-using-bitcoin-cli-command
You could use an online version of bitcoind RPC endpoint, but I am not sure you want to submit your private key over the network.


text:
Get value from leveldb bitcoin using node.js?
I request information about the block 100001 using leveldb and node js.
Below is my code example.
var level = require('level');
var db = level('E:/download/blockchain/block');
var str = '630010ec274a07f88f9b407da4753f91e15ee6bdf52f0bbc0dfc0dadb6815a6c24';
db.get(new Buffer(str, 'hex'), {
    encoding: 'binary'
}, function (err, value) {
    if (err) {
        console.log(err);
    } else {
        console.log(value);
    }
});

And i get this answer:
���Zl$]
    at E:\Work\Crypto\node_modules\levelup\lib\levelup.js:164:15
    at E:\Work\Crypto\node_modules\encoding-down\index.js:51:21

Why is this code throwing an exception, I can't understand. A little help will be appreciated, Thanks

looks like it's outputting binary, you need to change the output format?  Maybe change encoding?

Are there any assumptions?

Bitcoin's leveldb is serialized, why not use RPC to parse each block, then each transaction? I don't believe the structure of leveldb is in a format that would allow you to get any useful information just by reading the raw bytes.

Thanks for the answer. Do you think that this will not take much time? I just need to scan a lot of addresses for the transactions that come to them.

If you want to learn about transactions affecting certain addresses, make the wallet watch for those addresses. There is no information per address available in Bitcoin Core's LevelDB database, plus if you do this kind of thing while Bitcoin Core is running you may corrupt the database. It is not designed to be usable or useful for any other applications, or any purpose besides validating transactions.


text:
One to many transactions on the Lightning Network, practical approach/limits?
One to many transactions on the main chain are limited by the block size/tx limit size.
Does the same limitation apply on the Lightning Network?
What would be the best approach for 1-N transactions on the Lightning Network?

a. open N channels with individual 1-1 transactions
b. create a huge 1-N tx
c. combination of above

Is there a practical limit to N (order of magnitude; 10s 100s,1000000s?)
My current understanding is that the number of channels is limited by the tx throughput of the main chain (2 tx per channel setup). A rough working assuming 2000 channel initiation transactions per block on main chain means that 1000 channels per block can be created. So for N==1000000 that is 1000 blocks (~1 week)...But once those channels are initiated, the network forms a mesh and transactions are only limited by deposit levels.. Do I have this ~correctly?
If above is correct, does a compromise approach for a lightning app exist? Perhaps that allows key holders within the app to somehow nominate channel operators to act on their behalf?

Channel Factories: https://wiki.ion.radar.tech/tech/research/channel-factory

https://bitcoin.stackexchange.com/questions/67158/what-are-channel-factories-and-how-do-they-work

Today transaction throughput on the Lightning Network is mostly limited by available liquidity, network topology and direction of payments. It is possible longer term if Lightning becomes widely adopted that block size/weight and onchain transaction fees will add an additional constraint as you do need an onchain transaction to open or close a channel. However, today blocks mostly contain single signature transactions rather than Lightning channel opens and closes and so that constraint isn't being hit today.
To briefly explain liquidity, network topology and direction of payments. If you want to route a 10,000 BTC payment on Lightning you are going to struggle because there isn't sufficient capacity in channels to route such a large payment. If you want to make a payment to a very poorly connected Lightning node at the edge of the network you may struggle to find a route to that destination. And if all Lightning payments are being sent in one direction and Lightning channels become highly unbalanced then you may encounter a lot of routing failures if you try to make a payment that is also going in that same direction. All of these can be addressed using onchain transactions to open more channels, add more capacity to channels or rebalance channels but could pose difficulties in the short term.

My current understanding is that the number of channels is limited by the tx throughput of the main chain (2 tx per channel setup).

Every new channel needs a single onchain transaction sending Bitcoin to a 2-of-2 multisig address.

So for N==1000000 that is 1000 blocks (~1 week)...But once those channels are initiated, the network forms a mesh and transactions are only limited by deposit levels.. Do I have this ~correctly?

Yes, block space provides an upper limit on how many channels can be opened and closed but that limit is not close to being hit at the time of writing (September 2022). Once channels are opened the transaction throughput is theoretically infinite. For example we could send a payment back and forth in a channel an infinite number of times and technically that would be an infinite number of transactions. In practice you wouldn't want to do that but other variables come into play (liquidity, network topology, direction of payments etc) other than merely block space.

Perhaps that allows key holders within the app to somehow nominate channel operators to act on their behalf?

There are different models for delegating responsibility either in trusted setups or more trust minimized setups. Obviously you could pay to use a channel operated by a company rather than opening your own channel but that is entirely trusted. If you want your own channel and not to have to trust a third party you can't get around the requirement for an onchain transaction. Longer term there are proposals for channel factories etc where a single UTXO is backing multiple channels but they are not spec'ed and implemented at the time of writing (September 2022).


text:
Divide unknown future input amount sent to a given address amongst known recipients in known proportions?
Is there a way to divide an unknown future input amount received by a given address amongst three recipients with proportions of, for example 0.2 , 0.3, 0.5?
This would need to be done in such a way that one could send an amount and be sure that it will be divided in this way.
It would not matter if the transaction was "blank cheque"/repeatable as described here.

No. You can't impose restrictions on where a current UTXO moves (without covenant functionality that isn't enabled on Bitcoin today) let alone impose restrictions on where a future UTXO moves.

Thanks, slightly updated q (input rather than output). Another way of asking - is tx input amount able to be referred to by the script?

.. and perhaps that would only work if OP_DIV or OP_MUL enabled

Apologies, updated again, removed UTXO ref, I now get that UTXOs are referenced by hash and so you can't "send to an input".. answer still no I think.

No there's no opcode that refers to the amount in the UTXO. You could create a transaction spending to the three recipients with the three stated proportions, not broadcast it and then delete the private keys so no other transaction can be constructed that spends that UTXO. At the moment that's the only way of doing something like this.

I see, you broadcast the tx after deleting keys else would burn the coins?

Only if you lost the transaction that you were meant to broadcast at some later point. As long as you store it safely you can broadcast it later at the time of your choosing.

As Michael already explained, it is not possible to make a transaction that spends unknown UTXOs since a transaction must state which outputs it consumes. Such a functionality could be partially enabled by e.g. sighash_anyprevout (BIP118) which identifies the spent input by the scriptPubKey rather than identifying a specific UTXO, but even then you'd need to know the expected value of the UTXO in advance, as the output amounts are predetermined.
A practical solution might be to run an automated process which regularly checks if there is a balance on the online service's wallet and then creates a transaction which splits the funds in the pre-defined proportions to the receivers. The receivers would then trust this service for the duration until the wallet is swept not to steal or compromise the funds.


text:
Using bitcore-p2p and bitcore-lib to get block data
I've prepared a Nodejs javascript script to (attempt to) fetch block information for an example testnet block (3) from the P2P network, using bitcore-p2p library (which uses the getdata P2P protocol, also this):
let p2p = require('bitcore-p2p')
let Pool = p2p.Pool;
let Networks = require('bitcore-lib').Networks
let Messages = p2p.Messages
let pool = new Pool({network : Networks.testnet})
const endianness = require('endianness')

/* pool will receive "I'm here" peerinv messages from peers, respond with block request" */
let blockrequestcounter = 0
pool.on('peerinv', (peer, message) => {
  console.log('peerinv message: ',message)
  if (blockrequestcounter < 5) { //limit to 5 requests
    let exampleBlockHash = Buffer.from('000000008b896e272758da5297bcd98fdc6d97c9b765ecec401e286dc1fdbe10','hex') // block 3 in testnet
    endianness(exampleBlockHash,32) // flips endianness
    let message_out = new Messages({network:Networks.testnet}).GetData.forBlock(exampleBlockHash)
    peer.sendMessage(message_out)
    blockrequestcounter += 1
  }
})

/* Monitor other messages from pool peers; */
pool.on('ready', ()=> { console.log('ready')})
pool.on('error', (err) => {console.error('Error: ',err)})
pool.on('inv', (peer, message) => { console.log('Received inv: ',message)})
pool.on('alert', (peer, message) => { console.log('Received alert: ',message)})
pool.on('block', (peer, message) => { console.log('Received block: ',message)})
pool.on('merkleblock', (peer, message) => { console.log('Received merkleblock: ',message)})
pool.on('peermerkleblock', (peer, message) => { console.log('Received peermerkleblock: ',message)})
pool.on('peertx', (peer, message) => { console.log('Received peertx:',message)})
pool.on('getblocks', (peer, message) => { console.log('Received getblocks: ',message)})
pool.on('tx', (peer, message) => { console.log('Received tx: ',message)})

pool.connect()

At present, I get no messages back. I do continue to get "peerinv" messages though.
What is a good way to get block data using bitcore-p2p?
Are there any alternative constructions I could use (at present I'd only like the blockheader, the coinbasetx and its merkle partner (the root of the other transactions)?

Have you considered getting block data using the JSON-RPC interface?

Yes, you mean for a local node? I'd like something that'll run on machines without access to that interface though.

Crucially, the event name to capture block data is peerblock not block as I had it.
So adding :
    pool.on('peerblock', (peer, message) => {
     console.log('Received peerblock: ',message)
    })

allowed me to handle the block information.


text:
Is it possible to send a message to a bitcoin address? how?
Say I have an online store that accepts bitcoins and want people to be able to contact me through my wallet, because that is ultimately the entity involved in an hypothetical trade.
Can that be done? how?

Not in any way that is intended by the protocol.
What do you mean by "ultimately the entity involved in a hypothetical trade"? It's just a hash of a public key, the corresponding private key to which you hold.
What is preventing you from having a contact form or e-mail address in the online store?

I mean that payments are made to a certain wallet, not to a certain person.
An email is delivered to an email address, therefore is not the same level of reliability. If I could send a message o a wallet, I would know for a fact that the person reading is the one that has access to whatever funds I send to that wallet.
Using the destination's public key to encrypt an email message would be the equivalent to what I am asking.
Either way, your reply answers my question.

I think it might be possible to encrypt something with the public key bitcoin uses, but the address is a hash of that key, so it wouldn't work. If I recall correctly, once an address sends money, the public key it was derived from becomes part of the blockchain, so you could then encrypt messages to whoever holds the private key. How and if this is possible probably deserves a separate question, though.

Bitcoin transactions - at least the part that ends up on the block chain - should only contain whatever is necessary for the world to validate them. Anything else is pushing extra costs (bandwidth, storage) to everyone who wants to run a full node, and isn't necessary.
Of course, that doesn't mean that payments (as in: the full operation that takes places between to trading entities) need to be restricted to just the low-level transaction that ends up on the block chain. The proposed payment protocol (see https://gist.github.com/gavinandresen/4120476) provides a solution to this: transactions take place directly between two entities (and may involve exchanging messages, order ids, refund addresses, ...), and results in a negotiated transaction which can be broadcast on the P2P network.

Is possible to you sign a message with your address and your privKey, so you have a signed message. But it can't be send at the moment inside transaction, is necessary to send to your destiny by email for example. Whoever receives it will be able to verify that the sender address is true with "address" "signed message" "message". But exists other blockchains that is possible to do it.


text:
cant see bitcoin after restore of backup
I made a backup of my Qt wallet. The blockchain never got completely downloaded and i was sent a bitcoin that i never saw in my wallet as the downloading of the blockchain never caught up with the transaction. I placed this backup file into another Qt wallet that was fully up to date with the blockchain, thinking that i would see the bitcoin but I only see my bitcoin address.
Can anyone please tell me how this is?

Try running bitcoin-qt with the -rescan argument.

Thanks for your reply. Please can you tell me how i run bitcoin-qt-rescan?

Go to the folder: C:\Program Files (x86)\Bitcoin hold shift and right-click and select "open command window here" ( pic ). Now type: bitcoin-qt.exe -rescan and press the Enter key  ( pic ). You can close the cmd window afterwards.

@bob: Or you can just go to "properties" for the link you use to run Bitcoin, and add -rescan to the command.

thanks for the comments. still cant do it though. i tried Nicolai's advice but i have a different configuration. i have daemon. src. bitcoin-qt. COPYING. readme. uninstall. when i right click over bitcoin-qt i have a different popup box without the option to go to rescan. i have tried your advice meni but dont see how i can add - rescan to the command. would you mind giving me detailed instructions as to how to do this. thanks a lot

@bob, do you have a Bitcoin shortcut on your Start menu? You can (temporarily) edit the properties of that to include the -rescan option.


text:
Is there a user-friendly tool for creating and signing raw transactions?
The title stands for itself.
The only tool for doing so I know of is the bitcoind daemon, but it is for from user-friendly.
A web-tool in JS would be ideal or a simple CLI tool with clear documentation.

Electrum has a gui form for just that. Also I think brainwallet.org has a web form that works offline and runs off github source directly so you can verify privacy concerns.
Edit: also see:
http://bitcointalk.org/index.php?topic=40264.msg851062#msg851062
As referenced in Transaction signature generation

Blockchain doesn't do it. It only lets you push raw transactions or make them from funds you own in their wallet.
But the brainwallet feature was exactly what I was looking for!

SX is a set of modular Bitcoin commandline utilities that admin types can engage with Bitcoin functionality without having to write code.

http://sx.dyne.org
http://bitcoinmagazine.com/6234/what-libbitcoin-and-sx-are-and-why-they-matter/

Using the Mycelium mobile app has to be the easiest method to spend funds from a paper wallet.   From the app, select Cold Storage.  Then scan the private key from the wallet.  Then scan the QR code for the Bitcoin address to send the funds to.

Though it is an old question, I stumbled upon a great solution recently. Especially when brainwallet is now gone, I thought of updating it here. They call it Hashmal. Hashmal is an IDE for Bitcoin transaction scripts. Its purpose is to make it easier to write, evaluate, and learn about transaction scripts.
Github: https://github.com/mazaclub/hashmal
BitcoinTalk: https://bitcointalk.org/index.php?topic=1168604.0
p.s. If someone has any fork of the brainwallet Github repo, please post it in the comment.

maybe it is a little bit too late, but brainwallet worked the best and I have just quickly uploaded the version I had to some file hoster:
http://s000.tinyupload.com/?file_id=05407254289290446372
(I dont remember exactly, but I think this is the original zip-file I downloaded in April of 2013)


text:
What hash algorithm is used in Bitcoin Cash?
I know that bitcoin uses hashcash as PoW algorithm, Ethereum uses EtHash and Litecoin uses Scrypt. But I didn't found anywhere the PoW algorithm used in BitCoin Cash, does it uses hashcash too?

I would assume so since it was a hard fork from Bitcoin and was billed at one point as 'the real Bitcoin". Changing the PoW algorithm i think would have made that argument silly. I could be wrong and they did change, it just doesn't seem likely to me.

BCH and BSV both use SHA256 as their POW algorithm, as does Bitcoin (BTC).


text:
Coimarketcap api data different from coinmarketcap.com
I am using popular Coinmarketcap API request:
https://pro-api.coinmarketcap.com/v1/cryptocurrency/listings/latest?limit=100&convert=ETH

In response percentChangeFor24h and some other parameters are always different from what is show on coinmarketcap.com. Do I miss something or data is just irrelevant? Could it be from timezone? I have not found any way to change timezone into requests itself.

If you go to the coinmarketcap.com site and reload the page several times at about 1 second apart you'll see that the volume does not change. This means there's a cache, since there's definitely thousands of trades every second. The API, on the other hand, is probably not cached. This must be the source of the difference you see.

This is likely due to the update frequency of the API and website.
They certainly use the same source to get data for their website and API.
One might be lagging a few minutes sometimes. I'd assume the API data is the most up to date and it's safe to rely on it.


text:
How does work the next block election in blockchain?
In the mining process each miner will create a block with the transactions found in the pool and will start the calculation of nonce, the miner with greater hash power will finish the job first and announce the block.
When the process starts the miners will start the calculation again(the slowest and the fastest), imagine that we have 2 pools of mining and the slower needs 2 hour to calculate a nonce and the faster 2 minutes, the window of 10 minutes will have a winner and the slower have to start the caculation again.
How does lottery work to the solve this problem?

In this question no have the answer for my question. Because they comment about a lottery, by nobody explained how the algorithm solve.

Mining is a lottery, as the answers in that post explains. Your understanding of the process is incorrect.

@G.Maxwell I edit the question and created a scenario. Can you answer? What's the correct view?

The flaw in your question is that "time to calculate a nonce" is random, not deterministic.  It may be that A needs 2 minutes and B needs 2 hours on average, but that does not imply that A will always beat B; B can still get lucky.


text:
Set transaction fee
I am using the bitcoind API to send transactions from my account to user accounts. I have found, that the sendtoaddress method uses address,amount and comment to send transactions, but I need to set comission for each transaction. Please help me to solve this problem!

You can set the fee (commission) paid with the settxfee RPC command:

bitcoin-cli settxfee 0.00045

How can i check the size of transaction ?
I have already found answers in stackoverflow. but can not understood, how can i check the size of transaction before sending


text:
Current hash rate required for one block
Now, the height of the blockchain is 485531. How much hash power is ideally required to mine block number 500000.
And how much hash rate does a node require to publish a block successfully each hour?

Firstly, new blocks are published every 10 minutes on average, not every hour.
There is no 'required' amount of hash power to mine a block. It is all a game of luck, a race against the rest of the network. To mine a valid block roughly once per hour, you would be mining a sixth of the total blocks (~6 blocks mined per hour), so in theory you would need around a sixth of the total hashpower on the bitcoin network. You can see the current network hash rate here:
https://blockchain.info/charts/hash-rate
At the time of this post, that's roughly 1.4 exahashes per second (million terahashes per second).


text:
While calculating merkle proof, where are the other hashes being stored?
Consider that I have a merkle root made up of transactions a,b,c,d,e,f,g,h.
The root is H( H(H(a)+H(b)) + H(H(b)+H(b)) ) + H( H(H(b)+H(b)) + H(H(b)+H(h)) ).
Now, I have to verify whether transaction C is part of this root (which it is).
I am supposed to get hash of c H(c), which I can using the one-way hash function.
But then, after that I must get hash of other values also: H(d), H(H(H(a)+(b))) and so on in order to verify that c is a part of the Merkle tree.... Where do these hash values come from? Are they stored somewhere? If not, how are they dynamically generated?
And if all hashes are stored, how do I know that my hash H(C) has to be paired with H(D) and not H(A). Similarly for other levels also.
Doesn't storing all hashes defeat the purpose of optimizing space?

It might be better to use lower-case letters to symbolize transactions, since you are using H() to indicate the hash function.

These are not stored anywhere, and are calculated by the node.
The order in which transactions are included in the tree is the same as the order in which they appear in the block, which answers your last questions. To calculate a tree, one simply traverses the block's tx list, including them in pairs of two (and duplicating the last one if needed) to build all of the leaf nodes.
When asked if a block contains a particular transactions, nodes will check that block's transaction list. If the transaction exists, they will calculate the hashes you mentioned above to produce a merkle path, which contains the minimum nodes required to verify the transaction against the merkle root.
Since SPV wallets are aware of the block headers, they can verify the merkle root of the merkle path matches the one in the block header.

The root is H( H(H(A)+H(B)) + H(H(C)+H(D)) ) + H( H(H(E)+H(F)) + H(H(G)+H(H)) ).

You forgot one more level of hashing, it should be:
root = H( H( H(H(A)+H(B)) + H(H(C)+H(D)) ) + H( H(H(E)+H(F)) + H(H(G)+H(H)) ) )

Where do these hash values come from? Are they stored somewhere? If not, how are they dynamically generated?

The blockchain is referenced to find the raw transactions, and those transactions are hashed to verify the validity of the block. This happens on the level of individual nodes, every time the node hears about a new block. The merkle root in the blockcheader must be correct, and it is a cryptographic proof of the transaction content of the block. The merkle tree is computed by each node, but it doesn't need to be explicitly stored.
The merkle root provides a convenient and trustless way for light wallets to verify the authenticity of a transaction. Light wallets store all the headers, so they can just request that a node sends one branch of the merkle tree to them (for the relevant transaction). They can verify the hashes from the transaction to the root, and thus know the transaction is indeed included in the blockchain.
Including the merkle root also has other benefits, check out this question for good info.

Doesn't storing all hashes defeat the purpose of optimizing space?

The benefits gained from storing the merkle root far outweigh the reduction in blockspace usable for transactions (32 bytes for the merkle root).


text:
BT wifi Internet router not detecting S9K miner
I am mining crypto via GPU & ASIC miners. I recently bought an S9K Antminer which powers on perfectly fine; however as we all know, it needs to connect to the internet via an ethernet cable. This is where I have an issue.
When I connect my laptop or my GPU mining rig to my router via ethernet cable both devices are recognized on the router's 'BT Smart Hub' web interface, internet also works. However, when I connect my S9K to the router via ethernet the 'BT Smart Hub' web interface does not recognize nor detect the connection. I know its not the cable because of the examples above and because I attempted connecting the S9K to my GPU mining rig via ethernet cable and my computer recognized the connection straight away ( of course it had no internet, but still showed "Unidentified network via ethernet cable") I tried to call BT but the guy said unfortunately he has no expertise to address my issue, since I confirmed the router detected two other different devices (laptop / gpu mining rig) so he suggested I find an expert. Does anyone have any solutions?

Determine your home's private IP network information. It's likely somewhere in 192.168.x.y range, or perhaps 10.x.y.z
Antminer has instructions for determining the S9K's IP address (https://support.bitmain.com/hc/en-us/articles/360025765073-How-to-set-up-a-new-S9-SE-S9k) and to program its network and operating parameters.
It is likely the Antiminer is trying to get an IP address assigned  via DHCP; see if the router has an attached device list, possibly listing MAC addresses of attached devices. Antminers should have Bitmain's prefix, "E0-A5-09-xx-xx-xx". If you can see a device with a MAC address matching this prefix, that will be your S9K.
You may have to temporarily re-configure a laptop connected via ethernet directly to the Antminer to be able to access and reprogram the Antminer on a compatible browser to match your BT (British Telecom) router's private home network.


text:
Is the bits field a unique representation of the target?
The bits field is the compact representation of the target.
Example:
bits: 1d00ffff
target: 00ffff0000000000000000000000000000000000000000000000000000

bits: 1cfff00
target: ffff0000000000000000000000000000000000000000000000000000

But these two actually represent the same number.
int(target) ->  26959535291011309493156476344723991336010898738574164086137773096960
 for both of the above targets.
What (if anything) makes bits a unique representation of the target?

Clarification:
In regular interactions with numbers, this kind of thing doesn't really matter, as a few leading zeros don't affect how we interpret the number. However, in Bitcoin, the bits field is used as part of the hash of the block. Therefore, a different bits representation would produce a different hash of the block.

@NateEldredge Thanks for pointing this out. I've added a clarification to the question.

Some related fun, try and establish why the there is a sign bit in the target.

@Anonymous Is there a sign bit?

There is a sign bit.

See the answer over here for representation of sign bit. https://bitcoin.stackexchange.com/questions/48707/difficulty-target-representation-in-bitcoin-wiki

In short: no, the nBits encoding is not unique (there may be multiple 32-bit values that correspond to the same 256-bit target), but the nBits value as required by the network consensus rules is unique.
The reason for that is that all calculations happen on the target, which is then converted (using a deterministic algorithm) into nBits format. That nBits value is then required to match the value in the block header.

Yeah, I guess I was hoping for some more technical details? What is the algorithm to make sure everyone is using the same rep of bits?

@StephenCowley The point of consensus rules is that everyone uses the same ones; if they don't, they'd end up on their own chain. So by definition everyone who follows Bitcoin's consensus rules uses the same algorithm. In Bitcoin Core, that code is https://github.com/bitcoin/bitcoin/blob/v0.17.1/src/pow.cpp#L71 and https://github.com/bitcoin/bitcoin/blob/v0.17.1/src/arith_uint256.cpp#L226L247


text:
Bitcoin in RegTest throw (bad-cb-height) at block No. 500
Mining in RegTest mode goes well until it's reach block height=500, then server return (bad-cb-height) any idea what is wrong with this coninbase:
02000000
01
0000000000000000000000000000000000000000000000000000000000000000
ffffffff
2a
03f40100
2508000000313130311a00000052797a656e2e33363030582e69732e617765736f6d652e2e2e
00000000
01
40be402500000000
16
001420f897e733695493cc731b0b4b80352fb9a826f
000000000

https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki

Adding an answer to your own question is encouraged!

the answer is here: https://bitcointalk.org/index.php?topic=5293244.0

the problem is an incorrect implementation of BIP-0034 in my code, I thought the length of height should be at least 3 bytes which I was wrong,
"Coding Enthusiast" says :
"The block height has to be pushed with the minimal number of bytes:
Since BIP-34 activates at block 500 on RegTest, this is ignored on all blocks from height 1 to 499 and from block height 500 it starts being enforced and the invalid push is rejected."
the description of the answer is here: bitcointalk.org/index.php?topic=5293244.0


text:
Is Coinbase transaction required to be signed?
I am trying to build a coinbase for mining with the following steps:
1-Create dummy Input and output.
2-Pass them to CreateRawTransaction as collection/
3-Get a transaction back and fill the empty fields according to coinbase structure (specially set Txout’s Value to 12.5 bitcoin).
4-Serialized transaction into Hex string mode.
With above steps preformed in RegTest mode a new block created and 50 Bitcoins added to the wallet which seems to be correct but as far as I know a transaction should be signed, Is Coinbase excluded from signing procedure ? and why it’s add 50 bitcoins to account instead of amount which I specific set to 12.5 bitcoin ?

public async Task<string> BuildCoinbaseTransaction(string MinerAddress, uint Height)
{
    string coinTxSerialized = string.Empty;
    scriptData = Tools.RandomNumbers(rEngine);
    string pubKey = await GetPublicKey(MinerAddress);
    string scriptPubKey = CreateCoinbaseScript(pubKey);

    List<object> txi = new List<object>
    { new CoinIn { TxId = "0".PadLeft(64, '0'), Index = 0x0 } };

    List<object> txo = new List<object>
      { new Dictionary<string, double> { { MinerAddress, 0.00 } } };

    RPCResult<string> rpcResult = await cmd.CreateRawTransactionAsync(txi, txo);

    if (rpcResult.Error == null)
    {
        TotalReward = Math.Min(RewardCoins + CollectedFee, MaxCoinbaseValue);

        string rawCoinbase = rpcResult.Result;
        string decodedTx = await cmd.DecodeRawTransaction_CommandAsync(rawCoinbase);

        RPCResult<string> Transaction jsonTx= JsonConvert.DeserializeObject<RPCResult<string>>(decodedTx);
        Transaction coinTx = jsonTx.Result;

        coinTx.Height = BuildHeight(Height);
        coinTx.TxIn.FirstOrDefault().Coinbase = scriptData;
        coinTx.TxIn.FirstOrDefault().Sequence = 0xFFFFFFFF;
        coinTx.TxOut.FirstOrDefault().Value = TotalReward;
        coinTx.TxOut.FirstOrDefault().ScriptPubKey.Assembely = scriptPubKey;
        coinTx.Hex = coinTx.ToString();
        coinTxSerialized = coinTx.Hex;

        return coinTxSerialized;
   }//if

}//BuildCoinbaseTransaction

The coinbase transaction is constructed by the miner/mining pool operator and is not a transaction which can be broadcast to the mempool.
The amount of the coinbase output is strictly according to the block height, which begins with 50 BTC and halves every 150 blocks in regtest mode. When you create a new block in regtest mode, it will automatically generate a coinbase transaction, with the output spending to your specified coinbase wallet.
The input script of the coinbase has the [blockheight (4B)] and additional data, totally a maximum of 100B.
Input:

Previous TX hash: 00..00
Previous output index: max_value(ff..ff)
Input script: [blockheight (4B)] [additional arbitrary data]

The input is not signed because it does not spend from a UTXO. There are no locking conditions other than to be committed to a header with valid POW.

why are there scriptPubKey's in vout's of coinbase transactions?

The scriptPubKey in coinbase vouts indicate the spending conditions of the mining reward: this way, the miner can indicate who can spend the mining fees/minted coins.


text:
how can i get rid of a zombie channel in LND?
My LN-Node: 023bf99414b3e93ab7463ce60f44cd691f8be3c1ae33a2015fe784c85c36e770cf
bitcoind 0.17.1 // LND 0.5.2-beta commit=v0.5.2-beta-rc7
Channel: 598078250466476032
Problem: lncli feereport returns:
rpc error: code = Unknown desc = no policy for outgoing channel
edit:
more of the same?
lncli fwdinghistory returns:
{
    "forwarding_events": [
    ],
    "last_offset_index": 0
}
related?
trying to edit a recent channels policy..
"channel_id": "620981077780267008",
    "chan_point": "e388cce2698c0406985af2fce27ee47c5f02b04e8fbda0523975b71246e66d77:0",
    "last_update": 1551629972,
    "node1_pub": "023bf99414b3e93ab7463ce60f44cd691f8be3c1ae33a2015fe784c85c36e770cf",
    "node2_pub":
 "03efccf2c383d7bf340da9a3f02e2c23104a0e4fe8ac1a880c8e2dc92fbdacd9df",
    "capacity": "500000",
    "node1_policy": {
        "time_lock_delta": 144,
        "min_htlc": "0",
        "fee_base_msat": "1000",
        "fee_rate_milli_msat": "1",
        "disabled": false
    },
    "node2_policy": {
        "time_lock_delta": 14,
        "min_htlc": "1000",
        "fee_base_msat": "485",
        "fee_rate_milli_msat": "1",
        "disabled": false
lncli updatechanpolicy --base_fee_msat 419 --fee_rate 0.000001 --time_lock_delta 14 --chan_point e388cce2698c0406985af2fce27ee47c5f02b04e8fbda0523975b71246e66d77:0
[lncli] rpc error: code = Unknown desc = Channel from self node has no policy

as mentioned in the mail I send you it looks like the funding tx of the channel was already spend: https://www.smartbit.com.au/tx/2a00c8d2e392cbf20f9175f2ebb72dd1f8d522547cf5b3d01725446a08776e59 so the channel is closed

Also the command to remove a channel from the DB has not been added yet but should be released in 0.6 IIRC

yes, the channel is closed.
i want to purge it from the DB to fetch the feereport.
i guess 0.6 will fix this.
Thank you for your input.

this was fixed in version 0.6-beta

This problem still appears in lnd 0.9.0-beta.


text:
These testnet outputs are not making sense to me
Today I took some time to mess around with the bit Python library, which I find pretty easy to use. I have been wanting to do some Bitcoin programming for a while, so I decided to create a simple web wallet to test creating and broadcasting transactions. I'm obviously using testnet for this.
I initially used a testnet faucet to send two transactions to a main address, 0.0005 and 0.0001 tBTC to get started. I used my code to check for this address' balance and got 0.0006, cool. I then proceeded to used my newly developed web wallet to send two transactions to another address, both with a value of 0.00001 tBTC. I immediately noticed the balance from my main address was off, showing me 0.000028 tBTC which to me makes no sense, it should have been something close to 0.00058. I used blockcypher to check on those transactions (which are unconfirmed, but I believe this is irrelevant) to make sure my code was ok. Sure enough, 0.00001 tBTC was sent twice to the correct address, but the change sent back to the sender address is way off. What exactly happened here?
I include the transactions here and here.
Thanks in advance!

This is expected.
You don't appear to be accounting for fees.
If you account for them, you get:
+0.0005 386d83da01218ca74cbe72b19a6814293b98357921042a9b03ab39706fef8736
+0.0001 8e95c68f524e557a9b42d11207effae89c4e61913c5c4758adb142a6cdd03848
-0.00001 with -0.00034408 as Fees 91224995f2c240159141a499b91db8d26f0a6425fb12f5277d2f735576596aa7
-0.00001 with -0.00020792 as Fees  92287c75721563643f8dbf9ee5fff59abe1c9b6b36a638daa05c35d5fea981d0

This gives you a final balance of +0.0005 + 0.0001 -0.00001 -0.00034408 -0.00001 -0.00020792, which is 0.000028

Thanks for your reply! I was looking for tx fees in the pages I included but it slipped past me, so I assumed testnet transactions didn’t have fees at all.


text:
What did the opcode 0xba do prior to creation of OP_CHECKSIGADD?
From BIP0342:

The opcode 186 (0xba) is named as OP_CHECKSIGADD.

What did 0xba do prior to this?

Before the Taproot soft fork the opcode 186 (0xba) was an undefined opcode. Undefined opcodes abort verification and consider the transaction to be invalid. There are also OP_NOP opcodes that are designed to be ignored (do nothing) and do not invalidate the transaction. After the Taproot soft fork the opcode 186 (0xba) was defined as OP_CHECKSIGADD. There was an additional change in the Taproot soft fork where opcodes that remained undefined (not the case for the opcode 186) were made OP_SUCCESS. From BIP 342:

If any opcode numbered 80, 98, 126-129, 131-134, 137-138, 141-142, 149-153, 187-254 is encountered, validation succeeds (none of the rules below apply). This is true even if later bytes in the tapscript would fail to decode otherwise.

Thanks, I think there are also some specified OP_NOPs that do not invalidate the transaction.

@Lee: Indeed, I'm getting into a muddle here (been a while since I looked at this). There used to be undefined opcodes and OP_NOPs and after Taproot there are OP_SUCCESSes and OP_NOPs (I think) :)


text:
how to convert URI into Bip21
i am trying to convert the

URI into BIP21

currently i am generating URI from bitcoinj library, but i want it to be on BIP21 Standard. i have read many articles but didn't found any solution

Do you have an example of an URI generated by bitcoinj lib?

yes here: "mqe8V3Vrp77JKYG2tfnQ6P8wpN4YVZ84V2"

Have you tried convertToBitcoinURI(String address, Coin amount, String label, String message) or convertToBitcoinURI(Address address, Coin amount, String label, String message) ? or https://github.com/bitcoinjs/bip21

no i didn't try this...

yes i try this but didn't work for me

Did you get an error or something else?

well, i couldn't access the convertToBitcoinURI

This is how i am generating URI
// Derive address
mAddress = mECKey.toAddress(mParams);

Ohh I forgot, you have access the method in BitcoinURI , so like that ......................................................            String bitcoinURI = BitcoinURI.convertToBitcoinURI(String address, Coin amount, String label, String message)

did this generate BIP21 URI for me?

bitcoin:mqe8V3Vrp77YMZG2tfnQ6P8wpN4YVZ84V2?amount=0.000001&label=bla&message=So%20this%20is%20it%21%20hmm...This is i got when i print

That is bip21...???

Seems fine to me

The source file for that method is here
BIP21 wiki
Method can be accessed like this
 String bitcoinURI = BitcoinURI.convertToBitcoinURI(String address, Coin amount, String label, String message);


text:
Broadcasting signed transaction from Watching wallet using bitcoinj
I am working with watching wallet and Offline wallet using bitcoinj,
  I created Watching Wallet using tpub key of Offline Wallet
I am receiving payment on watching wallet Fine,
 now I want to spend coins from watching wallet after Signing my transaction from offline wallet
What I am doing is creating rawTx from the Watching Wallet and then signing it  with the private key from Offline Wallet but when I broadcast it, it throws an exception:
InsufficientMoneyException

But my wallet balance is 0.23389 BTC
, its not spendable balance as my watching wallet shows
Wallet containing 0.23389 BTC (spendable: 0.00 BTC)

This is not spendable because we cannot spend coins from watching wallet unless you sign it with the corresponding private key
Below is my code: As i am trying to sign transaction from my offline wallet, so i can spend coins from watching wallet
For creating Raw Transaction from Watching Wallet
private void bla()
{
    Coin coin = Coin.parseCoin("0.01");
    Address address = Address.fromBase58(params, "n4oLPFUGvohSdDxvJS3amXvfE1GEdZBddd");
    Transaction tx = new Transaction(params);
    System.out.println("Raw TX: " + tx.toString());
    byte[] bytes = Script.createInputScript("5ff01d61e67c706cb79653aa1e7ad2c7254b841167e0a34055504c35c7240469".getBytes()); // tx hash
    TransactionInput input = null;
    List<Transaction> list = kit.wallet().getTransactionsByTime();
    for(Transaction t: list)
    {
        input = t.getInput(0);
    }

    //Creates a scriptPubKey that encodes payment to the given address.
    Script scriptPubKey = ScriptBuilder.createOutputScript(address);
    // Signature Script
    Script scriptSig = input.getScriptSig();

    // Adding output that involves Amount and Script
    tx.addOutput(coin, scriptPubKey);
    System.out.println("Script pub key: " + scriptPubKey);

    //Adding input to the raw transaction
    tx.addInput(input);
    System.out.println("After adding inputs: " + tx.toString());
}

Signing Transaction from Offline Wallet Using Private Key
private String signTx()
{
    // TX Hash from Watching wallet
    String unSignHash = "f348ceadcb66e811799aa543107b63b9c92afebda5bc47d11222ba218df6638f";
    // Signing Hash with private key
    System.out.println("Signed Hash from prv key: " + DatatypeConverter.printHexBinary(prvKey().sign(Sha256Hash.wrap(unSignHash)).encodeToDER()));
}

Then I have added one more input in raw transaction
 input.setScriptSig(ScriptBuilder.createInputScript(new TransactionSignature(OfflineWallet.prvKey().sign(hash), Transaction.SigHash.ALL, true), OfflineWallet.ecKey()));
        tx.addInput(input);

After that my raw transaction looks like this
310cc780e414c1c64a1d8ed190df10aa5489183e72a73c000e42ff7cc00e41bb
     in   PUSHDATA(64)[35666630316436316536376337303663623739363533616131653761643263373235346238343131363765306133343035353530346333356337323430343639]
          outpoint:83c02edc7d30a63fd123835e0d966d3287ee28729e01d01a7119c055d975fd83:0
     in   PUSHDATA(71)[30440220598202f4822d3c18853f08df4c75bc65f8b42e1c815c6bfeecf53e389c764de80220060b6df8b206eebbd01400f3cc902a0afb24b365b4313f00de87b744a986378501] PUSHDATA(33)[02a0fbbfc754cdda4bc84874af8d5d8bdb8b0271a08a847a856afb3d4e2cd657e0]
          outpoint:c90cb5e1149430b1c99983626ce57588666c7d4e595089235ec0b2496ecae525:1 hash160:ff63fce58aeea04b03bfe29b85ec1cb4827eafad
     in   PUSHDATA(72)[30450221009b12dae5c6edb6f34df18637b06ae742ecb448b6a6797aadb22b6fb728dcba3c02205c95d2553a5d14d6c5bf3891f2dbc7cc3d49ba97ed5fdb6180c3e6225ea88efb81] PUSHDATA(33)[02a656694f40553fe33c06161189f13038a44ab545548b8d2f988ba54b766215d7]
          outpoint:0000000000000000000000000000000000000000000000000000000000000000:4294967295
     out  DUP HASH160 PUSHDATA(20)[ff63fce58aeea04b03bfe29b85ec1cb4827eafad] EQUALVERIFY CHECKSIG 0.00001 BTC
     out  DUP HASH160 PUSHDATA(20)[ff63fce58aeea04b03bfe29b85ec1cb4827eafad] EQUALVERIFY CHECKSIG 0.00001 BTC
     prps UNKNOWN

Then i am broadcasting it using
try
        {
            kit.wallet().sendCoins(SendRequest.forTx(tx));
        }
        catch (InsufficientMoneyException e)
        {
            e.printStackTrace();
        }

I am getting the exception here.
I don't know what I am doing wrong here, as I think my tx hash is just fine, all I have to do is broadcast the transaction into the network from watching wallet, which I am also doing but cannot succeed.
I would really appreciate if someone helps me to find my mistake and broadcasting the signed transaction from watching wallet.

i'm not able to find used input, are you using vaild input with correct vout number?

i am creating input by invoking TransactionInput object, i think i didn't provide the vout and also no idea about it, how to use it here.


text:
Custom derivation path
Instead of using bip32 or bip44 paths what if I use a custom derivation path,
For example:  m/0/0/55/1/1/0
I am thinking even if the private key is exposed then can someone guess the derivation path ?

If the private key for an address is exposed you don't need to guess the derivation path

Ie the above paths private key is exposed and using that private key anyone can get the other private keys ie  address 0,1,2,3

So are there any advantages in having custom derivation paths ?

Some projects use them to specify derivation schemes not covered by BIP44. Otherwise, not really. The whole point of the path is to create a standard, reproducible flow.


text:
No information available about transaction
I transferred all of my 0.0105 BTC in one address to “1Px92t3MBmZcMfomZmt2BKqaaWHRp2y7fQ” through Bitcoin Core. There are two transaction records as following:

Details are:

Status: 9 confirmations

> Date: 2016/12/3 19:30

> Debit: -0.01036619 BTC

> Net amount: -0.01036619 BTC

> Transaction ID:
  e71a265559886a784b242a77d952f58821deada04c547d26b61032ee4f8f5360

> Output index: 0
Status: 10 confirmations, broadcast through 6 node(s)

> Date: 2016/12/3 19:19

> To: huobi 1Px92t3MBmZcMfomZmt2BKqaaWHRp2y7fQ (watch-only)

> Debit: -0.01036619 BTC

> Credit: 0.01036619 BTC

> Total debit: -0.01036619 BTC

> Total credit: 0.01036619 BTC

> Transaction fee: -0.00013381 BTC

> Net amount: -0.00013381 BTC

> Transaction ID:
  9ff577cea7b86667eaea93084b4fb7ed75a5ed6d14bdc6e0557ca8fdc55efb82

> Output index: 0

Two questions:
FIRST
Why there two transaction records and one of them with type “Payment to yourself”? My balance is 0 now.
SECOND
getrawtransaction

9ff577cea7b86667eaea93084b4fb7ed75a5ed6d14bdc6e0557ca8fdc55efb82 1

results: No information available about transaction (code -5)

What does the transaction
  9ff577cea7b86667eaea93084b4fb7ed75a5ed6d14bdc6e0557ca8fdc55efb82
  represented?

looking at blockchain.info, your first spent to this address was done at 2016-DEC-03 11:19:29 CET, amount was 0.01036619 BTC. This is what is shown in your picture above. You can look at the raw TX here: 9ff577ce...c55efb82
Later on there was a second TX: e71a26555...f8f5360
Both TX are confirmed. All good.
Not sure if I got your question right, on the payment to yourself. Usually if you spend bitcoins, they come from UTXOs, and if a value doesn't exist, the wallet will try to combine several UTXOs to near the desired value. The remainings go back into your wallet. It is like buying something for 9 Euros, you pay with a ten Euro bill, and get 1 Euro back to your wallet.

Also, getrawtransaction only works for unconfirmed transactions unless you run in txindex mode. Use gettransaction instead, which requests wallet info about a transaction rather than node information.

Thx for your answer. Actually I had 0.0105 BTC in the account 19CtzwxLnkptTHp49BRVdvzVjxtYDkMvph, and I made a transfer to spend all of the 0.0105 BTC to 1Px92t3MBmZcMfomZmt2BKqaaWHRp2y7fQ. There should not be any remains to be paid back. If there is a payment to myself, I should not get a zero balance.


text:
How does the CHECKSIGADD opcode work? How does it compare to its predecessor CHECKMULTISIG?
How does the CHECKSIGADD opcode (defined in the Tapscript BIP) BIP342 work? How does it compare to its predecessor CHECKMULTISIG?
The design of CHECKSIGADD was discussed in this StackExchange question.

James Chiang explained how the CHECKSIGADD opcode works in this Bitcoin Optech workshop. (The code for CHECKSIGADD in the Bitcoin Core codebase is here.)

As you can see on the left we have an output script that uses CHECKSIGADD and CHECKSIG opcodes to express a n-of-n multisig output.

pk0
checksig
pk1
checksigadd
pk2
checksigadd
3
equal

This is our initial stack which is populated with 3 signatures:

sig0
sig1
sig2

In the first step we will push this public key (pk0) onto the stack and evaluate that against sig0 with the opcode CHECKSIG. Let’s assume this evaluates to TRUE. Since it evaluates to TRUE we will now have a 1 byte on the top of the stack:

1
sig1
sig2

We will use a counter.

2
sig2

As we evaluate the signatures against other public keys, if that script evaluates successfully we will then have a counter of 3 on the stack and that counter can then be compared to the one encoded in the output script. If they are equal we have successfully spent a 3-of-3 multisig output which uses CHECKSIGADD to encode that multisig.

3

How does it compare to its predecessor CHECKMULTISIG?

CHECKMULTISIG doesn't (it is still used for SegWit v0 spends) use an increasing counter. The equivalent locking script using CHECKMULTISIG would be:
3
pk0
pk1
pk2
3
checkmultisig

CHECKMULTISIG also contains a longstanding bug which means the unlocking script requires a 0 at the bottom to satisfy the locking script.
sig0
sig1
sig2
0

The operation of CHECKMULTISIG is explained in this StackExchange question.


text:
Limits to the number of accounts?
I wonder: is the built-in accounts facility scalable enough that you can assign each newly minted address to a different account?  Or am I going to run into hard limits, or a database that becomes too sluggish because accounts were meant to be few in number?

The upcoming switch to LevelDB and/or the implementation of Ultraprune will likely eliminate any problem, if one exists.

Out of curiosity, is there a reason for that?

There most likely isn't any hard limit - you might only be limited by your computer's memory (and even then, that would require tons of addresses).


text:
Can the same target address appear more than once on transaction output?
Normally, a transaction output will contain a list of address + amount.
Each element in this list has an associate output number, "vout".
For example:
Transaction outputs:
vout=0: addr=m111111, amount=100
vout=1: addr=m222222, amount=200

My question is: would it be legal for a transaction output to contain
the same target address more than once?  Take for instance the example below, where address "m222222" appears in vout=1 and vout=2:
vout=0: addr=m111111, amount=100
vout=1: addr=m222222, amount=100
vout=2: addr=m222222, amount=100

I know this seems silly.  I'm just wondering if it is the sort of
thing one might encounter "in the wild".


text:
Import Bitcoin core pubkey into Electrum for multisig setup
Background
I have a service running on a server using bitcoin core that is signing transactions from a Bitcoin wallet automatically. However, if anyone were to get access to this server, they'd have access to the full Bitcoin keys.
Hence, I was trying to create a multi-sig setup using Electrum on bitcoin core as follows:

I started to create a 2 of 3 multi-sig in Electrum where my plan was to have 1 key in the server (bitcoin core) and 2 keys are in Electrum instances, i.e., I'd always have to come online to verify that the transaction is made correctly.
I managed to create two Electrum wallets and export their pubkeys to add them to the 2 of 3 multi-sig.
I got stuck on importing a pubkey from bitcoin core into Electrum. As far as I understand, bitcoin core does not support extended pub keys (How do I export an xpub from Bitcoin Core for use in BTCPayServer?).

Question
Is there any way to import a pubkey for a single address from bitcoin core into Electrum?
Related
I found posts on how to import xpub keys into core (Create multisignature wallet from xpub keys in bitcoin core) but I'm trying to do the opposite (pubkey from bitcoin core into Electrum).

If you use Descriptor wallets, you can get the descriptors used by the wallet with the listdescriptors RPC. These descriptors will contain xpubs that you can import.
Without descriptor wallets, you can only get individual pubkeys from Bitcoin Core by using getaddressinfo for an address in the wallet.