1 2015-03-25 00:30:54 <dgenr8> I see jgarzik introduced this idea on the mailing list as "address TTL" on 2014-07-15
  2 2015-03-25 00:35:55 <phantomcircuit> what's the purpose of an address ttl that isn't voluntary
  3 2015-03-25 00:36:10 <phantomcircuit> ie embed a ttl into the address and simply have clients "enforce" the restriction
  4 2015-03-25 00:36:51 <Luke-Jr> dgenr8: I didn't, I clicked pay immediately. It just took a week before a miner decided to include it in a block.
  5 2015-03-25 00:38:49 <dgenr8> Luke-Jr: you knew after TTL expiration that it wasn't going to be confirmed
  6 2015-03-25 00:39:26 <phantomcircuit> oh having it be a consensus rule would prevent "gotcha" scenarios
  7 2015-03-25 00:39:28 <phantomcircuit> hmm
  8 2015-03-25 00:39:41 <Luke-Jr> dgenr8: not my problem at that point
  9 2015-03-25 00:41:13 <dgenr8> Luke-Jr: merchant wouldn't have sent the goods so non-confirm is both of your problem.  just like today
 10 2015-03-25 00:43:40 <Luke-Jr> point is there is no problem at all right now
 11 2015-03-25 00:45:15 <dgenr8> Luke-Jr: address reuse is not a problem?
 12 2015-03-25 00:55:37 <Luke-Jr> dgenr8: address reuse is not supported, nor in much retail use
 13 2015-03-25 00:55:55 <Luke-Jr> and is entirely unrelated to the topic O.o
 14 2015-03-25 01:02:13 <phantomcircuit> Luke-Jr, bitpay actually seems to reuse 100% of their addresses...
 15 2015-03-25 01:02:19 <phantomcircuit> or at least did at somepoint
 16 2015-03-25 01:02:22 <phantomcircuit> some point*
 17 2015-03-25 01:10:50 <dgenr8> Luke-Jr: the topic is "hey, with an address expiration height, reuse could be prevented"
 18 2015-03-25 01:13:17 <Luke-Jr> phantomcircuit: they definitely don't now..
 19 2015-03-25 01:13:33 <Luke-Jr> dgenr8: well, no need for a consensus rule for that
 20 2015-03-25 01:14:16 <dgenr8> how do you figure that?
 21 2015-03-25 01:15:08 <Luke-Jr> dgenr8: it's sufficient for wallets to give an error for expired destinations
 22 2015-03-25 01:16:05 <Luke-Jr> which they already do, using the payment protocol which replaces addresses
 23 2015-03-25 01:34:37 <dgenr8> payment protocol is not bitcoin.  addresses are the bitcoin payment destination interface.
 24 2015-03-25 01:43:48 <dgenr8> there would also need to be a expiration - locktime < X requirement to keep the reuse check bounded
 25 2015-03-25 01:45:56 <Luke-Jr> payment protocol is indeed bitcoin
 26 2015-03-25 06:56:29 <midnightmagic> :-(
 27 2015-03-25 06:57:05 <midnightmagic> huh..
 28 2015-03-25 08:35:33 <hno> Before I dig into this too deep. Is there any known issue where bitcoin-0.9 might reuse change addresses or somehow generate the same address more than once in the keypool?
 29 2015-03-25 08:37:40 <hno> What I do know before digging into the code is that we have change addresses that have received change twice, and debug.log mentions different keypool reservation numbers when creating each transaction.
 30 2015-03-25 09:14:40 <fanquake> ;;blocks
 31 2015-03-25 09:14:41 <gribble> 349149
 32 2015-03-25 11:21:45 <wumpus> hno: unless you restored a wallet.dat at some point that should not happen
 33 2015-03-25 13:19:33 <hno> wumpus, I know it should not happen. The wallet have been there for a long time, and have verified that both transactions were initiated on the same bitcoind instance, with only one day between.
 34 2015-03-25 13:21:49 <hno> and different keypool id are reported in debug.log for both transaction as expected, but they end up using the same change address.
 35 2015-03-25 13:22:50 <hno> looking at an backup of the wallet those keypool ids appear to refer to different pubkeys, unless I misunderstand how keypool entries are serialized.
 36 2015-03-25 13:51:01 <hno> Ah, sorry for the noise. Got it now. Major brain fart in many levels.
 37 2015-03-25 13:51:24 <hno> nothing to worry about other than my brain..
 38 2015-03-25 14:31:14 <wumpus> okay
 39 2015-03-25 15:50:37 <morcos> gavinandresen: you there?
 40 2015-03-25 15:50:46 <gavinandresen> yup
 41 2015-03-25 15:51:08 <morcos> i was looking at your reorg pull because i was playing around with something similar last week
 42 2015-03-25 15:51:19 <morcos> i think you ran into the same problem i did
 43 2015-03-25 15:51:55 <gavinandresen> probably… I ran into a few problems, thought that would be an afternoon’s work and it turned into a couple days....
 44 2015-03-25 15:51:55 <morcos> the call to mempool.remove() doesn't actually do anything (remove dependent txs) because the original tx is not in the mempool so it just short circuits right away
 45 2015-03-25 15:52:33 <morcos> this isn't usually a problem because now all tx's should get added back to the mempool, and then if they conflict with a tx from the new chain, they are removed then and then the recursive removal works
 46 2015-03-25 15:52:59 <morcos> but if you never add them back to the mempool, this process doesn't work, and dependent tx's will stay in the mempool
 47 2015-03-25 15:53:53 <gavinandresen> I didn’t run into that problem, but I should have....
 48 2015-03-25 15:53:57 <morcos> mempool.check() found this for me while running the giant autoprune.py rpc test with my faster reorg patch
 49 2015-03-25 15:54:12 <morcos> yeah so i didn't demonstrate it happens with your code yet
 50 2015-03-25 15:54:16 <morcos> but it seems like it would
 51 2015-03-25 15:54:18 <gavinandresen> yup
 52 2015-03-25 15:54:36 <gavinandresen> Moving the if (!mapTx.count(hash))  to after the recursive check should fix it.
 53 2015-03-25 15:55:13 <gavinandresen> wait… no....
 54 2015-03-25 15:55:28 <morcos> i didn't really think about how to fix it
 55 2015-03-25 15:56:12 <morcos> but it does seem like there is a more fundamental fix like that needed, because obviously we're kind of assuming that it does the "right" thing by the way we call it when we're disconnecting blocks
 56 2015-03-25 15:56:37 <gavinandresen> yup
 57 2015-03-25 15:56:47 <morcos> is there any way a transaction could fail to be accepted to the mempool from a disconnected block?
 58 2015-03-25 15:57:02 <gavinandresen> sure, if it is non-standard it won’t go into the mempool
 59 2015-03-25 15:57:09 <morcos> ah
 60 2015-03-25 15:57:17 <morcos> so then this problem exists in the code right now
 61 2015-03-25 15:57:49 <gavinandresen> almost certainly… do you want to try to craft a regression test that shows the problem, or shall I?
 62 2015-03-25 15:57:50 <morcos> we could break the invariant that all tx's in the mempool could be included in the next block...
 63 2015-03-25 15:57:59 <morcos> i can do it if you like
 64 2015-03-25 15:58:06 <gavinandresen> awesome, go for it!
 65 2015-03-25 15:58:44 <morcos> hmm, a bit tricky, how do i make regtest mempool reject non-standard?
 66 2015-03-25 15:59:19 <gavinandresen> mmm… good question….
 67 2015-03-25 15:59:50 <morcos> i've actually wanted to do that before..   i'm not 100% up to date on the proposed path forward for policies, but it does seem like that should be something you should be able to choose
 68 2015-03-25 16:00:14 <morcos> ok i'll play around, if you have any good ideas, shoot them over
 69 2015-03-25 16:05:06 <gavinandresen> morcos: fix should be easier than the regression test, just add origTx inputs at the top of ::remove:  https://0bin.zertrin.org/paste/7e1050f92c3d7a29b6c9a096010af759969fc0f4#Tjm2nPUhUdPe78Ocecvv8Rsp5FPyEXBejyYBlr/KH04=
 70 2015-03-25 16:07:01 <phantomcircuit> i like how we all make use of heavily encrypted pastebins and then post the encryption keys in public irc channels
 71 2015-03-25 16:07:41 <gavinandresen> morcos: wait… no… that’s backwards….  I’m confusing myself
 72 2015-03-25 16:09:30 <morcos> gavinandresen: it was?  seemed ok to me, hard to go back and forth between pastebin and code..  i'm sure its possible to change it to just delete the orig tx's dependents, but i just hadn't thought through whether that was perfectly fine to do or not
 73 2015-03-25 16:10:28 <morcos> oh now you'd remove twice if it was in?
 74 2015-03-25 16:11:20 <gavinandresen> morcos: no, the if (!mapTx.count()) would short-circuit the second remove.  Ignore me, I’m overthinking.
 75 2015-03-25 16:11:29 <gavinandresen> (and should get some lunch)
 76 2015-03-25 16:11:47 <gavinandresen> I don’t see how dependents can be in the mempool without the parent, though
 77 2015-03-25 16:12:18 <gavinandresen> … but I need to stare at the block re-org code some more
 78 2015-03-25 16:12:20 <morcos> what do you mean?  they got in there when the parent was in a block, which you are now disconnecting
 79 2015-03-25 16:15:04 <gavinandresen> morcos: right! I think I need more caffeine....
 80 2015-03-25 16:15:15 <morcos> so here's the other issue though
 81 2015-03-25 16:15:33 <morcos> well maybe its minor
 82 2015-03-25 16:16:00 <morcos> but lets say your reorg and can't add back the tx (maybe its non-standard) then you go and remove all its dependents, but then that tx was included in the new chain
 83 2015-03-25 16:16:05 <morcos> now you've lost all the dependents
 84 2015-03-25 16:16:14 <gavinandresen> yup
 85 2015-03-25 16:16:16 <morcos> thats not the end of the world, but its different than todays behavior
 86 2015-03-25 16:16:43 <gavinandresen> dependents could be moved to mapOrphans instead of just dropped.
 87 2015-03-25 16:16:54 <gavinandresen> … but mapOrphans can overflow and they can get lost
 88 2015-03-25 16:17:41 <morcos> all these things tie together into the question of what are we trying to achieve with the mempool, and i don't seem to grasp what the consensus is on that, if there is one
 89 2015-03-25 16:18:15 <gavinandresen> the mempool should be “transactions ready to go into a block right now”
 90 2015-03-25 16:19:05 <gavinandresen> eventually I think we’ll need to rewrite the mempool so it is more efficient when it is time to create a block
 91 2015-03-25 16:20:13 <gavinandresen> … e.g. keep it pre-sorted by fee and priority, so block creation is very fast and when we relay transactions based on whether or not they would be likely to get into the next block or two those checks can be very fast
 92 2015-03-25 16:20:47 <morcos> yes, but i mean with regards to how important is it to have similar mempools or to ensure transactions aren't accidentally lost..   it kind of almost makes sense to have different mempools for miners and for nodes.  and within nodes, you keep things in the mempool only for efficient block propogation and you  have another set of data structures that tracks what you've relayed, so that every tx gets a chance to reach miners
 93 2015-03-25 16:21:20 <gavinandresen> We’ve already got another set of data structures that tracks what is relayed, down in net.cpp
 94 2015-03-25 16:21:24 <morcos> but at miners, they can drop whatever they're never going to mine, but possibly have bigger mempools and bigger mapOrphans to keep around things they may eventually mine
 95 2015-03-25 16:22:02 <gavinandresen> mmm…. it has been a bad idea to have different relay policies from mining policies
 96 2015-03-25 16:22:31 <gavinandresen> it is better for wallets to know quickly whether or not their transactions will get relayed/mined
 97 2015-03-25 16:23:29 <morcos> well i think it comes down to how different are mining policies going to be,  i agree if they all stick close to the default, then sure, the relay shoudl be the same, but if there are many custom mining policies, then its kind of hopeless to approximate that too much with the relay policy.. or maybe you relay more things than you keep around or something..
 98 2015-03-25 16:24:09 <morcos> i do think regardless of whether we are increasing block size soon or not, it would make a lot of sense to soft lower it now.  i know you suggested that and i've seen kanzure argue for it.
 99 2015-03-25 16:24:44 <morcos> a lot to be learned about what to do with resource constraints
100 2015-03-25 16:24:53 <gavinandresen> what do you think we’ll learn with (say) a 500K soft limit?
101 2015-03-25 16:25:56 <morcos> well we'll learn how to predict which tx's we need to keep around b/c they are likely to be mined, which have trouble getting eventually mined b/c some of the network drops them, how people respond to capacity constraints
102 2015-03-25 16:26:18 <gavinandresen> I think we already know all of that
103 2015-03-25 16:26:48 <gavinandresen> Keep transactions with high priority or fee.  Low priority/fee will have trouble.  And people will respond by paying more or finding a cheaper alternative.
104 2015-03-25 16:26:59 <morcos> i don't think we'd want to impose so much pressure to cause fees to jump, but we could easily cause upwards pressure from where i think fees are likely to settle as fee estimation becomes more common place (which is basically minRelay i think)
105 2015-03-25 16:27:47 <morcos> right so what happens to the things that are not high fee/pri enough?  do they get "lost".
106 2015-03-25 16:28:16 <gavinandresen> sure, if there is not enough space in the blocks mined then they HAVE to get lost.
107 2015-03-25 16:28:55 <gavinandresen> There’s a good theoretical analysis here: http://hashingit.com/analysis/34-bitcoin-traffic-bulletin
108 2015-03-25 16:29:35 <gavinandresen> I’m worried about block size because Very Bad Things happen as we go past 40% capacity....
109 2015-03-25 16:29:44 <morcos> so what i think we're going to learn is what problems are associated with that, if they are partially lost, maybe they are hard to re-relay?   is it necessary to re-relay them or do miners still have them?   what mempool limiting parameters affect this?
110 2015-03-25 16:30:05 <morcos> really?
111 2015-03-25 16:31:08 <gavinandresen> yes, confirmation times for marginal-fee/priority transactions starts to rise very quickly as we get to half-full-or-more blocks
112 2015-03-25 16:31:26 <gavinandresen> basically because they have to wait until the network gets lucky and finds several blocks in a row to clear the backlog of marginal transactions
113 2015-03-25 16:31:31 <morcos> ok i'll take a look at that page... anyway lunch time for me..   are you going to submit a remove patch?
114 2015-03-25 16:31:52 <morcos> or should i?
115 2015-03-25 16:32:08 <gavinandresen> I’ll do it
116 2015-03-25 16:32:26 <gavinandresen> I’ll write a unit test instead of a regression test….
117 2015-03-25 16:33:23 <morcos> k
118 2015-03-25 17:21:19 <gavinandresen> morcos: https://github.com/bitcoin/bitcoin/pull/5945
119 2015-03-25 17:24:21 <morcos> gavinandresen: so doesn't that add the dependents of the orig tx twice
120 2015-03-25 17:24:35 <morcos> not in the case we were trying to fix, but in the regular case where the orig tx is in the mempool
121 2015-03-25 17:26:06 <gavinandresen> morcos: yes, but adding it twice is harmless.  I suppose I could add a bit of code to optimize that away....
122 2015-03-25 17:28:28 <gavinandresen> morcos: bit of code added to avoid adding it twice, pull request updated
123 2015-03-25 17:30:29 <morcos> :) thanks
124 2015-03-25 17:46:30 <terranpants> What is AssertLockHeld(cs_main); doing exactly? Is it required? It doesn't appear Litecoin uses it at all.
125 2015-03-25 17:46:58 <terranpants> It is causing an runtime error on a Bitcoin QT for OSX I'm compiling
126 2015-03-25 17:48:16 <ajweiss> is the runtime error complaining about locks not being held?
127 2015-03-25 17:48:24 <gavinandresen> terranpants: AssertLockHeld is used by routines that require that the calling routine acquire a lock
128 2015-03-25 17:48:37 <gavinandresen> It is checked when you compile with -DDEBUG_LOCKORDER
129 2015-03-25 17:48:57 <terranpants> Thank you for explaining that
130 2015-03-25 17:49:08 <gavinandresen> … and if you get the assertion failure it means some code is Doing The Wrong Thing with locking.
131 2015-03-25 17:49:08 <terranpants> I do notice that is being compiled with that flag currently
132 2015-03-25 17:49:19 <terranpants> Ah okay
133 2015-03-25 17:49:23 <phantomcircuit> gavinandresen, do you have a feel for how much of a performance hit DEBUG_LOCKORDER has?
134 2015-03-25 17:49:53 <gavinandresen> phantomcircuit: dunno, have never benchmarked it.  I tend to run with -DDEBUG_LOCKORDER all the time, but I’m pretty tolerant of slow startup, syncing, etc
135 2015-03-25 17:50:39 <gavinandresen> phantomcircuit: it is probably pretty slow— it will allocate some memory for every LOCK()
136 2015-03-25 17:50:44 <terranpants> Thank you for having patience with my lack of knowledge. I will mess around with this more and see if I can understand it better
137 2015-03-25 17:52:59 <phantomcircuit> gavinandresen, hmm interesting
138 2015-03-25 18:05:19 <waxwing> is sergio lerner here at all?
139 2015-03-25 19:03:01 <denisx> what is the % of version blocks right now?
140 2015-03-25 19:03:05 <denisx> version 3
141 2015-03-25 19:03:34 <Luke-Jr> tail debug.log
142 2015-03-25 19:04:24 <Luke-Jr> eh, I thought it was in there..
143 2015-03-25 19:08:18 <denisx> Luke-Jr: yeah, me too
144 2015-03-25 19:08:26 <denisx> Luke-Jr: it was there some time ago
145 2015-03-25 19:08:30 <cfields> wumpus: ping. Any reason to hold on https://github.com/bitcoin/bitcoin/pull/5812 ?
146 2015-03-25 19:09:46 <phantomcircuit> it's in there for releases without the softfork
147 2015-03-25 19:09:48 <phantomcircuit> which is ironic
148 2015-03-25 19:18:15 <gavinandresen> denisx: 22% of last 100 blocks are version 3:  https://0bin.zertrin.org/paste/c184d267b8796a22565782dcc9e3b354894ca02e#zR0P5mhEmjFXrbfkSiVD22gC7LEuuR6Pw2uk5IV9vlw=
149 2015-03-25 19:18:33 <denisx> gavinandresen: thanks
150 2015-03-25 19:22:51 <denisx> is the getwork code in 0.10 completely removed or only the rpc call for it?
151 2015-03-25 19:23:19 <Luke-Jr> define "getwork code"?
152 2015-03-25 19:23:34 <Luke-Jr> the internal miner still exists, which uses a lot of the same stuff at least
153 2015-03-25 19:24:13 <denisx> Luke-Jr: the code behind the getwork rpc call
154 2015-03-25 19:24:37 <Luke-Jr> denisx: most of that code is common to GBT, and even more with the internal miner
155 2015-03-25 19:24:46 <denisx> the swiss money museum has an installation which uses getwork on my pool
156 2015-03-25 19:32:32 <morcos> does anyone have the blocks from the mar 2013 fork?  it seems like that would be good data for testing non trivial length reorgs
157 2015-03-25 19:37:13 <gmaxwell> morcos: I probably do someplace(?).. but perhaps better: I have a testnet blocks file with a many thousands of blocks reorg.
158 2015-03-25 19:39:58 <terranpants> So I'm compiling under 10.9 OSX and I successfully got a .app file but I get a runtime error: Assertion failed: (!pthread_mutex_lock(&m)), function lock, file /opt/local/include/boost/thread/pthread/recursive_mutex.hpp, line 110
159 2015-03-25 19:40:08 <terranpants> Any guess where I would look to even start to debug this?
160 2015-03-25 19:40:19 <terranpants> I thought sync.h but it doesnt appear to be there
161 2015-03-25 19:43:15 <morcos> gmaxwell:  I'd be interested in both.   mainnet because it maybe would have somewhat representative transaction duplication rates and orders..   No hurry, but if you ever come across them..
162 2015-03-25 19:45:47 <gmaxwell> morcos: I'll grab both when I get home.
163 2015-03-25 19:47:50 <morcos> thanks!
164 2015-03-25 20:01:25 <ajweiss> terranpants: see build-osx.md in the doc directory in the source tree
165 2015-03-25 20:02:28 <terranpants> I have been following that guide
166 2015-03-25 20:02:44 <terranpants> But I'm not doing gitian or anything, just building directly on my computer
167 2015-03-25 20:03:28 <ajweiss> it should work, i've built on a yosemite box without problems before
168 2015-03-25 20:03:32 <terranpants> I'm finding it hard to determine where in the code this assertion is even trigerred
169 2015-03-25 20:03:45 <ajweiss> that's happening down in a supporting library
170 2015-03-25 20:04:15 <ajweiss> if you get a backtrace with the debugger you can see where it's coming from in the bitcoin code
171 2015-03-25 20:04:27 <terranpants> That is what I need
172 2015-03-25 20:04:30 <ajweiss> but something else is likely wrong, likely in the dependencies or build setup
173 2015-03-25 20:04:52 <terranpants> Maybe Ill start the environment from scratch
174 2015-03-25 20:05:02 <terranpants> really I'm just experimenting with the code and trying to get a better grasp of it
175 2015-03-25 20:05:13 <terranpants> Any recommednations for debuggers?
176 2015-03-25 20:05:20 <terranpants> Pardon my ignorance
177 2015-03-25 20:05:38 <ajweiss> i use gdb, but that's off-topic for here
178 2015-03-25 20:06:35 <terranpants> Sorry don't mean to go off topic
179 2015-03-25 20:06:42 <terranpants> I guess I should jump in the C++ room too
180 2015-03-25 20:36:04 <jhns> In https://en.bitcoin.it/wiki/Script#Standard_Transaction_to_Bitcoin_address_.28pay-to-pubkey-hash.29, the "<sig>", what exactly is signed? the public key?
181 2015-03-25 20:38:07 <gmaxwell> jhns: thats a fine question for #bitcoin
182 2015-03-25 20:39:10 <jhns> okay, thanks
183 2015-03-25 20:44:18 <petertodd> "phantomcircuit> i like how we all make use of heavily encrypted pastebins and then post the encryption keys in public irc channels" <- there are really good reasons to do that - legitimizes the idea that a service shouldn't by default have access to the data stored on it - they should always go out of their way to find out
184 2015-03-25 21:35:28 <petertodd> sipa> the receiver can broadcast the transaction when he agrees with the payment <- this is dangerous from a regulatory perspective, as it makes it easy for the receiver to reject payments from blacklisted funds. (this was actually brought up by some regulatory and legal people at the recent stanford blockchain conference - the US Dept. Of Treasury is aware of how the payment protocol works remarkably)
185 2015-03-25 21:43:44 <petertodd> sipa: in short, because the payment protocol allows the receiver to reject *how* a payment is satisfied we set a precedent that it matters how you pay and what funds you use to pay, which then lets the mechanisms of blacklists/whitelists work better as we already will have technical support for them
186 2015-03-25 21:44:36 <petertodd> sipa: it'd be good to make it clear in the BIP standard that we expect wallets to also try to get the payment ot the receiver via other means; that must definitely not break the mechanism
187 2015-03-25 21:45:43 <dinnu93_> Hello we are trying to spread bit coin in developing nations for more and more activity can anybody donate bitcoins to help us with this process ?
188 2015-03-25 21:46:07 <petertodd> of course, unfortunatley the payment protocol itself is rather dangerous as it provides an easy avenue to satisfy the travel rule requirements that all transactions have metadata attached identifying the actual sender's identity - another US regulatory requirement that people are trying to meet
189 2015-03-25 21:46:27 <petertodd> dinnu93_: take that to #bitcoin
190 2015-03-25 21:46:47 <dinnu93_> petertodd: Thanks would they help ?
191 2015-03-25 21:48:23 <petertodd> dinnu93_: maybe? point is that is off topic here
192 2015-03-25 21:49:02 <teward> dinnu93_: that point's offtopic here, in #Bitcoin, and probably offtopic in other chans (it can be construed as 'begging' which is bannable)
193 2015-03-25 21:49:35 <teward> (your request for 'donate bitcoins' is the problem)
194 2015-03-25 21:49:43 <ajweiss> isn't it possible to bounce any transaction by generating a new one?
195 2015-03-25 21:52:47 <GAit> petertodd: i have been asked to implement such a protocol
196 2015-03-25 21:53:05 <GAit> instead of passing instant metadata passing kyc/aml metadata
197 2015-03-25 21:54:08 <petertodd> GAit: oh, interesting, can you say who asked you?
198 2015-03-25 21:57:13 <GAit> petertodd: not really but it wasn't any player, just someone that understood the BIP70 extention i proposed and thought this idea could be big in egaming and other services that require kyc aml
199 2015-03-25 21:57:54 <petertodd> GAit: ah, too bad - been having a hard time getting any of the players here to be willing to say stuff on the record
200 2015-03-25 21:59:37 <petertodd> GAit: I keep getting into these discussions with people directly and indirectly and no-one wants to go on the record modulo the Dept. of Treasury person
201 2015-03-25 22:00:18 <GAit> about what exactly?
202 2015-03-25 22:00:28 <GAit> sorry let me read back a bit
203 2015-03-25 22:00:58 <petertodd> GAit: in short, getting Bitcoin users to identify themselves/removing anonymity from bitcoin
204 2015-03-25 22:01:48 <petertodd> GAit: e.g. the discussions at the US Dept. of Treasury are leaning towards the idea that the protocol should be changed at the fundemental level to have real-world identity attached to transactions
205 2015-03-25 22:02:31 <petertodd> not an "official" position yet, but officials there see it as an obvious thing to ask for - next step is to force miners to reject transactions without such identifiers
206 2015-03-25 22:04:02 <petertodd> a policy question for them is whether or not that identity information should be public, or encrypted such that only authorized entities (e.g. law enforcement) can decrypt it
207 2015-03-25 22:04:28 <GAit> that would require some world wide centralized db of identities
208 2015-03-25 22:04:49 <GAit> you can pay only if you are an american?
209 2015-03-25 22:04:52 <GAit> can you imagine
210 2015-03-25 22:05:02 <GAit> *with bitcoin
211 2015-03-25 22:05:02 <petertodd> GAit: it would, which those policy makers would like to see happen - it's something being pushed for in other contexts within finance
212 2015-03-25 22:06:01 <petertodd> GAit: well, remember they do know that it's possible to pressure mining pools into adopting this stuff; it's also possible to pressure US companies to only accept BTC payments with this identity info attached - it's ok if it's a gradual process of tightening down
213 2015-03-25 22:06:36 <GAit> you mean like regrep? Dodd Frank?
214 2015-03-25 22:06:46 <petertodd> regrep?
215 2015-03-25 22:06:50 <GAit> regulatory reporting
216 2015-03-25 22:06:57 <petertodd> ah, yup, exacty that kind of thing
217 2015-03-25 22:07:43 <petertodd> for instance, a near term thing might be to say that Coinbase clients can only accept payments over $1k/day if the payments come from non-anonymous sources that obey the travel rule
218 2015-03-25 22:08:12 <GAit> yeah like for cash
219 2015-03-25 22:08:14 <petertodd> they want that identity info to be on the blockchain itself, so that they can then legally pressure miners into adopting those policies as well
220 2015-03-25 22:08:18 <petertodd> GAit: exactly like cash
221 2015-03-25 22:09:26 <GAit> i am confused, they can pressure us miners but surely the rest of the world will take forever to adapt and even within the us, why go after the miners when you can just go after the processors and up and down rumps
222 2015-03-25 22:10:11 <petertodd> GAit: they're not stupid - they know damn well that if you go after just processors and on/off ramps people can bypass that by switching to other processors and ways of converting btc for fiat
223 2015-03-25 22:11:10 <petertodd> GAit: for instance, a discussion I had recently with someone was how it was ineffective to try to regulate exchanges in the US when US citizens could still bypass anti-terrorist blacklists by just sending those people funds directly, who would then do conversion on exchanges outside the US
224 2015-03-25 22:11:37 <petertodd> GAit: the *current* focus on exchanges and payment processors is simply because it's the easiest thing to do right now - the regulations are already written with that in mind
225 2015-03-25 22:12:53 <terranpants> ls
226 2015-03-25 22:13:52 <GAit> it feels like an identity system would just break bitcoin, it can't go anywhere without fungibility can it?
227 2015-03-25 22:14:21 <petertodd> GAit: it probably would - from the point of view of regulators that's 100% acceptable
228 2015-03-25 22:14:47 <petertodd> GAit: bitcoin is a challenge to the spirit of that regulation in pretty fundemental ways
229 2015-03-25 22:15:10 <GAit> regulation requires refactoring indeed
230 2015-03-25 22:17:24 <petertodd> GAit: it's an ugly situation to be in, because Bitcoin is simply unable to comply with certain regulations in pretty fundemental ways - e.g. if Coinbase allows a customer to withdraw money to their own wallet, and that customer sends money to ISIL, laws have been broken; if a mining pool builts on top of a block containing that transaction knowingly, laws have been broken. Those laws aren't going to be enforced soon, but the fact is they have been ...
231 2015-03-25 22:17:30 <petertodd> ... broken.
232 2015-03-25 22:19:05 <GAit> of course and you can break thise laws with gold or cash but we don't regulate the transfer for small amounts
233 2015-03-25 22:20:00 <petertodd> yup, because there is overhead attached - something that keeps coming up re: bitcoin is the fact that you can automate the transferral of small amounts to transfer large amounts in the form of many small transactions is a major concern
234 2015-03-25 22:24:45 <GAit> this is like requiring a licence to blog
235 2015-03-25 22:25:15 <petertodd> GAit: indeed, but unfortunately money is treated differently than speech
236 2015-03-25 22:25:35 <petertodd> just look at the crackdown on hawala, which is nothing more than people calling other people on the phone and writing numbers down in notebooks
237 2015-03-25 22:25:37 <sipa> we should just all be yelling our bitcoin transactions then
238 2015-03-25 22:25:50 <sipa> (yes i know this has nothing to do with free speech)
239 2015-03-25 22:29:50 <petertodd> sipa: well... if the blockchain had more uses than purely finance we'd be in a better position, maybe
240 2015-03-25 22:32:33 <GAit> quick, let's use the blockchain as the storage for a p2p blog system!
241 2015-03-25 22:33:27 <petertodd> GAit: heh, well, if it was keeping the p2p blog system secure in *some* way - doesn't have to be directly storage :)
242 2015-03-25 22:33:47 <GAit> then i am pretty sure some people are already doing it
243 2015-03-25 22:34:17 <petertodd> yup, and the more of that the better re: regulation
244 2015-03-25 22:34:39 <petertodd> it'd be good if more of those uses are indistinguishable from normal transactions too, so they can't be whitelisted
245 2015-03-25 23:55:15 <dgenr8> all very reminiscent of the US ban on encryption in years past