1 2015-12-26 02:02:06 <tg_> i am planning to use block.io bitcoin API to send and receive bitcoin amount for a web based game. very simple API usage.. is there any reason to go with something else than block.io?
 2 2015-12-26 02:02:44 <tg_> i am just asking to see if there is anything obvious in terms of what other people use that I am not aware of
 3 2015-12-26 02:13:05 <Luke-Jr> tg_: #bitcoin topic
 4 2015-12-26 02:29:21 <phantomcircuit> tg, use the bitcoin client api...
 5 2015-12-26 09:12:09 <maaku> CodeShark: I'm pretty sure your latest email regarding block withholding is incorrect
 6 2015-12-26 09:12:26 <CodeShark> howso?
 7 2015-12-26 09:12:45 <maaku> a block can display the actual difficulty, while the miner doesn''t know what difficulty a share is
 8 2015-12-26 09:13:54 <maaku> the pool picks a nonce, and the rule is H(header) must meet diff 1, and H(nonce || header) must meet declared difficulty
 9 2015-12-26 09:16:33 <CodeShark> if the whole point is to prevent miners from not submitting solved blocks to the pool what's important is to make it hard for the miner to know how close to the line separating shares from solved blocks he is
10 2015-12-26 09:17:20 <CodeShark> we can't reduce the difficulty as per the bits semantics without a hard fork
11 2015-12-26 09:18:30 <CodeShark> or at least I don't see how
12 2015-12-26 09:20:07 <CodeShark> the two-stage target mechanism changes the bit field semantics
13 2015-12-26 09:21:54 <CodeShark> in other words, to do this as a soft fork, H(header) must be at least as small as before
14 2015-12-26 09:22:58 <CodeShark> which means we can only increase difficulty further away from the line dividing shares from solved blocks
15 2015-12-26 09:23:22 <maaku> CodeShark: the hasher doesn't know nonce, so it doesn't know H(nonce || header)
16 2015-12-26 09:23:32 <CodeShark> yes, I understand
17 2015-12-26 09:23:40 <CodeShark> the problem is the first part of the conditional
18 2015-12-26 09:24:09 <maaku> H(header) > diff 1 is the definition of a share though
19 2015-12-26 09:24:48 <maaku> so the hasher has no information more than whether or not the header is a valid share
20 2015-12-26 09:25:23 <maaku> but the target difficulty of an actual block is not unknown or obscured
21 2015-12-26 09:25:40 <maaku> it' sjust that the hasher is not in a position to calculate it
22 2015-12-26 09:25:45 <CodeShark> ok, perhaps we're confusing terms here
23 2015-12-26 09:26:04 <CodeShark> there are two independent PoW checks that when combined give a known target difficulty
24 2015-12-26 09:26:13 <CodeShark> one is visible to the hasher, the other is not
25 2015-12-26 09:27:06 <CodeShark> in the current situation, the one that is not known to the hasher can be thought of as trivial - it's always satisfied
26 2015-12-26 09:28:22 <CodeShark> if we add a nontrivial unknown PoW check, to preserve the same total difficulty we must reduce the difficulty as per the bits semantics
27 2015-12-26 09:29:48 <CodeShark> I mean...blocks that did not satisfy the difficulty according to the bits semantics before might now satisfy it (assuming the unknown PoW test passes)
28 2015-12-26 09:30:36 <CodeShark> of course, the bits field can still encode the total difficulty
29 2015-12-26 09:30:58 <CodeShark> but now H(header) can be larger than it was allowed to be before
30 2015-12-26 09:31:11 <CodeShark> ergo, it's a hard fork
31 2015-12-26 09:33:44 <CodeShark> I might not have stated this very clearly
32 2015-12-26 09:39:28 <CodeShark> point is this feature is independent of the specifics of the scheme used to blind the hasher
33 2015-12-26 09:40:41 <CodeShark> a soft fork would require H(header) to be no larger than it could have been before for a given bits value
34 2015-12-26 09:42:35 <maaku> CodeShark: you could step down the v1 difficulty over time, moving it into v2 difficulty
35 2015-12-26 09:42:46 <maaku> it is possible to turn into a soft-fork, if that were really desired
36 2015-12-26 09:43:05 <CodeShark> not sure I follow
37 2015-12-26 09:43:57 <CodeShark> are you talking about something other than jl2012's suggestion?
38 2015-12-26 09:44:10 <maaku> I don't really know what jl2012's suggestion is
39 2015-12-26 09:44:16 <maaku> I'm following this from first principles
40 2015-12-26 09:44:39 <CodeShark> you step down the difficulty by artificially increasing block time interval
41 2015-12-26 09:45:07 <CodeShark> how else can you step down the difficulty over time?
42 2015-12-26 09:45:15 <maaku> oh you're worried about the diff adjustment algorithm? do spv nodes really verify that?
43 2015-12-26 09:45:41 <CodeShark> I'm not just talking about SPV nodes
44 2015-12-26 09:46:53 <CodeShark> if spv nodes do not really verify that then it could be deployed as an spv-compatible hard fork...in principle spv nodes should verify that
45 2015-12-26 09:47:16 <CodeShark> but my main concern is for full nodes
46 2015-12-26 09:55:06 <CodeShark> we cannot change CalculateNextWorkRequired and CheckProofOfWork to be more permissive (without changing their inputs)
47 2015-12-26 09:55:20 <CodeShark> and have a soft fork
48 2015-12-26 09:56:17 <CodeShark> Specifically, CheckProofOfWork would have to take an extra input not visible to the hasher
49 2015-12-26 10:20:54 <jl2012> maaku: this is my softfork idea for block withholding attack: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012051.html
50 2015-12-26 10:21:04 <jl2012> that's very inefficient
51 2015-12-26 10:47:58 <CodeShark> jl2012's idea can be summed up as follows (I think) - since we can't make PoW on headers (without requiring external data) less restrictive, we make it more restrictive but siphon off some of the extra difficulty for use in blinded PoW
52 2015-12-26 10:51:58 <jl2012> the header PoW still becomes less restrictive. With a constant hash rate, the main difficulty will become 1/16 after 10 years
53 2015-12-26 10:53:18 <CodeShark> well, the rest of the siphoned off difficulty is used to increase block interval which has the effect of making it less restrictive after the next retarget
54 2015-12-26 10:53:50 <jl2012> yes
55 2015-12-26 10:55:35 <CodeShark> but more restrictive over the present retarget period
56 2015-12-26 10:56:25 <CodeShark> We always must be more restrictive in the present than before
57 2015-12-26 11:02:29 <CodeShark> Before meaning before the soft fork
58 2015-12-26 15:52:55 <Mazer> HI, can anyone hellp with bitcoind setup?
59 2015-12-26 15:55:00 <haakonn> Mazer:  sounds like a question that is better suited in #bitcoin
60 2015-12-26 16:34:47 <jl2012> I'm rewriting the segwit address bip: https://github.com/jl2012/bips/blob/segwit-address2/bip-segwitaddress.mediawiki
61 2015-12-26 16:36:12 <jl2012> 2 new address types are proposed. One is Base58 encoded and is only for P2PKH segwit. The other one is Base32 with Damm algorithm and is for general witness program
62 2015-12-26 17:07:12 <haakonn> is it possible to temporarily ban matsjj? joining/quitting is creating a lot of noise
63 2015-12-26 17:50:39 <phantomcircuit> midnightmagic, ^
64 2015-12-26 18:02:59 <maaku> jl2012: for base32 consider using this alphabet : http://philzimmermann.com/docs/human-oriented-base-32-encoding.txt
65 2015-12-26 18:03:07 <maaku> (and direct quesitons about it to zooko)
66 2015-12-26 18:04:52 <maaku> jl2012: to save you time, here's the Damm table : http://0bin.net/paste/+ykp++5bK7leB8NU#RTGpYDmtXGCi1Pt5W5mou2MQ0jxFO3sfFExzN-Pi0Fl
67 2015-12-26 18:05:51 <maaku> and the code that generated it : http://0bin.net/paste/hbUsaHtTbEft8QIx#IbxElizsKTDYEG+YVoqmWQc89lrrrn3X71DlSRb2mLc
68 2015-12-26 18:09:25 <maaku> also, I look forward to all the "where's the Damm algorithm?" and "here's the Damm encoding" jokes
69 2015-12-26 18:12:22 <jl2012> thanks maaku. We can decide the character set later
70 2015-12-26 18:12:45 <jl2012> do you understand my example? Does it seem secure?
71 2015-12-26 18:13:47 <jl2012> for example, in the first round checksum, I calculate damm(BR000), damm(00000) ..... damm(XW25C)
72 2015-12-26 18:14:16 <jl2012> and the checksum is appended to the end of each segment
73 2015-12-26 18:15:02 <jl2012> then the second round is damm(B00E0UNERGX), damm(R00T8P7GVDW) .....
74 2015-12-26 18:15:17 <jl2012> and append the checksums to the end of the address
75 2015-12-26 18:16:13 <jl2012> maybe the "checksum of checksum" at the very end is not needed. Then it's 71 digits in total
76 2015-12-26 19:02:09 <dgenr8> http://www.the-wabe.com/notebook/second-system.html
77 2015-12-26 20:45:30 <sturles> BlueMatt: I'm usually there every year, but unfortunately not this year. :-(
78 2015-12-26 21:15:34 <Jdillinger> How can you make a big coin account
79 2015-12-26 21:16:32 <Jdillinger> How can you make a bitcoin account
80 2015-12-26 21:16:36 <haakonn> Jdillinger:  please ask in #bitcoin instead
81 2015-12-26 21:17:13 <Jdillinger> #bitcoin
82 2015-12-26 21:20:25 <Jdillinger> I'm  confuse
83 2015-12-26 21:21:01 <haakonn> Jdillinger:  to go to the #bitcoin chat room, type this:
84 2015-12-26 21:21:06 <haakonn> /join #bitcoin
85 2015-12-26 21:21:58 <Jdillinger> Join #bitcoin
86 2015-12-26 21:22:29 <haakonn> with a / (slash) in front