Re: [Bitcoin-development] BIP 32.5
On Thu, Aug 15, 2013 at 7:26 PM, Gregory Maxwell gmaxw...@gmail.com wrote: I am wondering if we shouldn't have a BIP32 addendum which makes the following signing related recommendations: Looks like we're in the midst of another DSA duplicated K disaster. (Now, blockchain.info mywallet) I talked to Pieter about this some earlier today and he sounded pretty positive. I'll go ahead and start on an actual BIP document for it. -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/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: BIP 70, 71, 72
I think the confidence of the tx is not really the users concern anyway. They wrote it so they know it's valid. If the merchant disagrees for some reason then the user can find out, out of band when the goods/services are not delivered. On Tue, Aug 20, 2013 at 1:19 AM, Gavin Andresen gavinandre...@gmail.comwrote: On Tue, Aug 20, 2013 at 8:15 AM, Andreas Petersson andr...@petersson.atwrote: I was just reviewing the integration work to integrate the Payment Protocol into our products. Is there any notion of a standardized invoice serialisation? If i pay for two Burgers and one Club Mate, how would my Bitcoin Wallet be able to know that? No. There are XML-based (shudder) standards for electronic invoicing that include all sorts of bells and whistles; the PaymentDetails message could easily encapsulate one of them in an 'invoice' field extension. Or we could reinvent the wheel and come up with our own, but I'd rather use an existing standard (or maybe a subset of an existing standard). I didn't want to wade into that swamp for the 1.0 version of the payment protocol. Right now, i would simply put that into memo and come up with my own serialisation mechanism. Two Burgers, one Club Mate seems pretty user-friendly. Second, is there a way to communicate acceptance levels of TX (unconfirmed, 1 conf, 6 conf) maybe using several PaymentACK? No, because the Payment-PaymentACK communication round-trip is done in one, non-persistent http request-response round-trip. I don't think we want to allow merchants to push messages to the wallet (wouldn't take long for merchants to use the opportunity to push annoying advertising at me, I think), and I don't think we want wallets to poll the merchant. Although maybe a payment protocol version 2.0 feature could be a PaymentACK extension that says ask me how the transaction is going at THIS URL in THIS many minutes. -- -- Gavin Andresen -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] There will be a 0.8.4 release
There have been a few not-quite-serious-enough-to-justify-a-release security fixes that, along with a couple of serious bugs, we think together DO justify a new 0.8.* release. So I just created a 0.8.4 branch, based on the 0.8.3 branch, and will be cherry-picking from the master branch. Planned changes from the 0.8.3 release: Security-related: 42656ea Make RPC password resistant to timing attacks 159bc48 Simplify storage of orphan transactions, fix CVE-2013-4627 37c6389 Performance optimization for bloom filters (help mitigate potential DoS attack discussed last week) Bug fixes: 9bf2a4ab Fix multi-block reorg transaction resurrection bf81a3ef Fix Gnome bitcoin: URI handler f0784ac4 Fix non-standard disconnected transactions causing mempool orphans 2461aba1 Mempool consistency check pull 2916 Import OSX fsync change from LevelDB subtree (will hopefully fix the random-OSX leveldb corruption issues) There are lots of little fixes that could be included, but those will wait for the 0.9 release. -- -- Gavin Andresen -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Making bitcoin traceability harder
Dear bitcoin developers, trading arbitrary amounts of bitcoins makes it easier to trace who does what just by observing the amounts being traded, and where the residual money ends up: e.g. you can identify that obviously, the recurrent user of address A sent 2.5 bitcoins to the recurrent user of address B, keeping the rest of his money in A. If instead bitcoin users practice the discipline, enforced by the client software by default, of only keeping a power-of-two amount of satoshis in use-once wallets except where public donation addresses are meant, then tracing suddenly becomes much harder. Whether this particular discipline is the best to implement or not, shouldn't bitcoin clients enforce SOME discipline that makes tracing harder? After all we know that uniformed goons are eager to watch who's trading with whom and to crack down on users. We shouldn't be making it easy for them, though this will mean slightly higher transaction cost. Merchants would then generate not one but a series of new addresses at each transaction, and the customer would send appropriately sized buckets of satoshis to each of the addresses. There should just be a standard way to specify an amount and a list of addresses as a target for payment, that merchants can communicate to customers (though that might require e.g. higher resolution QR codes). Has this idea already been considered before? Accepted or rejected? —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Of course, Third World leaders love you. By ascribing third world ills to First World sins, you absolve them of blame for their countries' failure to advance. — John McCarthy -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
