How often does a block have only one transaction?

It's possible that this could happen just because there aren't any transactions to be mined. Early on in the bitcoin block chain, this was often the case. This could also happen if two blocks are solved on top of each other in a very short amount of time, with not much time for new transactions to be broadcasted in between. Today, however, more often than not this is due to a miner trying to get his/her block out to the rest of the peers on the network as soon as possible.

A miner would want to do this because bigger blocks take longer to propagate to the rest of the network. Nodes have to download and verify the validity of a block before they can relay them to their peers, because if they don't verify before sending and they send an invalid block, then their peers may ban them and the node will have no one to connect with on the network.

Think of it this way. If your block takes 50 seconds to get out to 90% of the peers on the network, and someone else mines a block 1 second later than you but can get their block out to 90% of the network in 9 seconds, who do you think will have the greater chance of getting their block accepted by more peers?

It may also be worthwhile to note that while this seems like it has a better pay off, it also sends a message to everyone on the network that the miner who mined the block doesn't really actually care about the bitcoin network's transactions, it just cares about its reward. And if the miners don't support the system, then why should investors or anyone else have confidence in it? I guess what I'm trying to say is that if a lot of miners did this, then the price of bitcoin would likely drop as it would show a lack of faith in the system.

There's a more mathematical analysis of orphan rates and payoffs here: http://organofcorti.blogspot.com/2013/10/161-network-orphaned-blocks-part-1.html\

In addition, it may interest you to know that there is a new proposal to enable faster propagation of blocks even if they are very large. See here for more info: https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2.

A different way of explaining this would be that, for a block to be accepted by the network, it has to be propagated out and checked by everyone. While blocks are spreading through the network, any miners who don't know about the new block will just keep mining on the block they have. In most cases, probably, this is just wasted work since there is already a block that is on it's way to being accepted. But if your block is much smaller (i.e. very few txs), then it gives other miners less time to solve a block while yours is propagating, and it also increases your chance that your block will get accepted by the majority of the miners even if someone else solved a block slightly before you.

To answer this question with a bit of data, I made a script that processed the last 1 month of blocks (4,464 blocks before and including block 338,782), and gathered data about the number of transactions in each block. These were the results.

  From this data, it seems that roughly

  1.3% of blocks are solved with just the reward transaction
  1.6% of blocks are solved with fewer than 10 transactions.

# Transactions  # Blocks with transaction count in MIN-MAX range
MIN     MAX     COUNT
0       9       73
10      19      31
20      29      22
30      39      74
40      49      52
50      59      43
60      69      107
70      79      50
80      89      41
90      99      56
100     109     55
110     119     50
120     129     86
130     139     46
140     149     54
150     159     57
160     169     51
170     179     62
180     189     49
190     199     53
200     209     46
210     219     45
220     229     64
230     239     42
240     249     45
250     259     69
260     269     58
270     279     39
280     289     41
290     299     41
300     309     44
310     319     45
320     329     37
330     339     35
340     349     45
350     359     42
360     369     40
370     379     42
380     389     41
390     399     37
400     409     48
410     419     47
420     429     42
430     439     40
440     449     40
450     459     46
460     469     42
470     479     32
480     489     33
490     499     40
500     509     38
510     519     68
520     529     44
530     539     28
540     549     32
550     559     28
560     569     35
570     579     27
580     589     29
590     599     28
600     609     19
610     619     31
620     629     20
630     639     27
640     649     38
650     659     28
660     669     27
670     679     25
680     689     18
690     699     21
700     709     27
710     719     28
720     729     23
730     739     25
740     749     25
750     759     19
760     769     21
770     779     24
780     789     27
790     799     23
800     809     16
810     819     18
820     829     19
830     839     18
840     849     16
850     859     19
860     869     20
870     879     16
880     889     18
890     899     16
900     909     24
910     919     24
920     929     14
930     939     18
940     949     20
950     959     12
960     969     13
970     979     15
980     989     15
990     999     21
1000    1009    15
1010    1019    15
1020    1029    18
1030    1039    14
1040    1049    13
1050    1059    13
1060    1069    9
1070    1079    16
1080    1089    16
1090    1099    8
1100    1109    17
1110    1119    10
1120    1129    12
1130    1139    8
1140    1149    8
1150    1159    22
1160    1169    10
1170    1179    14
1180    1189    17
1190    1199    10
1200    1209    11
1210    1219    14
1220    1229    9
1230    1239    9
1240    1249    12
1250    1259    9
1260    1269    8
1270    1279    7
1280    1289    7
1290    1299    9
1300    1309    8
1310    1319    12
1320    1329    8
1330    1339    7
1340    1349    12
1350    1359    10
1360    1369    13
1370    1379    10
1380    1389    10
1390    1399    9
1400    1409    10
1410    1419    8
1420    1429    14
1430    1439    10
1440    1449    6
1450    1459    6
1460    1469    6
1470    1479    9
1480    1489    7
1490    1499    4
1500    1509    5
1510    1519    8
1520    1529    5
1530    1539    12
1540    1549    3
1550    1559    7
1560    1569    8
1570    1579    3
1580    1589    7
1590    1599    2
1600    1609    12
1610    1619    5
1620    1629    10
1630    1639    3
1640    1649    4
1650    1659    5
1660    1669    6
1670    1679    5
1680    1689    3
1690    1699    5
1700    1709    2
1710    1719    1
1720    1729    10
1730    1739    4
1740    1749    5
1750    1759    4
1760    1769    4
1770    1779    2
1780    1789    3
1790    1799    6
1800    1809    3
1810    1819    2
1820    1829    4
1830    1839    5
1840    1849    4
1850    1859    3
1860    1869    3
1870    1879    3
1880    1889    5
1890    1899    3
1900    1909    3
1910    1919    4
1920    1929    1
1930    1939    0
1940    1949    3
1950    1959    0
1960    1969    0
1970    1979    3
1980    1989    2
1990    1999    2
2000    2009    3
2010    2019    3
2020    2029    3
2030    2039    3
2040    2049    7
2050    2059    3
2060    2069    1
2070    2079    4
2080    2089    2
2090    2099    1
2100    2109    1
2110    2119    3
2120    2129    2
2130    2139    2
2140    2149    4
2150    2159    1
2160    2169    2
2170    2179    1
2180    2189    2
2190    2199    3
2200    2209    0
2210    2219    0
2220    2229    1
2230    2239    0
2240    2249    3
2250    2259    0
2260    2269    1
2270    2279    2
2280    2289    1
2290    2299    3
2300    2309    0
2310    2319    1
2320    2329    0
2330    2339    1
2340    2349    1
2350    2359    1
2360    2369    1
2370    2379    1
2380    2389    0
2390    2399    0
2400    2409    1
2410    2419    1
2420    2429    1
2430    2439    0
2440    2449    0
2450    2459    0
2460    2469    1
2470    2479    0
2480    2489    0
2490    2499    2
2500    2509    0
2510    2519    0
2520    2529    1
2530    2539    2
2540    2549    2
2550    2559    1
2560    2569    0
2570    2579    1
2580    2589    1
2590    2599    0
2600    2609    0
2610    2619    0
2620    2629    0
2630    2639    0
2640    2649    2
2650    2659    0
2660    2669    0
2670    2679    0
2680    2689    0
2690    2699    0
2700    2709    0
2710    2719    0
2720    2729    0
2730    2739    0
2740    2749    0
2750    2759    0
2760    2769    0
2770    2779    0
2780    2789    0
2790    2799    0
2800    2809    0
2810    2819    1
2820    2829    0
2830    2839    0
2840    2849    0
2850    2859    1
2860    2869    0
2870    2879    0
2880    2889    0
2890    2899    0
2900    2909    0
2910    2919    0
2920    2929    0
2930    2939    0
2940    2949    0
2950    2959    0
2960    2969    0
2970    2979    0
2980    2989    0
2990    2999    0
3000    3009    0
3010    3019    0
3020    3029    0
3030    3039    1
3040    3049    0
3050    3059    0
3060    3069    0
3070    3079    0
3080    3089    0
3090    3099    0
3100    3109    0
3110    3119    0
3120    3129    0
3130    3139    1

The x-axis here (it may be hard to read) is the transaction range (each MIN-MAX pair in data above represents one column). The y-axis shows the number of blocks in the last month that had a transaction count within the range.


Re-indexing blocks taking more than a week - Cant access my wallet

You can quickly import your wallet to blockchain.info, which will give you instant access to your funds. From there you can send them back to a usable wallet on your Mac, such as Electrum or MultiBit which don't require lengthy synchronisation times. I do not recommend you leave your funds in a web-based wallet like Blockchain.info's for longer than you need to, but they are generally regarded as being trustworthy.

Find your wallet.dat in /Users/<name>/Library/Application Support/Bitcoin/, and follow the instructions on the page below.

https://blockchain.info/wallet/import-wallet

Some alternative, fast syncing Mac clients.

http://electrum.org/

https://multibit.org/

Good luck.


Are there valid transactions which are impossible to mine?

I think that the answer to your question is no, a transaction which makes every block it is included in invalid does not exist.

An important core property of a cryptographic hash function is that there is no discernable relationship between the input data, and output data. If such a relationship existed, then miners could 'cheat' by only creating blocks (input data) that would lead to a valid hash (output data) in the preferred range (lower than the difficulty target). In reality, we see that changing the input data slightly will drastically alter the output data, in a deterministic but unpredictable way.

And so I don't believe a transaction could exist, which would invalidate every block which it was attempted to be included in. Even if you create a block with just a coinbase transaction, and exhaust the nonce and extranonce space without finding a valid solution, the timestamp will still slowly increment, and each time it does you can search the entire nonce/extranonce space again. Probabilistically, since we expect an even, and random output value distribution from the hash function, after enough time, some combination of your transaction / the timestamp / the nonce and extranonce should lead to a valid block.

There is also lots of other data that can be included in a block, and altering any piece of it will affect the block hash as well. Murch's answer here tells us that lately there are ~2000 transactions in a block on average. For simplicity, lets assume that all transactions in the block are independent, so they could be included in any order. The number of permutations for the transaction ordering is thus 2000!, which is a huge number (~3.316 E +5735). For each of these combinations, the miner could exhaust the nonce space, the extranonce space, and then increment the timestamp and do it all again. This makes our number of possible arrangements even more enormous! Given enough time, and computational power, it becomes likely that a valid block hash will be found.

So, just from a probabilistic argument, I don't believe it is possible for the inclusion of some transaction to magically only create invalid blocks. Perhaps someone more well versed in the nitty-gritty details can offer a more thorough proof of this, but I think just the numbers alone, combined with the security properties of a cryptographic hash function, are reasonable enough proof.


There are basically four pieces of data that are maintained:

blocks/blk*.dat: the actual Bitcoin blocks, in network format, dumped in raw on disk. They are only needed for rescanning missing transactions in a wallet, reorganizing to a different part of the chain, and serving the block data to other nodes that are synchronizing.
blocks/index/*: this is a LevelDB database that contains metadata about all known blocks, and where to find them on disk. Without this, finding a block would be very slow.
chainstate/*: this is a LevelDB database with a compact representation of all currently unspent transaction outputs and some metadata about the transactions they are from. The data here is necessary for validating new incoming blocks and transactions. It can theoretically be rebuilt from the block data (see the -reindex command line option), but this takes a rather long time. Without it, you could still theoretically do validation indeed, but it would mean a full scan through the blocks (207 GB as of march 2019 - https://www.blockchain.com/charts/blocks-size) for every output being spent.
blocks/rev*.dat: these contain "undo" data. You can see blocks as 'patches' to the chain state (they consume some unspent outputs, and produce new ones), and see the undo data as reverse patches. They are necessary for rolling back the chainstate, which is necessary in case of reorganisations.

So yes, everything but the block data itself is indeed redundant, as it can be rebuilt from it. But validation and other operations would become intolerably slow without them.


For precise calculations consider using raw transactions. Then you have to decide how this transaction fee will be calculated. For single output transactions it's clear, you deduct the tx fee from the receiving amount, although for some micro-payments this is not possible as the tx fee might be bigger than the actual payout amount. Batching your outgoing payments (pay many outputs in a single tx) will help reduce the transaction fees for your customers but in this case you have to decide who pays what. The tx fee is what is left if you deduct your outputs total amount (change included in that) from your inputs total amount. You can also chose to charge a flat fee per tx which is less precise but more transparent for your clients and easier for your calculations.


There will be no change in this scenario on only one output sent to bob's address. Note that 0 fee transactions are unlikely to be mined these days so do include a fee. Usually you let your wallet calculate a reasonable fee for you.


If you want to allow connections from any machine, use:

rpcallowip=*

If you want to allow connections from one specific IP address, put that IP address instead of *:

rpcallowip=192.168.0.101

You can have as many of these lines as you like.  Use one for each IP address you want to allow.  And wildcards are also allowed:

rpcallowip=192.168.0.*
rcpallowip=10.*
rcpallowip=192.168.*.100


There's no way this is legitimate.

Domain is less than a month old
All product photos can be found elsewhere on the web. http://www.stss.ru/products/workstations/tesla/RX240T8.2.html http://www.fractal-design.com/?view=product&prod=94
Address/phone number/name on Contact Us page differs from address/phone number/name on WHOIS record.
They say their miner connects over USB. However, they don't have any drivers for it on their website, or say what OS it works with.
They said that they're too busy to take a video, or post an non stock-photo image, but they would in a week. They said that 10 days ago.
They claimed that they designed, wrote, sourced, soldered, and tested the whole thing, front to back, in 3 weeks. Then somebody on bitcointalk pointed that out, and now it took them 3 months! Still implausible, though. Unless you're willing to pay insane markups, your shortest turnaround time on an ASIC is around 6 months, and that's if you already have your design done.
They offer local pickup (in the Czech Republic)
This gem:

  Due to Czech law, we MUST, give you back your money even after 14 days, if you are not satisfied with the product.

I doubt that.

So yeah. Scam. I'm guessing that Antonio Barreto is the brains of the operation, and Anamur Silif is the fall guy.


Are sequential blocks more likely to be "empty" if solved by the same entity?

It is actually less likely to occur by the same miner. The reason for this is the fact that the miner that found the Block will have already validated it, thus it knows which transactions from the mempool were used. If the block is mined by another person their mining software might not have validated the previously mined block yet, which causes them to be unaware of which transactions were included. Thus an empty block is more likely when it was mined by someone else.


What happens if I use same k twice in DSA algorithm?

If you sign two messages using the same nonce, then it is possible for someone to derive your private key. See How do you derive the private key from two signatures that share the same k value?


note: what Nils Schneider calls 'z',  i call 'm'.

this gist implements all this: https://gist.github.com/nlitsme/dda36eeef541de37d996

the calculation

ecdsa signing is done as follows:

given a message 'm', a sign-secret 'k', a private key 'x'

 R = G*k  (elliptic curve scalar multiplication)
 r = xcoordinate(R)
 s = (m + x * r) / k     (mod q)

q = the group order of secp256k1 = 2^256 - 432420386565659656852420866394968145599

now if we have 2 signatures with identical k, we can write this as follows:

 s1 * k = ( m1 + x * r ) (mod q)
 s2 * k = ( m2 + x * r ) (mod q)

substract these two equations, leading to:

(s1-s2)*k = (m1-m2)      (mod q)

so the sign-secret 'k'  can now be calculated like this:

k = (m1-m2)/(s1-s2)      (mod q)

and given k, the private key can be calculated like this:

x = (s1*k-m1) / r        (mod q)

practical example

the original transaction

the lines below represent:

the version field
the nr of inputs (02)
the 2 inputs
the nr of outputs (01)
the output
the locktime field

01 00 00 00
02
 f6 4c 60 3e 2f 9f 4d af 70 c2 f4 25 2b 2d cd b0 7c c0 19 2b 72 38 bc 9c 3d ac ba e5 55 ba f7 01 01 00 00 00  8a 47 30 44 02 20 d4 7c e4 c0 25 c3 5e c4 40 bc 81 d9 98 34 a6 24 87 51 61 a2 6b f5 6e f7 fd c0 f5 d5 2f 84 3a d1 02 20 44 e1 ff 2d fd 81 02 cf 7a 47 c2 1d 5c 9f d5 70 16 10 d0 49 53 c6 83 65 96 b4 fe 9d d2 f5 3e 3e 01 41 04 db d0 c6 15 32 27 9c f7 29 81 c3 58 4f c3 22 16 e0 12 76 99 63 5c 27 89 f5 49 e0 73 0c 05 9b 81 ae 13 30 16 a6 9c 21 e2 3f 18 59 a9 5f 06 d5 2b 7b f1 49 a8 f2 fe 4e 85 35 c8 a8 29 b4 49 c5 ff  ff ff ff ff
 29 f8 41 db 2b a0 ca fa 3a 2a 89 3c d1 d8 c3 e9 62 e8 67 8f c6 1e be 89 f4 15 a4 6b c8 d9 85 4a 01 00 00 00  8a 47 30 44 02 20 d4 7c e4 c0 25 c3 5e c4 40 bc 81 d9 98 34 a6 24 87 51 61 a2 6b f5 6e f7 fd c0 f5 d5 2f 84 3a d1 02 20 9a 5f 1c 75 e4 61 d7 ce b1 cf 3c ab 90 13 eb 2d c8 5b 6d 0d a8 c3 c6 e2 7e 3a 5a 5b 3f aa 5b ab 01 41 04 db d0 c6 15 32 27 9c f7 29 81 c3 58 4f c3 22 16 e0 12 76 99 63 5c 27 89 f5 49 e0 73 0c 05 9b 81 ae 13 30 16 a6 9c 21 e2 3f 18 59 a9 5f 06 d5 2b 7b f1 49 a8 f2 fe 4e 85 35 c8 a8 29 b4 49 c5 ff  ff ff ff ff
01
 a0 86 01 00 00 00 00 00 19 76 a9 14 70 79 2f b7 4a 5d f7 45 ba c0 7d f6 fe 02 0f 87 1c bb 29 3b 88 ac
00 00 00 00

the input scripts

the input script consists of:
 * the total length (8a)
 * the signature
 * the public key

8a
  47  30 44 02 20 d4 7c e4 c0 25 c3 5e c4 40 bc 81 d9 98 34 a6 24 87 51 61 a2 6b f5 6e f7 fd c0 f5 d5 2f 84 3a d1 02 20 44 e1 ff 2d fd 81 02 cf 7a 47 c2 1d 5c 9f d5 70 16 10 d0 49 53 c6 83 65 96 b4 fe 9d d2 f5 3e 3e 01
  41  04 db d0 c6 15 32 27 9c f7 29 81 c3 58 4f c3 22 16 e0 12 76 99 63 5c 27 89 f5 49 e0 73 0c 05 9b 81 ae 13 30 16 a6 9c 21 e2 3f 18 59 a9 5f 06 d5 2b 7b f1 49 a8 f2 fe 4e 85 35 c8 a8 29 b4 49 c5 ff

the signature is an asn1 encoded r+s value + a hashtype indicator (01)

30 44
    02 20  d4 7c e4 c0 25 c3 5e c4 40 bc 81 d9 98 34 a6 24 87 51 61 a2 6b f5 6e f7 fd c0 f5 d5 2f 84 3a d1
    02 20  44 e1 ff 2d fd 81 02 cf 7a 47 c2 1d 5c 9f d5 70 16 10 d0 49 53 c6 83 65 96 b4 fe 9d d2 f5 3e 3e
01

so now we can extract these values from the transaction:

pk 04dbd0c61532279cf72981c3584fc32216e0127699635c2789f549e0730c059b81ae133016a69c21e23f1859a95f06d52b7bf149a8f2fe4e8535c8a829b449c5ff
r  d47ce4c025c35ec440bc81d99834a624875161a26bf56ef7fdc0f5d52f843ad1
s1 44e1ff2dfd8102cf7a47c21d5c9fd5701610d04953c6836596b4fe9dd2f53e3e
s2 9a5f1c75e461d7ceb1cf3cab9013eb2dc85b6d0da8c3c6e27e3a5a5b3faa5bab

next we need to calculate the message hashes.

prepare

Strip the input scripts, and add the hashtype

01 00 00 00
02
 f6 4c 60 3e 2f 9f 4d af 70 c2 f4 25 2b 2d cd b0 7c c0 19 2b 72 38 bc 9c 3d ac ba e5 55 ba f7 01 01 00 00 00  00  ff ff ff ff
 29 f8 41 db 2b a0 ca fa 3a 2a 89 3c d1 d8 c3 e9 62 e8 67 8f c6 1e be 89 f4 15 a4 6b c8 d9 85 4a 01 00 00 00  00  ff ff ff ff
01
 a0 86 01 00 00 00 00 00 19 76 a9 14 70 79 2f b7 4a 5d f7 45 ba c0 7d f6 fe 02 0f 87 1c bb 29 3b 88 ac
00 00 00 00
01 00 00 00   <<< hashtype

calculating m1

replace the first input with the corresponding output script

01 00 00 00
02
 f6 4c 60 3e 2f 9f 4d af 70 c2 f4 25 2b 2d cd b0 7c c0 19 2b 72 38 bc 9c 3d ac ba e5 55 ba f7 01 01 00 00 00  19 76 a9 14 70 79 2f b7 4a 5d f7 45 ba c0 7d f6 fe 02 0f 87 1c bb 29 3b 88 ac  ff ff ff ff
 29 f8 41 db 2b a0 ca fa 3a 2a 89 3c d1 d8 c3 e9 62 e8 67 8f c6 1e be 89 f4 15 a4 6b c8 d9 85 4a 01 00 00 00  00  ff ff ff ff
01
 a0 86 01 00 00 00 00 00 19 76 a9 14 70 79 2f b7 4a 5d f7 45 ba c0 7d f6 fe 02 0f 87 1c bb 29 3b 88 ac
00 00 00 00
01 00 00 00

then do sha256(sha256(modified transaction))

this will result in : c0e2d0a89a348de88fda08211c70d1d7e52ccef2eb9459911bf977d587784c6e

calculating m2

replace the second input with the corresponding output script

01 00 00 00
02
 f6 4c 60 3e 2f 9f 4d af 70 c2 f4 25 2b 2d cd b0 7c c0 19 2b 72 38 bc 9c 3d ac ba e5 55 ba f7 01 01 00 00 00  00  ff ff ff ff
 29 f8 41 db 2b a0 ca fa 3a 2a 89 3c d1 d8 c3 e9 62 e8 67 8f c6 1e be 89 f4 15 a4 6b c8 d9 85 4a 01 00 00 00  19 76 a9 14 70 79 2f b7 4a 5d f7 45 ba c0 7d f6 fe 02 0f 87 1c bb 29 3b 88 ac  ff ff ff ff
01
 a0 86 01 00 00 00 00 00 19 76 a9 14 70 79 2f b7 4a 5d f7 45 ba c0 7d f6 fe 02 0f 87 1c bb 29 3b 88 ac
00 00 00 00
01 00 00 00

then do sha256(sha256(modified transaction))

this will result in : 17b0f41c8c337ac1e18c98759e83a8cccbc368dd9d89e5f03cb633c265fd0ddc

Note that the redeemed output scripts and the output script of this transaction are all identical in this case. That is not usually so.

so our message hashes are:

m1 c0e2d0a89a348de88fda08211c70d1d7e52ccef2eb9459911bf977d587784c6e
m2 17b0f41c8c337ac1e18c98759e83a8cccbc368dd9d89e5f03cb633c265fd0ddc
s1 44e1ff2dfd8102cf7a47c21d5c9fd5701610d04953c6836596b4fe9dd2f53e3e
s2 9a5f1c75e461d7ceb1cf3cab9013eb2dc85b6d0da8c3c6e27e3a5a5b3faa5bab

m1-m2 = 0xA931DC8C0E011326AE4D6FAB7DED290B196966154E0A73A0DF434413217B3E92
s1-s2 = 0xAA82E2B8191F2B00C8788571CC8BEA41086440225A4B5CBED84D02CF638123D4

modulare inverse of s1-s2 = 0xf7d5417b3844fd8f4b3d909979fa7480ce094fb233d759274fd6c3aa6cf86593

so our secret 'k' value is:

-> (m1-m2)/(s1-s2) = 0x7a1a7e52797fc8caaa435d2a4dace39158504bf204fbe19f14dbb427faee50ae

the private key can then be calculated :

s1*k-m1 = 0x797035d79964e4b74fbbef4460379c410261cd01de43278bc2a7efaa541dd8e9 - 0xc0e2d0a89a348de88fda08211c70d1d7e52ccef2eb9459911bf977d587784c6e
        = 0xB88D652EFF3056CEBFE1E72343C6CA67D7E3DAF5A1F76E366680D6619CDBCDBC

(s1*k-m1)/r = 0xc477f9f65c22cce20657faa5b2d1d8122336f851a508a1ed04e479c34985bf96

Explanation of Transaction Contents

A transaction consists of a number of inputs, and a number of outputs.

An input refers to one of the outputs from another transaction, and contains a script which proofs that this transaction is allowed to redeem that output.

An output consists of a BTC value, and a script which will be used to validate the proof presented in the input script at the time this output will be redeemed.

When an output is redeemed, the input and output scripts are concatenated, and evaluated by the bitcoin client. the result must be 'TRUE'.

The script language is a very simple, non-turing complete, stack based language.

The most common script looks like this:

---- input script ( aka scriptSig )
PUSH signature
PUSH publickey
---- output script ( aka scriptPubKey )
DUP
HASH160
PUSH pubkeyhash
EQUALVERIFY
CHECKSIG

Note that the 'PUSH' is not explicitly labeled as PUSH in the bitcoin script description.

In the output script, first it is verified that the addresshash ( which is the bitcoin address in binary format ) corresponds to the public key from the input.
Then with CHECKSIG it is verified that the specified signature is valid for this transaction.


You can do

sudo apt-get install -y software-properties-common
sudo add-apt-repository -u ppa:bitcoin/bitcoin
sudo add-apt-repository -u ppa:lightningnetwork/ppa
sudo apt-get install bitcoind lightningd

If you don't want to add external repositories you can flollow the clightning docs from https://github.com/ElementsProject/lightning/blob/master/doc/INSTALL.md they worked perfectly last time I checked and are copied here for your convenience.

Library Requirements

You will need several development libraries:

libsqlite3: for database support.
libgmp: for secp256k1
zlib: for compression routines.

For actually doing development and running the tests, you will also need:

pip3: to install python-bitcoinlib
valgrind: for extra debugging checks

You will also need a version of bitcoind with segregated witness and estimatesmartfee economical node, such as the 0.16 or above.

To Build on Ubuntu

OS version: Ubuntu 15.10 or above

Get dependencies:

sudo apt-get update
sudo apt-get install -y \
  autoconf automake build-essential git libtool libgmp-dev \
  libsqlite3-dev python python3 python3-mako net-tools zlib1g-dev libsodium-dev \
  git gettext

Clone lightning:

git clone https://github.com/ElementsProject/lightning.git
cd lightning

For development or running tests, get additional dependencies:

sudo apt-get install -y valgrind python3-pip libpq-dev
sudo pip3 install -r tests/requirements.txt -r doc/requirements.txt

Build lightning:

./configure
make
sudo make install

Running lightning:

bitcoind --datadir=<path_to_blockchain> && ./lightningd/lightningd && ./cli/lightning-cli help

Note: You may need to include testnet=1 in bitcoin.conf


How can I know that my transaction has been confirmed on the longer chain?

Building a chain longer than the best chain would require someone to have more Proof of Work hashpower than 51% or more of the total Bitcoin network hashpower.

The unlikelihood of this happening is the guarantee that the longest chain is the best chain.

To build a one block longer chain you'd have to assemble a block and find a nonce that produces a target less than or equal to the network target. Otherwise Bitcoin Core will discard your block as invalid. So to build a chain that is just 1 block longer than the current best chain you'd need massive amounts of hashpower, electricity, infrastructure and tens of millions of U$ investment. Again, all this for just one block.

The astronomic amount of work put into mining each block protects Bitcoin's consensus mechanism and assures everyone that the longest chain is correct.

If your TX was included in a block with depth 6 it means that for approximately one hour (~ 6 x 10 minute blocks) that chain where the block that holds your TX was included had the most work put into it all over the world.

There could be some other place where someone created an artificial chain with your TX in it but that chain will never be able to be longer than the main chain - unless they beat the network to find the next block. If they're unable to, then that chain will get ignored by everyone else in the network. That's how you know the TX you see on block explorers is in the longest/best chain.

For a more detailed reply you should read Antonopoulos' book (Mastering Bitcoin).


For SegWit node, is witness necessary to verify a block? Because I know witness are committed as wtxid merkle node in coinbase. What's the purpose of the wtxid merkle node?

If a block contains transactions that have witnesses, if the block then does not have a witness, the Segwit node will still validate it, but it will find it to be invalid. Because segwit is a soft fork, Segwit nodes still know what blocks without witnesses look like and can verify them as such. This is because the block structure actually did not change, what changed was the transaction structure.

  If witenss is necessary for SegWit node, then can I say witness is an part of blockchain in SegWit node's view?

Yes.


To unlock your wallet:
Option 1: Introduce password in prompt that opens when you send coins
Option 2: Console (Help > Debug window > Console)
Type the following:
walletpassphrase "passphrase" timeout

Where passphrase is your password and timeout is the number of seconds you want the wallet unlocked (i.e. 120 = 2 min). This is option is the only one when you want to do something that requires unlocking but you don't want to send coins (like dumping a private key) or when you plan to leave the wallet open and fear forgetting to lock it again.


There is no way to convert the resulting seed back to the original mnemonic.

As stated in the BIP 39 proposal:

  To create a binary seed from the mnemonic, we use the PBKDF2 function
  with a mnemonic sentence (in UTF-8 NFKD) used as the password and the
  string "mnemonic" + passphrase (again in UTF-8 NFKD) used as the salt.

The seed (and optional passphrase) are passed through pbkdf2, which is not reversible.


Powering the Butterfly Labs BFG0005G ASIC Miner

If it's the 5GHs in this picture:

https://i.pinimg.com/originals/30/5e/a0/305ea076f1dac979e04f44cb4de04ed5.jpg

Then the power adapter looks like 12V @ 7.5A. You might even find one on ebay (check the connectors look right in the photos think you want barrel tip)


Can I run a full bitcoin node on a Raspberry Pi?

Yes. I have one with an external usb hard drive if you want to store full blockchain or without it if you run a pruned node.


Trading bot - what is the maximum load an exchange server can take?

Finally, after 7 days of waiting, I got this answer from Bittrex:

  Your account has been re-enabled.
  "Your account was disabled for API-ABUSE.  Please refrain from making more than 1 request per second or you can expect your account will be disabled again"

Now you now it too, fellow bot-users: no more than 1 request per second !

HTH


Are there alternatives to ButterflyLabs?

There are USB ASIC mining equipment on ebay from the company ASICMinner called Block Errupter listed under which is in hand and able to ship imediatly however it is $150 per 333MH/sec which means it would take 2k to reach 5GH/sec. You can order a 5GH/sec BFL for 2.6k and have it shipped today on ebay. However with the price of Bitcoins droping it would be wise to consider profitability using bitcoinx before making a purchase. Also you can contract out your mining http://coinminer.biz/ offer a reasonable rate for a single year.


what happens to UTXOs when a transaction output script is satisfied?

I would like to first clarify a thing, before trying to answer, and it is also from the book:

  unspent transaction output (UTXO) UTXO is an unspent transaction
  output that can be spent as an input in a new transaction.

a UTXO is not an element per se, it is a description for a set of data in a transaction. UTXO's can be spent, or unspent. For transactions to become valid, they of course can only use unspents. So when using an UTXO from a previous transaction, spending all funds to a new address and a return address, the previous UTXO becomes part of two new UTXOs. And yes, the previous UTXO is spent, documented in the blockchain, and can't be used anymore.

When it comes to adding or removing UTXOs: here it is about mempool. The list of unspent tx is kept by the bitcoin client in memory. To see, how big UTXO database is, see here. This is what you described as a separate pool. And in this sense

  removed from the set of available (unspent) UTXO

simply means, that when you have sent a transaction, this particular UTXO must be removed from the mempool. I am not 100% sure, but the mempool is needed to verify, if the tx is valid or not (aka spends only valid UTXO out of the mempool). See also page 119 in the book.

  Would the output of the child transaction contain the same transaction
  ids as the its parent'output contained?

Each tx references a previous tx, to specify from which transaction (the tx hash) and VOUT to take the funds. So a child tx would reference a parents tx inputs. However, if the child tx is then referenced by the next tx, you wouldn't see references from the parent tx.

Assuming you have (you see) these three TX_IDs and outpoints and values,

7dbc497969c7475e45d952c4a872e213fb15d45e5cd3473c386a71a1b0c136a1:0 25000000 Satoshis
7f42eda67921ee92eae5f79bd37c68c9cb859b899ce70dba68c48338857b7818:0 16100000 Satoshis
6596fd070679de96e405d52b51b8e1d644029108ec4cbfe451454486796a1ecf:0 16050000 Satoshis

the wallet software would know, these are unspent outputs, and could be asked to use these as inputs for a new transaction of ~0.57BTC to a new address.

Besides the very good book from Andreas, I also recommend Ken Shirrif's blog entry, were he explains how to manually sign a tx. That makes things very clear as well.


Is there a way for me observe network traffic of bitcoin exchange?

You can use a "network sniffer" to observe data packets on your local network which are sent from or received by your computer.

It will be helpful to study the Bitcoin network protocol documentation so that you can define a filter that will only show the Bitcoin related traffic.

A popular choice for Windows is Wireshark, but there are many other options. If Wireshark does not have a decoder (dissector) for your protocol of interest you may have to manually decode from hex.

See https://www.google.com/search?q=wireshark+bitcoin+dissector --  there seem to be several bitcoin dissectors you can add to Wireshark.


In CEX.IO Should I include the fee in the sending bitcoin amount?

When sending a transaction to a recipient, they generally don't care what fees have been paid; they just care how much they've received at their given receiving address.

If you're wanting to send 0.015BTC then you'll need to ensure the fees don't reduce that amount. Given the screenshot, it is reasonably clear that you'd need to enter 0.016BTC to ensure that 0.015BTC arrives at the receiving address.


`walletcreatefundedpsbt` with unconfirmed inputs

Bitcoin Core will never select unconfirmed incoming outputs. These are always considered to be untrusted and not safe for coin selection. This applies to any transactions that Bitcoin Core creates, including those created by using walletcreatefundedpsbt or fundrawtransaction.

For a code reference, the AvailableCoins function is used to fetch and filter the coins available for coin selection which calls the IsTrusted function for every available output (well really transaction stored in the wallet which include incoming and outgoing transactions). If the transaction was not created by that wallet, it is considered not trusted, so IsTrusted returns false which results in AvailableCoins excluding all of that transaction's outputs from the set of outputs used for coin selection.


Slush on December 16th 2010

http://mining.bitcoin.cz

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

Was that what you were looking for?


Transaction verification vs block mining

The connected peers do the first one. If it is invalid, they don't relay to other peers and the transaction gets forgotten. If it's valid, then peers relay it to their peers and then miners include the transaction in their block.


Is the "recovery phrase" generated by a wallet app platform independent?

The mnemonic words that is given to you by the wallets is a representation of entropy. This entropy is then passed through PBKDF2 hashing function to generate seed. The industry standard for this conversion of mnemonic to seed is documented in BIP 39 and most wallets follow that method. The seed is then passed to HMAC-SHA512 to get a master extended private key.

Until this point the implementations are standard and you are unlikely to face any issue with different wallet implementations. But after this step, the derivation gets a bit trickier. There are a number of methods to go from here. You could use BIP 32, BIP 44, BIP 49 or the BIP 84 derivation methods to generate individual private keys from the master private key. Then there will be distinction between hardened and non-hardened derivation between different wallets. Each derivation path will give you a completely different set of keys as compared to other paths.

There is a spreadsheet tracking these derivation paths of numerous wallets here (please verify the data yourself as it may be dated or incorrect). I have pasted the derivation paths of different wallets below from the linked spreadsheet.

So, when using a wallet you should note the derivation path the wallet followed in order to recover it later. Also note that use of a passphrase along with the mnemonic words will generate a completely different set of keys as compared to only using the mnemonic words.


You can recover your seed phrase from their website (Settings > Security > Backup Phrase)

You should be able to use this phrase to restore your BTC and BTG in another wallet.


How to generate random addresses from public key such that they're recoverable later using pub key only

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.


bitcoin-cli getinfo will show the number of connections.

bitcoin-cli getpeerinfo will give information about individual connections.


How can I find a transaction on my Bittrex Ripple address with tag?

Bithomp now shows transaction hash (id), in the transaction block. You need to press on the orange i. The problem that is shows only first or last 200 transactions. You can use ripple api, to get the info as well.
https://ripple.com/build/data-api-v2/


Are there any fundamental security vulnerabilities in Bitcoin?

As David Schwartz said in 367; Dan Kaminsky has spent some time auditing the Bitcoin core . He is a respected security professional, and his opinion on these matters is highly regarded.

He came to the conclusion that there weren't any concerning security vulnerabilities, but scalability is something that will have to be tackled as the project grows. Essentially; nothing the developers didn't already know about.


BIP9: What happens if I make a segwit transaction after lock in but before activation?

The new rules are come into effect only when the softfork activates.

I am not completely sure, but I think in the case of segwit transactions these would be treated as non-standard nodes and thus not accept it in their mempool. If a miner does have it in their mempool, they will not mine it into a block.

Hopefully, everyone that receives it would immediately drop it, but I think that third parties could pick the input up with an ANYBODY_CAN_SPEND transaction. They'd need to deposit the transaction directly to a miner that mines this type of non-standard transactions though for it to be mined.


How can one see if an address is multisig?

There are different types of addresses in Bitcoin. The simplest format is called pay-to-public-key-hash (p2pkh) which locks funds to a single private key. Another is called pay-to-script-hash (p2sh), which allows to lock funds to a script that encodes the spending conditions.

The recipient(s) of a p2sh output must reveal the redeemscript upon spending and must fulfill the encoded conditions to prove their ownership. P2sh addresses are recognized by having a 3… prefix. The most popular application of p2sh is to encode a payment to multiple co-owners, i.e. multisignature addresses. For example in the case of a 2-of-3 multisig, said redeemscript would be composed from 2 pubkey1 pubkey2 pubkey3 3 OP_CHECKMULTISIG where the "2" is the required signatures and the "3" the number of eligible public keys. The proof of ownership is then provided by two signatures corresponding to two of the listed public keys. In other words, once a p2sh output is spent, all that needs to happen is that you read the m-of-n directly from the redeemscript. ;)

Also, since the p2sh address is derived from a hash of the redeemscript, you cannot tell anything whatsoever about the content of the redeemscript until it is revealed in spending (unless you're part of the recipients that created it in the first place).

For a complete walkthrough, see CHECKMULTISIG a worked out example.


How are fractions of bitcoin implemented and spent?

Bitcoin doesn't use the concept of "balances" it uses transactions.  A transaction consists of inputs and outputs.

The transaction amount is the total of all inputs.  Each input in a transaction is spent in its entirety during the transaction.   And the outputs can total any amount up to the total transaction amount.  Any amount remaining (inputs - outputs) goes to the miner as a fee.

So a transaction might look like:

INPUTS:
25 BTC
50 BTC

OUTPUTS
40.2 BTC
34.7 BTC

So the 75 BTC total inputs, less 74.9 BTC total outputs means 0.1 BTC goes to the miner.

Now, at the protocol level, the 25 BTC amount is really 2,500,000,000 because each 1 BTC is actually 100,000,000 Satoshis.

So the 34.7 BTC output was really the number 3,470,000,000.

So there are no fractions.  These are all integers.

When the client displays these numbers, it shows them in whatever units the client is configured to use (BTC, mBTC, uBTC).


These aggregating sites are just hooking up to every exchange API and querying the data and then dumping it in a database. You could do the same, it's a decent amount of work and costs money to run the server.

For example, Coinigy's API is hooked up with just about every exchange and pair, it is a paid service. I have no affiliation with them. This is only an example.


How are public and private keys related to the wallet?

Thomas' answer is correct, but I think an easy version may be appreciated as well.

I suppose you know the concept of public key cryptography? If you don't, here is a very short explanation (or read the wikipedia page): Public key cryptography (as used in Bitcoin), allows you to hand people a public key and use the corresponding private key to prove the ownership. So you can create any random private key (keep it secret) and calculate the corresponding public key (give it out to public for verification). Using this private key, you can sign a message and other people can verify that you own the private key by using your public key.

So, applied to Bitcoin.

A Bitcoin address is just a shorthand notation for a public key. When someone makes a transaction to an address, he states that "I give the right to spend this money to the person who owns the private key corresponding to this address".
The person who has received this transaction will in turn be able to spend the transaction by signing the transaction using his private key. With this signature he can prove that he owns the key, without disclosing it. Others can verify the signature using the public key.

As for the second part of your question, it gets a little more advanced. An easy way of viewing it is that every transaction takes a number of inputs and generates a number of outputs. Inputs in this case are outputs from previous transactions. For each input, the user will have to provide verification he is allowed to spend that output by adding a signature.


A quick websearch found me a review on BehindMLM. The site indicates that BitKingdom was a multi-layer marketing scheme. Unless your grandfather happened to be one of the first investors and actually cashed out, the funds are probably lost.
Disclaimer: I'm only familiar in passing with BehindMLM, but they had a lot of useful background information on BitClub and OneCoin in the past. I have not further verified this initial take.


Please see the following:

What open source miner applications are there?

https://en.bitcoin.it/wiki/Software#Mining_apps

https://github.com/ckolivas/cgminer


Wallet: how to generate public extended key?

Generally the private key and chain code (these 2 parts make up the extended private key) are generated at the same time from a seed. The seed can be either a randomly generated number, or derived from a 12 word mnemonic like BIP 39 details. Once you have a seed, BIP 32 explains:

  Calculate I = HMAC-SHA512(Key = "Bitcoin seed", Data = yourSeed)
  Split I into two 32-byte sequences, IL and IR.
  Use parse256(IL) as master secret key, and IR as master chain code.

So basically you take the 512 bit hash of the seed, and split it into two 256 bit halves, one of which is the private key and the other is the chain code. And from the private key, you can obtain the public key.


Is there a newer Bitcoin blockchain download available?

Since v0.10, the parallel block download in Bitcoin Core is often comparable in speed to torrent downloading, does not require temporary double storage, and validates while downloading instead of sequentially.

Original answer:

Please use the bootstrap.dat torrent download. It is more frequently updated and much safer to use.

You can find the .torrent download at http://sourceforge.net/projects/bitcoin/files/Bitcoin/blockchain/bootstrap.dat.torrent/download


How do services like ShapeShift generate new addresses

This is called Hierarchical Deterministic key derivation.

New public keys, and by extension Bitcoin addresses, can be generated from a set of parent public keys. This way, the front-end of Shape-shift never needs to communicate with a "hot wallet" and can generate a new set of addresses for every user transaction.

To spend from these addresses, Shapeshift simply derives the corresponding private key (server-side) from its parent private keys.

Child private and public keys can be derived in parallel (front/back-ends), maintaining a fire-wall between them.

Intro to HD Wallets

For details on HD key derivation works, check a recent talk of mine at Scaling Bitcoin: https://youtu.be/OVvue2dXkJo
Slides here: https://teachbitcoin.github.io/wallets.html#/5


How long has it taken for BIP-Taproot to go from draft specification to activation?

The idea of using the leaves of a Merkle tree to store alternative Bitcoin scripts dates back to Russell O'Connor in 2012. The idea of using Schnorr signatures instead of ECDSA has been discussed for at least as long. So you could say that what we will collectively call BIP-Taproot (BIP 340, BIP 341 and BIP 342) has been in the making for over eight years at this point.
However, there have been different iterations of how to apply these ideas and what we now consider BIP-Taproot was first proposed on the Bitcoin dev mailing list by Greg Maxwell in January 2018.
The draft of the Schnorr BIP (what became BIP 340) was first sent to the Bitcoin dev mailing list in July 2018.
The draft of the Taproot BIP and the Tapscript BIP (what became BIP 341 and BIP 342) were sent to the Bitcoin dev mailing list in May 2019. The BIPs were all allocated BIP numbers in January 2020.
Jonas Nick laid out the full timeline of BIP-Taproot progress here.
Greg Maxwell compared how long it took SegWit to go from draft specification to merged into Bitcoin Core in this Reddit post.

Segwit went from early public discussions to merged in six months. So in spite being more complex and subject to more debate due to splashback from blocksize drama, segwit was still done in significantly less time already.
Taproot has also been exceptionally widely discussed by the wider bitcoin community for a couple years now. It's application is narrow, users who don't care to use it are ultimately unaffected by it (it should decrease resource consumption by nodes, rather than increase it) and no one is forced to use it for their own coins. It also introduces new tools to make other future improvements simpler, safer (particularly, taproot leaf versions), and more private... so there is a good reason that other future improvements are waiting on tapoot.


Given a Bitcoin transaction as JSON data, how can I determine the number of confirmations?

Confirmations are nothing but just the number of blocks added after the block the transaction was added in. So accordingly, during the time of writing, the current block is 620093 and your transaction was added in block 615893

So if you subtract these two , current block - tx added block(620093 - 615893 = 4200), you will get the total number of confiramtions, which is near to your block confirmations (4198)

Hope this was helpful. Have a great day!


Mnemonic seed BIP 39 HD wallet with vanity address

Yes, this is possible. You will need to create a random BIP39 seed and derive keys/addresses, and check if the address has the pattern you desire. Repeat the process until you find a seed that produces your vanity address.

Here's a solution using Node. Being javascript, this will run slowly, but it's what I know, and it will eventually get the job done.
The script finds an address that has the search term either in all lowercase or all uppercase.

var bip39 = require( 'bip39' );
var bitcoin = require( 'bitcoinjs-lib' );

var searchTerm = 'newb';
var searchTermLower = searchTerm.toLowerCase();
var searchTermUpper = searchTerm.toUpperCase();

// Use a BIP44 derivation path for coin #2 (Litecoin)
var path = "m/44'/2'/0'/0/0";

var words, address, seed, root, i = 0;
do {
    // A value of 128 gives a 12-word phrase, and a value of
    // 256 gives a 24-word phrase
    words = bip39.generateMnemonic( 128 );
    seed = bip39.mnemonicToSeed( words ).toString( 'hex' );

    root = bitcoin.HDNode.fromSeedHex( seed );
    address = root.derivePath( path ).getAddress();

    if ( ++i % 100 === 0 ) console.log( 'Tried ' + i + ' seeds...' );

} while (
    address.indexOf( searchTermLower ) === -1 &&
    address.indexOf( searchTermUpper ) === -1
);

console.log( words + '\n' + address );


Securely encrypting a cold storage wallet

Even if you seem worried about losing your coins, the safest way to store bitcoins is probably to acquire a hardware wallet. To mitigate the risk, you should store several copies of your wallet seed words in different locations. This is a form of backup that allows you to regenerate your wallet on another hardware wallet if you lose the first. It is highly recommended that you store the backups in a way that they are not easily accessible to other people that may use the backup to steal your coins.

If you're going to invest significantly more than $1,000, the one-time cost of acquiring a hardware wallet at ~$100 seems a reasonable investment to me.


Several millions of Dogecoins have been stolen. Is a similar hack possible with Bitcoin?

The attack was made possible by an error of the coin owners (trusting the online wallet) and another error by the online wallet admins (they didn't make public the exact details, but the attacker certainly exploited a vulnerability that should not have been there).
The same is possible for cash/gold etc: if you trust a safe-deposit box to hold an ounce of gold and a door is accidentally left unlocked, you're pretty much in the same situation as the dogecoin hack.

You can find a list of bitcoin incidents at bitcointalk.


How to check if a given address belong to an exchange

A few exchanges publicize their hot and cold wallets, but currently, as far as I'm aware, no exchange publishes a full list.
This may change as FATF's Recommendation 16 adoption grows, but may still be limited to closed access networks among exchanges.
Beyond that, for most services, it is not very hard to determine if a used address belongs to an exchange - most exchanges tend to follow fairly easy to identify sweeping patterns to move funds between receiver, hot, and cold wallets. Many block explorers tag various addresses to exchanges, in addition to paid coin monitoring services.


The average amount of time (in seconds) to find a single share is:

difficulty * 2^32 / hashrate

In that equation, difficulty is the difficulty of a share and hashrate is your hash rate in hashes per second.  A day has 86,400 seconds in it, so the number of shares you'll find in 24 hours is:

86,400 / (difficulty * 2^32 / hashrate)

A slightly more complex formula, using PHP:

$hashTime = ((float) $difficulty) * (pow(2.0, 32) / ($hashRate * 1000.0)) ;
$powerCostPerYear = 365.25 * 24.0 * $powerConsumption / 1000.0 * $electricityRate;
$blocksPerYear =  (365.25 * 24.0 * 3600.0) / $hashTime ;
$coinsPerYear = $blockCoins * $blocksPerYear;
$revenuePerYear = $coinsPerYear * $conversionRate;
$profitPerYear = $revenuePerYear - $powerCostPerYear;
$netProfit1st = $revenuePerYear - $costHardware - $powerCostPerYear;
if ($profitPerYear <= 0) $breakEvenTime = -1;
else $breakEvenTime = $costHardware / ($profitPerYear / (365.25 * 24.0 * 3600.0));


Do all implementation of Deterministic RFC6979-compliant ECDSA signatures generate the same signed transaction given the same data?

So if I were to create the same transaction using bitcoinjs and bitcoinj, the end result of the signed transaction would be the same with both libraries, is that correct?

They certainly should. That's why they're called deterministic. Any particular library could have a bug in it, however. I would check against examples given in the spec to make sure a library is compliant with the spec, or run the unit tests if the library you're using has them.


Access the NXT / Ardor database console?

You can access the NXT's H2 database from the website by going to /dbshell path.

Example:
Show top 100 accounts sorted by balance:

  select *, BALANCE / 100000000 as NXT from account where latest = true
  order by balance desc limit 100


Wrong testnet address generation [python]

You didn't post the wrong result that you get... As I am not a python specialist, and don't know the library calls, I have an idea: you may want to place your private key here, and add print(s) after every step as debug commands, and compare line by line. I just checked the privkey and the pubkey, the page returns the same result as your main address. If you enter in step 4 the "6f", you get this testnet address: "mpGvZCV4DYnVLZJWMfeCHa1L3VvC1hetT8".

When done, you can edit your question and show how you fixed it, or extend the question with your results.


Can a shorter chain overcome a longer one?

Background info:

Strongest vs Longest chain and orphaned blocks
How does a client decide which is the longest block chain if there is a fork?
Where exactly is the "off-by-one" difficulty bug? (timewarp info)

A shorter chain could possibly be considered the correct one, but it would be very hard to make this happen in bitcoin. I can think of two ways this could happen.

  1) Go back to the genesis block and use the time warp attack.

See this for information on how the timewarp attack works.

This would let the attacker create a very long chain very quickly, because the difficulty could be artificially kept low even though blocks were solved very quickly. However, this chain would not have nearly as much work as the main chain, and so even if it were longer, it would not be accepted by the network as the correct chain. It would also fail most wallets' checkpoints.

  2) Two blocks are solved at the last height in a difficulty period and a network fork ensues.

If there happened to be a fork in the last block of a difficulty period, then the new difficulty for the next period would be different depending on which side of the fork you were on. In this case, blocks solved on top of one side of the fork would have precedence over the other.

This isn't a case of a shorter chain being chosen over a longer chain (unless the fork gets really long), but rather two chains of the same length and one of them being chosen by the network as the correct one even if it gets seen second.


It sounds like a lot of hassle to send bitcoins because you have to re-install you offline armory each time. Also, the fact you're trying to do it on a live CD tells me you likely don't have an air-gapped machine. If you think your wallet won't "touch the Internet" in such a case, think root-kit. I would advise against this.

Instead, get a cheap Raspberry Pi (disable the Ethernet) and use that as your offline wallet. If you encrypt the wallet and generate your paper backup, your coins will be very safe, (provided you don't lose your paper backup) and will be less of a headache to access your funds.


It seems that you have entered a valid mnemonic, but it cannot decrypt the nlocktime.zip file. It could be that the mnemonic you entered is not the one associated with the wallet (which can be used to decrypt the nlocktime.zip).

I replicated your error by using another mnemonic in one of the examples (garecovery/examples/example_2of2.sh):

$ garecovery-cli --network=testnet --mnemonic-file garecovery/tests/test_data/mnemonic_2.txt 2of2 --nlocktime-file garecovery/tests/test_data/compressed_1.zip
Traceback (most recent call last):
  File "/tmp/recovery/venv/bin/garecovery-cli", line 7, in <module>
    sys.exit(recoverycli.main(sys.argv))
  File "/tmp/recovery/venv/local/lib/python2.7/site-packages/garecovery/recoverycli.py", line 86, in main
    recovery = get_recovery(clargs.args, mnemonic, seed)
  File "/tmp/recovery/venv/local/lib/python2.7/site-packages/garecovery/recoverycli.py", line 61, in get_recovery
    return TwoOfTwo(mnemonic, seed, options.nlocktime_file)
  File "/tmp/recovery/venv/local/lib/python2.7/site-packages/garecovery/two_of_two.py", line 25, in __init__
    zipdata = gacommon._unzip(self.compressed_zip, chaincode)
  File "/tmp/recovery/venv/local/lib/python2.7/site-packages/gaservices/utils/gacommon.py", line 35, in _unzip
    all_data.extend(_unzip(_fernet_decrypt(key, encrypted), key))
  File "/tmp/recovery/venv/local/lib/python2.7/site-packages/gaservices/utils/gacommon.py", line 11, in _fernet_decrypt
    assert wally.hmac_sha256(key[:16], data[:-32]) == data[-32:]
AssertionError

For sure, the error message will have to be improved.

If you need further assistance and you feel you may reveal too much information about your situation, please send an email to info@greenaddress.it.


That seems right except there are some gotchas if you try to spend from your paper wallet.  The "change" will go to you another address and the paper backup address will be empty.  This should not be an issue with Armory though because it has deterministic addresses.  Be sure to follow the instructions carefully.


BIP 32 child key derivation "stops working" after a certain index (i)

Mycelium HD is BIP 44 compliant. As specified by BIP 44, the address gap limit is 20. This means that after 20 indexes of unused addresses, the wallet expects that no more addresses are used beyond that point. Therefore if you send funds to an address with a gap of more than 20 indexes between the last used address, the wallet software will not check if that address has received any funds.


Can you use lower dual fuel electricity rates to run a crypto miner for heating with a second back up heat source?

Is it permitted

There are certain regions (e.g. the Pacific Ocean) where everything is permitted, and certain regions where doing stuff that are allowed by law may even land you in jail.

crypto currency miner for heating and thus qualify for the lower energy rates

Yes, this is a smart thing to do wherever it's cold and mining is permitted!
Be careful, if mining is illegal, your ISP or your energy supplier may figure out that you're mining.


Just received a payment twice from coinbase

What I see in the transaction record is a bit different from what you describe.

I see that account 1FT4bog... received 0.01 on November 12th.
That same account spent virtually all of that (0.009292) on November 19th.

I do not see the duplicate transaction you describe.
I do not see that your account received 0.02 or even 0.03.


Using Bitcoins as a reward and micropayment system is possible. You wouldn't want to send a separate transaction for each micropayment (fee/transaction ratio would be quite big), but you can pay everyone down to a couple decimal places for each operation they make say, once a day.  Details of implementation would vary, depending on what you want to do exactly.


Armory by default doesnt run Bitcoin-qt, it runs Bitcoind. Since armory installs the entire Bitcoin reference client by default, Bitcoin-qt will be present regardless (you can try to delete it, though):

  Bitcoin-Qt is the “Graphical User Interface” around the core Bitcoin
  protocol that is run by the majority of nodes on the network.
  ”bitcoind” is the same software but without the user interface — it is
  simply a process that runs in the background and only allows access to
  it through its API.  For the purposes of running Armory, either one is
  sufficient, but one of them must be running and synchronized.  The
  latest version of Armory will run bitcoind for you in the background.

Armory/Bitcoind does need to download the entire blockchain:

  Regardless of which one you use, it will download the entire
  blockchain

Source for both snips: https://bitcoinarmory.com/about/armory-and-bitcoin-qt/


How can you construct a cycle with LND to rebalance one of your channels with another?

Create an invoice for yourself: lncli addinvoice <amt>
Pay the invoice specifying the outgoing channel and the last hop to take before paying you: lncli payinvoice --allow_self_payment --outgoing_chan_id <outgoing_chan> --last_hop <last_hop> <payreq_from_1>

To get the outgoing channel id use lncli listchannels --active_only. I usually have to grep for the remote_pubkey that I get from Zeus interface and then look for the chan_id string.
The last hop is the remote_pubkey of the node associated with the channel you want to increase the local balance on.
I learned this from this pull request documentation: https://github.com/lightningnetwork/lnd/pull/3736
Good luck rebalancing!


Reject TXs based on fee in comparison to TX size?

minrelayfee is already in BTC/kB, so that's exactly what you need.

  35kb tx with a tiny 0.0003 fee.

Didn't do the math, but I think even the default minrelayfee should block those.


There's no document explaining step-by-step, because the routing decisions are not part of the protocol (the BOLTs). It is purely client-side decision making about how to find a route through the graph, and any client can choose to implement their own mechanisms. There is no compatibility issues because only the payer makes routing decisions, and intermediate hops merely forward packets as requested.

If you wish to know the specific details of how LND, c-lightning etc implement it, you will need to dig into the code and documentation for those projects.

As far as I'm aware, the current implementations all use a variant of Dijstra's algorithm, or A*, taking the routing fees as the heuristic to minimize when calculating the weights of each path, and c-lightning uses the Bellman-Ford modification in the link above.

Once a path has been calculated by the payer, there is a standard process by which the path and the packets for it are constructed, defined in BOLT#4.


Why is the accept / utility of one of my miners consistently higher than the others?

It appears that the worker with the more shares/utility is solving low difficulty pool shares, where the other 3 are probably mining at a more appropriate difficulty level.

Utility is the measure of how many shares are submitted per minute (diff1*pool difficulty mining at). That suggests further that the unit is working on lower difficulty shares than the other workers.

Usually on your pool website there will be a spot to change worker difficulty, and for those units, I would recommend 2 for the ICA and 8 for AMU, but you could always adjust according to your preference.


How do I list all unique scripts from blockchain?

If you are looking for actual input scripts then the answer is simple: if there are n outputs being claimed then there are exactly n distinct scripts that are used exactly once. This is because each script includes a signature for a particular output that is being claimed, and they should be unique (that is excluding random collision, which are extremely unlikely).

If you are looking for output scripts then the number of distinct scripts is likely to be the number of addresses that received an incoming transaction, as they contain the addresses that may claim the output.

This is ofcourse just for the standard transactions in which you put up a claiming condition by requiring a single signature from an address and then provide the matching signature when claiming it.

More interesting could be the number of distinct script formats. That is counting the unique types of scripts, for example by just replacing all signatures and hashes with a placeholder and then counting them.

As far as I know blockchain.info does not currently offer such a functionality, but they might be interested to include it.


How to monitor large number of public addresses

My idea is create an account at http://blockchain.info/wallet then add all of your address as watch only address. This way you can see everything about them all together or separate.


Why doesn't a change address just point back to the address that sent the transaction?

The reason for not sending back to (one of the) previous addresses, is privacy. Not just your privacy - perhaps you don't care - but the privacy of everyone using the system. Reusing addresses this way makes it blatantly obvious which of the output is the real output and which is change, meaning that transaction graph analysis becomes a lot easier.

Wallet backups going out of date is a very good counter-argument to this. Security and privacy are often hard to combine. It's also the reason why for example Multibit and Bitcoin Wallet for Android up to now do reuse addresses for change.

However, a solution that has the advantages of both exists. Deterministic wallets (in particular BIP32) allow generation of new change addresses (including the ability to detect them when recovering from a backup), without revealing this to everyone in the world. In addition, they do support selective disclosure to people with whom you want to share your wallet's history.


What protection does Bitcoin have against Denial of Service (DoS) attacks?

The network has a moderate amount of protection against DoS attacks. If you flooded a single node with data from a single source, it would just drop you. You could reconnect, of course. You would need a lot of resources and effort to knock out a node, but it's possible to knock out a single node by overloading it.

The owner of an attacked node could simply stop accepting incoming connections and he could still operate. He still might, by sheer bad luck, make some outgoing connections to malicious nodes. But he'd quickly close all such connections and be left only with connections to non-malicious nodes.

Transaction flooding is perhaps the DoS attack for which the network is currently best defended. Trying to flood the network with legitimate, but nonsense transactions won't work very well. To form such a transaction, you have to claim some coins. The network will only maintain one transaction that claims a given output. And to claim newer output generally requires a transaction fee.

It's hard to imagine any scenario in which an attacker could maintain a significant number of concurrently valid transactions without paying large transaction fees. And even if he could, as soon as those were accepted, he'd need to be able to claim additional transaction outputs to keep up the flood. The outputs of the transaction from earlier in the flood would be too new to spend without fees.

In any event, the harm would be minimal. If this were working to cause harm, that would mean legitimate transactions wouldn't be going through. This means their coins would be getting older and older while the attack had to consist of newer and newer transaction outputs. Soon, the legitimate transactions would win.


bitcoin-cli can read rpcuser and rpcpassword out of your config file. Just run it like this:

bitcoin-cli -conf=/Users/varunvb/Downloads/bitcoin.conf -datadir=/Users/varunvb/Downloads getinfo

Also, remove the -e from your bitcoin.conf.


Convert WIF to Witness PubKey Hash Address in Go

There are 2 cases where the version byte in the witness program is either 0 or 1.
If the version byte is 0, you need a 20-byte HASH160 of the public key. Reference wiki.
witnessProg := btcutil.Hash160(w.SerializePubKey())
p2wpkh, err := btcutil.NewAddressWitnessPubKeyHash(witnessProg, chainParams)

But I am not really sure about the case where version byte is 1.
Edit: previous implementation was probably wrong, fixed after some more research.


This guide will set up everything you need on a single machine.

Let's get started by setting up the environment:

sudo apt-get update
sudo apt-get install build-essential
sudo apt-get install automake gcc
sudo apt-get install libevent-dev libmemcached-dev libcurl4-openssl-dev zlib1g-dev libjansson-dev curl memcached

Depending on your distro some of these may not be available (libjansson-dev for example is not available on Lucid), and you may have to download and compile the sources.

Pushpool requires a database to work so we have to install either SQLite3 or MySQL. MySQL probably is the better choice, but SQLite3 suffices to just test pushpool:

sudo apt-get install libsqlite3-dev sqlite3

To get MySQL you'd instead install libmysql++-dev.

Next we download the pushpool source and extract it to /tmp/:

cd /tmp/
curl -s http://yyz.us/bitcoin/pushpool-0.5.1.tar.gz | tar -xvz
cd pushpool-0.5.1

Now let's get on with it by configuring, compiling and installing it into /opt/pushpool:

./configure --prefix=/opt/pushpool/
make
sudo make install
cd /opt/pushpool/

At this point we can quickly check that everything worked:

$ sbin/pushpoold -E -F
[2013-01-04 16:00:40.682356] config file(server.json): No such file or directory

All we need to do now is to configure the pushpool server.

sudo cp /tmp/pushpool-0.5.1/example-cfg.json /opt/pushpool/server.json
sudo nano /opt/pushpool/server.json

Here's mine for example:

{
        # network ports
        "listen" : [
                # binary protocol (default), port 8336
                { "port" : 8336 },

                # HTTP JSON-RPC protocol, port 8337
                { "port" : 8337, "protocol" : "http-json" }

        ],

        # database settings
        "database" : {
                "engine" : "sqlite3",
                "name" : "/tmp/data.sqlite",
                "stmt.pwdb" :
                  "SELECT password FROM pool_worker WHERE username = ?"

        },

        # cache settings
        "memcached" : {
                "servers" : [
                        { "host" : "127.0.0.1", "port" : 11211 }
                ]
        },

        "pid" : "/tmp/pushpoold.pid",

        # overrides local hostname detection
        "forcehost" : "localhost.localdomain",

        "log.requests" : "/tmp/request.log",
        "log.shares" : "/tmp/shares.log",

        # the server assumes longpolling (w/ SIGUSR1 called for each blk)
        "longpoll.disable" : false,

        # length of time to cache username/password credentials, in seconds
        "auth.cred_cache.expire" : 75,

        # RPC settings
        "rpc.url" : "http://127.0.0.1:8332/",
        "rpc.user" : "bitcoinrpc",
        "rpc.pass" : "bitcoinpassword",

        # rewrite returned 'target' to difficulty-1?
        "rpc.target.rewrite" : true,

        # allow clients to update the ntime field of their work
        "roll.ntime.disable" : false
}

And finally we get to the database setup:

sqlite3 /tmp/data.sqlite "CREATE TABLE pool_worker (username VARCHAR(32), password VARCHAR(32))"
sqlite3 /tmp/data.sqlite "INSERT INTO pool_worker VALUES ('username', 'password');

At this point we have created the database and inserted a new user called username and password password. Running sbin/pushpoold -E -F again will start the daemon.

Pointing your miner to http://username:password@127.0.0.1:8336/ should get you mining.


How much bitcoin do companies have on their balance sheets?

If a public company accepts bitcoin, it would be recorded on it's balance sheet as Cash.  You might be able to discover the amount by getting lists of companies that accept Btc and then looking it up in their annual (10-K) and quarterly (8-Q) reports on EDGAR (https://www.sec.gov/edgar/searchedgar/companysearch.html).


Who is in the Bitcoin Business Alliance?

Well, I won't speak about other people, just that I am now a part of BBA myself.


Stealth address transaction example on Bitcoin's blockchain

You cannot tell them apart from transactions using ordinary addresses; they are exactly the same.  Any regular transaction you look at could have been created using a stealth address.

As I wrote in my answer here, a "stealth address" is just one particular way of generating a unique address, known only to the payer and payee, to use for a transaction.  Once the unique address is created, the transaction itself is created just like any other.


How does Base58Check prefix character prediction work?

This is not unique to Base58 encoding (nor the Check part). It's about base conversion:

The number 13 in hex is 0x0d, the number 18 in hex is 0x12. Even though in decimal both start with 1, their first digits in hex are different. In fact, in Bitcoin's address format, unlike the example above, that would be comparing d with 1 instead of 0 with 1 because encoded Bitcoin addresses have different lengths.

What's common is the largest factor deciding the significant digits are the significant digits. That's why if you want to calculate a few first characters of Base58check instead of adding 4 byte checksum at the end you can add 4 empty bytes and the first characters of the result would be same. Most of the time, (unless a base is a power of another, such as base-2 and base-16. Also note that 1s in front of addresses in Bitcoin are specially handled) the length of the input should be the same to calculate the same first few characters.

  So, how is the expected prefix characters of Base58Check derived from the prefix?

We also need to have an input of constant length (including 4 bytes of Base58check). I assume we have the first few bytes of the input. We pad the rest with zeros and Base58 encode it. We than pad the rest with 1s (or 255s if bytes) and Base58 encode.

Then we open the Bae58 alphabet:

123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz

Suppose we calculated 1FGMQ... as the lower range and 1FJwz... as the higher range. As long as the input is of the same length, no matter what you fill in to the rest of the bytes the encoded address will be between those two.


Code example for Ardor bundler code snippet to filter transactions of a certain criteria to pay ZERO 0 ignis Fees?

Take a look at the bundler filter shipped with Ardor: src/java/nxt/addons/AccountPropertyBundler.java and PersonalBundler.java

You need to be familiar with internal Ardor interfaces in order to write your own bundler filter.  The bundler filter runs as part of the server and is loaded during server initialization.

You specify a custom bundler in nxt.properties by setting nxt.bundlingFilter.


A Butterflylabs 5 GH/s Bitcoin Miner running at 270 Watts?

If you can hold your hand on the Bitcoin Miner for an extended period of time without burning it, I doubt the cube is consuming 270 Watts. What does your mining software indicate the temperature is?  My two cubes run at temperatures between upper 30s and low 50s Celsius. (These cubes do make nice winter hand warmers for cold typing hands:-)

Once you rule out the cube is not sucking the power, the question then becomes what about the associated power brick or the integrity of the meter. Again, imagine the heat a sixty Watt indecent light bulb puts out.  If your brick can't be held for an extended period of time without burning your hand, you got a bad brick that mightbe a fire hazard.  Otherwise, you got a bad meter or your house may need capacitive power factor (PF) correction where you plug your cube into an outlet.


You can try this, close core and temporarily add these to your config file in the data directory (create a bitcoin.conf file if you didn't have one).
Code:

addresstype=p2sh-segwit

changetype=p2sh-segwit

keypool=5000

(delete them later if this didn't worked)
That will force your wallet to create 4000 more "P2SH Wrapped SegWit" receiving and change addresses to your wallet's keypool.

Then open Bitcoin core, open console (Window->Console), and type getaddressinfo '3your-missing-addressxxxxxxxx'
If the value of "ismine" is "true", you've restored that address and it's beyond the default keypool (1000 receiving/change).

This worked. Solution found here:
https://bitcointalk.org/index.php?topic=5244862.msg54344316#msg54344316


how do you get your computer not to run out of memory with the system syncing

You can configure Bitcoin Core to run with --dbcache=50 which will limit the database cache size to 50MB (default is 100MB).  You can read more about it here.

Alternatively, you probably don't need to be running a full node, and should instead consider using an SPV wallet, which will consume a lot less of your system resources.


It's valid but it's a miner writing wrong data, e.g. changing a transaction address to his own or changing a 3 btc transaction to 30 (while the wallet holds 50). The hashes are correct but the miner is using his position as miner to benefit himself or others

Miners can't change that data in a transaction because that data is secured by the transaction-author's digital signature. Any change in the data will cause a signature check to fail.
Nobody cares about other people's balances, no one ever needs to know another person's balance. Bitcoin keeps track of coins not balances. In this case a coin means an unspent transaction output (UTXO). These UTXOs can only be spent by someone who knows the secret number (private-key) that can be used in a mathematical proof of right to spend.


I mean, is there a way to import the real bitcoin transactions on the blockchain into a private blockchain?

no


Are Bitcoin wallet apps on iOS truly decentralised

An iOS app does not need to use any multiple connection framework provided by the iOS SDK at all. Apple does not need to have any API to support this since it can be done with threading and the normal network connection API.

An iOS app developer can use the standard Network connection framework in order to open a TCP connection to whatever nodes they want to. They can connect to multiple nodes by creating a thread for each node and each thread uses the Network connection framework to establish the connection. In this way, there is no need for anything like MultiPeerConnectivity or any special framework for connecting to multiple network targets.


How can I hide my bitcoin transactions to protect anonymity from others?

Your address is a classical 1 (Pay-to-public-key-hash) address. Your friend has a newer Bech32 Pay-to-Witness-public-key-hash-type address. The block explorer you referenced is partially compatible with Bech32. Sometimes, it doesn't work. On the other hand, there's nothing that prevents you from looking at your friend's transactions using a different block explorer such as https://Blockstream.info or https://blockchair.com/.


How to claim Bitcoin Cash & Bitcoin Gold from paper wallet

Go to Blockchain.info

Sign up and after logging in, go to settings. Then in settings, you will see addresses as shown below:

Then click on Import Bitcoin Address as shown:

Then add your private key as it is in the form as shown:

Click import, and you will be able to use your BTC again.

Now to get Bitcoin Cash, just go to Settings > General

There you will see a button near this to claim your Bitcoin Cash as well:

Regarding Bitcoin Gold, it is still not officially started, and will update the answer once there is any secure way to access your Bitcoin Gold as well.

Please follow that and let me know if you were able to retrieve the coins.

Update:

For those who want to retrieve BTG, please head to Coinsutra for easy retrieval.


How do nodes communicate over Lightning network?

You are confusing two things here: payment channels and network communication. A payment channel is really the set of commitment transactions and their revocations. It is unrelated to network communications and the participants in a payment channel do not need to communicate via one specific way.

The network communications that nodes use to talk to each other (e.g. to update payment channel states) use TCP in a P2P manner. Like Bitcoin, a node establishes a TCP connection to other nodes, and those nodes have connections to other nodes. P2P is not a communication standard like TCP and UDP, rather it is a model of the network's structure and is a concept.


Bitcoin and Merkle Tree - is in Bitcoin the Merkle Tree actually a List (which of course is a special form of a tree)?

The edit is completely correct. However, there are two known quirks you might be interested:

This quirk happens if the number of transaction is not 2^n. You can read more about it here. This was known by the creator of Bitcoin.
This attack (may) happen in the case where a transaction with length 64 bytes is an element of a Merkle tree. Details can be found here.


How are MtGox options going to affect Bitcoin price volatility?

Probably both, though the effect may be pretty small.

Arguably, the most prudent use of options is reducing risk.  For example, a merchant with accounts receivable in Bitcoins would want to protect the value of the fixed amount of BTC he will receive.  Options can limit his downside risk.  At present the price volatility of Bitcoins hampers its use for commerce, since the value of an asking price in BTC varies so much from day to day.  With options to reduce risk, more businesses will be willing to accept Bitcoins, bringing more liquidity to the Bitcoin "ecosystem".

Increased acceptance of Bitcoins and increased "money supply" are more likely than options to stabilize prices.  They would reduce price fluctuations caused by thin trading.  The same effect is seen in the stock market where relatively unknown stocks undergo drastic price swings due to somewhat small trades.  Conversely, a widely traded stock exhibits much less volatility.


How to run a bitcoin server with automatic restart and backup?

Upstart is the preferred method, have it launch your mining program on boot and respawn the program if it dies.

Checking if it's working is another matter, it requires a more meta approach.  I would suggest you start another script that queries bitcoind via the command line, parses the response, and kills the process if it's not mining.  Upstart will see that the process is gone and spawn a new one.

If you run into problems (overclocked GPU's are mighty unstable!) you might even want to log the number of times you have killed it and reboot the server after X kills in Y minutes.


I agree, that 15W card should calculate hashes slower than anything listed at  https://en.bitcoin.it/wiki/Mining_hardware_comparison - 20MH/s sounds about right.  You probably misread the units (1GH = 1000MH), or the software has a bug and miswrote them.


electrum CLI - 'daemon is not connected'

you need to run

electrum daemon load_wallet

load_wallet or other wallet


Is there an address format for P2WPKH or P2WSH?

No.  BIP142 would have provided an address format for these output scripts, but it is in "deferred" status and expected to remain that way.  Wallet developers are being encouraged to discuss a new address format on the bitcoin-dev mailing list, and it is my understanding that one proposal may be coming soon.

In the meantime, BIP70 supports paying to arbitrary outputs, so it can be used for the native segwit outputs, as can any other software that communicates using its own protocol (such as payment channel software like that being used for various Lightning Network implementations).

  If P2WPKH uses the same address format as P2PKH, how does a wallet know which one to use?

Although the new address proposal will probably not use base58check like the current address formats for P2PKH and P2SH, the now-deferred proposal in BIP142 explains how this could easily be done by changing the first byte of the address (which is a version number):

"For P2WPKH address, the address version is 6 (0x06) for a main-network address or 3 (0x03) for a testnet address.

"For P2WSH address, the address version is 10 (0x0A) for a main-network address or 40 (0x28) for a testnet address."


Is stack overflow reputation actually a Cryptocurrency?

No, it is not accurate to call the reputation system a cryptocurrency.

Cryptocurrencies use a distributed form of updating the ledger of ownership, not controlled by any one person. Stack Exchange reputation points are just an online point system maintained and controlled by the Stack Exchange company. The two are very different.

Cryptocurrencies also typically have a blockchain, and are transferrable at any time between any two persons. With SE Rep, you can only transfer if you do a bounty. And SE rep can be created out of thin air for someone answering a question well. Cryptocurrencies have a supply that is carefully controlled by code, and can only be created by solving a block.


Lightweight wallets use a simplified payment verification (SPV) mode which only requires them to download part of the blockchain so yes a full node is required,yes you can clone an existing opensource wallet but skills is required for that


What is the difference between a miner and a full node?

A 'full node' is a participant on the network that has independently validated the complete copy of the blockchain, and thus has verified all transactions since the beginning.  This requires about 350GB of drive space (currently).
A pruning node is one that has verified all prior transactions; however, it has deleted all blocks below a certain space requirement, but still has a copy of the UXTO set.  It's less useful to the community, but is useful to the node's owner, and takes less resources on the computer (can be under 1GB of drive space).
A miner on the other hand creates blocks in the blockchain which the nodes keep.  Basically, the miner adds transactions to a block, with the goal of creating a new block with a valid hash that will be accepted by the network.    Miners spend about 10 minutes working on a problem, but nodes keep that result forever after in the database and verify it with others.  Miners don't need to know about prior blocks (except for the prior one) with very few exceptions.
So, a miner is completely different than a full node.  It's not comparing the same like things.  Full vs Light is comparing two like things - fruit (apple and orange).  Miner vs FullNode is comparing two totally different things (apple and fence).


Why does bitcoind have to listen to the public internet when supporting lnd?

Your experience was coincidental, there's no requirement for bitcoind to be listening on a public interface while using lightningd.


What is the User Activated Softfork (UASF) proposal? How do its risks compare to hardforks?

What does the UASF proposal entail?

The UASF proposal is an extension of BIP9 that allows soft-forks to specify a mandatory activation time. If miners have not started signaling support by this time, they must start to signal. Any blocks not signaling support for the soft-fork after this time are rejected.

BIP148 is an instance of the UASF proposal that implements a UASF for SegWit. The idea is to have the economic majority, users and businesses, run software that forces miners to activate SegWit. If miners do not start signaling for SegWit by the proposed time, their blocks and the bitcoins mined within will be invalid. In this sense, it is a hard-fork for miners, but a soft-fork for most full-node operators.

A soft-fork usually undergoes the IsSuperMajority process, where miners do not start to enforce the new rules until 95% of the last 1000 blocks signal readiness to enforce. This is usually just for coordination, so that miners are in agreement about exactly when the new rules become enforced. Of late, however, miners have been using this process to block the SegWit soft-fork from being enforced at all. Many believe that miners should not be able to block soft-forks, so the UASF was created to remove that ability from miners.

  How do its risks compare to other methods of upgrading the protocol?

A UASF may transition to be enforced before miners have updated their software to support it (typically this would be intentional on a miner's part, as the activation date would be chosen very far in advance). In this case, that miner may be mining invalid blocks, according to the rest of the upgraded network. If a large portion of the network has upgraded their software to enforce the signalling for the soft-fork, but a large portion of the miners do not agree to signal for the support of the soft-fork, then a chain fork may occur. Non-mining nodes would see very slow block generation times and the transaction backlog could grow. Mining nodes would produce blocks, and bitcoins within, that are not acknowledged as valid by exchanges and users, rendering their mined bitcoins worthless if they do not upgrade.

This situation would create a stand-off between economic stake-holders and miners. For upgraded nodes, the longer the stand-off continues, the more transactions build up in the backlog without miners mining them. For miners, a chain-split means they are creating bitcoins that exchanges and users will not accept as payment, which is essentially losing money. It is undetermined which group would give-in first and support the other's chain just for the sake of restoring consensus and clearing the transaction backlog. Users and exchanges already cope with low transaction throughput and high block solve times due to normal variance, whereas miners currently have nearly 100% of their blocks accepted by the network. So I suspect the miners would be the first to give in and start signalling support for the soft-fork they don't like.

However, a miner may produce a block which signals support for a soft-fork without actually enforcing the new rules imposed by the soft fork. This may conceal the lack of consensus temporarily, for as long as the produced blocks follow all the rules of the new soft-fork. As soon as a block is produced that does not satisfy the new soft-fork rules but is still valid according to the old pre-soft-fork rules, there would be a chain split with the same stand-off dynamics mentioned before.

UASFs also rely on getting a large portion of the network, especially large economic actors such as exchanges, to upgrade. If this does not happen, and the miners do not start signalling support for the new soft-fork on their own, then the minority of nodes that did upgrade risk forking onto their own chain with no miners on it. This may cause outages of some bitcoin services, but since the bulk of nodes and miners are supporting the growing chain, there would at least be consensus on which chain is valid. Upgraded users would have to downgrade their software to return to consensus with the main chain. In this case, the UASF fails.

But who decides whether a soft-fork has enough consensus to warrant a mandatory activation time? Shaolinfry has this to say on this topic:

  There is an implicit assumption in my text, that the decision to deploy a soft fork (regardless of the activation method) is based on a reasonable expectation that users will make use of the new feature. Hashrate signalling is not a vote, but a coordination trigger. Soft forks are backwards compatible and opt-in; so long as they are well written and bug free, users should at worst, be agnostic towards them because they have a choice whether to safely use the new feature or not, without preventing others' enjoyment of the feature. A controversial or unreasonable soft fork would not gain traction and I believe it would be fairly self evident. [Source]

So UASFs could be used to attempt to force controversial or potentially harmful updates, but enforcing the UASF activation time would require the majority of the network to upgrade, so this may be seen as a relatively small risk factor.

In short, UASFs are more risky, but may be deemed necessary when miners refuse to support soft-forks that have the backing of the economic majority.


What would be the implications of limiting Bitcoin transactions to fifty inputs?

The main concern with sigops is the quadratic behavior of the pre-segwit signature hash.  I believe specially constructed transactions with lots of OP_CHECKSIGS but few inputs would be similarly bad as transaction with many inputs.

Having additional limits also makes life a little harder for anyone working with the system; e.g. you have to be under 100k, AND under 50 inputs.

Ultimately the best solution is to avoid quadratic behavior like the new signature hashing in Bitcoin did.


What will happen if all bitcoin nodes are pruned?

If all nodes were pruned a new node would keep making connections looking for an unpruned peer forever and fail to sync.  If instead almost all were pruned it would simply take a longer time than today to get connected to them and start syncing.


One option would be to ask multiple servers: that way you can as sure as you want that. Or you could just run a server—it’s quite simple—and point the wallet to it since, presumably, you wouldn’t lie to yourself.


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


Which pools offer payouts via generation? (Eligius-style payouts)

Luke recently posted that:

  Fresh-mined coins for payouts were innovated by pools in the following
  order: puddinpop, Eligius, BitPenny, p2pool.


Handling change addresses without using rawtransactions?

It sounds like there is a misunderstanding of how accounts work (which is not surprising given that the accounts system is very unintuitive).

First of all, addresses are only tied to accounts for receiving, not sending. So when you send from an account, any input associated with any address in the wallet can be selected for the transaction. During that send, the account's balance is deducted by exactly the amount that was sent. Change goes back into the wallet and has no effect on the balance as it was not sent from the account.

The account field in listunspent is slightly misleading as outputs are really not associated with accounts at all. When you send from an account, ANY output can be chosen as inputs for the transaction, not just ones that are part of the account.

When sending, because you know the recipients address, you can use the subtractFeeFrom parameters of sendmany or sendtoaddress to specify that the fee will be subtracted from the specified addresses (i.e. the recipients). This should still deduct from the account balance.


The nonce is an arbitrary string of bits with no particular meaning. Typically they are converted into an unsigned integer for convenience. Every possible set of nonce bits has a corresponding integer in this representation.

To get letter in a nonce, you'd have to present the bits in the nonce in some encoding scheme that had some way to encode letters. There is no such scheme in common use.


Bitcoin Core does this thing called non-atomic flushing. What that means is that the database, instead of being updated atomically (i.e. everything is written at the same time, or nothing is written), has data written to it over time. If the database crashes, with non-atomic flushing, there will be some data written, and some data that is not written. This is different from atomic flushing where either all of the data was written, or none of it was.

Non-atomic flushing allows Bitcoin Core to skip validation of things it has already validated and then just flush things to the database later after a crash or unclean shutdown. But in order to know where it has validated up to, it has to store that block hash (where it has validated up to and where it is flushing up to). It also has to store the block it started at (the block the database knew up to when flushing began).

This is where GetHeadBlocks() comes in. When Bitcoin Core begins flushing, it first writes those two blocks, the old one where the database head was at, and the new one, where the database head will be once flushing finishes. In the event of an unclean shutdown or database crash, these values are already written to the database so it can pull those out of the database, know where its last known good database state was at, and know where it has validated up to so it can skip full validation and just build the database data and flush it. If there was no unclean shutdown or crash, GetHeadBlocks() would return an empty vector.

For example, suppose the database was at block 50, and it is flushing to block 60. When it begins flushing, the hashes of blocks 50 and 60 are written to the database. Suppose that the computer suddenly loses power when it has only flushed up to block 55. When the node comes back on, it will call GetHeadBlocks() and get the hashes of blocks 50 and 60. Now it knows that it was mid-flush when it uncleanly shutdown. So it then rebuilds what the database would be from blocks 50 to 60 but does not perform full validation. It then flushes the remaining data and removes the hashes of blocks 50 and 60 from where they were written.