1 2016-01-01 00:19:33 <Lyth0s> hey sipa you still around
 2 2016-01-01 02:32:24 <kanzure> is it accurate to say that soft-forks could be decided by miners through out-of-band communication?
 3 2016-01-01 02:32:38 <sipa> i'd say no
 4 2016-01-01 02:32:41 <kanzure> (er, soft-fork activation)
 5 2016-01-01 02:32:54 <sipa> miners can out of band decide to enforce more rules than strictly demanded by the full node network
 6 2016-01-01 02:33:16 <kanzure> how is this different from soft-fork activation?
 7 2016-01-01 02:33:17 <sipa> but softforking is more than that: it's also letting (some) full nodes know they can start enforcing a new rule
 8 2016-01-01 02:33:42 <sipa> if you're just talking about miners enforcing an additional rule, they can also undo that without damage
 9 2016-01-01 02:33:55 <sipa> undoing an actual softfork that has full nodes enforcing it, requires a hardfork
10 2016-01-01 02:56:33 <Lyth0s_> hey sipa I didn't recongize that you were pieter wuille
11 2016-01-01 02:57:18 <sipa> :)
12 2016-01-01 02:57:49 <Lyth0s_> thanks for helping me out with the ideas around flops vs hashes yesterday
13 2016-01-01 02:57:57 <Lyth0s_> er a few days ago
14 2016-01-01 02:58:09 <sipa> yw :)
15 2016-01-01 02:58:12 <Lyth0s_> so how did you initially come up with the idea of SW?
16 2016-01-01 02:58:42 <Lyth0s_> like the first moment the idea spawned in your mind
17 2016-01-01 02:58:45 <sipa> Lyth0s_: many people involved; i mostly did fleshing out some details and implementation
18 2016-01-01 02:58:46 <Lyth0s_> first*
19 2016-01-01 02:59:01 <Lyth0s_> ah I see
20 2016-01-01 02:59:15 <sipa> Lyth0s_: elements alpha (a sidechain) has had segregated witness from the start, suggested by gmaxwell
21 2016-01-01 02:59:26 <sipa> Lyth0s_: Luke-Jr discovered it was possible through a soft fork
22 2016-01-01 02:59:53 <Lyth0s_> interesting
23 2016-01-01 03:00:05 <Lyth0s_> do you have a whitepaper for newbs that you suggest I read?
24 2016-01-01 03:00:08 <sipa> kanzure: so i'd say that the 'signaling' part of a softfork is not the actual fork; the fork is full nodes deciding to act on it
25 2016-01-01 03:00:19 <Lyth0s_> not full of technicals but the basic ideas
26 2016-01-01 03:00:24 <sipa> Lyth0s_: nope, too little time :)
27 2016-01-01 03:00:30 <sipa> though there are BIPs in progress
28 2016-01-01 03:00:42 <Lyth0s_> ok gotcha, stick with the important stuff then :D
29 2016-01-01 03:01:59 <kanzure> sipa: context was that someone was trying to convince me that pow decides soft-forks.... (reddit stuff)
30 2016-01-01 03:02:24 <Lyth0s_> I'm no expert, but miners rely on nodes
31 2016-01-01 03:02:36 <kanzure> i mean there's activation signaling and stuff, but that's not something computed by pow really.
32 2016-01-01 03:04:18 <Lyth0s_> nodes have to interpret soft fork information, so if they don't I dont think the miners blocks would be useful (for example with SW)
33 2016-01-01 03:04:23 <kanzure> it's off-topic but here's a link anyway https://www.reddit.com/r/Bitcoin/comments/3yyvmp/they_think_satoshi_was_wrong/cyhytbc?context=3
34 2016-01-01 03:04:38 <Lyth0s_> let me know if I'm wrong though
35 2016-01-01 05:26:13 <kenrestivo> who's pow?
36 2016-01-01 05:26:22 <kenrestivo> proof of work?
37 2016-01-01 05:43:40 <gentoognuhurd> kenrestivo: #bitcoin
38 2016-01-01 06:07:20 <kenrestivo> aye
39 2016-01-01 16:14:06 <kanzure> i think bip1 needs to be clarified, especially an emphasis on the responsibility of the bip author to figure out what the existing critiism is, and also to clear up the confusion (in the bip text itself) regarding what an initial email to bitcoin-dev is meant to be about (it says to gather feedback or see if anyone has heard of a similar idea before, but in practice what we get are people attempting to send entire bips)
40 2016-01-01 16:14:25 <kanzure> i'm not sure if these changes have been proposed before, and if they were then i definitely don't know what the feedback was :-)
41 2016-01-01 16:15:28 <kanzure> oh i should clarify that, specifically, the reason why i think there is this confusion is because bip1 is slightly ambiguous about the purpose of the initial email. it says "the best place to send the bip is the mailing list" but it also says a few other things about what the first email should ideally be.... and it's sort of contradictory in this aspect.
42 2016-01-01 16:54:22 <maaku> kanzure: yeah my understanding (and what I followed for 68/112/113) was that the initial email was -not- a bip draft but rather a general discussion of the concept
43 2016-01-01 16:54:44 <kanzure> if you read bip1 i think you'll agree with me that this is insufficiently clear
44 2016-01-01 17:00:14 <maaku> i do agree
45 2016-01-01 17:25:20 <kanzure> maaku: i am updating the text. i am confused about this line: "Once a BIP has been accepted, the reference implementation must be completed.". elsewhere it seemed more that an implementation must be provided in the first place.
46 2016-01-01 17:34:59 <Luke-Jr> kanzure: the Accepted status probably would be better named "Completed"
47 2016-01-01 17:35:12 <Luke-Jr> ie, the Draft is now Complete and ready for implementation and consideration
48 2016-01-01 17:35:33 <kanzure> i don't want to change the diagram thing
49 2016-01-01 17:36:32 <Luke-Jr> probably best to just do a BIP 2 IMO
50 2016-01-01 17:47:51 <kanzure> maaku: Luke-Jr: just posted https://github.com/bitcoin/bips/pull/269
51 2016-01-01 17:48:32 <Luke-Jr> kanzure: NACK any mention of Core
52 2016-01-01 17:48:40 <Luke-Jr> BIP is intentionally independent of any given project
53 2016-01-01 17:50:17 <kanzure> well it previously mentioned "Bitcoin issue tracker"........
54 2016-01-01 17:50:38 <Luke-Jr> well, I still think a BIP 2 would be appropriate :p
55 2016-01-01 17:51:12 <Luke-Jr> this is adding way too much already
56 2016-01-01 17:51:15 <kanzure> can you clarify your NACK regarding preference for "Bitcoin issue tracker" vs "Bitcoin Core issue tracker" ? perhaps removing the sentene is OK?
57 2016-01-01 17:51:20 <kanzure> *sentence
58 2016-01-01 17:51:37 <kanzure> i mean, it seems like a good idea to recommend "not making a BIP" especially when a BIP is unwarranted
59 2016-01-01 17:52:02 <Luke-Jr> kanzure: "relevant issue tracker" sounds like it would work
60 2016-01-01 17:52:10 <kanzure> Luke-Jr: would you ACK that ?
61 2016-01-01 17:52:29 <Luke-Jr> kanzure: I'd have to read over the diff first. GitHub displays it crappily
62 2016-01-01 17:52:44 <Luke-Jr> besides, it's genjix and/or gmaxwell that would need to ACK it..
63 2016-01-01 17:53:32 <kanzure> whatever, i think you are a good substitute, i'm sure they would have similar concerns
64 2016-01-01 20:22:05 <jl2012> how can I turn off *any* tx standardness check in bitcoin core? So the only thing I check is consensus rules?
65 2016-01-01 20:44:45 <phantomcircuit> jl2012, fRequireStandard
66 2016-01-01 20:45:02 <sipa> jl2012: and change the defaukt verification flags
67 2016-01-01 20:45:03 <petertodd> phantomcircuit: though that's still missing some non-consensus checks, like nValue != 0
68 2016-01-01 20:45:13 <sipa> and set the minimum relay to 0
69 2016-01-01 20:45:21 <sipa> and allow free relay
70 2016-01-01 20:45:30 <sipa> and set mempool limits to infinity
71 2016-01-01 20:45:40 <petertodd> and turn it up to 11
72 2016-01-01 20:46:39 <sipa> and set the max data carrier size to infinity
73 2016-01-01 20:47:00 <sipa> and then still a few policy rules that prevent oversized transactionsz high sigopd, ...