text:
I've gotten an error that says "000 curl: (7) Failed to connect to 127.0.0.1 port 18332: Connection refused"
Macintosh HD>Users>nishidaryu>Library>Application Support>Bitcoin>bitcoin.conf
          rpcuser=ryunishida
          rpcpassword=password

          HOST=localhost
          server=1
          txindex=1
          rpcport=18332
          testnet=3

Then I enter the code below
 curl --user ryunishida:password --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getinfo", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:18332/ -w '%{http_code}\n'

The i got the error.
curl: (7) Failed to connect to 127.0.0.1 port 18332: Connection refused

 est=0000000000000000131fad7d9f3e327b229f8307513db4a8b1fa6ee451ab889b

height=354966 version=0x00000002 log2_work=82.72942 tx=67647897 date='2015-05-04 21:21:14' progress=0.272143 cache=603.4MiB(4479558txo)
 2017-08-21 22:57:46 Pre-allocating up to position 0xa00000 in rev00264.dat
2017-08-21 22:57:46 UpdateTip: new
 best=00000000000000001615f90d49ca0e1cb869fcd8427f495fa4f0d978e5db473f height=354967 version=0x00000002 log2_work=82.729456 tx=67649081 date='2015-05-04 21:27:45' progress=0.272148 cache=603.3MiB(4478757txo)
2017-08-21 22:57:46 UpdateTip: new best=000000000000000012f058764064d0153bd74289b17fb6b27350881d8da13cb7
 height=354968 version=0x00000002 log2_work=82.729493 tx=67651444 date='2015-05-04 22:09:58' progress=0.272158 cache=603.6MiB(4480444txo)
2017-08-21 22:57:47 UpdateTip: new best=0000000000000000006d2018e9b9b09bf922b373f81dc58cc4003e4e9a8a432f height=354969 version=0x00000003 log2_work=82.72953 tx=67652384 date='2015-
 05-04 22:22:02' progress=0.272161 cache=603.5MiB(4479690txo)
2017-08-21 22:57:47 UpdateTip: new best=0000000000000000033478f661ac741a6dd1ffea71d0eab468ab9aa42f173dff height=354970 version=0x00000002 log2_work=82.729567 tx=67653681 date='2015-05-04 22:26:12' progress=0.272167 cache=603.5MiB(4480056txo)
2017-08-21 22:57:47 UpdateTip: new best=00000000000000000f2be95aadbccc1ac9d7d48707087afdb62824f5d1b12eb6 height=354971 version=0x00000002 log2_work=82.729604 tx=67654797 date='2015-05-04 22:30:04' progress=0.272171 cache=603.6MiB(4480873txo)
2017-08-21 22:57:47 UpdateTip: new best=00000000000000000ead2a41cbe7181eebabcfa5b2fe6cef7a4aeb6b55dba0cb height=354972 version=0x00000002 log2_work=82.729641 tx=67657563 date='2015-05-04 23:10:54' progress=0.272182 cache=603.7MiB(4482027txo)
2017-08-21 22:57:47 UpdateTip: new best=00000000000000000baff238a3586819dbe4dbc1867a1a39f30e930cd9df2bf4 height=354973 version=0x00000002 log2_work=82.729677 tx=67658315 date='2015-05-04 23:15:51' progress=0.272185 cache=603.7MiB(4481277txo)
2017-08-21 22:57:47 UpdateTip: new best=00000000000000000f127e1a0ff0569d6d12443abdfd462c8c26df2ae4d15944 height=354974 version=0x00000003 log2_work=82.729714 tx=67658985 date='2015-05-04 23:23:16' progress=0.272188 cache=603.6MiB(4481195txo)
2017-08-21 22:57:47 UpdateTip: new best=00000000000000000157ad89daea0378f166da78b2a318020ce91c3fceceafca height=354975 version=0x00000002 log2_work=82.729751 tx=67659273 date='2015-05-04 23:26:55' progress=0.272189 cache=603.7MiB(4481258txo)
2017-08-21 22:57:47 UpdateTip: new best=00000000000000000e7f7961db3f1c66f51bc4e02f38bfd38674f2b7553314b3 height=354976 version=0x00000002 log2_work=82.729788 tx=67659400 date='2015-05-04 23:27:18' progress=0.272190 cache=603.6MiB(4481156txo)
2017-08-21 22:57:47 UpdateTip: new best=000000000000000007e3a0824a86b9bfb41eff5a2922023d4412b78d53f7ded9 height=354977 version=0x00000002 log2_work=82.729825 tx=67659627 date='2015-05-04 23:30:26' progress=0.272191 cache=603.6MiB(4481105txo)
2017-08-21 22:57:47 UpdateTip: new best=000000000000000005a51002cb8e60c3d4be68442c53961542d99f8152588b28 height=354978 version=0x00000003 log2_work=82.729861 tx=67660082 date='2015-05-04 23:40:13' progress=0.272192 cache=603.6MiB(4481029txo)
2017-08-21 22:57:47 UpdateTip: new best=00000000000000001388f868a4c3064b590539b9b3a04bca84bf8b2b74ba0889 height=354979 version=0x00000003 log2_work=82.729898 tx=67661498 date='2015-05-04 23:53:07' progress=0.272198 cache=603.6MiB(4481026txo)
2017-08-21 22:57:47 Pre-allocating up to position 0xb00000 in rev00264.dat
2017-08-21 22:57:47 UpdateTip: new best=0000000000000000087eddfd1f31bf696779531ad0428f48ccc6b34bd5d9e4f3 height=354980 version=0x00000002 log2_work=82.729935 tx=67662569 date='2015-05-05 00:09:16' progress=0.272202 cache=603.7MiB(4481770txo)
2017-08-21 22:57:47 UpdateTip: new best=0000000000000000108c19386547eec79a9aa91f2e6cb581b3aa098c927a7032 height=354981 version=0x00000003 log2_work=82.729972 tx=67663090 date='2015-05-05 00:16:51' progress=0.272204 cache=603.7MiB(4482020txo)
2017-08-21 22:57:47 UpdateTip: new best=00000000000000000f490b20c3e59af00e61444bb15bc13cbbf18052fda98cf8 height=354982 version=0x00000002 log2_work=82.730009 tx=67663368 date='2015-05-05 00:21:12' progress=0.272206 cache=603.8MiB(4482085txo)
2017-08-21 22:57:47 UpdateTip: new best=00000000000000000ac4d6497c11ecd4edd1274b0bcf181658a8d19b73ab3cf3 height=354983 version=0x00000002 log2_work=82.730046 tx=67663847 date='2015-05-05 00:28:01' progress=0.272208 cache=603.8MiB(4482192txo)
2017-08-21 22:57:47 UpdateTip: new best=00000000000000000728bbf03cc4feb5bdcff5bf8cf74b54e5e2df1d8160f5f6 height=354984 version=0x00000003 log2_work=82.730082 tx=67664089 date='2015-05-05 00:31:14' progress=0.272208 cache=603.8MiB(4482253txo)
2017-08-21 22:57:47 UpdateTip: new best=00000000000000000646e2241de38777d1afd577b50de57e5f8fa728833b6474 height=354985 version=0x00000002 log2_work=82.730119 tx=67664090 date='2015-05-05 00:32:02' progress=0.272208 cache=603.8MiB(4482254txo)
2017-08-21 22:57:47 UpdateTip: new best=000000000000000005e5a5cb8804c7671aa9423464bc398b5cf20b49078f2773 height=354986 version=0x00000002 log2_work=82.730156 tx=67664990 date='2015-05-05 00:44:55' progress=0.272212 cache=604.3MiB(4486601txo)
2017-08-21 22:57:47 UpdateTip: new best=00000000000000000a92cf169d8667a6a27cb813dc0fc55335139d6c86545390 height=354987 version=0x00000003 log2_work=82.730193 tx=67665061 date='2015-05-05 00:45:33' progress=0.272212 cache=604.3MiB(4486804txo)
2017-08-21 22:57:47 UpdateTip: new best=0000000000000000086260a5d4a3b256093f832f85b3317e35aa901437ddfaaf height=354988 version=0x00000002 log2_work=82.73023 tx=67665376 date='2015-05-05 00:50:20' progress=0.272214 cache=604.3MiB(4486959txo)
2017-08-21 22:57:47 UpdateTip: new best=0000000000000000170069f72eb85516ff457fdc342cc127356dd79a9ece0f4c height=354989 version=0x00000003 log2_work=82.730266 tx=67665615 date='2015-05-05 00:53:27' progress=0.272215 cache=604.4MiB(4487414txo)
2017-08-21 22:57:47 UpdateTip: new best=000000000000000007398380f9b977dca33789388f01bbb12fcae1e5432e3b9e height=354990 version=0x00000003 log2_work=82.730303 tx=67665882 date='2015-05-05 00:57:00' progress=0.272216 cache=604.5MiB(4487853txo)
2017-08-21 22:57:47 UpdateTip: new best=000000000000000000cd5669c7f4a84118de23cd06913a3248823eba1228d524 height=354991 version=0x00000003 log2_work=82.73034 tx=67666538 date='2015-05-05 01:05:51' progress=0.272218 cache=604.6MiB(4488883txo)
2017-08-21 22:57:48 UpdateTip: new best=000000000000000013b376160cc763defe8e106e279681290785cd59423dc6c2 height=354992 version=0x00000002 log2_work=82.730377 tx=67666850 date='2015-05-05 01:09:44' progress=0.272220 cache=604.6MiB(4488646txo)
2017-08-21 22:57:48 UpdateTip: new best=00000000000000001320c8181b11d3f02d6c8701a5170713dbdfa260011830be height=354993 version=0x00000002 log2_work=82.730414 tx=67667874 date='2015-05-05 01:40:38' progress=0.272224 cache=604.7MiB(4489567txo)
2017-08-21 22:57:48 UpdateTip: new best=00000000000000000e6fb7eb872db8d751f0416716fdbf42758a3dd4df0f9a40 height=354994 version=0x00000002 log2_work=82.73045 tx=67669148 date='2015-05-05 01:45:36' progress=0.272229 cache=604.6MiB(4488760txo)
2017-08-21 22:57:48 UpdateTip: new best=0000000000000000066fa7334af0df6dd0e33ae3673ffa430786f61c45bb35e2 height=354995 version=0x00000002 log2_work=82.730487 tx=67669295 date='2015-05-05 01:47:16' progress=0.272229 cache=604.5MiB(4488565txo)
2017-08-21 22:57:48 UpdateTip: new best=00000000000000000113b62f20455002d0a4f5be3ca10b16bbdf5d638d1dd0be height=354996 version=0x00000003 log2_work=82.730524 tx=67669783 date='2015-05-05 01:54:18' progress=0.272231 cache=604.6MiB(4488812txo)
2017-08-21 22:57:48 UpdateTip: new best=00000000000000000c1d6b36cfbcd962a1f32dc504af13118fb983ef4e55944a height=354997 version=0x00000002 log2_work=82.730561 tx=67670262 date='2015-05-05 02:00:24' progress=0.272233 cache=604.6MiB(4488783txo)
2017-08-21 22:57:48 UpdateTip: new best=0000000000000000080c826f7515aae9a3d18a65472029dbb1343e5d78b685c0 height=354998 version=0x00000003 log2_work=82.730597 tx=67670725 date='2015-05-05 02:07:42' progress=0.272235 cache=604.6MiB(4488655txo)
2017-08-21 22:57:48 UpdateTip: new best=0000000000000000032a581d801b0a3d269f7633d0d6cf99158e9074578c22fd height=354999 version=0x00000002 log2_work=82.730634 tx=67671646 date='2015-05-05 02:21:33' progress=0.272239 cache=604.6MiB(4488941txo)
2017-08-21 22:57:48 UpdateTip: new best=00000000000000000b36c1f926e9f4afeac50a580d220c38aacd0185ffc77126 height=355000 version=0x00000002 log2_work=82.730671 tx=67671774 date='2015-05-05 02:29:06' progress=0.272239 cache=604.6MiB(4489000txo)
2017-08-21 22:57:48 UpdateTip: new best=0000000000000000149fb3ca841309360d5f648ba1e36d0a891c165dd5f89804 height=355001 version=0x00000002 log2_work=82.730708 tx=67672597 date='2015-05-05 02:34:52' progress=0.272243 cache=604.6MiB(4489037txo)
2017-08-21 22:57:48 UpdateTip: new best=000000000000000012cc000d5fde40d9133b99c3248eee9f8fb453ac3e3c9fc5 height=355002 version=0x00000003 log2_work=82.730745 tx=67675071 date='2015-05-05 03:30:50' progress=0.272253 cache=604.8MiB(4490406txo)
2017-08-21 22:57:48 UpdateTip: new best=00000000000000000c07f84a68ae35632e5a7bc8c2c3b44fe25ddfbfd080b71b height=355003 version=0x00000002 log2_work=82.730781 tx=67676270 date='2015-05-05 03:34:04' progress=0.272257 cache=604.7MiB(4490163txo)
2017-08-21 22:57:48 UpdateTip: new best=00000000000000000e7b9baf6a815c05b416b6342962197846eeb298d4602163 height=355004 version=0x00000002 log2_work=82.730818 tx=67676751 date='2015-05-05 03:36:19' progress=0.272259 cache=604.8MiB(4490704txo)
2017-08-21 22:57:48 UpdateTip: new best=000000000000000013a15ea6356fd802e862a31d95f26f16176b60a7f9d03358 height=355005 version=0x00000003 log2_work=82.730855 tx=67677212 date='2015-05-05 03:43:46' progress=0.272261 cache=604.8MiB(4490646txo)
2017-08-21 22:57:48 Pre-allocating up to position 0xc00000 in rev00264.dat
2017-08-21 22:57:48 UpdateTip: new
 best=0000000000000000005ceece7a8f247433cce63a4fd6b8ebe7c47f8cc1918730 height=355006 version=0x00000002 log2_work=82.730892 tx=67678892
 date='2015-05-05 04:05:52' progress=0.272268 cache=605.3MiB(4494999txo)
2017-08-21 22:57:48 UpdateTip: new
 best=000000000000000013b1f8d2a39ab4f6f5c4079dc9aa5c9ae23b07a45191ffa1 height=355007 version=0x00000002 log2_work=82.730929 tx=67679522 date='2015-05-05 04:14:11' progress=0.272271 cache=605.4MiB(4495318txo)
2017-08-21 22:57:48 UpdateTip: new best=00000000000000000c4eae36d98809c24d42bf671978526914495fdee16eba07 height=355008 version=0x00000002 log2_work=82.730965 tx=67681734 date='2015-05-05 04:56:48' progress=0.272279 cache=605.5MiB(4496424txo)
   2017-08-21 22:57:49 UpdateTip: new best=00000000000000000be5e8bebac30df1463241b9ab8669605936e20ee9370a39 height=355009 version=0x00000003 log2_work=82.731002 tx=67682377 date='2015-05-05 05:01:48' progress=0.272282 cache=605.4MiB(4495316txo)
2017-08-21 22:57:49 UpdateTip: new best=00000000000000000105cfab9e6cca7cb1822c508e52973f1128d3d83480c05d height=355010 version=0x00000003 log2_work=82.731039 tx=67682547 date='2015-05-05 05:01:45' progress=0.272283 cache=605.4MiB(4495522txo)
2017-08-21 22:57:49 UpdateTip: new best=00000000000000000a8db82eff5ec78d3feb4b8699d140fe52accd3be4ba90c6 height=355011 version=0x00000002 log2_work=82.731076 tx=67683299 date='2015-05-05 05:15:27' progress=0.272286 cache=605.4MiB(4495735txo)
2017-08-21 22:57:49 UpdateTip: new best=000000000000000008cf8e3d3295bc3499edc4d256aebd317ef453a9f01a5968 height=355012 version=0x00000003 log2_work=82.731112 tx=67683476 date='2015-05-05 05:17:20' progress=0.272286 cache=605.4MiB(4495578txo)
2017-08-21 22:57:49 UpdateTip: new best=00000000000000000f2211a9e252dfaa2f656ba632d1645d8885b54a258d1dfe height=355013 version=0x00000003 log2_work=82.731149 tx=67683823 date='2015-05-05 05:19:18' progress=0.272288 cache=605.4MiB(4495519txo)
2017-08-21 22:57:49 UpdateTip: new best=00000000000000000421a8b979ea8cf6cfe5377e6aa88a163a7691055302b602 height=355014 version=0x00000002 log2_work=82.731186 tx=67684769 date='2015-05-05 05:35:35' progress=0.272292 cache=605.4MiB(4495753txo)
2017-08-21 22:57:49 UpdateTip: new best=00000000000000000910d42aefde5e09539c05119ab2fadb3053fb71dedc607e height=355015 version=0x00000002 log2_work=82.731223 tx=67684897 date='2015-05-05 05:48:03' progress=0.272292 cache=605.4MiB(4495645txo)
2017-08-21 22:57:49 UpdateTip: new best=000000000000000008ed45f34eca684d9d351bde8d01fd7198bb666adac70a20 height=355016 version=0x00000002 log2_work=82.73126 tx=67685277 date='2015-05-05 05:42:02' progress=0.272294 cache=605.4MiB(4495547txo)
2017-08-21 22:57:56 UpdateTip: new best=00000000000000001573d1aa3c756b0e6d62591cf5e1b4360d0a96e39e41ec4c height=355017 version=0x00000003 log2_work=82.731296 tx=67686335 date='2015-05-05 06:00:59' progress=0.272298 cache=605.4MiB(4495714txo)
2017-08-21 22:57:56 UpdateTip: new best=00000000000000000f76f04a3170243fa978673465cc096b7bd022aacd1296ed height=355018 version=0x00000002 log2_work=82.731333 tx=67686586 date='2015-05-05 06:17:08' progress=0.272299 cache=605.4MiB(4495605txo)
2017-08-21 22:57:56 UpdateTip: new best=000000000000000002405ca139a0481f771af3c868bc1bee6fa3d44a3264decc height=355019 version=0x00000002 log2_work=82.73137 tx=67688975 date='2015-05-05 06:54:11' progress=0.272309 cache=605.5MiB(4496706txo)
2017-08-21 22:57:56 UpdateTip: new best=0000000000000000002486a6023a2cbc18ffc55f40ace89ced2ebd9143df99fe height=355020 version=0x00000002 log2_work=82.731407 tx=67689341 date='2015-05-05 07:03:57' progress=0.272310 cache=605.5MiB(4496321txo)
2017-08-21 22:57:56 UpdateTip: new best=0000000000000000100296dd99bb9d2d2e082d94b1650ee74e774e619ecba46e height=355021 version=0x00000003 log2_work=82.731443 tx=67690231 date='2015-05-05 07:07:17' progress=0.272314 cache=605.5MiB(4496274txo)
2017-08-21 22:57:56 UpdateTip: new best=0000000000000000105f2032ed871e2daba8e1f83f1d69a3a1db7e2eaa38d558 height=355022 version=0x00000003 log2_work=82.73148 tx=67690485 date='2015-05-05 07:09:28' progress=0.272315 cache=605.5MiB(4496445txo)
2017-08-21 22:57:56 UpdateTip: new best=00000000000000000449cf51e1e7a5db93a3cf2a27c5333396a2640996a0b0bb height=355023 version=0x00000002 log2_work=82.731517 tx=67690585 date='2015-05-05 07:10:34' progress=0.272315 cache=605.5MiB(4496422txo)
2017-08-21 22:57:56 UpdateTip: new best=00000000000000000416506049b419f86de8e0e35ebb6a590d3f223d458a0656 height=355024 version=0x00000003 log2_work=82.731554 tx=67690830 date='2015-05-05 07:15:32' progress=0.272316 cache=605.5MiB(4496459txo)
2017-08-21 22:57:56 UpdateTip: new best=0000000000000000049cdfd6d4074c61d6d61141f4fc929e5c0a813d0b916b55 height=355025 version=0x00000002 log2_work=82.731591 tx=67690969 date='2015-05-05 07:16:43' progress=0.272317 cache=605.5MiB(4496439txo)
2017-08-21 22:57:56 UpdateTip: new best=000000000000000004dc867e4541315090329f45ed4dd30e2fd7423a38a72c0e height=355026 version=0x00000003 log2_work=82.731627 tx=67691153 date='2015-05-05 07:17:33' progress=0.272317 cache=605.5MiB(4496392txo)
2017-08-21 22:57:56 UpdateTip: new best=000000000000000006ef727e0e4a456d1c53bfbb972100fe6c02aed4129c6af9 height=355027 version=0x00000003 log2_work=82.731664 tx=67691823 date='2015-05-05 07:32:02' progress=0.272320 cache=605.5MiB(4496283txo)
2017-08-21 22:57:56 UpdateTip: new best=000000000000000006667c124b0f8e9ea7b9ecc4aaa6949a64dc4aeed278e086 height=355028 version=0x00000002 log2_work=82.731701 tx=67692524 date='2015-05-05 07:41:01' progress=0.272323 cache=605.5MiB(4496414txo)
2017-08-21 22:57:56 UpdateTip: new best=00000000000000000e39e9dea18f78fb917d2a61fbc3885858acb5736d716045 height=355029 version=0x00000003 log2_work=82.731738 tx=67692835 date='2015-05-05 07:45:05' progress=0.272324 cache=605.5MiB(4496276txo)
2017-08-21 22:57:56 UpdateTip: new best=00000000000000000af5078aabaa03b5ead6826cfccdf0f46d469d6736a0661b height=355030 version=0x00000003 log2_work=82.731774 tx=67693051 date='2015-05-05 07:48:19' progress=0.272325 cache=605.5MiB(4496132txo)
2017-08-21 22:57:56 UpdateTip: new best=00000000000000001665b830058098349c5279826b396877517b1cb9c0840722 height=355031 version=0x00000002 log2_work=82.731811 tx=67693160 date='2015-05-05 07:49:08' progress=0.272325 cache=605.5MiB(4496044txo)
2017-08-21 22:57:56 UpdateTip: new best=00000000000000000c31becd1b32471be94c53256f738adad62acdc4e964ed41 height=355032 version=0x00000002 log2_work=82.731848 tx=67693797 date='2015-05-05 07:59:35' progress=0.272328 cache=605.5MiB(4496201txo)
2017-08-21 22:57:56 UpdateTip: new best=0000000000000000108fb7a3c21491e04be01fbf8d3d310183bd97e6bddc39c6 height=355033 version=0x00000002 log2_work=82.731885 tx=67693962 date='2015-05-05 08:02:18' progress=0.272329 cache=605.5MiB(4496142txo)
2017-08-21 22:57:56 UpdateTip: new best=00000000000000000ea900c6f107397862fc1578be6c8b881deca4babbf5b2bc height=355034 version=0x00000003 log2_work=82.731921 tx=67694201 date='2015-05-05 08:05:27' progress=0.272330 cache=605.5MiB(4496431txo)
2017-08-21 22:57:56 UpdateTip: new best=000000000000000005e08c949c0e6c9a8df7b351b070f7cba008b475c330aceb height=355035 version=0x00000003 log2_work=82.731958 tx=67694620 date='2015-05-05 08:10:33' progress=0.272331 cache=605.5MiB(4496393txo)
2017-08-21 22:57:56 UpdateTip: new best=000000000000000013202f3d202d82d70d5be9af44b24770989bf8925cbbb4a8 height=355036 version=0x00000002 log2_work=82.731995 tx=67695178 date='2015-05-05 08:19:08' progress=0.272334 cache=605.5MiB(4496531txo)
2017-08-21 22:57:56 UpdateTip: new best=00000000000000001359218ce1948a429887b440084b68860924a6cd62fdaf56 height=355037 version=0x00000002 log2_work=82.732032 tx=67695266 date='2015-05-05 08:20:04' progress=0.272334 cache=605.5MiB(4496568txo)
2017-08-21 22:57:57 UpdateTip: new best=000000000000000015278af940fad044a10e7af79ac424a7712834344cd26d10 height=355038 version=0x00000002 log2_work=82.732068 tx=67695502 date='2015-05-05 08:22:56' progress=0.272335 cache=605.5MiB(4496568txo)
2017-08-21 22:57:57 UpdateTip: new best=000000000000000015ac94a71ceb6d698b012c50303774d93199f580f1ae1042 height=355039 version=0x00000002 log2_work=82.732105 tx=67695580 date='2015-05-05 08:30:40' progress=0.272335 cache=605.5MiB(4496575txo)
2017-08-21 22:57:57 UpdateTip: new best=00000000000000000321cb05567e72bd2faa5d44f6be4b5692d77c41b367a927 height=355040 version=0x00000002 log2_work=82.732142 tx=67696944 date='2015-05-05 08:43:41' progress=0.272341 cache=605.6MiB(4497013txo)
2017-08-21 22:57:57 UpdateTip: new best=0000000000000000146a99d54646eb2bf5b7aec676b77f1dee6f9acff162dc81 height=355041 version=0x00000003 log2_work=82.732179 tx=67697207 date='2015-05-05 08:46:12' progress=0.272342 cache=605.6MiB(4496986txo)
2017-08-21 22:57:57 Pre-allocating up to position 0xd00000 in rev00264.dat
2017-08-21 22:57:57 UpdateTip: new best=00000000000000000667ada1e714e88f08b4bea9cf5c5e5c9d9c0d55b10d76f3 height=355042 version=0x00000002 log2_work=82.732215 tx=67697982 date='2015-05-05 08:56:26' progress=0.272345 cache=605.6MiB(4497106txo)
2017-08-21 22:57:57 UpdateTip: new best=000000000000000014b1af92a4a6c4c193319589b68455446b8bbd79ccda988a height=355043 version=0x00000003 log2_work=82.732252 tx=67698218 date='2015-05-05 08:59:35' progress=0.272346 cache=605.6MiB(4497221txo)
2017-08-21 22:57:57 UpdateTip: new best=00000000000000000cc71648326bc5b088f151aa86511d58eee9d8cafe08b1b6 height=355044 version=0x00000002 log2_work=82.732289 tx=67699011 date='2015-05-05 09:10:08' progress=0.272349 cache=605.6MiB(4497489txo)
2017-08-21 22:57:57 UpdateTip: new best=0000000000000000122a3578dd80a4c382165474983937a2753f641c746abfec height=355045 version=0x00000002 log2_work=82.732326 tx=67699832 date='2015-05-05 09:32:36' progress=0.272352 cache=605.7MiB(4497575txo)
2017-08-21 22:57:57 UpdateTip: new best=0000000000000000045fdb433b21fb63d3de6ab2374752bee95c213596d0f22b height=355046 version=0x00000003 log2_work=82.732362 tx=67700695 date='2015-05-05 09:33:33' progress=0.272356 cache=605.7MiB(4497771txo)
2017-08-21 22:57:57 UpdateTip: new best=000000000000000007892ed933ef1af3d534519c5098379a7310a68cd1e3370d height=355047 version=0x00000002 log2_work=82.732399 tx=67700846 date='2015-05-05 09:35:50' progress=0.272356 cache=605.7MiB(4497788txo)
2017-08-21 22:57:57 UpdateTip: new best=000000000000000008641293a1de7cbde40b24fc29b5cb79c0582664e53ba97b height=355048 version=0x00000003 log2_work=82.732436 tx=67701353 date='2015-05-05 09:41:09' progress=0.272358 cache=605.7MiB(4497948txo)
2017-08-21 22:57:57 UpdateTip: new best=00000000000000000e55d2b84f06836a0a132663ab6af152d4f70ed2563b080b height=355049 version=0x00000002 log2_work=82.732473 tx=67702830 date='2015-05-05 10:03:18' progress=0.272364 cache=605.8MiB(4498598txo)
2017-08-21 22:57:57 UpdateTip: new best=00000000000000000d97c863738c36c06412463c203265cd826c3281acbd5846 height=355050 version=0x00000003 log2_work=82.732509 tx=67703933 date='2015-05-05 10:17:41' progress=0.272369 cache=605.8MiB(4498691txo)
2017-08-21 22:57:57 UpdateTip: new best=00000000000000000b7e790ec6cf63bb94e0354516ab3bb5a9aaa96d7676afa8 height=355051 version=0x00000002 log2_work=82.732546 tx=67705816 date='2015-05-05 10:46:34' progress=0.272376 cache=606.2MiB(4502183txo)
2017-08-21 22:57:57 UpdateTip: new best=00000000000000000fe801a16676667b6e7e270ef989c27ecbe893767d6c7548 height=355052 version=0x00000002 log2_work=82.732583 tx=67706394 date='2015-05-05 10:48:23' progress=0.272379 cache=606.2MiB(4502435txo)
2017-08-21 22:57:57 UpdateTip: new best=0000000000000000029a678a6c3b12c451cfc8d18e8a21629afdb81120cc33a8 height=355053 version=0x00000002 log2_work=82.73262 tx=67707207 date='2015-05-05 10:56:49' progress=0.272382 cache=606.3MiB(4502540txo)
2017-08-21 22:57:57 UpdateTip: new best=0000000000000000168710c7a956b07f740f4f17cf84ca208588d0f0309dcd51 height=355054 version=0x00000003 log2_work=82.732656 tx=67707780 date='2015-05-05 11:06:26' progress=0.272384 cache=606.6MiB(4505559txo)
2017-08-21 22:57:57 UpdateTip: new best=00000000000000000ea0c1a2d5e9c7dd67e3b2c14eabedb478313e878282d7eb height=355055 version=0x00000002 log2_work=82.732693 tx=67708935 date='2015-05-05 11:19:28' progress=0.272389 cache=606.6MiB(4505675txo)
2017-08-21 22:57:57 UpdateTip: new best=0000000000000000156f0bf7fa060438edec28357c011fe5dbfe48f5b7dc4f59 height=355056 version=0x00000002 log2_work=82.73273 tx=67709460 date='2015-05-05 11:24:26' progress=0.272391 cache=606.7MiB(4505758txo)
2017-08-21 22:57:58 UpdateTip: new best=000000000000000003b44c2f5db22df08866e704412e0d1704c4e6c383a09c72 height=355057 version=0x00000002 log2_work=82.732767 tx=67709888 date='2015-05-05 11:27:51' progress=0.272393 cache=606.7MiB(4505883txo)
2017-08-21 22:57:58 UpdateTip: new best=000000000000000000b4d506ba5bbbdba67d4114ddec6b860fa0b4805bd0a247 height=355058 version=0x00000003 log2_work=82.732803 tx=67711307 date='2015-05-05 11:43:11' progress=0.272398 cache=606.7MiB(4506460txo)
2017-08-21 22:57:58 UpdateTip: new best=00000000000000000bc5bd7ddecf861bd1488d7553e5124e89b678c7416cdaf4 height=355059 version=0x00000002 log2_work=82.73284 tx=67711873 date='2015-05-05 11:49:19' progress=0.272401 cache=606.8MiB(4506882txo)
2017-08-21 22:57:58 UpdateTip: new best=000000000000000002a24f166c603b798d3fac08a3a6476fefa79dd5f84a555c height=355060 version=0x00000003 log2_work=82.732877 tx=67712898 date='2015-05-05 12:00:32' progress=0.272405 cache=606.8MiB(4506644txo)
2017-08-21 22:57:58 Pre-allocating up to position 0xe00000 in rev00264.dat
2017-08-21 22:57:58 UpdateTip: new best=000000000000000015904c5a1ab19652278f0d69eb5ed9fc96c30ce8bc326d43 height=355061 version=0x00000003 log2_work=82.732914 tx=67714559 date='2015-05-05 12:21:51' progress=0.272411 cache=606.8MiB(4507324txo)
2017-08-21 22:57:58 UpdateTip: new best=0000000000000000021eee625490f82894fd4753229735435a28fb2b0b6698b3 height=355062 version=0x00000003 log2_work=82.73295 tx=67714819 date='2015-05-05 12:23:10' progress=0.272413 cache=606.8MiB(4507177txo)
2017-08-21 22:57:58 UpdateTip: new best=00000000000000000bd568195c703df04cd8c5b3d00153c74523a92601aaa4ca height=355063 version=0x00000003 log2_work=82.732987 tx=67717005 date='2015-05-05 12:57:34' progress=0.272421 cache=607.0MiB(4508326txo)
2017-08-21 22:57:58 UpdateTip: new best=00000000000000000ceb5b981a3dc1324bd02c90631c1a37d09e6bd59a6d364a height=355064 version=0x00000003 log2_work=82.733024 tx=67717940 date='2015-05-05 13:01:10' progress=0.272425 cache=607.0MiB(4508462txo)
2017-08-21 22:57:58 UpdateTip: new best=00000000000000001324d4cb385458edcba6bd65288e04d0aa7ea18e7f558d4f height=355065 version=0x00000003 log2_work=82.73306 tx=67719107 date='2015-05-05 13:14:09' progress=0.272430 cache=607.1MiB(4509061txo)
2017-08-21 22:57:58 UpdateTip: new best=00000000000000000b34cfbb72c0db704e7fa3b2bafe8bdbaea9d7f56980cc6d height=355066 version=0x00000002 log2_work=82.733097 tx=67719665 date='2015-05-05 13:19:27' progress=0.272432 cache=607.1MiB(4509177txo)
2017-08-21 22:57:58 UpdateTip: new best=000000000000000004597ff3dabc9ad3e251a0123ae17e9fe002c2fb94333b28 height=355067 version=0x00000002 log2_work=82.733134 tx=67720290 date='2015-05-05 13:25:55' progress=0.272435 cache=607.1MiB(4509467txo)
2017-08-21 22:57:58 UpdateTip: new best=0000000000000000001b47a82c40042a20380f73c7070b244c9d2b5dd429b6b9 height=355068 version=0x00000002 log2_work=82.733171 tx=67720403 date='2015-05-05 13:26:40' progress=0.272435 cache=607.1MiB(4509595txo)
2017-08-21 22:57:58 UpdateTip: new best=00000000000000001651ad6fc25a5ff1f28244de888efd8c7dd557a76dd96abe height=355069 version=0x00000003 log2_work=82.733207 tx=67720642 date='2015-05-05 13:28:20' progress=0.272436 cache=607.1MiB(4509534txo)
2017-08-21 22:57:58 UpdateTip: new best=00000000000000000708d3f75ed2c56e99e0237547a8012539ae6baad76fe791 height=355070 version=0x00000002 log2_work=82.733244 tx=67720809 date='2015-05-05 13:29:54' progress=0.272437 cache=607.2MiB(4510028txo)
2017-08-21 22:57:59 UpdateTip: new best=000000000000000000659c1295857f37d035074c53cafac35c8769676e58e2e9 height=355071 version=0x00000002 log2_work=82.733281 tx=67721712 date='2015-05-05 13:37:56' progress=0.272440 cache=607.3MiB(4511046txo)
2017-08-21 22:58:00 UpdateTip: new best=0000000000000000152a5befb704571d023b3e74421359309bc6920778e76195 height=355072 version=0x00000003 log2_work=82.733318 tx=67722207 date='2015-05-05 13:41:30' progress=0.272442 cache=607.3MiB(4510801txo)
2017-08-21 22:58:00 UpdateTip: new best=000000000000000012b422a2d3a33da9700f095f37768709f9973d612f35af83 height=355073 version=0x00000003 log2_work=82.733354 tx=67722208 date='2015-05-05 13:42:25' progress=0.272442 cache=607.3MiB(4510802txo)
2017-08-21 22:58:00 UpdateTip: new best=00000000000000000a5d047d643ef63b2e5608eecbe4866184f89ce34fce5b4f height=355074 version=0x00000002 log2_work=82.733391 tx=67722956 date='2015-05-05 13:51:33' progress=0.272445 cache=607.3MiB(4510960txo)
2017-08-21 22:58:00 UpdateTip: new best=000000000000000011ab450f3abe89a18f4911f48bdcd2fc2bb0104721a3d061 height=355075 version=0x00000002 log2_work=82.733428 tx=67723200 date='2015-05-05 13:54:24' progress=0.272446 cache=607.3MiB(4510978txo)
2017-08-21 22:58:00 UpdateTip: new best=000000000000000001af82cf103fef247f5606ae62deb3630d76003fe10fb5fa height=355076 version=0x00000002 log2_work=82.733464 tx=67724096 date='2015-05-05 14:04:52' progress=0.272450 cache=607.3MiB(4511299txo)
2017-08-21 22:58:00 UpdateTip: new best=000925 tx=67838825 date='2015-05-06 14:55:54' progress=0.272911 cache=612.8MiB(4555745txo)
2017-08-21 22:59:11 UpdateTip: new best=000000000000000007da0160fe28a5ad6c0416bbff7f440323be3f948c648764 height=355226

lsof -i

What happens if you use curl with --verbose? Also, HOST=localhost isn't doing anything; that is not a valid bitcoin.conf option. I don't think testnet=3 does anything either; the proper config for that is testnet=1. You aren't specifying which testnet to use; you are specifying whether to use testnet or not.

Did you mean I need to specify testnet=1 for config if I use  Testnet? And I don't know about the curl 'cause I was told that I entered the curl to check my bitcoind environment is fine or not by a developer on GitHub.

Yes, you need to specify testnet=1 in your bitcoin.conf to use testnet. For curl, use the --verbose option after the curl command, so your command should be something like curl --verbose --user ryunishida:password --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getinfo", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:18332/ -w '%{http_code}\n'. Also, what is %{http_code}?

Sorry I don't know but maybe thanks to specifying that,I can know the status code like 403.im not familiar with curl.

I got the same error again.

Trying 127.0.0.1...
TCP_NODELAY set
Connection failed
connect to 127.0.0.1 port 18332 failed: Connection refused
Failed to connect to 127.0.0.1 port 18332: Connection refused
Closing connection 0
000
curl: (7) Failed to connect to 127.0.0.1 port 18332: Connection refused

Of course you get the same error, --verbose is not a fix, it is a thing to get more information about the error. Can you edit your post with the output of lsof -i? This is not going to fix any problems, it will just give us more information to figure out what is wrong. Can you also edit your post with the entirety of the debug.log file which you can find in the same folder as the bitcoin.conf file.

Sorry the debug.log was too huge so i won't be able to show you all of them.So I posted recent datas.

The section you posted is not helpful. Please find a section that has 10 blank lines before actual entries. Such sections are for starting up Bitcoin Core which is will have the information I need to see. Please post as much as you can in the entries following those 10 blank lines. If you can't find such a section, just post as much as you can.

You meant both of them or debug.log or lsof- i?

Post both the debug.log file and lsof -i output.

Bitcoin Core is not binding to port 18332. Add the following line to your bitcoin.conf file.
rpcbind=127.0.0.1:18332

I had that {"result":null,"error":{"code":-28,"message":"Loading block index..."},"id":"curltext"}

That means that it is working. Bitcoin Core is still in its startup phase. Just wait a few minutes and try again.

I reinstalled then I got

Trying 127.0.0.1...
TCP_NODELAY set
Connected to 127.0.0.1 (127.0.0.1) port 18332 (#0)
Server auth using Basic with user 'ryunishida'

POST / HTTP/1.1
Host: 127.0.0.1:18332
Authorization: Basic cnl1bmlzaGlkYTpwYXNzd29yZA==
User-Agent: curl/7.54.0
Accept: /
content-type: text/plain;
Content-Length: 71

upload completely sent off: 71 out of 71 bytes
< HTTP/1.1 200 OK
< Content-Type: application/json
< Date: Tue, 22 Aug 2017 09:29:09 GMT
< Content-Length: 626
<

{"result":{"deprecation-warning":"WARNING: getinfo is deprecated and will be fully removed in 0.16. Projects should transition to using getblockchaininfo, getnetworkinfo, and getwalletinfo before upgrading to 0.16","version":159900,"protocolversion":70015,"walletversion":139900,"balance":0.00000000,"blocks":149215,"timeoffset":-2,"connections":7,"proxy":"

","difficulty":1,"testnet":true,"keypoololdest":1503393418,"keypoolsize":2000,"paytxfee":0.00000000,"relayfee":0.00001000,"errors":"This is a pre-release test build - use at your own risk - do not use for mining or merchant applications"},"error":null,"id":"curltest"}

Connection #0 to host 127.0.0.1 left intact
200

Those responses mean that it is working now.


text:
I got an error that says curl: (7) Failed to connect to localhost port 18332: Connection refused
I could succeed to work the testnet at once.However after I restarted my Mac,bitcoind came not to work.

bitcoind doesn't restart after your computer restarts. Start bitcoind after you start your computer.

source: Stack Exchange

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

sort: votes


text:
How could I integrate bitcoin transfer between users in my mobile/web application?
Hello I wanted to allows users of the application to be able to exchange bitcoin and maybe other cryptocurrencies in the app. I'm trying to figure out the best way to implement this. Can anyone recommend a good method, api, or example I can use to implement this system?

What kind of exchange do you want? "On-chain" exchange with blockchain transactions or "off-chain" exchange like an exchange market?

I think on-chain. It would be used for users to tip other users or donate bitcoin. Mostly curious what standard procedure is for this kinda thing and what the best way to implement it is...

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


text:
Can my internet provider see I'm using bitcoin core (Russia)
I live in Russia and bitcoin is prohibited here. Can my internet provider see I'm using bitcoin so I will have problems?
UPD: Right now I'm still syncing bitcoin core. Is syncing as dangerous as participating in transactions?

Yes, they can see you. Even if you're using cash in person, you still can be traced. Think about just trying to verify an address in an exchange, because you are interested in that address, there is a chance that you know somebody the address belongs to. When something is prohibited, it's better to work on politics to make it legal then trying to go around it because you will live in fear to be traced one day or an other.

Yes, they can.  It is quite easy to detect an ordinary Bitcoin client; it sends unencrypted messages of a standard and unique format to well-known TCP ports.  Moreover, if they monitor all your traffic, it would not be too hard for them to link you with the transactions you send; Bitcoin tries to "cloak" your transactions by sending them out along with other people's relayed transactions.  But if they can see all your incoming traffic, then when you send out a transaction that you never received from someone else, they can conclude it is one that you yourself created.
Identifying the recipient of the transaction might be harder, unless it happens to be someone they are already monitoring;  then they could see when that person spends the coins you sent.
An encrypted VPN, or proxy service like Tor, can help with this, to some extent.  However, then you have to trust the VPN provider not to cooperate with the authorities, or to monitor your traffic themselves and use it for their own evil purposes.  In the case of Tor, there might be similar problems if you connect to a Tor node which is compromised; someone who controls all your Internet traffic might be able to arrange for this to happen.

Thank you!
Right now I'm still syncing bitcoin core. Is syncing as dangerous as participating in transactions?

Well, it certainly shows that you are using the client.  And once the sync finishes, you will start relaying transactions for other people, and you might have a hard time proving that those are not transactions you are making.  I don't know enough about the legal situation to know how risky that might be.

if bitcoin is prohibited there, then your government must has a way to monitor its usage, so you probably could get into problem, but the chance of getting prosecuted is very low because they can't trace who you are paying to, so you can buy drug or child pornography or bombs from anyone, and your government won't know what you are buying, but there is a chance that when the police search your house and find the illegal things that you bought with bitcoin and you will definitely go to jail and get your a$$ cleaned there.

can vpn help here?

by using VPN, you are only hidden yourself from the ISP and your government for doing the bitcoin thing, but when they are suspicious you of breaking the law in one way or other, they can still search your house and computer and know what you were doing. so wearing mask (VPN) or not if you want to rob somebody, rob them outside of your neighborhood.


text:
Lightning Route Discovery - How to know capacity in each direction?
So i have a question how routing works in the LN. I read partly through the RFC described in https://github.com/lightningnetwork/lightning-rfc but I have still this open question.
I know every node in LN has the whole network topology information, so it knows each node and each channel and with that also the capacity of a channel. But the capacity of a channel doesn't say which side is owning how much. How can we find now a valid route and be sure that there is enough capacity in each channel for the direction which is part of our route?
So for an example lets say I am node A und have a channel to node B and this one has a channel to node C. Lets say each channel has a capacity of 1 BTC, I want to send now 0.4 BTC from A to C and chose the route A -> B -> C. But now it may be that in the channel B - C the node B only owns 0.3 BTC at the moment and node C owns 0.7 BTC. That would mean that B can't send 0.4 to node C. So if I send now this transaction B would return with an error.
If I have now a longer route the possibility of such an event increases exponentially. So at the end it is very unlikely that my chosen route is valid. How does the protocol prevent a lot of tries until one finds a really valid route?

Even if you did find such a route successfully, what guarantees that B WILL use its payment channel? B can deny at any moment, because decentralization.
Also, from routing recommendations:

When calculating a route for an HTLC, the cltv_expiry_delta and the
  fee both need to be considered: the cltv_expiry_delta contributes to
  the time that funds will be unavailable on worst-case failure. The
  tradeoff between these two is unclear, as it depends on the
  reliability of nodes.

Goes on to explain that the problem is deeper:

If a route is computed by simply routing to the intended recipient,
  summing up the cltv_expiry_deltas, then nodes along the route may
  guess their position in the route. Knowing the CLTV of the HTLC and
  the surrounding topology with the cltv_expiry_deltas gives an attacker
  a way to guess the intended recipient. Therefore it is highly
  suggested to add a random offset to the CLTV that the intended
  recipient will receive, bumping all CLTVs along the route. In order to
  create a plausible offset the sender MAY start a limited random walk
  on the graph, starting from the intended recipient, sum the
  cltv_expiry_deltas, and then use the sum as the offset. This
  effectively creates a shadow route extension to the actual route,
  providing better protection against this kind of attack than simply
  picking a random offset.

Importantly for this answer, it ends at:

Other more advanced considerations involve diversity of routes to
  avoid single points of failure and detection and channel balance of
  local channels.

So the answer would be, that LN just provides discovery, doesn't build a path(because a channel cannot be guaranteed to be online in a decentralized network??) so 'tries' is not a feature of core LN(but of the autopilot feature).
The autopilot can be seen here. This is where the heuristics for finding the path goes.

The autopilot package has been signed to be as abstract as possible in
  order to allow users, developers, and researchers to plug in various
  heuristics in order to experiment with the possibilities, or attempt
  to optimize the channel sub-graph for their targeted nodes. The
  current default heuristic is a mode called ConstrainedPrefAttachment.

Also,

This is only one example of the
  possible heuristics which could be hooked into an active
  autopilot.Agent instance. We look forward to the additional heuristics
  that developers/researchers will implement!

In short, the current heuristic implementation first selects a slice in the network, and then greedily allocates funds.
switch {
    // If we have enough available funds to distribute the maximum channel
    // size for each of the selected peers to attach to, then we'll
    // allocate the maximum amount to each peer.
    case int64(fundsAvailable) >= numSelectedNodes*int64(p.maxChanSize):
        for i := 0; i < int(numSelectedNodes); i++ {
            directives[i].ChanAmt = p.maxChanSize
        }

        return directives, nil

    // Otherwise, we'll greedily allocate our funds to the channels
    // successively until we run out of available funds, or can't create a
    // channel above the min channel size.
    case int64(fundsAvailable) < numSelectedNodes*int64(p.maxChanSize):
        i := 0
        for fundsAvailable > p.minChanSize {
            // We'll attempt to allocate the max channel size
            // initially. If we don't have enough funds to do this,
            // then we'll allocate the remainder of the funds
            // available to the channel.
            delta := p.maxChanSize
            if fundsAvailable-delta < 0 {
                delta = fundsAvailable
            }

            directives[i].ChanAmt = delta

            fundsAvailable -= delta
            i++
        }

        // We'll slice the initial set of directives to properly
        // reflect the amount of funds we were able to allocate.
return directives[:i:i], nil

[EDIT:straight answer]

So the heuristic only uses the channel capacity to find a route?

"based on the current internal state, the state of the channel graph, the set of nodes we should exclude, and the amount of funds available"

Does the path finding heuristic have the information which side of a channel in the network owns how much, or does it only compute a route based on the capacity of channels?

Looking at the spec example, we only get info of "capacity" of an "edge" in the graph and not how much each party owns; only the amount they are willing to transmit. As explained above, yes, it depends on capacity, but it has more properties and not just amounts.

Thanks for your answer, I don't really understand how the heuristic works. So the heuristic only uses the channel capacity to find a route? So what my initial question was: Does the path finding heuristic have the information which side of a channel in the network owns how much, or does it only compute a route based on the capacity of channels?

@blacktemplar edited the answer. I hope it answers your query. If not please ask for more clarification.


text:
how to import my wallet from blockchain.info into bitcoin-qt?
I have read the related discussions about how to import a wallet and though they are close, the answers does not help with this problem so I'm asking it here and now.
I have my bitcoin public address which was given to me by blockchain website when i registered, and the secret 12 words passphrase, and the blockchain wallet ID and my password for blockchain website. I can't login to the blockchain website because it sends a 2FA key to an old email for which I lost my password a long time ago. I have been asking for blockchain support because I can easily prove I am the account owner but I got no answer so far.
So, I'm looking to solve this problem. I'm running Linux Mint and I would like to import by bitcoin wallet into bitcoin-qt client. I know I need to use importprivkey into the debug console but I don't know how to get my private key since I can't login to blockchain website.
Many thanks for any help.


text:
How do I securely store different CryptoCurrencies?
I may be seen as a newcomer and and a non-tech-savy person for asking this, but after serveral hours combing the internet, I now have to admit my defeat and ask the question instead of just finding the answer myself.
For long I have been wanting to invest in more "exotic" crypto currencies. What is the most secure way to do long-time investments in crypto currency?
I don't like the idea of having my currency lying at a broker, and ideally I would like to buy a currency, transfer it to a cold wallet, and then let the wallet and backups thereof sit offline until I believe it's time for selling the currency again.
Is this possible to do for anything else than BitCoins and Etherium?

Try Monero or Bitcoin Cash.

I think this question is mistitled: What you actually seem to be asking is "how do I securely store cryptocurrency". Since questions for investment advice are off-topic here, I think you'll get a much better response if you edit your question to clarify it is about storage.

Short answer: Yes, it is possible. But depends on every coin. The majority of the top coins has his own wallet where your funds can't be stolen.
First of all, taking into account that cryptocurrencies are a developing technology I wouldn't use the word "securely". But if you want to minimize the risk, I recommend you to diversify your portfolio, for example:

50% BTC
20% ETH
10% LTC
10% XMR
5% IOTA
5% MAID

That would be pretty much my choice, you can make your own.
In any case, for a long-term investment I recommend you to research the core technology of each coin. And of course guard the funds on your own wallet.
If you want to invest on really new cryptocurrencies that doesn't have a wallet yet, you'll have to let the money on the exchange until a wallet is launched. There's no other way.

For example, for a medium-team investment I have been looking into WTC. But I cannot find any way to buy and the nexstract those coins.
But as you are saying, in those cases where the coins are really new, I might just have to rely on the broker and then hope my coins aren't stolen or lost before a wallet is out there.


text:
Cryptocurrency arbitrage taxes in India
Suppose I buy cryptocurrencies in the U.S. and transfer to my or my parents' wallet in India and sell at a premium and make a profit.

Is this profit taxable in India?
If so, how is it calculated? Selling price in INR minus buying price in USD to INR = capital gains?

I'm afraid you should be asking in an Indian financial forum, not a Bitcoin one

I'm voting to close this question as off-topic because it needs to asked in a local indian forum, not here.


text:
bitcoind password for every address
I need a system where I need to create new address for every user(personal account) where they will transfer some bitcoins to it and buy some products from my website.
So, I've started bitcoind and through bitcoin-cli, I've generated new address(bitcoin-cli getnewaddress "USEREMAILID") and assigned it to the users.
Now the users will buy some products on my website (i.e. transfer amount from their account to company's account) and then the transfer happens and based on the confirmations, the product will be purchased.
Now my question is, whenever user starts buying a product, he will execute command (bitcoin-cli sendfrom) and for doing that, we need to first unlock the wallet by walletpassphrase and then do the transaction. so, there would be only 1 password which is assigned to the wallet but not every address.
Is this the correct way?
If user needs to enter his custom password and then process the transaction, would it be possible?

So, I've started bitcoind and through bitcoin-cli, I've generated new address(bitcoin-cli getnewaddress "USEREMAILID") and assigned it to the users.

Please don't do this. You are using the accounts system in Bitcoin Core which is deprecated, slightly unreliable/has weird behavior, and will be removed in the future.
Maintain your own accounting system outside of Bitcoin Core. Just have a database with addresses and their associated user.

Now my question is, whenever user starts buying a product, he will execute command (bitcoin-cli sendfrom) and for doing that,

Why? Why don't you just change their balance on the website and just leave the coins there? There is no need to make actual transactions that move the coins to you, just change it internally.

we need to first unlock the wallet by walletpassphrase and then do the transaction. so, there would be only 1 password which is assigned to the wallet but not every address.

No, that is not how Bitcoin Core, addresses, or accounts work. Accounts are not wallets. All of the addresses for all of the accounts belong to the same wallet. Unless you are using Bitcoin Core 0.15+ and have enabled the use of multiwallet, you are only using one wallet in Bitcoin Core. So there is only one passphrase to be used with walletpassphrase and it unlocks the entire wallet which includes all of the addresses you have given out on your website.

Is this the correct way?

No, it is not.
The correct way is to maintain a separate database with user accounts, associated addresses, and account balance. When you transfer coins internally (i.e. from one user to another or from one user to you), update the balances in that database instead of making a Bitcoin transaction. When you want to send coins externally (i.e. user withdraws) then you send from the Bitcoin Core wallet and update your own database. When you send, just use sendtoaddress. Do not use Bitcoin Core's accounts system and don't try to make it so that you are sending from certain addresses.

If user needs to enter his custom password and then process the transaction, would it be possible?

No, as I explained above, that is not how this works.


text:
GDAX deposit accounts - what happens to addresses that change?
I sent a LTC transfer into a GDAX deposit account. I have done this before without any issues.
The transfer appears processing from the exchange I sent it and it still hasn't appeared in the block explorer, however when I check on GDAX, the deposit address changed. I did a test sending a small amount, and after seeing it went through repeated the transfer to the same address with a larger amount.
I cannot stop or modify the transfer out and would like to know what happens to the old GDAX deposit account?
Will the deposit be recognized by GDAX? Has anybody sent litecoin or bitcoin to a deposit account that had changed before sending?

The address changed because you used the old one.
Don't worry, the transfer is valid, and they keep track of the old address. However, for future transfers they want you to use another address. This is beneficial to privacy.

Thanks for the answer. What happens if I used the old address for a new transaction?

Presumably that will work, but that's up to GDAX.

I hope it does... otherwise my "best practice" of testing with a low amount and then repeating with the big one just got me into big problems. I'll come back to share the result.

How so? Just send the bigger amount to the new address?

I had already sent it to the old one, that is the issue...

Transfer appeared on GDAX account. So relieved!


text:
Sent BTC to Jaxx Wallet Never Received
A friend suggested I use Jaxx Wallet so I downloaded the software and sent my BTC using their QR Code from Coinbase. Looking back, I should've left it where it was!
It never arrived. I also sent LTC using the same QR Code method. That has arrived and is in my Jaxx Wallet now.
I see my transaction completed and verified on the blockchain. How do I locate where it is?
How can I trace that this transaction was actually sent (and maybe received) by Jaxx although it doesn't show in my wallet?

This is really a service question for either Jaxx or Coinbase, or both.

try resetting the cache on jaxx and let it re-sync, the coins should show up

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


text:
What is the average time for an honest network to find a block when its hash rate is p?
let p be the hash rate that belongs to honest network and T be the time a block is found. In the Bitcoin paper it's said "assuming the honest blocks took the average expected time per block...". In another paper it's said this average time is T/p.
Question: What is the average time for an honest network to find a block?
If it's T/p, why?

I think,
if p+q=1, where q is an attacker's hash rate and a block is found with the full hash rate: H, in T time. Then for an honest network, it would take, pT (not T/p).
Am I missing something?

I do not agree with the assumptions.
In the Bitcoin network, the average block time is also a function of the difficulty, approximately:
(P*d)/p = 10 minutes

Where P is the average number of hashes to obtain a new block in 10 minutes (if d=1 and p=1 at base - it wasn't - then P=600), d is the current network difficulty and, p is the current network hash rate per second.

Presuming the honest network and the attacker both perform honest mining, the expected time till the honest network finds a block is T/p.
T is the expected time until any participant in the network finds a new block, p is the hash power of the honest network.
pT makes absolutely no sense since this would mean that a low hash rate will make you find blocks fast. In fact a participant with a mining power of 0 would be able to find a new block in 0*T = 0 time.


text:
How to install Trezor Bridge?
When opening my Trezor Wallet on Chrome I get a message:

The TREZOR Chrome Extension will be outdated soon.
  Google will disable the functionality required by the TREZOR Chrome Extension during this year.
  To avoid any service downtime, please install the TREZOR Bridge instead.

So I installed Trezor Bridge 2.0.14 on a MacOS High Sierra 10.13.3 but the website is still not recognizing the installation. It still says that it is not installed even though I used the Mac's Installer and everything went fine.
How can I install it properly or make the website recognize the installation?
EDIT: This is what I see after installing Bridge but then when I refresh it still says it is not installed. There are no additional icons like blocked popups or something like that in the url bar.

Chrome may be blocking the site from having access to the bridge. Check in the URL bar for any icons that aren't normally there. Those will usually have some box saying "X has been blocked" and have an option to allow it. Can you also post a screenshot of the issue that you are seeing?

Check out the bridge wiki page.  It has a link to the download files through github as well as a link to the URL to check your own bridge status.

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


text:
Keeping my bitcoins safe: any flaws in my strategy?
I'm looking for a very safe way to keep my bitcoins. I'm using a Trezor and used passphrase to hide additional wallets in case someone gets access to my Trezor or seed by physical coercion. I'm not interested in recommendations about keeping my seed safe. Hope this strategy can help someone in this forum and would like to get any feedback about some flaws.
My strategy needs to prevent a scenario where there is no Trezor hardware wallet (eg. Trezor is out of business). I checked for wallets that can recover my wallet using my seed and verify myself that it works. The wallets that worked at this moment (October 24th 2017) are Electrum (I used the OS X program), Mycelium (the Android app) and Wallet32 (the Android app).
I restored with Electrum by using the New/Restore -> Creating a wallet -> Standard Wallet -> I already have a seed and then provide the seed with the Extend this seed with custom words and BIP39 seed options checked. And finally provide the passphrase.
Mycelium and Wallet32 are super friendly with restoring your wallet.
Note I currently have only managed to recover my bitcoin wallet from the Legacy Account and not from the Segwit-ready Account. Looks like these wallets still haven't support this Segwit-ready accounts.

The segwit accounts in TREZOR Web Wallet are derived using BIP49.
So far, no software wallet I know support this, unfortunately. I have heard that Electrum is working on it.
However, if you already wrote your seed to your PC or phone to some of the wallets - Electrum, Mycelium, Wallet32 - you should consider it compromised and move your coins somewhere else. Seed is good only if you don't rewrite it to your PC or mobile phone.
Note that Wallet32 is no longer maintained; since it is a regular SPV wallet, it's possible it will stop working with Segwit2x fork. Mycelium should work; as should Electrum, or its Android clone.
Also, other hardware wallets support the same seeds as TREZOR - for example, there is Ledger wallet, that uses the same seeds and the same logic for accounts. So you can rewrite your seed there and you will have access to your coins.
Because I am an employee of TREZOR, I will tell you that it's more wasy to use than Ledger, but I am obviously biased :) but if you have the seed, you can also use Ledger with the same seed as TREZOR.

After verifying that I can recover from those wallets (Electrum, Mycelium, Wallet32) I moved my bitcoins to a new wallet generated from my Trezor. Then I wiped out my Trezor and recover the wallet using the Advanced Recovery method. My seed is stored in a paper wallet. Is my seed compromised by just recovering using the Advanced Recovery method?

Advanced recovery is fine, since the letter matrix is randomized, so possible  attacker doesn't know anything.


text:
How is the value of a forked currency being determined?
As in the case of Bitcoin's hard fork Bitcoin Cash, what determines the value of the forked currency?
Say before the fork I had X BTC; then now after the fork I have X BTC and X BCH. What does affect the value of my X BTC? What does affect the value of my X BCH? What does determine the market caps of both currencies? Is it a group of big backers that come to an agreement on shifting their assets to the forked currency? Can you think of it (in the bigger picture) as: post_fork_BTC_market_cap = pre_fork_BTC_market_cap - initial_BCH_market_cap? Or otherwise the forked currency's market cap is "imported" from a combination of different market caps?
Note: I used Bitcoin and Bitcoin Cash as an example, without loss of generality.
Another approach that comes to my mind is to think of it as an ICO funding. Let's say that there is currently a circulating supply of 800,000 FOO (Foocoin), and now I'm creating a fork of Foocoin called Barcoin (BAR). I funded 200,000 FOO for this purpose at an exchange rate of 1 FOO = 500 BAR, so the initial circulating supply of Barcoin is 800,000 + 200,000 * 500 BAR = 100,800,000 BAR, so that eventually each one of the funders has lost some value, while each one of the FOO holders has gained some value in the form of an "airdrop".
For example someone who had ~2000 FOO now also has ~2000 BAR that equal to ~4 FOO; this is without correlation to the market cap of FOO. But if this person funded Barcoin using Foocoin, then it is resulted in less profit out of the fork. But then nobody will fund this project unless it's completely necessary from the person's viewpoint.
Is it something like this?

It's entirely supply and demand.  The "price" is just a report of what buyers and sellers are doing right now.  They may or may not be motivated by any particular notion of value. Market cap is just a name for price times quantity.


text:
-SOLVED- I was Making a new genesis block and i got this error
following this guide i solved my problem
my psztime was so long so i had to make it short and all were solved :) it successfully compiled and run pretty well
I was making a new genesis block, all was successfully but when I launch the new
 main.cpp:2747: bool LoadBlockIndex(bool): Assertion
 `block.CheckBlock()' failed. Aborted

I don't know what that means. I replaced the block.GetHash(), the hashMerkleRoot and also the block.nNonce in to the corresponding files but it won't work.
Anyone knows what is wrong?
This is my dump
CBlock(hash=000008d24b2b4473cf5ceb4c858b31dbd4d812c20cb5a6d60002e55a88cf6bf3, ver=1, hashPrevBlock=0000000000000000000000000000000000000000000000000000000000000000, hashMerkleRoot=00a51fca8509df84304bc58ee4da87b67552829d83c19faaea3358dc9a582cc6, nTime=1508815578, nBits=1e0fffff, nNonce=80207, vtx=1, vchBlockSig=)
  Coinbase(hash=00a51fca85, nTime=1508815578, ver=1, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(0000000000, 4294967295), coinbase 00012a4c8a4f6e65206772657920656c657068616e742062616c616e63696e6720537465702062792073746570206f6e2061207069656365206f6620737472696e672048652074686f75676874206974207761732073756368206120776f6e64657266756c207374756e7420546861742068652063616c6c656420666f7220616e6f7468657220656c657068616e74)
    CTxOut(empty)
  vMerkleTree: 00a51fca85
block.GetHash() == 000008d24b2b4473cf5ceb4c858b31dbd4d812c20cb5a6d60002e55a88cf6bf3
block.hashMerkleRoot == 00a51fca8509df84304bc58ee4da87b67552829d83c19faaea3358dc9a582cc6
block.nTime = 1508815578
block.nNonce = 80207

What to do?

what is the exact code at line 2747.  that is where your error is.  If i remember correctly you need to assert the correct hash.  You are following a guide to create your own genesis block? can u post it so I can see what you have done already

i didn't followed a guide i dont know where to find one i was searching and searching and inothing found maybe i dont know how to use google :P
this is the line content
assert(block.CheckBlock());
this is my main.cpp file
http://pasted.co/824fad42
and this is my main.h file
http://pasted.co/a49efcaf

http://pasted.co/824fad42 does not display code :( im afraid.... have a look at the peershares wiki on how to generate new genesis block and new network, https://github.com/Peershares/Peershares/wiki/Genesis-Block-%28Starting-a-New-Blockchain-Instance%29

omg! weird i uploaded it again to pasted.co and checked but didnt show code so i uploaded the file to my host and it's on
http://cyber-xtreme.net/main.cpp
i will take a look on that wiki thanks bro

@Fuzzybear thanks for your help my pszTimestamp was so long so i had to make it more small and now it's working the daemon now i just need to compile wallet and it's done! thanks for your help i followed that guide and works!

@Rodrigo - Instead of adding "solved" to title and writing it to comments, add your own answer as a regular answer and accept it, please

@Rodrigo No you did not.

@PieterWuille
ohhhhh sorry i didn't saw the answer my question button

Following this guide solved my problem my psztime was so long, so I had to make it short and they all were solved :) It successfully compiled and ran pretty well.


text:
altcoin debug.log shows ERROR: CTxDB::LoadBlockIndex() : Failed stake modifier checkpoint height=0
What I have done so far:

Generated new Genesis Block
Generated new MerkleRoot
Updated MerkleRoot
Updated Genesis block values
Commented out these lines
Compiled on CentOS 6
Created altcoin.confwith

rpcuser=someuser
rpcpassword=somepassword

lauched ./altcoin

at this point all seemed to be OK but...

./altcoind getinfo

shows:
{
    "version" : 60300,
    "protocolversion" : 60001,
    "walletversion" : 60000,
    "balance" : 0,
    "blocks" : 0,
    "connections" : 1,
    "proxy" : "",
    "difficulty" : 1.00000000,
    "testnet" : false,
    "keypoololdest" : 1400530204,
    "keypoolsize" : 104,
    "paytxfee" : 0.00000000,
    "mininput" : 0.00010000,
    "errors" : ""
}

so I try to use internal miner to mine first block ./altcoind setgenerate true 8
while checking progress by ./altcoind getmininginfo i got strange output

which shows:
{
    "blocks" : 0,
    "currentblocksize" : 0,
    "currentblocktx" : 0,
    "difficulty" : 1.00000000,
    "errors" : "",
    "generate" : true,
    "genproclimit" : 4,
    "hashespersec" : 0,
    "networkhashps" : 1.46543,
    "pooledtx" : 0,
    "testnet" : false
}

At this point, I've issues ./altcoind stop and when I try to launch it again, debug.log shows:
Altcoin Network: genesis=0x00000000324a1b505ecd nBitsLimit=0x1d00ffff nBitsInitial=0x1c00ffff nStakeMinAge=604800 nCoinbaseMaturity=500 nModifierInterval=21600
ERROR: CTxDB::LoadBlockIndex() : Failed stake modifier checkpoint height=0, modifier=0x0000000000000000
 block index               1ms
Loading wallet...
nFileVersion = 60300
Error loading blkindex.dat
 wallet                  301ms
Done loading
mapBlockIndex.size() = 1
nBestHeight = -1
setKeyPool.size() = 101
mapWallet.size() = 0
mapAddressBook.size() = 1

uncommented these lines
lauched ./altcoind

and the same error over and over again... I am cracking my head already a while....
can one, please point me the right direction. thanks
UPDATE1:

deleted all the content from ~/.altcoin/ except altcoin.conf
launched ./altcoind
issued ./altcoind setgenerate true 4

at this point I figured out ./altcoind starts up without complaining about stake modifier though everytime I want to restart I have to delete the contents of ~/.altcoin/ otherwise error pops up.
output of debug.log:
AltCoin version v0.5.4.0-unk-beta ()
Default data directory /root/.thecoin
Loading addresses...
dbenv.open LogDir=/root/.altcoin/database ErrorFile=/root/.altcoin/db.log
Loaded 0 addresses
 addresses                30ms
Loading block index...
AltCoin Network: genesis=0x00000000324a1b505ecd nBitsLimit=0x1d00ffff nBitsInitial=0x1c00ffff nStakeMinAge=604800 nCoinbaseMaturity=500     nModifierInterval=21600
00000000324a1b505ecd77b793658f4fa6cd386653fdabd7d1c66907177174d6
00000000324a1b505ecd77b793658f4fa6cd386653fdabd7d1c66907177174d6
d8098e7eb449eed16c09fd7c97dec2acd1ec386ced36cf970a05c92fc2c0a05b
CBlock(hash=00000000324a1b505ecd, ver=1, hashPrevBlock=00000000000000000000, hashMerkleRoot=d8098e7eb4, nTime=1508926967, nBits=1d00ffff, nNonce=2600258680, vtx=1, vchBlockSig=)
  Coinbase(hash=d8098e7eb4, nTime=1508926967, ver=1, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(0000000000, -1), coinbase 04ffff001d020f274c4c205468652045636f6e6f6d697374202d2054686520626f79636f7474206f662051617461722069732068757274696e672069747320656e666f7263657273202d204f63742031392032303137)
    CTxOut(empty)
  vMerkleTree: d8098e7eb4
SetBestChain: new best=00000000324a1b505ecd  height=0  trust=1  moneysupply=0.00
 Upgrade Info: v0.5+ txdb initialization
ResetSyncCheckpoint: pending for sync-checkpoint ab0dad4b10d2370f009ed6df6effca1ba42f01d5070d6b30afeedf6463fbe7a2
ResetSyncCheckpoint: sync-checkpoint reset to 00000000324a1b505ecd77b793658f4fa6cd386653fdabd7d1c66907177174d6
 Upgrade Info: no txdb upgrade v0.3->v0.4 detected.
 Upgrade Info: v0.5+ no txdb upgrade detected.
 block index               4ms
Loading wallet...
nFileVersion = 60300
Performing wallet upgrade to 60000
keypool added key 1, size=1
keypool added key 2, size=2
keypool added key 3, size=3
...
...
keypool added key 101, size=101
keypool reserve 1
keypool keep 1
 wallet                  755ms
Done loading
mapBlockIndex.size() = 1
nBestHeight = 0
setKeyPool.size() = 100
mapWallet.size() = 0
mapAddressBook.size() = 1
Bound to port 11111
Added 1.1.1.90:11111 from 127.0.0.1: 0 tried, 1 new
Added 1.1.1.1:11111 from 127.0.0.1: 0 tried, 2 new
ThreadRPCServer started
ipv4 venet0: 127.0.0.1
ipv4 venet0:0: 2.2.2.62
addrLocalHost = 2.2.2.62:11111
IRC seeding/communication disabled
ThreadSocketHandler started
ThreadOpenAddedConnections started
trying connection 1.1.1.90:11111 lastseen=-391515.5hrs
ThreadOpenConnections started
ThreadMessageHandler started
ThreadStakeMinter started
CPUMiner started for proof-of-stake
ThreadDNSAddressSeed started
Loading addresses from DNS seeds (could take a while)
Added 9 addresses from 0:0:0:0:0:0:0:0: 0 tried, 11 new
connected 1.1.1.90:11111
Added time data, samples 2, offset +0 (+0 minutes)
Moving 1.1.1.90:11111 to tried
version message: version 60006, blocks=0
getblocks -1 to 00000000000000000000 limit 500
trying connection 1.1.1.9:11111 lastseen=-391515.5hrs
Added 13 addresses from 1.1.1.90: 1 tried, 23 new
GetMyExternalIP() received [2.2.2.62] 2.2.2.62:0
GetMyExternalIP() returned 2.2.2.62
connected 198.143.186.9:11111
Added 21 addresses from 0:0:0:0:0:0:0:0: 1 tried, 44 new
...
...
2017-10-31 13:15:58 UTC Flushing wallet.dat
...
4 processors
Starting 4 BitcoinMiner threads
CPUMiner started for proof-of-work
CPUMiner started for proof-of-work
CPUMiner started for proof-of-work
CPUMiner started for proof-of-work
...
...
ThreadRPCServer method=getmininginfo

despite it is up and running and both nodes are connected to eachother, outputs of ./altcoind getinfo and ./altcoind getmininginfo are still the same.
UPDATE 2

removed all hard checkpoints from kernel.cpp link
added ( 0, 0x0000000000000000 )
// Hard checkpoints of stake modifiers to ensure they are deterministic
static std::map mapStakeModifierCheckpoints =
boost::assign::map_list_of
  ( 0, 0x0000000000000000 )
//    ( 0, 0x0e00670bu )
//    ( 19080, 0xad4e4d29u )
//    ( 30583, 0xdc7bf136u )
//    ( 99999, 0xf555cfd2u )
//    (219999, 0x91b7444du )
;
recompiled
removed all the contents of ~/.altcoin/ folder
added altcoin.conf
launched ./altcoind
issued ./altcoind getinfo - output is still the same
issues ./altcoind setgenerate true 4 -
debug.log output is the same as previously
issued ./altcoind stop
launched ./altcoind

at this point I it failed again with the same error message
AltCoin Network: genesis=0x00000000324a1b505ecd nBitsLimit=0x1d00ffff nBitsInitial=0x1c00ffff nStakeMinAge=604800 nCoinbaseMaturity=500 nModifierInterval=21600
ERROR: CTxDB::LoadBlockIndex() : Failed stake modifier checkpoint height=0, modifier=0x0000000000000000

I have also removed all checkpoints beside (0, genesisBlock) from checkpoints.cpp and recompile it again... still the same problem...

Is https://github.com/mammix2/boostcoin-core your source code or something you forked from?

I forked peercoin master0.5 link . Since it is for educational purposes, I did not submit code to GitHub or anywhere else, Let me know what you need and I will provide it via pastebin

I just have added UPDATE 1 in the main block

It is not altcoin forum

I have added UPDATE 2 in the main block which covers some of the kernel.cpp changes advised by @AndrewChow

It looks like you did not change the stake modifier checkpoints which are found here: https://github.com/peercoin/peercoin/blob/master-0.5/src/kernel.cpp#L40. You will need to change these stake modifier checkpoints to match the stake modifiers of your checkpoint blocks.
If you don't want to check those checkpoints, you can just change this function: https://github.com/peercoin/peercoin/blob/master-0.5/src/kernel.cpp#L508 to always return true. That should "fix" this problem that you are experiencing.

I did that. See my comment above.

a snippet of checkpoints.cpp file

I didn't see your comment. I have updated my answer

since there are no blocks apart from genesis, where do I find one?

Just remove all of the modifiers for heights other than 0 and change the one for 0 to be whatever the stake modifier for your genesis block is.

I got the following output AltCoin Network: genesis=0x00000000324a1b505ecd nBitsLimit=0x1d00ffff nBitsInitial=0x1c00ffff nStakeMinAge=604800 nCoinbaseMaturity=500 nModifierInterval=21600 ERROR: CTxDB::LoadBlockIndex() : Failed stake modifier checkpoint height=0, modifier=0x0000000000000000 can it be that modifier is modifier=0x0000000000000000? otherwise, please advise where should I search for it. Thanks.

I gave it a try as per your last update... still the same outcome...

I updated my answer again.

Thanks a ton. I will give it a try but what in case I want to use checkpoints later? Can those be safely enabled at the later stage ?

If you want to use checkpoints later then you will have to add back in that function and set the checkpoints map properly. I'm guessing that you are not setting it properly (stake modifier is probably wrong) so it isn't working. I don't know what the correct value for your genesis block is.

Let us continue this discussion in chat.

You should find the correct modifier to use for block 0 by using getblock of your genesis hash
getblock 00000000324a1b505ecd77b793658f4fa6cd386653fdabd7d1c66907177174d6

authors: Григорий Косолапов


text:
Help with Coinbase? Confused BCC address with BTC one
As a newbie a friend who owed me some money suggested I get Coinbase and let him pay me in bitcoin.  I got the address but didn’t realize I got the address to my BCC wallet instead of bitcoin wallet.  It is quite a lot of money and I have no idea what to do.  Am i just out of luck?  Thanks a lot for any help.

He did send it.  Here is the address.  1Pb8E4VMy2zfCJST3FJNUJ41J1Kn9YovpE.  Is there a way to see where the coin is?  It’s 8500 dollars.

You are at Coinbase's mercy. Coinbase has the funds now. Ask their support nicely if they can recover it for you, I'm sure a deal can be made.

Did he actually send you the bitcoins to the BCC address? If yes, and the transaction has been sent to the blockchain, then you are indeed out of luck and can't recover that.
Sorry!

Coinbase probably have that address, try contacting their support


text:
Does Bitfinex support B2X? Will BTC holders at the moment of the fork be credited B2X on a 1:1 ratio?
I know, we should hold them in cold storage, etc, but I can't know for sure whether Bitfinex will credit the B2X on a 1:1 ratio for BTC holders.
Thank you for your answers!
David

Most exchanges will not credit you the same day but make you wait a certain amount of time. Your best bet is to withdraw and extract it yourself if you want 2x coins quickly.

There's no 2X fork anymore now, since it has been called off


text:
Unusual Version Number in Blocks
I've noticed recently that some blocks contain version numbers that are not the traditional 0x10000000 or 0x20000000.
For example, this block, has a version number of 0x3FFFE000 instead of 0x20000000 like the previous block has.
From my understanding this will not affect the actual hash digest, since it will produce a valid hash regardless of what the version field is.
A quick search on the forum did not return any results, but I am going to take a slight guess that this has something to do with miner voting to show what the consensus is for a future change? If this is the case, does it really make sense due to mining pools being a majority of hash power anyways? (Instead of miners votes individually)
If my prediction is correct, is there some list that defines which proposal coordinates to a given version number?
Thanks

but I am going to take a slight guess that this has something to do with miner voting to show what the consensus is for a future change?

No. There are currently no active consensus change proposals.

These version numbers are likely due to a mining optimization known as ASICBOOST. This optimization is due to a quirk of SHA256 and Bitcoin's block header format.
ASICBOOST is a hardware level optimization for mining chips that allows them to be more power efficient. One of the methods for ASICBOOST is to modify the block version number. The other method is to change only the first 4 bytes of the merkle root, but that requires much more computation than just changing the version number.
Even though this is a hardware optimization, the software for ASICBOOST miners also need to be aware of this optimization. This is why only some pools produce these ASICBOOST blocks, and only some machines can be used to produce them.
For more information about how ASICBOOST works, see How does AsicBoost work?


text:
Differentiating Output Script (scriptPubKey) Types
I am working on a little script to breakdown the data inside coinbase transactions. This is largely to improve my understanding of legacy and SegWit transactions (Given coinbase transactions have less data than for example a multisig TX, it is easier for me to work through).
One thing I've noticed about these transactions is differences in the output scripts. The Bitcoin RPC API works pretty well in decoding them, though I would like to know how to do it without an external tool.
I am aware that there are different types such as P2PKH, P2SH, and P2PK. However, what I do not know is how to differentiate them only given the raw hexadecimal representation.
For example this transaction has two output scripts:
76A91494155788E7233D7BEA9AA29FEB2ED37BC878C40B88AC

and
6A24AA21A9ED7387872912D999B657F4146043675D84B9BBCF66AD5DEC8BCC14117E4FB6999E

The RPC API tells me the first one has the type pubkeyhash with a P2SH value of 3EstC3Hhe8zvNGP73oX9oDvo36sNCygjJi
The second output script appears to be random data which cannot be decoded. (I've also seen many coinbase transactions have one readable output and one or more output that cannot be decoded).
Another example, The genesis block coinbase transaction decoded by the RPC API has the type pubkey with this script:
4104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac

Question: How can I take this output script and determine the type of transaction and the assembly (OP script code) of it without external APIs?
Thank you!

As I was writing this I stumbled upon this image which implies that the scriptPubKeys follow a standardized format, can someone confirm it is accurate? Thanks again!

thx for linking one of my older pics from 2016 :-) meanwhile things had changed, especially the multisig was not clear enough. I attach an updated version here. I didn't have the time to put newest SegWit related things into the pic though...
Still happy to see other opinions ...

Thanks man! I ended up figuring out most of the information I needed once I reviewed your picture. One other question I figured I'd ask. I know with the adoption of segregated witness there has been some degree of backwards compatibility with P2SH. Though, I have also heard people mention P2SH-P2WSH, P2WSH, P2WPKH, and P2SH-P2WPKH. Would you happen to know what differences there are in these versions, if any? Or perhaps a thread that might share the details? Regardless, thanks for this! PS: I'd love to upvote this too, but I don't have enough reputation yet :(

I haven't seen any "prepared" stuff for easy usage, so my reference is currently here: https://en.bitcoinwiki.org/wiki/Segregated_Witness - with the links at the bottom to BIPs and the Wallet Development Guide.

Bitcoin core just rolled out descriptor wallet implementation (PR here). Descriptors are modeled as functions. They take input a public key, and return the corresponding scriptPubKey,describing its spending conditions in engineer-readable format. For example, sh(wpkh(03fff97bd5755eeea420453a14355235d382f6472f8568a18b2f057a1460297556)) describes a P2SH-P2WPKH output with the specified public key.
You can refer to this doc for more details.
achow101 also gave a great talk (15 min) to explain this idea in details.


text:
Variables in Coinbase Transaction & Decoding I/O Scripts
I just have a few questions to help better my understanding of the coinbase transaction.
Example:
01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000

From what I know currently, the format of the coinbase transaction typically looks something like this when decoded:
TX Version:         01000000
# of Inputs:        01
Previous TX Hash:   0000000000000000000000000000000000000000000000000000000000000000
Previous Index:     FFFFFFFF
Input Script Len:   4D
Input Script:       04FFFF001D0104455468652054696D65732030332F4A616E2F32303039204368616E63656C6C6F72206F6E206272696E6B206F66207365636F6E64206261696C6F757420666F722062616E6B73
Input Sequence:     FFFFFFFF
# of Outputs:       01
Output Value (Sat): 00F2052A01000000
Output Script Len:  43
Output Script:      4104678AFDB0FE5548271967F1A67130B7105CD6A828E03909A67962E0EA1F61DEB649F6BC3F4CEF38C4F35504E51EC112DE5C384DF7BA0B8D578A4C702B6BF11D5FAC
Lock Time:          00000000

My first question:
What exactly is the "Previous Index" and why is the value of it FFFFFFFF and not 00000000? Since the previous transaction doesn't exist, shouldn't it be 0 just like the previous hash?
Second question:
From my understanding, the input script contains arbitrary data chosen by the miner when constructing the coinbase transaction and can typically be decoded into ASCII.
For example, this example input script (genesis block) decodes into ASCII as:
ÿÿEThe Times 03/Jan/2009 Chancellor on brink of second bailout for banks

Is this correct? And is this also used when the nonce overflows as an 'extraNonce'?
Third question:
What is the input sequence? Why is it always 0xFFFFFFFF when the locktime is 0x00000000?
Final question (I promise):
What data is stored in the output script, and how can it be broken down to be decoded?
Thank you!

What exactly is the "Previous Index" and why is the value of it FFFFFFFF and not 00000000? Since the previous transaction doesn't exist, shouldn't it be 0 just like the previous hash?

Coinbase transactions must have index FFFFFFFF, which is -1.

From my understanding, the input script contains arbitrary data chosen by the miner when constructing the coinbase transaction and can typically be decoded into ASCII.
For example, this example input script (genesis block) decodes into ASCII as:
ÿÿEThe Times 03/Jan/2009 Chancellor on brink of second bailout for banks

Is this correct? And is this also used when the nonce overflows as an 'extraNonce'?

Yes, it is exactly ÿÿEThe Times 03/Jan/2009 Chancellor on brink of second bailout for banks. Any part of coinbase can be used as the extranonce.

What is the input sequence? Why is it always 0xFFFFFFFF when the locktime is 0x00000000?

See this for details

What data is stored in the output script, and how can it be broken down to be decoded?

It is a pay-to-pubkey output.
41 Push 65 bytes
04678AFDB0FE5548271967F1A67130B7105CD6A828E03909A67962E0EA1F61DEB649F6BC3F4CEF38C4F35504E51EC112DE5C384DF7BA0B8D578A4C702B6BF11D5F Satoshi's public key
AC OP_CHECKSIG

Thanks! Maybe this deserves a different question, but it appears that newer block coinbase transactions have their version as "02000000" indicating version 2. From what I read here this was implemented in BIP34. However instead of the Version+NumberOfInputs+PreviousTXHash There appear to be extra fields. This block for example, Has the version first, and then 3 bytes of something I cannot identify. Do you know what these are?

BIP34 added the requirement that the coinbase scriptSig must start with a push of the block height.


text:
How do I Derive Bech32 Address from P2WPKH Output Script?
I am building a small script to decode the raw coinbase transaction data into a human-readable viewer without external scripts to better my understanding around the subject.
I've noticed that there are many different types of output script types among transactions. (P2SH, P2PK (as seen in genesis block), P2PKH, etc)
One thing I have not been able to grasp is how to obtain the Base58 address in the new SegWit P2WPK and P2WSH types.
For example, Block #542748 has this coinbase transaction which my script determines to have a pay to witness public key (P2WPK) output with 97cfc76442fe717f2a3f0cc9c175f7561b661997 as the public key hash.
The full output script: 0[] PUSHDATA(20)[97cfc76442fe717f2a3f0cc9c175f7561b661997]

Traditionally, in P2PK, P2PKH and P2SH I've used the image on this thread which works quite well.
When I apply the same method as the pubkeyhash (P2PKH) with the following operations I get a totally different address:
Append version byte:
0097CFC76442FE717F2A3F0CC9C175F7561B661997
SHA-256 Round 1:
f756795a3b878d16bfa9e426a47d857830bb08a02e691f0487cbeac51b510f40
SHA-256 Digest of Round 1:
ea7fe8c3b7680b79ff507c7d1b40bfc29ca8269bb1033cc84010506743cce404
Append checksum 4 bytes: 0097CFC76442FE717F2A3F0CC9C175F7561B661997ea7fe8c3
Base58 Encode: 1EqhwhM5t5NxedLoSuJ6BtBvUMLhanBLxa
This is quite different than bc1qjl8uwezzlech723lpnyuza0h2cdkvxvh54v3dn which is listed on blockchain.info's website here
What's the best way to obtain the same address they have listed (starting with bc1)?

Possible duplicate of How to create a Bech32 address from a public key?

Okay so I think I've figured it out for anyone else wondering what exactly you have to do to derive an address from this type.
In the case of the already mentioned transaction, (coinbase of block 542748) we first start by looking at the full decoded output script.
0 PUSHDATA(20) 97cfc76442fe717f2a3f0cc9c175f7561b661997

The very first OP_0 in the decoded script is the witness version
We then take the data pushed (in our case 97cfc76442fe717f2a3f0cc9c175f7561b661997) and convert it into binary
Then we divide the binary into 5 bit sections. In our case: 10010 11111 00111 11100 01110 11001 00010 00010 11111 11001 11000 10111 11110 01010 10001 11111 00001 10011 00100 11100 00010 11101 01111 10111 01010 11000 01101 10110 01100 00110 01100 10111
Then we prefix the witness version in 5 bits 00000
Our binary then becomes 00000 10010 11111 00111 11100 01110 11001 00010 00010 11111 11001 11000 10111 11110 01010 10001 11111 00001 10011 00100 11100 00010 11101 01111 10111 01010 11000 01101 10110 01100 00110 01100 10111
The first part of the address is considered the human readable portion.
This is always bc on the mainnet and tb on the testnet
1 is always the seperator between the human readable portion and the rest or data
Now our address starts with bc1 (mainnet is bc + seperator 1)
Now we map each 5 bits into the table here - or this alternative chart I've created
bc1 qjl8uwezzlech723lpnyuza0h2cdkvxvh
The remaining 6 characters is a checksum
Using the provided python code here we can compute the checksum using the bech32_create_checksum function
The first argument is the human readable portion as a STRING without the seperator (1)
The second argument is an array of integers converted from our binary data portion

Our example:
bech32_create_checksum("bc", [0, 18, 31, 7, 28, 14, 25, 2, 2, 31, 25, 24, 23, 30, 10, 17, 31, 1, 19, 4, 28, 2, 29, 15, 23, 10, 24, 13, 22, 12, 6, 12, 23] )

This gives us:
[20, 21, 12, 17, 13, 19]

Which can be mapped with our table to 54v3dn
Finally, we concatenate the human readable, seperator, decoded data, and the checksum for our final address: bc1qjl8uwezzlech723lpnyuza0h2cdkvxvh54v3dn

Good job answering your own question. You can cross reference with code for this available at https://github.com/sipa/bech32


text:
Failed to start lnd.service: Unit bitcoind.service not found. (lnd installation)

I installed my bitcoind and lnd correctly.
I put my datadir=/mnt/vdb to bitcoind.conf file and it allows me to start bitcoind with this command: bitcoind -daemon.
As a final step, I want to learn lnd
sudo service lnd start

Failed to start lnd.service: Unit bitcoind.service not found.

For me, I don't understand why it can't find bitcoind.service since I could run bitcoind without --datadir parameter.
How do I fix this error?

Starting a service by hand doesn't mean that it has the proper init.d or systemd config files in place that it could be started with the service command.  In this case it looks like lnd was setup to assume that bitcoind was also a systemd service so it can make sure it is started first.  If you can't start bitcoind with the service command then something is missing.

Maybe you didn't install bitcoind correctly and didn't realize it.  Look at the files that were installed and see if anything got put into /usr/lib/systemd/system/unit or /etc/systemd/system/unit.d/ directories.
Or lnd has expectations that have drifted from what bitcoind is providing over some period of time.  The "easy" work around is to modify the systemd config for lnd to no longer try to start bitcoind.


text:
Sending P2SH transaction with non-standard script
I'm trying to send transaction with script:
ScriptSig: OP_PUSHDATA<Sig> OP_PUSHDATA<Data1> OP_PUSHDATA<Data2> OP_PUSHDATA<Data3> OP_PUSHDATA<RedeemScript>
Since the data is less than 75 bytes in the raw transaction performed direct pushes.
RedeemScript: 2OP_DROP OP_2DROP OP_PUSHDATA<PubKey> OP_CHECKSIG
RedeemScriptHash160 of 6d6d2202ada9884dbd1e8bd90968ba66256f017cd77d83595027f7929ae3537f98c92d4aac=738292fc46dd7af803bd56035d0988af96a31681
ScriptPubKey: OP_HASH160 <redeemScriptHash> OP_EQUAL
But I get error when sending raw transaction:

code=-26, message=16: mandatory-script-verify-flag-failed (Script
  evaluated without error but finished with a false/empty top stack
  element)

Could someone help to understand what is wrong with that script?
This this my transaction:
020000000001012f15356f4dfb7f48a91a72f5ff1071f72cb5fe4acc29e98ff5ae17a008a01dba000000007C160014ac09dd336a6fc10034fc44dcb706855668921ce7141f8b0800ffc1765400038d78055c545df3ff5d4a141f8b0800ffc1765400038d78055c545df3ff5d4a141f8b0800ffc1765400038d78055c545df3ff5d4a246d6d2202ada9884dbd1e8bd90968ba66246f017cd77d83595027f7929ae3537f98c92d4aacffffffff01c005d9010000000017a914738292fc46dd7af803bd56035d0988af96a3168187024830450221009108d4e65a34fb50cd3283b6386a679f0dfc2b5fe97e3b3c3f6b8320814b3a2902204631daf2bb93605c9e079750092f304966b69fe28ce7701f4bc677714bca23af012102ada9884dbd1e8bd90968ba66256f017cd77d83595027f7929ae3537f98c92d4a00000000

{
  "result": {
    "txid": "441cf52028ee0acc8b4076681c7fd46dad03501be62c6b0050ca59090fa52973",
    "hash": "dad2b4c56556b74d87243149ca3384ce04584d3bd8d21d80e291c4f9eed7e3f8",
    "version": 2,
    "size": 317,
    "vsize": 235,
    "locktime": 0,
    "vin": [
      {
        "txid": "ba1da008a017aef58fe929cc4afeb52cf77110fff5721aa9487ffb4d6f35152f",
        "vout": 0,
        "scriptSig": {
          "asm": "0014ac09dd336a6fc10034fc44dcb706855668921ce7 1f8b0800ffc1765400038d78055c545df3ff5d4a 1f8b0800ffc1765400038d78055c545df3ff5d4a 1f8b0800ffc1765400038d78055c545df3ff5d4a 6d6d2202ada9884dbd1e8bd90968ba66246f017cd77d83595027f7929ae3537f98c92d4a OP_CHECKSIG",
          "hex": "160014ac09dd336a6fc10034fc44dcb706855668921ce7141f8b0800ffc1765400038d78055c545df3ff5d4a141f8b0800ffc1765400038d78055c545df3ff5d4a141f8b0800ffc1765400038d78055c545df3ff5d4a246d6d2202ada9884dbd1e8bd90968ba66246f017cd77d83595027f7929ae3537f98c92d4aac"
        },
        "txinwitness": [
          "30450221009108d4e65a34fb50cd3283b6386a679f0dfc2b5fe97e3b3c3f6b8320814b3a2902204631daf2bb93605c9e079750092f304966b69fe28ce7701f4bc677714bca23af01",
          "02ada9884dbd1e8bd90968ba66256f017cd77d83595027f7929ae3537f98c92d4a"
        ],
        "sequence": 4294967295
      }
    ],
    "vout": [
      {
        "value": 0.31,
        "n": 0,
        "scriptPubKey": {
          "asm": "OP_HASH160 738292fc46dd7af803bd56035d0988af96a31681 OP_EQUAL",
          "hex": "a914738292fc46dd7af803bd56035d0988af96a3168187",
          "reqSigs": 1,
          "type": "scripthash",
          "addresses": [
            "2N3mz7o8v3YT4arXdQ5p8So6q3FUGjhUpEE"
          ]
        }
      }
    ]
  },
  "error": null,
  "id": "curltext"
}

Before the redeem script is executed, the stack looks like this (from top to bottom): TRUE, Data3, Data2, Data1, Sig. The TRUE on top of the stack comes from OP_EQUAL.
Now the redeem script runs and you drop the top three elements from the stack and then add PubKey, leaving you with PubKey, Data1, Sig. When OP_CHECKSIG runs now it uses Data1 as Signature instead of Sig which makes it fail. At the end the stack is FALSE, Sig. The top element of the stack is FALSE which makes the transaction fail.

Thank you for your answer. Based on this, if I change OP_DROP on OP_2DROP this should resolve my problem but not.

Did you make a completly new transaction? Because if you change OP_DROP to OP_2DROP the hash of the redeem script will be different and thus OP_EQUAL will return FALSE if you reuse your old scriptPubKey with the updated redeem script.

Yes, I updated it, but after I read your comment =). Also, I updated the post with new raw transaction.

I found one more mistake in my raw transaction. There was OP_PUSHDATA<PubKey> together with OP_CHECKSIG. You helped to resolve my issue but I have new. When I'm sending that raw I get error mandatory-script-verify-flag-failed (Signature is found in scriptCode). Maybe you know what's wrong?

Sorry I also don't know what that means :( I suggest you make a new question with the new problem, maybe someone else knows whats wrong.


text:
online tool to play around with ECDSA public keys, message signature verification?
I realize that this question may be borderline bannable because it's asking for suggestions on tools, but it will really help newbies. This online tool allowed me to play around with hashes and to really understand them at a deeper level: http://www.fileformat.info/tool/hash.htm
I can't find a similar tool (that works) for ECDSA cryptography where I can play around with public and private keys, and do digital signatures on messages, and test signature verification.
I've found these 2 sites that claim to do this but didn't work for me:

http://dbis.rwth-aachen.de/~renzel/mobsos/lib/js/jsrsasign/sample-ecdsa.html
http://extranet.cryptomathic.com/ecc/index

Thoughts? Suggestions?

UPDATE: Great suggestions below. Some tools I found:
for hashing:
http://www.fileformat.info/tool/hash.htm
generating public private key pairs and decrypting ciphers:
https://8gwifi.org/rsafunctions.jsp
Generating EC public private key pairs and signing Verifying the Message
https://8gwifi.org/ecsignverify.jsp
generating public private key pairs and testing signing:
https://kjur.github.io/jsrsasign/sample/sample-ecdsa.html

For generating EC Keys https://8gwifi.org/ecfunctions.jsp

HDwallet Generator https://8gwifi.org/hdwallet.jsp

Here are a few I'd recommend:

https://bitcore.io/playground/#/address (private key - public key)
https://brainwalletx.github.io/#generator (signing and verifying but bitcoin specific)

Or play with pybitcointools at the command line (not online):
$ git clone https://github.com/vbuterin/pybitcointools.git
$ cd pybitcointools
$ python
>>> from bitcoin import *
>>> sk = random_key()  # Generate a private key
>>> vk = privtopub(sk) # Generate a public key
>>> msg = 'hello world' # Create a simple message
>>> sig = ecdsa_sign(msg, sk) # Sign the message using your private key
>>> print sig
GxXGAt...2L/eJk=
>>> print ecdsa_verify(msg, sig, vk) # Use sig and public key to verify
True
>>> msg = 'hello mars' # Change the message
>>> print ecdsa_verify(msg, sig, vk) # Changing the msg invalidates sig
False

http://showterm.io/203b168061b0156c4d1dd
HD Wallet stuff:

https://iancoleman.github.io/bip39/
http://bip32.org/

If you're looking to learn more about ECDSA suggest checking out: https://jeremykun.com/2014/02/08/introducing-elliptic-curves/

Question: In the first link (bitcore.io), they provide a private-public key pair, and an 'Address'. I presume the 'Address' is the SHA-256 hash of the public key. But when I try to hash the public key on this site (http://www.fileformat.info/tool/hash.htm) I don't get the same SHA-256 hash. Could you help me understand what the 'Address' is in that case?

Address creation is a bit more complicated. It's really a series of steps as shown here: http://gobittest.appspot.com/Address. Though there are two types (compressed vs. uncompressed) and I believe you will get different addresses if you use the gobittest vs. bitcore.

Using this private key: 2b1f14de0bc7b8d71a6409749e9e88d6e227c6516943713ed08448343722ae85
Bitcore generates: 1JmAEL8KbzVXFc15KUb9YXjgTop321WiC6
Gobittest generates: 1JsnjS7t8JW5CDi1UMwp6BSG2rJ3Xm94BF
For more see: https://github.com/bitcoin-bootcamp/bitcoin-exercises/tree/master/addresses
$ python address.py --secret '2b1...e85'
Bitcoin Address (Compressed): 1JmAEL8KbzVXFc15KUb9YXjgTop321WiC6
$ python address.py --secret '2b1...e85' --u
Bitcoin Address (Uncompressed): 1JsnjS7t8JW5CDi1UMwp6BSG2rJ3Xm94BF

Interesting - good to know. I thought a bitcoin address was simply the hash of a public key. Turns out it's more complicated.

closest I can come up with are these:
http://coinig.com/
http://gobittest.appspot.com/Address
https://www.bitaddress.org/bitaddress.org-v3.2.0-SHA256-ad4fd171c647772aa76d0ce828731b01ca586596275d43a94008766b758e8736.html
https://coinb.in/
not exactly ECDSA, but served me alot for Bitcoin undertsanding/testing.

Security hint: you would never provide/use a private key to/from such a public website, unless you are really sure of what you are
  doing. Be extremly careful.

The first link lets me verify a public key + message + signature combination. Do you know of some online site that will generate a signature given a private key and a message (just for playing around purposes of course -- your fair warning is very apt).

no, I don't know a webpage that provides this ... when I was playing with signatures, I used the command line: https://bitcoin.stackexchange.com/questions/46455/verifying-a-bitcoin-trx-on-the-unix-cmd-line-with-openssl

Here is an ECC calculator for the Secp256k1 curve that I'm programming in Java.
https://github.com/MrMaxweII/Secp256k1-Calculator

for build modern GUI swing you can use this library


text:
How to confirm that given bitcoin address is generated by given public key?
I have 10s of private and public keys associated with 10s of different addresses.
Now I have a test-net btc address "mfoxBS2TpoiUWrEV3sZopoEB6Pi2d7TE9N".
What operations can I perform to find the appropriate Public Key associated with given address?
UPDATE
I am not trying to find out reverse scenario of fetching a public key from address.
As I already have bunch of public keys. One of them have created the given address. And I just want to figure out which one is it from the whole bunch?

Possible duplicate of Is it possible to get the public key of a bitcoin address I do not have the private keys for with the standard client?

it's not duplicate. updated my question description.

There is a step-by-step guide here and you can also test it on this site.
You can also use this python library.
import os
os.environ['CRYPTOTOOLS_NETWORK'] = 'test'

from btctools import PublicKey

>>> pub = Publickey.from_hex('yourpubkeyhere')
>>> pub.to_address('P2PKH')
'mp9CpH3h25m7FZqsPBf2UfU9Gm4u41j9Eg'

Is there any way I can do this check by Java program or using Api?

There is a java library call bitcoinj that might be able to do this. Also there is this: https://bitcore.io/playground/#/address but I wouldn't trust any online service with a private key. It might be good enough for testnet though.

Your only option is to derive the address from each public key, and compare it with the address you have.