text:
Need help with my withdrawal
If I used coinme to deposit at an atm can someone walk me through how to withdrawal? I have the coinme app and trust wallet? Which one would I use? Someone was helping me and stopped responding..
Desperately seeking help!

According to the FAQ on the coinme website

Any bitcoin or crypto purchase made through Coinme at one of our partner locations will be stored in your Coinme wallet.

They also have a video explaining how to "sell Bitcoin for cash"

You wrote

Someone was helping me and stopped responding.

Frankly, that's a bit of a red flag. All too often that means somebody you met online tricked you and ran away with your money. I hope this isn't the case.

Desperately seeking help!

Beware, don't pay any unexpected fees to people who offer to help you. Desperate people attract scammers pretending to be able to return stolen money, pretending to know someone who can return stolen money or pretending to be an official in charge of returning stolen money. I recommend reading a few answers to questions tagged "fraud"


text:
Why is number of downloaded block files far fewer than current block height?
I'm attempting to download the entire blockchain and then run some analysis of wealth distribution at various points in time and in response to specific events. A website like blockchain.com's block explorer is similar to what I would like, but scrolling through hundreds of pages for thousands of blocks isn't exactly feasible
I've already downloaded bitcoin core and disabled pruned storage, but have noticed that the 'blocks' folder contains blk files only up to ~3000, and there are these rev files up to the same number. I'm confused, because this is obviously nowhere near the actual current block height, but as far as I can tell, I should have everything.

The first blocks are so little in size, so many of them fit into a large blocks file.

the 'blocks' folder contains blk files only up to ~3000, and there are these rev files up to the same number. I'm confused, because this is obviously nowhere near the actual current block height,

That is because each block file contains many blocks, not just one per file.
Each block file is about 128 MB. The earliest files will contain nearly 120,000 blocks each. Recent files will contain about 100 blocks each.

What follows is rather lengthy and may be of no interest to most readers - if you are not OP, you should probably skip it.
We can see how many blocks were in the earliest block file:
C> blockchain -file blk00000.dat -longstats

Statistics for blk00000.dat (2009-01-03 to 2011-04-25)

119967 blocks
435199 transactions (3.6 per block)
     0 Segwit tx    (0.0%)
623168 inputs       (mean 1.4, max 965 per transaction)
653813 outputs      (mean 1.5, max 100 per transaction)

We can compare that with the number of blocks in a more recent block file:
C> blockchain -file blk02400.dat -longstats

Statistics for blk02400.dat (2021-01-09 to 2021-01-10)

   105 blocks
236980 transactions (2257.0 per block)
112027 Segwit tx    (47.3%)
642768 inputs       (mean 2.7, max 1033 per transaction)
710364 outputs      (mean 3.0, max 4107 per transaction)

The exact contents of each block file  will vary from computer to computer but these sort of statistics probably won't vary very much.
We can list the blocks in a block file:
C> blockchain -file blk02400.dat -blocks
   No.|Date and Time   |   Txs|Target  |Id
------|----------------|------|--------|----
     1|2021-01-09 20:25|  3391|170DA8A1|00000000000000000005F03FFA1CE2A9E9D0CE2277C41485F34023472C1356B7
     2|2021-01-09 14:10|  1306|170F2217|00000000000000000004D6301FB493DE076F1668542CFF5092291C5FF668C80A
     3|2021-01-09 20:38|  3100|170DA8A1|00000000000000000008093D43CEB62AC2722189506B7A10B5446FC00E7320C0
     4|2021-01-09 14:16|  2821|170F2217|000000000000000000034F3F40D021B75ED2C059C9FACAD18E6C3B23E5AB87EF
     5|2021-01-09 15:01|  3314|170F2217|00000000000000000006E955A5F5543A9E3DBD5FD6F098BF9A3B376432C682F7
     6|2021-01-09 15:05|  2485|170F2217|00000000000000000003A919868B680476494C6EEDE8CFEFF44AB3EF2D6CEE65
     7|2021-01-09 15:09|  2854|170F2217|0000000000000000000809B96117D2C6C958977AA5B7EE41E1BFC8CDEC6FD78F
     8|2021-01-09 15:18|  2143|170F2217|0000000000000000000EA5ABC8D23CE15F85AFBDF574DA6C82C67BEF5DF0D752
     9|2021-01-09 16:25|  2510|170DA8A1|00000000000000000008063A0A93F2480FC1AAA838459B0CE5C1F483AA79DF18
    10|2021-01-09 16:35|  2731|170DA8A1|000000000000000000002F9BDAE5CF1DE5F886A8DB38CDED6B612A1CEF918CAC
    11|2021-01-09 16:42|  2892|170DA8A1|000000000000000000082B6D302C835B7D4BBC328D9E4B9E8A50BBE3782E0903
    12|2021-01-09 17:12|  3110|170DA8A1|0000000000000000000C1AC5FED21866D539379AB6FDF1A59FCF9B7685D10F71
    13|2021-01-09 17:44|  3125|170DA8A1|000000000000000000065E39F6F57DAF0EA29F64B3D610A94A2024E9C889E9A7
    14|2021-01-09 17:48|  2787|170DA8A1|0000000000000000000D67AE7AC5BF50715EB23B5B86E22998D12769C91AFC71
    15|2021-01-09 17:52|  3083|170DA8A1|000000000000000000082F723B665098596F00FCD6EAF0A363580686DA70C713
    16|2021-01-09 18:07|  2246|170DA8A1|0000000000000000000790E48A8F98EE34D9A16D6153258ED9CF6607ED25FE6B
    17|2021-01-09 18:08|  1774|170DA8A1|0000000000000000000779F3123A2F1FF5B94589B598E160E288AFA33EB8F4EF
    18|2021-01-09 18:28|  2968|170DA8A1|00000000000000000007E224F729A414BCCBE799917453BE54DA9E36C1CC668C
    19|2021-01-09 18:35|  3223|170DA8A1|0000000000000000000402C3D1AE9D7A6BFAB7302EA0C53991397F492C7EBA83
    20|2021-01-09 18:43|  2950|170DA8A1|00000000000000000001F53E1B3F61713D33C0EF13F9A7FEED760C33317632AB
    21|2021-01-09 18:47|  2502|170DA8A1|00000000000000000008FACFF8297CC0E610023F7B73D46E641DA355D9B8A521
    22|2021-01-09 18:54|  2860|170DA8A1|000000000000000000045206A88D6265417AA4E61E517F16FEC65F7831F7A3BC
    23|2021-01-09 19:25|  3288|170DA8A1|0000000000000000000BB38AA4D289F78EC84DD2953D47C52DF427C3CB6EB06B
    24|2021-01-09 19:52|  3081|170DA8A1|00000000000000000001E66AD20E29AC4675D3EF0AB166BD402C01F26A5CC562
    25|2021-01-09 20:38|     1|170DA8A1|00000000000000000005BACEFC27B5960FDD85E1590C75B82454F6C14558975F
    26|2021-01-09 20:51|  2790|170DA8A1|0000000000000000000B9E1C8531CA827A4AFE5B98F57FFEC34BCFCFE797BE47
    27|2021-01-09 21:07|  2689|170DA8A1|0000000000000000000ABB087C2C1598264C3F05CCD2CCDD792A690DA65D8459
    28|2021-01-09 21:24|  2998|170DA8A1|0000000000000000000970E063C43C2A92CB9CF33500A0FE6A2F1A4DD6162530
    29|2021-01-09 21:28|  3288|170DA8A1|00000000000000000006D4021E0ED2F8F08720E826E5260563A6BEA24156E10E
    30|2021-01-09 21:30|  2382|170DA8A1|00000000000000000001EB0DC4D4263AB5E78710D3F6953E64CAEABECBB09B3D
    31|2021-01-09 21:51|  3015|170DA8A1|000000000000000000023A99AD2C797E17B3637D3F33C4591CFF3847F85E8494
    32|2021-01-09 22:00|  2838|170DA8A1|0000000000000000000D5DE02C30786604A52E1888A9536D04C6A9635D161C1F
    33|2021-01-09 21:59|  3004|170DA8A1|000000000000000000019988DB5E710916F7FD8CBAE11C969E6A035569780D18
    34|2021-01-09 22:04|  1142|170DA8A1|0000000000000000000B50CB3CF533334B50A62CB4A936A510A92E5D93B57125
    35|2021-01-09 22:08|  2409|170DA8A1|00000000000000000007FC98B36B1F5A07BA3C89CB584460B9343B4D26322014
    36|2021-01-09 22:23|  3090|170DA8A1|00000000000000000000E7F692996D702284AA4C13E84CA4977E7EEC7E0ABB1F
    37|2021-01-09 22:28|  3012|170DA8A1|0000000000000000000B6CE97DC6F3F7133C0763162D5F3CB14F995C2390A2E8
    38|2021-01-10 00:37|  2394|170DA8A1|0000000000000000000320A02F11EC2D73EFE1573668841528C36B0BB435F3AD
    39|2021-01-10 00:45|  2139|170DA8A1|00000000000000000009570ED0935D992B9B7BB6EB3CF101AA5E0377EE2AEF77
    40|2021-01-10 01:02|  2572|170DA8A1|00000000000000000001D10CB8EDEED36BAA9FC4378DB1963B8D74BC5CB111BC
    41|2021-01-09 22:44|  2655|170DA8A1|00000000000000000002F03956DDA2F7A3F382A2664411BE524527A16EC21812
    42|2021-01-10 01:48|  3223|170DA8A1|00000000000000000006D0758FB720F5B51E4A371BAAA3FF6BF3B76B954B7B43
    43|2021-01-10 01:52|  2546|170DA8A1|0000000000000000000B6FE4B5B3EAE044A9DBA9E6004A0F9A67B9DE82D069A8
    44|2021-01-09 22:45|  2938|170DA8A1|00000000000000000009617534D22D9D32E7E72EC73CB6812200490823CE22A4
    45|2021-01-10 01:54|  2989|170DA8A1|0000000000000000000A94CE6F96F4949F777CFD6F2DCC7E3FFC8F1734E49337
    46|2021-01-09 22:59|  2681|170DA8A1|000000000000000000017A1EA207A0B13EB1891EC20A687E4ED95A5B5DF9332E
    47|2021-01-10 01:55|  1068|170DA8A1|00000000000000000006EAFC816EBD106DB34B2A06818CAA5AF5C1814C10DF4F
    48|2021-01-09 23:07|  2357|170DA8A1|000000000000000000067F8C48BAC6335D70815C719E82871CB9978D8307FB95
    49|2021-01-09 23:19|  2725|170DA8A1|00000000000000000008AA5D1D8C3F5153A22924ECE549223BCF1B2AFB957439
    50|2021-01-10 01:57|  1028|170DA8A1|00000000000000000005D44140FAE05F0EDE3F9E120896379BBE59E93EB0D0B2
    51|2021-01-09 23:44|  2971|170DA8A1|00000000000000000006B229DE520567FA6484555DE3856FCD118E18E4DC8BE3
    52|2021-01-10 02:03|   917|170DA8A1|000000000000000000046ABC7E5ABE57F5E7AE3AF246BF4443D2C8B423B479C5
    53|2021-01-10 00:00|  2320|170DA8A1|00000000000000000006BC39AFAF382CA492D2026DD067FDE4E52BCDBE8EAD07
    54|2021-01-10 00:04|  2449|170DA8A1|00000000000000000005C205D5E55CE8ED68299F99D4A9DDB77D980F2B7A7702
    55|2021-01-10 02:40|  2974|170DA8A1|00000000000000000008BC4F146D04E8109381E62E82CF1AE1C2637DDF0B897F
    56|2021-01-10 00:04|  1779|170DA8A1|0000000000000000000363078973EC40F7B487B47D11009DAAC1AB9D7BE84E81
    57|2021-01-10 02:57|  2199|170DA8A1|0000000000000000000B353F8218E01BB241FAC0CDD161D26CA3874403BBF39C
    58|2021-01-10 00:21|  2337|170DA8A1|00000000000000000005E540A870558B5C9F35E387623C121A5CB8313F18136B
    59|2021-01-10 03:16|  2524|170DA8A1|00000000000000000000C65854E22F72448001E42410D7C3EFD11C98F6C3D667
    60|2021-01-10 03:18|  1807|170DA8A1|00000000000000000000187015798F996931DEB860CBB1C6C685EAA877EB9101
    61|2021-01-10 03:26|  2387|170DA8A1|000000000000000000057D10C92F02C85301358E10F339D5F9752A0873BACA17
    62|2021-01-10 03:28|  1869|170DA8A1|000000000000000000016A6CE5807975CFF07EB74E0B4EB79ACF451490ECF059
    63|2021-01-10 00:21|   893|170DA8A1|000000000000000000012A969245697ECEB07BE3D3ACDE233FA73271D6F5BECA
    64|2021-01-10 00:24|  2086|170DA8A1|00000000000000000008B33D07FC50EDA338425126F04123C7F69431956BFA86
    65|2021-01-10 03:30|  1450|170DA8A1|000000000000000000054F2BA4109E5F3CE8B66EEBC3DC5F6F178468DC9365E3
    66|2021-01-10 07:14|   263|170DA8A1|0000000000000000000D44DC06A741E3439BC6EBE2A112F295AE1C840B2A6FC6
    67|2021-01-10 04:29|  1781|170DA8A1|000000000000000000058277A6AD6B20E7C0E40039CC127013B9EC78C3CF38F8
    68|2021-01-10 07:36|  2448|170DA8A1|00000000000000000002C46C92D4411C7A91E4D3EAA656CD9E40A6C7F2526AA1
    69|2021-01-10 03:34|  2009|170DA8A1|00000000000000000006833F3DB67898D0BEAB11F8DE110490AB1AD134BA0930
    70|2021-01-10 10:02|  1181|170DA8A1|00000000000000000008E23F0ACAE31EC0806578D9C0F082A3B4A203984B9859
    71|2021-01-10 10:12|  2293|170DA8A1|0000000000000000000B8F65405332FD550208E9A9593CB69E21934F69688846
    72|2021-01-10 07:39|  2044|170DA8A1|00000000000000000004A6ED454C9621E4E007DACC7149A83945D5F09A89DBD2
    73|2021-01-10 04:30|  1881|170DA8A1|00000000000000000004478B792B36E692A93D61B8A298DA32ADEC7FFE96F0EF
    74|2021-01-10 03:49|  2317|170DA8A1|00000000000000000001B1F1D934D0CC4D936E47292574FCF030E2BB364F13F3
    75|2021-01-10 10:24|  2818|170DA8A1|0000000000000000000B5A5054E5F45A223921EB750FB24A0ADEDC1D4E7EF41D
    76|2021-01-10 04:40|  1807|170DA8A1|000000000000000000010B2CF32CDCC2F7669B6F587541DD430F4C99C9DDDDF1
    77|2021-01-10 04:01|  2090|170DA8A1|00000000000000000000DE313796DF16EF4789FC6B7704E2A7E667225DC77B42
    78|2021-01-10 07:41|   318|170DA8A1|000000000000000000036461F9B3BFF8CDB0D0B4D8C757B1A626DE8687CBDB62
    79|2021-01-10 07:50|  1849|170DA8A1|0000000000000000000383C9E6C3547E7B47A949320A9ADF9C97575383D32CAF
    80|2021-01-10 10:32|  2378|170DA8A1|000000000000000000000103B3CE7C49083C6A2532E0725DFA3F332F4D474FEC
    81|2021-01-10 04:57|  1015|170DA8A1|0000000000000000000C1EB6DA67CF140E21C29ECB760FCB4F61781E3A7D8AEA
    82|2021-01-10 05:01|  1156|170DA8A1|0000000000000000000B0E5EEC04D784347EF564B3DDB939ECA019A66C9CEDBE
    83|2021-01-10 10:39|  2529|170DA8A1|0000000000000000000D8C72FFEEBE65B9C655B02B52F1941EA009505FCE083A
    84|2021-01-10 07:55|  1295|170DA8A1|0000000000000000000AB5EC32EC090CCEF7F8EE3D7546CEF18A1C0B93472108
    85|2021-01-10 04:25|  2201|170DA8A1|00000000000000000009A2A303DC09CF54FDC5F61767CA3A5E28F87FAC4094D2
    86|2021-01-10 07:58|   749|170DA8A1|00000000000000000006BE3C3D4FCAC8CC2227AF410DB11E36ED8F07C2E5E96B
    87|2021-01-10 04:56|  2312|170DA8A1|00000000000000000008EBCA9E4D528F653D8226CA83DDBDCB41F93272A522C9
    88|2021-01-10 05:07|  1501|170DA8A1|0000000000000000000097E9159B5CF374DB6E8E11F6C5F451AB86390D58C824
    89|2021-01-10 05:10|  1540|170DA8A1|00000000000000000001C49986FC8AA30FE1F06F468A56FB2AF3F29C5AF1B175
    90|2021-01-10 16:26|  1542|170DA8A1|0000000000000000000A6295DEF22EC0FFCBB70AA5A34A14567214AC9550FCA0
    91|2021-01-10 05:49|  2861|170DA8A1|0000000000000000000541A910624C40CEC96C823D78F0C3D49E68D2C8DF1752
    92|2021-01-10 08:10|  1104|170DA8A1|0000000000000000000CB4F5452A21ECB1819427D10914DF21217DCA9CCA7B69
    93|2021-01-10 05:27|  2502|170DA8A1|00000000000000000009475315532F65460EEAF7D7F7E9FAD998C3996FD7A0CB
    94|2021-01-10 10:40|  1619|170DA8A1|0000000000000000000B11842312A15FB02D7CDEFEAF3A68932D43F3229FB40D
    95|2021-01-10 10:53|  2453|170DA8A1|00000000000000000006D1189E451EFAB7E4492E8CD4984E526B7EDC3BC3F7D5
    96|2021-01-10 08:29|  2378|170DA8A1|0000000000000000000793AA8C982AB702B932C7316500E586A2C52CA2C1E863
    97|2021-01-10 16:39|  2808|170DA8A1|0000000000000000000022131D35DDE7409AD4C022521A2E32C3819DAF0B4347
    98|2021-01-10 06:05|  1831|170DA8A1|0000000000000000000267AF6B6E9CDEB5C89A2672086E7D73171FB26068357A
    99|2021-01-10 17:09|  2958|170DA8A1|00000000000000000002FE8AD94D018446BBEB804B375E1285AD3D490C630367
   100|2021-01-10 06:05|  1678|170DA8A1|00000000000000000007CC6F90325D941B9957E185B17E8E8384707090DB17EF
   101|2021-01-10 08:31|  2452|170DA8A1|000000000000000000067EDE91AE7F27BB9A7276FA65D86C59DA871BAB262925
   102|2021-01-10 10:59|  1584|170DA8A1|00000000000000000000E102B9C2A2376F719A4B4BC01547F4F43F71D35F4CBA
   103|2021-01-10 17:13|  2410|170DA8A1|000000000000000000022EE80DFD3BDAB9496AD70834D061604BCDC661080A45
   104|2021-01-10 06:17|  2080|170DA8A1|000000000000000000038BE25434EEB0A039570832D1072FE92F369AD75DCE4D
   105|2021-01-10 11:06|  1466|170DA8A1|00000000000000000002843A3630C957361D1408F26C34FAC7CD02B39E3F6D97

We can list all the transactions in one of those blocks
C> blockchain -file blk02400.dat -block 52

Summary of transactions in block 000000000000000000046ABC7E5ABE57F5E7AE3AF246BF4443D2C8B423B479C5
---

 No.|V|Type  | Ins|Outs|Lock  |B  Satoshi |Id
----|-|------|----|----|------|-----------|---
   1|1|Segwit|   1|   4|2008-09-28 03:27|  721158157|DB1EEB1CF856BE1B38BAE46C2C5A2B29F2E619F8034D2DABA19DB1F91B8FB19F
   2|2|Segwit|   1|   4|665346| 2368483760|50B15923336D75D30CA20646A8118E78B8EEBB98015634F53935367650B59C18
   3|1|Segwit|   1|   2|     0|    1641325|416AB808A3DE945971B0D6FCC182B70E3B75FF5577D456C723B1AC5D97FB2453
   4|1|Legacy|   1|   3|     0|      30913|DC672971AC8708FC8180D7E274CDAB581281CDCEAAE39FF00B52C9EDAD12E6B5
   5|2|Legacy|   2|   3|     0|   22538288|56120BFFA44B7F69040DB578D556E786C8E1D629468A6ACDC6EAE1E11E98D375
   6|1|Segwit|   1|   1|     0|    1258946|E2D8F22094842D4042C557699D7EC6BD4604AA90A503C5C1EFDF844119E25E47
   7|1|Segwit|   1|   2|     0|   28916308|1CE48F8C0F0F72AF64E1E50D59911C5988369D1CC2B17F65CE62D10DA8B9B451
   8|1|Segwit|   1|   2|     0|  266778494|0C6FEA9B49ED3C213515422066FEFD8B7AF33B0DFA56738B66EDA3BF215E8956
   9|2|Segwit|   1|   3|     0| 4559557687|374A9D3F692C4CF790513829F9C2E92B5835DE2393994FC09A516B2412A35FB5
  10|2|Segwit|   1|   2|665346|   23873450|DB3C282C7AAF1CB616CD28DA69D44E07CFC3224852B07863B43DBF2DB1FC84E3
  11|2|Segwit|   1|   2|665346|   23629326|76F2BBA4E7A677B3CAF90FBBD2A5CBFDD35421FF8B57375BEF393B1CEA6E4877
  12|2|Segwit|   1|  10|665346| 1272773474|03CE4A39D72720FDB080E5F70167528CFCB1548ED59DF1A06BDE4AE8ABA2E581
  13|2|Segwit|   1|   2|665346|   21573654|9011B154E9CC3F9EBA2AB9403658D43EEDABA8DEA21191474B6ECB11CAC964F3
  14|2|Segwit|   1|   2|     0|  170071125|534672155360AD914EC9103609F238F36757CEA280A585ECDB9933ED1177E45F
  15|2|Segwit|   2|   2|     0|  651807440|E45F67A948B7A078CC32F7C859BE65DEF8F403C01D8B62121DF13123413154F5
  16|1|Segwit|   1|   3|     0|   36707310|83453CEA55D387C52AD9C828475FA31E85E79224C52E97F20BB70A5FFFBB5F77
  17|1|Segwit|   1|   2|     0|   84156628|A3337D6986E33AD73C8A5734864678B7904C23646BA215A2A990146A43A8EF0B
  18|1|Segwit|   1|   2|     0|   83776167|328ECBE080CDCE1CF23CC30099ABDAA4491096575A77C1319B0208C78AF20295
  19|1|Segwit|   1|   2|     0|   80934141|08D77F850C783C544BE9B868106885DB86D6D5B8FCB07ACE6EF191D8BD606AA2
[...]
 895|2|Segwit|   2|   2|665346|    1123442|45D7FE4FB4D1E83DFC194E8446A9BCA2B3EABC8E0B635E1C1CD35C1711134780
 896|2|Segwit|   1|   2|     0|    1120741|8D2656BF376646F8681E109C1FD188E54DBED8211C6951AE77AB726B7C123B2C
 897|2|Segwit|   1|   2|     0|    1269934|B57740E0960DCA911CFF075A409E79402E7C4588C7BA1BB27A90ABF2D792E171
 898|2|Segwit|   1|   2|     0|    1261686|9D79E4B68352AF3AC6F2E45267886346CAFBDE63A1D07ACD189E9CDD9A83DFB5
 899|2|Segwit|   2|   2|     0|    2100882|52D8EBD3AE147FA5532E9460D969161188A34E1D7030A535E33C898836B795A5
 900|2|Segwit|   2|   2|     0|     376227|C44E060847E801ACBD4828E9746637D05E7C8ABF231993389CAFB960C5DBD477
 901|2|Legacy|   1|   2|665346|    4487935|7E45C209782CFC1AFAAD693E709237DCFF362F97E12B3DD8B4F25F27B1CE07B9
 902|1|Legacy|   2|   2|     0|   12712070|C120857602717596C994074211E648D5F821F71A1242C2038B657DA0F494C115
 903|1|Legacy|   1|   2|     0|   12387703|D5BBD8BAC026E6BE9FB2FFBF501866654E1DA90977B2802EDA7CBCE0933C6178
 904|1|Legacy|   1|   2|     0|   12063336|54EC992AC654BE36CEA7B9FC5F5ED33C47748E0BFC575C960781593A850CA6E7
 905|1|Legacy|   3|   2|     0|     924996|16B9AE3BAFD97D81C30C62693BA27C3554A008C7E621B293A06102B1FD6B2C18
 906|1|Segwit|   2|   2|     0|     666448|91BC39C91FDD3A656864816AC7584EA92899BACF9ED67F7668416D6030BA4D54
 907|2|Segwit|   2|   2|     0|    1101827|DCF22A62A39B6A3FB96E0FE3C352C0062B88568187DF97319DFEF4292D2F6891
 908|2|Segwit|   4|   2|     0|    1086016|82F76CC637809D141CEB8D583CD39A753DA5F7A93A49E4105BFA92F976AD64DF
 909|2|Segwit|   5|   2|     0|    1299211|8CA7B8B8B07C6E3C31D697FBA002E74AFBE6D0058B25F5ED9FD05EC7D47DB424
 910|1|Legacy|   1|   1|     0|      65955|79F10524D4C967C9A49A4079A1C7DA7CD6E05ED32431FF85A0139987E26D6E6B
 911|1|Legacy|   1|   2|     0|     271693|5E7008861A027CCAE77EA278C1163E4BBC3B227B7996F55A5354EBB297C9538F
 912|1|Legacy|   1|   2|     0|     208668|C92FCA753825AF19A1814AA01CF8209319698B1BAFF63A83DC4C0D1B7BF8B02F
 913|2|Segwit|   1|   2|     0|     184940|5320656D370F4187CB13415944285AD5193B730AF41C5DBFABB0AE4E6A6DFC47
 914|1|Segwit|   1|   1|     0|      31481|BE41200E7E0F021A9C86CC79150342544A15A94DF082B4A1E93CA2044BBB8C68
 915|1|Segwit|   2|   1|665347|      90593|7FF57A09259E3E9FC037F3143FBBD852A0D029DE398C12056CD2F23B1FE870C3
 916|1|Legacy|   1|   1|     0|      24265|33CA23938986D73C509BCCD7009CD9E6850A995E14C5B7865B3410446AF07035
 917|1|Segwit|   1|   3|     0|   49329046|BE7F6C492EAD97FA3B6C45184740BE3E71C0C233B41AB65FE27B5A2BF7D3E1D6

We can examine a transaction from that block:
C> blockchain -file blk02400.dat -block 52 -tx 886
Transaction Details in Hex (Decimal/Symbolic):

  Version:................02000000 (2)
  Type:...................0001 (Segwit)
  Inputs:.................03 (3)
  Input:1
    Previous Transaction:.83DF8B6DF89B5F7277BAA7D7BA09061FA1B582F2220827D0D33520276BDD78CC
    Previous Output Index:0007 (7)
    Script Length:........17 (23)
    Unlocking Script:.....1600147F1F6A45857B1F358C984B07890F9115D226F8C9
    Sequence:.............FFFFFFFF
  Input:2
    Previous Transaction:.6198DFBF9FB6F4AE7C4DD38F7CC375CA960F6878732EE0697254562D3589559E
    Previous Output Index:0001 (1)
    Script Length:........17 (23)
    Unlocking Script:.....160014ECD7D1B0B8E482D19273326EF77A6EC0A431FB34
    Sequence:.............FFFFFFFF
  Input:3
    Previous Transaction:.0CE30827913BEC7A2EC5216D2796E9D1E23B00B6B875BE03854053E35F95CF52
    Previous Output Index:0001 (1)
    Script Length:........17 (23)
    Unlocking Script:.....1600141C3A7B47ACE893C90CF01983AE2CB54CCA5EE5BC
    Sequence:.............FFFFFFFF
  Outputs:................02 (2)
  Output 1
    Value:................C57A010000000000 (96965)
    Script Length:........19 (25)
    Locking Script:.......76A9147A6DF010C56E2AC4C72F7A5948ED1BAE7ACED92D88AC
  Output 2
    Value:................8205000000000000 (1410)
    Script Length:........17 (23)
    Locking Script:.......A914EF2532E20719E9D40E3A3FE35472FAD80E9B968A87
  Witness 1
    Item Count:...........02 (2)
    Item 1
      Length:.............48 (72)
      Data:...............3045022100D14107F6DDB48AB581E1662E75483466AB5999B306648E61DFDFC3
                          187A7BCDA502207D819B60D30CAC8CB90A017B5A5FC252D03FEBDBE1CB26B748
                          ADEBF23051502401
    Item 2
      Length:.............21 (33)
      Data:...............024C0DB5B46BAF3985BA6CFDD618BF0A32DB00A7A7238CA10D6EF3F78A0DC75C
                          38
  Witness 2
    Item Count:...........02 (2)
    Item 1
      Length:.............47 (71)
      Data:...............304402202276F11B85E56DB648B71BD82B2BBD68C79A810C135123B6134CE7A7
                          4AD613250220085E6CAA73AD9A3BF512BD10DC093DE9CA2FCDEDE0EDD6A3E79C
                          F4371816F10601
    Item 2
      Length:.............21 (33)
      Data:...............02133ADFA21764CD0B13542A7598388B4C91F4F1E6A42A43472AB5052C550DED
                          30
  Witness 3
    Item Count:...........02 (2)
    Item 1
      Length:.............47 (71)
      Data:...............304402204F91C97137BAFB6CE5BAB8588C887D2CDA9BA9FAA9BE03B980E925F8
                          125547F602203F10604628B9472A284A3119D745AF5802AA454BDEA1E4CE8F6B
                          A30DC34ECC3901
    Item 2
      Length:.............21 (33)
      Data:...............026A9722A6DFA935E36C27D9D0BE5BED54FB96D332E368CC4216F6E6D821477A
                          B5
  LockTime:...............00000000 (0)
  (Calculated hash is 94A7F510C18ABA66FAD5B688C14FC4054A25CC3E525B828954A37277F3A50483)

We can look at the same transaction formatted as a markdown table:
C> blockchain -file blk02400.dat -block 52 -tx 886 -format md

TXID: 94A7F510C18ABA66FAD5B688C14FC4054A25CC3E525B828954A37277F3A50483

Hexadecimal Data
Meaning

02000000
Version 2

0001
Type Segwit

03
3 Inputs

83DF8B6DF89B5F7277BAA7D7BA09061FA1B582F2220827D0D33520276BDD78CC
Input 1 : Previous Transaction ID

0007
Input 1 : Previous Output Index 7

17
Input 1 : Script Length 23

1600147F1F6A45857B1F358C984B07890F9115D226F8C9
Input 1 : Unlocking script

FFFFFFFF
Input 1 : Sequence

6198DFBF9FB6F4AE7C4DD38F7CC375CA960F6878732EE0697254562D3589559E
Input 2 : Previous Transaction ID

0001
Input 2 : Previous Output Index 1

17
Input 2 : Script Length 23

160014ECD7D1B0B8E482D19273326EF77A6EC0A431FB34
Input 2 : Unlocking script

FFFFFFFF
Input 2 : Sequence

0CE30827913BEC7A2EC5216D2796E9D1E23B00B6B875BE03854053E35F95CF52
Input 3 : Previous Transaction ID

0001
Input 3 : Previous Output Index 1

17
Input 3 : Script Length 23

1600141C3A7B47ACE893C90CF01983AE2CB54CCA5EE5BC
Input 3 : Unlocking script

FFFFFFFF
Input 3 : Sequence

02
2 Outputs

C57A010000000000
Output 1 : Value 96965

19
Output 1 : Script Length 25

76A9147A6DF010C56E2AC4C72F7A5948ED1BAE7ACED92D88AC
Output 1 : Locking script

8205000000000000
Output 2 : Value 1410

17
Output 2 : Script Length 23

A914EF2532E20719E9D40E3A3FE35472FAD80E9B968A87
Output 2 : Locking script

02
Witness 0 : Item Count 2

48
Witness 0 : Item 0 : Length 72

3045022100D14107F6DDB48AB581E1662E75483466AB5999B306648E61DFDFC3
Witness 0 : Item 0 : Data

187A7BCDA502207D819B60D30CAC8CB90A017B5A5FC252D03FEBDBE1CB26B748
Witness 0 : Item 0 : ...

ADEBF23051502401
Witness 0 : Item 0 : ...

21
Witness 0 : Item 1 : Length 33

024C0DB5B46BAF3985BA6CFDD618BF0A32DB00A7A7238CA10D6EF3F78A0DC75C
Witness 0 : Item 1 : Data

38
Witness 0 : Item 1 : ...

02
Witness 1 : Item Count 2

47
Witness 1 : Item 0 : Length 71

304402202276F11B85E56DB648B71BD82B2BBD68C79A810C135123B6134CE7A7
Witness 1 : Item 0 : Data

4AD613250220085E6CAA73AD9A3BF512BD10DC093DE9CA2FCDEDE0EDD6A3E79C
Witness 1 : Item 0 : ...

F4371816F10601
Witness 1 : Item 0 : ...

21
Witness 1 : Item 1 : Length 33

02133ADFA21764CD0B13542A7598388B4C91F4F1E6A42A43472AB5052C550DED
Witness 1 : Item 1 : Data

30
Witness 1 : Item 1 : ...

02
Witness 2 : Item Count 2

47
Witness 2 : Item 0 : Length 71

304402204F91C97137BAFB6CE5BAB8588C887D2CDA9BA9FAA9BE03B980E925F8
Witness 2 : Item 0 : Data

125547F602203F10604628B9472A284A3119D745AF5802AA454BDEA1E4CE8F6B
Witness 2 : Item 0 : ...

A30DC34ECC3901
Witness 2 : Item 0 : ...

21
Witness 2 : Item 1 : Length 33

026A9722A6DFA935E36C27D9D0BE5BED54FB96D332E368CC4216F6E6D821477A
Witness 2 : Item 1 : Data

B5
Witness 2 : Item 1 : ...

00000000
LockTime 0

My parser is a work in progress (very occasionally) but there are several other blockchain parsers available.

Ah that makes much more sense, thank you! This still leaves me with the question of how to get the actual transactions out from the block, and not just block-level statistics though..

@incendiary: use a block file parser, I believe there are some available. I wrote my own based on the protocol documentation.  See amended answer for example.

thanks a ton for all this. Definitely cleared a lot of things up for me

source: Stack Exchange

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

sort: votes


text:
Network traffic peaks for Bitcoin Core GUI Node
I have the latest version installed, no SOCKS5 connexion.
Sending maximum is around 4500Ko/s (also seeable on the picture).
Do you know why it goes up like that ?

Does someone could explain these data sending around 4000Ko/s ?

Please use the edit link on your question to add additional information. The Post Answer button should be used only for complete answers to the question. - From Review

I assume that's a graph of network activity attributable to bitcoin-qt.
My hypothesis for the sharp peaks would be that there is a low level of chatter where the node finds out whether peers have new data using small inventory messages. Occasionally a peer has new data and the peaks might represent the actual bulk transfer of that newly discovered data in larger data messages.
The newly discovered data could arise from newly created unconfirmed transactions or from newly mined blocks.
I suppose the only way to actually confirm this would be to correlate the network activity with bitcoin log entries.
I would use Wireshark or another network-sniffer to capture and decode the data being sent & received. I believe Wireshark has protocol decoders for Bitcoin traffic.

Thank you for your answer and the Wireshark tips.
Usually, I don't have a lot of peaks like that,, it was only one or two on the 5min chart.
The main question remain on the fact that on my other computer, I have a maximum sending around 100Ko/s. I say around because on the one I took the picture on this topic,, maximum sending is around 4000Ko/s.
Does someone already have this differences or could explain them ?

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


text:
Does the US hold almost all of the bitcoins?
It seems to me that most of the people involved in this bitcoin market are from the US.
Are there any statistics that can confirm this?
Also, related question. If this is indeed true, is it reasonable to think that bitcoin was invented by the US in order to destroy the dollar? The US would win because they hold most of the bitcoins, while superpowers like China, who sit on trillions of dollars, would end up with worthless dollars. Does this make sense?

There are no precise statistics, but you can make educated guesses about where the BTC are by looking at the trade volumes of large CNY and USD exchanges (and to a more limited degree, the IPs that relay transactions in the network). The rest of your question is mere speculation and any answer would be the same, as such it's not a good fit for StackExchange.

k.. care to share some of those educated guesses?

http://bitcoincharts.com/charts/volumepie/ will give you a good overview. I'd personally consider it more likely that non-US people are trading BTC<->USD than non-CN people trading BTC<->CNY, so the distribution shifts away from USD a bit, but that's merely my opinion.

interesting pies. it looks like there's a bitcoin war between the US and China :D Could my theory be true?

Well, if I was a government that planned to burn its own currency to get rid of debts, I would make sure that my fallback plan wasn't a transparent network with no regulatory influence.

you're assuming that all governments have shady intentions :)

Well, if you think that plotting to "destroy the dollar" does not classify as "shady intentions", I'm really not quite sure what to say. (Hint: Such a plan, if carried out 'successfully', does NOT lead to all Americans living happily ever after while the Chinese are crying because their dollars are worthless)

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


text:
Pending transfer
I sent some bitcoin from my Electrum wallet to Exodus app and the transfer is still pending after more than a day!
I chose the lowest fee possible, could that be the reason? And when I can I expect it confirm?

@Prayank confirmed that yes, it's your fee rate and provided some sites you can use to check the state of the mempool - and hence the fees that fit with your objectives - before sending the transaction.
Additionally, if you want to INCREASE the fee of your transaction AFTER you've sent it, there are a couple of ways to do it. The simplest way is called Replace By Fee (RBF) and the Electrum wallet does support this. Effectively you're going back to the wallet and selecting the transaction and increasing the fee. That then is the new increased fee for the transaction and may help it be confirmed sooner .. depending upon the new fee rate you select.

The way I read it, the user sent from Electrum to Exodus, so the question would be whether Electrum supports RBF, not Exodus.

Doh. Thanks Murch - yes you're correct. I should finish morning coffee before pontificating! Will amend.


text:
What makes cross input signature aggregation complicated to implement?
What makes cross input signature aggregation complicated to implement? Other than for design space reasons why didn't it make it into BIP-Taproot? (Key aggregation within one input can be achieved with MuSig, MuSig2 etc but signatures cannot be aggregated across different inputs with BIP-Taproot.)
This questions was asked by Thorkil Vaerge on Twitter.

Pieter Wuille answered this on Twitter.
The most important complication of cross input aggregation is explained in this Bitcoin dev mailing list post by AJ Towns.

TL;DR: if softforks change which signatures are checked, they mustn't
change what is aggregated together. This is especially complicated when they interact with BIP341's OP_SUCCESSx upgrade mechanism, which could easily let future softforks change script semantics entirely. There is nothing fundamentally hard here - it's just engineering complexity to make sure everything works well together.

Pieter added at a London BitDevs Socratic Seminar on BIP-Taproot:

Graftroot and cross input aggregation are such deeply conceptual changes. You can’t permit building them later. It is such a structural change to how scripts work. These things are not something that can be just added later on top of Taproot. You need a successor. Cross input aggregation, the concept of script verification is no longer a per input thing but it is a per transaction thing. You can’t do it with optimal efficiency, I guess you can invent things. The type of extensibility that is built in is new opcodes, new types of public keys, new sighash types, all these things are made fairly easy and come with almost no downsides compared to not doing them immediately. Real structural changes to script execution, they need something else.

edit (September 2023): The latest state of research on cross input signature aggregation (CISA) is summarized here.

"These things are not something that can be just added later on top of Taproot." Isn't that exactly what will need to happen though?

@nilskp: There is a difference between building on top of Taproot (e.g. a new leaf version) and not leveraging Taproot. Pieter's point above is that cross input signature aggregation can't leverage Taproot and has to be built from scratch.

Thanks @Murch, you're right. I'll delete that last edit.


text:
Is it true that bitcoin could be extremely slow?
I am trying to understand the algorithm of bitcoin.
Let A be a node, and let (...,T_0,T_1,T_2) represents a block chain that A has at some time.
Here, T_i designates a block which was created at the time T_i, meaning that the block T_n was created before the block T_{n+1} was created.
Now, say miners C and D created two different blocks T_3 and T_3’ within 10 minutes. Then, A appends these two blocks to the current block chain and store them separately. Following the above notation, these two chains are (...,T_0,T_1,T_2,T_3) and (...,T_0,T_1,T_2,T_3’).
Now, say E sent F some bitcoins and made a transaction which is included in the block T_3.
After some time, if the blockchain (...,T_0,T_1,T_2,T_3’) is chosen to be the correct one, the chain (...,T_0,T_1,T_2,T_3) is removed from server. (Actually, at this point, these two separate blockchains do not appear in this way. That is, they would appear like (...,T_0,T_1,T_2,T_3’,T_4’,...,T_n’) and (...,T_0,T_1,T_2,T_3,T_4,...,T_n) because as time passes new blocks are added.
Assume that the transaction that E sent F some bitcoins was not included in any other blocks except the block T_3. (This is possible if E sent F very small amount of money, so if this transaction costs really tiny small fee, miners would not choose this transaction to be included in their block).
In this case, if E wants to send some bitcoins to F, does he have to make a transaction all over again?

In this case, if E wants to send some bitcoins to F, does he have to make a transaction all over again?

Not necessarily. A blockchain reorganization will cause transactions that were not confirmed in the "winning" blockchain to remain unconfirmed and placed back into the mempools of nodes which switched blockchains. So the transaction will still be in nodes' mempools and could still be picked up by a miner. If the fee was very low, the situation would be the same as having a "stuck" transaction.

So theoretically, is it possible that some transactions will never be included in a “winning” blockchain? And how many transancations each node can save in mempoola? Is there no limit?

It is theoretically possible for a transaction to remain unconfirmed forever, regardless of blockchain reorgs. The mempool configurations of each node may be different. The defaults for Bitcoin Core nodes is 300 MB of transactions and transactions will be evicted if they remain in the mempool for 2 weeks.

Oh.. so this is a disadvantage of bitcoin algorithm.. thank you very much!

Now, say miners C,D created two different blocks T_3 and T_3’ within
  10 minutes. Then, A appends these two blocks to the current block
  chain and store them separately. Following the above notation, these
  two chains are (...,T_0,T_1,T_2,T_3) and (...,T_0,T_1,T_2,T_3’).

This situation when there are multiple chains of the same length simultaneously co-exists is called a fork. The research paper at http://homepages.gsd.inesc-id.pt/~ler/docencia/rcs1213/papers/P2P2013_041.pdf shows that the probability of fork depends on

the propagation delay of a block in the network which implicitly depends on the size of the block(1 Mb in bitcoin(without segwit2)) which effects
the expected duration of consecutive block generation time(10 min in bitcoin).

It also shows the probability of fork proportional to (avg. block generation time)/(avg. propagation delay). Considering the number in bitcoin the probability that the length of fork i.e n value, in this case, will reduce exponentially.

In this case, if E wants to send some bitcoins to F, does he have to
  make a transaction all over again?

Adding to @Andrew chow's answer, if the txn from E to F is propagated to sufficient fraction of miners who extending the chain (...,T_0,T_1,T_2,T_3,T_4,...,T_n) then it is likely that they will include the txn(E -> F) in the chain as it is yet unspent.

Assume that the transaction that E sent F some bitcoins was not
  included in any other blocks except the block T_3.

Additionally, the main reason for a txn not getting included in the block are
1. It is not propagated to sufficiently many miners.
2. Since a block is limited in size, and the inclusion of txn is purely dependent on the miner mining the block, a miner may prefer a txn with higher txn fee over any other.

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


text:
Importing 24 word mnemonic to bitcoin-qt
How can I import my 24 word mnemonic seed into bitcoin-qt?
I think that I will have to convert it to some other format but I don't know how to do that nor what format to use. BIP 39 does not work.

You can't. Bitcoin Core does not currently allow the importing of seeds or mnemonics.

couldn't one use "https://iancoleman.io/bip39/", enter the 24 words, and at the very bottom get a list of priv & pub keys, that can be imported into bitcoin core (1 by 1) ?

Yes, you could do that, but that's not importing the mnemonic or seed directly into Core. You could still miss some private keys and if you continued to use the wallet that had the mnemonic, then you would likely miss later transactions too.

Electrum can do it. There's no Python script or something to convert it into a format Bitcoin Core can import?

@Geremia It is not a format or encoding issue. It is the fact that Bitcoin Core cannot handle the 512 bit BIP 32 seeds that BIP 39 mnemonics always produce.

any updates, Please add console option!

yes You Can`t, but you could create new wallet then export the private key


text:
How do I construct a Bitcoin transaction with the Bitcoin Core Console?
How do I create a transaction using the debug console of Bitcoin Core v0.15.1 (64-bit)?
I have been able to use the commands to create addresses. I figured out how to create, sign, and send a raw transaction. However when I try to send the transaction, I get an erro saying that my fee is too low.
Am I getting this error because I'm resetting the console before I start my commands ? Should I let my console time add up or reset it before a transaction ?

Am I getting this error because I'm resetting the console before I start my commands ? Should I let my console time add up or reset it before a transaction ?

No, that is completely unrelated.
The transaction fee in a transaction is determined by the difference between the sum of the values of the outputs and the sum of the values of the inputs. Bitcoin Core will not accept a transaction which has a fee rate (in BTC/virtual-kilobyte) that is too low. You probably aren't setting a transaction fee or are setting one that is too low. To set a transaction fee, you need to decrease the values of your outputs so that the difference is larger.


text:
Does the fact that bitcoins are limited prove that the system is a scam?
As we all know the total amount of bitcoins which can be available at any time are capped at 21 Million. This was done by design by its creator/creators (he/she/they say that it is intended to make the coin "scarce").
But if I think about it, this fact is completely destroying the intent of creating a currency for people to buy things with. Nobody who has even the smallest understanding of economy would spend bitcoin to buy things with because it is guaranteed that it will be, sooner or later more valuable over time.
For me, it seems that the only reason this technology was created was just to trap people into buying it, believing that it will become more valuable, but in the end, the only people who do really make real (fiat) money from this are the "early adopters" and the creator himself who got the bitcoins when they were very cheap. Also, take into account that the creator is still anonymous to this day et voila - you got a lot of evidence to why this whole system is just a kind of ponzi scheme designed to distribute wealth from late adopters to early adopters.
Please prove me wrong because until now I was very fascinated by bitcoin and altoins.

There are some good answers here. I'd just like to point out that the thing with scams is that there's a lie or deception involved in it. With bitcoin there is no such thing. Everyone knows about the 21 million coin limit. Everyone knows that those who got in earlier got it cheaper and have a strong influence on the price. Knowing all this you can make an informed decision about whether to buy bitcoin or not.

Nobody who has even the smallest understanding of economy would spend bitcoin to buy things with because it is guaranteed that it will be, sooner or later more valuable over time.

If you assume this statement is a fact, why spend your fiat currency on anything except more Bitcoin? The stock market is virtually guaranteed to keep increasing over time as well, but people are still spending money on non-investments. By your logic, everyone would be keeping everything in investments and only cashing out for bare necessities, because "sooner or later they would be more valuable".

You make a lot of interesting claims. The ethos behind bitcoin is similar to that of gold, hence 'mining'. Gold is also limited supply and I am certain that people who first found gold a long time ago are rich beyond their wildest dreams. That does not stop anybody trading gold for something of value.

... a kind of ponzi scheme ...

Ponzi scheme is a particular arrangement which Bitcoin certainly is not.

My understanding until now was that Bitcoin is designed to serve as a currency not as a storage of value only. thus the term, cryptocurrency.

@Acroneos True, and gold was once widely used as a currency and still regularly is. Paper money is an adaptation of the right to access gold.

Nobody who has even the smallest understanding of economy would spend bitcoin to buy things with because it is guaranteed that it will be, sooner or later more valuable over time.

Apparently, that's not true, because there's an entire economy that's backed by bitcoins. Merchants are willing to accept bitcoin, because it comes with benefits they can't otherwise have, such as privacy, censorship-resistance, fast transaction finality, and less costs.

For me, it seems that the only reason this technology was created was just to trap people into buying it, believing that it will become more valuable, but in the end, the only people who do really make real (fiat) money from this are the "early adopters" and the creator himself who got the bitcoins when they were very cheap.

Some did sell their coins, and bought them solely to return to fiat. Granted. Just as some others didn't.

you got a lot of evidence to why this whole system is just a kind of ponzi scheme designed to distribute wealth from late adopters to early adopters.

The last thing I'd call it is a ponzi scheme. First of all, in a ponzi scheme there are  promised returns from the founder(s). There were no zero promised returns from Satoshi Nakamoto.
Secondly, ponzi schemes are characterized by lack of transparency. Bitcoin is the exact opposite. Everything's transparent, from the source code of the software, to the discussions that were made by those who got involved early.
Thirdly, in ponzi schemes old investors earn when new investors lose. This is clearly not true with bitcoin. If the market value rises, it makes both old and new investors gain, and oppositely, when the market value drops, it makes both the old and new investors lose. It's no more different than gold and stocks.

Or...
... it's limited because we (at least we in Europe) made bad experiences with inflationary money in the past. banks waste your money but you have to pay for that (taxes). banks can print more and more money until it's worthless. One $ is always one $, but you could buy more in the past than now.
I don't think, that Bitcoin is a scam. It's "trying something new". The system has proved that banks are not relevant within it.
And: Why should Satoshi not cash out if it's a scam? He should have around 10,000,000,000$ but his known addresses are untouched for years. What's the reason of risking that money?

Bitcoin is limited by design. It is part of tokonomics. Only if it is limited will it have value. It is not a scam, it is governed by a protocol, not a regulatory body.


text:
Bip32 bitcoin core wallet `hdseed` format from xprv master key
I'm trying to use a mnemonic seed to generate a bitcoin-core wallet. I know core does not support bip39, but it does support bip32 and sethdseed should make it possible to use the seed generated by a given mnemonic.
What I'm trying to do is to generate a seed using https://github.com/iancoleman/bip39 and use that xprv to feed sethdseed on an empty wallet created on bitcoin core.
The main problem I'm facing is that the format required by the bitcoin core wallet is not available, and I'm not being able to generate it on any way:
I've just created a new wallet just for testing and make a dump, it reads something like:
# extended private masterkey: xprv9s21ZrQH143K3ndNedb7hus3kpzuUyAafU9zvKxgqgveg4623gViHrSrkiaweK2WfNNbdANyEa6D9GceWtiyWHPtSdyUCpVweg8A6wdqG7g

L5613pTNa7wks3DVt9HrPYDR1aBpMHn3qpxBLfQyDR4kKgaBrNRS 2019-07-14T21:57:10Z hdseed=1 # addr=32AoHsZ6AvTPxiqkACTMbMcdPhD4Xye1nM
KyAP4Jf5APLei25PbfeohPWaRNmCj2yQjwWtreqM4ixXJR23Dxo7 2019-07-14T21:57:11Z reserve=1 # addr=36DxZaj6JEXgSSdTtsN6yEdULgGrfc5A5W hdkeypath=m/0'/0'/9'
...

So it says that the masterkey given translate on the given hdseed
xprv = xprv9s21ZrQH143K3ndNedb7hus3kpzuUyAafU9zvKxgqgveg4623gViHrSrkiaweK2WfNNbdANyEa6D9GceWtiyWHPtSdyUCpVweg8A6wdqG7g
should translate in some way to:
hdseed = L5613pTNa7wks3DVt9HrPYDR1aBpMHn3qpxBLfQyDR4kKgaBrNRS

But I could not found any way to get from one to the other.
It seems that there is already an isssue on bip39, about this, without results.
I've tested using bitcoinjs-lib with the following code without luck:
const bip32 = require('bip32')
const bitcoin = require('bitcoinjs-lib')
const xpriv = 'xprv9s21ZrQH143K3ndNedb7hus3kpzuUyAafU9zvKxgqgveg4623gViHrSrkiaweK2WfNNbdANyEa6D9GceWtiyWHPtSdyUCpVweg8A6wdqG7g'

const node = bip32.fromBase58(xpriv, bitcoin.networks.bitcoin)

console.log(node.toWIF())

But it does generate 'L1UsWzEdexKrXmNaM8b4dyv4TsMHouVFgKhFANuhomHJjNbniWdx'.

You simply cannot. The HD seed is used to derive the master private key, not the other way around. This derivation uses a hash function so it only works in one direction: HD seed to master private key. Given the master private key, you cannot get the HD seed used to produce it.
BIP 39 mnemonics are used to create a HD seed which is then used to create the master private key. However BIP 39 specifies that the HD seed be created using SHA512 (within PBKDF2) so it will always output a 512 bit seed. But Bitcoin Core cannot take 512 bit seeds, so you cannot use a BIP 39 mnemonic with Bitcoin Core at all.


text:
deriving address from pubkey API problem?
This code:
sender_public_key = sender_private_key.pub
sender_address = P2PKHBitcoinAddress.from_pubkey(sender_public_key)

print(sender_public_key)
print(bitcoin.core.Hash160(sender_public_key))
print(sender_address)

produces output:
CPubKey(b'\x033\xad\xcb\xe4r\xe6\xef\x04\xa0I\x0f(B\x1c\x8a;@C\xa8\x99jo\x8a\x85\xd5\xee\x9e\xe2\x8a\x1f|q')
b'\x93\xa7\xc4E$\xa3\xcf{0\xfe\x91\xa6\xa3XR\xfav6\x80#'
mtygbtN2LZt3U5QcMNQF3Zq2sqJF4HowYm

but Hash160 should give the sender address - the second and the third lines should be the same. What am I missing here?

P2PKH (pay to public key hash) addresses do contain the same information as the 160 bit public key hash they correspond to, but they use a different encoding than is used for hashes typically.
Specifically, addresses use the Base58 encoding format (including a truncated double-SHA256 checksum and a version byte to indicate the type of address). Public keys and hashes are usually presented in hexadecimal.


text:
Fraud account that money was put into
My bank account was fraudulent taken over. They put my money into a bitcoin account it supposed to be the amount of $18500. They have all the information but is supposes to be under my name. They want me to pay them to get it out. I don’t know who why are or what state they are in. I’m just trying to get my money out. I don’t know anything about bitcoin.

Does this answer your question? How do I recover from a cryptocurrency scam?

See also who really controls bitcoin

Does this answer your question? Is it normal to be asked for an advance fee on a withdrawal?

I feel you should be contacting your bank's fraud dept.

Your bank covers bank fraud. Do what @Michael Tidwell said.


text:
Unable to Listen Incoming transaction on bitcoin Node using zeromq
I have done setup and its config setup of bitcoin. I am trying to listen incoming transactions using zeromq I first tried to listen transaction using latest version but not work. Then tried with 5.3.1, 5.3.0 but that also not worked.
Here is my script...
var zmq = require("zeromq"),
sock = zmq.socket("sub");
sock.connect("tcp://52.66.249.25:29000");
sock.subscribe('hashtx');
console.log("Subscriber connected to port 29000");
sock.on("message", function (topic, message) {
console.log(topic.toString(), message.toString('hex'));
});

In above script RPC Host : "52.66.249.25" but that not worked. So then I change host in config and make changes in script and set host : 127.0.0.1 but from this port also i unable to listen an incoming transactions.
Here is my config file.
testnet=1
[test]
txindex=1
listen=1
server=1
rest=1
rpcbind=0.0.0.0
zmqpubrawblock=tcp://52.66.249.25:29000
zmqpubrawtx=tcp://52.66.249.25:29000
zmqpubhashtx=tcp://52.66.249.25:29000
zmqpubhashblock=tcp://52.66.249.25:29000
rpcallowip=0.0.0.0/0
rpcuser=" "
rpcpassword=" "
rpcport=18332


text:
Privacy. How to prevent transaction recipient tracing prior transactions of mine
I am thinking of sending some BTC to a new BTC address, but do not have complete trust in that new one.
I'm sending to someone else, but want to be sure that if I do, they can't access other people I have used the same BTC wallet to send BTC

Could you elaborate? Are you sending to someone else or to another address that you own? Also, what do you mean by not having complete trust in it? Do you not trust the owner of the new address?

I'm sending to someone else, but want to be sure that if I do, they can't access other people I have used the same BTC wallet to send BTC.

So you are asking about financial privacy? By sending a tx, you don't want the recipient to learn about your past transactions?

You might want to consider finding a reliable Bitcoin Tumbler (Bitcoin Mixer).
But be aware that you are placing trust in a third party, especially for custodial mixers. Some people have lost money to fraudulent mixers. I would do my research into a company very carefully before risking using them.
Some wallets have mixing capabilities built in to them. These may be a better option.
One example of an article on the subject is How to Mix Your Bitcoins Using Coinjoin for Greater Privacy -- but I can't vouch for the correctness of this article. I suggest taking the time to do your own research.


text:
How can I progmatically generate bitcoin address with in WASABI Deskstop wallet?
I would like to generate 10000 btc address and save it as csv file on my computer to be uploaded it on my server. I hope anyone can help me find the solution.
Thanks in advanced!

Maybe a hacky way, but you can export the xpub/zpub to electrum and do it there with a bit of Python.
Another option would be to use the same public key with this website that seems to be able to generates a CSV of addresses: https://iancoleman.io/bip39/

My Wasabi xpub was not accepted on https://iancoleman.io/bip39/  and it only accepts root keys or mnemonic word conversion.

bummer. well, for sure electrum would let you do it (I've done it myself). worth a try. and the console is basically a python REPL so you can get it to spit out a CSV probably

I think this doc will be helpful. https://docs.wasabiwallet.io/FAQ/FAQ-UseWasabi.html#what-derivation-paths-does-wasabi-use

Wasabi follows BIP 84: Derivation scheme for P2WPKH Based Accounts, so
  the main path is m/84'/0'/0'. On TestNet and RegTest Wasabi uses
  m/84'/0'/0', and not the standard m/84'/1'/0'. Due to the CoinJoin
  implementation, the key depth can be rather large, thus when
  recovering the gap limit should be elevated to at least 100.

And here are all the BIPs Wasabi supports: https://docs.wasabiwallet.io/using-wasabi/BIPs.html


text:
Recovering wallet from MultibitHD backup file
I was able to create a Multibit HD hash in the form of $multibit$232characters32characters*32characters... If Hashcat has uncovered a password for a mbhd.wallet.aes file, what's next? One thing I'm confused about is why did Multibit HD create a wallet file with the .aes ending when it's not even a AESCrypt file or maybe that's just to throw people off??
Anyway, it doesn't really matter as long as I have the wallet password, I guess. So, what are the next steps to take to see if the wallet has private keys or not? It is only 27 Kb so I'm assuming it's a dump of the private keys, if any or it could be corrupted. I don't know the process moving forward. I think I read that Multibit HD wallets are not safe and should be converted to something else, like Electrum or something... is that true? In addition, I do not have the 12 seed/secret words so Multibit HD doesn't allow you to enter a remembered password... it wants the seed words to recover the wallet.  What do you recommend and what's the correct process?  Should I try to get the seed words somehow or should I try to import the keys into Electrum or something else?
Also, how does one go about getting public keys or addresses or both from private keys? Google searches are not helping so much as the Multibit HD wallet information is old and I'm not sure it's reliable. Any help and/or direction would be greatly appreciated.

If Hashcat has uncovered a password for a mbhd.wallet.aes file, what's next?

I would either

use MultibitHD to recover the wallet or

manually decrypt the file and manually extract all the private keys

The second method probably requires a lot more knowledge of the internals of a Multibit wallet.

One thing I'm confused about is why did Multibit HD create a wallet file with the .aes ending when it's not even a AESCrypt file

From what I've read, Multibit HD wallet backups are encrypted using the AES algorithm where the AES encryption key is the "wallet words" (not the wallet password).
You don't say what caused you to think the file with the .aes filename extension was not AES encrypted?

it doesn't really matter as long as I have the wallet password, I guess.

If what I've read is right, the "wallet password" is of no help in using a wallet backup.
However maybe what Hashcat recovered was the twelve "wallet words"? If so you would be able to use those to recover the wallet.

I read that Multibit HD wallets are not safe and should be converted to something else

Multibit became defunct in 2017. I vaguely recall there was a Multibit classic that became defunct long ago. If I remember correctly it was superceded by Multibit HD. Anyway the multibit.org URL now redirects to an unrelated project which makes me suspect it will be hard or impossible to find any official documentation or support.
This is of course a good reason to never depend on any specific software to hold your backup of your private keys. Its probably safest to have a BIP-compliant recovery phrase or private keys in WIF format. Either of these would still be usable even if your wallet developers disappear and the software becomes unusable.

I do not have the 12 seed/secret words

Then it seems to me that hashcat has been of no use to you.

how does one go about getting public keys or addresses or both from private keys?

The easiest method is probably to use established wallet software
The algorithms are public. There are many libraries or bitcoin toolsets. Its a fairly broad subject. If I wanted to do it outside of an actual wallet I'd maybe look at PyWallet, btcutils and some of the other popular toolsets.


text:
What is the fastest public SHA256^2 code for x86?
I am asking about the double SHA256 hashing function - the one that bitcoin uses.
Which publicly available implementation is the fastest one out there?
It can be in assembler, as long as it is for x86, also 64 bit.

I suspect, that since SHA256 has no real weaknesses, you can't do 2x SHA256 faster than twice the time of one SHA256...


text:
Why does blockchain.info show a different balance from bitcoin-qt?
I just created a wallet on blockchain.info by importing my wallet.dat from Bitcoin-QT. My Bitcoin-QT shows a balance of 3.991 BTC, while blockchain.info shows a balance of 3.016.
Where does the difference come from, and which one is 'correct'?

Either one of the factors may affect either balance:

There is a double spend against one of your accounts
Some transaction might not have yet been included in a block and one program does not see it yet
There can be an error in one of the programs that skipped over some transactions. In case of the client, you should try rescanning the blockchain to make sure all data is properly extracted in case you suspect an error

You should make sure your client is fully synchronised and all your transactions have at least one confirmation.
You should generally trust the place where you issue your transactions from to have an accurate balance of your outgoing transactions, and blockchain.info for the information available everywhere else.

Thanks. How do I 'rescan the blockchain' ?

@Sietse - https://en.bitcoin.it/wiki/Running_Bitcoin - use -rescan

As it turns out, the import did not pick up all my addresses/keys. By comparing the output from pywallet --dumpwallet and the blockchain.info exports I was able to identify the missing keys and add them manually. Both balances match now :-)


text:
MtGox Transaction IDs are internal or bitcoin issued?
Why did MtGox issue me a transaction ID (and charge a fee) for funds that have not "transacted" to the address I provided (but have been withdrawn from MtGox)?
Do they issue some kind of internal transaction ID which does not lead anywhere when I search it in blockchain?


text:
Bought BTC from Blockchain but Received Less Than Expected
Recently, I bought £350 worth of bitcoins back when they where £37 the other day. They've taken over a day to get through to me and when I have received them I only have 7.7 (compared to the 9.1 that I need). I appears they have charged me at today's prices instead of the ones that where the current price the other day. Even though when I purchased the coins it said I was buying £350@37 a coin.
Is it normal practice to do this?

When you say they took over a day, was that a day when they had your money? Or was that a day before the money got to them? How did you pay? By what method?

I gave them the money on "Day 1" at 3:00pm when the going rate was £37 a coin. I paid via PingIt so I think it should be almost instant. I recieved my bitcoins on "Day 3" at 5am when the going rate was about £42 a coin.
I hope this clears things up.

That sounds like a problem. You should talk to them.

Same problem here. Their mobile phone number goes to answerphone but I've sent an email following up my original support request.

Im glad to hear Im not the only one. I assume its due to the sudden surge in bitcoin purchases. Ill try calling them now.

Right, just called up and it looks like Barclays (The owners of pingit) where completely overwhelemed at the point and so where slow to process it. The person I talked to was very helpful and is going to send me the extra amount now.  I contacted him at this number: (+44) 7525 431876

Thanks Marche. The person I spoke to just now was also very helpful and we seem to have resolved the issue (related to trying two transactions at once). I must say I'm very impressed with their customer service. Edited to add: fixed, within 10 minutes.

@Marche101 Post that as an answer

Right, just called up and it looks like Barclays (The owners of PingIt) where completely overwhelemed at the point and so where slow to process it. The person I talked to was very helpful and is going to send me the extra amount now. I contacted him at this number: (+44) 7525 431876.
In hindsight, I think they where just incredibly busy with orders and so where slow putting it through.


text:
Where can I find well-written criticism about Bitcoin?
I couldn't find an article about criticism in the wiki. Is there some other place that contains well-constructed criticism for Bitcoin?

What kind of criticism do you mean? Some of the answers have criticism, which is not related to the economic impact if wide-spread Bitcoin adoption is achieved, which is what I suspect that you are asking, given your "economics" tag.

@David - I think the Weaknesses page is the page I'm looking for. It should incorporate all weaknesses, not just technical - edit it if you feel it's missing something.

Here's the page on the wiki where weaknesses are addressed.

That's more technical weaknesses, it says nothing about the economic problems of a deflationary currency.

@r3m0t - I think the Weaknesses page is the page I'm looking for. It should incorporate all weaknesses, not just technical - edit it if you feel it's missing something.

This Quora question is a start.

This is a great source:
http://critiquesoflibertarianism.blogspot.co.il/2011/05/simple-critique-of-bitcoin.html
It is a short article but you can learn a lot from the comments

See "Decentralised Currencies Are Probably Impossible (But Let’s At Least Make Them Efficient)" by Ben Laurie. He shows how Bitcoin's so-called "decentralization" is such a joke, because it doesn't really work. If Bitcoin's decentralization doesn't work, it makes no sense to waste so many resources over proof-of-work transaction processing. He also proposes an alternative design in a follow-up post.


text:
Running a store through Tor - what are the setup options available?
I am required to setup a store that will operate through Tor and accept Bitcoin payments only. I know I can run the standard client on the server and make it connect to peers only through Tor. However, are there any other options available for handling Bitcoin side of things - hosting the wallet, creating accounts, receiving money and so forth? Do any eWallets or other services allow access through Tor?

I'm curious what's great about a tor-based e-commerce site. If there's shipping, you'll need the buyer's address. If there's digital download, you'll need to give them a link, and it won't matter if they are or aren't TOR. Saving the user's session via cookie / session vars to continue to use their system makes sense.

The benefit is that it's a lot more difficult for a government to shut down a Tor hidden service than an open web site. See: Silk Road

If you're doing what Silk Road do you would want to run your own Bitcoin-Qt and not use some third-party online service.

Try using bitwasp. It seems to provide a lot of features you need. Try it and let us know if it works.
https://github.com/Bit-Wasp/BitWasp
https://bitcointalk.org/index.php?topic=109223.0

Very cool! Looks like a codeigniter instance. W

Bit-Wasp abandonware or close been hacked to many time to count sadly.

Yea please don't use Bitwasp the marketplace :)  it's a project that I could never keep up with maintaining and really isn't secure or high quality code.

BTCPay Server "is a self-hosted, open-source cryptocurrency payment processor. It's secure, private, censorship-resistant and free."
There are still some outstanding issues around Tor though.


text:
Bitcoin-qt transaction not initiated by the wallet owner
I was just mining for some Dogecoins with Eobot and parallel I had BGFminer set on solo mining + 4 pools from eclipse.
The issue is that the moment the Eobot kicked in (it started on mining Dogecoins as they just started on increasing) I saw a notice of Bitcoin transaction, asap I opened the client to see it i found the following:

The best part is that I did not post my sending address anywhere nor iniciated this transaction (And seems I have this wallet since a week and this is the entire  amount that was stored there) so is it possible that i got some Trojan on my PC that somehow managed to process this transaction or similar.
Any suggestions?

Your hypothesis of a Trojan seems likely, unfortunately. Just be glad you didn't have more coins in that wallet.
You'll probably want to wipe and reinstall the computer in question.

Well , that's what i expected ...


text:
I have/had 31 bitcoins on MtGox; What are my options now?
After reading the joint-statement on blockchain, and the fact MtGox is down now, I am scared, what are my options? Is there anyone who can help me in my situation? I purchased those coins for 800$.
Edit:
MtGox files for bankruptcy protection. What is the difference between bankruptcy and bankruptcy protection? I don't know, but I don't think that I am going to see anything from there...

I'm really sorry to hear that.  Unfortunately no one really knows what's going on at Mt. Gox right now, and nothing they're doing is in any way reassuring. We'll just have to wait and see how this all plays out.

Also keep your coins to yourself, whenever possible. Never let them be sitting around somewhere. I dodged a bullet here...

The exchanges should show you your private key so you could always transfer the money from a different client.

@ja72, I don't think any exchange actually do that. It is impossible to maintain a hot wallet this way.

I guess I need to look up "hot wallet."

@ja72: That would cause its own problems. Suppose you've just sold some coins, but then the price went up so you wish you could undo the trade. If you hold the private key, you could try a double spend, and if you're successful the trade has to be unwound. This would mean that the buyer couldn't safely spend or resell those coins until 6 confirmations or so - it would drastically slow down the market.

Seems not all hope is lost. According to this press report http://www.theguardian.com/technology/2014/feb/28/bitcoin-mtgox-bankruptcy-japan , MtGox could theoretically reimburse 59.47% of its clients money should they be able to get 100% value off their still existing assets. Unlikely, of course, but getting back 0.4 or 0.5 from every 1 BTC depositted could be a God-sent gift to many people.

@joe see my comment in the edit

I guess your last question can only be answered by someone versed in Japanese law...

This is generally called counterparty risk - if your resources are in custody of someone else, there is a risk that they go bankrupt and you lose it. And in that case it is too late and your options are limited to making a sadface :( and writing it off as a loss - do note that you can get x% of the loss back from your income tax in most places.
There are options to limit that risk before it materializes - it might be too late for MtGox, but important for the future. All the lessons are pretty the same as historically for 'normal' banks before modern regulation.

Diversify the risk - if your funds are spread out among multiple institutions, then there is less chance in losing it all than putting it all in one basket;
Insure the risk - your bank deposits are insured in most countries, i.e., if the bank can't return them then the insurer pays up to a certain amount. Bitcoin companies currently aren't insured that way, however it means that when some of them get deposit insurance then that would be a serious selling point for their trustworthiness; and if (when?) regulated banks start offering bitcoin services, then you'd get that protection as well. Also, you can purchase insurance for yourself, although it might be unpleasantly expensive.
Reduce the risk - choose the company properly. Reputation certainly didn't help in MtGox case and it's not a guarantee, however, you should be looking at solid evidence that the company is solvent. I.e., you want periodic, publicly visible financial statements that are seen and analyzed by many people and that show that they really can afford to pay all the depositors back even if they have a bad day or a bad year. At the very minimum you need this to be (a) according to common accounting standards; (b) expressed by a company officer in a manner that means jail for him if (s)he lies in these statements; (c) audited by a third party - otherwise these statements are worthless, as if there will be real problems, then they will lie always. Regulators of financial institutions do much of that job for banks; not eliminating those problems but reducing them - for unregulated entities you'll have to check everything yourself.

What exactly happens to the bitcoins that Mt. Gox does have, though? Just because they have more liabilities than assets doesn't mean no one should get back anything they lost, does it?

During bankruptcy, the assets would be liquidated and then distributed proportionally to everyone that MtGox owes. However, I haven't seen solid financial reports of MtGox (that itself being a poor sign), but the leaked documents seemed to indicate that their assets are just a tiny fraction of what they owe (i.e., they lost $500m worth of bitcoin but have ~$40m of assets). In practice that means that within due time (1-2 years?) depositors might receive a payout of some 5% of their funds or something like that.

You are not going to like this:
Man-up and accept that you took a chance using MtGox and lost. The same applies to stocks, commodities, gold, etc. You decided to keep substantial funds in an unregulated exchange in an unregulated "currency".
What was lost was the amount in fiat currency represented by the BTC at the time you deposited them, not todays, yesterdays or any other chosen dates rate. Just like buying stock--except stock exchanges are regulated.
P.S. My holdings are down too, but not via holdings at MtGox.

Consider: I bought 1 Bitcoin at $400. it goes up to $600. I lose the Bitcoin. How much have I lost, $400 or $600? Next: I bought 1 Bitcoin at $400. it goes down to $200. I lose the Bitcoin. How much have I lost, $400 or $200?

I am sorry about anyone's loss. BTC and other coins are speculative; one may win big (10x, 100x) or loose all (1x). As are gold, gems, property, etc. Regulation helps to stabilize losses but also tends to limit gains. One needs to decide the level of risk one is willing to take. Personally I have invested in mining, the only way I will make any real money is if BTC succeeds in a rather big way. I figure it will take years to determine the outcome. My wife and I have discussed how much we are willing to risk while admitting we may well lose our entire investment.

One the positive side one can only lose all of their investment. There are many ways to lose much more than your investment, been there, got the t-shirt. But, if you don't play you can't win.

@Gracchus You do realize that Ripple is completely based on counterparty risk?

@Gracchus I was referring to IOUs. Your IOUs become worthless when their issuer is bankrupt/just never uses Ripple anymore. It seems inconsistent to be disgruntled at Bitcoin for people losing money to a localized instance of counterparty risk, and then advocating a system completely built around counterparty risk.

Could you phrase your advice in a less sexist way?

@Zaph, while the IRS hasn't yet stated its intended way of accounting for casualty loss of Bitcoin, I speculate that it's safe to assume that it would be regulated as a commodity or security. Thus, you can only lose what your initial investment was. You had not realized the gain. So, in either case, your loss is $400.

@Colin I agree. My intent was to bring home that the the loss (in my hypothetical example) was $400.

@Colin I do take exception to your edit of my post, in particular the deletion of "Man-up". I do not view it as sexist in the same manner as the English language allows the word "he" to be used when both sexes (male and female) are being addressed. The phrase "Person-up" just does not work nor does ""Man/Woman-up". The intent was to imply "Take responsibility", that is now lost. Please change it back! As an aside, you might want to explain how this is sexist. If you don't like my use of "Man-up" feel free to down-vote my answer. Nate, I suspect that the last sentence applies to you as well

@Nate, Colin "Man-up" meaning grow up, accept responsibility, don't be a baby. If you want sexist, just look at advertisements including my local newspaper on-line version, horrible.

Your meaning is clear, but I stand by my objection to your word choice.

@Nate I have no problem with that, no problem with your comment, no problem with your down-voting (not saying you did). My post was about taking responsibility yet Colin did not mention his change to my post, the change nor why. I do have a problem with Colin changing the meaning of my post.  There was a down-vote yet that person did not take responsibility, provide a reason. I support their right to do so, just find it in juxtaposition to accepting responsibility. Oops, I referred to Colin with a masculine gender (common English) yet Colin might be a woman.

I have a question: Do you ever use the word Policeman or Fireman? My Wife was a police officer and I have a friend who was a firewoman (somehow that seems awkward yet PC).

If you insist on your wording you can certainly edit to change it back.  I don't think it will be productive for us to discuss it further here.

Actually, from an ethymological POV "man-up" is not sexist at all. "Man" is Germanic for "generic human being" just like "homus", "anthropos", "manu" are unisex in Latin, Greek and Sanskrit respectively. All these languages had specific words for male humans: "were", "vir", "andros", "virah" respectively. The fact that over time Indo-European languages have largely dropped the male-specific word and put the unisex to do double work (meaning both unisex and male-specific) is a sad turn-up of history. "Woman-up" or "were-up" would be indeed sexist :)

@Gracchus Ripple's good for a lot of reasons, but it's not the panacea, either. It takes this modern-economies' concept of "banks creating money ex-nihilo by emission of debt" to the extreme! Remember: what is transmitted thru the Ripple-network is not money, but debt. We're all sending each other IOUs and then settle them altogether. So the network as a whole has same risks as a bank, for the same reasons: should a significant % of users go bankrupt, default or do plain fraud, rest of users will take a heavy blow to their finances.

@Zaph I completely agree with you: thank God with BTC you may win big or lose at most your initial investment - with other speculative investments you can lose much more than that. As to losing $400: due to inflation the amount is actually higher, though for accounting purposes I guess that's the most you can claim as a lose.

@Gracchus Kinda. You may read http://bitcoin.stackexchange.com/questions/10242/ as well as questions 11963, 7621 and 7714.

I received this email:

To whom it may concern,
At 5:00 p.m. on April 24, 2014, the Tokyo
District Court granted the order for the commencement of the
bankruptcy proceedings vis-à-vis MtGox Co., Ltd. (“MtGox”), and based
upon such order, I was appointed as the bankruptcy trustee (Tokyo
District Court 2014 (fu) no. 3830). The bankruptcy trustee will
implement the bankruptcy proceedings, including the administration and
realization of the assets and investigation of the claims. For the
purpose of providing information to the related parties, we hereby
inform you of the basic matters regarding the bankruptcy proceedings
as attached.
This email address（mtgox_trustee@noandt.com） is used
only for the purpose of sending messages, and we are unable to check
and respond to any replies to this email address. Since we plan to
provide the information regarding the bankruptcy proceedings by
posting it on the website hosted by the bankruptcy trustee (
http://www.mtgox.com/ ), please check this website.
Bankrupt MtGox Co., Ltd. Bankruptcy trustee Attorney-at-law Nobuaki Kobayashi

One of the links on the mtgox site had a Q&A section
Q. Please return the bitcoins and cash that I deposited with the Company.
A. We will make the liquidating distribution to the bankruptcy claims if funds for distribution are secured. With regard to the liquidating distribution under the bankruptcy proceedings, please see below.
Q. How many bitcoins or how much cash does the Company have?
A. The actual amount and value of bitcoins and cash of the Company will be investigated by
the bankruptcy trustee with the cooperation of certain experts, etc.
Q. Will the bankruptcy trustee investigate the bitcoins and cash that are said to be lost?
A. The bankruptcy trustee will investigate such matters to the extent possible through its
asset administration. The Company has consulted with the police authority, and the
bankruptcy trustee will also proactively cooperate with it when such cooperation is
requested.

Yep, I got it too.

Contact a Lawyer and sue them.

Suing an entity that has no money is just like flushing it down the toilet. Suing out of you own jurisdiction is much worse. Extrapolate that to suing in a Pacific Rim Nation

@zaph: Well, as they are filing for bankruptcy, as a creditor you can make a claim for a share of whatever assets they do have. It may be hard to know at this point how significant those assets are.

~$25k USD in Bitcoin is not an insignificant amount. However, it's likely to be a protracted battle and unlikely to be settled in BTC.

I can see a "Former Mt.Gox clients bring class-action suit" line in the newspapers, very soon... anyway, it's your legal right to fight to get back at least one cent off every Bitcoin you had there. Even recovering 1mBTC would be better than losing it all...

Ha! Happened earlier than I thought
http://arstechnica.com/tech-policy/2014/02/illinois-man-files-class-action-lawsuit-against-bitcoin-exchange-mtgox
Since aprox. 30% of MtGox users were from Europe rather than USA, let's see how long 'till a similar class-action arises in a Schengen-area country...

I think this question deserves a simple and direct answer.

What are my options?

None, essentially.

Forget about your 31 bitcoins - they are now in the hands of a thief and are untraceable.
Wait several months, perhaps years and see whether some fractional return results if

MtGox is resurrected in another form and makes some effort to repay creditors from future earnings.
Japanese investigators can salvage anything

Is there anyone who can help me in my situation?

No. No-one can help you to retrieve your 31 bitcoins.

2013-02-28 Yahoo News report

"We're at a loss for how to help them," said Yuko Otsuki, who works in the [Consumer Affairs] agency's counseling department.

Not meaning to diminish the Japanese police and their investigators, I don't think they'll be able to accomplish much. Frankly, save a handful of very specialized units in certain countries (USA? Israel?? Britain???) I doubt any police force in the world would be able to understand the robbery, much less track the robbed coins, retrieve them and jail the perpetrators :(

Kraken just sent an update for MtGox funds claim. Log in here - https://claims.mtgox.com/assets/index.html#/ .
Thou I have to admit I have problems logging in.

Yeah I so it, going to try latter. Will keep you posted

There are people buying and selling 'MTGox BTC' for 'Real BTC' here
https://bitcoinbuilder.com/
essentially a gamble on whetehr they payout on the accounts there.  But they now it seems have stopped trading since the official insolvency declaration. However as a once (a long time ago) customer of MtGox I did see in my inbox a form entitling me to apply to get any funds I may have held in MtGox back as part of the liquidation process.  I would suggest you look to that as your first avenue. Failing that as is the case in many liquidations you may never see your BTC back.

Can't, I need to transfer my funds to his bitcoin account, but bitcoin trade is down.

I feel very fortunate in learning before I invested in BTC the difference between public and private keys.  Also knowing how to use Localbitcoins (as an example) as an exchange and being advised once I received my bitcoins at LBC not to leave them there for any time.....because you never know what will happen to any exchange. I was advised to transfer the BTC in LBC to a wallet such as Electrum which uses a random seed to generate private keys. Storing your BTC in such a way gives you far more security than leaving them deposited on an exchange.

Theoretically, a well-run company would/could have best-of-breed people devising ways to improve security and building layer upon layer of redundancy, honeypots, offline storage, etc. none of which you can unless you happen to be a security expert. Most people's wallets aren't attacked because of their being very small targets rather than the high-security of a typical PC. MtGox blunted it, period.


text:
How to determine valid vanity address prefixes for any starting net byte?
Question inspired by this.
There are some combinations letters that will never produce a valid vanity address prefix for various network bytes. For example, for net byte of 52 (Namecoin), one cannot create addresses starting with
Na, Nb, Nc, Nd, Ne, Nf, Ng, Nh, Ni, Nj, Nk, Nm, Nn, No, Np, Nq, Nr, Ns, Nt, Nu, Nv, Nw, Nx, Ny, Nz, NL, NM, NN, NP, NQ, NR, NS, NT, NU, NV, NW, NX, NY, NZ
Given websites like Vanity Pool that outsource vanity address creation, creating a blacklist of address prefixes for every net byte would be a complicated task. How can one determine a valid range of address prefixes that can be created with any given net byte?

Casascius' Bitcoin Address Utility includes a Base58 calculator. You can input into it the lowest and highest values to encode to obtain the lowest and highest strings.
For example, to get the lowest Namecoin address, start with the hex representation of its network byte 52, which is 34, and add 40 zeroes (representing the 160 bits of the public key hash in hex). The result is MvaNCeVyvP6ZXYFWGpKaDX9ujEQ418F7sm. Likewise, to get the highest string use 34 followed by 40 f's, giving NKuyBkoGdZZSLyPbJEetheRhMjezbtjJCf.
Only 34-character strings which are between these two, in lexicographic ordering, can be valid Namecoin addresses. The ordering of the characters is compatible with ASCII, 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz, and thus most programming environments should be able to check the address with the built-in string comparison functions.
Specifically, the first 2 characters can only be one of the combinations between Mv and NK, which are Mv, Mw, Mx, My, Mz, N1, N2, N3, N4, N5, N6, N7, N8, N9, NA, NB, NC, ND, NE, NF, NG, NH, NJ and NK.
A more general approach is to decode the address into a number, and verify that the result is composed of the required version byte followed by any n bits (where n is the bit length of the encoded data, 160 in the case of a receiving address).

I realized this answer doesn't properly address the effect of the checksum; this has negligible chance to cause errors in practice (for vanitygen prefix purposes) but I'll fix this when I have the time.


text:
How to get crypto currency wallet balances
I am trying to build an app that will pull in all my wallet balances. I can easily do this with exchange apis, but how do I get balances that are stored in wallet?
Do I need to set up bitcoind, litecoind, neo equivalent, and all of the rest? That sounds like a lot of work and A LOT of server space / resources?
I'm surprised I haven't been able to find a single unified api provider, where I can just send a BTC address, or a LTC address or a NEO address and it returns me a balance. Does such a thing not exist?
Thanks :)

Questions seeking product or service reviews are off-topic because they tend to attract subjective, low-quality, and spam answers.

Do I need to set up bitcoind, litecoind, neo equivalent, and all of the rest?

You don't have to; you can use different APIs for different coins. But not all coins will have a service that offers that, so for those you will need to run your own node software.

I'm surprised I haven't been able to find a single unified api provider

You've answered this yourself:

That sounds like a lot of work and A LOT of server space / resources?

It's simply too expensive for someone to do that.

You cant get balance of a address, a address is not a account or wallet and accounts dont exist in bitcoin anymore all address's are unchangeable linked to account " " you could get the balance of your wallet in its entirety but not "address's". A address is simply a entry point into your wallet, the best you can do is get "getreceivedbyaddress" but this would not show you the balance only a starting point.


text:
16: mandatory-script-verify-flag-failed (Script evaluated without error but finished with a false/empty top stack element), code=-26)
This is the raw transaction.
01000000013a1b3a9209583a8fd345fdf73c80bb22fdf8a0bf1e4fc48252151f6d18b2822901000000020151ffffffff0160a59e7d5100000017a9143dbbda49ccc09591516be148dd966610f254e4bc8700000000

Welcome to SE.Bitcoin. I don't understand what you're asking, there's not even a question mark. Please improve your answer and provide more context.

Your raw transaction is just completely wrong. Just pushing OP_TRUE to the stack does not make any output spendable; you still need to execute the output script. The combined script (input script and output script together) results in a failure/OP_FALSE so the input is invalid. Thus the transaction is invalid.
Looking at the output you are trying to spend from, it looks like it is a 3 of 5 multisig, so unless you have 3 of the 5 keys, you can't spend from that output.


text:
Why is my wallet in Maintenance mode?
My OMG wallet on Yobit.net is in maintenance. I get this message when I try to withdraw or lodge to the wallet. Why is this so?

this happens sometimes on many exchanges. i have seen this also on poloniex and bittrex for other cryptocurrensies. this is usually a normal procedure. in a few days you should be able to deposit/withdraw your funds again.

Bittrex provides a prompt that advises that the wallet is in maintenance; the same happens on Binance but not so on Yobit.net; at least not in this instance with me. It would certainly reduce anxiety if Yobit would do likewise.


text:
Unable to broadcast raw transaction
I am a real beginner and am having trouble with signing this P2sh code:
020000000190001f2feb1d5f282f7e15f75259db6200bbdde6498442c7ae571ce4e9f595bd010000006a47304402205f49f55952d189148d570f23e6eb623b65631bdbf88a894c4f314d51a518c65602201bd88c35ebbe52b5dd00c482f4f47211436fe40447c230ebb22ee07f3437a5af0121031a4aa9b7fb5f97d7a6443d72e5420cebd50b2b6986abf3fd5be54e597ee334ddfeffffff026edae88c3c0000001976a9140115aef14ab7459df7e8892bcbfaf4d03501e9fa88ac6bf50904000000001976a914c1d3b9ab95f4a100f8b0e8daa11c01bbe4179ecb88ac1b211300
{
  "txid": "ae3ebf9b4216b2669fca8dc9091903b242cccb345f44883633ba7d7377347995",
  "hash": "ae3ebf9b4216b2669fca8dc9091903b242cccb345f44883633ba7d7377347995",
  "version": 2,
  "size": 225,
  "vsize": 225,
  "locktime": 1253659,
  "vin": [
    {
      "txid": "bd95f5e9e41c57aec7428449e6ddbb0062db5952f7157e2f285f1deb2f1f0090",
      "vout": 1,
      "scriptSig": {
        "asm": "304402205f49f55952d189148d570f23e6eb623b65631bdbf88a894c4f314d51a518c65602201bd88c35ebbe52b5dd00c482f4f47211436fe40447c230ebb22ee07f3437a5af[ALL] 031a4aa9b7fb5f97d7a6443d72e5420cebd50b2b6986abf3fd5be54e597ee334dd",
        "hex": "47304402205f49f55952d189148d570f23e6eb623b65631bdbf88a894c4f314d51a518c65602201bd88c35ebbe52b5dd00c482f4f47211436fe40447c230ebb22ee07f3437a5af0121031a4aa9b7fb5f97d7a6443d72e5420cebd50b2b6986abf3fd5be54e597ee334dd"
      },
      "sequence": 4294967294
    }
  ],
  "vout": [
    {
      "value": 2600.62108270,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 0115aef14ab7459df7e8892bcbfaf4d03501e9fa OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a9140115aef14ab7459df7e8892bcbfaf4d03501e9fa88ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "16jenAh8U7g3epf7YU1Mmmxf1uieymWp7"
        ]
      }
    },
    {
      "value": 0.67761515,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 c1d3b9ab95f4a100f8b0e8daa11c01bbe4179ecb OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914c1d3b9ab95f4a100f8b0e8daa11c01bbe4179ecb88ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "1Jfs3xHhPBeRThAo9kcsXiGnAVwHpa1tiA"
        ]
      }
    }
  ]
}

I can get it to 'true' with creatrawtransaction and signrawtransaction - but it is still lacking inputs when I try to sendrawtransaction to the network.
Any advice? The problem seems to be in the Witness script and I am clueless as to how to resolve it.

This transaction has nothing to do with witnesses. There is no witness script here.

You appear to be using the main Bitcoin network but the transaction you are spending from does not exist on mainnet. It only exists on the test network. You need to restart your node in testnet mode in order for it to work.

Thanks. The mystery is that the data in this transaction turned up in both my testnet and mainnet accounts. I don't  know how it got scrambled/crossed over but it effectively formatted  the addresses properly on each side. Very weird.


text:
Curl bitcoin protocol for learning?
I'm trying to understand bitcoin RPC Peer to Peer protocol to implement SPV on a web-application that should receive crypto payments.
The problem is that on the examples I found, examples are about RPC requests to a full node I'm supposed to own, but I want to query other nodes (nodes I have no user:password for).
As far as I understand, bitcoinj and full wallets connects to the network make requests to them without user:pass, but I could not found how that requests are built, and how can I test and try them using curl to learn how it works.
Is there a api documentation I can check and a list of nodes I can query?
Also, I understand that to establish a connection I should send the version request, but from curl I don't have a "version".
I've found this documentation about the protocol, but I've found no way to test that out in simple terms (like curl), to know what is being sent-received.
I want to understand what queries I can make using this protocol without running a full node.
update
It seems that what I wanted to know if it is possible to learn about the bitcoin protocol making test calls with curl to full-nodes (not RPC). It seems that it is not possible.

Nodes communicate to each other using the peer-to-peer protocol, typically using TCP port 8333. They rumor blocks and transactions to each other, request data, tell each other about other IP addresses in the network, ...
Each node implements the level of validation they desire; some download all blocks and validate everything (full nodes), some do that but don't keep the blocks on disk after validation (pruned full nodes), and some download only the transactions they're interested in along with proofs they wee including in the chain without verifying validity.
Independently, some node software also exposes an interface to communicate with users or other software using an RPC protocol. This interface however is not public for good reasons:

It's usually not designed to work in adverserial settings (for example: the RPC interface may expose a command to shut down a node, or dump its private keys, ...).
It's not hardened against denial-of-service (DoS) attacks.
It's not others than the node's operator should be using anyway, as the information provided by RPC is an interpretation of what is going on in the network; it's not verifiable. So if exposed to untrusted party, node software could just lie, possibly defrauding the party using it.

Ok, but can I try the peer-to-peer protocol, what can I do with that, and what cannot be done? (I will change the question to make that idea clear)

Obviously everything can be done with the P2P protocol (it's literally how all nodes get all their information).


text:
Running multiple bitcoin instances on same server system
I wish to run multiple instances of bitcoind on my server to support highly read intensive RPC applications.
Following links:
how to run multiple bitcoind node on one server?
Running Multiple Full Nodes on one Host
Is it possible to run more than one client instance on a machine?
How do I run two instances of bitcoind on the same linux machine with different conf files?
suggests that by using different conf file and data dir we can run multiple instances.
However, my doubt is that since in each case, we are specifying different config file and data dir to same binary bitcoind, e.g.
bitcoind -datadir=./bitcoinNode1/ -conf=./bitcoinNode1/bitcoin.conf
bitcoind -datadir=./bitcoinNode2/ -conf=./bitcoinNode2/bitcoin.conf
bitcoind -datadir=./bitcoinNode3/ -conf=./bitcoinNode3/bitcoin.conf

Does same single binary bitcoind is going to handle request for all instances (bitcoinNode1, bitcoinNode2, bitcoinNode3)? In such case load will be on single binary and I have a doubt for performance gain.
Or is it better to create different binaries bitcoind1, bitcoind2 etc. for each config+data_dir combo?
Thanks.

The provided approach is correct.
A binary itself does not handle any requests. When you run bitcoind with separate instances of the config and data directories, the system will create multiple instances of the bitcoind program to execute. Each of these instances is a fully independent bitcoin node, and has no relation to any other instance running on that machine.
Copying the binary will make no difference.

Thank you for your answer and clarification.

Just to add to what @RaghavSood said.  You also need to make sure that you have set a unique port in each of the configurations you are providing to the Bitcoin daemons, for their respective communication channel, otherwise the second and third demons will fail with a 'port already in use'.