Re: [Bitcoin-development] SPV bitcoind? (was: Introducing BitcoinKit.framework)

2013-07-18 Thread Mike Hearn
 The 90 minutes is not - the blockchain has grown quite a lot since last
 year, and as for the 3.5 speed, I havn't tested it since Pieter's
 ultraprune - libcoin also has something similar to ultraprune, done
 directly in the sqlite database backend, but I should run a head to head
 again - could be fun. I would assume, though, that the result would be
 similar timings.


ultraprune made a huge difference. I think it's very likely that this claim
is no longer true. Bitcoin got a lot more optimised since you first did
libcoin.
--
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] Anti DoS for tx replacement

2013-07-18 Thread Peter Todd
On Fri, Apr 19, 2013 at 06:48:11PM -0700, Jeremy Spilman wrote:
  0. User and AP negotiate how much to escrow, who pays the fees, and how
 far in the future nLockTime will be set (how long user’s funds will be tied
 if AP doesn’t close the channel)
 
  1. User creates an unsigned TX1 with 1 or more inputs from user’s
 ‘listunspent’, change going back to user (if any), and a single output of
 ‘FundAmount’ with scriptPubKey of ‘2 PK1 OP_0 CHECKMULTISIG’, and sends to
 the AP

Note that with OP_DEPTH we can remove the small chance of the payee
vanishing and putting the funds in limbo:

height + n OP_DEPTH OP_LESSTHAN
IF 2 PK1 PK2 CHECKMULTISIG
ELSE PK1 CHECKSIG
ENDIF

Though that shows how to implement OP_DEPTH as a true soft-fork we're
probably best off doing it as part of a script v2 using the soft-fork
mechanism I outlined before when talking about fidelity-bonded ledgers.
(best to do MAST (merklized abstract syntax tree) support at the same
time)

-- 
'peter'[:-1]@petertodd.org


signature.asc
Description: Digital 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] Anti DoS for tx replacement

2013-07-18 Thread Jeff Garzik
On Thu, Jul 18, 2013 at 7:13 AM, Peter Todd p...@petertodd.org wrote:
 Note that with OP_DEPTH we can remove the small chance of the payee
 vanishing and putting the funds in limbo:

What are the costs, benefits, and risks associated with scripts no
longer being stateless, as OP_DEPTH would seem to introduce?

-- 
Jeff Garzik
Senior Software Engineer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
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] SPV bitcoind? (was: Introducing BitcoinKit.framework)

2013-07-18 Thread Michael Gronager
Hi Bazyli,

I actually do my main development on Mac OSX, so it surprises me to hear - I 
build Xcode projects with libcoin daily on Mac OSX and linux, on Windows it is 
agreeable more of a fight to build. QT is really not needed, I kept it there 
for BitcoinQT, that was once part of the tree too, will remove it as the qt 
part got split out.

Building clean on Mac requires OpenSSL, BDB and Boost - all can be installed 
using homebrew, also remember to use the latest cmake, and a normal cmake xcode 
call: cmake -GXcode should do the job. Otherwise pls send me the debug output. 

A few quick notes for building stuff there:
 - try with coinexplorer, it is the base code I am using - it splits out the 
wallet from the server, nice if you e.g. want to build a webcoin like server.
 - The wallet parts from bitcoind I don't use personally, so if you have 
problems with these I need to have a closer look.

Also note that as the first version of libcoin was a direct refactorization of 
bitcoin, the current one add a lot of different features and handles things 
quite differently - you can e.g. lookup any unspent output by script (bitcoin 
address) in milliseconds (nice for web wallets).

Finally: 

   Because of the templates that bitcoind is actually using that's not 
 gonna work ever. That's why BitcoinKit is a separate dynamic library that's 
 compiled with gcc (or at least llvm pretending to be gcc ;P)

As I mentioned it also compiles on Linux (gcc) - gcc is quite savvy when it 
comes to templates - I agree that the template stuff from Database.h is quite 
involved, but as I mentioned before try with coinexplorer.

- I will try to do a from scratch recompilation to see if I experience similar 
issues...

Also - if you are good at creating frameworks on Mac OSX using cmake, help 
would be appreciated! I think that libcoin by defaults build using shared libs, 
this configurable from ccmake using the dynamic library option.

Thanks,

Michael


--
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] SPV bitcoind? (was: Introducing BitcoinKit.framework)

2013-07-18 Thread Michael Gronager
Hi Bazyli,

Just did a fresh build based on git (Xcode) - had one issue: the paillier and 
account tests were missing - please comment them out in tests/CMakeLists.txt, 
then coinexplorer should build nicely.

Note I did a git push as well, so you need to do a git pull first.

/Michael
--
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] SPV bitcoind? (was: Introducing BitcoinKit.framework)

2013-07-18 Thread Peter Todd
On Thu, Jul 18, 2013 at 08:13:08AM -0400, Peter Todd wrote:
 A more sophisticated approach would be possible if there existed a
 version of H() with a computational trap-door - that is if there existed
 H'(s, i)=H(i) where H' had significantly faster running time than H(),
 but required knowledge of a secret. Our peers would then be able to
 answer our challenges quickly only if they stored the intermediate
 results in a lookup table, while we could check those challenges cheaply
 without that table.
 
 Adam: you're our local crypto-expert, what can we use for H'? Seems that
 maybe some kind of asymmetric crypto system would work by requiring the
 peer to crack weak secret keys that we generate deterministicly.

Actually, come to think of it a really easy way to create H' is for the
node to create some expensive to compute set of data associated with
their identity. The data set is then stored once by the node, cheap, but
the clients have to store one set for every unique node they connect
too, expensive. A set of the function scrypt(k | i) for i in 0..n is an
obvious way to do it.

This can equally be used as a proof-of-work to make creating lots of
nodes expensive given a cheap way to verify the POW; easily done with a
non-interactive zero-knowledge proofs. It'd be nice if that POW could
incorporate blockchain data, showing that the identity had access to
that data and thus could have computed the UTXO set honestly. (the POW
should be incrementally extendable as new data becomes available)
However that is back to using a bunch of bandwidth at startup if our
peer doesn't have access to blockchain data, so both mechanisms would
probably have to be done independently. Note how we also make MITM
attacks on encrypted P2P connections expensive this way too even without
any form of authentication. (works best when the proof-of-work is
dependent on your IP addresses)

-- 
'peter'[:-1]@petertodd.org
00762784b647ede3678f172d73dd0c72c2180ab451b00d756959


signature.asc
Description: Digital 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] SPV bitcoind? (was: Introducing BitcoinKit.framework)

2013-07-18 Thread Mike Hearn
 SPV clients behaving normally are highly abusive: they use up maximum
 node resources with minimum cost to themselves.


This must be a new use of the word abuse I haven't come across before :)

At any rate, some of these assumptions are incorrect. Botnets of
compromised web servers are quite common, and asymmetry in node resources
is obviously biased against the kinds of devices people increasingly have
(phones, tablets) where extremely limited memory bandwidth is common and
apps routinely have just 16 or 32mb of memory to do everything including
the GUI.

A good anti-DoS strategy looks much the same as a good load shedding
strategy. There's little reason to treat them separately. Perhaps instead
of talking about DoS we should instead talk about what happens if Bitcoin
suddenly gets too popular. Now there are suddenly lots of good users all
wanting to use the network, and not enough nodes to support them all. What
do we do?

Some rules seem obvious - try to prioritise existing users over new users,
old coins over new coins (dPriority already does this) etc. If you run out
of TCP sockets prefer to disconnect recent connections (probably new users)
to long lived connections (probably high powered backbone peers). If you
run out of disk seeks prefer processing new blocks to serving old parts of
the chain, etc.
--
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] SPV bitcoind? (was: Introducing BitcoinKit.framework)

2013-07-18 Thread Peter Todd
On Wed, Jul 17, 2013 at 03:37:41PM +0200, Wendell wrote:
 Peter,
 
 This sounds like a _very_ good idea for a desktop client, and probably 
 acceptable to users so long as we take available disk space into 
 consideration, and only ever use a fraction of it.
 
 Will you implement this?

I've got one or two orders of magnitude more good ideas than I have time
to implement, but I will say this one would have a pretty big impact -
I'm considering it.

Of course, I would accept bribes. :) But in all seriousness I also
accepted funds from John Dillon to implement replace-by-fee, although
he's been good in understanding that the scope of the project was quite
a bit bigger than originally thought. (it turned out replace-by-fee can
enable very safe zero-conf transactions, but only with mempool and
relaying changes) I'd suggest looking at my git commit track record
before you offer anything FWIW; I've been much more of an academic than
a programmer.

-- 
'peter'[:-1]@petertodd.org
0013030f49fe3eed5e7f9388c4ecc237b7a847ca93255836bc3b


signature.asc
Description: Digital 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] SPV bitcoind? (was: Introducing BitcoinKit.framework)

2013-07-18 Thread Wendell
Heh, will do. If you have less confidence in your programming skills perhaps 
its best if you write documentation and we bring in someone else to do the 
heavy lifting? Maybe Eric Lombrozo would be interested in this, for example...

-wendell

grabhive.com | twitter.com/grabhive

On Jul 18, 2013, at 6:22 PM, Peter Todd wrote:

 I've got one or two orders of magnitude more good ideas than I have time
 to implement, but I will say this one would have a pretty big impact -
 I'm considering it.
 
 Of course, I would accept bribes. :) But in all seriousness I also
 accepted funds from John Dillon to implement replace-by-fee, although
 he's been good in understanding that the scope of the project was quite
 a bit bigger than originally thought. (it turned out replace-by-fee can
 enable very safe zero-conf transactions, but only with mempool and
 relaying changes) I'd suggest looking at my git commit track record
 before you offer anything FWIW; I've been much more of an academic than
 a programmer.



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
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] SPV bitcoind? (was: Introducing BitcoinKit.framework)

2013-07-18 Thread Peter Todd
On Thu, Jul 18, 2013 at 06:46:16PM +0200, Wendell wrote:
 Heh, will do. If you have less confidence in your programming skills perhaps 
 its best if you write documentation and we bring in someone else to do the 
 heavy lifting? Maybe Eric Lombrozo would be interested in this, for example...

I have plenty of confidence in my programming skills, I just don't have
very much evidence in the Bitcoin git history to convince you my
confidence is well placed. :)

I do have a day job I love, so it will certainly get done faster if you
can get someone else to do the actual coding; I'd be willing to write
the specifications and supervise/audit/advise for a few hours a week.

 -wendell
 
 grabhive.com | twitter.com/grabhive
 
 On Jul 18, 2013, at 6:22 PM, Peter Todd wrote:
 
  I've got one or two orders of magnitude more good ideas than I have time
  to implement, but I will say this one would have a pretty big impact -
  I'm considering it.
  
  Of course, I would accept bribes. :) But in all seriousness I also
  accepted funds from John Dillon to implement replace-by-fee, although
  he's been good in understanding that the scope of the project was quite
  a bit bigger than originally thought. (it turned out replace-by-fee can
  enable very safe zero-conf transactions, but only with mempool and
  relaying changes) I'd suggest looking at my git commit track record
  before you offer anything FWIW; I've been much more of an academic than
  a programmer.

-- 
'peter'[:-1]@petertodd.org


signature.asc
Description: Digital 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