Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining

2013-07-15 Thread Peter Vessenes
I'm at the Aspen Institute right now talking about Bitcoin and I mentioned the perils of starting an alt-chain based on proof of work that pool operators might attack; funny synchronicity! Peter On Mon, Jul 15, 2013 at 2:29 PM, Peter Todd wrote: > On Mon, Jul 15, 2013 at 03:05:52PM +0200, Jorg

Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining

2013-07-15 Thread Peter Todd
On Mon, Jul 15, 2013 at 03:05:52PM +0200, Jorge Timón wrote: > One way sacrifice (btc to zerocoin) is a non-issue since there's no > modification required for bitcoin and you can't do anything to prevent > it anyway. > The controversial thing is sacrificing something outside bitcoin's > chain and n

Re: [Bitcoin-development] Introducing BitcoinKit.framework

2013-07-15 Thread Mike Hearn
You can cut down the JVM to be a few megabytes if you're aggressive about it. But for a desktop app I'm not sure it's really necessary these days. A few megabytes used to make a noticeable difference to success rates but bandwidth improved a lot since then. Portability to android is a given, it's

Re: [Bitcoin-development] Introducing BitcoinKit.framework

2013-07-15 Thread Mike Hearn
Oracle provide an OSX JVM and will do so for the forseeable future, it's also open source, so the community could carry on if they stopped. The primary problem with the Oracle JVM is lack of retina support for Swing, but if you'd write a Cocoa UI yourself then it doesn't matter of course as Java wo

Re: [Bitcoin-development] Introducing BitcoinKit.framework

2013-07-15 Thread Wendell
Hi Mike, You are absolutely right about the synchronize time, it's one of our main frustration points right now and we clearly won't deliver the kind of user experience we want, without fixing this. Actually we were thinking of extending Jeff Garzik's picocoin as time permits, but the plan is f

Re: [Bitcoin-development] Introducing BitcoinKit.framework

2013-07-15 Thread Mike Hearn
That's great! I'm all for more wallets, especially user friendly UIs. However being based on bitcoind means it will take a very long time to synchronize for new users. We know a lot of users drop out. The best fix for this is SPV mode. Do you have any plans in this direction? So far, the only SPV

Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining

2013-07-15 Thread Jorge Timón
One way sacrifice (btc to zerocoin) is a non-issue since there's no modification required for bitcoin and you can't do anything to prevent it anyway. The controversial thing is sacrificing something outside bitcoin's chain and new btc appearing. On merged mining. It is true that "merged attacking"

[Bitcoin-development] Introducing BitcoinKit.framework

2013-07-15 Thread Wendell
Hi devs, Just wanted to cross-post this here since it seems very relevant. We're launching BitcoinKit.framework, a Cocoa framework that allows developers to write Bitcoin wallet apps for Mac OS X. BitcoinKit uses bitcoind, and serves a small and tidy API for developer use. Support for other Bit

Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining

2013-07-15 Thread Peter Todd
On Sat, Jul 13, 2013 at 11:32:39AM -0700, Peter Vessenes wrote: > One very real issue for alt-currencies that don't peg to Bitcoin is that > market liquidity is a bitch. By almost all standards current global Bitcoin > liquidity is already very, very low. Too low for many transactions that > come a

Re: [Bitcoin-development] Protecting Bitcoin against network-wide DoS attack

2013-07-15 Thread Peter Todd
On Sun, Jul 14, 2013 at 10:12:00PM +, John Dillon wrote: > 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 a