1 2014-01-02 00:01:15 <comboy> getaddr returns only nodes that given peer has been connected to or also addrs received from others?
  2 2014-01-02 00:30:56 <gmaxwell> hehe: https://proofmarket.org/
  3 2014-01-02 00:31:22 <gmaxwell> now, just need a COQ to SNARK compiler and support in Bitcoin to make that trustless. :P
  4 2014-01-02 00:35:05 <robonerd> meh
  5 2014-01-02 00:35:12 <robonerd> stackoverflow ftw
  6 2014-01-02 01:05:43 <nessence> gmaxwell: what is the idea behind "Switch to block hashing algorithm secure against block withholding attacks."?
  7 2014-01-02 01:06:13 <nessence> er, if that's something you happened to have considered
  8 2014-01-02 01:06:54 <gmaxwell> nessence: I think these days I probably want to do the opposite— (e.g. make cloud hashing impossible to secure)... but the thought there is easy to explain.
  9 2014-01-02 01:07:58 <gmaxwell> nessence: make it so that the difficulty of a block is tested in two stages. E.g. H(header) < target_1  AND H(header||pool_nonce) < target_2 with H(pool_nonce) committed in the block.
 10 2014-01-02 01:08:34 <gmaxwell> then target_1 is just a share difficulty, and target_2 is the pool difficulty. Then the miner can tell if he has a share, but can't tell if he has a block.
 11 2014-01-02 01:09:26 <gmaxwell> But doing that would break some of the "selfish mining" fixes, plus doing things that _lower_ the costs of hashpower consolidations (like the risk of withholding attacks) would be the wrong direction.
 12 2014-01-02 01:09:53 <nessence> that'd probably be nice for the next 6.5yrs
 13 2014-01-02 01:13:27 <nessence> how does the second hash discourage withholding transactions?
 14 2014-01-02 01:15:30 <nessence> I was thinking earlier today that miners could charge people (out of band) to prioritize inclusion of their transactions
 15 2014-01-02 01:18:24 <gmaxwell> nessence: oh perhaps you didn't understand the problem that the text you were speaking about was concerned with.
 16 2014-01-02 01:18:49 <nessence> ah, crap, you're right
 17 2014-01-02 01:18:50 <gmaxwell> It's concerned with "block withholding", which is an attack on mining pools where the miner discards any blocks they find, in order to bankrupt the pool.
 18 2014-01-02 01:19:03 <nessence> I guess instead of the word block, I saw the word transaction
 19 2014-01-02 01:19:29 <nessence> I can see how the nonce resolves that
 20 2014-01-02 01:20:40 <gmaxwell> It's costly to the attacker too, which is part of why it doesn't appear to be a major problem there are other things pools can do, like make 1% of their payout take the form of bonuses for finding blocks— increases variance for small miners but makes withholding even less attractive.
 21 2014-01-02 01:22:33 <nessence> I think it's only costly right now because it's not a problem yet, because there aren't enough transactions for there to be a market for it
 22 2014-01-02 01:23:25 <nessence> the volume is low enough that it probably wouldn't be worth it to write the code
 23 2014-01-02 01:24:01 <nessence> but if two people have 90% of the throughput, they can work together to replace the wireline fee with their own fee
 24 2014-01-02 01:24:16 <nessence> or is that too far fetched?
 25 2014-01-02 01:26:14 <gmaxwell> huh?
 26 2014-01-02 01:26:58 <shesek> I'm not sure when I got disconnected, so I'll re-post it:
 27 2014-01-02 01:27:00 <shesek> <shesek> how does that help?
 28 2014-01-02 01:27:02 <shesek> <shesek> and why's "Elimination of output scripts: all transactions pay-to-scripthash" considered an hard fork?
 29 2014-01-02 01:27:05 <shesek> (the first question was about the two stage difficulty test)
 30 2014-01-02 01:27:37 <nessence> gmaxwell: a transaction commits by way of a miner solving a block?
 31 2014-01-02 01:28:00 <gmaxwell> shesek: go look at the logs and I explained it more http://bitcoinstats.com/irc/bitcoin-dev/logs/2014/01/02
 32 2014-01-02 01:28:57 <shesek> ah, I only saw what you wrote until "make it so that the difficulty of a block is tested in two stages ..."
 33 2014-01-02 01:29:27 <gmaxwell> shesek: prohibiting something is a soft-fork, though really disruptive soft-forking changes are "compariable" to hardforks in the timing or caution in deploying them. If bitcoin really were to eliminate non-P2SH transactions there would probably be some refactoring to make that simpler.
 34 2014-01-02 01:30:23 <gmaxwell> most of that hardfork wishlist stuff was written in late 2011 I think, it would be somewhat different if written today.
 35 2014-01-02 01:30:53 <gmaxwell> (changing everything to something P2SH like would still be there though)
 36 2014-01-02 01:30:54 <shesek> oh, right. I was thinking "eliminate" just meant always using p2sh as the default, not forbidding non-p2sh outputs
 37 2014-01-02 01:31:24 <gmaxwell> yea, no, you don't get the simplification unless you get rid of the old stuff. :)
 38 2014-01-02 01:32:44 <nessence> gmaxwell: if pool A had 40% hashpower and pool B had 40% hashpower, is pool A+B going to solve 80% of the blocks?
 39 2014-01-02 01:33:41 <shesek> wouldn't that kill the option of using OP_RETURN for storing data though?
 40 2014-01-02 01:34:21 <shesek> and also, make it impossible to know if an output is prunable?
 41 2014-01-02 01:35:47 <gmaxwell> nessence: yes.
 42 2014-01-02 01:36:26 <gmaxwell> shesek: it would be better to just have a not-an-output data in transactions, preferrably behind a hash, so that the transaction minus that data could be proven without that data.
 43 2014-01-02 01:37:16 <gmaxwell> shesek: Have you seen the P2SH^2 post? http://sourceforge.net/mailarchive/message.php?msg_id=30705609
 44 2014-01-02 01:37:48 <shesek> reading now
 45 2014-01-02 01:38:53 <gmaxwell> (I think in general the technical minds consider data storage (as opposed to data commitments) to be a minor existential risk for Bitcoin, though probably not one worth doing anything about except guiding people to the least damaging ways to do it.)
 46 2014-01-02 01:39:47 <phantomcircuit> gmaxwell, quick put the blockchain in a DHT
 47 2014-01-02 01:39:52 <phantomcircuit> 
ACTION runs away

 48 2014-01-02 01:42:26 <nessence> gmaxwell: so, once transaction volume reaches say... 10 transactions per second, even if there are 1000 mining pools... those 2 pool owners could just silently withhold transactions. Your transaction will then only have a 20% chance of making it into this block, 20% of next block, etc. Meanwhile the rest of the network will be buffering these transactions.
 49 2014-01-02 01:43:32 <gmaxwell> nessence: You are providing a lot of extranious details there that suggest confusion to me. Why do you think "transactions per second" is relevant?
 50 2014-01-02 01:44:00 <gmaxwell> also, for the purpose of common language, I'd probably not use the word "withhold", I'd call it "censor" or "block"
 51 2014-01-02 01:44:03 <nessence> right now the average volume is so slow, why would a mining pool even bother with the idea?
 52 2014-01-02 01:44:20 <gmaxwell> nessence: Yea, so your response still makes no sense to me.
 53 2014-01-02 01:44:22 <nessence> or drop, perhaps
 54 2014-01-02 01:44:29 <gmaxwell> Can you explain to me why you think volume matters?
 55 2014-01-02 01:45:16 <nessence> if I have a pool w/80% hash throughput, and there are 100 transactions per second occurring, why should I include any 0.01BTC transaction in my blocks?
 56 2014-01-02 01:45:55 <gmaxwell> nessence: why not, if they're the highest paying transactions per byte that fit in the block?
 57 2014-01-02 01:46:28 <gmaxwell> Already the behavior of miners is to rank transactions by the fee per byte and include the most profitable ones first— thats how you get a fee market.
 58 2014-01-02 01:46:46 <gmaxwell> Including just everything with no selection creates a trivial DOS vulnerability.
 59 2014-01-02 01:47:58 <nessence> hrm
 60 2014-01-02 01:48:08 <gmaxwell> More potent is that miners can censor transactions even if they are higher paying... and some do today. Usually for reasons which they believe are protective of the network, but the same capability could be used for purposes most would agree were bad in the future. This is part of why it's important to not reuse addresses in bitcoin since doing so makes censoring more viable.
 61 2014-01-02 01:48:09 <nessence> a 1.00 BTC transaction uses more bytes than 0.01BTC?
 62 2014-01-02 01:48:22 <gmaxwell> nessence: no. The value and bytes are not directly related.
 63 2014-01-02 01:48:47 <gmaxwell> A transaction which spends more previous outputs is larger, and a transaction which creates more new outputs is somewhat larger.
 64 2014-01-02 01:49:09 <shesek> gmaxwell, interesting solution, definitely makes sense to only allow hashes for data verification and force the actual storage to take place elsewhere
 65 2014-01-02 01:49:10 <nessence> yeah, that was the other thing I was going to mention. They can censor all transactions > 1BTC unless you pay them under the table
 66 2014-01-02 01:49:50 <nessence> or heck. censor every transaction unless you pay them
 67 2014-01-02 01:50:00 <shesek> I see a lot of interesting use-cases for storing hashes that could benefit from using bitcoin's blockchain, not so much for arbitrary data storage
 68 2014-01-02 01:50:04 <phantomcircuit> nessence, that would be economically irrational in nearly every case
 69 2014-01-02 01:50:19 <gmaxwell> shesek: yea, I dunno if we'll ever implement something like that in bitcoin. The problem is that people won't think its important until its too late. (e.g. some authority saying its unlawful to run a bitcoin full node because of some forbidden data someone stuffed in a transaction) ("But don't worry, you can use a thin client, and the state is running this nice node for you.")
 70 2014-01-02 01:50:56 <gmaxwell> shesek: yea, though with merged mined hasttrees you don't even need the hashes in the blocks, just a single hash of a tree of hashes. So that takes no space at all.
 71 2014-01-02 01:51:24 <gmaxwell> nessence: they can, but it's not very effective unless malicious parties control a majority of hashpower.
 72 2014-01-02 01:51:36 <gmaxwell> Sadly, the poor distribution of control of hashpower now means thats not out of the question.
 73 2014-01-02 01:51:43 <gmaxwell> But that isn't the intended design of the system. :(
 74 2014-01-02 01:51:46 <shesek> well, it does, it takes the space of one hash
 75 2014-01-02 01:51:52 <nessence> well, I guess the point is that, for a given transaction, there's a criteria such that a miner could make more by censoring those transactions and charging a premium to include them
 76 2014-01-02 01:51:59 <gmaxwell> shesek: we already have a data commitment hash in most blocks.
 77 2014-01-02 01:52:00 <phantomcircuit> shesek, ~0 then
 78 2014-01-02 01:52:07 <gmaxwell> shesek: so no more than we already have. :P
 79 2014-01-02 01:52:12 <gmaxwell> (for merged mining)
 80 2014-01-02 01:52:28 <shesek> and it requires cooperation with some parties to include it, which takes away some of the decentralization
 81 2014-01-02 01:52:34 <phantomcircuit> nessence, except some other miner would incorporate them
 82 2014-01-02 01:52:59 <gmaxwell> shesek: well, ehh, all bitcoin requires mining cooperation. The only difference is what the software does by default, which could be changed.
 83 2014-01-02 01:54:11 <gmaxwell> (and I think if someone showed up with good patches to add by-default-data commitment stuff I would be strongly in favor of merging them. ... Sure, it's "outside of bitcoin's scope" but it would prevent a lot of inefficient usage.)
 84 2014-01-02 01:55:57 <shesek> so how does it work? how do/would I get a hash into the merkle tree whose root is getting included in the block?
 85 2014-01-02 01:56:33 <shesek> would there some way to broadcast it using bitcoin's p2p network? what's to motive to include it?
 86 2014-01-02 01:57:22 <shesek> I assume you can't attach fees to it, so what's the incentive?
 87 2014-01-02 01:59:23 <gmaxwell> The motivation is to keep shit out of the bitcoin blockchain (in every bitcoin user's interest). Payment could be in the form of proving you paid transaction fees in the past.
 88 2014-01-02 01:59:53 <gmaxwell> (e.g. no marginal transactions per commitment)  or in the form of a probablistic payment of some kind.
 89 2014-01-02 02:01:07 <gmaxwell> as far as getting data in, probably by having nodes flood announcement of willingness to accept and aggregate them. There are a number of ways it could be constructed. I suspect someone who sat down to implement would have a better feel for which ways they preferred.
 90 2014-01-02 02:01:18 <shesek> I think we're already seeing the tragedy of the commons in action (like what's going on with cex/ghash), I'm not sure that keeping shit out the blockchain is a good enough incentive for people
 91 2014-01-02 02:02:18 <shesek> how about protecting against ddos attacks on those nodes?
 92 2014-01-02 02:03:04 <shesek> I dunno, it just seems like the way transactions work already resolves a lot of possible issues with that
 93 2014-01-02 02:03:12 <gmaxwell> shesek: just use the same mechnisms that prevents them from being DDOSed today.
 94 2014-01-02 02:03:59 <gmaxwell> E.g. your request to commit data comes in the form of a transaction which spends spendable coins. Just one thats made invalid (e.g. by being locked until a billion years into the future) so it can't actually get in the chain.
 95 2014-01-02 02:04:30 <gmaxwell> or by commiting to it in a probablistic payment that only as a 1:10000 chance of being minable.
 96 2014-01-02 02:05:35 <shesek> so they'll keep track of which outputs were already used for that?
 97 2014-01-02 02:05:54 <gmaxwell> yea, via a limitedmap or the like.
 98 2014-01-02 02:06:15 <gmaxwell> (capacitated random hashtable)
 99 2014-01-02 02:06:16 <shesek> you could just pay them for inclusion beforehand, but than you still end up with a tx for every committed hash :\
100 2014-01-02 02:06:45 <shesek> so what prevents one from moving the coins to a output and using that? they'll take the coin age into account?
101 2014-01-02 02:06:50 <shesek> * a new output
102 2014-01-02 02:06:52 <gmaxwell> yea, and plus if you have a direct pay for like that it may well be too expensive. The proper price for commitments is ~0 because you could always nest commitments.
103 2014-01-02 02:08:01 <shesek> it still requires holding the tree in memory and hashing it, so there's some ram and cpu that's being used for that (but yeah, the cost is pretty close to 0)
104 2014-01-02 02:09:02 <gmaxwell> see open transactions, petertodd uses a insertion ordered tree that requires log2(n) storage. In theory the commiting party can forget the data as they commit it.
105 2014-01-02 02:09:29 <gmaxwell> (incrementally I mean, you're never require to store more than log2(n) hashes.)
106 2014-01-02 02:10:17 <gmaxwell> its trivially cheap in any case. Ignoring the more direct bitcoin tie-ins you can probalby using mining hashcash as a POW to prevent flooding.
107 2014-01-02 02:10:46 <gmaxwell> probably* :)
108 2014-01-02 02:11:26 <gmaxwell> in any case, this infrastructure just doesn't exist in part because there is no way to monetize it, and while bitcoin users will dump millions on make money fast schemes they generally will not fund common infrastructure.
109 2014-01-02 02:11:36 <shesek> don't they still need to give each committer the parts of the merkle tree that he needs in order to prove his hash is in there?
110 2014-01-02 02:13:10 <gmaxwell> shesek: yes, but the tree grows incrementally meaning you could, if you wanted, give them one addtional hash at a time as it grows.
111 2014-01-02 02:14:47 <gmaxwell> in any case, talking about the cost of the trees is kinda blue skies stuff. Consider stamping a million items per block, thats 32 mbytes of hashes.. no big deal, and a million items is enormous, and yet 32mbytes is cheap, something that widely used could presumably find ways to support itself.
112 2014-01-02 02:15:05 <shesek> so the committer would have to stay connected and receive those messages until its finalized and mined?
113 2014-01-02 02:15:33 <gmaxwell> yea, if you wanted to use that optimization that made the tree builder memoryless.
114 2014-01-02 02:17:02 <gmaxwell> shesek: e.g. you have some channel to communicate back the proofs,  so you just transmit on it every time the amount being committed doubles, telling everyone of an extra hash.
115 2014-01-02 02:18:25 <gmaxwell> e.g. you give them data, then someone else gives them data and they tell the two players the adj hashes. Then two more people give them data, and it tells each of the four players the adj hashes. The server itself just needs to remember the rightmost nodes long the tree as it grows.
116 2014-01-02 02:19:13 <gmaxwell> though I think, realisitcally, just having the aggregating node use 32mbytes of storage and be only willing to commit to proofs up to 20 levels deep (a million entries), is probably perfectly reasonable.
117 2014-01-02 02:19:48 <gmaxwell> I think the worldwide need for bitcoin stamped commitments is way less than that, and if I'm wrong you can just stack another system inside of it.
118 2014-01-02 02:20:57 <shesek> you could have an hierarchical tree of aggregating nodes, each giving his hash root to a bigger merkle tree
119 2014-01-02 02:21:13 <shesek> like a merkle tree of nodes, where each keeps track of its own internal tree
120 2014-01-02 02:21:26 <gmaxwell> fwiw, NTP seems to be surviving pretty well, and has no direct monetization scheme, likewise for DNS resolvers (well, they're considered necessary for ISPs, ... but we could consider bitcoin stamper aggregation a criticial internet infrastructure someday)
121 2014-01-02 02:21:26 <shesek> that could scale to pretty much anything
122 2014-01-02 02:22:45 <gmaxwell> shesek: yea thats why I say the fair price for this is ~0 because if you have a stamper that costs X, well I can build a substamper which supports up to Y, for Y→∞ substamps, and the stamper can't even block me from doing that. So the natural price in a competative market is probably very close to 0 (just blocked by the development and startup cost friction)
123 2014-01-02 02:24:32 <shesek> I agree - the actual resources needed for operating this are close to nothing and the payment for committing an hash is indeed ~0
124 2014-01-02 02:25:08 <shesek> but what's the motivation for people to take the hassle of setting this up? just goodwill and care about the bitcoin network?
125 2014-01-02 02:25:13 <gmaxwell> so I _think_ it's in bitcoin users/holders best interest to just build and run the damn thing to keep people who want the service from kluding it poorly and externalizing an even greater cost onto us.
126 2014-01-02 02:25:25 <shesek> if Bitcoin mining was based on that, we'd go nowhere :)
127 2014-01-02 02:25:29 <gmaxwell> Because people doing it in the O(N) way makes bitcoin less useful as a currency.
128 2014-01-02 02:25:52 <gmaxwell> And bitcoin is already useful is a currency, so there is some expected value loss if we don't. Though I dunno how to cut through the freeloading.
129 2014-01-02 02:25:55 <shesek> I'm afraid that everyone would just assume that someone else would take care of that...
130 2014-01-02 02:26:02 <gmaxwell> yea, thus freeloading. :)
131 2014-01-02 02:27:17 <gmaxwell> A lot of open source software has no obvious direct economically rational reason to exist in any case, it just sort of happens, and then its easier to improve it.
132 2014-01-02 02:37:30 <shesek> wouldn't it be easier to have services that commit the root hash in a single transaction?
133 2014-01-02 02:37:41 <shesek> so that it wouldn't depend on having mining power?
134 2014-01-02 02:38:10 <nessence> 
ACTION isn't very good at preventing coercion in a capitalistic work environment

135 2014-01-02 02:38:25 <shesek> you'll end up with more transactions from multiple services, but its still pretty negligible and doesn't depend on the willingness of pools to participate
136 2014-01-02 02:40:01 <shesek> plus those services could commit their hash root to another one of those services
137 2014-01-02 02:40:29 <shesek> so it could even end up as a single tx, if everyone eventually delegates to the same top service
138 2014-01-02 02:43:05 <gmaxwell> shesek: it still depends on miners willingness to not block it. Besides, you're then requiring _additional_ parties who might want to monetize it, when it could just be some largely invisibile software behavior in programs miners already run, basically a one time cost.
139 2014-01-02 02:44:22 <shesek> oh, you think its possible to have it integrated directly into bitcoind and on by default?
140 2014-01-02 02:44:46 <gmaxwell> yep
141 2014-01-02 02:44:48 <shesek> yeah, that does make it much easier
142 2014-01-02 02:45:53 <gmaxwell> basically it changes it to just the development cost, .. and then it would just be a question of it being cheap enough to run that no one would bother turning it off... and I believe thats not hard to achieve.
143 2014-01-02 02:45:56 <nessence> bitcoin really isn't evil right now. miners are handsomely rewarded no matter how honest they are :P (at a transactional level)
144 2014-01-02 02:46:45 <shesek> btw, I've been thinking on changing the way btproof works (currently it spams the utxo... shame on the younger naive me who didn't know better). what would you suggest to do that's possible right now?
145 2014-01-02 02:48:27 <shesek> I could at least avoid spamming the utxo with OP_RETURN, which isn't ideal but still better than what its currently doing
146 2014-01-02 02:49:03 <gmaxwell> shesek: oh is btproof yours?
147 2014-01-02 02:49:03 <shesek> but that would probably be hard to get mined, which could be problematic with time-sensitive timestamps
148 2014-01-02 02:49:49 <shesek> yeah, it is
149 2014-01-02 02:50:29 <shesek> I know what it currently does is quite awful, I did that a long time ago :-\
150 2014-01-02 02:50:37 <gmaxwell> shesek: you could switch to what opentimestamps does... builds it's own hashtree and uses multisig to commit it in a spendable output. (one of two, and one public key is the data). OP_RETURN would be slightly preferable but you'll have problems getting it mined right now.  (Eligius will mine op_return but not if they carry any data at all).
151 2014-01-02 02:51:06 <shesek> yeah, 1-of-2 was my other option
152 2014-01-02 02:51:17 <warren> would the chronobit approach work if you had enough pools cooperating?
153 2014-01-02 02:51:35 <gmaxwell> warren: sure, it just requires someone to actually do and maintain the software.
154 2014-01-02 02:51:51 <shesek> but it would require using an api btproof would provide, I wanted to allow people to do that in-browser themselves without having the server involved
155 2014-01-02 02:52:07 <shesek> but it might be a bad idea to pursue that option
156 2014-01-02 02:52:41 <gmaxwell> shesek: you can also convert delays into benefits.  E.g. the advantage of having an aggregation point is that you can also get a conventional timestamp from the aggregator which can be much more precise (though obviously less trustworthy, but with a source of trust which is easier to explain)
157 2014-01-02 02:53:41 <maaku> gmaxwell: i'd love to see your new hard-fork wishlist ;)
158 2014-01-02 02:53:43 <shesek> if you commit to the blockchain once a day, it gives the service operator a whole 24 hours range it can lie about
159 2014-01-02 02:53:57 <gmaxwell> e.g. any commitment gives you two times, one from the aggregator which is as precise and reliable as he is, and one from the bitcoin network.
160 2014-01-02 02:54:00 <shesek> I can see courts trusting the blockchain, not so much trusting server operators
161 2014-01-02 02:54:09 <shesek> * service
162 2014-01-02 02:55:00 <gmaxwell> shesek: aggregating once per block is still always no worse than no aggregation.
163 2014-01-02 02:56:17 <shesek> its hard to do that reliably, how do you know when to broadcast?
164 2014-01-02 02:56:23 <gmaxwell> e.g. just produce a commitment transaction up to once an hour, maybe it's only commiting one thing sometimes, but thats in no way worse than one transaction per item.
165 2014-01-02 02:56:39 <gmaxwell> shesek: one hour from the first item you have in the queue. :P
166 2014-01-02 02:56:58 <shesek> its once per 6 blocks on average, not once per block
167 2014-01-02 02:57:30 <shesek> but yeah, its a good option with no downside other than adding a small delay between the timestamp request and when its mined
168 2014-01-02 02:57:43 <gmaxwell> well I switched from saying once per block to once per hour because I thought once per time was easier to implement, and because once per hour was a good natural speed.
169 2014-01-02 02:57:47 <shesek> one hour shouldn't be critical in most cases
170 2014-01-02 02:58:12 <gmaxwell> (there are applications which care about timestamps faster than once per hour but they cannot be satisfied by any blockchain regardless, though the notary's own clock may be sufficient)
171 2014-01-02 02:58:33 <gmaxwell> keep in mind the bitcoin blockchan only has very lose promises about time.
172 2014-01-02 02:59:19 <shesek> yes, of course
173 2014-01-02 02:59:20 <gmaxwell> I've observed blocks with times an hour in the past and well over an hour (1.5?) in the future.
174 2014-01-02 03:00:18 <nessence> I certainly hope I'm on a pool that's not changing the timestamp
175 2014-01-02 03:00:57 <gmaxwell> nessence: 'changing' ... there isn't any need for changing, though many miners roll the time by 128 or 256 seconds. it's just that not everone agrees on the time.
176 2014-01-02 03:01:07 <gmaxwell> (nor do they need to, nor would it be desirable to)
177 2014-01-02 03:01:57 <gmaxwell> a serious enough notary service could even coordinate getting centeralized timestamps from several independent parties.
178 2014-01-02 03:02:48 <shesek> so, you think I should abandon the in-browser one-tx-per-timestamp thing? would it be terrible if btproof allowed that, but aggregated the timestamp it does server side? (it would do it server-side for users who request to have it done for them and for timestamp requests via the api)
179 2014-01-02 03:04:27 <nessence> I wonder how much incrementing the 576th bit of the header changes the probability of solving a block
180 2014-01-02 03:05:01 <gmaxwell> meh, I think the in-browser one-tx-per is just kind of a trap, eventually transaction fees may make it unrelable unless you over pay for it anyways.
181 2014-01-02 03:05:49 <gmaxwell> shesek: I think you should see if you can perhaps back your server up with petertodd's OT thing. better to have more thing colaborating on fewer timestamps.
182 2014-01-02 03:07:20 <shesek> yeah, I should definitely take a look at working with OT. back when I created btproof I didn't know the technical aspects of bitcoin much and dismissed it as too complicated :)
183 2014-01-02 03:08:03 <shesek> I just think its much nicer to allow people to timestamp the data themselves directly to the blockchain, without being depended on a service that did it for them
184 2014-01-02 03:09:08 <shesek> and with 1-of-2 its at least prunable... thought its obviously still not ideal
185 2014-01-02 03:09:15 <gmaxwell> It is nicer, but not scalable. At least unless/until we integrate aggregation into the network, and then its scalable again.
186 2014-01-02 03:11:39 <shesek> won't pruning make it scalable too?
187 2014-01-02 03:11:59 <shesek> well, at least more scalable
188 2014-01-02 03:12:51 <shesek> aggregating it is a lot more scalable obviously, but pruning should also make those one-tx-per-timestamp easier to handle
189 2014-01-02 03:13:31 <dredredre> Why is it that almost all addresses in recent transactions begin with 1? Does this suggest that whomever is generating these wallets is not using enough entropy?
190 2014-01-02 03:14:56 <shesek> dredredre, all addresses begin in 1
191 2014-01-02 03:15:02 <shesek> well, all pay-to-pubkey-hash addresses, that is
192 2014-01-02 03:15:16 <PRab> dredredre: https://en.bitcoin.it/wiki/Address. In general all basic addresses start with 1.
193 2014-01-02 03:15:39 <dredredre> interesting.. thx
194 2014-01-02 03:16:08 <gmaxwell> shesek: no, pruning doesn't make it scalable, it's still an O(N) forever cost for the whole network, it's just a cost with a lower constant factor.
195 2014-01-02 03:16:56 <gmaxwell> because not every full node needs to constantly store the data, its still must be widely available, however, because it's needed to validate blocks, bring up new nodes, and scan historical txn to rebuild wallets.
196 2014-01-02 03:16:56 <justanotheruser> dredredre: becasue the version number for pubkey addresses is 00, which in bitcoin-defined base58 is 1
197 2014-01-02 03:23:23 <shesek> gmaxwell, yeah, I am aware of that, but its still a lot better than having everyone store it forever
198 2014-01-02 03:24:30 <shesek> ugh, I'm not sure how to go about it. I think I might indeed just kill the in-browser option and force people to do it via the service and aggregate it
199 2014-01-02 03:25:43 <bitanarchy> how do mastercoins exist?
200 2014-01-02 03:26:20 <maaku> bitanarchy: #mastercoin
201 2014-01-02 03:26:27 <nessence> bitanarchy: if enough people believe they exist, then they *might* exist https://blockchain.info/address/1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P
202 2014-01-02 03:26:34 <nessence> #scam
203 2014-01-02 03:28:48 <bitanarchy> nessence: are mastercoins coins that have gone through the exodus address?
204 2014-01-02 03:29:18 <nessence> bitanarchy: yeah. better link if you're curious https://blockchain.info/address/1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P?filter=1
205 2014-01-02 03:31:49 <nessence> gmaxwell: what would you think if the difficulty of H(header||pool_nonce) was inversely based on the count of input and output addresses from the previous block?
206 2014-01-02 03:46:58 <jacob___> hi
207 2014-01-02 04:35:19 <nessence> meh. they could pad the blocks with fake transactions :/
208 2014-01-02 07:00:47 <dredredre> am I correct in saying that each private key has 2 effective addresses 1 compressed and 1 uncompressed?
209 2014-01-02 07:01:35 <Luke-Jr> 4
210 2014-01-02 07:02:05 <Luke-Jr> compressed/uncompressed + pubkeyhash/scripthash
211 2014-01-02 07:09:32 <ahmedbodi_> Hello guys
212 2014-01-02 07:10:11 <ahmedbodi_> Does anyone know if its possible for a pool to only send out its transactions
213 2014-01-02 07:10:20 <ahmedbodi_> In one of its on mined blocks
214 2014-01-02 07:10:34 <brisque> as in, transactions only belonging to them and nobody else?
215 2014-01-02 07:10:35 <ahmedbodi_> So no tax fees need to be paid by users
216 2014-01-02 07:10:47 <ahmedbodi_> Yes
217 2014-01-02 07:11:04 <ahmedbodi_> Transactions made by the pool itself
218 2014-01-02 07:11:04 <brisque> a pool can include absolutely anything they want, including public transactions if they choose.
219 2014-01-02 07:11:28 <ahmedbodi_> I see, any ideas how?
220 2014-01-02 07:11:45 <ahmedbodi_> I'd guess gbt would be needed to do so
221 2014-01-02 07:11:56 <brisque> it depends on the software, I'm not in a position to give a walkthrough.
222 2014-01-02 07:12:22 <ahmedbodi_> Ahh so it'd be dependant on the pool server
223 2014-01-02 07:12:44 <brisque> yes, except for GPT and when using p2pool (to a certain extent)
224 2014-01-02 07:13:17 <ahmedbodi_> What's makes it different when using get block template?
225 2014-01-02 07:15:35 <brisque> GBT allows the mining client to choose their own transactions for inclusion, the pool has less control.
226 2014-01-02 07:16:16 <ahmedbodi_> Ahh okay
227 2014-01-02 07:16:31 <ahmedbodi_> With stratum the miners don't have control
228 2014-01-02 07:17:14 <ahmedbodi_> I don't use gbt anyway (yet) want to add it to stratum-mining tho
229 2014-01-02 07:17:46 <brisque> yes, with stratum the mining clients are completely blind as to what they are mining on.
230 2014-01-02 07:18:08 <ahmedbodi_> Okay cool
231 2014-01-02 07:18:35 <ahmedbodi_> So on the pool end I'd need to make stratum include the pools own transactions?
232 2014-01-02 07:19:24 <brisque> yes, it's completely up to the poolserver as to what transactions they include in the block header that is presented to the stratum miners.
233 2014-01-02 07:20:05 <ahmedbodi_> Alright cool do u know if anyone done it so far
234 2014-01-02 07:22:09 <brisque> most pools seem to have their own logic for inclusion. some notably include none, where some include a small number of transactions even with long block spacing. we can assume they already do what you are talking about. Eligius does specifically allow submission of unusual transactions.
235 2014-01-02 07:22:54 <ahmedbodi_> Okay
236 2014-01-02 07:23:26 <ahmedbodi_> So in that they are likely to include their own transactions so fees don't need to be paid?
237 2014-01-02 07:25:09 <brisque> I don't know if they do, but it is technically possible. a large pool could even team up with a company to process their 0 fee transactions for a set monthly sum if they wanted to. the transaction selection process is completely up to the person creating the blocks.
238 2014-01-02 07:25:43 <brisque> the only rules really are that the transactions must be valid, and the coinbase transaction must contain unique data.
239 2014-01-02 07:26:09 <ahmedbodi_> Alright thanks I guess, I'll look into adding it :)
240 2014-01-02 07:27:01 <atian> brisque: Eligius used to have partnership with MtGox to include free transactions :)
241 2014-01-02 07:28:20 <brisque> atian: oh neat, I wasn't aware of that.
242 2014-01-02 09:31:37 <michagogo> cloud|9:00:43 <dredredre> am I correct in saying that each private key has 2 effective addresses 1 compressed and 1 uncompressed?
243 2014-01-02 09:31:50 <michagogo> cloud|An ECDSA private key, yes.
244 2014-01-02 09:32:02 <michagogo> cloud|A Bitcoin private key, no
245 2014-01-02 09:35:56 <shesek> how so? what's the distinction you're making between the two?
246 2014-01-02 09:36:24 <brisque> a bitcoin private key contains an identifier of what type it is, when it's in the WIF format.
247 2014-01-02 09:36:47 <shesek> yes, the 0x01 flag, but he's saying it the other way around
248 2014-01-02 09:37:35 <brisque> he's saying that a bitcoin private key isn't ambiguous, which it isn't. the version byte tells me if it's a compressed point or not.
249 2014-01-02 09:38:06 <sipa> comboy: any
250 2014-01-02 09:38:35 <shesek> ah, right. I misunderstood what michagogo was saying.
251 2014-01-02 09:38:40 <brisque> 0x01 is a bitcoin address anyway. the private keys have a different version byte
252 2014-01-02 09:38:47 <BlueMatt> why did fortune just spit out "I smell a wumpus."?
253 2014-01-02 09:39:00 <BlueMatt> oh, wumpus isnt here :(
254 2014-01-02 09:42:09 <sipa> shesek: bitcoin pay to pubkeyhash addresses have 0x00 as version byte
255 2014-01-02 09:42:32 <sipa> and private keys use 0x80
256 2014-01-02 09:43:45 <shesek> I wasn't talking about the version byte, I was referring to the 0x01 flag that's appended to the end of private key to indicate their corresponding pubkey should be compressed
257 2014-01-02 09:45:30 <sipa> ooh!
258 2014-01-02 09:45:47 <sipa> sorry, didn't read everything
259 2014-01-02 09:48:01 <shesek> (which, btw, makes compressed public keys and private keys of the exact same length, which is somewhat annoying :\)
260 2014-01-02 09:48:54 <shesek> (makes it hard to tell them apart if you just have a byte array, which forced me to do some refactoring when I added support for compressed keys in bitrated)
261 2014-01-02 09:53:39 <sipa> huh?
262 2014-01-02 09:54:09 <sipa> ah, actual public keys, not addresses
263 2014-01-02 09:54:11 <sipa> right
264 2014-01-02 09:54:50 <shesek> yeah, compressed public keys are 33 bytes, and private keys are normally 32 but with the flag they're also 33
265 2014-01-02 09:55:54 <shesek> I was just passing around byte arrays and checking their length to determine what they are, supporting compressed keys forced me to wrap that in an object that also indicates the type
266 2014-01-02 09:56:12 <shesek> but its probably better that way anyway
267 2014-01-02 09:56:14 <sipa> sounds like the right approach anyway
268 2014-01-02 09:57:20 <shesek> yeah... I also added some utility methods on that object along the way, which was also helpful
269 2014-01-02 09:57:33 <shesek> should've probably done it like that to begin with
270 2014-01-02 09:58:23 <shesek> it was just super annoying having to rewrite anything that deals with public/private keys throughout all the code, heh
271 2014-01-02 10:01:05 <sipa> and what program is this?
272 2014-01-02 10:02:11 <shesek> an interface for multi-signature transactions (specifically for arbitration, not general purpose) I released recently
273 2014-01-02 10:02:15 <shesek> www.bitrated.com
274 2014-01-02 10:02:35 <sipa> ah nice
275 2014-01-02 10:04:38 <CodeShark> shesek, could bitrated support this? https://github.com/CodeShark/bips/blob/master/bip-n1.mediawiki
276 2014-01-02 10:14:14 <shesek> CodeShark, I'm not quite sure I understand the advantage of that
277 2014-01-02 10:15:14 <shesek> currently, the party that initiates the transaction sends a partially-signed transaction w/o a placeholder
278 2014-01-02 10:15:52 <shesek> all parties already know the pubkeys in the multisig and already has the redeem script
279 2014-01-02 10:16:50 <shesek> its trivial to figure out on the receiving end where the signature should go
280 2014-01-02 10:18:47 <CodeShark> could you add placeholders? it would make your site compatible with my tools
281 2014-01-02 10:19:33 <shesek> but incompatible with bitcoind :-\
282 2014-01-02 10:19:39 <CodeShark> howso?
283 2014-01-02 10:20:09 <CodeShark> bitcoind won't relay partially signed transactions anyhow - and decoderawtransaction works just fine with placeholders
284 2014-01-02 10:20:31 <CodeShark> or hmm
285 2014-01-02 10:20:43 <CodeShark> you're using a bitcoind wallet...
286 2014-01-02 10:20:54 <shesek> it won't relay them, but you can sign partially signed transaction
287 2014-01-02 10:21:19 <CodeShark> right - the bitcoind approach doesn't really work for the general case, which is why I wrote txbuilder in the first place
288 2014-01-02 10:22:58 <shesek> bitcoind (or the bitcoin network, really) doesn't help at all with distributing partially-signed transactions
289 2014-01-02 10:23:21 <shesek> but bitcoind does handle signing them just fine
290 2014-01-02 10:23:34 <CodeShark> only if you know the redeemscript a priori
291 2014-01-02 10:23:37 <CodeShark> which is not the general case
292 2014-01-02 10:25:37 <shesek> well, someone has to know it, even with your BIP the first one to create the transaction needs to know it
293 2014-01-02 10:26:10 <shesek> but its also the same with regular partially signed transaction w/o placeholders, the redeem script is still there
294 2014-01-02 10:27:26 <CodeShark> also, in a coinjoin-type transaction, there's no way generally for other parties to verify the signatures without the use of placeholders and including the redeemscripts in the inputs
295 2014-01-02 10:27:37 <shesek> also, I would imagine people would usually know the redeem script (or, at least, the pubkeys that are used for the multisig, which you can `addmultisigaddress` to bitcoind which allows it to determine the script on its own)
296 2014-01-02 10:28:00 <CodeShark> knowing the pubkeys isn't enough - you also have to know the permutation
297 2014-01-02 10:28:30 <CodeShark> otherwise you have to brute force through them all until you find the correct one (unless you enforce a standard, like pubkey sorting)
298 2014-01-02 10:28:40 <shesek> permutation?
299 2014-01-02 10:28:47 <CodeShark> yes, the order of the pubkeys matters
300 2014-01-02 10:28:49 <shesek> you mean their order? (I'm not a native english speaker)
301 2014-01-02 10:28:52 <CodeShark> yes
302 2014-01-02 10:29:14 <shesek> oh, right. I had no idea what that word means :)
303 2014-01-02 10:29:38 <shesek> well, yes, you're right, you have to know the pubkeys and their order
304 2014-01-02 10:30:05 <shesek> in bitrated I indeed sort them before creating the multisig script
305 2014-01-02 10:31:02 <shesek> but in both cases, the first one to create the partial transaction has to know the order
306 2014-01-02 10:31:05 <CodeShark> should probably write a BIP for pubkey sorting…but it will require at least a soft fork
307 2014-01-02 10:32:06 <CodeShark> then there's the case of dealing with more than two other parties - where each needs to be able to add another signature
308 2014-01-02 10:32:08 <shesek> I think it could be enough to just make addmultisigaddress/createmultisig order them by default, with a flag that tells it not to
309 2014-01-02 10:32:18 <shesek> and standardize on all the clients doing so
310 2014-01-02 10:32:29 <CodeShark> that's not a bad start
311 2014-01-02 10:36:00 <shesek> I'm still not sure what's the purpose of the placeholder - doesn't it just offload the need to determine where new signatures should go from the receiver to the sender?
312 2014-01-02 10:37:31 <shesek> also, have you seen BIP 10?
313 2014-01-02 11:11:42 <CodeShark> not sure what you mean by receiver and sender - if you're talking about the sender of bitcoins, the sender only needs to know the script hash.
314 2014-01-02 11:12:42 <CodeShark> if you're talking about this in the context of a signature request protocol, yes, the one requesting the signature has to determine where the signature should go
315 2014-01-02 11:15:12 <CodeShark> also, BIP0010 was created before BIP0016, which makes it somewhat dated
316 2014-01-02 11:25:05 <netg> what "services" : "00000001" vs. "services" : "00000000" when reading "bitcoind getpeerinfo"?
317 2014-01-02 11:28:00 <sipa> bit 1 means it's a NODE_NETWORK
318 2014-01-02 11:28:14 <sipa> i.e., one that relays blocks and transactions, and can be queried for older blocks
319 2014-01-02 11:28:19 <sipa> (= a full node)
320 2014-01-02 11:28:27 <sipa> 0's are likely BitcoinJ wallets
321 2014-01-02 11:29:28 <netg> thank you sipa and sorry for mentioned this here, i want to ask in #bitcoin, sorry
322 2014-01-02 11:49:02 <comboy> sipa: thx, I wonder if there's any risk of even a single node spamming with a lot of fake addrs with some very recent time, I guess it would a least be able to fake number on things like getaddr.bitnodes.io
323 2014-01-02 11:54:10 <sipa> comboy: don't they at least try to connect to peers?
324 2014-01-02 11:54:20 <sipa> my crawler/seeder does
325 2014-01-02 11:56:31 <comboy> sipa: I think they do but the number seems total "alive" addrs, I doubt they would be able to make connection with that many nodes
326 2014-01-02 11:59:17 <comboy> sipa: do you have stats somewhere from this crawler? I'm playing with one miself, but last ~24h I was only able to connect to like ~20k hosts (not listening, just making connections) (I can paste user agent distribution if somebody is interested)
327 2014-01-02 11:59:34 <sipa> http://bitcoin.sipa.be/seeds.txt
328 2014-01-02 12:00:05 <comboy> ah, right, crawler for seed nodes
329 2014-01-02 12:00:38 <sipa> well, it's just a crawler :)
330 2014-01-02 12:03:47 <comboy> more ipv6 than I imagined
331 2014-01-02 12:04:16 <sipa> and onion!
332 2014-01-02 12:08:00 <comboy> yeah, that's nice to see, I also wonder hov many people have dynamic ips, but I guess not that many among those accepting connections
333 2014-01-02 12:12:47 <comboy> sa anyway, I make a node, and respond to getaddr or send random addrs messages with !M? (is there any limit?) fake ips, adding some nice recent time to them, do you think it could do harm since they are propagated without checking?
334 2014-01-02 12:12:59 <comboy> *1M
335 2014-01-02 12:14:36 <Dagger> 3.5% v6, but of that 75% is Teredo, so only 0.85% proper v6 overall
336 2014-01-02 12:15:19 <Dagger> although I'd expect a bigger fraction of the v6 to be static than of the v4, so that will be weighing against it
337 2014-01-02 12:22:51 <Dagger> and indeed, 1.7% is proper v6 if I only consider the first 53000 nodes (i.e. those with a 30d uptime of greater than 1%)
338 2014-01-02 12:23:54 <comboy> itshappening.gif
339 2014-01-02 12:25:06 <brisque> IPV6 just means a lot more beef cake babe for everybody.
340 2014-01-02 12:26:39 <brisque> heh, first ipv6 node I saw on the list was "cafe". not too far off.
341 2014-01-02 12:26:52 <brisque> [2a01:4f8:200:23d1::dead:beef]:8333
342 2014-01-02 12:28:46 <Dagger> only 8 using beef, cafe and/or dead
343 2014-01-02 12:29:06 <Dagger> nobody using babe or cake
344 2014-01-02 12:29:24 <brisque> I'm extremely disappointed.
345 2014-01-02 13:01:18 <Hans-Martin> doing cake with base-16 might be challenging, though.
346 2014-01-02 13:07:24 <Dagger> ...probably why I didn't find anybody using it...
347 2014-01-02 13:18:37 <LobsterMan> quick question...if i set the transaction fee to 0.00005 will that significantly negatively affect my chances of getting accepted in any given block?
348 2014-01-02 13:19:49 <michagogo> cloud|LobsterMan: It will be treated as a 0-fee transaction in most cases
349 2014-01-02 13:20:26 <LobsterMan> so i should not use less than .0001?
350 2014-01-02 13:20:38 <LobsterMan> because my transactions where i pay no fee sometimes take an hour or more to get accepted
351 2014-01-02 13:20:43 <LobsterMan> confirmed*
352 2014-01-02 13:20:54 <sipa> iirc, only values below 0.00001 per kilobyte are treated as 0
353 2014-01-02 13:21:07 <LobsterMan> hmm
354 2014-01-02 13:21:08 <michagogo> cloud|LobsterMan: #bitcoin-dev isn't really the right place for this
355 2014-01-02 13:21:28 <LobsterMan> someone told me i should ask here O_o
356 2014-01-02 13:21:33 <LobsterMan> where is the best place to ask?
357 2014-01-02 13:21:55 <michagogo> cloud|#bitcoin
358 2014-01-02 13:22:19 <michagogo> cloud|
ACTION looks quizzically at the topic

359 2014-01-02 13:22:28 <michagogo> cloud|"#bitcoin-dev: Development of the Bitcoin"
360 2014-01-02 13:22:58 <LobsterMan> ok, well thanks for the assistance anyway :P
361 2014-01-02 13:41:25 <shesek> I'm wondering... if you turn a bitcoin address to, say, base 50,000, where each "character" is a word (probably based on the 50,000 most common words)
362 2014-01-02 13:41:35 <shesek> how long would that be? would it be short enough to be memorable?
363 2014-01-02 13:44:09 <nightlingo> hello guys!   I've read in the bitcoin wiki page that bitcoind should not be used to build a scalable solution when handling thousands of bitcoin addresses. What is the alternative? Thanks
364 2014-01-02 13:46:23 <brisque> nightlingo: bit of a sticky one, there's not that much in the way of alternatives.
365 2014-01-02 13:47:37 <nightlingo> brisque: so, to get this straight, when you make a query to bitcoind, it goes through all the transactions up to this point in order to give you the answer?
366 2014-01-02 13:47:56 <nightlingo> *a balance query
367 2014-01-02 13:47:57 <brisque> nightlingo: well no, it keeps a cache of most things
368 2014-01-02 13:48:38 <brisque> nightlingo: for transactions in your wallet it is looking up just the very tip of the blockchain which is kept in memory. you can't query for transactions that are not your own without building a separate optional index.
369 2014-01-02 13:49:11 <nightlingo> brisque: I am talking about accounts
370 2014-01-02 13:49:49 <brisque> nightlingo: if you are keeping accounts for every one of your services users, that's generally extremely ill advised. they aren't designed for that.
371 2014-01-02 13:50:35 <nightlingo> brisque: so how would you do that?
372 2014-01-02 13:51:05 <brisque> nightlingo: most services that I've seen or spoken to keep an external balance sheet, using the "notify" command to push updates from the bitcoin daemon back to whatever is keeping the balance database.
373 2014-01-02 13:51:41 <brisque> nightlingo: bitcoind can run a command every time a new block is seen on the network, and you can use this to trigger updates of individual external balances and confirmation amounts.
374 2014-01-02 13:52:26 <nightlingo>  brisque: so they don't keep accounts in bitcoind at all? they just have one wallet and simply generate new addresses in that wallet?
375 2014-01-02 13:53:07 <nightlingo> brisque: that's cool actually thanks!  I didn't know about the notify command
376 2014-01-02 13:53:41 <brisque> nightlingo: you might want to check up with some other people too, but that is how I've seen it done. by generating a new receiving address for every user you can determine who has sent what into your shared wallet, and update your balances when funds come into each individually.
377 2014-01-02 13:54:21 <brisque> nightlingo: the command is "-blocknotify", there's some more information on the wiki too regarding getting it to pass the block hash onto your updating script as well.
378 2014-01-02 13:54:50 <nightlingo> that's awesome man thanks!
379 2014-01-02 13:55:52 <brisque> there's -txnotify as well, but you should never allow your users to spend or use 0 confirmation funds.
380 2014-01-02 13:56:11 <shesek> apparently its not very practical... using 100,000 words gives you ~13 words to represent an address
381 2014-01-02 13:57:02 <shesek> 1m words lowers that to ~10 words, which still isn't practical :-\
382 2014-01-02 13:57:06 <brisque> shesek: use a big enough dictionary and you can take that down to one word per address.
383 2014-01-02 13:57:19 <sipa> why would you want words to represent an address...?
384 2014-01-02 13:57:39 <sipa> anything that requires users to see or pass along addresses is broken imho
385 2014-01-02 13:57:44 <shesek> even with 100k, a lot of words aren't commonly used
386 2014-01-02 13:57:55 <brisque> sipa: I think it's a continuation of talking about NXT before, coming up with bad ideas rather than good ones.
387 2014-01-02 13:58:14 <shesek> I dunno, just thought it could be a cool way to represent addresses in a way that can be remembered/spoken
388 2014-01-02 13:58:41 <brisque> you sort of don't want to do that anyway. addresses are for the most part single use
389 2014-01-02 13:58:41 <shesek> if it were like 5-6 words with a list of words that are actually common, it could've been cool
390 2014-01-02 13:59:05 <sipa> why would you want to remember an address in the first place?
391 2014-01-02 13:59:20 <sipa> they're not intended to be reused
392 2014-01-02 14:00:08 <shesek> not re-using addresses doesn't mean that its useless to have a more convenient way to remember/communicate them
393 2014-01-02 14:00:31 <shesek> like, when I'm taking addresses from my offline machine, I copy them by hand
394 2014-01-02 14:00:34 <brisque> addresses already have checksums so you can't make mistakes when communicating them
395 2014-01-02 14:00:49 <brisque> your client won't accept an address with a typo in it
396 2014-01-02 14:00:50 <sipa> mhmm
397 2014-01-02 14:01:09 <sipa> i think any effort that tries to simplify usage of addresses fails to address the real issue
398 2014-01-02 14:01:11 <shesek> I know you can't make mistakes (or, rather, its extremely unlikely to typo a valid address), but its still useful to have a memorable form for them
399 2014-01-02 14:01:19 <sipa> we shouldn't be calling them address, and they shouldn't be visible
400 2014-01-02 14:01:43 <sipa> unfortunately much of the ecosystem has developed around the opposite idea
401 2014-01-02 14:01:53 <shesek> the payment protocol won't be suitable for every use case
402 2014-01-02 14:01:59 <brisque> sipa: if anything, we need significantly more abstraction in the wallet.
403 2014-01-02 14:02:13 <sipa> shesek: then the payment protocol needs to be improved :)
404 2014-01-02 14:02:16 <brisque> sipa: users importing and playing with private keys is scary.
405 2014-01-02 14:02:23 <sipa> brisque: i agree
406 2014-01-02 14:02:28 <shesek> like the one I just gave - if I generate a key pair on an offline machine, copying the address is the most sensible way to send funds to it
407 2014-01-02 14:02:54 <shesek> I can't use any payment protocol, because its not really connected to any network
408 2014-01-02 14:03:07 <shesek> and I still see addresses being used for development funds on github and such
409 2014-01-02 14:03:20 <brisque> sipa: a few days back I was attempting to convince a user that he didn't need to "clean up" his wallet.dat by removing private keys from it. a few kilobytes verses the gigabytes of blocks and indexes.
410 2014-01-02 14:03:27 <shesek> setting up a payment server to receive some donations is an overkill imho
411 2014-01-02 14:03:35 <sipa> you can copy the bip32 neutered key, import the wallet watch-only on an online machine, and generate address using that one
412 2014-01-02 14:03:55 <sipa> i'm not talking about now, by the way
413 2014-01-02 14:04:12 <sipa> just about future efforts to improve ease of use for addresses
414 2014-01-02 14:05:36 <shesek> I personally think using addresses directly still have some use-cases where its the best option, regardless of how awesome the payment protocol is :P
415 2014-01-02 14:05:55 <sipa> for anonymous donations, perhaps
416 2014-01-02 14:06:01 <sipa> for other things, unsure
417 2014-01-02 14:06:43 <shesek> how about multi-signature and other p2sh addresses?
418 2014-01-02 14:07:09 <shesek> some transactions aren't even paid to someone that should give you an address, like OP_RETURN transactions
419 2014-01-02 14:07:27 <sipa> i hate OP_RETURN, but it's just the least harmful of all alternatives
420 2014-01-02 14:08:23 <sipa> and not sure what you mean... you're always paying someone (perhaps yourself)
421 2014-01-02 14:08:55 <shesek> OP_RETURN is unspendable/prunable, you aren't really paying to anyone
422 2014-01-02 14:09:24 <shesek> and paying yourself is another case where it doesn't make sense for the payment protocol to replace addresses
423 2014-01-02 14:09:48 <sipa> yes, that's just abusive data storage attached to a transaction... but where does the transaction itself go?
424 2014-01-02 14:10:18 <sipa> s/transaction/payment/
425 2014-01-02 14:10:50 <shesek> if I understand correctly, its a zero-value output with the unspendable OP_RETURN as its script
426 2014-01-02 14:10:51 <sipa> yes
427 2014-01-02 14:10:56 <shesek> so the transaction isn't really going anywhere
428 2014-01-02 14:11:02 <shesek> or at least that output is not going anywhere
429 2014-01-02 14:11:02 <sipa> well it's not the whole transaction
430 2014-01-02 14:11:10 <sipa> it's an additional output to attach data to the transaction
431 2014-01-02 14:11:22 <sipa> the payment protocol works with files too, by the way - you can have a payment request stored in a file, and import it in a client to pay it
432 2014-01-02 14:11:41 <shesek> for some use cases, but for others it could be the only output (like for creating trusted timestamps)
433 2014-01-02 14:11:49 <shesek> (well, assuming you don't have change)
434 2014-01-02 14:11:58 <sipa> i still consider it abuse :)
435 2014-01-02 14:13:16 <shesek> well, possibly... but its still a case the payment protocol won't resolve (though its not really an address, now that I think about it)
436 2014-01-02 14:14:19 <sipa> yes, that's what i mean
437 2014-01-02 14:14:32 <shesek> how about multisig addresses? would you have one of the parties generate the address on its own and give it as part of the payment request?
438 2014-01-02 14:14:50 <sipa> doesn't matter
439 2014-01-02 14:15:00 <sipa> you can get it from anyone
440 2014-01-02 14:15:08 <shesek> the other parties need to independently verify the address is correct somehow
441 2014-01-02 14:15:20 <sipa> but even multisig addresses are not intended from reuse
442 2014-01-02 14:15:37 <sipa> so you need some synchronized way of generating addresses for payments to it
443 2014-01-02 14:16:27 <sipa> who does that is irrelevant from the point of view of the payer
444 2014-01-02 14:16:42 <sipa> (in fact, the payer shouldn't even know/care that he's paying to a multisig address)
445 2014-01-02 14:17:34 <sipa> there are two very different issues here: generation of the address, and getting it in a trustable way to the sender
446 2014-01-02 14:17:54 <shesek> if its a multi-signature used for arbitration, shouldn't he be able to confirm that his and the trusted third party public keys are in that multisig?
447 2014-01-02 14:18:27 <sipa> if he knows the full script, it's obvious
448 2014-01-02 14:19:08 <sipa> so yes, if that is necessary you need to agree on a script, and then convert it to an address yourself
449 2014-01-02 14:19:35 <sipa> (but that's only because the sender is also a receiver, not because he's a sender on itself)
450 2014-01-02 14:21:05 <shesek> all I'm saying... I think addresses still have their place, thought it could be cool to represent them as words, looks like its not possible (takes way too many words)
451 2014-01-02 14:21:50 <Belxjander> Shesek: the only way it would work is to key strings based off a word using some kind of vector math
452 2014-01-02 14:21:51 <shesek> ah damn it, I think my cat got stuck on a tree again... bbl
453 2014-01-02 14:21:52 <sipa> i still believe that any usage where a human needs to see an address, is the wrong approeach
454 2014-01-02 14:22:09 <Belxjander> but you would need the "word key" and the vector to rebuild the data correctly
455 2014-01-02 14:23:55 <shesek> blah... stupid cat, why does he keep climbing it when he knows he can't get down? :\
456 2014-01-02 14:24:19 <shesek> Belxjander, its actually much simpler than that - I hacked a base58 implementation to use an array of words as its "characters" instead of the regular characters
457 2014-01-02 14:24:31 <shesek> and changed it to use base 50,000
458 2014-01-02 14:25:05 <shesek> it worked just fine, but it ends up really long
459 2014-01-02 14:25:31 <shesek> sipa, how about confirming identities with message signatures?
460 2014-01-02 14:25:33 <Belxjander> ahh right
461 2014-01-02 14:25:49 <sipa> shesek: i should clarify
462 2014-01-02 14:26:11 <sipa> i consider "key id" and "address" two different things; the first is a reference to a key, the second is a destination of money
463 2014-01-02 14:26:26 <sipa> unfortunately, we've grown to confuse them pretty much everywhere
464 2014-01-02 14:26:57 <sipa> if you're confirming an identity, it has nothing to do with an address anymore, you're just using a bitcoin key for some other purpose
465 2014-01-02 14:27:01 <Belxjander> sipa: Identification by a recognised symbology?
466 2014-01-02 14:27:14 <shesek> yeah, it definitely makes sense to make that distinction
467 2014-01-02 14:27:18 <sipa> (for which also better solutions may exist, but it's a different discussion)
468 2014-01-02 14:28:02 <shesek> and I do agree that the addresses concept is somewhat flawed, and that the payment protocol is much better for almost all cases
469 2014-01-02 14:29:08 <sipa> i'm pretty sure that static addresses will remain, and there will be uses for which alternatives barely provide any advantages (anonymous donations, for example)
470 2014-01-02 14:29:10 <shesek> here's another use case for my idea - make pubkeys used for signing memorable
471 2014-01-02 14:29:30 <shesek> so people can easily defect when they're changed
472 2014-01-02 14:29:32 <brisque> pubkeys are huge compared with addresses.
473 2014-01-02 14:29:42 <sipa> 30% larger
474 2014-01-02 14:29:54 <shesek> well, not the actual pubkeys, also a hash of them
475 2014-01-02 14:30:08 <sipa> not sure what you mean?
476 2014-01-02 14:30:11 <brisque> a pubkey hash is just the address
477 2014-01-02 14:30:22 <sipa> :)
478 2014-01-02 14:30:22 <sipa> s/address/key id/
479 2014-01-02 14:30:34 <sipa> if you're using it as a txout script template, it is an address
480 2014-01-02 14:31:04 <brisque> sipa: to me "key ID" implies it's unique and perminant too
481 2014-01-02 14:31:12 <brisque> permanent.
482 2014-01-02 14:31:22 <sipa> it is unique and permanent
483 2014-01-02 14:31:25 <shesek> brisque, for that purpose, it makes sense to use a shorter hash than addresses
484 2014-01-02 14:31:33 <sipa> but address implies it's a unique and permanent _destination_
485 2014-01-02 14:31:55 <shesek> like maybe, 15 first bytes + 4 bytes checksum
486 2014-01-02 14:31:57 <brisque> an address isn't permanent to a user though. it's one off, throwaway
487 2014-01-02 14:32:20 <shesek> should make the words short enough to be memorable
488 2014-01-02 14:32:49 <sipa> brisque: "address" for me is a destination of money; there are imho 3 types of addresses: send-to-pubkeyhash (aka send to key id), send-to-scripthash (aka p2sh) and send-to-url (payment protocol)
489 2014-01-02 14:33:15 <sipa> and the problem is that the first are considered an address rather than a protocol implementation detail
490 2014-01-02 14:33:53 <sipa> a key id is the hash of a public key, and can be used as an address, but can be used for other things too (message signatures, for example)
491 2014-01-02 14:34:05 <brisque> I follow.
492 2014-01-02 14:34:49 <sipa> and yes, the key ids used inside transactions should be trowaway
493 2014-01-02 14:35:20 <sipa> but the word 'address' implies that it is some permanent designation of a destination for money
494 2014-01-02 14:36:00 <brisque> indeed. "receiving address" is a nice compromise in my mind.
495 2014-01-02 14:36:00 <shesek> seems like 10 bytes + 2 checksum bytes, with 50000 words, would end up as ~6 words, which seems reasonable to memorize
496 2014-01-02 14:36:01 <brisque> it makes it clear that a "sending address" doesn't exist.
497 2014-01-02 14:36:16 <sipa> even better: just start using URLs as addresses
498 2014-01-02 14:36:47 <shesek> this could be a cool way to memorize key ids used for message signature and ensure the key wasn't replaced
499 2014-01-02 14:37:07 <sipa> but they're the destinations of payments (high-level concept of transfer of money between entities), rather than destination of lowlevel bitcoin transactions
500 2014-01-02 14:38:25 <sipa> if i'd create an altcoin now, it would be p2sh at the protocol level, and payment-protocol-only on the client level :)
501 2014-01-02 14:39:36 <shesek> how do regular users get casual payments? setup their own payment server?
502 2014-01-02 14:39:57 <sipa> yes
503 2014-01-02 14:40:10 <sipa> how do you get e-mail?
504 2014-01-02 14:40:30 <shesek> I trust email to third-party providers, as most people do
505 2014-01-02 14:40:41 <shesek> if anyone had to setup their own email servers, email wouldn't have gotten very far
506 2014-01-02 14:40:48 <brisque> in that scenario you end up with someone like google controlling the vast portion of payments
507 2014-01-02 14:41:06 <sipa> brisque: is that different from now, with blockchain.info controller the vast portion of wallets? :)
508 2014-01-02 14:41:08 <shesek> people could use services that offer payment-server-as-a-service
509 2014-01-02 14:41:36 <brisque> sipa: I suppose not.
510 2014-01-02 14:41:41 <shesek> but its something that I personally wouldn't do
511 2014-01-02 14:41:55 <shesek> and I think its much more likely that everyone would end up on cloud wallets when setting up a payment server is required
512 2014-01-02 14:41:57 <sipa> and people should absolutely be able to run their own payment server
513 2014-01-02 14:42:25 <shesek> people don't even bother installing a desktop client now and choose to use web interface instead
514 2014-01-02 14:42:46 <shesek> you think they would pay for a server and setup their own payment system on it?
515 2014-01-02 14:42:46 <sipa> btw, payment server doesn't mean they have your wallet
516 2014-01-02 14:43:02 <shesek> payment server means they can send whatever addresses they want, tho
517 2014-01-02 14:43:16 <sipa> and you can trivially check whether they're doing that
518 2014-01-02 14:43:22 <sipa> but yes, it requires trust
519 2014-01-02 14:45:37 <nightlingo> what is the "best block" ? is it the newest block in the network?
520 2014-01-02 14:45:50 <brisque> the most difficult chain.
521 2014-01-02 14:45:55 <sipa> nightlingo: it's the best block your client knows about
522 2014-01-02 14:46:03 <sipa> "the newest block in the network" is not well-defined
523 2014-01-02 14:46:04 <brisque> *not* the highest block.
524 2014-01-02 14:46:22 <nightlingo> so it's the newest block my client knows about?
525 2014-01-02 14:46:34 <brisque> no, it's the best and most difficult to create block
526 2014-01-02 14:46:43 <nightlingo> what does "best" mean?
527 2014-01-02 14:46:49 <sipa> or rather, it's the tip of the (valid) block chain with the most proof-of-work your client knows about
528 2014-01-02 14:47:06 <brisque> nightlingo: the most difficult to create, cumulatively speaking from all the way from the genesis block.
529 2014-01-02 14:47:15 <nightlingo> oh ok
530 2014-01-02 14:47:16 <sipa> most proof-of-work, and not invalid
531 2014-01-02 14:47:50 <nightlingo> If I wanted to be up-to-date with the latest transactions, would it be ok if I monitor the best block?
532 2014-01-02 14:48:06 <sipa> shesek: btw, it could also mean that wallet clients have a built-in trivial payment server, which only supports payment-requests-as-files
533 2014-01-02 14:48:19 <brisque> the "best" block is where the truth lies, at least from the perspective of your client
534 2014-01-02 14:48:44 <shesek> sipa, I was thinking the other day about an alternative scheme where people would publish their master public key and people sending payments to them would create a random "receipt number" (like 10-15 random bytes), derive an address from the master pubkey with that receipt, pay to that, and than send the receipt as a proof of payment
535 2014-01-02 14:48:50 <nightlingo> ok cool thanks
536 2014-01-02 14:48:56 <shesek> was something like that ever suggested?
537 2014-01-02 14:49:03 <sipa> shesek: what advantage does that have?
538 2014-01-02 14:49:20 <sipa> shesek: if you're publishing your master public key, you're giving up the same privacy as you'd lose with address reuse
539 2014-01-02 14:49:35 <shesek> prevents address reuse without having to communicate before every payment
540 2014-01-02 14:49:36 <sipa> (though the bar to track it is harder)
541 2014-01-02 14:49:54 <shesek> how so? without knowing the recipes, it should be quite impossible to find that
542 2014-01-02 14:50:13 <sipa> ah, you're sending the recipe number along, i see
543 2014-01-02 14:50:14 <shesek> you can make them as large as you want... if 10-15 isn't enough, it could even be 100-200 bytes with no real added cost
544 2014-01-02 14:50:40 <sipa> in what scenario can you send a receipt number back, but not request something?
545 2014-01-02 14:50:55 <shesek> you publish your master once, and every time I want to pay you I derive an address with a random receipt and send you that receipt over some channel
546 2014-01-02 14:51:15 <sipa> why couldn't you request the address through the same channel?
547 2014-01-02 14:51:23 <brisque> shesek: nothing stops me from generating the same keys and finding every transaction you've ever made in that model
548 2014-01-02 14:51:47 <sipa> brisque: not if you can't observe or bruteforce the receipt ids
549 2014-01-02 14:51:50 <shesek> brisque, except that there are a lot of them... nothing stops me from generating every private key until I find the one to your address
550 2014-01-02 14:52:11 <brisque> sipa: in the model of transmitting an MPK you can
551 2014-01-02 14:52:36 <sipa> brisque: if the receipt ids are 160 bit, you can't iterate them :)
552 2014-01-02 14:52:50 <sipa> even if the mpk the actual keys are derived from is public
553 2014-01-02 14:52:53 <shesek> sipa, it requires both parties being active for the transaction, the receipt thing only requires the payer to be active
554 2014-01-02 14:53:07 <shesek> it could also be used for the anonymous donation kind of thing
555 2014-01-02 14:53:09 <shesek> with more privacy
556 2014-01-02 14:53:11 <jgarzik> mornin'
557 2014-01-02 14:53:12 <sipa> how will you send me the receipt, if i'm offline?
558 2014-01-02 14:53:19 <shesek> where the payee isn't involved at all
559 2014-01-02 14:53:27 <jgarzik> 
ACTION waves at brisque 

560 2014-01-02 14:53:37 <brisque> jgarzik: howdy.
561 2014-01-02 14:54:14 <shesek> well, if its a merchant website or something like that, it would be their api that does that (generate payment address client-side, send receipt to server)
562 2014-01-02 14:54:27 <shesek> but in other cases... I guess an email could do
563 2014-01-02 14:54:55 <shesek> the payee would get that "receipt" or "redemption code" or whatever and input it to his client
564 2014-01-02 14:54:55 <sipa> if it's a merchant website, you can just generate the key id to pay to on the fly, and hide the complexity of all that from the sender
565 2014-01-02 14:55:32 <sipa> in other cases... that actually sounds very much like a payment server :)
566 2014-01-02 14:56:15 <shesek> kinda, perhaps an asynchronous payment server where the payee is passive
567 2014-01-02 14:56:35 <shesek> the payer/payee don't have to synchronously communicate to send payments
568 2014-01-02 14:58:40 <shesek> also, its a really thin abstraction layer on top of what currently exists
569 2014-01-02 15:30:01 <shesek> I sent that idea to the mailing list, I wonder what people think about that
570 2014-01-02 15:33:53 <shesek> hmm... is sf's mailing list interface really laggy, or was it not sent?
571 2014-01-02 16:03:55 <shesek> seems like it isn't getting sent for some reason... sent it to bitcointalk for now https://bitcointalk.org/index.php?topic=395832.0
572 2014-01-02 16:10:09 <shesek> can someone tell me if the message I sent to bitcoin-development was received? It seems like it doesn't appear on sourceforge
573 2014-01-02 16:16:43 <netg> /
574 2014-01-02 16:18:01 <sipa> /quit
575 2014-01-02 16:19:32 <sipa> "Development of the Bitcoin" ?
576 2014-01-02 16:57:26 <correcto> is there anyone in here working on distributed computing projects that are not related with bitcoin or any digital currencies but have similar characteristics (parallel processing, heterogenous) ?
577 2014-01-02 16:59:01 <netg> http://en.wikipedia.org/wiki/Berkeley_Open_Infrastructure_for_Network_Computing ?
578 2014-01-02 17:13:40 <ProfMac> main.h mentions "all registered wallets."  How does one go about registering more than one?
579 2014-01-02 17:15:11 <Diablo-D3> you cant.
580 2014-01-02 17:16:44 <sipa> ProfMac: not implememted, but you easily can create multiple CWallet objects and register them
581 2014-01-02 17:18:57 <ProfMac> It's gonna take the rest of my life to comprehend the source code.  :-(
582 2014-01-02 17:37:01 <maaku> hard
583 2014-01-02 17:37:19 <maaku> sorry, wrong window
584 2014-01-02 18:01:12 <bitanarchy> bitaddress is not working properly when you pull it offline
585 2014-01-02 18:07:56 <gmaxwell> bitanarchy: yea, at the very least the logs-your-private-keys part won't work offline.
586 2014-01-02 18:10:02 <bitanarchy> gmaxwell: how would you advise to make paper wallets?
587 2014-01-02 18:10:52 <sipa> just as cold storage, to be spent only once
588 2014-01-02 18:11:02 <sipa> or as an actual wallet, which you send/receive from occasionally?
589 2014-01-02 18:12:05 <bitanarchy> but which tool.... i mean the standard bitcoin client has no option for creating paper wallets.... the most important thing is that you do not want to make errors... control human error component
590 2014-01-02 18:24:00 <pigeons> bitanarchy: make a new address with the client, dumprivkey it, print the key on paper or mnemonencode int
591 2014-01-02 18:24:14 <sipa> bitanarchy: you haven't answered my question :)
592 2014-01-02 18:27:00 <bitanarchy> sipa: cold storage
593 2014-01-02 18:29:48 <sipa> then you can just do what pigeons says
594 2014-01-02 18:30:06 <sipa> but if you really want to use it as a wallet, you'll need a program designed for that like armory
595 2014-01-02 18:30:30 <bitanarchy> does the bitcoin client support mnemonencode? didnt know that
596 2014-01-02 18:30:30 <sipa> bitcoin-qt will likely gain that capability too sometime, but we need deterministic wallets first
597 2014-01-02 18:30:44 <sipa> no, you need to do that
598 2014-01-02 18:30:55 <sipa> the reference client does not support paper wallets at all
599 2014-01-02 18:31:06 <bitanarchy> the bitcoin-qt client probably has the best entropy generator
600 2014-01-02 18:31:18 <sipa> it's just openssl
601 2014-01-02 18:31:25 <bitanarchy> dont trust browsers at all
602 2014-01-02 18:31:35 <sipa> don't use a browser
603 2014-01-02 18:32:06 <bitanarchy> but bitcoin-qt does not support bip38 :)
604 2014-01-02 18:32:43 <sipa> bip38 is flawed, imho
605 2014-01-02 18:33:00 <sipa> doesn't support compressed pubkey, and presumes only a single address
606 2014-01-02 18:34:14 <sipa> if it's just cold storage, just put a single dumped key on paper if you must
607 2014-01-02 18:34:51 <bitanarchy> and put it in multiple secure safes
608 2014-01-02 18:34:52 <sipa> but an actual paper wallet is not supported by bitcoin-qt, and you will very likely shoot yourself in the foot if you try
609 2014-01-02 18:36:12 <bitanarchy> is there a comparisson between paper wallets and usb wallets?
610 2014-01-02 18:36:13 <gmaxwell> sipa: did you see the person with the paper wallet who lost 35 BTC last week in #bitcoin?  He had a failure mode I hadn't seen reported yet:
611 2014-01-02 18:37:12 <gmaxwell> His basement flooded and turned the paper wallet to unreadable mush.  He'd been making extensive efforts to protect it too.. once a month he was using his scanner/printer to reproduce it (and shreding the old one) to guard against paper aging.
612 2014-01-02 18:38:12 <kjj> no baggie?