Re: [Bitcoin-development] Even simpler minimum fee calculation formula: f bounty*fork_rate/average_blocksize
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Last week I posted a writeup: On the optimal block size and why transaction fees are 8 times too low (or transactions 8 times too big). Peter Todd made some nice additions to it including different pool sizes into the numbers. Peter claims on IRC that he is writing a paper of some kind on this topic. I suggest he submit it to that crypto-currency thing the foundation is sponsoring. Given the Nov 24th deadline, I also suggest at least making part of it public ASAP so some peer review can be done. It would be a shame for a simple math error to cause embarassment later. However, it occurred to me that things can in fact be calculated even simpler: The measured fork rate will mean out all the different pool sizes and network latencies and will as such provide a simple number we can use to estimate the minimum fee. Are you sure about that? You are assuming linearity where none may exist. Luckily the fork frequency and the average block size are easily measurable. blockchain.info keeps historical graphs of number of orphaned blocks pr day Are those stats accurate? Have any pool operators at least confirmed that the orphaned blocks that blockchain.info reports match their own records? My gut feeling is to relay all orphaned blocks. We know that with a high investment and sybil attack as blockchain.info has done you can have better awareness of orphaned blocks than someone without those resources. If having that awareness is ever a profitable thing we have both created an incentive to sybil attack the network and we have linked profitability to high up-front capital investments. On those grounds alone I will argue that we should relay all orphans to even the playing field. If there is a circumstance where we do not want the attacker to have that knowledge we have failed anyway, as blockchain.info's sybil attack on the network clearly shows. Anyway - the all important number is alpha, the network latency which we expect to be dependent of various things such as interconnectivity, bandwidths, software quality etc, where mainly the latter is within our hands to bring down the fee. And you can actually setup the standard client to choose a better fee, as all the parameters in the formula are easily measured! With relayed orphans you could even have P2Pool enforce an optimal tx inclusion policy based on a statistical model by including proof of those orphans into the P2Pool share chain. P2Pool needs to take fees into account soon, but simply asking for blocks with the highest total fees or even highest fee/kb appears to be incomplete according to what your and Peter's analysis is suggesting. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJSg9pfAAoJEEWCsU4mNhiP5mcH/jKd2Rpl9gEJ7WhTndS5gYJ9 Ep151NyD/iKpAA4E/d9QVYalo8595LCqnrXnV6wuvuiifB6EJD5WBJq3MAMyaJLA agl920ygY98slhDmFhnwlU9lkJVim5FoUkZgE7lQ5dr0MIhvoLQiF2Ywky49Izf0 IqL+nyW83AQweSalvktA+XGkDfGDV/EnJN7SdNqKDNtE7E9NeMl61NNOWNndsYy6 uT4PF2YB7rh8wGyHXMTC4Z192pfW4S4s60ZAflG/sTtWCcEwWi+5V/RIu0o5Hmog RFpEPvc6d6ykdqtPfTRADMGkT2wC1yXsgeos9oFFVVuVSj8EqHb2db0B+psHRBk= =76Qs -END PGP SIGNATURE- -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment protocol for onion URLs.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Oct 26, 2013 at 3:31 AM, Gregory Maxwell gmaxw...@gmail.com wrote: One limitation of the payment protocol as speced is that there is no way for a hidden service site to make use of its full authentication capability because they are unable to get SSL certificates issued to them. Thoughts? I think this is a great idea and wish to see it done. Here is 1BTC for you, redeemable when you finish this task. I trust either Jeff Garzik or Peter Todd to evaluate your finished product, or possibly someone elses: 37NDa6iFLEozbvw8vj38ri5D6SLw5xQujS 22e067d3317e6300a9edda84fd0e24d8bfb86cf91540c3fe7acff45e4dc64dd3:0 redeemScript : 5241045f4bba15dbfe94a45f362aa13bbaef8bbf21ff84fec1be5b27fa628f4b3acca1a2e5711503c8b8fe2e228229b8b8814f9e33e0f7a314a089d7140269ffd51fe44104d34775baab521d7ba2bd43997312d5f663633484ae1a4d84246866b7088297715a049e2288ae16f168809d36e2da1162f03412bf23aa5f949f235eb2e71417834104f005d39733ec09a1efa0cf8dcf3df50691e22c2374ff9a96d1d9ecb98a1e866c9f558a9fa1ba8ef0bbbad01f396768c0cb2dda9924dc0aaee1481604a8bd9ce453ae -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJSbfy2AAoJEEWCsU4mNhiPrMMH/jd+AgVYUKd1vmP1BfaZum1s X186JulwF659YHOx94dLs+NOjvjMfY6cPbHm+B0j20CnhWrZrXzcXvwTHnzOSuoc 1AAXg0KDbvyo+7PvTrsGQfHhT1FZSRzIUToofVmFlvEIO6/LiYMAYWCgIiX9nPvv RlvdtavTST+cY19yZamo5X0XU5cgI2tbtVWKEHJQ2VcglCgwFg5K0kZ0O1NMKbcZ KBagY3PVTiHnYP+LwSTW6EU9DNq0eLYG39mz4N6CqGkXZjGgh2YXZ6Sl2qRuO/5e Rd9HcJXKqPKqMuRpQ2PA5U3U6QSyrUz7/fmi5dsOxnR6pdR53kjUVSvbOqBFHXw= =I1/R -END PGP SIGNATURE- -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Making fee estimation better
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sat, Oct 26, 2013 at 12:25 AM, Gavin Andresen
gavinandre...@gmail.com wrote:
I feel like there is a lot of in the weeds discussion here about
theoretical, what-if-this-and-that-happens-in-the-future scenarios.
I would just like to point out (again) that this is not intended to be The
One True Solution For Transaction Fees And Transaction Prioritization. If
you've got a better mechanism for estimating fees, fantastic! If it turns
out estimates are often-enough wrong to be a problem and you've got a
solution for that, fantastic!
This discussion seems to be a lot of hot air over a simple observation that
estimates are imperfect and always will be. I do not understand you vehement
opposition the notion that a backup is a good thing except in the context that
replacement to change fees is halfway to profit-seeking replacement by fee.
Peter Todd:
You did a fair bit of leg work for replace-by-fee. Seems to me that
replace-for-fee will help prep infrastructure to eventual replace-by-fee usage,
while avoiding some of the politics around zero-conf transactions.
Go dust off your code and make it happen. I want to see a mempool
implementation similar to what you did for me on replace-for-fee, and I
understand much of the code is written in any case. This time I also want to
see a increasetxfee RPC command, and erasewallettx RPC command to deal with
duplicates. (I know touching the wallet code is scary) Having all will enable
usage, and I can imagine getting pools to use this will be easy enough.
(eligius?)
Here is your 4BTC bounty. In the event I am not around Gregory Maxwell can also
adjudicate. If both you and him feel someone else deserves it, by all means
send them the funds
bitcoind decodescript
522102d527466a144aac2030cd16d8be3d91231af26a95c2f8fc345a0ea0e8d53ac3914104d34775baab521d7ba2bd43997312d5f663633484ae1a4d84246866b7088297715a049e2288ae16f168809d36e2da1162f03412bf23aa5f949f235eb2e71417834104f005d39733ec09a1efa0cf8dcf3df50691e22c2374ff9a96d1d9ecb98a1e866c9f558a9fa1ba8ef0bbbad01f396768c0cb2dda9924dc0aaee1481604a8bd9ce453ae
{
asm : 2
02d527466a144aac2030cd16d8be3d91231af26a95c2f8fc345a0ea0e8d53ac391
04d34775baab521d7ba2bd43997312d5f663633484ae1a4d84246866b7088297715a049e2288ae16f168809d36e2da1162f03412bf23aa5f949f235eb2e7141783
04f005d39733ec09a1efa0cf8dcf3df50691e22c2374ff9a96d1d9ecb98a1e866c9f558a9fa1ba8ef0bbbad01f396768c0cb2dda9924dc0aaee1481604a8bd9ce4
3 OP_CHECKMULTISIG,
reqSigs : 2,
type : multisig,
addresses : [
1L9p6QiWs2nfinyF4CnbqysWijMvvcsnxe,
1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv,
1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB
],
p2sh : 3BST1dPxvgMGL3d9GPCHvTyZNsJ7YKTVPo
}
(I realized right after my Tor payment protocol bounty that I would need some
bit of uniqueness like a bounty-specific pubkey to disambiguate multiple such
bounties!)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJSbg9wAAoJEEWCsU4mNhiPROQH/j+eWccx7oSVsr94cgGu7qza
kdnA7B6BAlnCPg3D+nqEFKDqzOyFppeHLadCCIYHHc5iVRfJuu9J1Gh9lgMCuyCW
qN7ZOBCARjiVOqrHPQR1pf18i0ko7dQWw2hZjy51XKuFxAsHwZpB/fzQCbVVzyB6
l5SECCou58bJ/x7B0L93K+yjXuMGnvi9jqiLAKkLWYDzVm7TeVWNVQr04B7sqi6A
mY+BfG61e7sqM2UJd69yGLeQdEfghYTmtA+EaaqYS0L11m7yFGZdUqD7UNy1FKO7
44M1JTh2ANnQRjSTJWOBXQNHMa/mxDCji1VFUtJhZKEuOZyWpGm7HMH1D3vcvcQ=
=4flN
-END PGP SIGNATURE-
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Aug 16, 2013 at 2:15 PM, Peter Todd p...@petertodd.org wrote: On Fri, Aug 16, 2013 at 10:01:16AM -0400, Peter Todd wrote: Doing this also makes it more difficult to sybil the network - for instance right now you can create SPV honeypots that allow incoming connections only from SPV nodes, thus attracting a disproportionate % of the total SPV population given a relatively small number of nodes. You can then use that to harm SPV nodes by, for instance, making a % of transactions be dropped deterministicly, either by the bloom matching code, or when sent. Users unlucky enough to be surrounded by sybil nodes will have their transactions mysteriously fail to arrive in their wallets, or have their transactions mysteriously never confirm. Given how few full nodes there are, it probably won't take very many honeypots to pull off this attack, especially if you combine it with a simultaneous max connections or bloom io attack to degrade the capacity of honest nodes. Oh, here's an even better way to do the tx drop attack: when you drop a transaction, make a fake one that pays the same scriptPubKeys with the same amount, and send it to the SPV peer instead. They'll see the transaction go through and show up in their wallet, but it'll look like it got stuck and never confirmed. They'll soon wind up with a wallet full of useless transactions, effectively locking them out of their money. Excellent, and makes a mockery of zero-confirmation transactions to boot. Can be prevented by passing along txin proofs, but they require the full transaction, so the effective UTXO set size would go up greatly post-pruning. I am sure Mike would love to demand that full nodes do this for their peers though, at least until UTXO commitments are greated, at great cost to full nodes. On the other hand, a tx with some txin proofs can be safely relayed by SPV nodes, an interesting concept. Do the UTXO commitment people have keeping proof size small in mind? Here's another question for you Mike: So does bitcoinj have any protections against peers flooding you with useless garbage? It'd be easy to rack up a user's data bill for instance by just creating junk unconfirmed transactions matching the bloom filter. That is good too. I'll bounty 2.5BTC to implement the first attack, and 0.5BTC for the second. Should be easy to do as a patch to satoshi bitcoin I think. The implementation must include a RFC3514 compliant service bit to let peers know of the operators intentions. Along those lines I'll donate 3BTC to adding service bit selection to DNS seeds. We should clearly show people the limitations of SPV before they depend too much on it. Nothing wakes users up like a 21 million BTC transaction in their wallet. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJSEYvxAAoJEEWCsU4mNhiPxI8IAJaWJ9s0YG3Ex5h8Dr6oPJ9M uXTXa/Rt0DqS6mmyD9O80sXfgPbPbQa2rDL6imlqONaWfpXFZl2W9vxRGaZJ9wrr 3KBHzK8lasDOKqlEX92h8ZmQBjw4w5bK/heRLo1PnSZ8ojKn8+My1JvZWOPzF0Ct tDXXuCE94csKuGRdmdDdVoXqy4XZaMQhHrGbrWVotQs1HzX3iK146GoGaZC0YyBx cdWg/xDPtAxgb5zf2RSeNHfXeY0wZawe8vBxaS56gCRl54PG7fJvqL+YPcarNb1p zEmahJjoyQHskjFeDpgEiXnWu3K3JGTSA5GvekWvBbJCcV4o1E6EI6LG0f1SfIs= =12DC -END PGP SIGNATURE- -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
-BEGIN PGP MESSAGE- Version: GnuPG v1.4.11 (GNU/Linux) hQEMA8xUMVQPvvGFAQf9HL/SN/TZNQuVAjz5ggDzVzpYEzLRkFlgTR2lPURaR28F G0SgcvJmt1cvucxZRxzSUDCx58Ub16dzx9IBKQ+GDDUXbHGqExfbeIFx96okNsSm GmRRyORm+L7rdpQ3G8HcfKr1R9YufgaAjsa05eXlXl+fgpYrSBgitY6T3IZ9c0Z7 eF6yjogj5iaDUP2m7xLmRyaQvT/0GdRYk+c2JOH0HGGQ2WWylPMiczJmKmV4jrDd 6asoesEk5kH0IWM2xiY2re+/WkRVeNUlVT7R4+uIzQm/iMzKpIWNiF5a87x3+E9+ +KgJg1a4elKZ6UO4Bvov+Gw65u7q3eunVUYHUKfaLIUBDAO4Pc5vOCVNqAEIAJyT qFTqTbV9XE+REN/1KVmRLgidcRcxnSFFnkUVUozdMev8oGqoW3iAs8rVr5DuSO/a FW0UOdI9vBLC51+pdbBNoR9c1saheRbnTks67kLziQmuBFkly6cbLYUyh859pA3K yjRaRLa1Q6IX76NZTdEc3F7XnfmMBwEFS2t9vSAqhFptAXlhnmKov+g7iJ8oaAWQ 361OcXvxPk6wmWKFroZIo1is0a3izoAcLFB9NWv7BU9I06XB3Gw5gVnzXQexTlV+ KHd8zeJYfc1IaPLdxefhp8tfrJIjAOXq9FmKjgB5Qki8cgCWM1pJIJK0t4XTVxI6 8LU1aldq5Qlond0aIBfS6QFErTFtVYmFLjl8YETcphBZAOSb6Rgudrz9mAL1brOu fjg9aVTSTjWjFHflRFSpNKVjj+5zS93NMEEaNQmWjeexScw175DVKJoU6lnVFgfk I7d+Lf5axVwlawZ+euN9YURE1azWUR4OECfDvd6Na8MGs+OwedbWP5/OfDGg2rzN OG/SK5AxlrshrOmrY7emlMOhYIhd8A+KQ0ghLocTv8JVDvaIEnWkWEq4idhzOv4m 9xFmde45SOxy/PuReDEgGAS3S1IOMMzdkEH8yuzYf2cFzQ0d4PmHNn6NGDo9bEIV Bjw9pqg5rg+8un14T3+c9ZbfkEvLB+sEQ9uVidg9jE1ZSH/l9XG0stbSnnDmAkYy DbbA7WDsJ0fxQD1zvnDUlq84I2Fr5RwecOWuCUUUHGXdfe0AnxGL1k96Jd0t3BXj JbY5fBUbN1QTuwqUSUBhE8uE7gGVZyWHel+DtKxwpIkpQ/CPLxFWJQL8oswN4Re+ CgS1Fs/P2MJdb0ht8cTTdFUEIKYW41eG84Vgpyn7gwd/IE1gPdpsDtoAV8uwIXsJ WBHtYgO/cH3ofyITOcsm7gfkI3V4T87I3Sjrnk0ipa6fWh8dwhZnG1s5b7lKVgAp QOqgWdjoP+4/FWCCpo9EVWqRfRU7js/TfuKOBiLDpKEkdmmuCOiMlxe5vt5FUHbq wT0V5Iian5GcqZvJ/CZWzAxMY+qXu/OziI9Emvz5AA/yWymcHJl2M8RY+L+fVB67 /JSsHl0xQLHehKIFZKuTacy87pRHCoq7vA72lm+XCqC7+RojzPwODia7ShCfrZe2 YctdU/VWVMMgkpLcGxRMRFc2Rxbbge3kEQCt+b7lL7HVq0vsBoF4g3X4kzLxxyeD JiR8PHknlWOjy5KgseKzTCt3sygvyJZrEPQ5SiBtoAkLgmEzkOxiy1DHrj59soM9 QY7L3XTLLOya4daL5+iZjZXm28JNXAYycAu3fyXx7rnbL6m/gcGjJZiuwwajMvmF WvjbJBm9f5qOxK87ShnPj2ZwQ1w1nnz7i5oOdtELwUb96uMFegNDRSfMNpN4pmTh 2Qpffp9QZMEOxE+a7SnNjq5xG4S3qTnhdhTzQL5sIC+yJZ7L2gdbbrjdud2gcKRc yQIkst51OIV6/xJ65AD6qzIcifpLm+u5/t6eVGLvw0G8u3gFHgelM1kPfX8iYDOR CTDnJxx30/GXEvqD4/nCm5JytgolzH/PilBME1w2dPf845HebA0XCAhSoqdoLCvF 7jrllVCh/PDlK40XbO/cDYgXF7deDbgXVF2OBGc6qqAho3VE83ebR1wQWlUOyPIo ScQyePNu500Yy/GUnwBK7029N4r6R1RBDn/rTsD/2w== =6OvE -END PGP MESSAGE- -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Linux packaging letter
My signature: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Linux distribution packaging and Bitcoin 2013-07-23 This note summarises the dangers inherent in the Linux distribution packaging model for Bitcoin, and forms a request from upstream maintainers to not distribute Bitcoin node software as part of distribution package repositories without understanding the special requirements of Bitcoin. Distributors typically unbundle internal libraries and apply other patches for a variety of generally good reasons, including ensuring that security-critical fixes can be applied once, rather than multiple times for many different packages. In most cases, the common distribution packaging policy has many advantages. However, Bitcoin nodes are an unusual category of software: they implement a complex group consensus in which every client verifies the behaviour of every other exactly. Even an exceptionally subtle change - including apparently harmless bugfixes - can cause a failure to reach consensus. A consensus failure of one client is a security risk to the user of that client. A significant number of nodes failing to reach consensus - as happened in March 2013 due to a change in database libraries[1] - is a critical problem that threatens the functionality and security of the system for all users. For this reason, it is _vital_ that as much of the network as possible uses _unmodified_ implementations that have been carefully audited and tested, including dependencies. For instance, if the included copy of LevelDB in bitcoind is replaced by a system-wide shared library, _any_ change to that shared library requires auditing and testing, a requirement generally not met by standard distributor packaging practices. Because distributed global consensus is a new area of computer science research, the undersigned request that distributors refrain from packaging Bitcoin node software (including bitcoind and Bitcoin-Qt) and direct users to the upstream-provided binaries instead _until they understand the unique testing procedures and other requirements to achieve consensus_. Beyond being globally consistent, upstream binaries are produced using a reproducible build system[2], ensuring that they can be audited for backdoors. 1. https://en.bitcoin.it/wiki/BIP_0050 2. http://gitian.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJR9WC5AAoJEEWCsU4mNhiPg6UH/2oHzBWBPaQMhH/GCTHQEi5U 7GSRfqwihIs/M2ROHLNq0HhgWR7mPAh5TTI6+tG95FCGCGNZq0seqw9wW4ZyGCoc VueY51q4hcn23405oLD/QGK2lDxxywWY8XtFYVPqAzXTq6zRzgpNJkjoRtOAUOP7 3PrRkimYYyj0KrqFg+cEvZDT27dkeX+5PXM6Ua0o7h/TlhR2RJPhej5DI8cNLXgA f0t+mES4Apb6zLgnEYYlPp22FR9vuFcJO3z1akhVL4DLUMqr58NYHLVnH1FH0Jhn hVuld159QtCjQ5Qyn19cn86akTQJVi+ikCXqaKriCc2jBFX7TCI8WTDc6aSZpsQ= =oX5d -END PGP SIGNATURE- -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Reward for P2SH IsStandard() patch.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 As you all know keeping the size of the UTXO set small is critical, and more recently we've also had problems with distasteful data being added to the UTXO set. (http://garzikrants.blogspot.se/2013_04_01_archive.html) Gregory Maxwell has an excellent solution to the distasteful data problem in the form of P2SH^2 (http://comments.gmane.org/gmane.comp.bitcoin.devel/1996) and Peter Todd pointed out how we can implement it with the existing P2SH form. We're also going to be implementing some kind of OP_RETURN data soon which handles the timestamping and similar use-cases, again without UTXO impact. Right now the only scriptPubKey form with any significant use is the checksighash. Bare pubkey gets used by the odd miner, and by Deepbit due to their ancient codebase. The former isn't an issue as the miner mines the txout themselves, and the latter shouldn't find updating to be a big deal. OP_CHECKMULTISIG is used by Peter Todd's timestamper, but that can be changed to OP_RETURN without difficulty. However all that will (hopefully!) soon change as hardware wallets and the payment protocol make hardware wallets worthwhile, and we should make sure these protocols take the extra step of using P2SH before we get locked into a bunch OP_CHECKMULTISIG implementations. We also have the problem that the IsStandard() code accepts up to 120 bytes of junk data as a pubkey, allowing injection of 240 bytes of *spendable* data into the UTXO set with bare OP_CHECKMULTISIG. This capability has to be stopped. Thus I'm offering a reward of 1BTC for whomever creates a patch to change IsStandard() to accept only P2SH and pubkeyhash in a raw scriptSig, allowing other forms only when used with P2SH. I'm offering a further 1BTC to whomever gets such a patch accepted into mainline. It's a pretty easy patch, so I'm asking that all core-developers (that includes you Peter) hold off for one week to give less experienced developers a crack at it. If for some reason you want to remain anonymous that is ok by me as well provided you assign copyright to me. I do expect unittests. Should be about half a day to a days work. Long-term we should be using P2SH with an inner OP_CHECKSIG for most addresses as it's a 1 byte savings. Change addresses can have this done first, although bitcoinj support will help so that satoshidice and similar sites can pay to P2SH change. As for multisig's P2SH overhead for a 1-of-2 and 2-of-2 and 3-of-3, is 10%, 8.6% and 6.2% respectively, all pretty minor, especially if you assume the blocksize limit will be raised. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJR4vX+AAoJEEWCsU4mNhiPg/EIAKWFaMsugbY4zZ+dpgnaTcUr D1ZnY5PogETVqcwuXdVdHe2zCUcBhejsBe8ic9vp8OnttXTxo8uXJp9xBuq9VYBN vXMyGKtxacLL5WS5ShAWnWS47xLf9wnKCJSGX0nqaETIQEUgqCMjTGspZNOpC9W0 fKBIDi4cZbpXn1EQx45v9vplZhFg+vBQV/Ia2/5rjZLPFvdqZoSBruOVTB/X2SDU Hq36DQkRFblp/s3Ktv9c3yUQ8HocRIXD8jKRsE+uCNfEeI2b9oLpPp1cPsOvjveI McJnHod8EDzxwbm6abK2cxHWBpGmBa5AABsRmQfpJK+u7GDQoPqzfJ68M1otZjk= =uP4n -END PGP SIGNATURE- -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Jul 14, 2013 at 11:18 AM, Jorge Timón jti...@monetize.io wrote: All the arguments in favor of this pegging use zerocoin's point of view. Sure it would be much better for it, but are additional costs to the bitcoin network and you cannot do it with every chain. Seems that Peter is describing a system that requires no changes at all to the Bitcoin codebase and thus there are no costs whatsoever. Peter: I'm a bit confused by this concept of bi-directional sacrifice though, I assume there exists only a sacrifice in one direction right? Wouldn't selling a zerocoin be just a matter of giving zerocoin a rule so that the zerocoin tx moving it to the new owner only happens if a specific form of bitcoin tx happens too? Merged mining is not mining the coin for free. The total reward (ie btc + frc + nmc + dvc) should tend to equal the mining costs. But the value comes from demand, not costs. So if people demand it more it price will rise no matter how is mined. And if the price rises it will make sense to spend more on mining. Bitcoins are worth because it costs to mine them is a Marxian labor thory of value argument. It's the other way arround as Menger taught us. Merge mining is very much mining a coin for free. Ask not what the total reward is, ask that the marginal cost of merge mining an additional coin is. The issue is that unless there is a cost to mining a *invalid* block the merge mined coin has little protection from miners who mine invalid blocks, either maliciously or through negligence. If the coin isn't worth much, either because it's market value is low or the worth is negative to the malicious miner, your theories of value have nothing to do with the issue. Gregory Maxwell has written about this issue before on the #bitcoin-dev IRC channel and on bitcointalk as well if memory serves. I advise you to look up his description of the problem, almost everything he writes on the topic of crypto-coin theory is spot-on correct. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJR4vpGAAoJEEWCsU4mNhiPwu0IAMrzkVfI0CQuNJRCR+jwhNts juEerApSSpBes6CjLBJJYZWDdMReSl6izqNDancnJygYc+Q5/IkwBispyZyeIVqY HbV+jyAFQeVaJBZp8N+ZUDfN9/35SkPb4Y30dkq6V76hBfl+59bWq4qG0dhiO915 SBWAUPLspb5GOyu494GJUr4SPzgs9mAKfNGeQR2anOLj8Qam8Khfa4Zm5T5dX8WQ vBunUCLykPvWBC3nuTDBU5gQu4TGW9ivGB4p6yLr7MyaPQYZEnYGqgU/yIfAhnBj MfIfs6njPwhGMwteNmwLoS0VLRBFjWZDflquJ0NK6mNLR3c9yjOFMFPTTZFVinQ= =b40P -END PGP SIGNATURE- -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Reward for P2SH IsStandard() patch.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Jul 14, 2013 at 7:28 PM, Pieter Wuille pieter.wui...@gmail.com wrote: On Sun, Jul 14, 2013 at 07:05:26PM +, John Dillon wrote: Long-term we should be using P2SH with an inner OP_CHECKSIG for most addresses as it's a 1 byte savings. Change addresses can have this done first, although bitcoinj support will help so that satoshidice and similar sites can pay to P2SH change. As for multisig's P2SH overhead for a 1-of-2 and 2-of-2 and 3-of-3, is 10%, 8.6% and 6.2% respectively, all pretty minor, especially if you assume the blocksize limit will be raised. Small comment: the current implementation in the reference client uses a custom script encoder for the UTXO database, which stores every (valid) send-to-pubkey as 33 bytes and every send-to-pubkeyhash or send-to-scripthash as 21 bytes. So for standard address payment, there is no storage impact of using P2SH instead. By impact I am referring to the impact on transaction size and thus blockchain space and fees, not UTXO size as stored by nodes themselves. Specifically take the size of the txout and txin and compare the version using P2SH to the equivalent version not using it to get my numbers. Anyway, given how much uncompressed keys are still used obviously fee pressure isn't even close to getting people to create efficient transactions. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJR4v6QAAoJEEWCsU4mNhiP/ToH/1zwzkG0v8OphBaglzhF/dha QgRXy3CGQqs43w1hEsfPNaZUyKIZz2gmGtJV2PUh5FavhWY9IUuMCVLvPJ18KZkc eCLtAWSlUkjemXz6S52RPXW3vmKTJzZK4ZBZP0JiRYfhBQWbUlArLh+mQw9RcWng 9fdS/Xw4QYFfnN46NMlHdHyqGn4Mu8VgsozeUlxWXBGorf2+IFbMxR1BRi33CluH 3r6AIRHXPSqgHf6qnHgWqKh/WXMxuG8lLyLa00Rj+ByNcNQCwLV/+9AzSJYNA5Ol nnGdkbVDtLjmDS4KjwuSXGP8jh/uRrHLubcgk6UEm27K2/yJxARBfECo78aBLsg= =Nx+9 -END PGP SIGNATURE- -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Jul 14, 2013 at 7:33 PM, Luke-Jr l...@dashjr.org wrote: Merge mining is very much mining a coin for free. Ask not what the total reward is, ask that the marginal cost of merge mining an additional coin is. But the total reward is what mining will tend toward equalizing in costs. In any case, the cryptocurrencies are neutral to cost of mining, or perhaps even benefit from it being as cheap as possible: if it's cheaper to mine, you can get an even higher difficulty/security out of it. Again, you forget that there may exist miners for which the value of the coin is negative. Never mind that in practice you want there to exist a cost to encourage miners to actually pay attention to what they mind and to encourage them to update software when required and participate. The issue is that unless there is a cost to mining a *invalid* block the merge mined coin has little protection from miners who mine invalid blocks, either maliciously or through negligence. If the coin isn't worth much, either because it's market value is low or the worth is negative to the malicious miner, your theories of value have nothing to do with the issue. Invalid blocks are rejected by validating clients in all circumstances. Validating clients, not SPV clients. I suspect you may mean a block that doesn't include transactions you want confirmed. In that case, you must not be paying sufficient fees for the miner to consider it worth their time, or must be doing something the miner considers fundamentally objectionable (in which case they won't be satisfied by any fee). But these miners, unless they are able to acquire over 50% of the hashrate (in which case the cryptocoin is compromised), are not the only ones mining blocks, and if another miner accepts your transactions there is no issue. All those things simply change the amount of alt-coin the miner gets, which to the miner may have no reward. You also have the issue that we may be talking about a non-currency chain where reward is more nebulous. In any case, regarding a zerocoin chain, Peter's observation that proof-of-sacrifice allows a strong 51% attck defense is very clever and IMO is significantly stronger than proof-of-work mining, merged or not, would provide. It's essentially the ability to conjur up mining capacity on demand, but only by those who have a stake in the crypto-coin. It does depend on the existance of a proof-of-work chain, but we have a perfectly good one handy. PS: good to see you signing you email! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJR4wCFAAoJEEWCsU4mNhiPIcwH+gLYbUPDi/7ITK02wftqEV2E FSlzZ0W8aw7z7sF7hqPm7jpmtqbXdvQRSSy+XRDgWUxvF72o5oRTwOpY7xN8KOct 9rMwF35nld8An9FOjOB6NR3sIQxmAg9q7xoilZrOHyRFcz/UT0BexSZ3x5DrKIAB 6S7qalrGT0NWZx8CI0PRAzY8Nx+WouaoofBaypRaXBVJxigFqJlWNxgUM1FuoCL+ C1wn0hlbWfO42Mh9jdnFZXhH2Omd5V3PzIS/t2cJGTjrwr7nT6VAJu+0hbNZHI/q yg0TGbO/01pp4OVe7WdLz9OktMqqDdDZJd6HWLQk07zqHS3iRJ2cpRIO6k9UCk0= =oicX -END PGP SIGNATURE- -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Jul 14, 2013 at 7:42 PM, Pieter Wuille pieter.wui...@gmail.com wrote: On Sun, Jul 14, 2013 at 07:33:06PM +, Luke-Jr wrote: Invalid blocks are rejected by validating clients in all circumstances. I don't think that's what John means. If you have hash power for the parent chain, mining invalid blocks for the merge-mined chain costs you nothing. Yes, they will be invalid, but you've lost nothing. The basic assumption underlying mining security is that it is more profitable to collaborate with mining a chain (and profit from the block payout) than to attack it. In the case of merged mining, this assumption is not valid. You said it better than I did. Essentially I am worried about the chain being strangled at birth, merge-mining makes doing so cost nothing for the attacker. With zerocoin this is a particularly dangerous possibility due to those in the Bitcoin community who would like to see Bitcoin continue to have poor privacy properties. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJR4wF9AAoJEEWCsU4mNhiPtCgH/3QLvFer3QHNU7AP+nehwcgK QS3xLv60lvm+pYLVAp9xFyJ5SCHVGTPvWRBmoldk8xxh9ORHlNEsnrcx9ZONTJ4F ja4Alp9MLZK5S8dKk2juJNdKziyRkQci/nNwuqepX5JjCIRNZq1lcW4Be4W7InPt Ltrvp7lA03uNuAXxtlYnko4mEY5l1NiBp4BvhGZ6+GRdCltPeIk2m0NwLDHWd31t qFLnnPSw0/9FGVs7lOaWuxbMGwPzGrIu6TXm17dqgBsl+8JuP6zHFE1ccqIxKyb6 Tdf4yNvhsvE+qlTnmcQNxM9nMHL4uqBZqJR174fAKQzcNGzVLloqbmRqKzuw5o4= =leUJ -END PGP SIGNATURE- -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Protecting Bitcoin against network-wide DoS attack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 It's been pointed out recently how a fairly cheap attack on the Bitcoin network would be to take advantage of the fact that we limit the number of incoming connections, but don't require anything of those connections. This means an attacker can simply repeatedly query the the DNS seeds for new addresses and make enough incoming connections that those nodes can not accept further clients. nMaxConnections defaults to 125, and beyond that there is the limit on file descriptors, as well as possible limits by stateful firewalls. (how much memory/cpu does an incoming connection require?) The DNS seeds themselves crawl the network on your behalf, and let you direct the attack starting at the nodes new SPV clients are most likely to connect too. The cost to the attacker is minimal, 1 INV message per transaction and block, and some gossiped peer addresses. Currently that should be on the order of 30 bytes a second. The attacker can do even better by pretending to be an SPV client, thus reducing their incoming bandwidth consumption to nearly nothing, yet increasing resource usage on the node. Peter estimated you would need just 200 or so well distributed IP addresses to make it impossible to use an SPV client. In fact as far as I can tell for incoming connections we don't force incoming connections to be well distributed, so the attack could be done by simply one server with enough amount of bandwidth. Estimates of the total number of nodes out there on mainnet are in the tens of thousands, let's say 25,000 for arguments sake. 125 connections to every one of those nodes would only cost the attacker 94MB/s of incoming bandwidth, easily attainable by a few cheap EC2 nodes, and on EC2 incoming bandwidth is free. The SPV version of the attack would let the attacker spend as little as they wished. Obviously if we want to make it possible for SPV nodes to reliably connect to the network we need to give them a way to prove they have sacrificed some limited resource to allow nodes to distinguish legit users from attackers. Failing that, we need to make attacks sufficiently expensive to discourage bored script-kiddies, much the same way flooding the network with transactions is sufficiently expensive due to fees that such attacks are impractical. Now something to keep in mind is whatever we ask SPV nodes to sacrifice must not be reusable. For instance proof-of-stake *doesn't* work without consensus because an attacker can reuse the proof for multiple connections. Similarly IP addresses don't work, requring incoming connections to be well distributed in IP space isn't a bad idea, but it doesn't buy much DoS resistance. Fees paid by confirmed transactions do work, but only if something links the transaction to the specific connection. We also want whatever the nodes to sacrifice to be something not much more costly to the client than to the attacker. Bandwidth isn't reusable, but an attacker with EC2 or a botnet has vastly lower costs for bandwidth than a user with an Android wallet on a phone. For a non-SPV-mode client we can easily do anti-DoS by requiring the peer to do useful work. As the incoming connections slots get used up, simply kick off the incoming peers who have relayed the least fee-paying transactions and valid blocks, keeping the peers who have relayed the most. We can continue to use the usual, randomized, logic for outgoing peers to attempt to preserve the randomized structure of the bitcoin network. Without an ongoing attack nodes making new connections are unaffected, and during an attack new connections are made somewhat easier by the increased numbers of incoming slots made available as the attackers connections timeout. Yes an attacker can simply relay some high-fee transactions to keep their nodes from being kicked off, but in that case are they really an attacker? I reject the argument that we are letting them de-randomize the structure of the network because as I've shown they can already do that with little expenditure. For SPV nodes again in the absense of an attack such anti-DoS code has no effect. When an attack is launched the SPV client can simply create some high-fee transactions with their own coins to get connection priority. SPV nodes already have serious privacy issues, so I don't see the creation of transactions as a big deal. Re-use is an issue, but nodes can take into account how long it takes for another nodes to advertise the transactions when dealing with SPV peers. Better systems can be implemented later, such as micropayment channels and coinbase probabalistic payments, that don't result in blockchain transactions just for the sake of anti-DoS. A demo of the attack against would be useful. Pieter Wuille's bitcoin-seeder code could probably be re-used as it already has the required functionality of making large numbers of connections. In fact, simply running multiple instances of it could do the trick. -BEGIN PGP
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Jun 28, 2013 at 9:05 AM, Mike Hearn m...@plan99.net wrote: I see some of the the other things that were concerning for me at the time are still uncorrected though, e.g. no proxy support (so users can't follow our recommended best practices of using it with Tor), Yeah. That's not the primary privacy issue with bitcoinj though. I'm much, much more concerned about leaks via the block chain than the network layer. Especially as Tor is basically a giant man in the middle, without any kind of authentication you can easily end up connected to a sybil network without any idea. I'd be surprised if Tor usage was very high amongst Bitcoin users. Tor does not act as a particularly effective man in the middle for nodes that support connections to hidden services because while your connections to standard Bitcoin nodes go through your exit node, the routing path for each hidden service peer is independent. Having said that we should offer modes that send your self-generated transactions out via Tor, while still maintaining non-Tor connections. Anyway Sybil attacks aren't all that interesting if you are the one sending the funds, and receivers are reasonably well protected simply because generating false confirmations is extremely expensive and very difficult to do quickly. After all, you always make the assumption that nearly all hashing power in existence is honest when you talk about replace-by-fee among other things, and that assumption naturally leads to the conclusion that generating false confirmations with a sybil attack would take more than long enough that the user would be suspicious that something was wrong long before being defrauded. I'd be surprised if anyone has ever bothered with a false confirmation sybil attack. I wouldn't be the slightest bit surprised if the NSA is recording all the Bitcoin traffic they can for future analysis to find true transaction origins. Which reminds me, again, we need node-to-node connections to be encrypted to at least protect against network-wide passive sniffiing. Regarding usage I would be interested to hear from those running Bitcoin nodes advertising themselves as hidden services. It's not a library limitation anyway, it's a case of how best to present information to a user who is not familiar with how Bitcoin works. Safe and Not safe is still a rather misleading distinction given the general absence of double spends against mempool transactions, but it's still a lot more meaningful than 2 confirms For what it is worth I ran a double-spend generator a month or so ago against the replace-by-fee node that Peter setup and I found that a small number of the double-spends did in fact appear to be mined under replace-by-fee rules. Specifically the generator would create a transaction from confirmed inputs, wait 60-180 seconds (randomized) to allow for full propagation, and then create a double-spend if the transaction hadn't already been mined. The transactions were randomized to look like normal traffic, including occasional bets to Satoshidice and similar for fun. (for the record the script had no way of knowing if a bet won and would happily attempt to double-spend wins) Fees for the replacement were power-law distributed IIRC, with some occasionally set to be quite hefty. Though possibly just an artifact of unusually slow transaction propagation it appeared that about 0.25% of hashing power was following replace-by-fee rules. (not including transactions involving gambling, I know Eligius and perhaps others block such transactions from their mempools making double-spends easy to accomplish by including Satoshidice outputs) I'm actually surprised by that figure myself given Peter Todd and I haven't made a serious attempt yet to get miners to use replace-by-fee rules. An interesting experiment would be to advertise that money is being given away by such a tx generator in the mining forum, although I would prefer to see solid mempool support for the scorched-earth double-spend countermeasure first; Peter sounds like he has some great ideas there, although as usual I am seeing very little in the way of code. :) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJRzWCOAAoJEEWCsU4mNhiPwhgH/ic/OJMCYwdIuEM2ArSAEQRY l5bqafMYMcC/KE9xqZ1HVkLJ9Zg57MQ8VZw95WOsmRgNA0v1xIoCyREjI84QkCIq R/hOgS97eJc+XXnPBVoB4Jadq5LQ6jNpJo7cmiLJjCEmE6rTxLZBBT4P3eQw8oIn WAd7X7utP7/QAkjhaWB9FsfWT8QZseqpSPv8WucRftsRCABurzuD+eSfpRqYwk2z XBD0zO+EyAtu6hB3dRAFhqnhVfEcOLJCtXpm76WO574H4AZ/8EN+HozLJSUtylCq j1NZnpj/6pdFh2v5Pid4HEMEvuNNX60u6iXGJ560PUsdKmOh+LEhUBLKd9acJTw= =QtjI -END PGP SIGNATURE- -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net
Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Thinking about this a little more, I guess it does not hurt to build some kind of voting system into the clients. But I think it's more useful for straw polls. For example a bug fix 100% of people should agree on. A protocol optimization perhaps 80% would agree on. A protocol change that redistributes wealth or incentives perhaps only 60% will agree on. At this point in time it's far too easy to deliver contentious changes into the hands of the general population. I think that fortunately we're blessed with a very strong dev team, but the fundamental philosophy of bitcoin is to not put too much trust in single point, but rather, to distribute and diversify trust to the edges. I disagree entirely. Your example of straw polls for bug fixes and features is precisely what the current method of rough consensus and running code, an IETF expression, handles just fine. What the method does not handle effectively are issues that are fundementally political rather than technical in nature. Blocksize is precisely the latter because while the tradeoffs are technical in nature the fundemental issue at hand is what do we want Bitcoin to be? Who are we going to allow to participate? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJRzWR7AAoJEEWCsU4mNhiPEYsIAME+VvS4vfE0PdOMv3vHWGSH HwUJdtKPold4+p0jhPBKSMbgnpMvXsZezMIIxj8xehnblnVuUdyakibXAdgVNLvp a6SCw+W/VnopYCw151zZ4FQS92KQuSbX+XmYTQy32oqZIXtBmTE1fydw5q6YhoXb gCCygPRyLTIQxLZAxqqRrQ0nsSE5ID5kDcr+xRsmCvfIKrzoOCbYL+nXPCB4Zzgu Gs7Lfa0yfTrUlQmoDseyoWrVuhfYuFNesTAs3z6imMTdHqZh8Z+a+gmC+G9qFO1h y7hOmzW4oz7hH4R2F6M+UpV6rKdwMaNYwrDw5eHClDgGYNfjjVduQ/YMQnbjyAc= =5mhd -END PGP SIGNATURE- -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, Jun 27, 2013 at 6:41 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Thu, Jun 27, 2013 at 11:04 AM, Luke-Jr l...@dashjr.org wrote: On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote: * Very real possibility of an overall net reduction of full nodes on P2P network Even a reduction of *nodes at all*, as I've never seen a listening bitcoinj or MultiBit node. :/ Jim, will MultiBit be adding p2p listening support? Without validation listening isn't currently very useful. :( Maybe it could be somewhat more with some protocol additions. Possible non-validation data that can be usefully propagated: 1) Block headers. 2) *Confirmed* transactions linked to an aformentioned blockheader. 3) Proof-of-work/sacrifice limited P2P messages, for instance to co-ordinate trust-free-mixes or act as a communication channel for micropayment channels. 4) With UTXO existance proof support propagate transactions accompanied by proofs that all inputs exist. This would also allow for implementation of Peter's low-bandwidth decentralized P2Pool proposal. 5) UTXO fraud proofs. (one day) Strictly speaking #2 doesn't even need the protocol to be changed actually as it can be handled entirely within the existing INV/getdata mechanism. Sure someone could throw away a lot of hashing power and get an invalid block propagated, but really so what? SPV nodes should always take confirmations with a grain of salt anyway. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJRzWx8AAoJEEWCsU4mNhiPlTkIAJKzFsT65o6LoU70hbaBsu3g aBdjYZSCnJ9+qWI2tqqUBedq2etbt71hAfWNnTXvFus+0iVB1HWJClW155319vuH Xi1m9G3O0NzX1d+cssMPxFBHsl4Rz6XYICrYyVEe2X554Zawdg6I53+1INHRfsBT 1vmq5Bxgopt0Tk9Vf8HNdRt/IXZJaPYm1PEzJHFppuOvl5+Fpypy3t/QXdsP8puP LnRdL7Bxfu3BSWrSRZo7l5Fpww3Y/vdNYCL4jDD/ME+36wi4CUM3psL8lsk81lB4 3t/ytF4y/adT/dEEtMj7BGWS0TIMMH0NyeCjqBdStiQsVfoowLCVfpuDzouZ6yY= =TI1m -END PGP SIGNATURE- -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Jun 10, 2013 at 5:43 PM, Peter Todd p...@petertodd.org wrote: On Mon, Jun 10, 2013 at 01:25:05PM -0400, Alan Reiner wrote: to sign votes. Not only that, but it would require them to reveal their public key, which while isn't technically so terrible, large amounts of money intended to be kept in storage for 10+ years will prefer to avoid any exposure at all, in the oft-chance that QCs come around a lot earlier than we expected. Sure, the actual risk should be pretty much non-existent, but some of the most paranoid folks are probably the same ones who have a lot of funds and want 100.00% of the security that is possible. They will see this as wildly inconvenient. Solving that problem is pretty easy actually: just add a voting only public key to your outputs. Specifically you would have an opcode called something like OP_VOTE and put a code-path in your script that only executes for that specific key. Rather than OP_VOTE all you really need is the spending tx matches a template functionality that has been proposed for many other things. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJRvLIoAAoJEEWCsU4mNhiPdtoIAKOeEwtWXw6fNKbSN0miGmcQ rHxgoEh5EAPsbs0hkCRpsVF7OjvmAftOn0Z0K0X/a4UFVHI64bvvGUg0brmAMnh3 ha4Mu/o7UwxwVJmmd6vpUw4smjbQrKbRzheXXQKUsDG2HOmRzMabFjJG1F20mPdg RobwYG49fKLcjAfqqTjOwSQE5KBjrugAUo32OUJWHZyNR5E3JYUXRHseHCfQ+1Fd VOQ8rWA4OaqwiX7PXdrNMWXc7Ab1dK7j9U7n4FgzCGIJjAek2dGbYLdrjftGKI+z Vje7o/RCJFLkJW5cC/wDoB/58XyJuvsvGOBAjvz01UrengUiapkhLRjKQwbveEo= =P0Hm -END PGP SIGNATURE- -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 It has been suggested that we leave the decision of what the blocksize to be entirely up to miners. However this leaves a parameter that affects every Bitcoin participant in the control of a small minority. Of course we can not force miners to increase the blocksize if they choose to decrease it, because the contents of the blocks they make are their decision and their decision only. However proposals to leave the maximum size unlimited to allow miners to force us to accept arbitrarily large blocks even if the will of the majority of Bitcoin participants is that they wish to remain able to validate the blockchain. What we need is a way to balance this asymetrical power relationship. Proof-of-stake voting gives us a way of achieving that balance. Essentially for a miner to prove that the majority will of the poeple is to accept a larger blocksize they must prove that the majority has in fact voted for that increase. The upper limit on the blocksize is then determined by the median of all votes, where each txout in the UTXO set is one vote, weighted by txout value. A txout without a corresponding vote is considered to be a vote for the status quo. To allow the voting process to continue even if coins are lost votes, including default votes, are weighted inversely according to their age in years after 1 year. IE a vote with weight 1BTC that is 1.5 years old will be recorded the same as a 1 year old vote weighted as 0.67BTC, and a 1 day old and 6 months old UTXO are treated equivalently. The 1 year minimum is simply to make voting required no more than once per year. (of course, a real implementation should do all of these figures by block height, IE after 52,560 blocks instead of after 1 year) A vote will consist of a txout with a scriptPubKey of the following form: OP_RETURN magic vote_id txid vout vote scriptSig Where scriptSig is a valid signature for a transaction with nLockTime 500,000,000-1 spending txid:vout to scriptPubKey: OP_HASH160 H(OP_RETURN magic vote_id txid vout vote) OP_EQUAL vote_id is the ID of the specific vote being made, and magic is included to allow UTXO proof implementations a as yet unspecified way of identifying votes and including the weighted median as part of the UTXO tree sums. (it also allows SPV clients to verify the vote if the UTXO set is a Patricia tree of scriptPubKeys) vote is just the numerical vote itself. The vote must compute the median, rather than the mean, so as to not allow someone to skew the vote by simply setting their value extremely high. Someone who still remembers their statistics classes should chime in on the right way to compute a median in a merkle-sum-tree. The slightly unusual construction of votes makes implementation by wallet software as simple as possible within existing code-paths. Votes could still be constructed even in wallets lacking specific voting capability provided the wallet software does have the ability to set nLockTime. Of course in the future the voting mechanism can be used for additional votes with an additional vote_id. For instance the Bitcoin community could vote to increase the inflation subsidy, another example of a situation where the wishes of miners may conflict with the wishes of the broader community. Users may of course actually create these specially encoded txouts themselves and get them into the blockchain. However doing so is not needed as a given vote is only required to actually be in the chain by a miner wishing to increase the blocksize. Thus we should extend the P2P protocol with a mechanism by which votes can be broadcast independently of transactions. To prevent DoS attacks only votes with known vote_id's will be accepted, and only for txid:vout's already in the blockchain, and a record of txouts for whom votes have already broadcast will be kept. (this record need not be authoritative as its purpose is only to prevent DoS attacks) Miners wishing to increase the blocksize can record these votes and include them in the blocks they mine as required. To reduce the cost of including votes in blocks 5% of every block should be assigned to voting only. (this can be implemented by a soft-fork) For any given block actual limit in effect is then the rolling median of the blocks in the last year. At the beginning of every year the value considered to be the status quo resets to the mean of the limit at the beginning and end of the interval. (again, by year we really mean 52,560 blocks) The rolling median and periodic reset process ensures that the limit changes gradually and is not influenced by temporary events such as hacks to large exchanges or malicious wallet software. The rolling median also ensures that for a miner the act of including a vote is never wasted due to the txout later being spent. Implementing the voting system can happen prior to an actual hard-fork allowing for an increase and can be an important part of determining if the
Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Jun 10, 2013 at 4:44 AM, Edmund Broadley rebr...@gmail.com wrote: I really like this idea. I also like that users with no clue will leave their vote to the default chosen by the software developers, which hopefully will be 1MB. I like how coin age is factored in do votes are hopefully proportional to bitcoin assert ownership. The default should *not* be set by wallets at all in fact. The default is that by not voting, you accept the status quo, which is defined as the mean of the old and new limits in the past year. So lets say the limit is 1MB, and through voting it ends up at 2MB in one year. Until that time by not voting you are in effect voting for the limit to be 1MB, but after the next interval you not voting is equivalent to voting for a 1.5MB limit. A subtle issue is then txout age, and at that point a 1.5 year old txout should be like voting for the 1MB limit still, albeit weighted less. What you don't want is your lack of vote to suddenly turn into a 1.5MB vote. This makes sure that at all levels the increases are gradual rather than abrupt, although the rate of increase may still be quite fast if the community votes that way. (first derivative of the limit is a close approximation to a continuous function) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJRtV0iAAoJEEWCsU4mNhiPRDIH+wapKxD0fc2div9gkhxZ4qVt 9Wh4u1vKM4RsxdPgh9uKFJomjErBXBROJ57cJqB1rwHt1xhUyHgbC8JstU0PWzUM Ygwgibe9nsSjqHp2w15Bat+NmkYpxrjmVhf9woZkPQl+A1bWd3MFXOGoTIPPCl3I KkMTaR3VbZDwqg0DlteZMR2im2DkT4zDsCkSb8KSCoaeTEdafkPceVHWU6isWxV9 Y0TGFCKaoMjxqxnkgH+vHsJlIM4E3rb0NHTo8rHD7Hm1txw/4/fVwE56/9U+8FaK XAPXS0gkIR83V7cWMLa/q6LpZyzJmfFXCZhjT4YxVqeq/wB/SR9j2hhNdLnjuCo= =y1c+ -END PGP SIGNATURE- -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I'm one of the people experimenting in this area. I've long argued that a zero-output transaction should be permitted -- 100% miner fee -- as an elegant proof of sacrifice. Unfortunately that requires a hard fork. Also, for most people, it seems likely that a change transaction would be generated. That, then, would generate an already-standard transaction, where inputs outputs. 100% miner fee is not a proof of anything because the miner could have created that transaction for themselves. You must have proof that all miners had an equal opportunity at collecting the fee, and the only way to do that is by Peter's announce-commit protocol, or his unspendable until after n blocks proposal. Also the idea of a zero-output transaction is silly. In almost all cases you are making the sarifice to link that act to an identity, and linking that act to arbitrary data is far more flexible than any scheme relying on the pubkeys that paid for the transaction. With a arbitrary data you can slice up the sacrifice for instance with a merkle-sum-tree, as well as hide what the sacrifice was for to preserve anonymity. The extra cost in size of the provably unspendable OP_RETURN scriptPubKey is minimal for the rare time when it isn't required. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJRrf/BAAoJEEWCsU4mNhiP7+MH/RGfo2k+Zd0VoGzv3KSTzBrM auK9Do2fYp2YvMnT/JFYbz2MgbTcCiKGyZfxjaH+zrqdTFgkgAE53midIv/Rd5/w kjjifJuqw5AyIN6ANA1TuLQ64elPOXXymsaMqWO8ou0angG6DBI/LZZEG7SXM7+I Jwk3MXLhFswvvuRif4G2C9v29WqSj4XRxxl3o63ziSYvZPPCHLYHAL9BJaMpDhaw LxebM088RofzJAoGL1QIeQhDS3aAK4jKSZtJ/6+fwYZQB2Qc3sa1v9IAcCQHE+M3 6oQY0tzEEFg9+xdnSM7J6pW7qW28nFS8Fdr6UkUUlwhI5c4KnIKCtQa3o1mYDFE= =SHWS -END PGP SIGNATURE- -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] merged mining hashcash bitcoin (Re: Coinbase TxOut Hashcash)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 - what about if a pool could lock the reward (rather than receive it or destroy it) eg some kind of merkle root instead of a public key hash in the reward recipient address field in the coinbase. Sorry I don't have time for a full reply due to some other commitments, but you remind me of an idea bouncing around to use a Merkle Sum tree as a way to split one sacrifice among an arbitrarily large set of users. Credit goes to Gregory Maxwell (according to the wiki) and the idea is to have the roots of the tree be account numbers (pubkeys here) and account amounts. He proposed it for off-chain transaction account ledgers, but the idea works equally well here to split some initial sacrifice into lots of little bits. For instance a on-chain sacrifice to an anyone-can-pay output could be split into enough parts to make it useful even when tx fees become large. Incidentally all this stuff about rivest paywords is probably silly, why not just commit your sacrifice to a pubkey and make signatures saying what your new balance is for each message and how much you intended to spend? This allows for easy fraud proof creation, and gives you a choice of either lying to some nodes, and getting poor propagation, or being honest and spending the amount you should have. For DoS protection it seems to me that mostly trusting nodes to give accurate balances, enforced with a fraud proof system to halt double-spending, is perfectly adequate. But no sense implementing so much complexity right at the start of the effort! Just a thought for where things can go in the future. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJRkaGUAAoJEEWCsU4mNhiPKsoH/1zhTBS/rINhF8oxxFoScD6i 0ybiUarIQEmmpAr3i46oMcSrw0SiOoiUzj6zvJorA21ddoErkTDVpMWI18RnKFos bTC4NVzvcegLdnbYb+76XKOCMc1dchFXq+WEGRdu/WKzOL7ODUUKAl/hG2Fk4lPU 3x8mHq0k2pqMAYX5/TX0w0pDnS227L+V1O3EoZD86MjR/CliHsZyBnXIqyqV4rY8 354JswKQ/XWb85gwZwFq1WXsFIZAep+eRVqmOluu3Ol97c5G85utNYDkg2hALURy gfpwmXKPFGm8h2lE1cMaOxkvQHOOPH8v7WdoBx08/ojhsyQNMpND4xej5FP/e5c= =vrFC -END PGP SIGNATURE- -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 32 vs 64-bit timestamp fields
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, May 8, 2013 at 11:44 PM, Peter Todd p...@petertodd.org wrote: Who knows? Satoshi used 32-bits and those fields can't be changed now without every single Bitcoin user changing all at once. (a hard-fork change) We'll probably need to do one of those eventually for other reasons, so we might as well leave fixing the timestamps until then. Perhaps Satoshi did this delibrately, knowing that at some point a hard-fork would be a good idea, so that we all would have a good excuse to do one? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJRivT1AAoJEEWCsU4mNhiPhxUH/271jtMvNrliZxFTvud282Dc snEieMig1p/HXy6ry1YLp+Q2k4Ya3QFFPlbsqHeTjL+NaJSGOHPBen4lpWahOH+T N6TQoOls7BMpQ7Y54Nqy5Qh9GeQnbDGcbQ8fBUfFqAF1Ljs0OBsbJtvC3vZTbYEn dwB+7dvPLGKVfz/yrR9wrLhDzoXHbG4C3sefqNnm+fkHHIuTy4nxwtVVMydlzerF Bwg1oc64dlul7sugBGXo2FjtGrxxkRxWWqj+dPgBnE/bDKIlemw34PtQZ2OK+IUS CH7Q0EGBnr7TpXJT5AOMkycd8v9MJ2wNIt4v3YLqyViQ48Q5coxAS0GepcRnbMU= =na4H -END PGP SIGNATURE- -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Service bits for pruned nodes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I think you too should ask yourself why you are putting so much effort into optimizing a centralized service, the DNS seeds, rather than putting effort into optimizing the P2P peer discovery instead. DNS seeds are a necessary evil, one that shouldn't be promoted with additional features beyond simply obtaining your initial set of peers. After all Peter, just like you have implemented alternate block header distribution over twitter, in the future we should have many different means of peer discovery. Right now we have DNS seeds, a fixed list, and IRC discovery that does not work because the servers it was pointed too no longer exist. Not a good place to be. Some random ideas: search engines - search for bitcoin seed address or something and try IP's found (twitter is similar) ipv4 scanning - not exactly friendly, but the density of bitcoin nodes is probably getting to the point where a brute force search is feasible anycast peers - would work best with UDP probably, who has the resources to set this up? It is probably not worth the effort implementing the above immediately, but it is worth the effort to ensure that we don't make the DNS seed system so complex and sophisticated that we depend on it. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBCAAGBQJRhU44AAoJEEWCsU4mNhiPtssH/1yb/FZRRaZpr3CwkoaOhbhu pxfRNWgOEOL/mlWKTVgp2812qEnY9DySpJ5DJMjx7/GhSvOtnteza5ts4+pbuWhd l6E1R9zAYxX+VOiBxcBtoZNEXDcS+CjMumuBH5S1v+L5jEntOWS9G8DKasjD2WAQ DzX8YbOuzIOqasEbr5Hpr9Vfl7ZtW/+q/sPhQ1q3a7n7MaaIZrZicisJw3z7T7+0 T0yK8vUdYfstTjs0zLzfI5PW9+TG5T0kvj0kXSCjnK723Mfl7SXp6UZx6yebBi6q tcTVOPo4hfBWk8XryZxaSNCkDYY6kryy5cb2V+BojVfqLWVKgR3pdZqXqnEKNLo= =0XFF -END PGP SIGNATURE- -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Service bits for pruned nodes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Apr 29, 2013 at 3:36 AM, Gregory Maxwell gmaxw...@gmail.com wrote: On Sun, Apr 28, 2013 at 7:57 PM, John Dillon john.dillon...@googlemail.com wrote: Have we considered just leaving that problem to a different protocol such as BitTorrent? Offering up a few GB of storage capacity is a nice idea but it means we would soon have to add structure to the network to allow nodes to find each other to actually get that data. BitTorrent already has that issue thought through carefully with it's DHT support. I think this is not a great idea on a couple levels— Least importantly, our own experience with tracker-less torrents on the bootstrap files that they don't work very well in practice— and thats without someone trying to DOS attack it. Unfortunate. What makes them not work out? DHT torrents seem pretty popular. More importantly, I think it's very important that the process of offering up more storage not take any more steps. The software could have user overridable defaults based on free disk space to make contributing painless. This isn't possible if it takes extra software, requires opening additional ports.. etc. Also means that someone would have to be constantly creating new torrents, there would be issues with people only seeding the old ones, etc. Now don't get me wrong, I'm not proposing we do this if it requires additional steps or other software. I only mean if it is possible in an easy way to integrate the BitTorrent technology into Bitcoin in an automatic fashion. Yes part of that may have to be finding a way to re-use the existing port for instance. We already have to worry about nodes finding each other just for basic operation. The only addition this requires is being able to advertise what parts of the chain they have. Sure I guess my concern is more how do you find the specific part of the chian you need without some structure to the network? Although I guess it may be enough to just add that structure or depend on just walking the nodes advertising themselves until you find what you want. We can build this stuff incrementally I'll agree. It won't be the case that one in a thousand nodes serve up the part of the chain you need overnight. So many I am over engineering the solution with BitTorrent. Using Bitcoin to bootstrap the Bittorrent DHT would probably make it more reliable, but then again it might cause commercial services that are in the business of poisoning the bittorrent DHT to target the Bitcoin network. Good point. Sadly one that may apply to the Tor network too in the future. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBCAAGBQJRfe1LAAoJEEWCsU4mNhiPuDgIAM1zz+ohlHgz37RgToQhInRc 1tv4Fnb6uGWyb4+U6UpK24LlXMFvOJsLm2czgbBc1Iz4z4wvb1m5IGw0ubJuV4mT GPUJhM4sNqfeKZlSWRw4Gia6Vk1jTkue+uVYvZn2vBS4SS6vYhYCC3zXIITyb2mp 7CVjcM84bTHKxIaMW1rIgmVJmfslsFdeNOp/cDVvkNl9+WvzWPeJ32BkT522p+pT AcPVFMsEJirYrXYi8HwdtGSeiG+mv0IemTAObJNPRrpw3x04ja6qecqzM51AkQ4t hPems5ShXM9FyDKFQNmtoC6ULpbd3CBBjsiQj0pp55epy6UC0eiUIXP8L9v0giM= =AOj8 -END PGP SIGNATURE- -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Anti DoS for tx replacement
Sorry I don't have time to reply more in depth, but I wanted to say to Jeremy (especially) and Peter I'm very impressed to see such a good design be created so fast that does not depend on replacement at all. This is a great example of how often the right approach to a problem is to accept that the easy solution will not work, and find a way to overcome the issue, rather than trying to paper over the easy solution's problems with insecure design. I'm reminded of Peter's work on fidelity bonded banking to overcome Bitcoin's scalability problem, although that needs to become real, and soon, so we can find all the flaws in it that will only become apparent when the idea is implemented for real. Jeremy: There does not seem to be a PGP key listed for your email address. Is that correct? On Sat, Apr 20, 2013 at 8:51 PM, Jeremy Spilman jeremy.spil...@gmail.com wrote: I was discussing this with petertodd a couple days ago and we were thinking the sequence I sent yesterday was usable today. I tried getting it to work on test-net but the final transaction closing the channel was not being accepted into the mempool beacause ERROR: CTxMemPool::accept() : inputs already spent But I was talking with sipa and gmaxwell on IRC about it, and sipa reminded me; Test-Net implements IsStandard() to allow the non-final refund TX into the mempool, but then doesn't allow it to be replaced, Main-Net implements IsStandard() to *reject* non-final transactions in the first place. Therefore, this actually will work on Main-Net today, since the refund TX won't even be allowed into the mempool until it's final, the AP is free to sign and broadcast its final TX without any replacement. Of course, if the AP waits too long, the user can get their Refund into the mempool and the AP's [higher seq] version will be locked out. This may be a case where Test-Net is in a bad state, by allowing non-final TXs into the pool, but not allowing replacement, you get an intermediate state which neither matches Main-Net behavior, nor implements behavior which would ever be deployed to Main-Net as-is. The current Main-Net behavior is actually very well suited for this application. Any application that can be reduced to two instances of a Tx, namely one non-final, and one final which is updated internally between the parties, works very well under the current Main-Net rules. If you set the nLockTime of the refund to be several days after the scheduled closing time of the channel, it would be quite challenging to get the Refund TX into the blockchain *despite* a final broadcast TX from the AP. Since the vast majority of Main-Net won't even accept it, the attacker would have to distribute the TX to any miner who could include the AP's transaction in a block between now and when the refund becomes final, and convince them all to not include the perfectly valid, fees paid, final, nSeq=MAX, nLockTime=0 transaction from the AP. Demonstrating that level of coordination would act substantially against the best interests of the miners, to say the least. This proposal still suffers from any malleability weakness, where the user's refund could be invalidated by a miner changing the TxID of TX1. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Anti DoS for tx replacement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Apr 17, 2013 at 9:48 AM, Mike Hearn m...@plan99.net wrote: So it'd be nice if this ended up not being necessary. Experience indicates that rational miners typically don't pursue a short-termist profit-at-any-cost agenda - free transactions have always been included in blocks, miners include transactions even though you could avoid a lot of complexity by just not including any at all, etc. Some miners like BTC Guild have actually sacrificed significant amounts of money for the good of the system. You can see this in terms of rational self interest - miners earn Bitcoins thus it's in their interest for Bitcoins to be as useful as possible, as that is what gives them value. Or you can see it in terms of ideologically-driven altruism. Or both. Please don't say Gavin agrees with you. This reminds me of discussing security in the early days of the internet when the general assumption that everyone played nice was still correct. We're seeing huge, expensive, DoS attacks against mining pools, exchanges, information sites, stores etc. Bitcoin has enemies. Peter Todd is 100% correct, tx replacement is another form of zero confirmation transaction and all that has to happen is some subset of mining power start doing replace by tx fee for it to have no security while with your proposed implementation opening up a DoS attack vector. You also see the DoS attack vector as unimportant and suggest to handle it as a prioritization problem. real world experience indicates that people don't pointlessly mount attacks over and over again if there's nothing to be gained by doing so. - of course there is something to be gained, shutting down a service dependent on tx replacement, as seen by all the DoS attacks we are seeing. If I were deciding if my service should use tx replacement and I understood that it could be trivially shut down, I sure wouldn't be happy I could just warn users not to take advantage of the feature whilst the flood is in progress Gavin do you actually agree with Mike on this stuff like he implies? Because if you do, I think people should know. Myself I wouldn't want to be contributing to your salary as a foundation member if you don't take Bitcoin security seriously. The rapidly-adjusted payments stuff on the Contracts page of the wiki is broken in multiple ways: 1. (known) Requires DoS vulnerable infrastructure. 2. (known) TX mutability 3. (unknown?) Just doesn't work. Step 5 is to check that T2 is signed correctly by the access point, and if so, sign T1 and T2. But the signature of T2 includes the txid of T1 and that isn't known until T1 is fully signed. That #3 has not been noticed before shows that for all this hot air no-one has ever bothered making an implementation of the idea. So Mike, why are you happy to make testnet vulnerable to an unusually easy DoS attack for an idea you haven't even tried on your own private testnet with replacement enabled? Anyway, with Peter Todd's much saner tx-replacement-by-fee the following can be done: 1. Create a new public key PK1 2. Request a public key PK2 from the access point. 2. Create TX1 with two inputs and two outputs. Both parties sign it and broadcast it. access point input - 2 PK1 PK2 checkmultisig, value = input #1 - fee you input - 2 PK1 PK2 checkmultisig, value == input #2 - fee 3. Create TX2. TX1 #1 - pay to access point PK2 TX1 #2 - pay to yourself PK1 (change) Set TX2 nLockTime to some time in the future. 4. Set the initial value's of TX2 out #1 and out #2 to the value the access point and you committed in TX1. Both parties sign with SIGHASH_SINGLE. (which means both parties are signing for both inputs) 5. Update TX2 as required and sign both inputs. The access point doesn't need to sign TX2 or give the updated copy of TX2 to the other party. The TX is not broadcast when updated (like the earlier contract proposal) although doing so harms no-one. When the session ends with both parties online, do the following: 1. You sign a version of TX2 with the final output values and nLockTime=0 2. If the final output values are acceptable to the access point, they sign the other half of the 2-of-2 inputs and broadcast. (with whatever fees required) If the buyer quits the session abruptly: 1. Access point signs the last (most funds) version of TX2 given to them, waits until the nLockTime expires, and broadcasts. This also gets their TX1 input back. If the access point quits abruptly they can do the above when they go back online. The buyer has the first, signed, version of TX2 and at worst can broadcast it eventually to get their deposit back. Attacks: After TX1 is signed and broadcast both parties are in on the contract together, so the funds can't move without the consent of the other. Both parties can block the movement of the other's deposit, but they lose their deposit too. With tx mutability there is a small window of time for a technical mistake, but that
Re: [Bitcoin-development] Anti DoS for tx replacement
I understand that Gavin has spent effort on security efforts against small-scale attackers. It's the fact that he is so dismissive of the threat that large attackers play that is what bothers me. But if I am being divisive I understand. I posted a clarification of what the reward is for exactly on the forums: https://bitcointalk.org/index.php?topic=179612.msg1881800#msg1881800 On Thu, Apr 18, 2013 at 8:14 AM, Peter Todd p...@petertodd.org wrote: On Thu, Apr 18, 2013 at 06:07:23AM +, John Dillon wrote: Gavin do you actually agree with Mike on this stuff like he implies? Because if you do, I think people should know. Myself I wouldn't want to be contributing to your salary as a foundation member if you don't take Bitcoin security seriously. FWIW Gavin has spent quite a bit of time and effort ensuring that Bitcoin is resistent to DoS attacks, as well as spearheading a move towards better testing. The latter in particular is helpful against chain-forking bugs, so better testing is very much a security issue. He also spearheaded P2SH, and the current efforts to get a payment protocol implemented. I'm less convinced about his stance against attackers that pose a threat to the system as a whole, but it's not fair to accuse him of not taking security seriously. Strict replacement by fee should be written so it can be tested properly and people in the Bitcoin ecosystem use proper security practices with regard to unconfirmed transactions. I'm willing to pledge $500USD to anyone who implements it. That is write the core functionality that does replacement by fee, and a simple 'undo' RPC command. I would do it myself but my programming is rusty. You should clarify if you want this patch to compute fees recursively or not, IE, should the patch include fees paid by child transactions in how it computes the total fee the transaction pays. Doing this is non-trivial, although Luke-Jr has written a patch to do this without replacement: https://github.com/bitcoin/bitcoin/pull/1647 Also, clarify if you want unit-tests and similar things included in the implementation. -- 'peter'[:-1]@petertodd.org -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
