1 2016-01-19 01:03:56 <brand0> does anyone know if univalue has any documentation (besides the source code)?
  2 2016-01-19 04:09:40 <kanzure> Luke-Jr: probably better to move away from using the word "acceptance" for bip1/bip2 stuff
  3 2016-01-19 04:10:12 <Luke-Jr> I wish someone made a BIP outlining acceptance of different types of BIPs.. but the only guy trying (him) seems to be failing hard
  4 2016-01-19 04:10:17 <Luke-Jr> looks like we'll end up with a forever-draft or rejected BIP 2 :/
  5 2016-01-19 04:10:31 <Luke-Jr> kanzure: I don't understand that point
  6 2016-01-19 04:10:59 <kanzure> Luke-Jr: "acceptance" what is this even supposed to mean. i suspect this is a strong source of persistent ambiguity.
  7 2016-01-19 04:11:16 <kanzure> bip process cannot define/mandate "acceptance"
  8 2016-01-19 04:12:13 <Luke-Jr> kanzure: right now, BIPs change Draft->Accepted when the author decides he's done revising it, and Accepted->Final when the community adopts it
  9 2016-01-19 04:12:19 <Luke-Jr> the last step is what is poorly defined
 10 2016-01-19 04:12:37 <Luke-Jr> especially for thigns like BIP 123 etc
 11 2016-01-19 04:12:45 <kanzure> "accepted [for bip number assignment]" yea that's not what most people think acceptance means :-)
 12 2016-01-19 04:13:42 <Luke-Jr> kanzure: BIP assignment is before Draft :p
 13 2016-01-19 04:16:07 <oneeman> "finalized" is more intuitive than "accepted"
 14 2016-01-19 04:16:19 <oneeman> lol, nvm
 15 2016-01-19 04:16:22 <oneeman> sorry
 16 2016-01-19 04:42:40 <adnn> https://www.reddit.com/r/btc/comments/41lpir/segwit_economics/ -- gavin's new conpiracy theory on why segwit is soft fork
 17 2016-01-19 05:29:10 <moa> adnn: odd that he's delved into a detailed economics analysis of SW that increases data handled by 175-200% and never bothered to do the same when proposed to increase data capacities by 2000%
 18 2016-01-19 05:31:09 <aj> moa: peterr did detailed economics analysis of massive bumps in the blocksize though
 19 2016-01-19 05:31:32 <aj> moa: level of insight is certainly arguable, but it was there
 20 2016-01-19 05:32:02 <moa> sorry, but that was a bunch of hokum, imho.
 21 2016-01-19 05:36:39 <aj> moa: sure, point is just that analysis was done. (i wouldn't say that segwit fee event etc analysis was any better than peterr's paper, for instance)
 22 2016-01-19 05:38:59 <moa> ha, right.
 23 2016-01-19 13:55:53 <aschildbach> Hi there, I've got a question about segwit. Looking at BIP144, I wonder if the "witness structure" (as part of the tx message serialization) has already been defined.
 24 2016-01-19 13:56:48 <aschildbach> I wonder specifically if the new tx messages will contain input values, rather than just a reference to the output.
 25 2016-01-19 13:56:49 <aschildbach> I wonder specifically if the new tx messages will contain input values, rather than just a reference to the output.
 26 2016-01-19 14:00:51 <Ylbam> aschildbach: have you tried #segwit-dev ?
 27 2016-01-19 14:01:21 <aschildbach> uh there is a new channel for that?
 28 2016-01-19 14:01:30 <Ylbam> yep
 29 2016-01-19 14:01:42 <aschildbach> thanks
 30 2016-01-19 14:03:42 <Ylbam> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012253.html
 31 2016-01-19 14:42:41 <jonasschnelli> How long would a possible hardfork (assume march 2016) delay a possible segwit softfork? Until supermajority of the hardfork?
 32 2016-01-19 14:42:42 <jonasschnelli> How long would a possible hardfork (assume march 2016) delay a possible segwit softfork? Until supermajority of the hardfork?
 33 2016-01-19 14:47:07 <bsm1175321> adnn: I really like that notion that in the new protocol (segwit) transactions are cheaper.  It gives an economic incentive to upgrade.
 34 2016-01-19 14:47:08 <bsm1175321> adnn: I really like that notion that in the new protocol (segwit) transactions are cheaper.  It gives an economic incentive to upgrade.
 35 2016-01-19 15:41:15 <Yoghur114> hey guys, one of my nodes has stalled at #393974 - and I can't figure out why. It's dishing out a lot of invalid header received errors, and appears to be refusing to connect to peers - I got it to connect to another node which I know is synced to the tip, though, but it isn't syncing w"
 36 2016-01-19 15:41:28 <Yoghur114> ... also getting the "WARNING: check your network connection, 0 blocks received in the last 4 hours (24 expected)" thing
 37 2016-01-19 15:43:21 <Yoghur114> would someone be willing/able to help out privately with a bunch of logs?
 38 2016-01-19 15:46:26 <Yoghur114> hmm ... peers with "synced_headers" : -1, (same for synced_blocks), what does that mean?
 39 2016-01-19 15:46:27 <Yoghur114> hmm ... peers with "synced_headers" : -1, (same for synced_blocks), what does that mean?
 40 2016-01-19 15:51:30 <bsm117532> Yoghur114: Have you done a reindex?
 41 2016-01-19 15:51:31 <bsm117532> Yoghur114: Have you done a reindex?
 42 2016-01-19 15:59:20 <Yoghur114> no - I got it to sync now, after doing a -reconsiderblock for 393973 (..) and restarting (previous restarts did nothing) -- pretty weird still, don't know why it stalled
 43 2016-01-19 16:11:17 <instagibbs> what OS you running? (just curious)
 44 2016-01-19 16:13:23 <Yoghur114> Ubuntu 14.04.3 LTS
 45 2016-01-19 16:14:42 <Yoghur114> the logs don't go back to the moment it first stalled, but it looks like it started banning peers for submitting blocks it perceived as invalid =/
 46 2016-01-19 16:14:43 <Yoghur114> the logs don't go back to the moment it first stalled, but it looks like it started banning peers for submitting blocks it perceived as invalid =/
 47 2016-01-19 16:16:25 <Yoghur114> ie.
 48 2016-01-19 16:16:26 <Yoghur114> ie.
 49 2016-01-19 16:16:27 <Yoghur114> 2016-01-19 12:15:07 ERROR: AcceptBlockHeader: prev block invalid
 50 2016-01-19 16:16:28 <Yoghur114> 2016-01-19 12:15:07 Misbehaving: 120.26.124.58:8333 (0 -> 100) BAN THRESHOLD EXCEEDED
 51 2016-01-19 16:16:29 <Yoghur114> 2016-01-19 12:15:07 Misbehaving: 120.26.124.58:8333 (0 -> 100) BAN THRESHOLD EXCEEDED
 52 2016-01-19 16:16:30 <Yoghur114> 2016-01-19 12:15:07 ERROR: invalid header received
 53 2016-01-19 16:16:57 <gijensen> That's something new to me o.o
 54 2016-01-19 16:17:28 <Yoghur114> yeah..
 55 2016-01-19 16:17:37 <pigeons> what bitcoin version
 56 2016-01-19 16:18:29 <pigeons> oh its working now, ok good
 57 2016-01-19 16:18:59 <Yoghur114> 11.2, with the addrindex patch - https://github.com/btcdrak/bitcoin/tree/addrindex-0.11
 58 2016-01-19 16:19:00 <Yoghur114> 11.2, with the addrindex patch - https://github.com/btcdrak/bitcoin/tree/addrindex-0.11
 59 2016-01-19 16:52:43 <bsm117532> Yoghur114: I'd suspect your hardware.  Run a memcheck and some CPU tests.  A single bit flip in a sha256 calculation or ECDSA sig verification can cause this.
 60 2016-01-19 20:29:14 <BW^-> libsecp256k1 build fails with "make: don't know how to make gen_context.o (prerequisite of: gen_context)", any idea?
 61 2016-01-19 20:30:23 <paveljanik> BW^-, what compiler?
 62 2016-01-19 20:30:24 <sipa> from within bitcoin, or outside?
 63 2016-01-19 20:30:25 <sipa> from within bitcoin, or outside?
 64 2016-01-19 20:30:37 <paveljanik> -I.? ;-)
 65 2016-01-19 20:31:15 <BW^-> paveljanik: "g++ (GCC) 4.2.1 20070719" and "eg++ (GCC) 4.8.4"
 66 2016-01-19 20:31:16 <BW^-> paveljanik: "g++ (GCC) 4.2.1 20070719" and "eg++ (GCC) 4.8.4"
 67 2016-01-19 20:31:44 <BW^-> sipa: outside.  it's the https://github.com/libbitcoin/secp256k1/tree/version4 distro
 68 2016-01-19 20:31:56 <paveljanik> can you paste the command line used to compile it?
 69 2016-01-19 20:32:06 <sipa> BW^-: ask the libbitcoin people then
 70 2016-01-19 20:32:21 <BW^-> mhm
 71 2016-01-19 20:33:00 <paveljanik> BW^- what OS?
 72 2016-01-19 20:33:12 <paveljanik> can you paste make output somewhere?
 73 2016-01-19 20:34:57 <BW^-> paveljanik: sec, i'm rebuilding to get the best conclusions for you :))
 74 2016-01-19 20:43:27 <BW^-> paveljanik: ah - the first error i spotted was that the build script I used used "make" whereas it's called "gmake" on my system
 75 2016-01-19 20:43:28 <BW^-> paveljanik: ah - the first error i spotted was that the build script I used used "make" whereas it's called "gmake" on my system
 76 2016-01-19 20:43:59 <BW^-> paveljanik: that seems to have resolved it all :D
 77 2016-01-19 20:49:16 <Lauda> https://github.com/luke-jr/bitcoin/commit/8d3a84c242598ef3cdc733e99dddebfecdad84a6
 78 2016-01-19 20:49:18 <Lauda> What does this do?
 79 2016-01-19 20:49:19 <Lauda> What does this do?
 80 2016-01-19 20:50:17 <Luke-Jr> Lauda: changes the PoW algorithm to SHA3 instead of SHA2
 81 2016-01-19 20:50:18 <Luke-Jr> Lauda: changes the PoW algorithm to SHA3 instead of SHA2
 82 2016-01-19 20:50:33 <Lauda> Does that mean what I think it does?
 83 2016-01-19 20:50:41 <Lauda> All current ASICs won't work?
 84 2016-01-19 20:50:44 <AdrianG> yes.
 85 2016-01-19 20:51:08 <Lauda> In what scenario would this gain consensus?
 86 2016-01-19 20:52:18 <AdrianG> what is the target release date for segwit?
 87 2016-01-19 20:52:40 <sipa> Lauda: none
 88 2016-01-19 20:52:59 <haakonn> AdrianG:  https://bitcoin.org/en/bitcoin-core/capacity-increases-faq#roadmap-dates
 89 2016-01-19 20:53:00 <haakonn> AdrianG:  https://bitcoin.org/en/bitcoin-core/capacity-increases-faq#roadmap-dates
 90 2016-01-19 20:53:12 <Lauda> sipa then why does it exist, or is it not related to Core at all?
 91 2016-01-19 20:53:38 <sipa> Lauda: people are free to make proposals
 92 2016-01-19 20:54:08 <Lauda> I know that. Just asking if there was a certain reason, it seems not then. Is SegWit going according to plan, i.e. no delays?
 93 2016-01-19 20:55:37 <sipa> well segwit too is just a proposal, but a first implementation is very close to being ready (and we've had a prototype running for 3 weeks now or so)
 94 2016-01-19 20:56:48 <Lauda> I know what it is. That is good.
 95 2016-01-19 21:11:14 <maaku> sipa: what are your branches: segwit{,2,3,stats}?
 96 2016-01-19 21:11:17 <maaku> sipa: what are your branches: segwit{,2,3,stats}?
 97 2016-01-19 21:12:05 <sipa> maaku: you should only care about segwit3
 98 2016-01-19 21:12:15 <sipa> 1 and 2 were for earlier test networks
 99 2016-01-19 21:13:25 <maaku> ok thank you
100 2016-01-19 21:13:56 <maaku> is this generally true of sipa's repo, the highest numbered branch is the most current proposal?
101 2016-01-19 21:16:15 <sipa> maaku: i've certainly used that occasionally before
102 2016-01-19 21:16:33 <sipa> the headersfirst that got merged was headersfirst8
103 2016-01-19 21:16:36 <sipa> i think
104 2016-01-19 21:16:37 <sipa> i think
105 2016-01-19 21:39:39 <maaku> ah good you've moved the commitment to an output. thank you
106 2016-01-19 21:47:35 <maaku> sipa: the witness nonce seems to have changed purpose, is that documented anywhere?
107 2016-01-19 21:47:36 <maaku> sipa: the witness nonce seems to have changed purpose, is that documented anywhere?
108 2016-01-19 21:48:12 <sipa> maaku: it is intended for future consensus-critical commitments
109 2016-01-19 21:48:22 <maaku> am I reading it correct that the nonce is now another branch of the witness tree for future expansion?
110 2016-01-19 21:49:07 <sipa> yup
111 2016-01-19 21:49:12 <maaku> ok
112 2016-01-19 22:08:13 <bsm117532> Why should a non-mining node impose any block size limit at all?  Why not accept any block at all, and follow the highest PoW, as Satoshi intended?
113 2016-01-19 22:08:22 <sdaftuar> sipa: i observed that implies you can't ever mark a block as permanently failed if the commitment doesn't match.  no reason that should be a problem for anything i guess?
114 2016-01-19 22:12:38 <sipa> bsm117532: because with arbitrary resource consumption, you can't know if the rest of the network can accept a block
115 2016-01-19 22:12:50 <sipa> which would lead to a fork
116 2016-01-19 22:15:10 <bsm117532> But I know the size of the block from its header, and I start tracking it as a new tip.  It's a fork in exactly the usual manner, and if I'm not mining, I *do* want to see which one is gaining more work.  I'd argue if bitcoind *knows* you're not mining, why not set the limit very high, tied to say, resource consumption.  e.g. 32MB?
117 2016-01-19 22:16:10 <sipa> so you're proposing a model where full nkdes accept blocks without being able to validate?
118 2016-01-19 22:16:31 <jonasschnelli> Size of the block in header?
119 2016-01-19 22:16:32 <sipa> there is no way to know the block size from the headerz by the way
120 2016-01-19 22:16:49 <bsm117532> ok whoops then.  Just stop downloading at 32MB...
121 2016-01-19 22:17:05 <sipa> you haven't answered my question
122 2016-01-19 22:17:06 <sipa> you haven't answered my question
123 2016-01-19 22:17:08 <bsm117532> Of course full nodes should validate.
124 2016-01-19 22:17:09 <bsm117532> Of course full nodes should validate.
125 2016-01-19 22:17:19 <maaku> bsm117532: pleaes strike "as Satoshi intended" from your vocabulary. it is of no relevance here
126 2016-01-19 22:17:26 <bsm117532> But they should also track the existence of other tips, even if they might/have rejected the block.
127 2016-01-19 22:17:45 <sipa> if they can't know whether every full node will accept it, the only choice is rejecting
128 2016-01-19 22:17:55 <sipa> or you have inconsistent rules across nodes, and risk a fork
129 2016-01-19 22:18:06 <sipa> we do track invalid header chains
130 2016-01-19 22:18:20 <sipa> or incomplete ones
131 2016-01-19 22:18:25 <bsm117532> sipa: the information about what full nodes will accept is not advertised.  The only thing I can actually know is which blocks were produced.  No?
132 2016-01-19 22:18:26 <bsm117532> sipa: the information about what full nodes will accept is not advertised.  The only thing I can actually know is which blocks were produced.  No?
133 2016-01-19 22:18:41 <sipa> bsm117532: that information is called the consensus rules
134 2016-01-19 22:18:51 <sipa> full nodes can jointly decide to change it
135 2016-01-19 22:18:52 <sipa> full nodes can jointly decide to change it
136 2016-01-19 22:18:57 <sipa> and that is called a hard fork
137 2016-01-19 22:19:04 <bsm117532> So why not track them all?  Even ones I can't validate.  (Seeing a longer PoW chain than I can validate would be an indication I'm totally hosed)
138 2016-01-19 22:19:18 <sipa> we do track that
139 2016-01-19 22:19:22 <sipa> see the getchaintips rpc
140 2016-01-19 22:19:23 <sipa> see the getchaintips rpc
141 2016-01-19 22:19:45 <bsm117532> And bitcoind screams when it sees a longer chain that the one it thinks is valid?
142 2016-01-19 22:19:49 <sipa> yes
143 2016-01-19 22:19:55 <maaku> is there a better way to extract a push data than calling GetOp?
144 2016-01-19 22:20:14 <sipa> nope
145 2016-01-19 22:20:20 <maaku> :(
146 2016-01-19 22:20:23 <sipa> not that i know of :)
147 2016-01-19 22:20:39 <bsm117532> Then this is a tempest in a teapot.  It will be decided once the first >1MB block is produced, and will all be over within 60 minutes...
148 2016-01-19 22:21:32 <sipa> bsm117532: if that ever happens intentionally, there is indeed a problem
149 2016-01-19 22:22:13 <sipa> as there will be two possible outcomes: 1) massive risk for reorgs 2) the ecosystem switching to what miners demand for risk of (1)
150 2016-01-19 22:22:41 <sipa> i wonder what will happen if they ever choose to increase the subsidy...
151 2016-01-19 22:22:53 <bsm117532> A political problem, not a software problem.  Miners will choose to maximize profits, and the system will continue.
152 2016-01-19 22:23:04 <bsm117532> sipa: Let's hope they don't try that.
153 2016-01-19 22:23:09 <sipa> so why do we have full nodes at all?
154 2016-01-19 22:23:35 <bsm117532> It's a read-only database node.  And to relay to the miners.
155 2016-01-19 22:23:37 <sipa> miners wouldn't ever mine a double spend, right?
156 2016-01-19 22:23:38 <sipa> miners wouldn't ever mine a double spend, right?
157 2016-01-19 22:23:55 <sipa> that would also undermine the trust in the system
158 2016-01-19 22:24:12 <sipa> the system is designed so we don't need to trust them
159 2016-01-19 22:25:24 <bsm117532> I disagree with that last statement sipa.  We trust them not to make hard forks willy-nilly.  They're economically incentivized to poll other miners before they do so.  Not that I like it...but this gets back to mining decentralization.
160 2016-01-19 22:26:01 <kanzure> anyone can make a hard-fork- go look at altcoins.
161 2016-01-19 22:26:03 <kanzure> anyone can make a hard-fork- go look at altcoins.
162 2016-01-19 22:26:27 <bsm117532> Even with mining decentalization a majority could take a poll.  This is a nasty business.
163 2016-01-19 22:26:28 <bsm117532> Even with mining decentalization a majority could take a poll.  This is a nasty business.
164 2016-01-19 22:26:46 <kanzure> sipa: in an unsuccessful hard-fork (that is, one that does not also destroy the previous chain), there will be minting on both chains, so... that's a change to the supply.
165 2016-01-19 22:26:51 <belcher> what about if that warning about a longer invalid chain was removed? to improve the inertia to change of the system
166 2016-01-19 22:27:12 <belcher> i suppose its too late now , but maybe in a future cryptocurrency..
167 2016-01-19 22:27:24 <dgenr8> bsm117532: we don't trust miners not to hard-fork.  we run nodes for that.
168 2016-01-19 22:27:41 <sipa> kanzure: but the exchange rate of the coins on both sides.will likely diverge, and perhaps even their sum will be less than what it was before
169 2016-01-19 22:27:48 <denisx> I have “LoadBlockIndexDB: transaction index disabled” in my debug.log
170 2016-01-19 22:27:49 <denisx> I have “LoadBlockIndexDB: transaction index disabled” in my debug.log
171 2016-01-19 22:27:51 <denisx> is that a problem?
172 2016-01-19 22:27:52 <denisx> is that a problem?
173 2016-01-19 22:28:02 <sipa> denisx: no, yoi can enable it with -txindex
174 2016-01-19 22:28:03 <sipa> denisx: no, yoi can enable it with -txindex
175 2016-01-19 22:28:08 <kanzure> sipa: sure. true. but remember, bitcoin's 21M coin limit is not about the exchange rate, it's about a coin limit.
176 2016-01-19 22:28:14 <jonasschnelli> denisx: that's normal.
177 2016-01-19 22:28:18 <denisx> sipa: would that explain a very slow bitcoind?
178 2016-01-19 22:28:27 <sipa> you only need the txindex if you want the getrawtransaction RPC
179 2016-01-19 22:28:34 <sipa> denisx: no, txindex makes it a lot slower
180 2016-01-19 22:29:05 <denisx> has it anything todo with the 0.11.2 update?
181 2016-01-19 22:29:31 <sipa> no
182 2016-01-19 22:29:34 <sipa> no
183 2016-01-19 22:29:36 <denisx> ok, thanks
184 2016-01-19 22:29:39 <sipa> it's been that way since 0.8
185 2016-01-19 22:29:55 <bsm117532> Well looks like we (BitDevsNYC) will probably hold a meeting on this topic.  I'm gonna bring popcorn and a fire extinguisher, and try really really hard not to say anythign.
186 2016-01-19 22:30:10 <jonasschnelli> :-)
187 2016-01-19 22:30:12 <sipa> bsm117532: haha
188 2016-01-19 22:30:42 <bsm117532> Meanwhile I'm going to think about ways to design a protocol that can accept more arbitrary changes to its protocol in a soft-fork manner...
189 2016-01-19 22:30:43 <bsm117532> Meanwhile I'm going to think about ways to design a protocol that can accept more arbitrary changes to its protocol in a soft-fork manner...
190 2016-01-19 22:31:30 <belcher> sipa so bitcoin core gives a warning when it detects an invalid chain longer than what it considers a valid one, would it be worth removing that warning to increase the inertia to change of the system ?
191 2016-01-19 22:31:54 <bsm117532> belcher: that's a violent and political move.
192 2016-01-19 22:32:18 <belcher> violent? i disagree, political? absolutely, i see bitcoin itself as political (i am aware that some people disagree)
193 2016-01-19 22:32:20 <bsm117532> coercive, rather.
194 2016-01-19 22:32:43 <bsm117532> coercion by enforced ignorance is not something I'd want in core.
195 2016-01-19 22:32:53 <belcher> wait a minute, i get it why sipa wont answer me, whoops sorry for asking :)
196 2016-01-19 22:32:54 <belcher> wait a minute, i get it why sipa wont answer me, whoops sorry for asking :)
197 2016-01-19 22:33:00 <belcher> forget i asked
198 2016-01-19 22:33:01 <belcher> forget i asked
199 2016-01-19 22:33:37 <belcher> bsm117532 people can always get their information in other ways, just bitcoin core is not obliged to share information that may help in destroying it's consensus
200 2016-01-19 22:33:38 <belcher> bsm117532 people can always get their information in other ways, just bitcoin core is not obliged to share information that may help in destroying it's consensus
201 2016-01-19 22:34:01 <Lauda> http://codesuppository.blogspot.ca/2016/01/the-lightning-network-reality-check.html
202 2016-01-19 22:34:05 <Lauda> There is one way that the Lightning Network numbers do work; and that is if individual people don't get to access the blockchain at all.  If the only ones opening and closing channels on the main blockchain are banks and wealthy individuals, everyone else can just operate on layer-2 or 3rd party networks 100% of the time.
203 2016-01-19 22:36:25 <sipa> belcher: my phone died :)
204 2016-01-19 22:36:54 <belcher> Lauda sounds correct from what i know about it, when the block space becomes rationed by the market, only those who are willing to pay enough will be able to access it
205 2016-01-19 22:36:55 <belcher> Lauda sounds correct from what i know about it, when the block space becomes rationed by the market, only those who are willing to pay enough will be able to access it
206 2016-01-19 22:37:42 <sipa> belcher: well, unfortunately the most common reason why that detection triggers is when the UTXO database gets corrupted
207 2016-01-19 22:38:15 <belcher> so it already triggers sometimes on its own? thats unfortunate
208 2016-01-19 22:38:16 <belcher> so it already triggers sometimes on its own? thats unfortunate
209 2016-01-19 22:38:17 <Lauda> belcher That sounds discouraging.
210 2016-01-19 22:38:18 <Lauda> belcher That sounds discouraging.
211 2016-01-19 22:38:50 <belcher> Lauda why? very few people are willing to pay for armoured cars to ship around tons and tons of gold bars too
212 2016-01-19 22:39:15 <Lauda> That's not exactly what I had in mind for when I joined though.
213 2016-01-19 22:39:35 <dgenr8> belcher: if you want to keep users in the dark, be sure to add code to falsify RPC blockchain statistics too
214 2016-01-19 22:39:56 <belcher> in gold this is solved by creating paper notes, in bitcoin we can use smart contracts and payment channels so that fractional reserve or fraud cannot happen
215 2016-01-19 22:40:47 <belcher> we can have our cake and eat it as well, so to speak, have the good properties of a digital gold, but also be able to move through the internet very easily
216 2016-01-19 22:41:36 <belcher> dgenr8 users can always just read bitcoin forums, theres no point trying to keep them in the dark, this is just about not having large warnings or popups that notify them
217 2016-01-19 22:41:40 <belcher> dgenr8 users can always just read bitcoin forums, theres no point trying to keep them in the dark, this is just about not having large warnings or popups that notify them
218 2016-01-19 22:41:47 <belcher> but it sounds like the idea will never work anyway
219 2016-01-19 22:43:22 <bsm117532> So, to be clear, if I don't have a horse in this race and am not a payment provider, I can just sneak in and change 1000000 to 0xffffffff, and a printf for if it happens, and watch the fireworks?  (I'll accept the risk that someone will spend $10k to mine a block just to DDoS me)
220 2016-01-19 22:43:29 <bsm117532> What else would go wrong?
221 2016-01-19 22:44:41 <belcher> bsm117532 you'd be running on spv security, however if the amount the miners could steal from you is less than 25btc+fees, you theoretically have nothing to worry about
222 2016-01-19 22:45:40 <sipa> bsm117532: not fireworks, just a warning in many nodes
223 2016-01-19 22:45:44 <sipa> people will talk about it
224 2016-01-19 22:45:46 <bsm117532> Hence the "not a payment provider" comment.
225 2016-01-19 22:45:47 <bsm117532> Hence the "not a payment provider" comment.
226 2016-01-19 22:46:54 <bsm117532> My wallet will have only UTXO's older than the fork, and I'd wait until the fire dies down to send any spends.
227 2016-01-19 22:46:55 <bsm117532> My wallet will have only UTXO's older than the fork, and I'd wait until the fire dies down to send any spends.
228 2016-01-19 22:47:47 <belcher> so in other words bsm117532 your bitcoins are frozen, you cannot spend them for the duration of the fork
229 2016-01-19 22:47:57 <belcher> (although that would be true even if you didnt edit your node)
230 2016-01-19 22:47:58 <belcher> (although that would be true even if you didnt edit your node)
231 2016-01-19 22:48:01 <bsm117532> belcher: Everyone's effectively are.
232 2016-01-19 22:51:51 <phantomcircuit> Lauda, hash locked bidirectional payment channels (aka lightning) fundamentally change the limitation from transactions per second (ie bytes/second) to channels open/closed per second (ie active users)
233 2016-01-19 22:52:48 <Lauda> phantomcircuit that does not really answer the part that I quoted, but thanks for the information.
234 2016-01-19 22:52:56 <Lauda> phantomcircuit that does not really answer the part that I quoted, but thanks for the information.
235 2016-01-19 22:52:56 <phantomcircuit> Lauda, hash locked bidirectional payment channels (aka lightning) fundamentally change the limitation from transactions per second (ie bytes/second) to channels open/closed per second (ie active users)
236 2016-01-19 22:54:01 <Lauda> "but now it seems that instead of allowing freedom of choice between normal bitcoin transactions and instant offchain transactions.. it seems they want to push all users offchain and only have selective merchants using the real blockchain to make settlements."
237 2016-01-19 22:54:20 <belcher> phantomcircuit would it be possible to imagine lightning users who never open any channels at all? e.g. someone gets paid a salary in the form of a LN tx and spends it all on food/bills/rent, never touching the actual blockchain
238 2016-01-19 22:54:20 <phantomcircuit> Lauda, the sentiment is completely ridiculous; "if we have ~10000 times more users than we have today then we're going to have a capacity problem with lightning!"
239 2016-01-19 22:54:23 <phantomcircuit> ok so what
240 2016-01-19 22:54:51 <Lauda> I'm just quoting people discussing this.
241 2016-01-19 22:54:56 <Lauda> and trying to understand
242 2016-01-19 22:54:57 <Lauda> and trying to understand
243 2016-01-19 22:54:57 <phantomcircuit> belcher, no you need to have a channel open to receive a payment
244 2016-01-19 22:55:06 <sipa> Lauda: many people somehow feel Lightning "is not Bitcoin"
245 2016-01-19 22:55:07 <sipa> Lauda: many people somehow feel Lightning "is not Bitcoin"
246 2016-01-19 22:55:25 <phantomcircuit> sipa, the person he's quoting at least admits that lightning is bitcoin
247 2016-01-19 22:55:25 <sipa> and perhaps the fact that it is called "Lightning network" encourages that
248 2016-01-19 22:55:34 <belcher> phantomcircuit so it doesnt work like streamium where one the parties has no money to start with ?
249 2016-01-19 22:55:35 <belcher> phantomcircuit so it doesnt work like streamium where one the parties has no money to start with ?
250 2016-01-19 22:56:07 <phantomcircuit> Lauda, the only thing they're saying is that lightning does not enable infinite scaling -- which is true -- but i fail to see why that even matters
251 2016-01-19 22:56:42 <dgenr8> many people feel that banks are not euros/dollars/yen
252 2016-01-19 22:56:43 <dgenr8> many people feel that banks are not euros/dollars/yen
253 2016-01-19 22:57:10 <bsm117532> I imagine with LN, most people will keep a payment channel open to a bank-like service provider, so that payments can be routed to any other person with a channel open.
254 2016-01-19 22:57:11 <bsm117532> I imagine with LN, most people will keep a payment channel open to a bank-like service provider, so that payments can be routed to any other person with a channel open.
255 2016-01-19 22:57:11 <phantomcircuit> belcher, i do not know how streamium works, but i am not aware of any scheme for receiving payments that doesn't require at least a single transaction to be included in a block
256 2016-01-19 22:57:16 <Lauda> Some users are comparing it to an altcoin sipa.
257 2016-01-19 22:57:17 <Lauda> Some users are comparing it to an altcoin sipa.
258 2016-01-19 22:57:32 <phantomcircuit> Lauda, those people are in a word retarded
259 2016-01-19 22:57:49 <sipa> Lauda: i think that's completely unwarranted; it's the same currency, and the same transactions even; they just don't instantly hit the blockchain (but are secure nonetheless)
260 2016-01-19 22:58:41 <dgenr8> phantomcircuit: thanks, that clears it up
261 2016-01-19 22:59:50 <Lauda> Sipa I agree with this. Apparently they missunderstand it and I'm trying to help clear things up (correctly), thus I ask questions here.
262 2016-01-19 22:59:51 <Lauda> Sipa I agree with this. Apparently they missunderstand it and I'm trying to help clear things up (correctly), thus I ask questions here.
263 2016-01-19 23:01:08 <bsm117532> Bidirectional payment channels are possible now on mainnet with CLTV. Whether it's called "lightning network" or not, routing payments this way will grow, and that growth is Bitcoin's growth.
264 2016-01-19 23:02:20 <belcher> phantomcircuit something like this, writing from memory. a 2-of-2 multisig is created, the sender holds one key and sends a coin to it, when they want to do a payment they send to the receiver a partially-signed tx paying out that coin between sender and receiver, the receiver does not broadcast this tx until the very end when the channel is closed, in this situation the receiver doesnt need to own any coins beforehand
265 2016-01-19 23:03:19 <moa> just fyi I always refer to it as the "Bitcoin Lightning Network" now ... because of the intentional FUD that has created the disconnect/revulsion
266 2016-01-19 23:04:09 <moa> could have called Bitcoin cache or bitcoin mempool-extension
267 2016-01-19 23:04:40 <moa> if you were being as disingenuous as the detractors
268 2016-01-19 23:09:18 <phantomcircuit> belcher, i think that works but only if the channel is only unidirectional
269 2016-01-19 23:09:42 <belcher> okay ty
270 2016-01-19 23:09:48 <dgenr8> moa: that's not really fair to LN, since it could just as easily be used with another chain
271 2016-01-19 23:10:36 <moa> dgenr8: which one? I don't know of any that have the hooks in place for it their scripting ...
272 2016-01-19 23:10:52 <phantomcircuit> belcher, and i think you dont really need the payment channel for a unidirectional payment
273 2016-01-19 23:11:10 <phantomcircuit> oh i guess you do nvm
274 2016-01-19 23:11:17 <dgenr8> well i'm not saying implementations haven't hard-coded a dependency on btc
275 2016-01-19 23:11:56 <phantomcircuit> belcher, no wait you dont, you just keep sending them new transactions with ever decreasing lock times
276 2016-01-19 23:11:59 <moa> except most/all of their coding is based on bitcoin script CLTV and CSV
277 2016-01-19 23:12:00 <moa> except most/all of their coding is based on bitcoin script CLTV and CSV
278 2016-01-19 23:12:12 <Lauda> https://bitcointalk.org/index.php?topic=1333984.0
279 2016-01-19 23:12:19 <Lauda> 2013 Pieter Wuille is not the same 2015 Pieter Blockstream Wuille..
280 2016-01-19 23:12:56 <Lauda> 2013 Pieter Wuille is not the same 2015 Pieter Blockstream Wuille..
281 2016-01-19 23:12:56 <Lauda> https://bitcointalk.org/index.php?topic=1333984.0
282 2016-01-19 23:12:56 <moa> except most/all of their coding is based on bitcoin script CLTV and CSV
283 2016-01-19 23:12:56 <phantomcircuit> belcher, no wait you dont, you just keep sending them new transactions with ever decreasing lock times
284 2016-01-19 23:14:39 <dgenr8> moa: it works with any genesis block, i'll leave it at that
285 2016-01-19 23:14:40 <dgenr8> moa: it works with any genesis block, i'll leave it at that
286 2016-01-19 23:15:06 <sipa> Lauda: my understanding increased
287 2016-01-19 23:15:09 <phantomcircuit> dgenr8, you realize 99.99% of the code for every altcoin is bitcoin right?
288 2016-01-19 23:15:25 <phantomcircuit> quick stop developing bitcoin so the altcoins cant use it!
289 2016-01-19 23:15:59 <Lauda> Sipa I know that. People are pulling up all kinds of nonsense these days in order to support them.
290 2016-01-19 23:16:00 <Lauda> Sipa I know that. People are pulling up all kinds of nonsense these days in order to support them.
291 2016-01-19 23:16:09 <Lauda> No response to the LN discussion yet.
292 2016-01-19 23:16:10 <Lauda> No response to the LN discussion yet.
293 2016-01-19 23:16:19 <moa> dgenr8: in reality no other altcoin has the dev resources to implement LN network on top ... hell, even bitcoin is struggling to make it happen
294 2016-01-19 23:16:39 <dgenr8> phantomcircuit: let's see ... how would I put it in your language .. "you clearly fail to understand even the basics of the situation here"
295 2016-01-19 23:16:51 <dgenr8> a bunch of large hubs could decide to switch to an alt
296 2016-01-19 23:16:52 <dgenr8> a bunch of large hubs could decide to switch to an alt
297 2016-01-19 23:16:58 <moa> riiiight
298 2016-01-19 23:16:59 <moa> riiiight
299 2016-01-19 23:17:24 <sipa> Lauda: anyway, if you feel inclined to, please link to the entire post where this quote came from. i think it gives a much better view (and yes, my understanding changed, i wasn't aware of the mining centralization that resulted from relay at that time)
300 2016-01-19 23:17:29 <sipa> https://bitcointalk.org/index.php?topic=144895.msg1537737#msg1537737
301 2016-01-19 23:17:56 <Lauda> sipa new thread at BTCT links to this
302 2016-01-19 23:17:57 <Lauda> https://www.reddit.com/r/btc/comments/3xg613/pieter_wuille_in_2013_bitcoin_is_a_consensus_of/
303 2016-01-19 23:17:57 <Lauda> sipa new thread at BTCT links to this
304 2016-01-19 23:17:58 <Lauda> https://www.reddit.com/r/btc/comments/3xg613/pieter_wuille_in_2013_bitcoin_is_a_consensus_of/
305 2016-01-19 23:18:29 <dgenr8> dollars in one side, dollars out the other.  meanwhile the usage of the alt grows
306 2016-01-19 23:19:14 <Lauda> Which is the same post.
307 2016-01-19 23:19:15 <dgenr8> they key is getting users to accept "layer 2" and not btc
308 2016-01-19 23:19:16 <dgenr8> they key is getting users to accept "layer 2" and not btc
309 2016-01-19 23:19:21 <moa> what's really eating me up is people who haven't been paying attention are now clamouring for "better communiction" ... doublespeak for "I don't understand so get me up to speed by spoonfeeding for free and then i can go and write an article or consult on it like I'm an expert"
310 2016-01-19 23:19:28 <phantomcircuit> dgenr8, THERE ARE NO HUBS FUCK RIGHT OFF
311 2016-01-19 23:19:29 <phantomcircuit> dgenr8, THERE ARE NO HUBS FUCK RIGHT OFF
312 2016-01-19 23:19:32 <phantomcircuit> idiot
313 2016-01-19 23:21:51 <dgenr8> i notice the ops have favorites
314 2016-01-19 23:23:06 <dgenr8> ripple had the same plan for a while.  invisible middleman XRP.
315 2016-01-19 23:35:43 <Lauda> "I mean you have to buy altcoins to pay with them. It's an investment. The same way you have to buy into payment channels and bind your bitcoins in the system without being able to freely move them. That's the first hurdle to overcome when it comes to convince people of using it. In fact i think it will be pretty much impossible to move a considerable amount of people to move to ln."
316 2016-01-19 23:35:44 <Lauda> "I mean you have to buy altcoins to pay with them. It's an investment. The same way you have to buy into payment channels and bind your bitcoins in the system without being able to freely move them. That's the first hurdle to overcome when it comes to convince people of using it. In fact i think it will be pretty much impossible to move a considerable amount of people to move to ln."
317 2016-01-19 23:35:58 <Lauda> "Well, you can say that changetip is bitcoin too then. The bitcoins only are transferred offchain. And you don't see a difference why you would not trust changetip with your monthly earnings? Yes, ln is safer but still there is a group who demands you, no tries to force you to use their new system. They don't take out the artificial restriction that hinders the bitcoin network and present their own network as solution."
318 2016-01-19 23:35:59 <Lauda> "Well, you can say that changetip is bitcoin too then. The bitcoins only are transferred offchain. And you don't see a difference why you would not trust changetip with your monthly earnings? Yes, ln is safer but still there is a group who demands you, no tries to force you to use their new system. They don't take out the artificial restriction that hinders the bitcoin network and present their own network as solution."
319 2016-01-19 23:36:48 <sipa> Lauda: changetip very much is Bitcoin (the currency)
320 2016-01-19 23:37:26 <sipa> Lauda: and LN is actually quite a bit like changetip, except LN is not a single party that can run away with your money, or go bankrupt, or hold your coins hostage
321 2016-01-19 23:37:28 <ibrightly> I see the LN as being more or less like using Changetip is today, with the difference being that if ChangeTip-LN-Node goes away, you get your funds back in a week or so. I'm actually pretty exciting for LN, although I imagine it'll take some time to get some traction.
322 2016-01-19 23:40:35 <ibrightly> I imagine that one of the harder parts to figure out will be how to determine paths. For example, if one user is on the LN and the other isn't, how do I negotiate that payment to get you setup with an open channel to someone we have in common? Making that UX go smoothly will be key.
323 2016-01-19 23:40:36 <ibrightly> I imagine that one of the harder parts to figure out will be how to determine paths. For example, if one user is on the LN and the other isn't, how do I negotiate that payment to get you setup with an open channel to someone we have in common? Making that UX go smoothly will be key.
324 2016-01-19 23:41:28 <Lauda> Thanks sipa.
325 2016-01-19 23:41:50 <sipa> Lauda: i also answered on reddit...
326 2016-01-19 23:48:07 <Lauda> thanks rusty & sipa.