1 2011-11-29 01:11:08 <Diablo-D3> ;;ticker
  2 2011-11-29 01:11:09 <gribble> Best bid: 2.6917, Best ask: 2.6999, Bid-ask spread: 0.0082, Last trade: 2.6999, 24 hour volume: 64967, 24 hour low: 2.44, 24 hour high: 2.6999
  3 2011-11-29 06:21:55 <Lolcust_Backup> Hello everyone! What is the limit on the ammount of verbiage a pool can put into coinbase nowadays ?
  4 2011-11-29 06:48:36 <[Tycho]> Hello.
  5 2011-11-29 08:10:28 <sipa> Lolcust_Backup: 100 bytes
  6 2011-11-29 08:13:33 <Lolcust_Backup> Thanks sipa
  7 2011-11-29 08:19:34 <denisx> with the merkletreeupdater my pushpool needs 70???sec for a getwork request
  8 2011-11-29 08:21:55 <alexwaters3> Anyone have any input on my Bitcoin funding initiative? https://docs.google.com/document/d/1YWcpPe-q5tNL0xbak6h8R152sy2DNgUVKsG2Lxutf_I/edit?pli=1
  9 2011-11-29 08:27:01 <alexwaters3> if you do plese feel free to comment within the doc
 10 2011-11-29 08:28:45 <SomeoneWeird> heh
 11 2011-11-29 08:28:49 <SomeoneWeird> stay away from paypal.
 12 2011-11-29 08:29:50 <wumpus> I agree with the proposal at large. But yeah, using paypal for accepting donations sounds like a recipe for disaster
 13 2011-11-29 08:30:18 <wumpus> they're not very donation friendly unless you have a registered charity, and even then they sometimes fuck up
 14 2011-11-29 08:33:08 <wumpus> using them to fund a "competitor", be prepared for a lot of drama
 15 2011-11-29 08:34:36 <wumpus> accepting donations in bitcoins would be a good start, eating our own dogfood etc :-)
 16 2011-11-29 08:35:03 <alexwaters3> i wrote it to bring up the point about attracting the people who will only donate via traditional means, how can we reach them?
 17 2011-11-29 08:35:38 <alexwaters3> is there an out of the box donation system we could use to process credit cards?
 18 2011-11-29 08:35:45 <sipa> is flattr still popular?
 19 2011-11-29 08:36:09 <wumpus> flattr is indeed a good option
 20 2011-11-29 08:39:58 <denisx> in europe it is popular
 21 2011-11-29 08:40:04 <wumpus> and at least they don't have the reputation to be "evil" like paypal
 22 2011-11-29 08:40:30 <denisx> one of the founder was also behind piratebay
 23 2011-11-29 08:40:37 <Lolcust_Backup> Well, there is also moneybookers (now rebranded into skrill)
 24 2011-11-29 08:41:00 <Lolcust_Backup> They have a "chargeback defense option" though it's probably expensive as fuck
 25 2011-11-29 08:42:13 <Lolcust_Backup> I think they also have a "accept funds only from moneybooker clients this tall" (that is, with a certain identity validation rating) option, but I might be wrong on that
 26 2011-11-29 08:45:04 <alexwaters3> on the mailing list gavin mentioned a Bitcoin not for profit, does anyone have more information on this?
 27 2011-11-29 08:45:15 <alexwaters3> i am searching the forums and can't find it
 28 2011-11-29 08:46:42 <wumpus> I don't think there is any more than wild plans
 29 2011-11-29 08:47:22 <wumpus> Lolcust_Backup: well chargebacks are a little less of an issue when accepting donations
 30 2011-11-29 08:47:59 <Lolcust_Backup> Well, maybe, but it is still a neat feat.
 31 2011-11-29 08:49:24 <wumpus> yeah
 32 2011-11-29 12:25:20 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * rd1036b101f01b7ab79fc3e10e5199f80f478674d /: Initial directory structure.
 33 2011-11-29 12:25:21 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * rfdde16681399d3e6bb65573a4caa7ff162a6b606 /: Move the banner print in the PingService until after the blockchain.
 34 2011-11-29 12:25:22 <CIA-100> bitcoinj: Seek past garbage before the message header starts. It's unclear how this occurs but is probably an issue in the
 35 2011-11-29 12:25:23 <CIA-100> bitcoinj: Refuse to connect to nodes that don't provide the block chain.
 36 2011-11-29 12:25:24 <CIA-100> bitcoinj: BUG=2
 37 2011-11-29 12:25:25 <CIA-100> bitcoinj: Add a serialVersionUID to other classes that were missing them. Thanks to Andreas for the report.
 38 2011-11-29 12:25:29 <TD> doh
 39 2011-11-29 12:25:31 <CIA-100> bitcoinj: BUG=4
 40 2011-11-29 12:25:32 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * rc40b7ce668f3664d546272a0ce0c889aefe91ecc /: Refresh JavaDocs.
 41 2011-11-29 12:25:32 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * rc9bc430f5364c1f34879ec9fb9a9722738b07bff /: Add a wallet dumping tool, toString() on the Wallet object.
 42 2011-11-29 12:25:35 <CIA-100> bitcoinj: - Progress is now made available
 43 2011-11-29 12:25:36 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * r7310e294f996a0f6a02e7035fa04e3db249a6fb9 /:
 44 2011-11-29 12:25:36 <TD> CIA is gonna get kicked
 45 2011-11-29 12:25:47 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * rd2e4284930e00b9685b8832815199f3312c3b200 / (2 files in 2 dirs): Improve the block locator we send to remote peers as a temporary hack for the lack of exponential thinning. Patch from Jan. Updates issue 84.
 46 2011-11-29 12:25:48 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * r65205b2655701aab2747877cb36952137636d4b8 /target/site/apidocs/ (100 files in 5 dirs): Remove javadocs from repo, they are available at javadoc.bitcoinj.org instead.
 47 2011-11-29 12:25:49 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * r00cb8a4abd7a11e94b6f6b0b9552b2001f25ecfa /src/com/google/bitcoin/core/Message.java: Make bitcoinSerialize() return a copy by default, provide an unsafeBitcoinSerialize() method for high performance applications that are willing to deal with the extra API complexity.
 48 2011-11-29 12:25:52 <CIA-100> bitcoinj: Miron Cuperman (devrandom) <miron@google.com> * ra4a711e2df203b97275e0f619181893d8a7d9479 /src/com/google/bitcoin/core/ (5 files): Fix serialization UIDs, other cleanup
 49 2011-11-29 12:25:53 <CIA-100> bitcoinj:  2) Add c'tors that allow a message to be configured to lazily parse on-demand.
 50 2011-11-29 12:25:54 <CIA-100> bitcoinj: Miron Cuperman (devrandom) <miron@google.com> * r228f30f66374dbf24a7012d57b71b3a0df72ffcb /src/com/google/bitcoin/core/ (Block.java Message.java): Fix length and parseLazy handling. Resolves issue 92
 51 2011-11-29 12:26:00 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * r99385e7aee1679a4c8eb6c733abe07a1eef111fe /src/com/google/bitcoin/store/BoundedOverheadBlockStore.java: Make a field static. Resolves comments by Miron on r194.
 52 2011-11-29 12:26:01 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * r03647dbb7e13f3b2139c26072d5dff45059c93e2 / (2 files in 2 dirs): Add a getTransactions() method that returns a set of all transactions, optionally including those which are dead and inactive. Add an argument for returning dead transactions in getRecentTransactions(). Updates issue 3.
 53 2011-11-29 12:26:06 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * ree083d6fac3036b1723b8611e0e2c22a12ea0352 / (7 files in 2 dirs): (log message trimmed)
 54 2011-11-29 12:26:07 <CIA-100> bitcoinj: Patch 9 from Steves lazy parsing patchset.
 55 2011-11-29 12:26:08 <CIA-100> bitcoinj: larger messages may require several array reallocations and almost all will
 56 2011-11-29 12:26:12 <CIA-100> bitcoinj: Miron Cuperman (devrandom) <miron@google.com> * rcb4067da09db411612c9715e5934391483b6d4a9 /src/com/google/bitcoin/core/ (3 files): Remove dependency on Java 1.6
 57 2011-11-29 12:26:13 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * r3191d5684becfa6c10dcaa7d3cfa9d7decc34d93 / (4 files in 2 dirs): Implement a way of getting a list of transactions in the wallet, ordered by recency. This doesn't yet support pending transactions, as those can't (yet) be added to the wallet.
 58 2011-11-29 12:26:14 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * r27b6b5ab97800e53b95535b6e222a509dcc24c62 /src/com/google/bitcoin/core/ (15 files):
 59 2011-11-29 12:26:18 <CIA-100> bitcoinj: More optimizations: pre-calculate or guess various array sizes to avoid needlessly re-sizing them later.
 60 2011-11-29 12:26:18 <CIA-100> bitcoinj: Patch 8 from Steves lazy parsing patchset.
 61 2011-11-29 12:26:19 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * reae1130a31c34e91f859dff67a8ecfd2b6ad3c4b / (2 files in 2 dirs): Make PeerGroup remember discovery sources and retry them after a while.
 62 2011-11-29 12:26:23 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * r133dad7305ab8ba2153600d25323919223ed0edc /src/com/google/bitcoin/core/PeerGroup.java: Tweak PeerGroup thread priority. Resolves issue 67.
 63 2011-11-29 12:26:24 <CIA-100> bitcoinj: 2) Reorg handling expected to be able to connect all inputs.
 64 2011-11-29 12:26:25 <CIA-100> bitcoinj: Miron Cuperman (devrandom) <miron@google.com> * r3a463e47999631945eed42c14689a633516f615a / (22 files in 4 dirs): Cleanup of lazy block parsing, patch from shadders
 65 2011-11-29 12:26:28 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * rafef6bc0293e23f521985168a6c122da5c65913c / (27 files in 3 dirs): (log message trimmed)
 66 2011-11-29 12:26:40 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * r7a4dfd1dc24c72b75427ba9f98dbd777284c7957 /:
 67 2011-11-29 12:26:41 <CIA-100> bitcoinj: Test that you can sign with the roundtrip key and verify with the original key, and vice versa.
 68 2011-11-29 12:26:42 <CIA-100> bitcoinj: Cache checksum for non-empty messages.
 69 2011-11-29 12:26:43 <CIA-100> bitcoinj: Checksum byte array is currently transient so no gains for a message extracted from java serialization then bitcoinSerialized. I don't think this would ever happen in real life but if it does then it could al
 70 2011-11-29 12:26:46 <CIA-100> bitcoinj: Miron Cuperman (devrandom) <miron@google.com> * r7dd1fce5aa45e27ef4683440033bc64a52c6aae3 /: Clean up Peer exception handling
 71 2011-11-29 12:26:47 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * rf336a899846061d2abf07f66021b181c63f77db2 / (2 files in 2 dirs): (log message trimmed)
 72 2011-11-29 12:26:48 <CIA-100> bitcoinj: Customize Sha256Hash.hashCode() method to only use first n bytes of the backing
 73 2011-11-29 12:26:49 <CIA-100> bitcoinj: required to be guaranteed unique this fulfills the contract and reduces hashing
 74 2011-11-29 12:26:50 <CIA-100> bitcoinj: time.
 75 2011-11-29 12:27:04 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * ra32a612630150297d89b70d66eafc6fdcafdb5e5 /:
 76 2011-11-29 12:27:05 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * rcd10099d3f18585af1a08c86bf445917d9f071e5 /: Some small renamings in BlockChain. Log but don't throw in TransactionOutput.isMine() if the script is unparseable. Suggestions from Miron.
 77 2011-11-29 12:27:06 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * r18d45f0590ed0d696bc751ce80b7d4d45b3689ce /: Update repo URLs. Patch from Gary Rowe.
 78 2011-11-29 12:27:10 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * r1e2f3ae3e2c2b162eb129aa520901e35e0b70ded /: Split the BlockChain.add method out into some smaller functions.
 79 2011-11-29 12:27:11 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * r794facc7272f8b85d2350c86d88b9122d49c6d9a /src/com/google/bitcoin/examples/PrintPeers.java: Dump out versions and chain heights in PrintPeers.
 80 2011-11-29 12:27:16 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * rea8cbd7465266864b2933a927eaa0cf408c7a7b6 /: Don't pre-calculate the hash in the Transaction parse code. Speeds up processing of large blocks with no relevant transactions.
 81 2011-11-29 12:27:17 <CIA-100> bitcoinj: Also require the height of the best chain to be specified when setting up a NetworkConnection. This API is getting too complicated and will be simplified soon.
 82 2011-11-29 12:27:22 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * r0953e79cb046a214afd3175acabff46acfd7ac9a /: Improve the documentation for the PingService. Patch by Gary Rowe.
 83 2011-11-29 12:27:23 <CIA-100> bitcoinj: Throw an exception if file delete in the block store failed, clears another warning.
 84 2011-11-29 12:27:28 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * r88212f6bfa5d9fe70655a74143de1000a03b5d72 /: Make BlockStore and StoredBlock public. Move StoredBlock building into the class itself.
 85 2011-11-29 12:27:29 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * r37cb9cb6e5f4041fc23cc766a4fd45f9ea1b9069 /:
 86 2011-11-29 12:27:33 <CIA-100> bitcoinj: Add a decodeChecked method that uses the last 4 bytes as a checksum, for IRC support.
 87 2011-11-29 12:27:34 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * r65b80720bd9cd7923ec5a179963129be971b9bdd /: Move the next header creation method out of BlockTest and into Block, as it is useful for other unit tests as well.
 88 2011-11-29 12:27:39 <CIA-100> bitcoinj: Some changes to PeerGroup and how we manage the download process:
 89 2011-11-29 12:27:40 <CIA-100> bitcoinj: - Rewrite the Peer/PeerGroup tests to use the mock connection. This simplifies testing of multiple independent peer threads within the same gro
 90 2011-11-29 12:27:41 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * r8bf12acb2b819b677878223e60fba7d231ed26d0 / (3 files in 2 dirs):
 91 2011-11-29 12:27:42 <jeremias> wtf
 92 2011-11-29 12:27:45 <CIA-100> bitcoinj: Patch 7 from Steves lazy parsing patchset:
 93 2011-11-29 12:27:46 <CIA-100> bitcoinj: Patch 5 from Steves lazy parsing patchset:
 94 2011-11-29 12:27:47 <CIA-100> bitcoinj: deserialize use it prepopulate the transaction's hash. Likewise on serialize
 95 2011-11-29 12:27:48 <CIA-100> bitcoinj: bytes. This yields performance improvesment up to 400% by saving on a double
 96 2011-11-29 12:27:49 <CIA-100> bitcoinj: hash.
 97 2011-11-29 12:27:50 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * rf4e54046f07f4d7e8aab5079b835277ec493d359 /src/com/google/bitcoin/store/BoundedOverheadBlockStore.java:
 98 2011-11-29 12:27:59 <jeremias> u no floodkick
 99 2011-11-29 12:28:02 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * reee6e0341696d6ef2bc53c111cd2a51704b63047 /: Fix the ant build.xml file to include SLF4J
100 2011-11-29 12:28:03 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * ra2f0cb54a77eec255c534af038bf33c00baad30a /pom.xml: POM for 0.3 release
101 2011-11-29 12:28:04 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * r2191a9979f93924d3791bcc58ae134cb030ce4d9 /:
102 2011-11-29 12:28:05 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * rbebc83f64cecefb1da309eb656e566f0714306df /:
103 2011-11-29 12:28:06 <CIA-100> bitcoinj: Improve unit tests to verify the arguments to the onDeadTransaction event. Fixed a bug revealed by this.
104 2011-11-29 12:28:08 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * r675abc29743f31670ec9ea3cfa9aee9ed9ff14cc /: Remove transactions from the dead pool when they become live, and from pending when they become dead. Addresses comments from Miron.
105 2011-11-29 12:28:10 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * r892dffd732cb19494b0bbad94ecb8a9ba26efe48 /README: Update README.
106 2011-11-29 12:28:12 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * rbbe133be88b943ec1de499fbcd457f4ae642a27d / (6 files in 3 dirs):
107 2011-11-29 12:28:13 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * r53d5d7572bc4d89679b0771d36e103b96c27d184 /: Delete unused setFakeHashForTesting method.
108 2011-11-29 12:28:16 <sipa> TD: moving to git?
109 2011-11-29 12:28:19 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * r66e596a8eb93d8e3804532c3ed953145f8d697a1 /:
110 2011-11-29 12:28:20 <CIA-100> bitcoinj: - Rename variables to be more helpful than i,i2,j etc.
111 2011-11-29 12:28:21 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * r9b787659758de48d179798363735746c8f1441d8 /: Remove obsolete comment.
112 2011-11-29 12:28:22 <CIA-100> bitcoinj: First part of block chain handling rework.
113 2011-11-29 12:28:23 <CIA-100> bitcoinj: - Store the block chain using a get/put interface keyed by hash,
114 2011-11-29 12:28:24 <CIA-100> bitcoinj: - Add unit tests for difficulty transitions. Move some stuff into
115 2011-11-29 12:28:29 <TD> sipa: can you op me?
116 2011-11-29 12:28:33 <TD> sipa: we need to kick CIA
117 2011-11-29 12:28:35 <CIA-100> bitcoinj: Simplify Block.equals
118 2011-11-29 12:28:36 <CIA-100> bitcoinj: Miron Cuperman (devrandom) <miron@google.com> * r8e84d71308d6fb2612c8f53946909e11fb79877f /: PeerGroup - fix copyright and text
119 2011-11-29 12:28:37 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * r39ccbb595c04b5df5a0048c41de7e316b0c6e34a /pom.xml: Correct typo in the POM file.
120 2011-11-29 12:28:38 <sipa> TD: i don't have op
121 2011-11-29 12:28:46 <CIA-100> bitcoinj: Change how socket errors are handled in NetworkConnection and Peer. This allows for cleaner shutdown and simplifies
122 2011-11-29 12:28:47 <CIA-100> bitcoinj: Add a create method to Sha256Hash.
123 2011-11-29 12:28:48 <CIA-100> bitcoinj: Miron Cuperman (devrandom) <miron@google.com> * r7a834cad6e5dd268b2861a030e0fdf5cfd331a78 /tests/com/google/bitcoin/core/MockNetworkConnection.java: Fix another Java-6ism
124 2011-11-29 12:28:48 <devrandom> sorry about that, didn't know it was going to trigger every single commit hook
125 2011-11-29 12:28:49 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * rf6fd61a3a0f6815cfbe196ff31b22006ed8577e4 /: Add a SeedPeers class that contains a pre-compiled list of IP addresses taking part in the Bitcoin network for a long period of time, for use if IRC and DNS are unavailable. Based on a patch by Micheal Swiggs.
126 2011-11-29 12:28:50 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * ra9d3ca45e522c72d0f8457e5c1515980f914ab96 /: Add serialVersionUID to StoredBlock
127 2011-11-29 12:28:51 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * rba2255a1850a3d0a63f547186d81c348ebf15b55 / (2 files in 2 dirs): Second part ... refresh timestamp when confirming a spend to the wallet.
128 2011-11-29 12:28:52 <CIA-100> bitcoinj: Change the order of the messages in the version handshake. This fixes
129 2011-11-29 12:28:53 <CIA-100> bitcoinj: connections to BitCoin nodes beyond v0.30.20.2 which are "shy", that is, they do
130 2011-11-29 12:28:54 <CIA-100> bitcoinj: is to make port scanning harder, though it is questionable whether this really
131 2011-11-29 12:29:06 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * r5561ffcb90416bbd8e64c78426cfc76b57287557 /tests/com/google/bitcoin/core/SpeedTest.java: Remove SpeedTest as it's not generally useful to have in the test suite.
132 2011-11-29 12:29:07 <TD> that seems like quite a stupid bug
133 2011-11-29 12:29:09 <TD> in google code
134 2011-11-29 12:29:10 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * ra3a4a927af4ccfa3186ea837737206df9b73dbd5 / (5 files in 2 dirs): Always pass the wallet into the event listeners on every event.
135 2011-11-29 12:29:11 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * r320933bb70a038eca01a8ae09f4dd121ff894a34 /: Add more info to the Wallet.toString() output.
136 2011-11-29 12:29:16 <CIA-100> bitcoinj: Miron Cuperman (devrandom) <miron@google.com> * r2ce328aa0be6be98e7c234c078f48a78f9ad42c4 / (2 files in 2 dirs): Use RandomAccessFile in DiskBlockStore to fix corruption. Resolves issue 76
137 2011-11-29 12:29:17 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * r525d5e8d556f530de31a92c6ed7aca04ebde6499 /src/com/google/bitcoin/ (utils/BriefLogFormatter.java examples/PingService.java): Switch to JDK logging and add a simple formatter that is more concise than the default Java one.
138 2011-11-29 12:29:22 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * r617c31dd6f7b8e387dd1c5649dba131553550831 /: Remove some Java 6isms.
139 2011-11-29 12:29:23 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * r61488d88d6ccf9c3391112014bb43992b8530e05 /: Add dnsseed.bluematt.me to the DNS discovery list.
140 2011-11-29 12:29:27 <shadders> TD: sipa:  this is kinda fun... it's like bitcoinj's life is flashing before my eyes
141 2011-11-29 12:29:28 <TD> we need more ops
142 2011-11-29 12:29:47 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * r6a4d0e866ff265644c20bdb1218d8e0459ea6266 /: Fix an assertion in Wallet to use the correct type.
143 2011-11-29 12:29:47 <CIA-100> bitcoinj: Mike Hearn <hearn@google.com> * rd37723afbf6d7dfe5f7f39ecc828043331707a75 /:
144 2011-11-29 12:29:48 <TD> at least some euro ops
145 2011-11-29 12:30:24 <sipa> are we finished?
146 2011-11-29 12:30:32 <TD> don't know
147 2011-11-29 12:30:37 <TD> maybe some kind of CIA protection kicked in
148 2011-11-29 12:30:48 <TD> I wrote the first version of CIA and it had flood control then, but maybe it's different now
149 2011-11-29 12:30:54 <TD> that wasn't the first commit by any measn
150 2011-11-29 12:30:58 <TD> there are hundreds of revisions in that repo
151 2011-11-29 12:31:01 <shadders> my CIA cuts out after 10 commits
152 2011-11-29 12:31:11 <sipa> oh CIA is google's?
153 2011-11-29 12:31:14 <TD> no
154 2011-11-29 12:31:24 <TD> it was just a side project i did with some friends years ago
155 2011-11-29 12:31:30 <sipa> cool
156 2011-11-29 12:31:45 <TD> i didn't actually write CIA. i suggested it be generalized from its project and wrote the CVS integration. back when CVS was cool :)
157 2011-11-29 12:31:55 <TD> i disconnected the project from CIA as well, so maybe that's the reason it stopped
158 2011-11-29 12:32:12 <shadders> TD: can you start it again?  I wanna see the rest
159 2011-11-29 12:32:57 <shadders> I'm a keen historian
160 2011-11-29 12:33:29 <TD> heh
161 2011-11-29 12:33:34 <TD> http://code.google.com/p/bitcoinj/source/list
162 2011-11-29 12:34:05 <shadders> that's like watching a concert on VHS :p
163 2011-11-29 12:35:08 <devrandom> okay, we have git for both the source and wiki
164 2011-11-29 12:35:36 <TD> great
165 2011-11-29 12:35:39 <TD> let me try checking it out
166 2011-11-29 12:36:38 <TD> seems to have worked
167 2011-11-29 12:36:45 <TD> now the question is, working style
168 2011-11-29 12:36:51 <devrandom> very good
169 2011-11-29 12:37:09 <TD> should i create a clone for myself and push to that, then just do pulls into the mainline client? or just push work in directly as before
170 2011-11-29 12:37:15 <TD> seems simpler to stick with the latter
171 2011-11-29 12:37:34 <devrandom> the github way is to clone, and create a branch for every patch
172 2011-11-29 12:37:41 <devrandom> then merge after code review
173 2011-11-29 12:37:59 <shadders> devrandom: is that you miron?
174 2011-11-29 12:38:09 <devrandom> shadders: yes
175 2011-11-29 12:40:20 <TD> i guess this will break the jenkins and such
176 2011-11-29 12:40:24 <TD> though it seems disabled anyway
177 2011-11-29 12:40:30 <TD> no matter. i'm sure gary will fix it up
178 2011-11-29 12:40:41 <TD> devrandom: if you still can't sleep i have a pending txns patch for you to review
179 2011-11-29 12:41:31 <sipa> gary rowe?
180 2011-11-29 12:41:38 <TD> yeah
181 2011-11-29 12:41:54 <sipa> ah, met him in prague last weekend
182 2011-11-29 12:42:32 <sipa> hello da2ce7!
183 2011-11-29 12:42:47 <da2ce7> hey sipa, it was great to see you at the confrence :)
184 2011-11-29 12:42:55 <sipa> likewise :D
185 2011-11-29 12:42:59 <TD> how was it?
186 2011-11-29 12:43:02 <TD> good talks?
187 2011-11-29 12:43:07 <da2ce7> ya
188 2011-11-29 12:43:12 <TD> i read the mobile payments thing at the restaurant did not work :-(
189 2011-11-29 12:43:19 <sipa> wifi troubles, indeed
190 2011-11-29 12:43:22 <da2ce7> yeah, sucky wifi.
191 2011-11-29 12:43:33 <sipa> nonetheless, people did pay with bitcoin :)
192 2011-11-29 12:43:39 <TD> ah, wifi issues
193 2011-11-29 12:43:50 <da2ce7> we really need a voucher based system, so people can do offline transactions...
194 2011-11-29 12:43:53 <sipa> da2ce7: by the way, i fear the bloom filter idea won't help to reduce database writes
195 2011-11-29 12:43:57 <TD> a nice addition to the mobile clients, would be a bluetooth broadcast network
196 2011-11-29 12:44:04 <da2ce7> sipa: why so?
197 2011-11-29 12:44:30 <TD> i'm sure sombody there had a local non-wifi data connection
198 2011-11-29 12:44:32 <sipa> da2ce7: a tx comes in, gets verified, and processed; its bits are set, and nothing is written to the database
199 2011-11-29 12:44:39 <TD> or you can just cache the transactions and assume no double spend, if you trust the spender
200 2011-11-29 12:44:56 <sipa> da2ce7: now an attempted double spend comes in - you get the bits and they are all set, meaning "probably spent"
201 2011-11-29 12:45:15 <sipa> there is however no way to be sure, as there is no definite information in the database
202 2011-11-29 12:45:29 <sipa> s/get/check/
203 2011-11-29 12:46:01 <sipa> or am i missing something?
204 2011-11-29 12:46:29 <da2ce7> yeah... if the bits are set, we can do the extra work to work out for certan if it is a doubble spend or not...
205 2011-11-29 12:46:47 <da2ce7> however if the bits are not set, we can sure that it is NOT a doubble spend.
206 2011-11-29 12:46:54 <sipa> yes, i know
207 2011-11-29 12:47:03 <sipa> so it does help to verify transactions
208 2011-11-29 12:47:07 <devrandom> TD: I think I better try to sleep again
209 2011-11-29 12:47:13 <sipa> it can very quickly guarantee that it is not a double spend
210 2011-11-29 12:47:19 <TD> devrandom: ok, good night
211 2011-11-29 12:47:32 <sipa> da2ce7: but it does still require each spending to be written to the database as well
212 2011-11-29 12:47:51 <sipa> since there is no way of guaranteeing spentness afterwards
213 2011-11-29 12:49:05 <sipa> and just not requiring data to be read, which still needs to be written to afterwards, won't help much i believe (only maybe for miners that won
214 2011-11-29 12:49:15 <sipa> want to verify incoming transactions very quickly
215 2011-11-29 12:49:26 <da2ce7> tx comes in, we need to first check if or the imputs are valid, checking the inputs requres that the we lookup the old outputs (to get the ammounts).
216 2011-11-29 12:49:35 <sipa> yes
217 2011-11-29 12:50:22 <sipa> 1) syntactic validity 2) bloom check to verify prevouts are not spend 3) read prevouts and verify scripts 4) update bloom filter and spendness in db
218 2011-11-29 12:50:26 <gmaxwell> you could use a bloom filter on the old outputs to quickly exclude junk transactions where that would fail.
219 2011-11-29 12:50:28 <sipa> that's the best you can do
220 2011-11-29 12:50:44 <gmaxwell> And if you use a counting filter, you could remove txn as they are spent rather than recomputing it.
221 2011-11-29 12:51:01 <gmaxwell> (though usually the cost of counting is high enough that it's better to just periodically recompute)
222 2011-11-29 12:51:46 <gmaxwell> it would be useful if people were conducting DOS attacks that involved flooding nodes with syntatically valid transactions that use fantasy inputs.
223 2011-11-29 12:51:50 <sipa> da2ce7: my point is that the idea of not needing to do any db write while processing transactions is not possible
224 2011-11-29 12:52:00 <gmaxwell> but otherwise&
225 2011-11-29 12:52:09 <makomk> The thing I've been thinking about bloom filters for is fast IsMine filtering on deeply embedded lightweight clients, actually.
226 2011-11-29 12:52:58 <sipa> makomk: not sure if you gain that much compared to just a hashset
227 2011-11-29 12:53:12 <makomk> Perhaps not, no.
228 2011-11-29 12:53:20 <sipa> provided you're able to keep the set in memory
229 2011-11-29 12:53:40 <sipa> if you're watching millions of addresses, and they are kept in a db on disk, a bloom filter would definitely help
230 2011-11-29 12:55:50 <da2ce7> the best optimization is a way to qucikly verify most tx, and the unlucky ones we can spend a bit more time on....
231 2011-11-29 12:56:32 <da2ce7> however I don't know any other way of doing it other than having a bloom-map for standard tx and their ammounts.
232 2011-11-29 12:56:32 <gmaxwell> da2ce7: but you can't quickly verify, you could only quickly exclude.
233 2011-11-29 12:56:56 <sipa> da2ce7: even that would not avoid db writes for each spent txout
234 2011-11-29 12:57:17 <sipa> and i assume most txs are valid, not invalid (in which case a quick bail-out would help)
235 2011-11-29 12:57:57 <da2ce7> sipa: we can have a large bloom filter, then only commit the tx hash if it it a conflit in the filter...
236 2011-11-29 12:58:06 <sipa> da2ce7: you don't get it
237 2011-11-29 12:58:14 <gmaxwell> ...
238 2011-11-29 12:58:15 <sipa> look at my example
239 2011-11-29 12:58:16 <da2ce7> filter + modifcations...
240 2011-11-29 12:58:30 <sipa> you cannot detect "conflicts"
241 2011-11-29 12:58:50 <sipa> every spending puts the bloom filter for those prevouts in the "probably spent" state\n2254964
242 2011-11-29 13:00:22 <da2ce7> so, maybe I missunderstand bloom filters... bit if I'm about to write a bit that is already set, can I tell that it is set, and say "bloom filter + these extra hashes"
243 2011-11-29 13:00:45 <sipa> ok, step by step
244 2011-11-29 13:00:48 <sipa> a valid tx comes in
245 2011-11-29 13:00:56 <da2ce7> ya.
246 2011-11-29 13:01:01 <sipa> for each of its inputs, we check the bloom filter
247 2011-11-29 13:01:19 <sipa> in the best case, not all its bits are set
248 2011-11-29 13:01:34 <sipa> so we have a guaranteed unspent prevout
249 2011-11-29 13:01:50 <sipa> we lookup the prevout itself, and verify amounts and scripts; good
250 2011-11-29 13:02:01 <sipa> everything went fine, this transaction is valid
251 2011-11-29 13:02:07 <sipa> so what do we do?
252 2011-11-29 13:03:04 <da2ce7> write the outputs to the bloom filter once it is in a block, I guess.
253 2011-11-29 13:03:23 <sipa> indeed, mark the prevout's hash bits in the bloom filter
254 2011-11-29 13:03:34 <TD> hmm
255 2011-11-29 13:03:36 <TD> any git experts here?
256 2011-11-29 13:03:51 <sipa> not expert, but i manage to use it
257 2011-11-29 13:03:55 <da2ce7> if any of the outputs (unlikely) conflict with an exzisting hash bits, we log that hash to a 'also excluded' list.
258 2011-11-29 13:04:13 <TD> i have cloned the main repo of bitcoinj to my local disk. now i'd like to switch to a clone of my personal clone instead.
259 2011-11-29 13:04:15 <wereHamster> TD: <-
260 2011-11-29 13:04:20 <sipa> da2ce7: but the point is that you must prevent *future* conflicts, that you do not know yet
261 2011-11-29 13:04:22 <TD> is there a way to switch my local clone to a different remote repository?
262 2011-11-29 13:04:42 <TD> i can do it just by recloning my remote repository then using patch/diff/mv :)
263 2011-11-29 13:04:43 <da2ce7> sipa: how, we are only checking a list we already know...
264 2011-11-29 13:04:49 <TD> might as well check if there's a magic command first
265 2011-11-29 13:04:56 <wereHamster> TD: git remote add td <url of your personal repository>; git fetch td; git checkout ...
266 2011-11-29 13:05:01 <da2ce7> we already know every hash in the bloom filter, we can check if there is any conflitcts or not.
267 2011-11-29 13:05:14 <gmaxwell> da2ce7: I generate a new transaction which conflicts with your last one. You've never seen this transaction.
268 2011-11-29 13:05:27 <wereHamster> TD: of if you want to permanently change the remote url: git remote set-url origin <some other url>
269 2011-11-29 13:05:33 <sipa> da2ce7: ok, so let's continue; this was a hash that itself didn't conflict, we actually changed bits from zero to one in the bloom filter
270 2011-11-29 13:05:47 <sipa> da2ce7: now a double spend arrives
271 2011-11-29 13:05:49 <TD> wereHamster: ok i did the second command
272 2011-11-29 13:05:59 <TD> wereHamster: i don't need to do anything to make it resync with server-side stuff?
273 2011-11-29 13:06:00 <sipa> da2ce7: we again check its prevouts in the bloomfilter
274 2011-11-29 13:06:10 <wereHamster> TD: git fetch origin
275 2011-11-29 13:06:22 <sipa> da2ce7: problem... all bits are set
276 2011-11-29 13:06:33 <TD> hmm, ok, thanks
277 2011-11-29 13:06:34 <sipa> da2ce7: what now?
278 2011-11-29 13:06:58 <sipa> how do we verify whether this is a double spend, or an accidental collision in the bloom filter?
279 2011-11-29 13:07:28 <wereHamster> TD: nice to see you again. Last time we met was quite a long time ago :) Do you work in zurich now?
280 2011-11-29 13:07:55 <da2ce7> since we know that those bits corispond to a single output, or we would have listed both hashes in the 'also spent' list, we check it aganst the bits, and the 'also spent' if it conflitcs we know it is spent.
281 2011-11-29 13:08:03 <TD> yep
282 2011-11-29 13:08:05 <TD> i do indeed
283 2011-11-29 13:08:17 <da2ce7> becasue as we made the bloom filter, we checked for conflitcts.
284 2011-11-29 13:08:23 <gmaxwell> da2ce7: so you just throw out the transaction because its a hit in the filter?
285 2011-11-29 13:08:31 <gmaxwell> great. keep that pattern in mind.
286 2011-11-29 13:08:59 <TD> wereHamster: wine, right?
287 2011-11-29 13:09:06 <gmaxwell> da2ce7: Now I generate a new completely valid transaction. But it just so happens by chance to have the same bits as a spent one. But you've never seen my transaction before.
288 2011-11-29 13:09:34 <da2ce7> ok, I've just worked out the problem.... ;)
289 2011-11-29 13:09:36 <gmaxwell> So .. you do what you just said.. you check the bits (they match)... then you drop the transaction.
290 2011-11-29 13:09:42 <gmaxwell> okay. :)
291 2011-11-29 13:09:51 <gmaxwell> We all have our slow days.
292 2011-11-29 13:10:04 <sipa> ok, glad i didn't make a mistake in my reasoning
293 2011-11-29 13:10:10 <wereHamster> TD: yeah :)
294 2011-11-29 13:10:39 <da2ce7> what happens if we have a list of 'good tx' aka a list of hashes that we know conflit with the spent tx filter, however are not spent yet.
295 2011-11-29 13:10:53 <da2ce7> so you have 'spent filter' + whitelist.
296 2011-11-29 13:11:31 <gmaxwell> why bother with the spent filter at all. Just have the whitelist and remove things from it as they're spent?  But this still doen't save you... alas.
297 2011-11-29 13:11:47 <gmaxwell> Because you'll still have to store/lookup to get the values to validate.
298 2011-11-29 13:11:53 <sipa> to construct that, you need to iterate the entire set of unspent txouts after marking bits in the filter
299 2011-11-29 13:12:08 <da2ce7> ya
300 2011-11-29 13:12:14 <da2ce7> very expencive to make.
301 2011-11-29 13:12:34 <sipa> O(n) times more expensive than just looking it up in the db
302 2011-11-29 13:13:00 <gmaxwell> sure but after n transactions you get it back. ;)
303 2011-11-29 13:13:17 <gmaxwell> (er, I mean you're even again ;) )
304 2011-11-29 13:16:00 <da2ce7> lol, you just have a large filter, and make the tx have to include more fees if they are spending an output that conflicts with the filter...
305 2011-11-29 13:16:47 <sipa> that still requires you to keep a non-probabilistic data structure with all non-spend txouts
306 2011-11-29 13:17:40 <gmaxwell> The key reason the lossy structure do not work here is that almost all requests will be valid.
307 2011-11-29 13:18:07 <gmaxwell> They only save you time in the cases which should almost never happen.
308 2011-11-29 13:18:31 <Diablo-D3> well guess fucking what
309 2011-11-29 13:18:37 <Diablo-D3> the rich people have no decided to steal more of my money
310 2011-11-29 13:18:46 <gmaxwell> And you can't flip it around because the space of invalid transactions is morally infinite... any reasonable bloom filter of invalid txn would have all its bits set. :)
311 2011-11-29 13:18:49 <Diablo-D3> american airlines has filed for bankruptcy, and this headline is not a repeat from the 70s.
312 2011-11-29 13:18:59 <Diablo-D3> lets bring on the fucking bailouts, you fucking fags
313 2011-11-29 13:19:05 <Diablo-D3> I fucking double dog dare you
314 2011-11-29 13:19:23 <gmaxwell> Diablo-D3: #AA is over -> there.
315 2011-11-29 13:19:35 <sipa> one possibility is to not use hash functions, but an invertible mapping between the bits and the txouts
316 2011-11-29 13:19:56 <sipa> so every time you mark bits in the filter, you can easily iterate possible conflicts with it
317 2011-11-29 13:20:12 <sipa> but even if that's possible, it won't gain you anything
318 2011-11-29 13:21:13 <Diablo-D3> Im just tired of this shit
319 2011-11-29 13:21:17 <Diablo-D3> I know a bailout is coming
320 2011-11-29 13:21:24 <Diablo-D3> we bailed those fuckers out before, and we'll do it again
321 2011-11-29 13:21:35 <Diablo-D3> the fucking sheeple will demand that their corporate overlords "fix' it
322 2011-11-29 13:22:43 <da2ce7> use a filter for only standard tx, where you map the ammount to the bit, then you can quickly validate a tx without random reads...
323 2011-11-29 13:23:04 <da2ce7> in the case there are not any bit-hits.
324 2011-11-29 13:23:08 <sipa> da2ce7: but you still need a write
325 2011-11-29 13:23:09 <gmaxwell> sipa: I still think a minimal perfect hash for finding txouts in an 'archived-and-locked' blockchain would be useful and interesting. E.g. O(1) lookup on that? not there? must be invalid or more recent then do a logN lookup on more recent txn...
326 2011-11-29 13:23:23 <Diablo-D3> night all
327 2011-11-29 13:23:29 <sipa> gmaxwell: for archived stuff, sure
328 2011-11-29 13:23:58 <gmaxwell> da2ce7: the amounts in non-standard txn aren't any different.
329 2011-11-29 13:24:21 <da2ce7> we we can work out for certan if the tx are NOT in a block older than X
330 2011-11-29 13:25:00 <gmaxwell> da2ce7: and you can't do that .. if there are two inputs and >=5 btc out....  how do you know the value of the inputs to do the lookup?
331 2011-11-29 13:25:29 <gmaxwell> I1 + I2 >= 5 is the only invariant you know must be true.
332 2011-11-29 13:25:41 <gmaxwell> But the inputs could be 0.1 and 20. (big fees)
333 2011-11-29 13:26:17 <da2ce7> :(
334 2011-11-29 13:26:59 <da2ce7> I guess, bitcoin isn't suited for probbalistic data structures...
335 2011-11-29 13:27:13 <gmaxwell> (and that fact .. actually kinda sucks in terms of using fees as evidence for anti-ddos... since you'll have to lookup to know the fees.)
336 2011-11-29 13:30:15 <da2ce7> we need a non-probilistic lookup for every non-spent tx output, with it's script and ammount...
337 2011-11-29 13:30:20 <da2ce7> and that is what we have already.
338 2011-11-29 13:30:53 <gmaxwell> da2ce7: all you have to do is start attacking bitcoin with txn that have bogus inputs, then your filtering idea will have a purpose. :-/
339 2011-11-29 13:33:23 <da2ce7> gmaxwell: how large is the very good dertmerisitic data strurture for all the non-spent outputs and their scripts and ammounts?
340 2011-11-29 13:33:40 <da2ce7> we are looking like 500mb now rite?
341 2011-11-29 13:34:09 <gmaxwell> https://en.wikipedia.org/wiki/Bloom_filter#Probability_of_false_positives
342 2011-11-29 13:34:19 <sipa> http://pastebin.com/7iKJkuqh
343 2011-11-29 13:35:02 <sipa> da2ce7: current txouts compress to 126Mb
344 2011-11-29 13:35:34 <da2ce7> so a little more that we would be happy to store all in ram...
345 2011-11-29 13:38:36 <da2ce7> well my other idea, well primarly designed for namecoin, was to include a Merkle tree of every block root-hash in the coinbase of every block.
346 2011-11-29 13:39:39 <da2ce7> so by downloading the latest 100 blocks (or so, with a few sanity check), people can just download the list of every block hash. and be able to compute there isn't any errors in the list.
347 2011-11-29 13:40:14 <da2ce7> thus allowing 'tx dns' systems, where we can lookup any tx just by finding it's merkle path.
348 2011-11-29 13:40:47 <da2ce7> it should fit into one DNS sized packet :)
349 2011-11-29 13:40:53 <UukGoblin> da2ce7, well, the root-hashes are relatively small
350 2011-11-29 13:41:31 <UukGoblin> 10 years worth of blocks' hashes would be about 40MB
351 2011-11-29 13:42:09 <da2ce7> sure, but to verifiy the list atm, I need to download every past block.
352 2011-11-29 13:42:37 <UukGoblin> downloading just the block headers is what should happen, imho
353 2011-11-29 13:42:46 <UukGoblin> and then look up txns via merkle branches like you said
354 2011-11-29 13:43:04 <UukGoblin> (I'm no expert though)
355 2011-11-29 13:43:07 <da2ce7> if the latest blocks included the a merkle root, I would be able to check if the block headers are valid or not.
356 2011-11-29 13:44:07 <UukGoblin> ah, I see
357 2011-11-29 13:44:12 <UukGoblin> (roughly)
358 2011-11-29 13:45:53 <gmaxwell> da2ce7: I haxor your dns.
359 2011-11-29 13:45:57 <gmaxwell> da2ce7: here is how:
360 2011-11-29 13:46:03 <da2ce7> that is what I wanted the bloom filter originaly for; if we were using a large one, all you care about is if the tx is spent or not... so people build their own filter, and keep nothing more
361 2011-11-29 13:46:13 <gmaxwell> da2ce7: I get a name. It gets mined in block 10.
362 2011-11-29 13:46:30 <gmaxwell> da2ce7: then .. later it changes ownership to you... in block 10000000
363 2011-11-29 13:46:47 <gmaxwell> da2ce7: I answer queries using block 10 as the result.
364 2011-11-29 13:46:57 <da2ce7> yep, so the block 10 one is marked of in my bloom filter... and reject your queries...
365 2011-11-29 13:46:57 <gmaxwell> (okay they expire, but same deal)
366 2011-11-29 13:47:20 <da2ce7> and I don't care about the rare case of false positive.
367 2011-11-29 13:47:26 <gmaxwell> da2ce7: ah you're assuming the client has been watching the whole network?
368 2011-11-29 13:47:36 <gmaxwell> I have something better for you anyways.
369 2011-11-29 13:47:41 <gmaxwell> Just commit all the open names.
370 2011-11-29 13:48:07 <gmaxwell> then when you query a helpful node gives you the tree fragment connecting the name to the root of the a recent block.
371 2011-11-29 13:48:16 <gmaxwell> da2ce7: https://bitcointalk.org/index.php?topic=21995.0
372 2011-11-29 13:48:49 <da2ce7> hmmm
373 2011-11-29 13:49:56 <gmaxwell> You can even arrange the tree so that there can only be one location.. so someone couldn't fake a NXDOMAIN, they could only refuse to reply.
374 2011-11-29 13:50:20 <gmaxwell> Though I suspect there may be stupid attacks that arise out of people intentionally choosing names that collide the hash.
375 2011-11-29 13:51:25 <da2ce7> yeah... well I though that if you have a standard bloom filters, people would choose not to transfer the domain to a hash that conflits with a the bloom filter...
376 2011-11-29 13:51:36 <da2ce7> otherwise nobody would accept the lookups.
377 2011-11-29 13:51:51 <da2ce7> it is only on their own dissavantage.
378 2011-11-29 13:52:33 <da2ce7> but you have the attack that people will see a tranfer, thne rush in a tx that has a higher-fee that conflits with it in the filter.
379 2011-11-29 13:52:57 <gmaxwell> I suppose thats how you solve the problem I'm suggesting... limit the tree depth... some names would become unregisterable but its highly unlikely an honest user would ever encounter such a name.
380 2011-11-29 13:55:26 <da2ce7> hmm...
381 2011-11-29 13:59:05 <da2ce7> well I've gotta prepare to go to london tonight...
382 2011-11-29 13:59:08 <da2ce7> have a good one all...
383 2011-11-29 13:59:29 <UukGoblin> da2ce7, going for a beer? :-)
384 2011-11-29 14:00:09 <da2ce7> :) UukGoblin maybe, when you going out? I'm in prauge atm... I'll be arriving in at arround 11pm
385 2011-11-29 14:00:25 <UukGoblin> all pubs are closed at 11pm ;-[
386 2011-11-29 14:00:31 <UukGoblin> perhaps thursday ;-)
387 2011-11-29 14:00:39 <da2ce7> oh yeah, I'm so used to european times...
388 2011-11-29 14:01:14 <wereHamster> is there a conference in prague right now?
389 2011-11-29 14:01:24 <da2ce7> wereHamster: no, it is over...
390 2011-11-29 14:01:36 <wereHamster> was it any good for the bitcoin community?
391 2011-11-29 14:01:38 <UukGoblin> how many people attended?
392 2011-11-29 14:01:40 <UukGoblin> ;-]
393 2011-11-29 14:01:45 <da2ce7> about 120
394 2011-11-29 14:02:14 <da2ce7> I quite enjoyed it... I spent my entire time talking about Open Transctions tho.
395 2011-11-29 14:02:36 <UukGoblin> :-)
396 2011-11-29 14:05:52 <UukGoblin> hrm, can't actually recommend any :-S
397 2011-11-29 14:05:55 <sipa> really 120? :o
398 2011-11-29 14:07:14 <da2ce7> sipa: I think so... that is what I beleve michael was saying it was arround.
399 2011-11-29 14:08:35 <sipa> da2ce7: too bad your talk was cut off, by the way
400 2011-11-29 14:08:58 <da2ce7> :S yeah, it was a little annoying. But I think that I got the gist across.
401 2011-11-29 14:09:14 <sipa> i'm afraid many people don't grasp the concept
402 2011-11-29 14:09:41 <da2ce7> well you cannot expect them to grasp bitcoin after one presentation either...
403 2011-11-29 14:10:02 <da2ce7> all you can do is hopefully peak their intrest so they will spend the time to learn it for themselves.
404 2011-11-29 14:10:14 <wereHamster> will there be any videos of the talks?
405 2011-11-29 14:10:17 <da2ce7> yep
406 2011-11-29 14:10:31 <da2ce7> they are going to eventualy put them up on youtube
407 2011-11-29 14:10:44 <wereHamster> great. I forgot to send my grandma to take notes, she lives in prague :P
408 2011-11-29 14:11:27 <da2ce7> Ok, I'm going now... chat later guys.
409 2011-11-29 16:02:55 <gmaxwell> So during an initial syncup.. bitcoin creates a whole pile of transaction log files.. which it deletes at the next startup.
410 2011-11-29 16:03:10 <gmaxwell> Anyone know if it keeps file descriptors open for each of them?
411 2011-11-29 16:08:34 <sipa> gmaxwell: for the log files, no idea
412 2011-11-29 16:09:09 <sipa> it seems to create a db transaction for each block processed, as it relies on being able to cancel that transaction when things go wrong
413 2011-11-29 16:09:16 <gmaxwell> someone in #bitcoin had it crash during initial synchup with db::open() returning invalid argument .. which seems quite suspect.
414 2011-11-29 16:45:45 <casacius> Hey all, just wanted to throw out an idea and see if it had merit.
415 2011-11-29 16:45:50 <gmaxwell> No.
416 2011-11-29 16:45:54 <gmaxwell> (that was easy)
417 2011-11-29 16:46:12 <casacius> I am new to the idea that you can take an EC point, "add" something to it, and get a new EC point, where the private key is the privkey of the first point plus whatever you added to it.
418 2011-11-29 16:46:32 <sipa> casacius: it's pretty much just like numbers
419 2011-11-29 16:46:51 <casacius> I don't understand the math well enough to know that's airtight, but I do see a lot of practical applications for that if that turns out to be the case.
420 2011-11-29 16:46:51 <sipa> a private key is a number N, a public key is N times the generator point
421 2011-11-29 16:47:27 <casacius> Here would be just one little application.  Right now we have wallet encryption.  And the keypool can only be topped up on an unencrypted wallet, right?
422 2011-11-29 16:47:41 <sipa> if P1 is N1*G, and P2 is N2*G, then (P1+P2) = (N1+N2)*G
423 2011-11-29 16:47:55 <sipa> thus P1+P2 is the pubkey corresponding to the private key N1+N2
424 2011-11-29 16:48:00 <sipa> casacius: right
425 2011-11-29 16:48:05 <gmaxwell> Yes, what you're thinking could be done. But thats a really narrow improvement, and potentially not worth the testing/qa burden.
426 2011-11-29 16:48:10 <casacius> What if an encrypted wallet kept a point unencrypted (but kept the N encrypted), it would be possible to add keys to the wallet.
427 2011-11-29 16:48:20 <casacius> gmaxwell: Yeah, I'm with you, I believe you are right on that point.
428 2011-11-29 16:48:23 <sipa> casacius: it does
429 2011-11-29 16:48:29 <sipa> casacius: only N is stored encrypted
430 2011-11-29 16:48:30 <casacius> (re: why bother, too difficult)
431 2011-11-29 16:48:33 <makomk> This was actually considered when wallet encryption was first implemented IIRC.
432 2011-11-29 16:48:48 <gmaxwell> But, yes, your understanding sounds fine. That could be done.
433 2011-11-29 16:49:02 <casacius> but given that... why don't I just start a two-factor wallet production service now, where I create N1, and deliver an open source program so users can generate N2
434 2011-11-29 16:49:19 <casacius> and I give them N1*G
435 2011-11-29 16:49:23 <casacius> and then sign their transactions
436 2011-11-29 16:49:33 <gmaxwell> Because you can't spend without having both N1/N2 in your hot little hands when you sign the tn.
437 2011-11-29 16:49:34 <casacius> and then send them a backup CD containing N1 in the mail (so it's out of band)
438 2011-11-29 16:50:02 <gmaxwell> ah you can do that.. but why?
439 2011-11-29 16:50:14 <casacius> OK, so I need both N1 and N2...somewhat limiting I suppose.... i don't imagine there is a way to create a signature with N2, and "add" something from N1 to it?
440 2011-11-29 16:50:28 <casacius> gmaxwell: you are asking why I would do which?
441 2011-11-29 16:50:44 <sipa> multisignature allows you to do the same thing, without needing both keys in the same hands at the same time
442 2011-11-29 16:51:01 <gmaxwell> You could generate a half wallet, but it's useless without the other half in your hands at the same time. I was wondering why you'd do that.
443 2011-11-29 16:51:02 <casacius> Even if I need N1 and N2, at the very least, the user's exposure is limited ot the balance of the single address that N2 encumbers...rather than his whole wallet.
444 2011-11-29 16:51:26 <sipa> casacius: love your coins, by the way - got myself a 1BTC one at the prague conference :)
445 2011-11-29 16:51:27 <gmaxwell> The whole motivation for the multisig stuff / op_eval etc/ is to make the objective there possible.
446 2011-11-29 16:51:33 <casacius> gmaxwell: someone could get a 100% secure paper wallet, simply by combining two half-wallets from two sources
447 2011-11-29 16:51:50 <casacius> sipa: awesome, thanks
448 2011-11-29 16:52:07 <sipa> casacius: the general idea is: yes, you can do transfer funds by passing private keys around (partial ones, full ones, ...) instead of using the scripts in transactions
449 2011-11-29 16:52:09 <gmaxwell> Yes, they could have that. But they couldn't spend from it without putting both halves on one computer.
450 2011-11-29 16:52:11 <casacius> i agree on the multisig and op_eval, but i'm surprised to know that i could do something like this right now with what we have
451 2011-11-29 16:52:26 <sipa> but doing it through scripts allows you to do it with less trust
452 2011-11-29 16:52:38 <casacius> Agreed they would have to put both halves on one computer, their exposure wouldn't be zero but it would be grossly minimized
453 2011-11-29 16:52:57 <gmaxwell> casacius: well, except you cant... without multisig both private keys need to make their way to a single trusted machine to spend, unfortunately.
454 2011-11-29 16:53:09 <gavinandresen> casacius: see the discussion here:  https://bitcointalk.org/index.php?topic=19080.80
455 2011-11-29 16:53:24 <casacius> here is another application I thought of.  I could sell 1000 BTC gold bars, but people get suspicious that I could burn them.  As an option...
456 2011-11-29 16:53:34 <gmaxwell> "minimized" depends on the threat model, e.g. under the assumption that the computer has malware which autosteals keys.. it's not good.
457 2011-11-29 16:53:50 <gavinandresen> ... it probably IS possible to split one ECDSA key into two parts, and then generate a valid signature using each of the two parts independently.   But it is tricky.
458 2011-11-29 16:53:50 <gmaxwell> casacius: yes, key splitting for you would be quite good I think.
459 2011-11-29 16:54:04 <casacius> they could send me G * sha256(passphrase), call that N1, and I could send the funds to the bitcoin address derived from their N1 plus my N2.
460 2011-11-29 16:54:21 <casascius> not sure why i mistyped my own name =)
461 2011-11-29 16:54:34 <gmaxwell> casascius: yes sir. That would work fine.
462 2011-11-29 16:54:50 <casascius> If I did that, one could buy my gold bars without any threat that I could steal their money
463 2011-11-29 16:55:06 <casascius> people don't worry about 1 BTC coins, but high value bars, makes people think about it more
464 2011-11-29 16:55:37 <gmaxwell> though they couldn't sell the bar to someone else without taking a risk.
465 2011-11-29 16:55:47 <gmaxwell> (er without that person taking a risk)
466 2011-11-29 16:56:16 <casascius> gmaxwell: If I laser etched on the bar a hash of g * sha256(passphrase), they could prove they properly conveyed passphrase by allowing their buyer to recompute it
467 2011-11-29 16:56:23 <casascius> (I just got a laser etching/cutting table a couple weeks ago....way sweet)
468 2011-11-29 16:56:39 <gmaxwell> casascius: yes, but the seller could steal the coins out from under them
469 2011-11-29 16:56:56 <casascius> https://bitcointalk.org/index.php?topic=53203.msg634255#msg634255
470 2011-11-29 16:57:06 <casascius> gmaxwell: how would the seller steal?  tehy would need to compromise my hologram to compute N2
471 2011-11-29 16:57:29 <gmaxwell> ah .. so you'd use those on the bar too? okay.
472 2011-11-29 16:57:41 <gmaxwell> Then you could conspire with the seller. ;) (but yes, there you go)
473 2011-11-29 16:58:15 <casascius> presumably, i'd want to conspire with someone to create some kickass secure bars...i provide n1, they provide n2, perhaps on a bar that holds 2 holograms
474 2011-11-29 16:58:37 <gmaxwell> You don't print g * sha256(passphrase) .. you print N2 and the address.. and they see if they can compute the address themselves.
475 2011-11-29 16:58:41 <casascius> i wouldn't bother with this for a 1 btc coin, but 100+ or 1000+ it's actually not a bad idea
476 2011-11-29 16:59:34 <casascius> somehow I imagined that the passphrase should be etched on the bar, so the bar itself is the full bearer item, it's just not available to me as the manufacturer and potential knower of the number under the hologram
477 2011-11-29 17:00:23 <casascius> so i suppose what to etch on the bar would be up to the person who did it, based on their security needs, hoping that it would be enough to prove to their buyer that the passphrase was good without needing to reveal N2
478 2011-11-29 17:00:34 <[Tycho]> casascius: do you use some kind of powder or paste to etch metals ?
479 2011-11-29 17:00:42 <gmaxwell> Wortks either way but you already need to print the address to make it easy to look up the balance.
480 2011-11-29 17:00:57 <casascius> the only thing that sucks, is I'm the one that owns the etcher =) so someone else would need to have some sort of expensive investment to add their secret to the bar (unless they used a simple sticker)
481 2011-11-29 17:01:08 <gmaxwell> casascius: also, only giving N2 + address would make someone trying to bruteforce the password do more work.
482 2011-11-29 17:01:22 <gmaxwell> oh you mean putting the cleartext on it.
483 2011-11-29 17:01:28 <casascius> [tycho]: I have a spray (expensive - $75/can) that creates a reactive layer on the metal, and then I can laser that.  WIthout that layer, the laser I have has no effect on the metal
484 2011-11-29 17:01:46 <gmaxwell> Obviously you need a bigger laser.
485 2011-11-29 17:01:48 <gmaxwell> ;)
486 2011-11-29 17:01:55 <sipa> mounted an a shark
487 2011-11-29 17:01:57 <casascius> i just need to make more money selling bitcoins and then maybe it will happen
488 2011-11-29 17:02:11 <casascius> bitcoin money bought this machine
489 2011-11-29 17:02:23 <gmaxwell> casascius: you could make a place to affix a sticker at least.
490 2011-11-29 17:02:36 <[Tycho]> What's happened with l0ss site ? Those graphs were so nice...
491 2011-11-29 17:02:45 <casascius> The bottom of the bar is flat and bare, a sticker would fit there.  (it would be unsightly, but then again it's the bottom)
492 2011-11-29 17:03:30 <gmaxwell> casascius: perhaps you could come up with a less unsightly sticker design that the buyer could print without having sharks and lasers? e.g. a transparent sticker.
493 2011-11-29 17:04:12 <casascius> gmaxwell: yeah, they have clear labels at officemax....they also have inkjet printable "gold foil" (but it's not real gold, and looks pretty fake when stuck on a gold plated bar)
494 2011-11-29 17:04:35 <casascius> what would be really sweet is if some other company made some of these (e.g. Bitbills), and we secured each others products
495 2011-11-29 17:04:40 <gmaxwell> e.g. could you get some better goild foil stickers made and just send them with the bar?
496 2011-11-29 17:04:54 <gmaxwell> yes, thats a possibility too.
497 2011-11-29 17:05:20 <casascius> for example, if bitbills or someone got the same 1" round stickers as I did, and I had gold bars made with 2 receptacles...they add one, I add one, and I laser-etch the resulting bitcoin address onto the bar
498 2011-11-29 17:05:50 <sipa> a receptacle... is that english, or a hybrid between a tentacle and a receptable?
499 2011-11-29 17:05:54 <casascius> (though I don't know about bitbills, they seem alive but not producing anything)
500 2011-11-29 17:05:57 <gmaxwell> why stop at two. ;)
501 2011-11-29 17:06:53 <casascius> gmaxwell: I suppose the more you get, the more inconvenient the redemption (and the greater chance that one of the codes is missing or corrupt and the balance unredeemable)... a balance between need for security
502 2011-11-29 17:08:00 <casascius> A half-wallet might also be valuable for creating a MyBitcoin-like service
503 2011-11-29 17:08:15 <casascius> Haven't really thought it through,
504 2011-11-29 17:08:35 <casascius> but it seems like it would allow a user to control the funds, while enjoying the convenience of a web based wallet
505 2011-11-29 17:12:19 <casascius> So here might be a very safe way to produce a paper wallet.  Consider Bitaddress.org, which prints a perfectly good paper wallet, but is vulnerable if the machine has (for example) a screen capture trojan.
506 2011-11-29 17:12:58 <casascius> Suppose I release an iPhone app that allows someone to type in a passphrase, and it computes G * sha256(passphrase) and e-mails it to the user.
507 2011-11-29 17:13:20 <casascius> (or I create a web service that does the same thing, but they send me their passphrase via SMS, so it is out-of-band with respect to the potentially compromised computer that will be doing the printing).
508 2011-11-29 17:13:39 <casascius> They go to Bitaddress.org and paste in an ASCII-armored G*sha256(passphrase).
509 2011-11-29 17:14:09 <casascius> They get a paper wallet, whose private keys can only be redeemed in conjunction with the passphrase.
510 2011-11-29 17:14:32 <casascius> The paper wallet might have a blank space where they are instructed to write the passphrase so their wallet will be complete.
511 2011-11-29 17:14:55 <casascius> Tada, 100% secure paper wallet for dummies.
512 2011-11-29 17:16:29 <casascius> http://www.merriam-webster.com/dictionary/receptacle - http://www.merriam-webster.com/dictionary/receptacle
513 2011-11-29 17:16:32 <casascius> oops
514 2011-11-29 17:16:55 <casascius> : one that receives and contains something : CONTAINER
515 2011-11-29 17:26:19 <imsaguy2> nice job with git
516 2011-11-29 18:14:02 <Eliel> casascius: something more to consider. rather than using a simple sha256 for transforming the users passphrase to the other part, consider using an algorithm that'll do that but take a minute or two to calculate.
517 2011-11-29 18:44:54 <klawd> hi!
518 2011-11-29 18:45:06 <klawd> im searching for noodles skute
519 2011-11-29 18:45:08 <klawd> anyone seen him?
520 2011-11-29 18:59:57 <sipa> who?
521 2011-11-29 19:07:12 <jgarzik> sipa: [Noodles]
522 2011-11-29 19:07:15 <jgarzik> iirc
523 2011-11-29 20:04:29 <hoijui> i tired compiling git(hub) master on latest ubuntu (11.10), and it seems to fail cause the version of libdb required to build (4.8) is not in repo anymore, and the ones in repo seems to be incompatible
524 2011-11-29 20:04:46 <lolcat> hoijui: Oh noes
525 2011-11-29 20:04:48 <hoijui> are there plans to move to a newer version, or support multiple versions of the lib?
526 2011-11-29 20:05:33 <hoijui> just asking cause.. it is usually good to be easily compilable on ubuntu, to get lots of testers and such
527 2011-11-29 20:06:58 <hoijui> sudo apt-get install libdb4.8++-dev
528 2011-11-29 20:07:01 <hoijui> E: Package 'libdb4.8++-dev' has no installation candidate
529 2011-11-29 20:07:37 <hoijui> current ubuntu version is: libdb5.1-dev
530 2011-11-29 20:08:01 <lolcat> ahh
531 2011-11-29 20:08:17 <lolcat> hoijui: download a deb and do dpkg -i --force-all blah.deb
532 2011-11-29 20:09:13 <hoijui> lolcat, ok
533 2011-11-29 20:09:17 <sipa> hoijui: just use 5.1
534 2011-11-29 20:09:19 <sipa> it will work
535 2011-11-29 20:09:26 <hoijui> sipa, does not so for me
536 2011-11-29 20:09:31 <sipa> what's the problem?
537 2011-11-29 20:09:41 <hoijui> first, there is no db_cxx.h header in 5.1
538 2011-11-29 20:09:41 <sipa> (i compile it on 11.10 myself)
539 2011-11-29 20:09:55 <hoijui> and if
540 2011-11-29 20:10:08 <sipa> you need libdb5.1++-dev
541 2011-11-29 20:10:21 <sipa> don't forget the ++
542 2011-11-29 20:11:25 <hoijui> ahh
543 2011-11-29 20:11:37 <hoijui> i only installed libdb-dev
544 2011-11-29 20:13:13 <hoijui> ahh.. there is also libdb++-dev.. ok :D sorry then!
545 2011-11-29 20:13:21 <sipa> np
546 2011-11-29 20:14:04 <hoijui> would it make sense to replace the libdb4.8++-dev with libdb++-dev
547 2011-11-29 20:14:09 <hoijui> in the install instructions?
548 2011-11-29 20:14:30 <hoijui> (for compiling)\n2258948
549 2011-11-29 20:14:39 <hoijui> ahh
550 2011-11-29 20:14:52 <sipa> if you compile bitcoin against 5.1, it will create files that will not work anymore on 4.8
551 2011-11-29 20:14:54 <hoijui> so for people with default versions older then that..
552 2011-11-29 20:15:01 <hoijui> ah ok
553 2011-11-29 20:18:52 <casascius> You know what this private key adding thing means?  I could go and probably make "bitcoin bills" for pennies
554 2011-11-29 20:19:03 <genjix> hey casascius
555 2011-11-29 20:19:13 <genjix> i got a coin. was very brilliant and shiny
556 2011-11-29 20:19:16 <casascius> I could go hire some company to produce high quality cheap bitcoin bills, like lottery tickets, and not care if they keep the private keys, because they'll need a "control number" on them which i will just overprint
557 2011-11-29 20:19:33 <genjix> it's darkened a lot now from either my handling it or oxidisation :)
558 2011-11-29 20:19:43 <casascius> genjix: cool!  i am glad they are getting around!
559 2011-11-29 20:19:43 <genjix> but it's super being able to hold a bitcoin
560 2011-11-29 20:19:57 <casascius> I believe that diluted brass polish will restore it...
561 2011-11-29 20:20:13 <genjix> yeah they were crowd drawers for people that had some
562 2011-11-29 20:20:17 <casascius> I have not tested it against the labels, but I have tested it against the coins, and it restores it within minutes
563 2011-11-29 20:20:22 <genjix> everyone (including me) wanted to touch one
564 2011-11-29 20:20:42 <genjix> molecula r gave me one as a present
565 2011-11-29 20:20:55 <casascius> I assume they would have sold well if someone were there selling them.... there just aren't that many cause they are hard to make.  but this whole thing about being able to add two private keys together...means i could probably completely outsource the production and have them made cheaply in bulk
566 2011-11-29 20:21:04 <genjix> i dont think i ever got a better present in many years
567 2011-11-29 20:21:12 <sipa> casascius: don't add them together - multiply
568 2011-11-29 20:21:15 <genjix> you should promote them that way :) as presents
569 2011-11-29 20:21:29 <casascius> sipa: gotcha...=)
570 2011-11-29 20:21:35 <sipa> otherwise if someone had two of your coins, they could subtract the keys and get your private key out of ot
571 2011-11-29 20:21:59 <sipa> wait that's not entirely correct
572 2011-11-29 20:22:02 <sipa> anyway, multiply!
573 2011-11-29 20:22:10 <casascius> when the time comes i will probably help with the math...though...i anticipate using unique keys for both halves
574 2011-11-29 20:22:18 <casascius> by "adding" I just mean conceptually, not mathematically
575 2011-11-29 20:22:19 <sipa> EC point division is computationally infeasible
576 2011-11-29 20:22:28 <casascius> how about "marrying"
577 2011-11-29 20:22:34 <casascius> that might make better sense
578 2011-11-29 20:22:58 <casascius> anyway I'm going to call a lotto printing company right now
579 2011-11-29 20:23:06 <sipa> wait, just a second
580 2011-11-29 20:23:10 <gmaxwell> sipa: it is adding. The private key is multipled with the generator, of course.
581 2011-11-29 20:23:11 <sipa> what exactly do you plan?
582 2011-11-29 20:23:39 <casascius> i plan on getting scratchoff tickets made by a manufacturer who puts a half paper wallet under the scratchoff
583 2011-11-29 20:23:41 <casascius> and i overprint the other half on the exterior of the ticket
584 2011-11-29 20:23:53 <casascius> i haven't figured out the math, but am interested in at least asking about pricing
585 2011-11-29 20:24:49 <gmaxwell> Pub3 = Pub1 (Sec1*g) + Pub2 (Sec2*g) ; Sec3 = Sec1+Sec2;
586 2011-11-29 20:27:00 <genjix> casascius: although i'd prefer the esperanto "forteco per nombroj" over the latin "vires in numeris"
587 2011-11-29 20:27:03 <genjix> :)
588 2011-11-29 20:27:59 <genjix> otherwise they're very well done.
589 2011-11-29 20:28:14 <casascius> thanks
590 2011-11-29 20:28:15 <genjix> i fidget/play around with it a lot
591 2011-11-29 20:28:17 <casascius> :)
592 2011-11-29 20:28:40 <genjix> someone played a trick though at the conference
593 2011-11-29 20:29:09 <genjix> they had redeemed the coin, and someone was saying how they would accept cascasius coins as payment (not worried about forged coins)
594 2011-11-29 20:29:20 <sipa> yeah
595 2011-11-29 20:29:23 <sipa> it was visible though
596 2011-11-29 20:29:26 <genjix> the guy asked if he'd take this coin (it looked legit at first glance)
597 2011-11-29 20:29:27 <sipa> but not very visible
598 2011-11-29 20:29:35 <genjix> yep sipa was there too
599 2011-11-29 20:30:49 <sipa> i didn't realize the pun in "vires in numeris" until some line ago here, though :$
600 2011-11-29 20:31:12 <genjix> what is the pun? i googled it and it means "strength in numbers"
601 2011-11-29 20:31:47 <sipa> yes, i knew the latin saying, but only interpreted it in the original meaning (where numbers stands for "many")
602 2011-11-29 20:31:59 <sipa> not as in maths
603 2011-11-29 20:32:09 <genjix> ahhhhhhh
604 2011-11-29 20:32:51 <sipa> it's genius :p
605 2011-11-29 20:33:33 <helo> i wonder if "numeris" can be interpreted as "numerous" or "numerals"
606 2011-11-29 20:33:54 <helo> as "numbers" can
607 2011-11-29 20:33:57 <genjix> "strength in mathematics"
608 2011-11-29 20:34:03 <genjix> i think that's the pun
609 2011-11-29 20:34:39 <genjix> hmm true. in esperanto they have nombroj (amount) and numeroj (numerals)
610 2011-11-29 20:38:57 <helo> i suppose "strength in amount" still works, as the amount of keyspace is the real strength
611 2011-11-29 20:39:58 <sipa> a keyspace of 2^80 would work as well
612 2011-11-29 20:40:18 <sipa> the strength comes from the use of cryptography in general
613 2011-11-29 20:41:18 <graingert> why does the installer exe extract a load of src files
614 2011-11-29 20:41:25 <graingert> cpp/h
615 2011-11-29 20:41:29 <graingert> (windows)
616 2011-11-29 20:42:10 <phantomcircuit> it's the full source iirc
617 2011-11-29 20:42:14 <phantomcircuit> or it was at some point
618 2011-11-29 20:42:36 <graingert> the wallet needed to be rewritten dialogue
619 2011-11-29 20:42:40 <graingert> makes a very bad sound
620 2011-11-29 20:42:45 <graingert> and uses the wrong icon
621 2011-11-29 20:42:50 <graingert> for something that isn't an issue
622 2011-11-29 20:43:02 <graingert> ie error dialogue, should have been info
623 2011-11-29 20:43:47 <graingert> yes it does seem to install the src
624 2011-11-29 21:15:23 <hoijui> i had to install package libminiupnpc-dev to get header miniupnpc/miniwget.h
625 2011-11-29 21:15:38 <hoijui> libminiupnpc-dev_1.5-2ubuntu2_i386.deb
626 2011-11-29 21:15:45 <hoijui> then it failed to compile with:
627 2011-11-29 21:16:00 <hoijui> http://pastebin.com/gRaFQyqM
628 2011-11-29 21:18:31 <rdponticelli> hoijui: You can install without upnp, if you don't need it...
629 2011-11-29 21:18:44 <rdponticelli> Just pass USE_UPNP=
630 2011-11-29 21:18:52 <hoijui> ok :-)
631 2011-11-29 21:20:07 <sipa> k
632 2011-11-29 21:20:20 <hoijui> i use that as argument to qmake?
633 2011-11-29 21:20:34 <hoijui> ... it still prints: Project MESSAGE: Building with UPNP support
634 2011-11-29 21:21:10 <hoijui> ahh
635 2011-11-29 21:21:28 <hoijui> make USE_UPNP=0
636 2011-11-29 21:21:34 <hoijui> .. nope, neither that
637 2011-11-29 21:21:53 <rdponticelli> No, the last one builds it, but make it not to use by default
638 2011-11-29 21:22:12 <hoijui> ah ok
639 2011-11-29 21:22:33 <rdponticelli> Try compile with the first one, I think there's a bug in the notification?
640 2011-11-29 21:22:41 <hoijui> qmake -set USE_UPNP 0
641 2011-11-29 21:22:45 <rdponticelli> Or try USE_UPNP=-
642 2011-11-29 21:23:02 <hoijui> hmm strange
643 2011-11-29 21:23:18 <sipa> try USE_UPNP=-