Bitcoin Forum
June 22, 2021, 08:29:16 PM *
News: Latest Bitcoin Core release: 0.21.1 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 »
1  Bitcoin / Development & Technical Discussion / Who is creating non-DER signatures? on: April 07, 2013, 03:22:15 PM
Hello everyone,

as some may know, Bitcoin uses DER-encoded signatures in its transactions. However, OpenSSL (which is used to verify them) accepts more than just the strict DER specification (it allows negative numbers, extra zero padding, extra bytes at the end, and perhaps more). As we don't like the de-facto specification of the Bitcoin block validity rules to depend on OpenSSL, we're trying to introduce a rule to make such non-standard signatures invalid. Obviously, that can't be done as long as any significant amount of clients on the network is creating these.

I've monitored all transactions the past weeks (1.4M transactions), and it seems 9641 of them contain at least one non-standard signature. Below is a list of the top 150 addresses that had coins used as inputs in such transactions, sorted by frequency. If you recognize any of these addresses, or have an idea of who owns them or what software they are using, please let me know. Thanks!

[BBE] [b.i] [google] 132qi1NCMqNB1bEU6HnmXmPQBsyV53Tv1q (592 x)
[BBE] [b.i] [google] 15DEU7jsJoQpgi6PTGjxJ32TQiApFtwfXP (559 x)
[BBE] [b.i] [google] 16moCd5oTg6XdvyM8rJkURtRpQrttZ4KFx (400 x)
[BBE] [b.i] [google] 1LG8ZFZZryWc8H3h8iktBNpXovni7P6Ve9 (335 x)
[BBE] [b.i] [google] 1DYcsSycrp5dAsHsodpv4cwwksfUNtg7MN (259 x)
[BBE] [b.i] [google] 1QJxz79cmdrqX9aAWV8vh4XXp9NRQpuhNE (240 x)
[BBE] [b.i] [google] 125iNj3y1figYKgFVoXaf88mCGoRxwXmRE (226 x)
[BBE] [b.i] [google] 1odh9G5QVtohMEycjTmmLg6aVTRNNtC26 (173 x)
[BBE] [b.i] [google] 1NqhoR6WPL1GthoiiMtXqEteqaK5XWkJRF (171 x)
[BBE] [b.i] [google] 1Ap2Yeont1eDmFbkNWEsHQbwHnJw7EjPBm (158 x)
[BBE] [b.i] [google] 1PrJNBJeGt44ZdoHZ8pRSzsMiVmuMXi9mX (156 x)
[BBE] [b.i] [google] 14YB3Tuwym4T9aJxT6eXTXRXWVLypwas77 (150 x)
[BBE] [b.i] [google] 1B4TVxR2ozssdbGorL2tBoBgcopAZZruBV (127 x)
[BBE] [b.i] [google] 1EWUna1WHDvRs3FDFJh9rCRSMT9MwjgJWT (126 x)
[BBE] [b.i] [google] 1EfBqGRp8GXEVZaCMHVQ5pXay41rHfnor4 (120 x)
[BBE] [b.i] [google] 1HKm9u2VcKP23AEUQRcPcjAyR4NSda97kC (111 x)
[BBE] [b.i] [google] 1PvtqFJb2twCJ67DSs8oFCDqtF7NngQ6Jw (82 x)
[BBE] [b.i] [google] 1CwusVDm8PxucEbBJ1moT7gdkkhmp1tcG8 (75 x)
[BBE] [b.i] [google] 1DvSJuFmDg2NZrt1uZ7asfTbhchvjP9Nbr (74 x)
[BBE] [b.i] [google] 1NuE71TnweKbhXtBPyo9GoJKYTio5hxB37 (72 x)
[BBE] [b.i] [google] 1BhF44x2EtJFvKHLGg8zSB3Dkd25A3q4Lp (70 x)
[BBE] [b.i] [google] 1GdFMzUiDdnu3DkQxdyrgDZVsCNrk3RQtE (63 x)
[BBE] [b.i] [google] 1PYVL91XyPzKPsL6bHjvYmd4bkkcUBm6qz (54 x)
[BBE] [b.i] [google] 1EMzCe8Q6KB7Sne64z3U34nVvmj5ueRg6a (54 x)
[BBE] [b.i] [google] 1BowP9AXuMTjiiR1u1AJjUwMNuRaZP9BSp (50 x)
[BBE] [b.i] [google] 1NAgDUBSotZKP4xSm8uaTkZ25Z5NNEprXK (44 x)
[BBE] [b.i] [google] 144JkmhfPDEyRfkLP21ie98Rx6pEs6eBAn (44 x)
[BBE] [b.i] [google] 1ALTa5wdGFmYPYYJkF1Sre9x2doGjCZ12b (41 x)
[BBE] [b.i] [google] 13XCZEMcfNayLddjT1fmgTu6mTu7mddGgr (41 x)
[BBE] [b.i] [google] 1EKtKALeoSjugVi2bVLsr3YvzLsqXyXsCs (38 x)
[BBE] [b.i] [google] 15tVpH12xqu9nMuxcayZNw2261iVUjywwH (38 x)
[BBE] [b.i] [google] 1LeVXmaxJ3RawczTY1MfvHN1h1qtZwRL8h (37 x)
[BBE] [b.i] [google] 184Y2GNzoZHpsEzpZcmoLxeda5gweyzHfs (36 x)
[BBE] [b.i] [google] 15uvrK8gGLxq6j85YM8nEyc3dNsdiMkYiH (36 x)
[BBE] [b.i] [google] 1Lxqx8e2e4Pq3jYjeD34rn9ExFmjPvhFNf (34 x)
[BBE] [b.i] [google] 1hDbFR7x1rwgCkMVsrBXzaYoBkGt89V8e (33 x)
[BBE] [b.i] [google] 15fkPeoZ8YfCSQD9tzveACNosKqd95fdPj (33 x)
[BBE] [b.i] [google] 13WQ45gQPeEnTwchuUc37HwrEaZWNtY1yA (33 x)
[BBE] [b.i] [google] 188BDtTAFJAn9WGn8h56mVpvth31RMYaXC (31 x)
[BBE] [b.i] [google] 14GnN2kGzij91Yd4KgCzdX8x5CAccHHe9x (31 x)
[BBE] [b.i] [google] 12M3URJVCKyxfU7THQ1KFVoeXPZoW5xkf5 (31 x)
[BBE] [b.i] [google] 14t7H7fsWkWo8qHgB7WjNgmny83KbVMp9z (30 x)
[BBE] [b.i] [google] 1NnghQNWY9MSgHNX56Z3VaL631fx3TK72K (29 x)
[BBE] [b.i] [google] 1HFWQz8mB6wf9GgrM3KuJaDVwbNxB3Gd7W (29 x)
[BBE] [b.i] [google] 14JzmMaSzxc9AGTsKCMV37M4zBJAg4yfRn (29 x)
[BBE] [b.i] [google] 1CZPvje299xsSHD9M3J2Cp3hV2h8tfYJLy (28 x)
[BBE] [b.i] [google] 1BQNHKi7YagT2Vozo1jsgnL1LgfAPfQ2MT (28 x)
[BBE] [b.i] [google] 1BGgRjZMqLn7XS1K8qiDxvTN71Up6wr7XA (27 x)
[BBE] [b.i] [google] 1Anq319DuqfFbEKtmfuANAR7mRqu7Scsvy (27 x)
[BBE] [b.i] [google] 1JkPjbHa3LPRfQEG9bGaVZwdn8jDarUVXF (25 x)
[BBE] [b.i] [google] 14XWpAuJ1xqWwyU9GxPUkChdFr7esYPGhN (23 x)
[BBE] [b.i] [google] 1RoLLsgNXws1fNfkXrUPAbhVmir5xkhFX (22 x)
[BBE] [b.i] [google] 1LXDi88VbsGFW69bqZ6dhdXQTH1ZQBgRYq (22 x)
[BBE] [b.i] [google] 12J1TqYw9FCXzWpC1zoMRTPGvquPJLAL4u (21 x)
[BBE] [b.i] [google] 1DSnduiZb91sKf5jTxkTQFyBYXmjDraSFX (20 x)
[BBE] [b.i] [google] 1BxfcSYLpSgu3ANaG49H7nNW1xvMqqvGPg (20 x)
[BBE] [b.i] [google] 1DMg1rA4U2NybNaUfoeE8AtvrXFu5pTV8T (19 x)
[BBE] [b.i] [google] 1DaZbGFmUskfBmAV3XHhcAxkpjs32UGBfh (19 x)
[BBE] [b.i] [google] 133a1seCmdyKBc5GjmjWdyyCr4A3Lth6Zj (19 x)
[BBE] [b.i] [google] 1JHztH2WGJxBGb6Xzv7Vmq9iPkgt942nJy (18 x)
[BBE] [b.i] [google] 19Bd7ci22v9bG4iWYvgpeSTxKeXBtXWjj4 (18 x)
[BBE] [b.i] [google] 16UBzqXVnXEQGA6Za4t4mTavRzazkCGeWi (18 x)
[BBE] [b.i] [google] 1ANqD4w4rHEWyf93sRQyc259QSVriab8d1 (17 x)
[BBE] [b.i] [google] 16uBqiGur9nohgMPyS6QzPA7EzF5gstA8q (17 x)
[BBE] [b.i] [google] 16rrFWnx81UkhqFktcyniVEZEHL6k51iub (17 x)
[BBE] [b.i] [google] 12DK76obundhnnbGKcaKEn3BcMNNH5SVU4 (16 x)
[BBE] [b.i] [google] 1PPddaBVYHLUNBbU8vhhqKr5nUvBspL7v1 (15 x)
[BBE] [b.i] [google] 1LgvQSLsyQUgDkpu9nM66qinuysSTg5iSQ (15 x)
[BBE] [b.i] [google] 1KJHFTRuQncgaNoEyXjGUi19QaKMB5VfN2 (15 x)
[BBE] [b.i] [google] 1FWq39AU9cx2kbqHgNhiWC6T863NgUGp2e (15 x)
[BBE] [b.i] [google] 1RNSdQGbrLP51wcrc84mne8zYC5GkwJ1C (14 x)
[BBE] [b.i] [google] 1NKd66PKvRGWqH2TQjcEiAzHfdKfhumqnJ (14 x)
[BBE] [b.i] [google] 1Kt9FAg8HAXrs8VWafsPjhL9dvq9NMDck4 (14 x)
[BBE] [b.i] [google] 1K7xZrzS41f9RNgRNnjttCKPNCAJk9BU5s (14 x)
[BBE] [b.i] [google] 1BuMcah7BVLGdDKRH63TyVabscKeULiEpu (14 x)
[BBE] [b.i] [google] 17uY6a7zUidQrJVvpnFchD1MX1untuAufd (14 x)
[BBE] [b.i] [google] 15iGs1jiTaW5oRVPJ9Jdt4exjVvWTKB9Dr (14 x)
[BBE] [b.i] [google] 1Lpp4qpinaxY9oznMskLAEGtBtdhPaS1eg (13 x)
[BBE] [b.i] [google] 1Hm55fL8wdwGqcZX9aZFe9ysM3gSAkE11x (13 x)
[BBE] [b.i] [google] 1EfZoGfbREGun4d5US7ARyyjZZPL11Egg8 (13 x)
[BBE] [b.i] [google] 1CxKmPeX2SuxXYosrvZr2jBvakjmxq1UJc (13 x)
[BBE] [b.i] [google] 1AshPGUbzMxbiGin3SvnfYk4CAnyQHzpHP (13 x)
[BBE] [b.i] [google] 1PowAnGLQLvNNnJ9Tuk7FNqYQpQUZqa6f3 (12 x)
[BBE] [b.i] [google] 1MZMEshX3Sp5AjGHR7dGp3nk8qkUfMgHQJ (12 x)
[BBE] [b.i] [google] 1MNH6WrJgSMxZwsMDhG92uxV6w7uawRVHQ (12 x)
[BBE] [b.i] [google] 1ManuSfoTfDVLrGkohsLbcShBD9Ahf8rPa (12 x)
[BBE] [b.i] [google] 1M2B4zktTxXZ1pqi4JkGkuRyLpMAEcXH37 (12 x)
[BBE] [b.i] [google] 1GzrQDm1tRx2P8DFe1f9pMUDiPfZyXvMmi (12 x)
[BBE] [b.i] [google] 1GAd65EGU2AKknrbmmkdgwL3FgVgwr7za9 (12 x)
[BBE] [b.i] [google] 1EfANwXf8oPHhy7Euc8DVzPKpXaZN7xfL1 (12 x)
[BBE] [b.i] [google] 16mKG9PNDFxRqWJXNi5tMBqVqzpdcqMk5 (12 x)
[BBE] [b.i] [google] 13NXx75d3YyiU83vb5P6kPaVpGKCdRAkur (12 x)
[BBE] [b.i] [google] 1Q7ZzqVtQKQ8vUvHfoNBRCoKeQD3df96a6 (11 x)
[BBE] [b.i] [google] 1LUDcDX8ixUVHEiZkw9rjk5JxdLisqqgku (11 x)
[BBE] [b.i] [google] 1KCcg3XCnZovNJzBnptjWvjwqz71dHYV1L (11 x)
[BBE] [b.i] [google] 1GWLpgvvgFWz2LN4VfidwEjpueM5mojjG6 (11 x)
[BBE] [b.i] [google] 1EPHjWZbZRUCBgzvkYGiWpLWNpK2ce31Vi (11 x)
[BBE] [b.i] [google] 1ChWbjxDi8NuGA9Pb9HLoy3hN38zJj1MvX (11 x)
[BBE] [b.i] [google] 1Bn1BaLibWMndHNZLxph77cz8uj9UvxGP6 (11 x)
[BBE] [b.i] [google] 1AQb7RsfMsXpdErHUKvuFEDFiDS43pNzPA (11 x)
[BBE] [b.i] [google] 17Ux4V8RVedGEDWCA5ZuUWX1CNqHphBiJj (11 x)
[BBE] [b.i] [google] 16u8NazpHqTF3WQXSeKry1jKDptxL8GvAo (11 x)
[BBE] [b.i] [google] 1PNX8xkC1BjtYXZudqYQSpWegtdT4Ks5Q3 (10 x)
[BBE] [b.i] [google] 1Pb6y7z25p81tzhaKbvqSykijB9y6yBEWq (10 x)
[BBE] [b.i] [google] 1P9xNaECSD8oR7mn18tB4DiSQ3Zf52vuVx (10 x)
[BBE] [b.i] [google] 1KMECq7FKVVHaMcmBWQFjkQBuUPE7RCTNp (10 x)
[BBE] [b.i] [google] 1JYZXAksakJuqoPgaF2REcVFUYLBLzTQrB (10 x)
[BBE] [b.i] [google] 1JChXiLbRtiFUsDsiw5Lbr1Qev4849wPiJ (10 x)
[BBE] [b.i] [google] 1J13NBTKiV8xrAo2dwaD4LhWs3zPobhh5S (10 x)
[BBE] [b.i] [google] 1GCTtQcHnS7BC93eNu3JaFhDgXvt3gfKXb (10 x)
[BBE] [b.i] [google] 1DFUPy1ggSMXmLuobyCiAAkes4QbD5LtJK (10 x)
[BBE] [b.i] [google] 1CXgSECGyHVwcwgcVoxti8nBHzBUphfQLc (10 x)
[BBE] [b.i] [google] 18eDmL4ov4YfZ6F2Wb5VFPyremFP8KuJYE (10 x)
[BBE] [b.i] [google] 1332BaqrqaMvjZGFNGVCviNbesMNxaYvDk (10 x)
[BBE] [b.i] [google] 1Q2mdgsgcRovAjsBFg8AHXypWzdjnKX2nf (9 x)
[BBE] [b.i] [google] 1LF9D48Sk48KNb9e5i4ZreftmHfCLY5NUS (9 x)
[BBE] [b.i] [google] 1L3Xq4A2v4Kg2QLAKzva3gKJYshHjKiqUS (9 x)
[BBE] [b.i] [google] 1KB16Cbs4VzDqawBcvLueXSim2tyFJp5dB (9 x)
[BBE] [b.i] [google] 1G6uaqz7aa3s969VRgevN8woeXEvepnDDi (9 x)
[BBE] [b.i] [google] 1Eqrpv6R5GFc92zoDDoMcRRSzqdGLPBc8H (9 x)
[BBE] [b.i] [google] 1D5imyAhoGzhzuhFauMp2aFRFQgZ5SmQV8 (9 x)
[BBE] [b.i] [google] 1BWhjzqob34B2gV3D8tgP6yV44oSsmXx17 (9 x)
[BBE] [b.i] [google] 1Bjaewgk3bXujiJUqLcrkk7aKSS1f9kUV3 (9 x)
[BBE] [b.i] [google] 18TG9ubxK3MU6DrCFgKiv3XTAE6SH3aDXA (9 x)
[BBE] [b.i] [google] 18qmrut47YftRkFDin2ZwctpDBjUaNiYtd (9 x)
[BBE] [b.i] [google] 17KBKMyTBkh9Qeza2AftMFRQss5a7J16Mj (9 x)
[BBE] [b.i] [google] 15kv5pJSiQUiPAa9L5Uxsc9ErMPJ8sRSau (9 x)
[BBE] [b.i] [google] 13CsjoQAACEwYwp5yGcsrbMmfbbYdwUXDb (9 x)
[BBE] [b.i] [google] 1PYHMBrQHLAtEPnDsT5Y1yvPA1wkpDqMZe (8 x)
[BBE] [b.i] [google] 1PEUFG7RFK3EJuDxSP2XMCv4n4f1AnWPLb (8 x)
[BBE] [b.i] [google] 1NzzG4TUHA3VgKXCy1i2ffVoCZBGUQHV4G (8 x)
[BBE] [b.i] [google] 1NFkjUVenDU4U1TVr5jm7YxwZ5ocjeizmU (8 x)
[BBE] [b.i] [google] 1n3PbYoZ7SKC4aLiRPKzjEYaNWCn4SHTP (8 x)
[BBE] [b.i] [google] 1LRsMQVVJmwgYYqtM7hL8uQqjepz27yFrj (8 x)
[BBE] [b.i] [google] 1L3ayzv8P4dRZLQ3vLcCVW3GEJauM5vKo8 (8 x)
[BBE] [b.i] [google] 1Kx4JK93A74rr3QuE3Yt3z9wruKKeUrJFw (8 x)
[BBE] [b.i] [google] 1KmNyVqQdimRR7eoRT6DRfCkiM4UW6tPJA (8 x)
[BBE] [b.i] [google] 1HaBCqaEQNcPcySFf4MkCTuc9Gh2ptHJ6F (8 x)
[BBE] [b.i] [google] 1DVGSxiMHNZsQDKQA5yAPHCPBtxaAtKG6E (8 x)
[BBE] [b.i] [google] 1Di97qTpRbnYrNonRnA82oaWdSdMTJW8JF (8 x)
[BBE] [b.i] [google] 1DEsxZ9fWCVAjkZgn4EoBc2YytSieMppCH (8 x)
[BBE] [b.i] [google] 1C41uDfQsBnt6FXeXo6tkVes3Cu7LFpcKC (8 x)
[BBE] [b.i] [google] 1B7FTiH3tzNgKqpnHNyrvmP53Zjvv3dszD (8 x)
[BBE] [b.i] [google] 19sgHtnHsT7ho67SKqLvgY9xm3BZEoahzR (8 x)
[BBE] [b.i] [google] 12a3Re3LN9JY1sSrhiGSQq5i2jNJtx4t8n (8 x)
[BBE] [b.i] [google] 1Q5RfT8a5YHnqaZPqA7K2x1J1mvbfJKwFs (7 x)
[BBE] [b.i] [google] 1NWDJpjqj6KEgKWZVGAwdFj4bCSihc1RjL (7 x)
[BBE] [b.i] [google] 1MPHRJvv6jhjp32GLo7jUW32qK7Wy7Fe29 (7 x)
[BBE] [b.i] [google] 1MMc227TR2ropsB7CaHaYGqPZNNdfs1yH (7 x)
[BBE] [b.i] [google] 1MaysWLxwd96onmLwsb1jYyKQY4oYjaTZU (7 x)
2  Bitcoin / Bitcoin Discussion / Alert: chain fork caused by pre-0.8 clients dealing badly with large blocks on: March 12, 2013, 01:29:57 AM
Hello everyone,

there is an emergency right now: the block chain has split between 0.7+earlier and 0.8 nodes. I'll explain the reasons in a minute, but this is what you need to know now:
  • After a discussion on #bitcoin-dev, it seems trying to get everyone on the old chain again is the least risky solution.
  • If you're a miner, please do not mine on 0.8 code. Stop, or switch back to 0.7. BTCGuild is switching to 0.7, so the old chain will get a majority hash rate soon.
  • If you're a merchant: please stop processing transactions until the chains converge.
  • If you're on 0.7 or older, the client will likely tell you that you need to upgrade. Do not follow this advise - the warning should go away as soon as the old chain catches up.
  • If you are not a merchant or a miner, don't worry.

Quote from: etotheipi on March 12, 2013, 02:40:59 AM
The original post lacked info for "regular users".  Here it is:

(1) If you are a "regular user" (not a miner), the best thing is to do nothing and wait a couple hours.
(2) If you are a "regular user", upgrading, downgrading, whining, FUD, etc, will make no difference.  Only miners have an incentive to do anything.  Otherwise, it doesn't matter which version you are running.
(3) Regardless of who you are, your transactions are not dead, your coins are not lost.  They will just temporarily be held up.  If you sent a transaction within the last few hours, it may take a few more hours before it's sorted out.
(4) If you insist on processing transactions right now it's probably best to wait 30+ confirmations.  It's just due diligence though ... an attacker would still need a tremendous amount of mining power, quick thinking, and a victim willing to part with a lot of BTC.
(5) By tomorrow this will be in the past and everything will appear to be normal again.  If you slept through this, you'd never know that anything happend (except for the price drop).

Let me reiterate, your coins are not at risk, your transactions are not lost.  It'll just take some time for the network to "iron itself out."  Everything will be okay.
3  Bitcoin / Bitcoin Discussion / Help me look for sites/software that produces non-standard signatures on: December 26, 2012, 07:19:59 PM
Hello everyone,

since it was discovered that Bitcoin accepts transactions whose signatures are not formatted entirely according to the DER standard, we've been wanting to fix this, by making the rules somewhat more strict (this would make it easier for new implementations for example, as they now have to mimic exactly what OpenSSL does, in case they use a different crypto library).

This is however hard to just change, as there is apparently still software out there that (probably unknowingly) violates the strict specification "as it worked anyway". Some time ago we already identified some "offenders", and the frequency of non-DER signatures dropped significantly since then. In the past few days, only 0.2%-0.5%. Still, I'd like to see this drop closer to zero before releasing software that doesn't relay it anymore. (Note: in time, this may become a network rule, but in this first stage the question is just whether to relay them or not - blocks with such transactions remain valid).

Here is a full list of all offending transactions the past 4 days. If can help identify their source, perhaps we can make the percentage drop further.

EDIT: here is a page with addresses from which non-standard transactions have originated.

Transactions with (at least) a signature with an "excessively padded R value":
Transactions with (at least) an "excessively padded S value":
Transaction with (at least) a "negative R value":
Transactions with (at least) a "negative S value":
Thanks!
4  Bitcoin / Development & Technical Discussion / Experimental pre-0.8 builds for testing on: December 09, 2012, 12:18:32 AM
Hello all,

I've uploaded a new set of builds of bitcoind/Bitcoin-Qt to my builds page. The new "turbo" build is based on current master on git, plus some more experimental patches (Hal Finney's optimized secp256k1 code, and parallel script verification). The source code for these can be found here (.tgz archive here).

Disclaimer: don't use these for any serious stuff - I am not responsible for destroyed wallets or exploded CPU's.

Testing of these is very welcome.

As the most invasive change is in the block/transaction validation system, this is the most interesting part to test. I am very interested in reports about speed, CPU usage, memory usage, ... during initial block synchronization, in particular on Windows systems. Obviously, crashes or other unexpected behaviour is even more important.

As these builds use the new 0.8 database code ("ultraprune", as I called it before), they will not use the existing block files/database from 0.7.2 or earlier. There are several ways to import the data:
  • Put bootstrap.dat in your data directory.
  • Start the program with options -loadblock=path/to/old/blk0001.dat -loadblock=path/to/old/blk0002.dat.
  • If you already have a full 0.8 database (perhaps from a next-test build), you can use the new -reindex option to rebuild your index from scratch, redoing the block validation process, reusing the block data you already have on disk.
  • Obviously, you can also just let it synchronize from network, but as the current block-fetch logic is somewhat of a hack, you may get unlucky, and hit a slow peer, or have downloads that stop for long periods of time. It is advised to use -connect=IP to connect to a single fast peer (you can use my server, 178.18.90.41, for this purpose if needed) for that.

As these builds use parallel script verification (only enabled after block 193000, the last checkpoint), you may wish to control how many threads are used (don't use more than the number of CPU cores you have). By default, it will try to autodetect, but you can use the -par=N option to select the number of threads. One interesting thing you can test is comparing -par=1 with higher numbers, and check the speedup (in particular of the blocks after 193000).

Other options which may be useful to play with:
  • -dbcache=N tweaks the amount of cache used. N is a number in megabytes (default is 25), but higher numbers may result in significant speedups.
  • -logtimestamps adds timestamps to the output in the debug.log file, which may be very useful to compare speed.
  • -benchmark produces detailed timing information during block validation (not very accurate on Windows, unfortunately).
5  Bitcoin / Development & Technical Discussion / Ultraprune merged in mainline on: October 20, 2012, 10:37:51 PM
(copy of mailinglist post)

I've just merged my "ultraprune" branch into mainline (including Mike's LevelDB work). This is a very significant change, and all testing is certainly welcome. As a result of this, many pull requests probably don't apply cleanly anymore. If you need help rebasing them on the new structure, ask me.

The idea behind ultraprune is to use an ultra-pruned copy (only unspent transaction outputs in a custom compact format) of the block chain for validation (as opposed to a transaction index into the block chain). It still keeps all blocks around for serving them to other nodes, for rescanning, and for reorganisations. As such, it is still a full node. So, despite the name, it does not implement any actual pruning yet, though pruning would be trivial to implement now. This would have profound effects on the network though, so may still need some discussion first.

A small summary of the changes:
  • Instead of blk000?.dat, we have blocks/blk000??.dat files of max 128 MiB, pre-allocated per 16 MiB
  • Instead of a Berklely DB blkindex.dat, we have a LevelDB directory blktree/. This only contains a block index, no transaction index.
  • A new LevelDB directory coins/, which contains data about the current unspent transaction output set.
  • New files blocks/rev000??.dat contain undo data for blocks (necessary for reorganisation).
  • More information is kept about blocks and block files, to facilitate pruning in the future, and to prepare for a headers-first mode.
  • Two new RPC calls are added: gettxout and gettxoutsetinfo.

The most noticeable change should be performance: LevelDB deals much better with slow I/O than BDB does, and the working set size for validation is an order of magnitude smaller. In the longer run, I think it is an evolution towards separation between validation nodes
and archive nodes, which is needed in my opinion.
6  Bitcoin / Development & Technical Discussion / Non-canonical signatures: looking for detectives on: September 07, 2012, 09:02:51 PM
Hello everyone,

as some of you may know, Bitcoin uses DER-encoded signatures. However, at least the reference client supports any signature encoded in the less strictly defined BER encoding (and even allows some deviations from that). There are several inconveniences associated with allowing multiple encodings, and even some very weak attacks (there's no risk of losing money, in any case). To prevent this, we'd like to at first make non-canonical signatures non-standard, and maybe at a (much) later time, propose a BIP to make them invalid entirely.

There are still some sites/software which produces non-canonical signatures, so we can't make them non-standard yet. My question for you is finding who creates them.

Here is a list of transaction id's my node saw recently, which use a particular type of DER violation (excessive padding):


2229be0a6b3342d5dc3443be9b8b5306e6531f177434b5111247c0155995ba58
284c7971387d1a049aee8bd693fe2dfbad69521c0e43224bd5263529f0002744
35c0819290fd7bdfd48e7a20ea8260a0805993d714a7d7e21892d93e6e7c2f7b
5b74b9b294769be261a9caa1310bb648dd6dd530ac75cee9b7c6bfb6d160d07d
6009f0ef333e81c15a3818fc18b728e7b37881e665ae2b2e6d71b2337219f3da
63c310454e0a23d2543548a4cf7500557a2c632a84fbeb20bee47a3b16bd37b9
72dd12b8451298f316a8b687766e399f397e81e4c1c318f87548725bc95aadf5
82f37114f752865b1520eae888913b02f68aea740d830d1afe9487efd6bfa6d0
83abc9588b7a5c6084398f92c88c485e025773c567745b125c977aa1a502bc88
8a1fae8c8dbb96d1f6b879830f4df948b11ea10806564a60e0197c28f7718d52
95b5b109b744c04369e4d122bb86f3cce951088ab641fe7c6dc35c91a66ffc5b
ae216d17d68fef69b53fbc283f60efd342509f36b51c8740bdf149c319a516b1
c0f852f402f1a9989cc4c8b4921461ec850d8c4b8a9c5733a6273429523f066a
cfd4fce2d88967fdbe089b455169b683503576f69faaa1e9da636ccd62196b05


Anyone knows who/what created these?
7  Bitcoin / Development & Technical Discussion / Self-descriptive strengthened keying: a standard for deriving keys from seeds on: August 21, 2012, 10:39:20 PM
(this is a proposal based on a discussion with gmaxwell and etotheipi, and inspired by a proposed extension to the Casascius mini private key format)

1. Abstract

There is currently a lot of talk about deriving keys or wallets from a relatively short seed in a deterministic way ("brainwallets"). As your wallet's keys are exposed to the whole world, it is essential to make sure it is hard to mount a brute-force attack against potentially easy-to-guess seeds (in particular when the seeds are user-chosen passwords). This is a proposal for a standard for doing this derivation, which has some nice properties.

2. Introduction

Typically, key strengthening is used to increase the time necessary for trying a single seed. This does however require either fixing the number of iterations (which should increase over time as hardware gets faster), or forcing the user to remember the number of iterations. It also lacks a way to verify a seed was correct, as every seed results in a valid key.

An alternative is using a checksumming system. For example, requiring that SHA256("BLAH" + seed) starts with a given number of zero bits, and using SHA256(seed) as key. With N required zero bits, this also slows down testing of seeds by 2N per valid seed. It does provide a way to verify a seed was correct, is very fast to do the actual derivation, but also introduces some variation in the seed generation.

Neither solution however addresses the fact that it requires the derivation count or checksum strength to be known in advance (either as part of the specification, or by making the user remember). However, by combining both strengthening and checksumming, we can have seeds that encode their own strength, without compromising security.

3. Proposed algorithm

This is the proposed derivation algorithm:
  • Calculate H(H(H(...(seed)...))), with 257 iterations, and H = HMAC-SHA512.
  • If the 257th iteration results in a hash that starts with 8 zero bits, the 256th iteration hash is the output (the key).
  • If not, keep doing iterations
  • If the 513th iteration results in a hash that starts with 9 zero bits, the 512th iteration hash is the output.
  • If the 1025th iterations results in a hash that starts with 10 zero bits, the 1024th iteration hash is the output.
  • ...

This results in a variable-strength keying that requires 216, 218, 220, ... iterations of H per valid seed (both for a legitimate user creating a new seed, and an attacker trying to attack them). However, an attacker who does not know which strength the user chose, cannot give up quickly after a limited number of iterations. In what follows, we will however assume an attacker does now, so the security of this scheme does not depend on that property.

What this does essentially, is split the generation difficulty equally over making it take 2N steps to generate a key, and at the same time, making only 1 in 2N seed valid. This has some nice properties:
  • Generating a key of a given strength S, requires 216+2*S iterations on average
  • An attacker that has an oracle which can iterate all valid seeds of a given strength in constant time, still needs as many elements as there are in the original seed space to test all valid keys.

Note that HMAC-SHA512 does take a salt as input. This salt can be an application-defined default (such as the fixed string "Bitcoin key derivation"), but the application can also prompt the user for some extra random but non-secret bits (such as an email address, a birthdate, ...). There have been threads above such a salt alone, if I recall correctly.

4. Improvements

The potential difficulties (number of iterations necessary to a generate a valid seed) offered by the scheme described above are relatively far apart: a factor 4. We can however tweak the algorithm a bit.

Instead of checking for a particular number of zero bits at the start of a hash, we can interpret the hash as a number, and compare it directly to some predefined constant. This is similar to how the proof-of-work check happens in Bitcoin itself. Assume we want the difficulties to start at 216 still, but have them be a factor 2 instead of a factor 4 apart, we can use this algorithm:
  • Calculate H(H(H(...(seed)...))), with 257 iterations, and H = HMAC-SHA512.
  • If the 257th iteration results in a hash whose first 32 bits are below 0x101000, the 256th iteration hash is the output (the key).
  • If not, keep doing iterations
  • If the 363th iteration results in a hash whose first 32 bits are below 0xB60183, the 362th iteration hash is the output.
  • If the 513th iteration results in a hash whose first 32 bits are below 0x80C1A2, the 512th iteration hash is the output.
  • If the 726th iteration results in a hash whose first 32 bits are below 0x5B2143, the 725th iteration hash is the output.
  • ...
(more constants and mathematical model to obtain them can be found here; the numbers are found by a numerical approximation).

This results in difficulties very close to 216, 217, 218, ...

Another potential improvement is using a different H function, such as something based on scrypt.

5. Implementation

An example implementation in Javascript can be found here. It does use a modified set of constants, which result in difficulties around 210, 211, 212, ... instead, as difficulties around 216 are already unusably slow (though possible) in Javascript.
8  Bitcoin / Bitcoin Discussion / Icelandic Bitcoiners? on: July 25, 2012, 09:40:09 AM
Hello all,

I spent the past 12 days travelling through Iceland (executive summary: waw!). The next 4 days I'm staying in Reykjavik, so if there are any people around that would like a meetup, let me know something!
9  Bitcoin / Development & Technical Discussion / Pruning in the reference client: ultraprune mode on: July 06, 2012, 04:58:50 PM
(cross-post from the mailing list)

Hello all,

I've implemented a new block/transaction validation system for the reference client, called "ultraprune".

Traditionally, pruning for bitcoin is considered to be the ability to delete full transactions from storage once all their outputs are spent, and they are buried deeply enough in the chain. That is not what this is about.

Given that almost all operations performed on the blockchain do not require full previous transactions, but only their unspent outputs, it seemed wasteful to use the fully indexed blockchain for everything. Instead, we keep a database with only the unspent transaction outputs. After some effort to write custom compact serializations for these, I could reduce the storage required for such a dataset to less than 70 MB. This is kept in a BDB database file (coins.dat), and with indexing and overhead, and takes around 130 MB.

Now, this is not enough. You cannot have a full node wit just these outputs. In particular, it cannot undo block connections, cannot rescan for wallet transactions, and cannot serve the chain to other nodes. These are, however, quite infrequent operations. To compensate, we keep non-indexed but entire blocks (just each block in a separate file, for now), plus "undo" information for connected blocks around in addition to coins.dat. We also need a block index with metadata about all stored blocks, which takes around 40 MB for now (though that could easily be reduced too). Note that this means we lose the ability to find an actual transaction in the chain from a txid, but this is not necessary for normal operation. Such an index could be re-added later, if necessary.

Once you have this, the step to pruning is easily made: just delete block files and undo information for old blocks. This isn't implemented for now, but there shouldn't be a problem. It simply means you cannot rescan/reorg/server those old blocks, but once those are deep enough (say a few thousand blocks), we can tolerate that.

So, in summary, it allows one to run a full node (now) with:
  • 130 MB coins.dat
  • 40 MB chain.dat
  • the size of the retained blocks, +12% of that for undo information.

Oh, it's also faster. I benchmarked a full import of the blockchain (187800 blocks) on my laptop (2.2GHz i7, 8 GiB RAM, 640 GB spinning harddisk) in 22 minutes. That was from a local disk, and not from network (which has extra overhead, and is limited by bandwidth constraints). That is with some tweaking though.

If people want to experiment with it, see my "ultraprune" branch on github:  https://github.com/sipa/bitcoin/tree/ultraprune.

Note that this is experimental, and has some disadvantages:
  • you cannot find a (full) transaction from just its txid.
  • if you have transactions that depend on unconfirmed transactions, those will not get rebroadcasted
  • only block download and reorganization are somewhat tested; use at your own risk
  • less consistency checks are possible on the database, and even fewer are implemented

Also note that this is not directly related to the recent pruning proposals that use an alt chain with an index of unspent coins (and addresses), merged mined with the main chain. This could be a step towards such a system, however.
10  Bitcoin / Development & Technical Discussion / New command line options in 0.6.0 on: March 31, 2012, 11:39:30 AM
Hello all,

since some new options to bitcoind are considered more for debugging and tinkering than for end users, they did not make it into the release notes. Therefore, here is a more complete such list:
  • -upgradewallet: new wallets in 0.6.0 are created in the latest format, but old wallets are left untouched in order for them to remain compatible with external tools. -upgradewallet forces the wallet to upgrade to the latest format
  • -upgradewallet=<n>: allow (but do not force) an automatic upgrade to a wallet that is still compatible with client version n (for example -upgradewallet=50000 will make sure the wallet remains compatible with 0.5.0). One exception is when the user takes an explicit action that implies a wallet upgrade (encrypting it, for example), and the condition specified by -upgradewallet=N is not satisfiable. In that case, the wallet will still be upgraded to the latest format anyway.  You can also use this option to create a new wallet that is compatible with older versions.
  • -checkblocks=<n>: In addition to -checkblocks (which verifies the entire chain), or no argument at all (which verifies the last 2500 blocks), you can now specify how many blocks the to check. For example, -checkblocks=10 will only verify the last 10 blocks. The minimum is 1, specifying 0 will cause a check of the entire chain
  • -checklevel=<n>: specify how thorough the inital block validation algorithm is. The default is 1, and corresponds to the level of checking older versions did. In 0.6.0, any number between 0 and 6 is accepted, each significantly slower than the previous one. Checking the entire chain at level 6 will take at least 5 minutes if the blockchain is already loaded into the OS cache entirely.
  • -dbcache=<n>: Specify how many megabytes of memory to use for internal caching. The default in 0.6.0 is 25, and higher numbers will not gain you much more speed probably. Higher numbers mean slower startup and shutdown, though.
11  Bitcoin / Bitcoin Discussion / Security update: duplicate transaction vulnerability fix on: March 07, 2012, 03:53:52 PM
UPDATE: 0.5.3 was released with BIP30 support

Hello all,

as some of you already know, a vulnerability was found in the way bitcoin currently handles duplicate transactions. Even though we were able to demonstrate a potential attack on testnet, there is no cause for alarm because such an attack requires significant hashing power, is rather complex, and even if carried out does not allow financial gain for an attacker. Still, it is a vulnerability that can cause problems and we want to fix it as soon as possible.

But before we roll out the fix we wanted to inform you, the community, exactly what the problem is and how we are going to fix it. Essentially we want everyone to be on the same page to make the fix roll-out as smooth and uneventful as possible.

For most problems, this is not required, as we can just release an updated client. However, the nature of the problem dictates a fix that will introduce a new stricter block-validity rule. This means we have to actually change the rules by which blocks are considered to be valid or invalid. This in and of itself poses a risk, because an attacker violating this new rule while only a minority has upgraded their clients could cause a block chain fork. This is a bad thing because it would allow any transaction output that existed before the fork to be spent twice: once in each branch of the fork. However, if a majority enforces the stricter rules, we are sure that any fork will be resolved quickly and not be permanent. This is why we need your support.

The fix, described in BIP 30, is noncontroversial. There was a long discussion on the mailing list, and several developers have expressed their support. A majority of mining pools (in terms of hashing power) have also confirmed they will be updating their nodes. BIP 30 is backward-compatible: only what was previously considered a valid block can become invalid and not the other way around. This means that old software will continue to accept blocks "mined" by clients following the new rule, and keep building upon them.

A bit more technical, the actual bug is this: the bitcoin software was written with the assumption that it is impossible to create a transaction with a hash that is identical to that of a previous transaction. This is however not entirely true. It requires buggy software, or malicious intent, but one can create a coinbase transaction that is identical to a previous coinbase, implying it has the same hash. Furthermore, by recreating transactions that use these duplicated coinbase(s), those can be duplicated as well. Now here is how the bitcoin software currently deals with this: it does not check whether that previous hash already exists but simply overwrites it in its transaction index database. Even worse, when a block that contained such a duplicate is reverted (during a reorganisation), the index entry is deleted entirely. If the original transaction was not yet spent, it has now become unspendable.

The way to fix this is simple: simply disallow blocks to contain such duplicated transactions. In order not to make pruning impossible in the future, one exception is added: if the original transaction was already completely spent before a block, it is (for now) still allowed to contain a duplicate. Without this exception, every full node in the network would be required to keep an index of all transactions ever. This was implemented, the change is merged in git master (so it will be included in the 0.6.0 release) as well as in several backports. It was tested by roconnor (who demonstrated the original attack on testnet) to prevent his attack, and it was tested to still accept the current longest block chain on the real network.


To conclude: We want to fix a newly found vulnerability, we need majority of miners to support the fix in order to prevent a potential permanent fork, the fix was thoroughly discussed on the mailing list, the developers support it and it is noncontroversial. With majority support, if all goes well, this change will be activated on march 15th 2012, 0:00 UTC.

PS: thanks to Hazek for proofreading
12  Bitcoin / Development & Technical Discussion / Proposal: bitcoin payment protocol on: October 03, 2011, 10:53:59 AM
Currently, addresses are the only well-supported way of initiating a bitcoin transaction. However, what bitcoin addresses are in practice is no more than a template for a txout script. In practice, such an address (typically a freshly-generated one) is communicated to the payer when a payment is requested, through a website, a QR code, e-mail, ...

If stop limiting ourselves to short strings to define a payment, a lot of possibilities open up. In the following gist i've written up a proposal for a full bitcoin payment protocol, that allows arbitrary scripts, makes the receiver responsible for getting the transaction accepted, optionally removes the burden of transaction fees from the payer, and allows easy tracking of actual individual payments.

https://gist.github.com/1237788

Comments, suggestions, ideas?
13  Bitcoin / Development & Technical Discussion / [PULL] IPv6 support on: July 24, 2011, 03:18:29 PM
See https://github.com/bitcoin/bitcoin/pull/427

General changes (even when IPv6 support is not compiled in):
  • Valid, routable IPv6 addresses are stored and forwarded
  • Name lookups are done using the general getaddrinfo() call
  • The detection system for the local address is improved. (addresses are classified according to their 'reachability', and the most reachable local address encountered is used).
  • The rule that no two connections to addresses within the same /16 should be attempted, was generalized by defining address groups:
    • IPv4 addresses are grouped in /16 blocks
    • IPv6 addresses are grouped in /32 blocks
    • Tunneled IPv6 addresses use the encapsulated IPv4 address (teredo, 6to4, SIIT, well-known prefix)
  • Hostnames can be given using the "[host]:port" format.
  • Support for the "checkorder" message was removed (obsolete, and not worth porting)

Behaviour changes when IPv6 support is enabled:
  • DNS lookups also return IPv6 matches
  • The listening socket is bound to the IPv6 ANY address (::/128) instead of the IPv4 ANY address (0.0.0.0)
  • Connections to non-IPv4 addresses are attempted, using IPv6 sockets (connections to IPv4 addresses still use IPv4 sockets)
  • A local IPv6 address is used instead of an IPv4 one if no routable IPv4 address is available. In this case, it is not advertized through IRC (obsolete).

For internal changes, see the commit message.
14  Bitcoin / Development & Technical Discussion / [RFD] Future fee policy for relaying and mining on: June 06, 2011, 02:09:57 PM
This thread is an attempt to establish a more flexible fee policy for relaying and block mining. Note that these are, eventually, decisions that can and should be made by each miner separately (and, to a lesser extent, all nodes), allowing a free market. However, having a reasonable default policy in the standard client - possibly with some configuration parameters - can make everyone's life a lot easier.

Before I start, this is not directly about the fees enforced by the client when creating transactions. It's definitely related though, but should be determined based on observation of how the network as a whole behaves, and not necessarily be analogous to the rules used for relaying and mining.

So, let's start with the current rules (as they are in git head, and will be in 0.3.23):

For relaying:
  • If a transaction has an output less than 0.01 BTC, a fee of 0.0005 is required.
  • If too many free transactions have already been relayed in the near past, a fee of 0.0005 is required.
  • If a transaction is at least 26000 bytes, it needs a fee of 0.0005 per started 1000 bytes.
  • If a transaction is at least 249000 bytes, it needs a progressively larger fee, as the size approaches 499000 bytes.

For mining:
  • If a transaction is not placed in the first 27000 bytes of a block, or not in the first 4000 bytes and is considered low-priority, a 0.0005 fee is required per started 1000 bytes.
  • If a transaction is not placed in the first 250000 bytes, it needs a progressively larger fee as the block's size approaches 500000 bytes.

To summarize, these rules try to:
  • Prevent bitcoin dust (very small txouts).
  • Prevent spammy transactions from ending up in the block chain, or even from being relayed.
  • Make block storage space increasingly more expensive, so that increased demand should lead to increased fees.

These all look like reasonable goals to encode in the fee policy, but the numbers look somewhat arbitrary and there is no flexibility. Furthermore, nodes that unconditionally drop transactions form a problem for the network's current growth pattern, as a 0.01 BTC (and soon maybe a 0.0005 BTC transaction) may very well be reasonable and useful things on the network soon, and we can't afford to keep issuing new versions of the client just to change the policy.

Therefore, I would suggest the following general scheme:
  • There is no special free-tx zone, all transactions are handled in the same way.
  • All transactions get a priority based on certain "badness" criteria (see further), compensated by fee and time waiting in queue.
  • The memory pool is limited in size (configurable), and when it fills up, the lowest-priority ones are kicked out.
  • Miners select the top priority transactions from the queue, but can enforce a rule like average fee per block, or per txout, or per byte, ... to decide the cut-off point. This, together with priority that takes time in queue into account, makes sure that each transaction (which is not dropped through the memory constraint), is eventually included in a block sometime.

The priority itself should be based on criteria that map to eventual cost for the network. Things I can come up with:
  • Size in bytes
  • Degree of "coin splitting" (see this post, sum of logarithms of input amounts, minus sum of logarithms of output amounts). I prefer this over a "<0.01 is BAD" rule.
  • Number of txouts (or number of signature verifications in them).
  • Other things, like something based on age of coins?

This would lead to eg. a priority formula of: A*(size + B*coinsplitting + C*numtxouts - D*timeinqueue) - fee, with:
  • A: fee per byte
  • B: penalty bytes per degree of coin splitting
  • C: penalty bytes per txout
  • D: bonus bytes per second in queue

So: any opinions, other general schemes, additional badness criteria, comments, remarks, analysis, flaws, bitcoins, ...?
15  Bitcoin / Bitcoin Discussion / 10000000000000000000 hashes on: May 29, 2011, 03:27:28 PM
With block 127430, the total number of hashes estimated to have been performed as work in the block chain surpassed 10^19, or 10 billion billion hashes.

This may look like a large number, but at the current hashing speed, it would only take around a month to redo all that...
16  Bitcoin / Development & Technical Discussion / [PULL] Modularizing bitcoin: CWallet class on: May 23, 2011, 12:39:55 PM
Hello all,

I've been working on restructuring the bitcoin source code a bit. A first step was splitting off all wallet-handling into a separate class CWallet, so that eventually eg. multiple loaded wallets at the same time are possible, less global variables are needed and in general the dependencies inside the code are improved.

I ended up changing somewhat more than expected, as really a lot of code depended on access to those globals.

A summary:
  • A new class CKeyStore manages private keys, and script.cpp depends on access to CKeyStore.
  • A new class CWallet extends CKeyStore, and contains all former wallet-specific globals; CWallet depends on script.cpp, not the other way around.
  • Wallet-specific functions in CTransaction (GetDebit, GetCredit, GetChange, IsMine, IsFromMe), are moved to CWallet, taking their former 'this' argument as an explicit parameter
  • CWalletTx objects know which CWallet they belong to, for convenience, so they have their own direct (and caching) GetDebit/... functions.
  • Some code was moved between CWalletDB, CWallet and main.
  • Main.cpp keeps a set of all 'registered' wallets, which should be informed about updates to the block chain, and does not have any notion about any 'main' wallet. Function in main.cpp that require a wallet (such as GenerateCoins), take an explicit CWallet* argument.
  • The actual CWallet instance used by the application is defined in init.cpp as "CWallet* pwalletMain". rpc.cpp and ui.cpp use this variable.

The code is here: https://github.com/sipa/bitcoin/tree/walletclass/src

Note that the branch is not yet rebased against the current master, is a work in progress and may have bugs. There should not be any changes to the actual program logic, but segfaults or performance degradations are definitely possible.

Comments are welcome.
17  Economy / Economics / IndexCoin on: May 18, 2011, 09:45:32 AM
(repost from general discussion)

Hello,

the past few months I've heard about many people who consider the limited money supply of Bitcoin as a flaw. I am no economist, and won't get involved in a discussion for or against deflation, but there is one claim I am sympathetic with: if people were paid in bitcoins, their pay rate might need to decrease gradually, and people definitely don't like to see decreasing numbers (purely a psychological thing). Hence my solution: IndexCoin.

IndexCoin is a currency backed by bitcoin, but with an exchange rate that varies in time. Actually, IndexCoin is nothing more than a different representation of bitcoin amounts. The exchange rate is determined by an index, which is defined by a central authority. Note however that many such authorities may exist, and people are free to choose one.

The authority publishes (using the necessary cryptographic arrangements, such as digitally signing) regularly an updated file which contains indexing points, Each point is defined as a block number together with an index value, plus a special index for any point in time before the first indexing (typically 1).

The IndexCoin client displays the amount for each transaction calculated for the time/block position in which the transaction took place, plus pseudo-transactions that represent the indexation, eg. "0.1% Interest on balance 1234.45 IDXC: +1.23445", if the index increased with 0.1% at a point in time where the wallet's balance was 1234.45 IDXC.

When doing a transaction, people can freely choose which index they want to use for the currency they send (or the address format could be modified to include information about the holder's native index). The client will then lookup the index value of that, and send the corresponding number of BTC, implicitly doing a feeless "currency convertion". If I use the Alpha-index, and you're using the Beta-index, I could choose to send you an amount in AlphaCoins or in BetaCoins.

Though I am not sure an index linked to such a volatile exchange rate would be a good idea, but exchange sites could be their own index authority, allowing eg. an indexcoin client that denominates values in "MTGUSD".

A payment contract could stipulate a trusted index authority to use for payments then.
18  Bitcoin / Bitcoin Discussion / IndexCoin on: May 17, 2011, 07:21:40 AM
Hello,

the past few months I've heard about many people who consider the limited money supply of Bitcoin as a flaw. I am no economist, and won't get involved in a discussion for or against deflation, but there is one claim I am sympathetic with: if people were paid in bitcoins, their pay rate might need to decrease gradually, and people definitely don't like to see decreasing numbers (purely a psychological thing). Hence my solution: IndexCoin.

IndexCoin is a currency backed by bitcoin, but with an exchange rate that varies in time. Actually, IndexCoin is nothing more than a different representation of bitcoin values. The exchange rate is determined by an index, which is defined by a central authority. Note however that many such authorities may exist, and people are free to choose one.

The authority publishes (using the necessary cryptographic arrangements, such as digitally signing) regularly an updated file which contains indexing points, Each point is defined as a block number together with an index value, plus a special index for any point in time before the first indexing (typically 1).

The IndexCoin client displays the amount for each transaction calculated for the time/block position in which the transaction took place, plus pseudo-transactions that represent the indexation, eg. "0.1% Interest on balance 1234.45 IDXC: +1.23445", if the index increased with 0.1% at a point in time where the wallet's balance was 1234.45 IDXC.

When doing a transaction, people can freely choose which index authority they want to use (or the address format could be modified to include information about the holder's native index). The client will then lookup the index value of the receiver, and send the corresponding number of BTC, implicitly doing a feeless "currency convertion".

Though I am not sure an index linked to such a volatile exchange rate would be a good idea, but exchange sites could be their own index authority, allowing eg. an indexcoin client that denominates values in "MTGUSD".

A payment contract could stipulate a trusted index authority to use for payments then.
19  Bitcoin / Development & Technical Discussion / [PULL] private key and wallet export/import on: May 12, 2011, 10:11:26 PM
See https://github.com/bitcoin/bitcoin/pull/220

Introduces four new RPC calls:
* dumpprivkey: retrieve the private key corresponding to an address
* importprivkey: add a private key to your wallet
* dumpwallet: export the contents of your wallet in various ways
* importwallet: import/merge a dumped wallet into your own

The private key format is analoguous to the address format. It is
a 51-character base58-encoded string, that includes a version number
and a checksum.

The wallet format is JSON-based, and includes:
* addresses (informational, optional)
* private keys
* amounts and balances per address (informational, optional)
* blocks where addresses were first used (optional)
* ids of transactions in which addresses were credited (optional)
* labels (optional)

It specifically does not contain:
* sender address book
* settings
* account information
* unconfirmed wallet transactions

I will post a full specification of the dump file format soon.

Earlier posts:
* Hal's challenge: http://bitcointalk.org/index.php?topic=3638.0
* Early discussion of dump format: http://bitcointalk.org/index.php?topic=4448.0
* Early patch with only private key export and import: http://bitcointalk.org/index.php?topic=3906.0
20  Bitcoin / Development & Technical Discussion / [RFC] txout destruction bonus on: May 11, 2011, 11:15:25 AM
Hello,

one of the aspects of the cost for the bitcoin network of a transaction, which is currently not taken into account in the default fee policy, is the permanent storage cost it requires. The size of a transaction is used, but not whether or not it will ever be possible to prune it from the chain.

It is possible to compensate for this, by giving a "bonus" for the redeeming of earlier txouts. If a transaction is large, but has a lot of 0.01 BTC inputs, and one big 10 BTC output, its cost for the network may actually be negative, since it may allow many older tx's to be pruned in the future.

Idea 1

Use a term A*(nTxOut - nTxIn) in the fee calculation.

This simply gives a bonus to transactions that merge a lot of coins, and a malus to transactions that split a lot of coins.

Idea 2

Do some weighing based on the value of the produced/consumed txout's, as small coins are worse for the network than large ones.

Use a term B*(sum(2log(21M/txout.amount),txout in tx.outputs) - sum(2log(21M/txin.amount),txin in tx.inputs)) in the fee calculation.

Essentially, we define a "weight" to each coin (=unredeemed txout), defined as the 2log of its fraction of the maximum amount. A 1 BTC coin would weigh 24.32, 1 ucBTC would weigh 50.90.

Splitting off 0.01 BTC from a 1 BTC coin, would increase the total weight of coins with 30.98, merging 100 coins of 0.01 BTC into a 1 BTC coin decreases the weight by 3072.45.

Idea 3

Use the actual sizes in the calculation.

Use a term (tx.size - C*sum(txin.prevout.tx.size/txin.prevout.tx.outputs.count, txin in tx.inputs)) instead of the normal per-size fee.

Essentially, we subtract a fraction of the size of all the prevout tx's from the current one. C should be between 0 and 1. C=0 is the current scheme, with C=1 a simple transfer-entirely transaction in a chain typically becomes costless (at least what its size concerns, there may and maybe should be other fee factors).
Pages: [1] 2 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!