How is subscript computed for OP_CHECKMULTISIG? I'm trying to learn the Bitcoin protocol by implementing it, and I've got OP_CHECKSIG working (following instructions in https://en.bitcoin.it/wiki/OP_CHECKSIG), but I can't get an transaction input using OP_CHECKMULTISIG to pass signature verification.

Specifically, I'm stuck with the second tx_input of transaction eb3b82c0884e3efa6d8b0be55b4915eb20be124c9766245bcc7f34fdac32bccb, and I suspect that the culprit is subscript (the one to replace signature script in current transaction).

Here's how subscript is computed in my implementation.

First, generate the script by concatenating [sigScript][OP_CODESEPARATOR][pubkeyScript] (I understand that script execution has evolved from this).

So a (parsed) script for the input would be like this:

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

Then, I create the subscript from the closest OP_CODESEPARATOR before the OP_CHECKMULTISIG that I am executing till the end of the script. So, I include Frame 03 to Frame 10.

Then, I remove other OP_CODESEPARATORs in the script, which is Frame 07.

That means these frames should compose the subscript:

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

Serialized, the final subscript looks like this:

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

However, when this subscript is used to replace signature script, and eventually generate hash, the ecdsa_verify function reports that signature verification fails (but the inputs are legal).

Since the same procedure works for OP_CHECKSIG, I probably missed something obvious, but I couldn't figure this out reading the original Satoshi code, the current implementation, or Bitcoin Wiki.

If it helps, my code for OP_CHECKMULTISIG is here:
https://github.com/blaesus/tinybtc/blob/checkmultisig/src/script.c#L687

A more simplistic version (using prevTx.pubkeyScript as subscript) doesn't yield valid results either: https://github.com/blaesus/tinybtc/blob/validate/src/script.c#L344

The main confusion here comes from this :

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

Then you add :

  I understand that script execution has evolved from this

I'm not sure whether you mean "Builds upon this method" or "Has since changed this method", but if it is the former then this might explain the unexpected results that you're getting.  Hopefully my answer can clear this up.

It's true that for a (relatively) short period Bitcoin's script evaluation was done by the way you mentioned, where a CODESEPARATOR was placed between scriptSig and scriptPubkey then the whole thing was concatenated to form a single script which would be executed, but that was changed rather early on in commit 6ff5f718b6a67797b2b3bab8905d607ad216ee21 which dates to July 31st 2010.

After said change, which introduced a function named VerifyScript in script.cpp (today the logic is in interpreter.cpp), scriptSig and scriptPubkey are no longer concatenated with a CODESEPARATOR between them.  Rather they are executed as two separate scripts one after the other, where the stack's contents carries from the first to the second.

The difference is subtle and doesn't really change the flow of standard redemptions, but becomes noticable when a CHECKSIG operation is done within the scriptSig.

Starting from the funding transaction

b8fd633e7713a43d5ac87266adc78444669b987a56b3a65fb92d58c2c4b0e84d

we see that the second output in it is a payment to the following scriptPubKey at index 1 :

14 2a9bc5447d664c1d0141392a842d23dba45c4f13
NOP2
DROP

OP_CLTV is not active yet, so the opcode 0xb1 is still NOP2.

Which is then redeemed by

eb3b82c0884e3efa6d8b0be55b4915eb20be124c9766245bcc7f34fdac32bccb

by the input at index 1 :

0
47
  30
  44
    02
    20 276d6dad3defa37b5f81add3992d510d2f44a317fd85e04f93a1e2daea646602
    02
    20 0f862a0da684249322ceb8ed842fb8c859c0cb94c81e1c5308b4868157a428ee
  01
CODESEPARATOR
1
21 0232abdc893e7f0631364d7fd01cb33d24da45329a00357b3a7886211ab414d55a
1
CHECKMULTISIG

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

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

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

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

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

1
21 0232abdc893e7f0631364d7fd01cb33d24da45329a00357b3a7886211ab414d55a
1
CHECKMULTISIG
14 2a9bc5447d664c1d0141392a842d23dba45c4f13
NOP2
DROP

Which is what you initially came up with, but now let's see how the change at 6ff5f718 makes a difference.

Recall that we are now dealing with two separate scripts, but none of the other rules change.  The only difference is that these two scripts are executed separately, one after the other, and that the stack that remains from the execution of scriptSig passes on to the execution of scriptPubkey.

We start by executing scriptSig and go through steps #1 - #7 as before, arriving at the same point of CHECKMULTISIG where we construct the scriptCode.
Since the actual executed script now consists of only what was in scriptSig, scriptCode becomes :

1
21 0232abdc893e7f0631364d7fd01cb33d24da45329a00357b3a7886211ab414d55a
1
CHECKMULTISIG

If this signature check passes (and it does), a value of 1 is pushed onto the stack, and scriptSig execution ends successfuly.  This stack now passes on to the exectution of scriptPubkey (which is very simple) and eventually left as the final value on the stack, which makes scriptPubkey resolve to True.

This transaction is very interesting really shows how non-trivial commit 6ff5f718 actually was.  It's a great example.

Another minor thing to note is that this scriptPubKey by itself is an anyone-can-spend script.  This script's conditions are satisfiable simply by passing a single push of an element which evaluates to True (e.g. 1 - 0x51) and that the signature check in scriptSig actually has no significance and does not secure the funds at all.

Edit :

Actually, looking into this some more, it seems that this transaction is specifically mentioned in BIP-17 (which has since been abandoned).  The 20 bytes in scriptPubkey is actually the hash160 of the 1-of-1 multisig script itself :

51210232abdc893e7f0631364d7fd01cb33d24da45329a00357b3a7886211ab414d55a51ae

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


A transaction that does not get processed Yesterday I moved 20 bitcoins from my wallet in MtGox to my personal wallet, twice. The two transactions were made in a short time (about 1 minute). Both were done toward the same recipient: 142fUrgXNJiKwhXWiN9gkR8zvTbucm2idA
The ID of the first transaction was:

63eddec307c6ab9bf285b6b33f506fe90069e5d297263ed55249580a8120fff7

And of the second was: 67d1c656a65dc4c29f20292f4abecdb45d5a492091a167a0643fd50723f61dbf

Both transactions were registered from my MtGox account lowering it of said amount (thus taking away the possibility to try again).
Well, the first appeared immediately in my wallet, And after a few minutes gathered the confirmations necessary, and is now happily sitting there. The second never appeared. It did however appear on Blockchain:
https://blockchain.info/tx/67d1c656a65dc4c29f20292f4abecdb45d5a492091a167a0643fd50723f61dbf

Where it is sitting in a queue from yesterday evening with a confirmation warning saying: "This transaction has a none standard input".

So I would like to understand what is going on. What shall I do to recover those bitcoins?

Thanks,
Pietro

P.S. Note that making a search on the warning on google shows only one result: the code in github. So no one must have had this problem before. Weird.

Eventually 20 BTC arrived. But not from THAT transaction. Maybe MtGox realising that they made an error sent another extra 20. Weird.


Is there a remote, trustless bitcoin API that doesn't require anything (blockchain/SPV headers) to be stored locally? This question asks about how to work with bitcoin via an API without requiring a local blockchain. The only answer is about blockchain.info's JSON API, but it appears that unlike the web version of blockchain.info, the JSON API requires the account passwords to be sent to the server.

Is there another remote API that allows one to perform various bitcoin operations without compromising security - without sending private keys anywhere, but rather signing transactions locally? The API should not require any downloads - SPV does not fall under this category - but should just be a remote API to the bitcoin network that doesn't require any state / bootstrap from its client.

If I recall correctly then Stratum was supposed to be this API. Did it ever take off?

The BOP Enterprise Bitcoin Server is an open source full node implementation with remote (that is client side) wallet. The server downloads the block chain does the transaction and block validation and routes transactions signed at the client.

The client connects to the server via a message bus. There is a Java and other APIs available with added client side features. Source code: https://github.com/bitsofproof/supernode

Commercial support and hosted instances available at http://bitsofproof.com


How many unspent transaction outputs are there? I was wondering the other day how many unspent transaction outputs there are ?

If you just keep track of the unspent transaction outputs you could import private keys, know its balance  and perform spends. How much data is this compared to the full blockchain ?

The biggest downside is that you would not have the full transaction list for a private key/address - just the transactions that you can use for future transaction inputs.

As of block 177778 (Apr 29, 2012 6:17:33 PM):

2944702 transactions
6904591 transaction outputs
5376092 transaction inputs
1528499 unredeemed outputs left
642432 addresses with non-zero balance


Online Store in Cheyenne, Wyoming Accepting Bitcoin for Payment Can an online store located in Cheyenne, Wyoming accept bitcoin as payment for goods from customers in either Wyoming, or other states or countries, without collecting every customers Social Security Number, or other KYC and AML type identifying information, without the possibility of being prosecuted for money laundering by either Wyoming or the US Federal Government?

For absolute clarity, you should consult the appropriate lawyer / tax professional in your jurisdiction.

However, in general, accepting bitcoin for payment should be no different than accepting any other form of payment. Think of it like accepting a foreign currency, and apply the appropriate accounting practices. There are even services out there which allow you to accept payment from customers in bitcoin, but will then pay you out in your local currency.

KYC/AML type stuff usually applies to businesses that are money transmitters, trading one form of currency for another. But as I mentioned above, if you are truly worried, then you shouldn't take the advice of a stranger on the internet, you should hire the appropriate professional to advise you on the matter.


Do I need to wait for blockchain to complete to use private key elsewhere? As the title says: My blockchain sync still needs to sync 56 weeks, but I want to export my private keys from the bitcoin qt wallet to blockchain.info.
Is it possible to do that without waiting for the chain to complete and unninstall the program, or do I have to wait?

Thanks!

You can export your private keys (using the dumpprivkey command in the console) without having to wait to sync the blockchain.


Mining with low specs? If I have a computer with low specifications (2GB RAM, 2.13 GHz, integrated graphics), is there any way to mine normally with Bitcoin-qt? If not, will joining a pool with these specs be worth the time and effort? What kind of specs are normally recommended for mining?

No, this would not be worth it. CPU mining is extremely slow and there is probably no OpenCL driver for your integrated graphics. You could however hook up FPGAs to that computer, or in the future, bitcoin ASICs.

Currently recommended hardware would be FPGAs and/or fast AMD graphics cards.

In the near future there are several ASIC-based mining devices scheduled for launch. These will drive up the difficulty, making today's FPGAs and AMD GPUs seem slow.


Can BIP91 cause a chain split? BIP91 forces BIP141 signaling, the blocks that do not signal BIP141 will be rejected by those who are pro-BIP91.
The minority of miners that do not support BIP91 (and by extension BIP141), could start rejecting blocks of those who are signaling BIP141, thereby creating a different chain.
Is that a possibility both in theory and in practice?

The minority of miners that do not support BIP91 (and by extension BIP141), could start rejecting blocks of those who are signaling BIP141, thereby creating a different chain.
  Is that a possibility both in theory and in practice?

Yes that is possible, but unlikely. Since BIP 91 has a majority of the hashrate, I think it is unlikely that there will be a persistent chain fork. Rather what is more likely to happen is that there are short multi-block forks that are then orphaned and reorged out as the majority hash rate chain becomes longer than those forks.


Recovering wallet using BIP32/wordlist/.priv file I was using Msigna but it's having issues connecting to the localhost (Running updated bitcoinqt). I sent coins to my old account without waiting for sync (noob move) but now I'm unable to access the wallet.

Can anyone help me with migrating from msigna to another wallet? I'm able to download my private key but unable to actually find out what it is. I do have the master key BIP32 and the wordlist associated with it.

The derivation paths for BIP32 will be different. The easiest way to migrate is to sync mSIGNA and send all the coins to an address generated by the other wallet.


Is there a crowdfunding site for Bitcoin? Does a crowdfunding site like kickstarter.com exist, which accepts bitcoins instead of dollars?

For donation-based crowdfunding:

http://www.BitcoinStarter.com
http://www.CoinFunder.com
http://www.nestorbooster.com
http://ignitiondeck.com/id/bitcoin-crowdfunding

There's also:

http://www.Propster.me
http://www.PirateMyFilm.com
http://www.Booster.io

and some day coming back:

http://www.BitcoinChipIn.com

Of course, the "equity" markets for equity-based crowdfunding:

http://www.BitFunder.com
http://www.MPEX.co
http://www.CryptoStocks.com

And a forms of microlending from the crowd include:

http://www.BTCJam.com

and others.

[Update: Thanks to others answering this question as well, I've updated this list with their input as well.]


BTG wallet or exchange with BIP39 seed import Can anyone recommend a Bitcoin Gold exchange or SPV wallet for Linux that supports importing wallets from a BIP39 seed? The best I’ve found so far is a fork of Electrum that supports BTG for Windows or exchanges with no wallet import.

This doesn't answer the question directly, but Coinomi running in Genymotion works and allows restoration from a BIP39 seed, per the instructions given here:

https://medium.com/@coinomi/collecting-your-free-bitcoin-gold-btg-coins-da937d4255d1

Genymotion can run under Linux, so while it's a bit of work, one can achieve the desired outcome using this method.


How to generate random addresses from public key such that they're recoverable later using pub key only I head that from a public key, you can generate random addresses just by adding a nonce to the public key. Then, you can regenerate all these addresses again when you need, right?

If my wallet has knowledge of my public key (of course it has), it can generate lots of private/public key pairs just by adding a number to it. For example, suppose the private key is x and its public key is y. If the wallet deleted the private key x for a while, it can generate the address y+1 and be sure that when it does x+1 it will get the private key for this address in the future when it needs to spend those funds. This is a property of elliptic curve cryptography, because there's a homeomorphism between the sets of private and public keys.

I've heard that if I give someone my public key, he can derive a unique address and send to this address being sure that I'll be able to spend it because I can find the private key for that address just by adding the same nonce he used to generate its public key. The problem is:

He has to tell me which nonce was used, otherwise I'd have to try random ones till I get to the one he used. BUT, if that's how its made, then anyone can pick my public key and find all my addresses. If he really has to tell me the nonce used (suppose it's really big and random so I couldn't guess by brute forcing), then there's the risk that I'll lose it, because I'd have to keep track of all these nonces.

So how is this done? How can I, given the public key of someone, generate a random address for him such that he'll be able to get the private/public key for it later, but such that he does not need to store anything that was used to generate that address?

I believe you are talking about HD derived keys, as is the previous question you linked. HD wallet structure is laid out in BIP 32.

If someone has your parent extended public key, they can derive public extended child keys using it and an index/nonce. They must have the extended key (including the chain code) But they cannot derive the child private keys. Only you can do that, using the parent extended private key. So they can tell you the index, and anyone else with the index and the extended parent public key can see which public key was used, but the only one with the private key is you.

To derive the child keys you have to at least keep the master extended private key (or the seed it came from). Without that, you cannot derive any private keys.


How do I withdraw money from BitPay? I have funds in BitPay that I received from several sales on my website. My split is 0% USD cash and 100% Bitcoin.

Is it possible to transfer this Bitcoin balance to another account within BitPay?

Alternatively, how can I withdraw bitcoins from my account? I cannot find a withdraw option in my dashboard section.

According to their support site it should be on it's way without you doing a thing. I quote:

  If you choose to take settlement in bitcoin, BitPay will forward bitcoin payments to your bitcoin address on file. The minimum settlement is 0.01 BTC.

Maybe look on blockchain if there is an unconfirmed transaction to your address or reset Multibit if you are using that. Or you haven't hit the minimum settlement of 0.01 BTC.


Is transaction malleability the only consensus issue that needs fix to allow lightning network? Is transaction malleability the only thing needs fix in the bitcoin consensus code to enable lightning network to be implemented?

Of course, lightning network itself would need to be implemented, but I'm wondering if after fixing transaction malleability, any changes to bitcoin itself is required.

In particular, if BIP 62 is implemented, would that be enough?

BIP62 has been scrapped and will never be implemented. Instead a much better solution with many more advantages, Seggregated Wittness, has been developed and is currently being rolled out. Its finished code is in 0.13, but not activated yet on main net, that will happen in 0.13.1.

As far as I know, yes, this is the last thing required to enable LN. From what I've seen LN was actually possible without malleability fix (as proposed in the original LN whitepaper) but it would have been so much more complex and less efficient that it was well worth fixing it in Bitcoin first, which was the plan anyway even before LN was proposed.


Generate address (for receiving) on GNU/Linux without Bitcoin client? If I understand it correctly, I could generate a valid Bitcoin address (key pair) following this algorithm.

With an address generated in such a way I would be able to receive Bitcoin without ever having to install a Bitcoin client. Is this correct?

How could I follow this algorithm with common (command-line) tools, i.e. those typically available on (even older) GNU/Linux systems? (they don’t have to be installed by default, but they should be part of the distributor’s package archive)

Would there be any risks/problems using such a key instead of one generated by a Bitcoin client?

I recommend simply using vanitygen like this:

vanitygen -1 1

This will generate a small number of addresses that you can use, as well as their private keys.

vanitygen is trivial to install on any POSIX system and is proven to work.

Alternatively, you can try bitcoin-bash-tools. Source that from your .bashrc or simply run it, then you can create a new keypair with newBitcoinKey.


How are compressed PubKeys generated? Just read this: https://bitcoin.stackexchange.com/a/1715/

What is the process to generate compressed pub keys via ECDSA?

There is no algorithm for generating compressed pubkeys from private keys keys specifically.  In fact, all internal calculations involving points are done using the both the x and y coordinates of the points involved.  There is no other way to operate on points other than using the (x,y) coordinates.
A compressed representation of the point is useful in data transmission and storage because it only takes 33 bytes as opposed to 65 bytes to convey the point.  It's very easy to go from compressed -> uncompressed when the need arise to perform point related operations, and even easier to go from uncompressed -> compressed representation.
To answer your question, you would generate the public key as you normally would with an uncompressed pubkey, and when you're done, look for even-ness or odd-ness of the y corrdinate.
If it is even, encode only the x coordinate with a prefix 0x02 byte, and if it's odd the prefix is 0x03.
To go back from compressed -> uncompressed (really I just mean find the original y coordinate), you would just solve the curve's equation :

y^2 = x^3 + a*x + b

Specifically for secp256k1, the curve used in Bitcoin, a is zero, which makes this calculation easier, and there is a shortcut: due to a property of the curve's parameter p, where p ≡ 3 mod 4 we are able to derive the y coordinate from an x coordinate simply by calculating:

q = (p+1) * invmod(4)  mod p
y = powmod(y^2,q)      mod p

And there we have the original y coordinate back.


Curious about a network-based double-spending attack In their paper Two Bitcoins at the Price of One? Double-Spending Attacks on
Fast Payments in Bitcoin, Karame and Androulaki outline a particular race-attack that involves the slight control over a vendor's network connection (we need a direct connection to the vendor in this attack).  After reading it, I wondered why we couldn't connect more than one peer to the vendor.

Suppose an adversary A who owns many nodes on the network surrounds a vendor V so that V unbeknowingly is only connected to A.  That way, we could send a transaction to them, say, T_AV.  Then, when they broadcast that transaction to the network, they're just broadcasting it to the adversary, who would of course confirm the validity of T_AV.  In the meantime, so long as V isn't connected to the rest of the network they wouldn't know about the double-spend.  This would make for an attack that has feasible hardware requirements, and isn't hindered by fast transactions.

Am I missing something or would this attack work?  I'm also curious what kind of measures Bitcoin takes to prevent the controlling of someone else's connections, and what kind of counter-measures attackers have used to control someone else's connections, if any.

That sort of attack sounds definitely doable. But it's important to take into consideration the cost of this type of attack versus the cost of the thing that you're actually stealing (double-spending):

If you're buying something expensive, the vendor will most likely
require you to wait at least 2-3 confirmations, defeating the
possibility for this type of attack.
If you're buying something inexpensive, the vendor could probably accept unconfirmed transactions, opening the possibility for a double-spending attack. But as an attacker, it'll probably cost you more to pull off this kind of stunt than actually buying the thing.

In conclusion, this type of attack can probably be successful, but the costs outweigh the benefits.


cgminer settings "--load-balance" vs "--balance"? http://www.amilitalia.it/github.com/ckolivas/cgminer.html

I'm looking for the best balance:

--load-balance Change multipool strategy from failover to quota based balance

and

--balance Change multipool strategy from failover to even share balance

How exactly it works?

E.g. there are 2 pool for different alt-coins with scrypt algo.

1st pool: difficulty 1.1234
2nd pool: difficulty 10.123

Is --balance set my cgminer to 90% for the second pool? Say, it will waiting for balance of ACCEPTED shares.

And --load-balance set power of cgminer to 50%/50%?

I'm afraid that one pool might go slow, will not give jobs. Will cgminer wait for this pool with --balance to keep balance of shares?

Peoples, I know that this is very old, overgrown with moss topic. Could somebody provide me with true link to the answer?

From: https://github.com/ckolivas/cgminer/blob/master/cgminer.c

/* In balanced mode, the amount of diff1 solutions per pool is monitored as a
 * rolling average per 10 minutes and if pools start getting more, it biases
 * away from them to distribute work evenly. The share count is reset to the
 * rolling average every 10 minutes to not send all work to one pool after it
 * has been disabled/out for an extended period. */

So --balance looks to the diff1 count and tries to get an even distribution.

--load-balance looks at the --quota values and distributes work in proportion to the GCD of them, counting down until remaining quotas are all 0 and the values are reset.


Bitcoin logo in LaTeX? Is there a fairly simple way to include a standard-looking but not too elaborate "Bitcoin accepted here" logo in a LaTeX document?

Yeah, check out this answer on tex.

% arara: lualatex

\documentclass{article}
\usepackage{fontspec}
\usepackage{fontawesome}
\def\faBtc{\FA\symbol{"F15A}}
\usepackage{tikz}
\usetikzlibrary

{positioning}
\newcommand{\bitcoin}{%
    \begin{tikzpicture}
\foreach \i in {0,100}{
    \node [circle, fill=orange!90!white!\i, font=\large, inner sep=0.25ex, rotate=-15, text=white]
    (symbol) at (-1.25,1/8+\i/4000) {\faBtc};}
    \end{tikzpicture}}
\usepackage{mathtools}
\usepackage{siunitx}
\DeclareSIUnit{\btc}{\ifmmode\text{\faBtc}\else\faBtc\fi}

\begin{document}
\SI{1000000}{\btc}
\bitcoin
\end{document}


Electrum Holding Bitcoin Long Term Seed I am sure this has been asked before but I want to be absolutely sure before I start:

Using the Electrum Software I have created a basic default wallet on my desktop. I have a good deal of money stored in it and I plan to leave it there for a year, hoping the price of bitcoin will rise.

My question: If after a year, my computer hard drive fries, I forget the public and private key, I don't remember my Electrum password and I hardly even rememeber what Bitcoin is, will I be able to recover everything with only the 12 word seed I have?

I could even delete my wallet and unistall Electrum, move to Mars and if I had an internet connection and the seed gain all my bitcoin back correct?

EDIT: I just want to add, that I don't wan't to use a paper wallet just in case I decide to temporarily use some of the money although I don't plan on using it I want to have the option.

Yes, you can do all of that. To use your money, you need your private keys. Those are generated by Electrum using your seed. The password only protects the data stored on your computer by Electrum so not everyone who has access to your computer can spend your money. Spending your money without knowing your password is possible if one has your seed.

To sum it up:

Things you need to recover your wallet

Electrum (not even that much of a requirement itself but it's the easiest option)
your seed
some data (which can automatically be retrieved from the internet by Electrum (easiest way; Internet access on the computer you make the transaction on is not a requirement but nice to have.))

Things you don't need to recover your wallet*

the computer you generated the wallet on
any data Electrum stored on that computer
the same operating system you used before
the same version of Electrum you used before
the same kind of device you used before
your addresses
your public keys
your master public key
your private keys
your master private key
your wallet password
an imaginary wallet.dat (because there is no wallet.dat with Electrum ;-) )

 * Of course, some of those or a combination of some of them can be used to spend your money or to determine your wallet's seed, but that's not what you need to care about, here.

You probably still should write your seed onto a piece of paper. This – of course – doesn't mean you can't spend your money in the mean time or have to update the seed afterwards. Your wallet's seed doesn't change.


When I use the "send_many()" function in the blockchain.info api, have I to pay the fee only once or for each? The blockchain.info api looks like this:

The link is: https://github.com/blockchain/api-v1-client-python/blob/master/docs/wallet.md

But when I give a fee like this:

add={'address1':amount1,'address2':amount2}
fee=5000
pay = wallet.send_many(recipients=add,fee=fee)

Will it then be 10000 (two times 5000) or will it be 5000?

Thanks for the answers.

You will pay the fee once, since it is one transaction with multiple outputs (thus only 5000).

However, also read this


How to get all time high and low price of bitcoin and other altcoins I am fetching current price of 500 coins from coinmarketcap.com using their api for some crypto research. I also the all time high and low of these coins to see how much has the value appreciated/ depreciated since all time high / low.

Does any one know where I can find the all time high and low of the coins.
Could't find any api/website offering the same. Its okey even if its a website because, I just want fetch the data once. I can update my record if the coin hits a new high / low after that using live data from coinmarketcap.

There is a special preset for ATH on coinpaprika.com


What is 999999999999ULL I am building an altcoin based on bitcoin 0.12, in chainparams we find :

consensus.vDeployments[Consensus::DEPLOYMENT_TESTDUMMY].nStartTime = 0;
    consensus.vDeployments[Consensus::DEPLOYMENT_TESTDUMMY].nTimeout = 999999999999ULL;
    consensus.vDeployments[Consensus::DEPLOYMENT_CSV].bit = 0;
    consensus.vDeployments[Consensus::DEPLOYMENT_CSV].nStartTime = 0;
    consensus.vDeployments[Consensus::DEPLOYMENT_CSV].nTimeout = 999999999999ULL;

what is 999999999999ULL?
should I use it in mainnet parameters instead this old dates ?

   consensus.vDeployments[Consensus::DEPLOYMENT_TESTDUMMY].bit = 28;
    consensus.vDeployments[Consensus::DEPLOYMENT_TESTDUMMY].nStartTime = 1199145601; // January 1, 2008
    consensus.vDeployments[Consensus::DEPLOYMENT_TESTDUMMY].nTimeout = 1230767999; // December 31, 2008

// Deployment of BIP68, BIP112, and BIP113.
consensus.vDeployments[Consensus::DEPLOYMENT_CSV].bit = 0;
consensus.vDeployments[Consensus::DEPLOYMENT_CSV].nStartTime = 1456790400; // March 1st, 2016
consensus.vDeployments[Consensus::DEPLOYMENT_CSV].nTimeout = 1493596800; // May 1st, 2017

Thanks

These values appear for the regtest chain only.

It looks like these values are supposed to state the time window during which deployment of a particular protocol change is allowed to happen. For regtest that window is set to be from times 0 to 999999999999, maybe so that you can do it whenever you want.

For your coin, you presumably either want these features active from day 1, or not at all. In either case you'll probably want to remove the time-deployment code altogether.


bitcoin recovery when exchange ceases business I had bitcoins with Coinroom exchange but I see they are gone. They should be independent of the exchange that manages them I assume. How do I recover my bitcoins or get them allocated to another wallet? Thanks, Peter

They should be independent of the exchange that manages them I assume.

Should be
If coinroom was a regulated currency exchange then there might be some financial arrangements they would be required to make by law. There is no indication this was the case. Even if it were the case, people often set up businesses that do not obey the law, through carelessness, incompetence or deliberate criminal intent.
Cold storage
Coinroom may have claimed they kept funds in cold storage but I am not aware of any independent audit of their processes - no one can easily tell whether such claims were true.
Even if they were kept in cold storage - that does not by itself provide any guarantees about how those funds would be disposed of when the business ceases operations.
Not your keys, not your bitcoin.
When you buy BTC at an exchange, you are giving money to someone else that you trust. The exchange owns the BTC not you. What you "own" is a debt whose amount is denominated in BTC.  You have 0 BTC until you use that exchange's facilities to transfer that BTC out of the exchange and into your own standalone wallet - to an address for which only you know and/or control the private-key.

How do I recover my bitcoins

Creditors of a failed business
When you gave money to the business in Poland, you would, if prudent, have made a note of the registered company (if any), its address, registration details and it's owners and managers names etc. You could then find out the legal status of the company and if it has been placed into any insolvency process by company regulators in Poland. If so, you might be able to register as a creditor in any winding up proceedings.
Debt recovery, breach of contract etc.
You gave some money to a business in Poland. The way to recover money from a business in Poland is to engage a lawyer in Poland and see if a prosecution is possible under Polish law. This is likely to be expensive. It will take a long time (compare MtGox) there is no guarantee that this process will be successful.
Recovering stolen money
If you believe a crime was committed, you could report the crime to your local police. I wouldn't hold out too much hope of recovering your money, especially if you are not a resident of Poland.


Simple bitcoin mining algorithm I'm trying to figure out how does simple Bitcoin mining algorithm works in plain simple c or c#  or some pseudo language. I've found an example at http://pastebin.com/EXDsRbYH, but unfortunately It isn't clear what it does. I was unable to run it.

Suppose I have only one input: a Bitcoin wallet "abc..." which I would like to be used for the Bitcoins to be mined. I need simple to understand algorithm that will do the bitcoin mining on one machine with one thread on one cpu [I know it will take ages to complete :)]

The simplest miner would work like this:

Request a new Getwork from a given pool/bitcoind with specified credentials
For nonce=0;nonce<0xFFFFFFFF;nonce++

Set Getwork Data nonce
SHA-256 hash the Getwork Data (block header)
Check if hash result is smaller than Getwork Target, if so, submit a share
If more than 1 second passed since you received Getwork, stop the loop

GOTO: 1

Now, if you want something that could rise up to par with currently used miners, you need to consider:

OpenCL calculations, without this you will never get the high hashrates of graphic cards.
Midstate, or in other words hashing optimization. First half of Getwork Data doesn't change, so no point in calculating midstate for each hash.
Longpolling, makes you calculate less stale blocks.
Rollntime, minimizes communication with the pool.


LND Security best practices? Disaster recovery? Can anyone share a knowledge how to

_ secure LND node

_ backup node with all Channels

I think only a seed will not be sufficient.
What is your plan B in case of disaster? How to do an  Emergency restore, migration to other server, or set up high availability solution?
thanks

You can secure an LND node in the same way how you would secure any host on the internet. You can for example use ufw to set up a firewall. You could also have a physical firewall in front of you node. Also a big step towards security would be to run no other software on the node.

As for backups it is a little bit more tricky. The seedwords will not include the state of all of your channels. With the current channel design you cannot restore an old backup. As an old channel state would - following the protocol - allow your channel partners to claim all bitcoins in that channel. However you can use a distributed file system or a distributed data base to store your channel state. If configured properly writing to the file system or database will certainly be slower as all calls have to be synchronized and blocking.
Also you could at least have a raid system that helps if a disk crashes.

Generally you can shutdown your lightning node and migrate it to another computer by copying the database. As mentioned again it is tricky as you really have to make sure that you don't migrate old state. I have a video showing this for c-lightning. The process for lnd should be similar.


The transaction, like the block, is in a serialized format. A description of the format is available on bitcoin.org


How can I avoid re-using a Bitcoin address more than once? I have a fundamental confusion regarding Bitcoin addresses. Apparently, addresses are only intended to be used once for security and privacy reasons (see here, for example). If I think of addresses as storing Bitcoins, then there seems to be a basic problem with this, which is that once some Bitcoins have been sent to a given address, they would never be able to be spent since that address must never be used again.

Clearly I have a misunderstanding of the connection between addresses and Bitcoins, and yet I can't find the resolution.

Address should not be used to receive bitcoins more than once, meaning each time you receive bitcoins you should use a fresh address. Of course, once you receive bitcoins at an address, you will want to spend them in the future, and that is fine. Ideally, an address is received to once, and then later spent from once.

The 'single spend recommendation' is sort of automatically enforced: when spending a UTXO, it is not possible to spend only part of the bitcoin, the entire UTXO must be consumed. So you just need to make sure you do not re-use an address to receive bitcoin / as a change address.

Perhaps the biggest reason this is recommended is that single use of an address preserves your privacy, as well as the privacy of those you interact with.


Tell me what it means blockinfo? If you can please me more.

bitcoin/src/test/miner_tests.cpp

Here is an example code.

https://github.com/bitcoin/bitcoin/blob/master/src/test/miner_tests.cpp#L43-L72

It is a variable name.

It holds the nonces needed to build a test blockchain.


Can I use walletnotify or blocknotify remotely with a NodeJS application? I'd like to get information from my bitcoin node running on a cloud server to be used to make changes in my NodeJS app running on my computer. So, in the bitcoin.conf file, should I have something like walletnotify=curl http://My.IP.Address:PortAppUses/walletnotify.js?tx=%s? If that's right, what do I write in the walletnotify.js file to simply save the incoming transaction id as a variable?

In your example you are telling it to place the transaction id as a GET request in the URI under the tx parameter.

walletnotify=curl http://My.IP.Address:PortAppUses/walletnotify.js?tx=%s

All you would need to do inside of walletnotify.js is pull the tx GET, in nodejs express that would be something like:

const express = require("express");
const app = express();
const request = require("request");

app.get("/", function(req, res){

    let transactionId = req.query.tx;

    //do whatever with transactionId

});


Unspent outputs get spent automatically After generating a 2-out-of-3 wallet (using brainwallet http://ms-brainwallet.org/#generator) I am able to store my private/public keys for each of the participants.

Afterwards I send a small amount of BTC to this address (0.0002). The amount is correctly recorded and confirmed in the blockchain and is listed as an unspent transaction.

Afterwards I create a new transaction that spends (0.0001 BTC). This transaction is successful. On the third step I sent more funds to the 2-out-of-3 wallet (0.0003). This is where the issue happens: any funds I deposit in this wallet from second transaction on are automatically spent towards various unknown addresses, and there is never any unspent transactions no matter how much I deposit there.

I have tested this with several wallets already.

What I am thinking of is that there is a change problem. I found some ways that funds can 'evaporate' but I haven't been able to nail the issue completely. Any inputs would be appreciated.

My guess is that you are using weak passphrases to generate your keys. This is a common mistake with brain wallets. It is well known that there are bots that scan the blockchain for any unspent coins contained in an address generated from a weak passphrase and takes it for itself. I've not heard of a bot that looks at multisig p2sh addresses for weak passphrases, but I'm not surprised that it exists. It's not that much different than looking for weak passphrases in a standard pay to pub key transaction.

The reason why I think this is the case is because your coins get taken from the multisig address after you've made one transaction from the multisig address. When you make a transaction from the multisig address, you reveal all the public keys that the multisig address is associated with. If the passphrase associated with the key is weak, the private key can be cracked by the bots and your coins will be gone.

If your coins were taken before you've made a transaction from the multisig address, this could mean that your computer or the brainwallet generator is compromised. It is also possible that there is a bot that can crack a p2sh multisig address without knowing the public keys (this is doable but since the search space is bigger it would be harder for the bot).  But since this is not the case, it seems pretty clear that you are using weak passphrases to generate your keys.


p2pool inbound connections I am trying to get inbound connections on my p2pool instance. I currently have 6 outbound connections and the pool is working fine, but I would like to have more connections (might help get a few less shares, and if nothing else help the network a little bit).

I have been looking around how to do this, it seems like you need to set up a port forward to port 9332 (or 9338 for litecoin). I have never done this before, and have a few miners which are doing OK on my existing pool so before I go ahead and ruin my p2pool node I thought I'd reach out and see if anyone had any experience they would like to share :)

I am using Ubuntu 12.04 (64-bit), thanks for your help!

From what we have noticed on LBTC Grid, out refers to connecting to coin network and the P2Pool network. In refers to miners connecting to your server.


Why do wallets use multiple private keys instead of one each? I am learning about Bitcoin and when I was about to export my private key from a single electrum wallet, I found that there  were in fact a lot more than one. Why is that so, don't you only need 1 private key to hold all bitcoins and manage them?

Why is that so, don't you only need 1 private key to hold all bitcoins and manage them?

Sure you could use only one private key and its associated address, but that is not recommended. It is more secure and more private to not reuse addresses. Instead you should use a new address for every transaction you receive and for every change output you make. Thus your wallet will have multiple private keys for the multiple addresses that you are using.


Can I mine bitcoin without damaging my hardware? I have a 900w gold certified power supply, an AMD fx 6350 @ 4.39ghz, a nvidia gt 630 2gb GPU with a fan and 8GB DDR3 RAM at 1600MHz. I'm wondering what mining for about 8 hours a day would do to my hardware. I'm not concerned about my graphics card as I only use it for mining but my CPU, RAM, motherboard and other components I am concerned about. My case has very well airflow with 3 exhaust fans and 2 intake, I also have aftermarket cpu cooler. This would be my first time mining along with using this site and I'm curious on whether or not it will do any damage or degrading to my PC.

Thanks

That would depend on your definition of damage.

First of all your equipment is going to 'wear down' much faster if the CPU is at 100% load longer than an hour or so. Normal computer usage lets the CPU throttle somewhere between 20% load and 100% for let's say 6 to 8 hours a day. CPU coolers are made to prevent the CPU from overheating in all possible situations, so it won't burn out your CPU immediately.

But with normal computer usage your CPU will heat up, cool down a bit (a bit less hot), heat up again, etc. With mining on a CPU, the CPU will heat up and continue heating up to the point where the heat exchanged by the CPU cooler will be equal to the heat produced by the CPU. This is called an equilibrium (or balance).

There are temperatures your PC would be OK with running 24/7, but that does not mean anyone would recommend you doing so. You won't ruin your computer right away, but the chances of it will definitely be higher.

Next to that, the amount of bitcoins you can generate letting your CPU mine bitcoin right now (December 2014) would be around 0.00000001 a week... ? That's about accurate. (Not taking power usage into account.) If you really want to mine cryptocoins on your CPU, look for a CPU-only cryptocoin and then exchange the mined coins to Bitcoin, that way you'll get much more in most cases.

If you absolutely want to mine Bitcoin directly without mining an altcoin, look at this: How do I start mining?


Blockchain 2 days still no confirmation I am so much worried. I don't know what to do.

https://blockchain.info/tx/41112430b191b5be2b4cd26e6f4203f3156f4437c72bd2ef242f0e9f15f75c82

Can you see blockchain?
https://blockchain.info/en/unconfirmed-transactions
If unconfirmed transaction will be less as now (~70 000) then you will see your btc ;)


Is it required to have an electrum account for electrum api usage? Is it necessary to have an account on electrum in order to build a custom BTC wallet interface using electrum-apis where user can create multiple wallets, address, send/receive transactions?

Or, there is no login credentials required for me to integrate all the features of Electrum into my application?

It is an open-source software. There's no need for credentials or accounts.

There's multiple public electrum servers you can connect to through your electrum wallet. You could build an interface on top of the electrum wallet that connects to any of these servers.


In Proof-of-Stake, can the same miner mine a block multiple times in a row? In Proof-of-Work, there are no rules on who will mine the next block - the selection is random and proportional to miners' computing power.

How is the next miner selected in various Proof-of-Stake block creation algorithms? Can the same miner / address / person be chosen to create multiple blocks in a row, or are there some mechanisms preventing this from happening?

Can the same miner / address / person be chosen to create multiple blocks in a row

Yes, a single entity can mine multiple blocks in a row with no ill effect.

  are there some mechanisms preventing [multiple blocks in a row from one entity] from happening?

The sybil problem makes this fundamentally impossible; if there was a way to stop a person from pretending to be multiple entities at once, proof of stake and proof of work would not need to exist in the first place. In a naive attempt at this if you prevent a specific key from signing two blocks in a row, then the user would simple split their money into multiple keys.

  How is the next miner selected in various Proof-of-Stake block creation algorithms?

In some implementations of proof of stake the selection is simply based on the previous block hash as a random oracle. ECDSA signatures can have a practically indefinite amount of permutations which allows a user in the network to simply sign repeatedly until the next "random" selection is also them, amplifying their income or ability to warp the network. This is commonly known as stake grinding.

In an attempt to fix this other implementations use either a block hash from a long time ago, or the hash of some period of blocks in the past. The intention of this is that an attacker would supposedly need to control all of the blocks in that period (or be extraordinarily lucky) in order to be able to re-sign and jump ahead with their new control.

There's other selection methods in existence but the enormous number of implementations make it extremely hard to research for this question, however they are likely variations on the same concept in some way. There's some more discussion of the general problems of proof of stake available for digestion in pos.pdf.


Can full node with only IPv4 connect to another full node with only IPv6? As far as I know, IPv4 and IPv6 are two different protocols and direct connection between an IPv4 and IPv6 cannot be established.
If I run a full node with only IPv4, can my node connect to another node with IPv6 only?
If no, why do I sometimes see my node's peers are IPv6?

Likewise, is it true that nodes with IPv6 can only connect to other nodes with IPv6?
Since there are only about 1000+ IPv6 full nodes in the network now, isn't that they have much fewer choices of peers?

No. IPv4 can not connect to IPv6. They’re almost completely disjoint networks except for the fact that some nodes can be dual stack with both, or many of each type routed.


Add dependency Bitcoin Core I'm trying to add a new dependency to my Bitcoin Core fork. The dependency is Rapidcheck, a property based testing framework.

I've added a file called rapidcheck.mk inside of depends/packages with the following content

package=rapidcheck

$(package)_version:1.0

$(package)_download_path:https://github.com/Christewart/rapidcheck/releases/download/1.0

$(package)_file_name:rapidcheck-1.0.tar.gz

$(package)_sha256_hash:c228dc21ec24618bfb6afa31d622d1f4ea71168f04ee499e1ffcfc63cd5833f4

define $(package)_preprocess_cmds
  mkdir build
endef

define $(package)_config_cmds
  cmake -DCMAKE_INSTALL_PREFIX:PATH=$(build_prefix)/bin ..
endef

define $(package)_build_cmds
  $(MAKE)
endef

I've also modified the depends/packages/packages.mk file to add rapidcheck

Now it looks like this

packages:=boost openssl libevent rapidcheck
darwin_packages:=zeromq
linux_packages:=zeromq
native_packages := native_ccache native_comparisontool

qt_native_packages = native_protobuf
qt_packages = qrencode protobuf

qt_x86_64_linux_packages:=qt expat dbus libxcb xcb_proto libXau xproto freetype fontconfig libX11 xextproto libXext xtrans
qt_i686_linux_packages:=$(qt_x86_64_linux_packages)

qt_darwin_packages=qt
qt_mingw32_packages=qt

wallet_packages=bdb

upnp_packages=miniupnpc

darwin_native_packages = native_biplist native_ds_store native_mac_alias

ifneq ($(build_os),darwin)
darwin_native_packages += native_cctools native_cdrkit native_libdmg-hfsplus
endif

I've run make clean && make after doing all this and added the include <rapidcheck.h> to a file in the test/ dir. I get an error saying that the file could not be found. What step(s) am I missing?

You can see my commit for these changes on my bitcoin core fork here

Make sure to build the dependency:

cd ./depends/
make

And then tell bitcoin where to find the dependency:

cd ../
./configure --prefix=`pwd`/depends/x86_whatever_your_current_arch_is

Further information:

https://github.com/bitcoin/bitcoin/blob/master/depends/README.md#usage


How can I recover from a corrupted blkindex.dat on Ubuntu 12.10? I've installed Bitcoin-Qt after a clean WUBI install, and installed Bitcoin-Qt directly. Now it suddenly says "Error loading blkindex.dat".

I assume my blkindex.dat file is corrupted, and I tried reinstalling Bitcoin-Qt with apt but it didn't work. Maybe if I delete the blkindex.dat file it will try to create it again, but I don't know where the installation folder is.

How can I solve this issue?

Extra information (added by other user); the error will likely look like this:

file blkindex.dat has LSN 727/2518588, past end of log at 727/1519938
Commonly caused by moving a database from one database environment
to another without clearing the database LSNs, or by removing all of
the log files from a database environment
__db_meta_setup: /home/user/.bitcoin/blkindex.dat: unexpected file type or format

You should be able to find this in ~/.bitcoin/db.log. This problem occured when interrupting the client suddenly or maybe because two of them opened the database at the same time.

On Linux, the Bitcoin client data is kept in the .bitcoin directory in your home directory. Go to ~/.bitcoin/ and you'll see the files in there. You may need to toggle Show Hidden Files in your file manager in order to see the directory.

If you remove blkindex.dat, the client will have to redownload the blockchain. I just tested this locally by moving my copy of the file to another file name temporarily - the client resync'd.

Since your copy of the index is corrupted apparently, it sounds like you need to delete it and resync.

A note: be careful to do not erase your wallet.dat. I recommend you back it up before. Your wallet.dat is your private keys.


rpc error: code = Unknown desc = dial tcp 103.102.44.207:9735: connect: connection refused I'm getting connection refused when I try to connect to a public testnet node.

lncli --network=testnet connect 022ff54505fe9b50ce6c3c99c645c9aab67fe91abb01504c5211045b82a09aa757@103.102.44.207:9735

Error

[lncli] rpc error: code = Unknown desc = dial tcp 103.102.44.207:9735: connect: connection refused

You need to connect to a node which has:

RPC enabled
username and password are known
client IPs are whitelisted using rpcallowip
the router has its port forwarding enabled.

Usually, public nodes don't share their RPC parameters, because that'd be very insecure. My advice is, run your own node. Otherwise, you could use the experimental neutrino client.


How has the Bitcoin average block size recently risen above 3 MB? I was aware that the block size could rise above the 1 MB cap due to SegWit. However, my understanding was that the block size would still be limited under SegWit.

My understanding of SegWit is that it partitions the signature part of the block from the transaction part. I also believe I read that the signature part can account for 65% of the block size. If this is true, I would be under the impression that the maximum block size with SegWit would be 1 MB * (1/.35) making the theoretical maximum 2.85 MB.

Is there a way to calculate the theoretical maximum allowed in Bitcoin blocks and where is my understanding above flawed?

I also believe I read that the signature part can account for 65% of the block size.

This is not entirely correct. The typical size of a block depends on the make-up of transactions in that block. The size of signatures to overall block size will depend on the number of inputs in a transaction. More the number of inputs in a transaction, higher the signature components and higher the ratio of signature size to block size. Also, higher the number of multi-sig inputs, more the signature components per input. Also, one has to note that both the signature and the redeemScript form the part of the witness, and not just the signature.

  Is there a way to calculate the theoretical maximum allowed in Bitcoin blocks and where is my understanding above flawed?

Yes, the theoretical maximum limit of block size is 4,000,000 WU. To calculate size in bytes, it will be very very close to 4,000,000 bytes. Consider a block made up of only one transaction, with only one OP_TRUE anyonecanspend output in that transaction and only one input. Assume the redeemScript and signature are so big that they take up the maximum allowed space in the block (Bitcoin supports custom scripting, so I can theoretically create a script in that way). Now, the standard components of the a block are:

size = 4 bytes / 16 WU
block header = 80 bytes / 320 WU
transaction counter = 1-9 bytes (1 byte in our case as we use 1 tx) = 4 WU
Transactions = variable

So this leaves 4,000,000 - (16 + 320 + 4) = 3,999,660 WU for our transaction.

Standard components of the transaction are:

nVersion = 4 bytes / 16 WU
number of inputs = 1 byte / 4 WU
previous transaction txid = 32 bytes / 128 WU
previous transaction output index = 4 byte / 16 WU
script length = 1 byte / 4 WU
script = 0 byte
nSequence = 4 bytes / 16 WU
output count = 1 byte / 4 WU
amount size = 4 bytes / 16 WU
script length = 1 byte / 4 WU
script (OP_TRUE) = 1 byte / 4 WU
nLocktime = 4 bytes /16 WU

so witness size is: 3,999,660 WU - 228 WU = 3,999,432 WU

Now, to convert this to traditional bytes that would be relayed on the wire:

340/4 + 228/4 + 3,999,432 = 3,999,574 bytes

Note: Standard transaction weight is 400,000 WU, which means full nodes won't relay transactions higher than this cap. However, consensus rules allows transaction to be as high as the block size, which means nothing stops a miner from including this transaction in a block and then mine the block with it.


Can old wallet.dat (offline long time) still receive money? I have an old wallet.dat file (from a backup) and no client installed since a very long time. Recently some transactions have been made (BTC have been sent to my address).

Will this old wallet.dat file allow me to be the owner of the new money? I’ve read that 100 private keys are generated in advance and are in stock of the file. Does that mean, that I can receive 100 transactions after taking my client (it was bitcoin-qt/bitcoin-core) offline? Or what are these 100 keys for?

Can old wallet.dat (offline long time) still receive money?

Yes. If you have the addresses from that wallet, coins can be sent to those addresses.

  I think that I remember that 100 private keys are generated in advance and are in stock of the file. Does that mean, that I can receive 100 transactions after taking my client (it was bitcoin-qt/bitcoin-core) offline?

An address can receive coins more than once, although it's considered best practice to try to avoid that. But, in practice, you can receive many transaction that pay to any of those 100 addresses.


I lost my computer, inside my hive wallet , I do have my adress and password can I recover my bitcoins? Is it possible to login from other wallet with adress and password to get back my btc?

The address is useless, the password insufficient. You need to have a backup of your wallet, or know the mnemonics for the seed. Otherwise you can't recover your coins.


Determine which transaction output is a change address and which is not Is there a way to determine which transaction output is a likely a change address and which is not?

Looking at this transaction, there are two outputs - a change address and the output address. Blockchain.info says "Estimated BTC transacted: 0.5 BTC", but I'm not sure how it's estimating that.

You can guess at which output is a change address, but the only way to be certain is if you are the person initiating the transaction.

In fact, some wallet software could be designed to intentionally obfuscate this data, to improve user privacy. At best, services like blockchain.info can only guess.


Can you go backwards in a block chain? Can you go backwards in a block chain to unhash an old ledger and see the transaction details?

There seems to be a fundamental misunderstanding of how blockchains work. There is no hashing and hiding of transactions. Transactions are identified by their hashes and the hash is stored in a block, along with the transaction. There is no need for "unhashing" to see transaction details, the details are all there.


Could bitcoind support SPV mode by setting different args There are multi nodes type could be used in bitcoin network.

Could bitcoind support running different types of nodes by different sets of args?

I found many discussion here, but seems no clear conclusion.
Is there a light (SPV) version of bitcoin core (bitcoind)?

Per my understanding, if we use pruning, the node will drop the previous data block, and can not preserve all the transactions of a specific address set.

No. bitcoind does not have a SPV mode at all.

Pruning is not the same thing as SPV because a pruned node still downloads and verifies the blockchain. Just instead of storing all of the blocks in the blockchain, it discards  blocks when they become deep enough in the blockchain. This reduces disk usage but does not effect security, bandwidth usage, or initial sync time. Pruned still receive all blocks and transactions, validate them, and relay them.

Conversely, SPV wallets do not even download or verify the blockchain at all. They only do simple verification, not full verification. SPV wallets only download block headers and check the proof of work. They do not and cannot check entire block validity like full nodes can. This allows SPV wallets to have a much much faster initial sync time at the cost of security. SPV wallets do not receive all blocks and transactions and thus cannot validate or relay them.


How to get latest 50 transactions for a BCH address? Is there an API from where I can get latest received transactions for a bitcoin-cash address?

you can search to find it. there are a lot of API,s which help you.
as an example try https://explorer.bitcoin.com/bch.


Bitcoin HD Wallets with hardened derivation and watch-only addresses I'm learning about the details of how HD wallets work. After reading the BIP32 and BIP44 documents thoroughly and supplementing it with Mastering Bitcoin there's still on aspect that I can't figure out.

Say I derive an extended private key with the BIP44 first account, first address path path: m/44'/0'/0'/0/0 and then I convert the extended private key into an extended public key.

Based on what I've read so far proper way would be to take the extended public key and work with an entirely non-hardened path like: M/0/1 , M/0/2 ?

Is this the correct way to do it ? My problem is that a public key of M/44'/0'/0'/0/1 will not be the same as M/0/1.

I'm just trying to make sure I'm using the derivation paths correctly. Thanks a lot!

Use the master key (call it m) to derive m/44'/0'/0'. This will give you a pair of public/private keys, let's call them xpub-a and xprv-a.
Now you can take xpub-a onto your online machine, and use xpub-a to derive receive addresses (xpub-a/0/0, xpub-a/0/1, etc) and change addresses (xpub-a/1/0, xpub-a/1/1, etc).
In this way, you've used hardened derivation concatenated with non-hardened derivation for your change and receive addresses. Your final addresses from the path of your master key (m), will then be:
Receive addresses:
m/44'/0'/0'/0/0
m/44'/0'/0'/0/1
... etc.
and Change addresses:
m/44'/0'/0'/1/0
m/44'/0'/0'/1/1
...etc...
Example using bip32:

let master = bip32.fromBase58('xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi')
let final = master.derivePath("m/44'/0'/0'/0/0")
let middle = master.derivePath("m/44'/0'/0'").neutered() // "neutered" removes the private key
let final2 = middle.derivePath("0/0");
// observe that final.neutered().toBase58() === final2.toBase58()


Can I mine with BFGMiner on an ATI Radeon I have managed to connect to the pool via the command line but when I went to manage devices it says I have none. I tried to use auto and all commands to add the GPU and seemingly it will not pick it up.

Is it even possible to use a amd m880g?

Any advice appriciated

EDIT
I have also found the same is true with cgminer. Is it impossible to use this card?

You need to use cgminer-3.7.2 or earlier.  For some reason, GPU mining was removed from subsequent versions.

Cgminer is the best available miner for your purposes.  Con Kolivas is one of the world's great programmers, and we are lucky to be able to use his software.

Please also be sure to read the file SCRYPT-README to get reasonable performance.


Is the idea of fraud proofs possible in reality? I once read this on Twitter, which is said by Luke Dashjr, a Core dev:

  The original design was to have full nodes create proofs of invalid
  blocks, to alert SPV nodes to them. SPV nodes would then verify these
  proofs and reject the invalid blocks. But it turns out, it isn't
  possible to prove a block is invalid.

So I wonder whether the idea of fraud proofs is actually possible? If not, why?

The whitepaper said that SPV clients would avoid accepting a rules violating block by being altered to the violation, downloading the block, and checking for themselves. This is not realistically possible in the protocol as it exists today because the commitment structure means that for many rules the smallest amount of data you must download to tell if a block is actually invalid is the entire chain-- even if you have a peer that knows where the invalidity is. For example: if a transaction spends a vin txid that never existed in the chain currently the smallest amount of data you need to verify a claim that it didn't exist is the whole chain.

Back in 2012/2013 I proposed an additional set of commitments that would make what the whitepaper described possible by allowing the alerting peer to point you to the invalidity (thus calling it "fraud proofs"). For the above invalid-vin example fraud is proven by having every block commit to where in the chain their inputs came from and simply showing those commitments to the querying lite client. Unfortunately, even that isn't that sufficient: a miner producing an invalid block could decide to only serve SPV requests and keep the invalid part hidden from every full node that could alert others to the invalidity.

In 2014/2015 I proposed that clients sample from a locally decodable error correcting code to make it difficult for a malicious block to serve parts of the block without indirectly serving the entire block.  Unfortunately, the result has high overhead to only achieve a relatively low level of security against falsely accepting an invalid block and as a result no one in the Bitcoin space currently seems all that interested in exploring that sub-idea further at this time.


What applications of clients use bitcoin JSON-RPC? As far as I understood, the Bitcoin JSON-RPC is one of the ways (if not the only way) in which applications can be built that can access the bitcoin wallet. So, the RPC server here gives that access and any client (or app) can access via APIs.

So far, I have just figured our that only bitcoin-cli is such a local application which uses the RPC. Are there any other examples where the JSON-RPC is used?

In other words, are there any Desktop apps (mainly) that can access the bitcoin wallet.

As far as I understood, the Bitcoin JSON-RPC is one of the ways (if
  not the only way) in which applications can be built that can access
  the bitcoin wallet.

There is also a REST interface, but that is for read-only type commands like getting blocks or transaction info.

  So far, I have just figured our that only bitcoin-cli is such a local
  application which uses the RPC.

bitcoin-cli is just a cli interface to the RPC, it doesn't really do anything on it's own. Also, the RPC interface isn't just for wallet commands. A list of commands can be found in the documentation at https://bitcoincore.org/en/doc/0.16.2/. The commands expose functionality including:

blockchain
control
generating
mining
network
rawtransactions
util
wallet

  Are there any other examples where the JSON-RPC is used?

Many software libraries will communicate with the Bitcoin Core RPC, too many to list, but this might be a good start: https://github.com/igorbarinov/awesome-bitcoin. Not all use the Bitcoin core RPC, some implement their own full node (like copay).


Which API provides the logo for a cryptocurrency? I've been searching for an API that returns the logo/image for a cryptocurrency. API's like CoinCap.io and Bittrex don't return this information in the response. Is there any public API which provides the logo for a specific cryptocurrency?

You can use their css class

http://coincap.io/css/spritesheet.css?v=1_6_1

attach it in your html file and call it like that for bitcoin logo:

But you have to contact them for copyright measures.


How do I view the extended public key in Electrum? Someone's asking for my extended public key.

How do I view this?

What are the consequences of giving this to someone? Can they steal my Bitcoins if I give this to someone?

How do I view my extended public key?

Go to Wallet > Master Public Keys, and copy the text that starts with xpub

  What are the consequences of giving my extended public key to someone?

They can view all of the transactions and addresses in your wallet. They can generate as many of your addresses as they want.

  Can they steal my Bitcoins if I give this to someone?

No, unless you also give them one of your private keys. (All of your private keys are equivalent if they have access to your extended public key.) So, don't do that.


Why is the relationship between tx and block many to many? I was looking through the code for ABE, and I discovered that the relationship of blocks to transactions is many to many.

Why are some transactions stored in the transaction lists of multiple blocks?

Within one chain of blocks, every transaction can only occur once. However, the data structure people frequently call "the block chain" is actually a tree structure, with one root (the genesis block) and different branches. The longest valid branch of this tree is called the active block chain, but occassionally, during a reorganisation, nodes switch to another branch (usually only the last 1-2 blocks change). Any transactions that were in the old branch but not in the new are then attempted to be mined again when possible. This results in one transaction being in several blocks within the tree - but not the same chain.

There existed another way. Early on, there was a possibility for two coinbase transactions to be identical. This occurred in blocks at height 91842 and 91880. It has since been made illegal and later impossible through BIP30 and BIP34.


Is there a time limit how long a signed transaction is valid? When splitting coins from a hard fork and signing the transaction on the forked coin, is there a time/block limit when the transaction gets invalid on the BTC chain, so a potentially possible replay attack gets invalid forever?

Imagine this scenario: You successfully split 1 BTC and 1 BXX (which has no replay protection) from address A to B and C. At some later point you forget about it and send 2 BTC to address A. Can the old 1 BXX transaction be used to replay A -> C in BTC?

Bitcoin is not an account based currency like Ethereum, which track the balance in addresses. Instead it is a UTXO based currency. In a UTXO-based currency, funds are tracked in portions called "Unspent Transaction Outputs", these are uniquely identified through their history, specifically through the transaction id that created them. Any new money moved to the same address would have a different history and thus would not be replayable.


Running full node over Tor I am attempting to run a full bitcoin-core (v0.13.1) node over the Tor network for the first time. I have set up my /etc/tor/torrc file with the following two lines:

HiddenServiceDir /var/lib/tor/bitcoin_service/
HiddenServicePort 8333 127.0.0.1:8333

I have set up a file ~/.bitseed/bitseed.conf with (not sure this is required)

onion=1

I retrieved my onion address from /var/lib/tor/bitcoin-service/hostname allowing me to set up ~/.bitcoin/bitcoin.conf with settings such as:

onlynet=onion
onion=127.0.0.1:9050
listen=1
bind=127.0.0.1:8333
externalip=<my-onion-address>
seednode=wxvp2d4rspn7tqyu.onion
seednode=bk5ejfe56xakvtkk.onion
seednode=bpdlwholl7rnkrkw.onion
seednode=hhiv5pnxenvbf4am.onion
seednode=4iuf2zac6aq3ndrb.onion
seednode=nkf5e6b7pl4jfd4a.onion
seednode=xqzfakpeuvrobvpj.onion
seednode=tsyvzsqwa2kkf6b2.onion
banscore=10000
bantime=11

It seems to be working as I can see my mempool growing from the debug file, and I have one inbound connection. But my connection count is very small (2 or 3). Is there anything else I need to do? In particular, I wanted to confirm that I have no need to set up my firewall ufw to accept connections on port 8333 (or 9050) in order to achieve inbound connections, and I have no need to redirect port 8333 or 9050 from my router to the fixed local ip address of my machine (setting up ufw to allow 8833 and redirecting port 8333 from router would be required if I was running a normal node).

EDIT: 9 connections of which one inbound, but this single inbound connection is myself. So the question really is: How do I allow inbound connections?

EDIT2: I am now of the opinion that this setting is correct. I was wrong to think a prior inbound connection was to 'myself', after 24 hours I have seen a peek of 4 inbound connections. I can confirm there is no need to tweak ufw or change any of your router settings (the tor protocol is not affected by either of these), and this seems to be working having tor on top of a VPN connection (bitmask). Hence I have no more questions but happy to stand corrected if any of the above is wrong.

Your settings look correct for the versions you would have been using, I do not know about bitseed.conf however.

For a more up to date guide for setting up Bitcoin Core to run over Tor, you can try this question. Bitcoin Core now supports automatically configuring an ephemeral Tor service, for example.


What transaction was processed in the beginning? If there were very few coins available and people had to "mine" before they earned coins in the beginning.

What were they mining if there were no transactions to process? ie. no one had any coins to spend and if you arent spending there aren't any transactions to process to earn points. Seems like a chicken and egg scenario.

Creating blocks without transactions is trivial, valid, expected under certain circumstances, and in fact happens all the time.

There is no chicken-and-egg problem. The first blocks were just empty.


Is there a public API server for Stellar? I'm writing a Stellar application. I'm looking to use the API provided by stellard without running a copy of it myself.

Is there a public API server for Stellar?

Yep:
https://www.stellar.org/api/

Stellar Foundation runs two instances of stellard you can use if you
don't want to run your own.
network   address           RPC Port  Websocket Port
test          test.stellar.org 9002          9001
live           live.stellar.org 9002          9001


What backward compatibility testing is done on Bitcoin Core? The unit and functional tests of the latest release of Bitcoin Core obviously test the codebase of that release.
What backward compatibility testing is done to ensure the latest release passes previous releases' versions of the unit and functional tests?
And conversely what backward compatibility testing is done to ensure previous releases pass the current unit and functional tests?

What backward compatibility testing is done to ensure the latest release passes previous releases' versions of the functional tests?

There is a feature_backwards_compatibility.py functional test which spins up functional test nodes from each of the previous releases to do testing between them at the same time.
Once you have built the latest version of Bitcoin Core you can download the previous release binaries using:
test/get_previous_releases.py -b v0.19.1 v0.18.1 v0.17.2 v0.16.3 v0.15.2
You can then run the feature_backwards_compatibility.py test individually or through the test runner.
e.g. test/functional/test_runner.py feature_backwards_compatibility.py
This test is updated with each new release to add a functional test node from the latest release to functional test nodes from previous releases.
At the time of writing (December 2020) there is an open pull request from Sjors Provoost to add v0.20.1 to the backwards compatibility test.

And conversely what backward compatibility testing is done to ensure previous releases pass the current unit and functional tests?

I don't know at this stage if this in any way a priority (or for that matter whether it should be). It is certainly more resource intensive to build entire previous releases and then test them rather than merely spin up functional test nodes from previous releases. (I will update if I learn more.)


Best way for anonymous purchases (for small amounts only) with credit card or Paypal if you have Bitcoins to spend? Bitcoin-OTC? No name credit card? Obviously if you are American or you live somewhere where you have the opportunity to just buy a Visa (or Mastercard) gift card in a store for cash: you can't go better than that. But I don't have that opportunity around my country.

So how would you pay someone (not a big amount) with credit card or Paypal if these are the only payments accepted by the merchant and you simply want to stay anonymous?

If I understand correctly, the hefty fees are if you want to exchange credit card or Paypal to bitcoin because they are reversible payments but for the other way around (bitcoin to credit card or Paypal) there shouldn't be extra fees, correct?

Is Bitcoin-OTC the place to go? What are best practices for this procedure? Is there a newbie-friendly non-techie guide to Bitcoin-OTC?

Is there such a thing as a truly legitimate no-name reloadable Visa/Mastercard or only the once-loadable gift cards are available?

Taking a quick look here: https://en.bitcoin.it/wiki/Selling_bitcoins reveals that BTC-E is capable of doing PayPal withdrawals.

I'm not sure how closely it meets your requirements, and PayPal clearly requires you to provide personally identifiable information, but it could be helpful.


Multisig Addresses for Trading Currently, trading on centralized exchanges requires one to keep their funds on the exchange, with the private key controlled by the exchange's server.

Wouldn't it be possible to give people multisig addresses, perhaps in a 2 or 2 configuration or 2 of 3 configuration, where the exchange has one key and the user has the other keys, and giving people the capability of maintaining a known balance and placing orders on the order book with that balance.

Buy example:
When Alice buys Bob's bitcoin or cryptoasset, the exchange places the transfer with Bob's key (notifying Bob) and extends credit to Alice in the GUI, so Alice has "unsettled funds" but may be able to keep trading to an extent. Bob has to authorize the actual trade with his remaining keys, and may be limited in doing anything else on that site until he does authorize it.

The risk here is that Bob never authorizes the transaction, or too many users never authorize, bring the exchange's margin capabilities to a halt.

The benefit is that an exchange being hacked wouldn't result in massive amounts of cryptocurrency being stolen, and I think the risk parts can be mitigated.

Is this a practical possibility?

This has several downsides for the exchange:

It's complicated. The best the exchange could do is to offer both the way it's currently done and your way. Users will hear that your method is to their advantage and attempt do to it your way. Many will find it too complicated and use a different exchange or lose interest in acquiring money in bitcoin altogether.
The exchange now has to maintain 2 systems. More diversity means higher development costs, more personnel training, more maintenance, and more error-proneness. Overall higher expenditures and more ways to fail.
Users will think their money is now at the exchange and delete their wallets. If it sounds stupid to be done and can be done by users, it will be done. The exchange then has to explain to the users that their money is gone and there is nothing they can do about it. Which is also part of the next point.
There will be more support requests.
It takes control away from the exchange. Right now, if someone jumps off, the exchange still has the money and give it back to the other person. In your system, the exchange has to explain to the other person why the deal can't happen. This can cause trouble in some jurisdictions as the exchange may be the legal trading partner for both.
Right now, exchanges have a lot of funds deposited on their systems. If a user never accesses their account any more for whatever reason (bus factor, user forgets about it, etc.), that's effectively profit for the exchange.
Entities equipped with a lot of money have a tendency to gamble with it. That's not possible if you can't move the money around.

Put together, the disadvantages aren't worth the benefits which basically only consist of making a few users a bit happier.

Besides, if the exchange goes bankrupt, the money you have in a multi signature wallet shared with the exchange probably will be regarded as part of the insolvency estate anyways because you put it there with the intend of giving it to the exchange and that intent is probably all that counts (depending on the jurisdiction, of course, and I'm not a lawyer) so you probably have to agree to only get part of your money back anyways in order to get at least some of it back.


How do you push a transaction to the Bitcoin Cash Network? There are plenty of APIs for pushing to the Bitcoin network, like Smartbit's:

https://www.smartbit.com.au/api

However, the only API I found for Bitcoin Cash was Blocktrail's:

https://www.blocktrail.com/api/docs/lang/nodejs#payments_overview

And they do not seem to have a basic push endpoint.

I have listed a lot of Bitcoin Cash block explorers here, and most of them are Insight block explorers so I thought they should have Insight API. I checked all of them and the ones with API are:

Bitcoin.com: https://cashexplorer.bitcoin.com/insight-api/tx/send
BlockDozer: https://blockdozer.com/insight-api/tx/send
Blockexplorer: https://bitcoincash.blockexplorer.com/api/tx/send


Increasing the odds when solo mining with low-medium hashrates I never saw anything concrete related to this so I dare to ask here.
First, my situation:
I'm currently mining solo, on a private pool, with roughly 350Th/s. That to be increased soon with another ~200Th/s.
I know my odds, right now, from the plenty online calculators, I should solve a block roughly once a month at this diff.

But, would either or both of these following measures increase my chances?
 - First is running the pool bitcoin daemon as a full node with port 8333 open to the world.
 - The second is lowering the relayfee which is default to 0.00001000B.

No, neither of these things will help.

The only thing that really affects your chances is your hash rate, and the measures you describe do nothing to help it.

One other thing that can make a very slight difference (< 1%) is latency: the time it takes you to receive new blocks from the Internet (or work from your pool), and to send out your own.  In the unlikely event that you find a block very close to the same time as someone else, these would slightly increase the chance that your block is received first by other miners, and thus decrease the chance that it is orphaned.  But if your pool servers are properly run, they should be doing this pretty efficiently already.  Maybe faster than your own full node would be.

The relayfee has no relevance to mining.  If anything, you'd want to increase it, so that you relay fewer transactions and thus save bandwidth for receiving and sending mining work.  But this effect would likely be negligible anyway.


Demographics on Bitcoin users? Speaking with a large group about Bitcoins lately, I noticed that most people there came to like Bitcoins for different reasons. The shady ppl wanted drugs, the accountants wanted to avoid taxes, the Ron Paul people wanted more personal liberty and to end the Fed, The traders wanted new Forex opportunities, and the computer techies were in love with the elegance of the system...

So I'm really starting to wonder here, What are the demographics of the Bitcoin users? Has anyone attempted to do a serious attempt at finding those? Perhaps even a big website poll?

Inquiring minds want to know.

I can't think of any known data about real demographics.

But here are some things you can consider to get an idea:

BitcoinCharts' currency distribution: Gives you a view on what currencies are traded the most, most currencies are country- or region-specific so this can be a measure.
BlockChain.info's real-time transaction mapping: You can literally see every new transmitted transaction appear on the map. (This is possible because all transactions are public and have an IP bound to them. But note that some users might use Bitcoin with tools like Tor so their location can be wrong.)


Shutdown bitcoin-qt during reindexing? I started bitcoin-qt with --reindex and pruning on.
Can I safely shutdown and restart?
If yes how? Do I have to pass --reindex again or will bitcoin-qt remember and continue from where it stopped?

Can I safely shutdown and restart?

Yes.

If yes how? Do I have to pass --reindex again or will bitcoin-qt remember and continue from where it stopped?

No, Bitcoin Core will remember that it was reindexing and continue the reindex.


How does Bitcoin "inventor" makes money? Other than by having a non existent digital code become currency and riding on seeing the previously no-value cash become more valuable, how does the Inventors of Bitcoin profit from developing Bitcoin in the first place?

Idealists might argue that Bitcoin was developed to forever change the financial landscape, and would be affronted at the suggestion that Satoshi was out for profit. Skeptics might call the whole thing the most elaborate Ponzi scheme ever envisioned. Realists might suggest that Satoshi, emotionally traumatized by the recent unceremonious departure of his former love interest, was ruminating after a few too many beers late one Saturday night and decided to write some code on a whim.

If he retained the bitcoins he mined early on, he could certainly make quite a bit by cashing them out for fiat. No one would disagree that Bitcoin has made at least a small dent in the current dominant financial system, though whether it will really change the landscape has yet to be seen. And a girlfriend is a small price to pay for what he created.

The truth is, we don't know who Satoshi is, why he created Bitcoin, why he left, or what he sought to gain from it. For all we know, he could be among us today in a different guise. But whatever goals he had, I would suspect we're well on the way to accomplishing them if we haven't done so already.


Error sending SegWit transaction: error code: -26 using bitcoin-cli I'm trying spend funds that were sent to an SegWit address I created with the bitcoin-cli addwitnessaddress <P2PKH address> command.  The segwit address created was
33uUUt2V76HLcLqbs1Hou2ioofQo3d5kZ2.  I sent a small amount to this address as a test.

{txid: e360a6f86ebbdf0d2c3c86df60d1ad7e95af41248ff9305a48372db519028fcb, vout: 0}

I'm now trying to spend those funds to 3FNYRnLCgbGAaYmhkX1QHaXD5VYyXndpDa.  I created a raw transaction the normal way by specifying inputs and outputs:

bitcoin-cli createrawtransaction '[{"txid":"e360a6f86ebbdf0d2c3c86df60d1ad7e95af41248ff9305a48372db519028fcb","vout":0}]' '{"3FNYRnLCgbGAaYmhkX1QHaXD5VYyXndpDa":0.00451855}'
>> 0200000001cb8f0219b52d37485a30f98f2441af957eadd160df863c2c0ddfbb6ef8a660e30000000000ffffffff010fe506000000000017a9149613523d8525c0c444209b73eefda15101d1750d8700000000

bitcoin-cli signrawtransaction 0200000001cb8f0219b52d37485a30f98f2441af957eadd160df863c2c0ddfbb6ef8a660e30000000000ffffffff010fe506000000000017a9149613523d8525c0c444209b73eefda15101d1750d8700000000 '[{"txid":"e360a6f86ebbdf0d2c3c86df60d1ad7e95af41248ff9305a48372db519028fcb","vout":0,"scriptPubKey":"a914184b69873b307dc7081f2541098aaf4881bac20187","redeemScript":"0014568db227e811df5f502df149c8c9d899492140c9"}]'
>> {"hex": "02000000000101cb8f0219b52d37485a30f98f2441af957eadd160df863c2c0ddfbb6ef8a660e30000000017160014568db227e811df5f502df149c8c9d899492140c9ffffffff010fe506000000000017a9149613523d8525c0c444209b73eefda15101d1750d87024830450221009fe3df8448be56b052bcf81cb3e992ff606a10b1baf94eec49b1bad05914b97c0220752c6823152d0ef59945377a767edba6222a12b6e2b1baabafe498fa4801dea6012103ba8ae62944f27ce7a661866d6837ab3d6dd3fcd62bc6a09be5405074ec2473db00000000","complete": true}

Now I try to send the transaction:

bitcoin-cli sendrawtransaction 02000000000101cb8f0219b52d37485a30f98f2441af957eadd160df863c2c0ddfbb6ef8a660e30000000017160014568db227e811df5f502df149c8c9d899492140c9ffffffff010fe506000000000017a9149613523d8525c0c444209b73eefda15101d1750d87024830450221009fe3df8448be56b052bcf81cb3e992ff606a10b1baf94eec49b1bad05914b97c0220752c6823152d0ef59945377a767edba6222a12b6e2b1baabafe498fa4801dea6012103ba8ae62944f27ce7a661866d6837ab3d6dd3fcd62bc6a09be5405074ec2473db00000000

And get the following error:

error code: -26
error message:
64: non-mandatory-script-verify-flag (Signature must be zero for failed CHECK(MULTI)SIG operation)

I tried sending it through blockchain.info/pushtx in case it was a problem with my wallet but I got the same error.  I tried looking up what the error meant but couldn't find any explanation that would help me figure out what I did wrong.

After writing up this question I finally figured out the answer from here: https://bitcointalk.org/index.php?topic=1680640.0.  I will answer my own question for anyone who might be having the same problem.  It turns out I needed to specify the amount of each input in signrawtransaction.

bitcoin-cli signrawtransaction 0200000001cb8f0219b52d37485a30f98f2441af957eadd160df863c2c0ddfbb6ef8a660e30000000000ffffffff010fe506000000000017a9149613523d8525c0c444209b73eefda15101d1750d8700000000 '[{"txid":"e360a6f86ebbdf0d2c3c86df60d1ad7e95af41248ff9305a48372db519028fcb","vout":0,"amount":0.00541855,"scriptPubKey":"a914184b69873b307dc7081f2541098aaf4881bac20187","redeemScript":"0014568db227e811df5f502df149c8c9d899492140c9"}]'
>> {"hex":"02000000000101cb8f0219b52d37485a30f98f2441af957eadd160df863c2c0ddfbb6ef8a660e30000000017160014568db227e811df5f502df149c8c9d899492140c9ffffffff010fe506000000000017a9149613523d8525c0c444209b73eefda15101d1750d8702473044022006f8822e2a56fb4c9defaca393a0c4ee29a32b4caecc15e457dff1b5993e88290220096b1bae9819d64f2b69a44881c033fb7c9fbde77c9d16347ef2439e831c192d012103ba8ae62944f27ce7a661866d6837ab3d6dd3fcd62bc6a09be5405074ec2473db00000000","complete": true}

This time sending it works:

bitcoin-cli sendrawtransaction 02000000000101cb8f0219b52d37485a30f98f2441af957eadd160df863c2c0ddfbb6ef8a660e30000000017160014568db227e811df5f502df149c8c9d899492140c9ffffffff010fe506000000000017a9149613523d8525c0c444209b73eefda15101d1750d8702473044022006f8822e2a56fb4c9defaca393a0c4ee29a32b4caecc15e457dff1b5993e88290220096b1bae9819d64f2b69a44881c033fb7c9fbde77c9d16347ef2439e831c192d012103ba8ae62944f27ce7a661866d6837ab3d6dd3fcd62bc6a09be5405074ec2473db00000000
f375de743834e041f42a19eceb39fb25b4e6ea5159b5450ea3fdac95d67062dc

For some reason this wasn't necessary for spending regular P2PKH outputs but it seems that for P2SH outputs it is.  I am curious as to why this might be the case and why signrawtransaction didn't throw any errors.  I have to say that the documentation is very poor as https://bitcoin.org/en/developer-reference#signrawtransaction says nothing about including an amount in the parameter #2.


Why bitcoin is not full p2p? The goal of bitcoin is to serve as p2p electronic cash. But it still needs a 3rd party (miners) to approve/authorize/record/track/store transactions. The difference is this authority is decentralized and distributed.

Why is it not a complete p2p (like gold, fiat cash) electronic cash? Is it not possible to create such system with cryptography? If yes what are the difficulties?

it still needs a 3rd party (miners) to approve/authorize/record/track/store transactions

Role of miners vs other participants
In the beginning miners were not a third-party, every wallet owner was also a miner, all peers performed the same roles.
Nowadays mining has become a separate activity but miners do not really have any special control over the bitcoin network. They have a specialized role but I believe their influence over consensus rules carries the same weight as ordinary wallet nodes. Its just that a mining business deploys a lot more nodes than the average wallet owner does. In any peer-to-peer system, even a completely homogenous one, one person or organisation could deploy a large number of nodes.
approve/authorize/record/track/store transactions
approval
All nodes approve transactions, if all ordinary wallets disapprove of blocks from a miner then that miner loses money.
authorisation
There is no authorisation in the Bitcoin network protocols or consensus rules so far as I know.
The only action similar to authorisation is the P2P process of proving ownership of private keys in order to prove the right to spend the outputs of a transaction. Every wallet does this.
Recording transactions
Miners are responsible for recording transactions in the blockchain. So they do have a special role here. Bitcoin relies on no single organisation having more than 50% of the total available hashing power.
Tracking transactions
All full-nodes track transactions (i.e. keep local records of transactions in blockchain blocks as well as maintain an in-memory pool of unconfirmed transactions). Miners have no special role here.
Storing transactions
All full-nodes store a complete list of transactions from which blocks of fully-spent transactions are optionally pruned. Miners have no special role here.

Why is it not a complete p2p (like gold, fiat cash) electronic cash?

Gold is not P2P in the modern world. Generally people who buy and sell gold directly do so in the form of coins or ingots - the production of coins and ingots is performed by a limited number of businesses not by the buyers and sellers. Often it is governments that mint gold coins. Often governments regulate the gold market. Gold assayers are often relied on by buyers.
Fiat cash is not P2P. Banknotes and coins are typically created by governments, not by buyers and sellers. The amount of fiat cash in circulation is typically managed by governments. Inflation rates are set at the whim of politicians.


What is the max allowed depth for bip32 derivation paths? Generally I see that bip32 derivation paths are something like m/1/2/3/4, etc

How deep is allowed? Is there a limit on how deep the tree can go?

A path can have, at most, 256 elements, including the master. This limitation comes from the extended public key serialization format's depth field. This field is a single  byte which means it only has 256 possible values.


what's the link between iSCSI protocol and "stratum+tcp attacks I found a strange file under/var/tmp directory, named ietd.conf

{
    "url" : "stratum+tcp://188.165.254.85:80",
    "user" : "46Z6dQ77i2qAapF4kjLXaaYKCB59eajwaZbmtyyPsxDXWyxPS5nfYoe5t4R7yTgsvT
AxgE8DRwwtKiMxCmM39KCBPfEgL5b",
    "pass" : "x",
    "algo" : "cryptonight",
    "quiet" : true
}

Can someone explain it to me please

You most likely have a stealth Monero miner installed, I recommend checking your system for rootkits.


What's the risk of publicizing a Bitcoin address? What's the risk of public Bitcoin address, except  person - account link is publically known. Or, is it preferable to have one such account?

For privacy, Bitcoin relies on "pseudonymity", which means that the only way people can choose not to disclose their identity, is by making it hard to link addresses to people/businesses/....

Publishing an address publicly obviously makes you give up that privacy, but that's not a problem. everyone is free to choose so of course. The problem is that it also makes it easier to trace the identity of others, by linking addresses after following transactions in the block chain. Publishing addresses may in this way decrease the privacy of many people using the system, including people who are unrelated to you.

Even just reusing the same address for multiple receiving transactions is already bad for the network in this sense, as it increases the ability to link transactions and addresses.

The general advice is to use each receiving address just once. This also makes it easier to distinguish incoming transactions, for example.