Re: [Bitcoin-development] Even simpler minimum fee calculation formula: f bounty*fork_rate/average_blocksize

2013-11-13 Thread John Dillon
-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.

2013-10-28 Thread John Dillon
-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

2013-10-28 Thread John Dillon
-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...

2013-08-18 Thread John Dillon
-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...

2013-08-18 Thread John Dillon
-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

2013-07-28 Thread John Dillon
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.

2013-07-14 Thread John Dillon
-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

2013-07-14 Thread John Dillon
-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.

2013-07-14 Thread John Dillon
-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

2013-07-14 Thread John Dillon
-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

2013-07-14 Thread John Dillon
-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

2013-07-14 Thread John Dillon
-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

2013-06-28 Thread John Dillon
-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

2013-06-28 Thread John Dillon
-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

2013-06-28 Thread John Dillon
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, Jun 28, 2013 at 10:20 AM, Mike Hearn m...@plan99.net wrote:
 I suspect what you saw is mining nodes restarting and clearing their
 mempools out rather than an explicit policy of replace by fee.

Possibly, but it is a rather short window of opportunity and the mining node
would have to be connected directly, to Peter's replace-by-fee node. I also
took care to ensure transactions were only ever broadcast once. (I disabled the
wallet rebroadcast mechanism)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBCAAGBQJRzWYWAAoJEEWCsU4mNhiP3fIIAJLFxMnjI4BGRrNLsxs0hXp0
zDCgiZ6UnZa5JRcd/6KjV3hnPHwweGEjChGfrzY/Fxo4Pga1lQFlp8E8PaFUJq50
r6LTNJQLW50r5mFkZ6Mkh877WwX/OHBzkp8SqbbD7+dDBV7R9LqLYqLTHgObKxg1
V9UjGRJiMohW8HLdOzEXOz1ugoBCjR+vyQW5ZD2nZVcQlIhxSIgeC/M46oxMN7pE
Y5EepCQehNPuc1On7TtJ9LlmFJ6Dvsl6dqwKNWMi1lgBTiw7abdTJne2B/KeDyom
vhGuhmpMLGKKgJns3hne3yQM+Ivi3jLIHKejcoCm1JkSCdjw48XkyGd0V359M3w=
=qyyq
-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

2013-06-28 Thread John Dillon
-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

2013-06-15 Thread John Dillon
-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

2013-06-09 Thread John Dillon
-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

2013-06-09 Thread John Dillon
-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

2013-06-04 Thread John Dillon
-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)

2013-05-13 Thread John Dillon
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, May 11, 2013 at 10:22 AM, Adam Back a...@cypherspace.org wrote:
 I didnt quite understand the writeup and the references were ambiguous.

No you didn't. :)

What is special about what Peter is proposing is that it is *not* merge-mining.
You see, merge-mining is essentially where you use one PoW for two purposes,
two different blockchains. So you are getting more value from just one unit of
work.

But Peter's coinbase hashcash protocol carefully ensures that the act of mining
the hashcash is guaranteed to cost the miner at least some well-defined amount,
and that amount can be easily calculated by considering the probability that a
block could have been found with the effort required to generate the proof of
work, and the amount of value the miner would have then given away in a
anyone-can-spend output. (you may not realize this, but a scriptPubKey with a
single pushdata opcode is always evaluated as true, which means it can be
respent by anyone)

Don't feel bad though, I had to ask him to explain it to me too. :)

 Rivest's PayWord for people who dont know the reference in this context is
 the observation that for a low value micro-payment, you dont mind if you
 only receive a payment 1 time in k so long as the expected payment is n
 after receiving n (eg satoshi sized) payments.  Eg like a penny tip jar so
 long as your expected payment is correct long term (win as often as you
 lose) you dont mind.  And a fair 100% payout lottery can be fun of itself.

I think you are misremembering. I just checked the paper and PayWord is based
on chains of hashes and you give the receiver a digest and if after n repeated
hashes it is considered to have been worth n*k It is not a probabalistic
scheme.

Incedentally while it is an obvious enough idea, though I didn't see a
reference to it, PayWords can be easily extended with a time-bandwidth
trade-off by using a structure similar to a merkle tree. The roots could be
created from some fixed nonce K and a increaing integer, H(K | n) Then you
would provide a merkle path to the previously agreed upon final digest. So
proof size for your payment would be log(n), and time to check the proof
log(n). Unfortunately setting up the scheme is still 2*n however that only
needs to be done once.

 So let say each email client sends in an email header the head of the

I have to respect a man who after all these years is still thinking
about anti-spam for email. :)

 Maybe one can put the bitcoin hash in DNS with a 5min TTL and have mail
 clients read that to reduce scope for stale mining.

Peter actually made a blockchain headers over DNS system, and a blockchain
headers over twitter system as an April fools joke. See
https://twitter.com/blockheaders

 In this way one can merge mine bitcoin  hashcash to the benefit of the
 recipient (or some beneficiary trusted not to be paying the proceeds to the
 spammer).  And in a way that scales to email scale, and does not involve
 installing a bitcoin client in every client, nor mail server.

Blockchain header data may very well be one of the most widely distributed
single data sets in the history of mankind, and most of its closest cousins are
definitions such as the ASCII table or near definitions like the DNS root
servers. Not something with new data every 10 minutes.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBCAAGBQJRkJZoAAoJEEWCsU4mNhiPtscIAL4eM+reWCfAjw0FAv5c5lwQ
tJvuVgmkCVyVurQLFbMt0hxXiYAFeTJ31uW0QBEdvitzIUAWR4QO/wfqNULAdZoA
RzTCOBTjfFFGQLd7UdRuDSSEvq23oeJCoixbtdGpAmM1ySRvCExkO+fYehNqXEDN
FF1PVv9VPc5KXbDw3mB6l8dkMCLEHmYpkdrNRvHHQMhyLXO8q3Q6H3zDy3YbztZC
rxibYprOtF1Z2dZzIYTWaGoA9ONLqSgOU2J1htj6kastsjW1d3XKIkdU/eRP2cEs
CG2EWyyrm59e4zpYL4BJj0zBMW9+pQQsSvrAtAoAFVdLojsAWBVL0PIQ8h8N6SY=
=+ptH
-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] merged mining hashcash bitcoin (Re: Coinbase TxOut Hashcash)

2013-05-13 Thread John Dillon
-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] Discovery/addr packets (was: Service bits for pruned nodes)

2013-05-08 Thread John Dillon
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

  You mean scam you with a zero-conf transaction that hasn't actually been
  broadcast?

 Yeah. Or just scam you at all. It's hard to imagine an organisation as
 a big as a mobile carrier engaging in financial scamming (roaming fees
 excepted).

Unless the government told them too.

 I've said this before, but I think it's worth repeating. The
 double-spend protection the block chain gives you has a sweet spot
 where it's really, really valuable (essential even) and then there are
 lots of kinds of transactions on either side of that sweet spot that
 don't really benefit from it.

 Obvious/trivial case where you don't need a block chain - Facebook
 buys Instagram for a gajillion coins. The legal system is plenty good
 enough to ensure the payments are honoured. Another example, when my
 employer pays me my salary. They aren't going to double spend this
 except through some horrible accident that we can get sorted out some
 other way.

The employer example actually shows something important: between a worker and
an employer double-spending already irrelevant. People get paid after they work
their two weeks not before, so the double-spend is already irrelevant.

However when your employer pays you on the blockchain until the transaction
confirms for someone else to accept funds from that payment they not only have
to trust you, but also the employer. Sure they could take it as you said you
would apy me so it is your responsibility to make that happen but that brings
a whole new level of complexity.

A scheme where you vouch for your payments with your identity can benifit from
being able to follow that chain all the way back to the last confirmed
transaction, although actually implementing this may be too complex to be
worthwhile, especially initially.

 Another case, very small payments. This is Satoshi's bag of crisps
 example. If the cost/complexity of double spending is higher than what
 the payment is worth, again, you don't really need the block chain.
 That's why it's worth optimising unconfirmed transactions to be harder
 to double spend, it optimises (pushes up) that lower bar.

Yes. But the issue is how are you going to optmize it? By adding yet more
restrictions and limitations on those who chose to run a node or mining
operation, or by actually fixing the trust issue? We know you can do the
latter, so do not sacrifice Bitcoin's core layer in silly attempts to make
double-spends harder. Fundementally Bitcoin has exactly one way of achieving
consensus, and that is the blockchain.

It must be your right to chose what transactins you chose to mine and chose to
relay. End of story. Bitcoin is not about imposing regulation on those who
choose to use it.

 Place where you really want the chain - largeish sums of money are
 moving around, but not large enough to justify expensive
 cross-jurisdictional legal action, or where the cost of identity
 verification and all the associated paperwork is just too high. I
 guess most online transactions fall into this bucket today.

Indeed. Especially for the most popular use of Bitcoin as a payment system:
buying things PayPal won't let you. In that circumstance the only leverage you
have is the protections of the blockchain and the damage you can do to the
other (often anonymous) parties reputation.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBCAAGBQJRivRcAAoJEEWCsU4mNhiPoJcIAL7T/x5gipsCNn/w3EfhZhKo
iukP0Kc3cni/Kb6gJrOlXufIxDrX8QxEhbIIrypFbyg+xHPK8NzSd13ScKNtLgjM
w2uOI/IkgUh7VLIEZADqLO3TM5S5VDZ/A42yzTIq8MeWxaTBD1JulOc/RbljGu8V
UrF6ptxu2UXTc0eXcor1lHfJRVteTJAAba5Awa1EAHX8f2c/1FhdrnOZwfLVJIfK
/nnUgqGKc8l08knC6NnAlP39zbk/FHiZF/keWIFIzhiyXTnqKnqD096tIx6MpPci
LGafjCoXACpr1XeiSufER/z6WxTvOvCbWRw4MYrbyRkmChqMtc8a7RMEPLXhaMQ=
=Oh/p
-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] 32 vs 64-bit timestamp fields

2013-05-08 Thread John Dillon
-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] 32 vs 64-bit timestamp fields

2013-05-08 Thread John Dillon
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, May 9, 2013 at 1:13 AM, Pieter Wuille pieter.wui...@gmail.com wrote:
 On Wed, May 08, 2013 at 09:08:34PM -0400, Jeff Garzik wrote:
 Guffaw :)  The year 2038 is so far in the future that it is not really
 relevant, from that angle.

 Meh. I think it's highly unlikely we'll break the block header format, as it
 pretty much means invalidating all mining hardware.

Doesn't most mining hardware at the ASCI level start with a SHA256 midstate
given that the nonce is at the end?  Adding further information to the block
should be possible at the beginning of the block without major changes to the
mining hardware.

 There's also no need: 32 bits is plenty of precision. Hell, even 16 bits would
 do (assuming there's never more than a 65535s (about 18 hours) gap between two
 blocks). Just assume the full 64-bit time is the smallest one that makes
 sense, given its lower 32 bits.

I feel somewhat uncomfortable about the after-the-fact auditing possible in
this scenario. Besides the timestamping provided by the block headers appears
to be useful in some payment protocols, not to mention in general.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBCAAGBQJRivnmAAoJEEWCsU
4mNhiPUIYH/AlxK4DHvIdq0khNH0nfK65E
F1ZyYZTGLNHKqrJLCU2kc7zteGadQuccmFsYpmViIr14tzpU7xMImUHpj7fEHO3R
S/1zy59rx2+VYcevYdwMDTywanjeForRpli93Hz570GfwfG/D7VPejfLo6iq5dOt
EG5m3Z8F7wNzWBmfBYBHKLrNBJe6iw0qJ2nNiHXcELt6gaqG3C9wI9NAPtQWQKjB
57h7yTnFCRmjA3HDdCe2s0FVJgRP5cJqz3e62qZrY/BRmw/Vrx8ExuX1LJFqUx3k
5tg+BxXH4DJbNIojuq9lLl5lWxKOI1iSJJuCAixo/6s/manLFggJv7KtYgzhhjI=
=BxDb
-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] 32 vs 64-bit timestamp fields

2013-05-08 Thread John Dillon
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, May 9, 2013 at 1:57 AM, Peter Todd p...@petertodd.org wrote:
 Remember that interpreting the timestamp on a block for the purposes of
 timestamping is a lot more subtle than it appears at first.

I actually just meant how Pieter Wuille was talking about a blocktime accurate
to only within 18 hours. :) But it is a nice writeup!

In any case, for many things simple relative ordering is enough rather than
absolute time.

 There are two types of timestamps possible: proofs that data existed
 before a time, and proofs that data existed after. With the former type
 the *later* the proof says the data existed, the more conservative the
 assumptions behind the proof. So simply adding two hours to the block's
 timestamp is relatively reasonable. (this assumes the attack managed to
 mine a single block, and all nodes have accurate clocks)

Nope. The attacker can make the timestamp on the block they mine as little as
the minimum from GetMedianTimePast(), and adding two hours to that number could
easily be well before true time.

What you probably need to do is some sort of median time calculation for the
blocks around your timestamp. The proof becomes probabalistic based on the % of
hashing power the attacker controls and in turn depends on if the time they
created their timestamp was of their own choosing.

IE, if you just want to create an inaccurate timestamp, but don't care when,
you can just mine blocks and wait until you get lucky. If you need to create an
inaccurate timestamp *now* the problem is much harder.

But all this analysis can be developed later, and data timestamped now. :)

 Back to the block header time... Frankly, the easiest thing to do is
 just have a flag day where blocks after a certain height are considered
 to have a different epoch from the standard 1970 one when computing
 their time. Boring, but it works fine and only needs to be updated every
 few decades.

Oh, right, yes, that is a much more simple idea and far less prone to bugs.

Many SPV clients wouldn't even need upgrades if they don't acturally validate
the blocks they receive and just look for the biggest PoW.


 You're midstate idea is very clever though and could come in handy in
 the future for different purposes. Eventually we should discuss this
 with the ASIC manufacturers - if it can be implemented as a firmware or
 FPGA upgrade in the field all the better.

Yes


Anyway, you are being distracted from what we were talking about before, get
back to work!
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBCAAGBQJRiwrGAAoJEEWCsU4mNhiPvYAH/3kjlg5diWeyYUJlKPKRpygQ
XAU8a2D3h9bABacmmhx5yW3AmtV0QqLgKlB76t41JB4O6Jer5FT8tBBwPnjDijtI
KrBWwPqNhVZiyTSDZQTF6BR1a0DDCZVtOXlpOTj6NL1+hy7NYTYsqxAVzS8QgZUH
RXt7QTYGrrmMbmm75NdWhK59mbv22UEaDHfDW0qqgSzdb7f1EQv1fou3MfKScQSd
7OsGU3k5PM+KQ/FGBy+r+07GY5yj85YMooGky0MCjtkOiU/qr+pxfs1uT2R8/512
TyZxzn1vtgWUEGOUeMCml+bgjUOvOgcIvAarzZmyLyAAY15S/LT8MvAr2RUjAfY=
=UDyE
-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

2013-05-04 Thread John Dillon
-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

2013-04-28 Thread John Dillon
-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

2013-04-23 Thread John Dillon
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

2013-04-18 Thread John Dillon
-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

2013-04-18 Thread John Dillon
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