Re: [Bitcoin-development] Preparing for the Cryptopocalypse
Interesting! I will refrain from digging into QC right now, per Alan's suggestion. :) -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Preparing for the Cryptopocalypse
I studied with Jeffrey Hoffstein at Brown, one of the creators of NTRU. He told me recently NTRU, which is lattice based, is one of the few (only?) NIST-recommended QC-resistant algorithms. We talked over layering on NTRU to Bitcoin last year when I was out that way; I think such a thing could be done relatively easily from a crypto standpoint. Of course, there are many, many more questions beyond just the crypto. Peter -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/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
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 p...@petertodd.org wrote: 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 new btc appearing. Which is why I'm not proposing that. On merged mining. It is true that merged attacking the other chain is free, but it is still more profitable to just follow the rules and mine the other coin!! If someone considers that something he can sell in a market for btc is negative value...well, he's just dammed stupid. Proof of work is designed for rational actors, if you stop assuming miners are more or less rational everything falls apart. It is possible that the extra value is too little for some miners to bother. But the extra costs of validating something else are so little compared to chance-hashing that miners not merged mining namecoin right now are just stupid (irrational agents). You can merged mine and sell for btc right away. You are assuming value is the same for everyone - it's not. If I mine in a jurisdiction where zerocoin is banned, and the blocks I mine are public, the value of zerocoin blocks to me are at best zero. Equally it would be easy for the local authorities to ask that I merge mine zerocoin blocks to attack the chain - it doesn't cost me anything so what's the harm? I may even choose to do so to preserve the value of the coins I can mine legally - alt-coins are competition. Incedentally keep in mind it is likely that in the future pools will not allow miners to modify the work units they receive in any way as a means of combating block-withholding fraud; there may not be very many people willing or able to honestly merge-mine any given chain. Proof-of-sacrifice can be done in a way that is opaque to the master blockchain by creating txouts that look no different from any other txout. Hopefully not required, but it would be a good strategy against censorship of sacrifice-based chains. On prime proof of work...for me it's interseting only because it's moving towards SCIP-based mining but that should be the goal. Like Mark said, let's cure cancer while mining. That would end all mining is wasteful arguments about this great security system. This would make Ripple's consensus mechanism less attractive. People talking about new scrypts harder to ASIC-mine when that's the elephant in the room... Sorry, I'm going off-topic. SCIP-based merged mining for the win. SCIP is for now a dream. Give it a few more years and see how the technology shakes out. -- 'peter'[:-1]@petertodd.org 00582cc323897a582e9368a5c3dfbcdcf73e78b261703e1bd1ba -- -- [image: CoinLab Logo]PETER VESSENES CEO *pe...@coinlab.com * / 206.486.6856 / SKYPE: vessenes 900 Winslow Way East / SUITE 100 / Bainbridge Island, WA 98110 -- 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
-- -- [image: CoinLab Logo]PETER VESSENES CEO *pe...@coinlab.com * / 206.486.6856 / SKYPE: vessenes 900 Winslow Way East / SUITE 100 / Bainbridge Island, WA 98110 -- 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] Some PR preparation
Can some enterprising soul determine if there were any double-spend attempts? I'm assuming no, and if that's the case, we should talk about that publicly. Either way, I think it's generally another test well done by everyone; people pitched in on PR, tech, communication, yay Bitcoin! On Tue, Mar 12, 2013 at 9:55 AM, Alan Reiner etothe...@gmail.com wrote: On Tue, Mar 12, 2013 at 8:10 AM, Luke-Jr l...@dashjr.org wrote: I think we should be careful not to downplay the reality either. For a number of hours, transactions could have received up to N confirmations and then still been reversed. While we could contact the bigger payment processors, I saw people still trying to buy/sell on OTC, whom could have been scammed even by taking standard precautions. I don't want to misrepresent what happened, but how much of that was really a risk? The block was rejected, but the transactions were not. Any valid transactions to hit the network would get added to everyone's memory pool and mined in both chains. Thus all nodes would still reject double-spend attempts. As far as I understood it, you would've had to have majority mining power on one of the chains (and both had non-negligible computing power on them), so double-spending still required an exceptional amount of resources -- just not the normal 50% that is normally needed. Perhaps... 10%? But how many people can even have 10%? In addition to that, a victim needs to be found that hasn't seen the alert, is willing to execute a large transaction, and is on the wrong side of the chain. Is this incorrect? Yes, there was less resources needed to execute an attack -- but it still required a very powerful attacker, way outside the scope of regular users. -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- -- [image: CoinLab Logo]PETER VESSENES CEO *pe...@coinlab.com * / 206.486.6856 / SKYPE: vessenes 811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104 -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Some PR preparation
Thanks Chris. Yep, looks like an honest-ish user managed to accidentally get one tx into one chain and another into the other. I think I'd cautiously say that if OKPay gets their cash back, or freezes his balance nobody is out BTC for last night, (instead just time and effort). I'm doing a little FUD-fighting right now, but will try and pick up a bit more if necessary tonight after my flight lands. I think this is mostly over the heads of a lot of our typical media contacts, though. Peter On Tue, Mar 12, 2013 at 12:53 PM, Christian Decker decker.christ...@gmail.com wrote: Just a quick and dirty check if something bad actually happened. 430 transactions that were confirmed in the alt-chain, are not confirmed in the true blockchain. The good news is that as far as I can tell most of them are low volume transactions destined for SD. 7 transactions were true double spends, or to be more precise transactions in which an conflicting transaction was confirmed in the new chain (with their respective amount): 12814b8ad57ce5654ba69eb26a52ddae1bff42093ca20cef3ad96fe7fd85d195 261 BTC cb36ba33b3ecd4d3177d786209670c9e6cdf95eb62be54986f0b49ca292714af 0.06 BTC 7192807f952b252081d0db0aa7575c4695b945820adaf7776b7189e6b3d86f96 0.01 BTC 355d4ea51c3b780cf0b10e8099a06a31484e0060bc140b63f3d6e5fb713ace5e 0.05 BTC b961bc0c663a46893afd3166a604e7e2639533522d9fec61fdb95eb665e86f5a 0.61 BTC 138063e4bdb76feaa511f1e7f9c681eb468ef9140c141671741c965e503b84c6 1.62 BTC a10bd194cdbf9aa4c12eb0b120056998a081a9b0d93d70570edff24dec831f90 0.81 So the one transaction that really hurt was the one published on BitcoinTalk. We're not yet out of the woods as some of the 423 transactions still have a chance of being doublespent, but looks like it's not that bad after all. Cheers, Chris P.S.: For a complete list of transactions see http://pastebin.com/wctJU3Ln -- Christian Decker On Tue, Mar 12, 2013 at 7:39 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Mar 12, 2013 at 11:09 AM, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Mar 12, 2013 at 10:35 AM, Peter Vessenes pe...@coinlab.com wrote: Can some enterprising soul determine if there were any double-spend attempts? I'm assuming no, and if that's the case, we should talk about that publicly. [snip] I agree it would be good to confirm no one was ripped off, even though we can't say there weren't any attempts. https://bitcointalk.org/index.php?topic=152348.msg1616747#msg1616747 -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- -- [image: CoinLab Logo]PETER VESSENES CEO *pe...@coinlab.com * / 206.486.6856 / SKYPE: vessenes 811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104 -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Key retirement and key compromise
We've been toying with the idea of a 'dead' button, one that issues a bunch of pre-generated txs sending stuff out to a previously secured 'backup' set of addresses (we don't think in terms of wallets, just keypairs). In this scenario, you have a long-term storage address (or set of them), and if you need to hit the panic button, previously signed transactions send value over to your emergency storage. If you've mucked around sending / receiving with your long-term storage, you'd only catch some BTC, not necessarily all, but what's nice is the panic transaction leaking has lower security requirements than your private keys -- worst case it's out, and you've got to deal with stuff in emergency storage, as opposed to losing all your coins. You could pair this with a server that checks if 'safe' addresses have 'unauthorized' transactions showing up on the blockchain, and you'd have a reasonable automated security layer. Maybe. :) I'm interested in thoughts on this approach as well. Jorge -- I respectfully disagree with you, there are a number of enterprise scenarios where your method is not appropriate. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Re: Bitcoin Testing Project
My reply-all forward was blocked (over 40k), sigh. I figured I'd spammed the list enough for one night. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment protocol thoughts
I meant sent twice, a. No double-spends that I'm aware of. Sorry for the loose verbiage! Peter On Tue, Oct 2, 2012 at 11:07 AM, Jeff Garzik jgar...@exmulti.com wrote: On Tue, Oct 2, 2012 at 1:52 PM, Peter Vessenes pe...@coinlab.com wrote: This is small, but an interesting tidbit from BTC Foundation payments; roughly 3-5% of our initial members double-spent. WOW, that's terrible. To be specific, do you mean a) paid twice or b) sent BF coins, then sent the same coins elsewhere ? Double-spend is a specific technical term -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- -- [image: CoinLab Logo]PETER VESSENES CEO *pe...@coinlab.com * / 206.486.6856 / SKYPE: vessenes 811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104 -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Testing Project
And, finally, when I say Ditto to above I mean I have no idea, not nope. Double oops. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Testing Project
___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- -- [image: CoinLab Logo]PETER VESSENES CEO *pe...@coinlab.com * / 206.486.6856 / SKYPE: vessenes 811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104 -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] separate out blockchain db and wallet to two dirs?
I like this idea, although I would say the blockchain should go in /var/lib/bitcoin by default, right? I'm just a longtime LInux guy, not a formal sysadmin, though. Peter On Fri, Sep 14, 2012 at 11:15 AM, grarpamp grarp...@gmail.com wrote: I mentioned this somewhere a while ago. It is enough of a sysadmin problem to warrant a feature ticket. Open one on github for it. XDGBDS is not canon. So don't hardcode said paths. All paths should be specifiable in bitcoin the config file, whose location should itself be specifiable on the command line. -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- -- [image: CoinLab Logo]PETER VESSENES CEO *pe...@coinlab.com * / 206.486.6856 / SKYPE: vessenes 811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104 -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Signing release binaries
This is a good idea. I think I can come up with the cash, I will follow up with gavin. Sent from my smartphone! On Jul 29, 2012, at 7:18 PM, Mike Hearn m...@plan99.net wrote: MacOS X 10.8 makes application signing borderline mandatory, in that you cannot run unsigned apps unless you tweak your settings via the control panel. You must sign with a certificate issued by Apple via their identified developer program. Windows allows but does not require signing. However, anti-virus systems tend to use signers with good reputation as a whitelisting signal. Signing Bitcoin releases makes sense because it may lead to, at minimum, higher performance if AV engines ignore file reads/writes by Bitcoin. And it can also shield us from false positives. You only need to see the mess that the mining tools world has become to understand why this is important. As I don't take part in the release process, I can't help out with this directly, but I believe it's important and would be willing to throw some money in towards buying the signing certs for both platforms. I guess Gavin would be the final signer. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Reconsidering block version number use
I think it would be great to have more nonce space with less merkle calculation; keeping track of all possible versions of a block already takes real RAM, real computation. Being able to change one bit in the header and send out a new block for checking would ease our pool server work by a real amount, somewhat on the work generation side, but also on the checking old work side; we'll have a lot fewer unique transaction / coinbase sets to hold on to for checking when we get back a solution. Peter On Tue, Jul 24, 2012 at 4:58 PM, Mike Hearn m...@plan99.net wrote: That'd be 7 bytes of nonce in the block header, which is 72,057,594,037,927,936 ~ 72 petahashes = 72,000 terahashes So: the changes for version 2 blocks would be has height in the coinbase, and has a 1-byte version number with a 3-byte extranonce. I don't understand why more nonce bits are necessary. Is it really impossible for a multi-core CPU to keep up with the merkle root re-calculation and keep an ASIC miner fed, or is this working around a performance bottleneck somewhere else? -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- -- [image: CoinLab Logo]PETER VESSENES CEO *pe...@coinlab.com * / 206.486.6856 / SKYPE: vessenes 811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 34: Block v2, Height in Coinbase
On Fri, Jul 6, 2012 at 9:49 AM, Jeff Garzik jgar...@exmulti.com wrote: On Fri, Jul 6, 2012 at 12:45 PM, Peter Vessenes pe...@coinlab.com wrote: The proposal is simple, and it's a small change for miners, I imagine. My question is: why? I worry about stuffing too many requirements on the coinbase. I suppose the coinbase is easily extendible if we run out of bytes, but I think I'd like to see some more discussion / good / bad type cases for making this change. What do we get over just the prev_hash by doing this? With the existing setup (sans height in coinbase), you might not have unique transactions, with all that entails. Yes, I've experienced that myself, actually. Anyway, some background would be great; if I missed it, I'm happy to go read up, but I didn't see any links on the wiki. Gavin wrote some notes on upgrades and BIP16 lessons-learned at https://gist.github.com/2355445 This is a super coherent and excellent writeup. I may come back with more thoughts, I want to let it percolate. Thanks! -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- -- [image: CoinLab Logo]PETER VESSENES CEO *pe...@coinlab.com * / 206.486.6856 / SKYPE: vessenes 811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 34: Block v2, Height in Coinbase
So, The proposal is simple, and it's a small change for miners, I imagine. My question is: why? I worry about stuffing too many requirements on the coinbase. I suppose the coinbase is easily extendible if we run out of bytes, but I think I'd like to see some more discussion / good / bad type cases for making this change. What do we get over just the prev_hash by doing this? If this is just a voting mechanism for moving to v2 blocks, that's cool, but it would be nice to codify voting in the coinbase a bit? Maybe? We've now once voted with /p2sh/ and this is a different mechanism now, if I understand it properly. Anyway, some background would be great; if I missed it, I'm happy to go read up, but I didn't see any links on the wiki. Peter On Fri, Jul 6, 2012 at 8:10 AM, Jeff Garzik jgar...@exmulti.com wrote: Please review and comment... Block v2, Height in Coinbase https://en.bitcoin.it/wiki/BIP_0034 BIP: 34 Title: Block v2, Height in Coinbase Author: Gavin Andresen gavinandre...@gmail.com Status: Draft Type: Standards Track Created: 2012-07-06 Abstract Bitcoin blocks and transactions are versioned binary structures. Both currently use version 1. This BIP introduces an upgrade path for versioned transactions and blocks. A unique nonce is added to newly produced coinbase transactions, and blocks are updated to version 2. Motivation 1.Clarify and exercise the mechanism whereby the bitcoin network collectively consents to upgrade transaction or block binary structures, rules and behaviors. 2.Enforce block and transaction uniqueness, and assist unconnected block validation. Specification 1.Treat transactions with a version greater than 1 as non-standard (official Satoshi client will not mine or relay them). 2.Add height as the first item in the coinbase transaction's scriptSig, and increase block version to 2. The format of the height is serialized CScript -- first byte is number of bytes in the number (will be 0x03 on main net for the next 300 or so years), following bytes are little-endian representation of the number. 3.75% rule: If 750 of the last 1,000 blocks are version 2 or greater, reject invalid version 2 blocks. (testnet3: 51 of last 100) 4.95% rule (Point of no return): If 950 of the last 1,000 blocks are version 2 or greater, reject all version 1 blocks. (testnet3: 75 of last 100) Backward compatibility All older clients are compatible with this change. Users and merchants should not be impacted. Miners are strongly recommended to upgrade to version 2 blocks. Once 95% of the miners have upgraded to version 2, the remainder will be orphaned if they fail to upgrade. Implementation https://github.com/bitcoin/bitcoin/pull/1525 and https://github.com/bitcoin/bitcoin/pull/1526 -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- -- [image: CoinLab Logo]PETER VESSENES CEO *pe...@coinlab.com * / 206.486.6856 / SKYPE: vessenes 811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Raw Transaction RPC calls for bitcoind
This is super cool! I have a feature request: it would be awesome to be able to provide private keys at the command line with the signature, turning the client into a wallet-less signature machine. Peter On Thu, Jun 14, 2012 at 9:22 AM, Gavin Andresen gavinandre...@gmail.comwrote: I submitted a pull request yesterday that implements low-level raw transaction, and am looking for feedback on the API and help with trying to test/break it. ... -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Defeating the block withholding attack
On Sat, Jun 2, 2012 at 8:52 PM, Luke-Jr l...@dashjr.org wrote: Analysis, comments, constructive criticism, etc welcome for the following: ==Background== At present, an attacker can harm a pool by intentionally NOT submitting shares that are also valid blocks. All pools are vulnerable to this attack, whether centralized or decentralized and regardless of reward system used. The attack's effectiveness is proportional to ratio of the attacker's hashrate to the rest of the pool. I'm unclear on the economics of this attack; we spent a bit of time talking about it a few months ago at CoinLab and decided not to worry about it for right now. Does it have asymmetric payoff for an attacker, that is, over time does it pay them more to spend their hashes attacking than just mining? My gut is that it pays less well than mining, meaning I think this is likely a small problem in the aggregate, and certainly not something we should try and fork the blockchain for until there's real pain. Consider, for instance, whether it pays better than just mining bitcoins and spending those on 'bonuses' for getting users to switch from a pool you hate. Watson, I don't believe the attack signature you mention is a factor here, since the pool controls the merkle, only that pool will benefit from block submission. The nonce / coinbase combo is worthless otherwise, and so this attack is just in brief get lucky, but don't submit. So, can anyone enlighten me as to some actual estimates of badness for this attack? Peter -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Punishing empty blocks?
OK, I have a few thoughts on this:
1) Germane to the original conversation, anything hard to implement will
not get implemented by miners.
2) Coinbase is hard-limited to 100 bytes; this has to include space for
voting as well as extra nonce, etc. So, I'm not sure that a full URL is a
good plan.
3) I'm a little fuzzy on the details of BIP governance; but I'm happy to
write one up and get my thoughts down, or someone who's more familiar could
do it, I suppose.
I propose the following spec:
periodically a miner may choose to publish a url through their coinbase as
follows:
1) They shall prepend \mi: to the url to designate it as a url for miner
info, and append a trailing \ to the url
2) The url given in the coinbase shall have http:// prepended to it before
processing.
3) The destination may be a redirect (to allow short URLs), or may deliver
content
4) The content-type returned by the final site post-redirect shall be
either (preferred text/json) or text/plain or text/html
4) The text of the document delivered shall be a JSON format dictionary,
and shall include at minimum the following fields: 'min_fee', 'pool_name',
and 'last_modified' Optional fields can be determined over time as
necessary by the mining community
5) The Service Level Agreement isn't binding, but miners who implement it
are expected to make a best efforts attempt to follow it.
So a valid coinbase could be:
/P2SH/\mi:goo.gl/mr2D\extra_nonce:2110
Generally a miner would occasionally publish the \mi:\ when they had
updated their SLA, or just every so often, but the canonical location would
be the final destination URL from the redirects.
Inre: Luke's complaint about JSON, it is the language of the web. There is
no easier format for both computers and humans to read, and in this case,
it includes extensibility, which is nice, since we have no idea how miners
will wish to divvy up their services; I think one would need to make a
strong case against JSON for a specific reason to not choose it by default.
Thoughts welcome!
Best,
Peter
On Tue, May 29, 2012 at 10:47 AM, Luke-Jr l...@dashjr.org wrote:
On Tuesday, May 29, 2012 8:52:49 AM Michael Grønager wrote:
The format of the sla.php page should then be specified too - but it
could
be a json-rpc call returning a json object like (as result): {
sla_version: 0.1,
accept_no_fee_tx: false,
min_fee: 5,
big_tx_fee: 1, // extra fee pr kb
}
I guess miners could work out a more suitable set of fees...
Please not JSON, and not hard-coded logic. Bitcoin already has a secure
scripting system - perhaps we can decide on an initial stack format and
run a
script retrieved from the URI?
--
Peter J. Vessenes
CEO, CoinLab
M: 206.595.9839
Skype: vessenes
Google+ https://plus.google.com/112885659993091300749
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Punishing empty blocks?
I suppose I mean that I don't understand how to reverse that into a URL when one is presented only with a block, or perhaps a coinbase in a transaction. Best, Peter On Tue, May 29, 2012 at 11:34 AM, Luke-Jr l...@dashjr.org wrote: On Tuesday, May 29, 2012 3:28:56 PM Peter Vessenes wrote: I don't understand what the 20 byte keyhash is. Can you elucidate? 20 byte keyhashes are a fundamental building block of the Bitcoin protocol. ripemd160(sha256(ecdsaPubKey)) -- Peter J. Vessenes CEO, CoinLab M: 206.595.9839 Skype: vessenes Google+ https://plus.google.com/112885659993091300749 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Punishing empty blocks?
I see. That is undeniably more secure and bitcoin-y than my suggestion. It's also really a lot more work, especially in that it requires extra linkages between codebases that in my mind are largely separate. I'm just one voice, but I persist in believing that the 'lighter' solution, especially for something that may not be a particularly big problem in the bitcoin world is good -- it carries much less technical implementation debt going forward, and has a lower risk of sort of seizing up development with additional necessary code to worry about for those implementing to-spec clients. If that lighter solution turns out to be gameable, or has problems that require the full force of the bitcoin network and concepts, that would be the time to implement the improved version. That's just my approach, however. I worry that building in any additional requirements to the protocol or codebase adds significant cost to the network as a whole over the next 10 years. Peter On Tue, May 29, 2012 at 11:39 AM, Luke-Jr l...@dashjr.org wrote: On Tuesday, May 29, 2012 3:36:34 PM Peter Vessenes wrote: I suppose I mean that I don't understand how to reverse that into a URL when one is presented only with a block, or perhaps a coinbase in a transaction. A new message can be added to the p2p relay network, similar to tx and alert broadcasts, that allow miners to publish/update their policy URI signed by the key in question. Counter-DDoS rules could decline to relay or store URIs for keys that haven't been published in - or achieved statistical significance in - the last N blocks. -- Peter J. Vessenes CEO, CoinLab M: 206.595.9839 Skype: vessenes Google+ https://plus.google.com/112885659993091300749 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Punishing empty blocks?
I disagree with a bunch of your points, but I'll wait on others to comment, except I will say that I don't understand what the 20 byte keyhash is. Can you elucidate? I am assuming major mining folks have written their own coinbasing facilities, but perhaps this is not the case -- if so, I agree that some work is necessary for such miners. Finally I will just comment that I am guided by the general perspective that many things about bitcoins are opt-in; therefore it makes sense to me put difficult work onto those who are motivated to do it, and keep things as easy as possible for the 'maybes' to participate -- hence small courtesies like allowing text/plain or text/html. Peter On Tue, May 29, 2012 at 11:18 AM, Luke-Jr l...@dashjr.org wrote: On Tuesday, May 29, 2012 3:05:18 PM Peter Vessenes wrote: 1) Germane to the original conversation, anything hard to implement will not get implemented by miners. Without my got-tired-of-waiting-for-someone-to-merge-it coinbaser branch, anything modifying the coinbase is hard to implement. 2) Coinbase is hard-limited to 100 bytes; this has to include space for voting as well as extra nonce, etc. So, I'm not sure that a full URL is a good plan. Rather, I would suggest a 20 byte keyhash, which allows the owner to broadcast a full URI out-of-band. 1) They shall prepend \mi: to the url to designate it as a url for miner info, and append a trailing \ to the url How about a simple prefix to the fixed-size keyhash? Perhaps MFR= (Mining Fee Rules) 2) The url given in the coinbase shall have http:// prepended to it before processing. I would recommend miners use https, with a specified SSL keyhash in the URI (so we don't need to pay for a proper SSL cert). 3) The destination may be a redirect (to allow short URLs), or may deliver content Clients should simply be required to follow the relevant HTTP specification. 4) The content-type returned by the final site post-redirect shall be either (preferred text/json) or text/plain or text/html text/plain and text/html are just wrong and don't make any sense here. Inre: Luke's complaint about JSON, it is the language of the web. There is no easier format for both computers and humans to read, and in this case, it includes extensibility, which is nice, since we have no idea how miners will wish to divvy up their services; I think one would need to make a strong case against JSON for a specific reason to not choose it by default. Bitcoin isn't the web, it's a complicated script-based cryptocurrency. Everything in the Bitcoin protocol requires a computer's interpretation for humans, and there's no reason to stray from this default. Also, JSON is not extensible in any of the ways needed for this specific purpose. 4) The text of the document delivered shall be a JSON format dictionary, and shall include at minimum the following fields: 'min_fee', 'pool_name', and 'last_modified' Optional fields can be determined over time as necessary by the mining community Last Modified and other caching rules are dealt with in the relevant HTTP specification... 5) The Service Level Agreement isn't binding, but miners who implement it are expected to make a best efforts attempt to follow it. While it doesn't make sense to give it the full legal force of a contract, I think it should be expressed as a MUST in the BIP. Generally a miner would occasionally publish the \mi:\ when they had updated their SLA, or just every so often, but the canonical location would be the final destination URL from the redirects. The coinbase advertisement MUST be part of every coinbase mined by the miner, or there's no reliable way to prove which blocks are theirs. -- Peter J. Vessenes CEO, CoinLab M: 206.595.9839 Skype: vessenes Google+ https://plus.google.com/112885659993091300749 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Punishing empty blocks?
We just implemented our own mining tool, soup-to-nuts, and I would say that the likely motivation for what I presume are botnet owners is just economic. It's a lot more work to make sure your merkleing and keeping up-to-date are happening than it is to just get an 80 byte header from a central server, and re-calc a single transaction merkle client-side. Not to mention the extra work to keep track of what version of getmemorypool output you're receiving work for in a broadly distributed pool. For what it's worth, we did this extra engineering work since we care about Bitcoin, but if I just wanted to pull value out of the ecosystem, we would have skipped it. The only solutions to this are economic solutions -- making such 'cheater' blocks less valuable, or increasing the value of the transactions. Also note that botnet operators likely care, in the end, about fiat currency, so going to 25 btc per block in what I think of as transaction fee subsidies won't necessarily impact this -- it's a matter of what happens to exchange rates vs generation rates that will matter. I think we also have to moderate this consideration against the rights (and arguable benefits) of someone wanting to build an express-delivery mining service, one that will provide provably faster certification for those adding a transaction fee of, say, 1 btc. My own experience now in the MMO world is that we have to carefully understand how we deal with griefers who control massive resources (compute or gold-farmers). It may not be a winning battle to choose a solution which harms the rest of the network in exchange for harming the griefers. This is definitely out of the box, but one solution might be to change the difficulty calculations to just ignore 1tx blocks; that would minimize impact on others to a great extent, and would let someone set up an express block service if they chose. I guess we'd have to settle on whether or not such blocks counted towards the issuance countdown as well. Or, we could allow only 1/10 generation fees on such blocks. Peter On Fri, May 25, 2012 at 9:44 AM, Alan Reiner etothe...@gmail.com wrote: I like the concept except that it only works if every node connected to the miner enforces the rule (if it works). Once any one of the nodes forwards the block, other nodes see it coming from a node that can pass the challenge. I don't think any solution based on node queries will succeed, especially if it requires spontaneous super-majority-of-nodes acceptance. I think it's gotta be based on the block itself and each nodes' own info. If you could spontaneously get all miners to agree not to build off of anti-social blocks (however that is defined) , it would have a chance of making a difference, but individual miners would have an advantage building off the antisocial block because they only need to produce one to create the longest chain (and collect reward) while the miners following the rules need two blocks. --Sent from my overpriced smartphone On May 25, 2012 3:48 AM, Christian Decker decker.christ...@gmail.com wrote: How about a simple proof of work test? This one though does not ask for CPU work but asks the miner for a random old transaction. If the miner really stores the entire blockchain he will not have any problem answering to that getdata request, whereas a botnet would have to ask someone else for it, which could be detected if the response time deviates too much from what has been previously measured (compare it against getdata for the block they advertise). It's not perfect but it allows an estimate of whether it is a chainless miner. Regards, Chris -- Christian Decker On Fri, May 25, 2012 at 3:17 AM, Jeff Garzik jgar...@exmulti.com wrote: On Thu, May 24, 2012 at 8:57 PM, Luke-Jr l...@dashjr.org wrote: Block times are not accurate enough for that. The times in your log are very accurate, assuming your system clock is remotely accurate. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats.
Re: [Bitcoin-development] BIP 33 - Stratized Nodes
Thanks for this, Amir. My initial reactions: 1) This is cool and useful (but see 3) 2) This is significantly less secure than validating an entire blockchain; it's certainly worth working out some use cases here in more detail than just a sample conversation. More on this below 3) What about discovery? Will a client now have the chance to look for NODE_STRATIZED clients on IRC? How do you envision a stratized server decides which transactions to relay/store? Or is it just a caching layer in front of a high quality blockchain service? If it is just a caching service, the question of cache hits / misses is an interesting one as well. 4) What are the economic motivations to run a stratized server? Other than cheating people of course. 5) Seems like a 'send me everything for this source address' is going to save a lot of roundtrip conversations for what I imagine the most common request will be. Inre: majority agreement on transactions, and even balances, it would be nice to work out some theoretical security / cost / value calculations for the following scenarios: Likely value and cost to someone of subverting / lying about 1) An n-confirmation transaction, n 0 2) A 0 confirmation transaction 3) A NODE_STRATIZED transaction chain for a client with m connections to NODE_STRATIZED servers 4) An address balance request for a client with m connections to NODE_BALANCE_INFO (I made this name up) servers Peter -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP to improve the availability of blocks
Blocks already checksum; they hash to a low number. Also inre: block headers, you are furnished with a previous hash in the first 80 bytes of the block. You can always cut the connection at that moment if you've already seen the block headers. Peter On Mon, Apr 30, 2012 at 1:02 PM, Zell Faze zellf...@yahoo.com wrote: Although quite true, I actually agree though that there should be some sort of checksum for the blocks. Bandwidth may not be a bottleneck now (or ever), but it may be at some point. This change will help Bitcoin scale. It stopped being just a website a long time ago. For many of us, most of us, Wikipedia has become an indispensable part of our daily lives. — Jimmy Wales, Founder of Wikipedia Help protect it now. Please make a donation today: http://www.wikimediafoundation.org/wiki/Donate --- On Mon, 4/30/12, Amir Taaki zgen...@yahoo.com wrote: From: Amir Taaki zgen...@yahoo.com Subject: Re: [Bitcoin-development] BIP to improve the availability of blocks To: bitcoin-development@lists.sourceforge.net bitcoin-development@lists.sourceforge.net Date: Monday, April 30, 2012, 3:11 PM This is optimisation where it isn't needed. Bandwidth is not the bottleneck of the Bitcoin system. It is the immense time needed to validate the blockchain. And clients should never send blocks first. They always send an inv packet, then you request the block. It is a disruptive change and brings little. We don't need to optimise every aspect of Bitcoin :) Just focus on the big bits that matter, while keeping everything working with minimal changes. For instance say we did this and to maintain backwards compatible, we introduced a new message called hash+block. Now there are 2 code branches that must be maintained - urgh. From: Wladimir laa...@gmail.com To: Rebroad (sourceforge) rebroad+sourceforge@gmail.com Cc: bitcoin-development@lists.sourceforge.net Sent: Monday, April 30, 2012 7:26 PM Subject: Re: [Bitcoin-development] BIP to improve the availability of blocks On Mon, Apr 30, 2012 at 6:40 PM, Rebroad (sourceforge) rebroad+sourceforge@gmail.com wrote: My proposal is that in addition to the size (which is advertised in the header), the hash is also advertised in the header (of a block). This would help nodes to determine whether they wanted to reject the download. (e.g. if it already had a block matching that hash). This of course wouldn't prevent a rogue node from sending an incorrect hash, but this would aid in saving bandwidth amongst behaving nodes. I suppose it would make sense for clients to be able to reject blocks that they already have, if that's not currently possible. The other part of the proposal is to allow nodes to request upload and download blocks that have already been partially downloaded. This could be done by modifying the existing methods of upload, download, or by adding a new method, perhaps even using HTTP/HTTPS or something similar. This would also help nodes to obtain the blockchain who have restrictive ISPs, especially if they are being served on port 80 or 443. This could perhaps also allow web caches to keep caches of the blockchain, thereby making it also more available also. You don't need a BIP if you want to somehow fetch the (initial) block chain outside the bitcoin protocol. You could download it from some http server or even pass it along on an USB stick. Then with a simple client change you can import it: https://github.com/bitcoin/bitcoin/pull/883 . Currently, without this functionality, nodes with restrictive (or slow) internet have some options, such as going via a tor proxy, but due to the latency, the problem with multiple receptions of the same block still occur. If you're behind such a slow internet connection, and concerned about every bit of bandwidth, it is better to run a lightweight node. For example, Electrum. Even if you could reduce the wasted bandwidth a bit by puzzling around with partial blocks, the download will still be substantial (and that's going to get worse before it gets better). Wladimir -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Trusted identities
These are interesting thoughts, karma for bitcoins essentially. I would like CoinLab to publish a 'cost of subverting 1-n transactions with 90% probability' metric soon, and I think it would help everyone to understand what that number is. When we started out, you probably needed to wait 5 blocks for $10 or $20 of bitcoin value transfer. Now, I'd happily accept a $1k transaction with 1 confirmation. More difficulty shortens the safe time we can transact large volumes in, which is good for the network. I'm not sure of the current implementation of replacement transactions, can anyone on the core team speak to this? Can I replace transactions, or is that part of the spec unimplemented or deprecated right now? Peter On Thu, Apr 26, 2012 at 8:49 AM, Peter Todd p...@petertodd.org wrote: It recently occured to me that we can use the public nature of the block chain to create trusted identities, for a specific form of trust. Lets suppose Alice has some bitcoins held at bitcoin address A. She wants to establish trust in the identity associated with the ECC keypair associated with A, for instance for the purpose of having other users trust her not to attempt to double spend. Since the trust she seeks is financial in nature, she can do this by valuing the identity associated with A, by delibrately throwing away resources. A simple way to do this would of course be to transfer coins to a null address, provably incurring a cost to her. A more socially responsible way would be for her to create a series of transactions that happen to have large, and equal, transaction fees. Bitcoin makes the assumption that no one entity controls more than 50% of the network, so if she makes n of these transactions consecutively, each spending m BTC to transaction fees, there is a high probability that she has given up at least n/2 * m BTC of value. This of course is all public knowledge, recorded in the block chain. It also increases the transaction fees for miners, which will be very important for the network in the future. Now Bob can easily examine the block chain, and upon verifying Alice's trust purchase, can decide to accept a zero-confirmation transaction at face value. If Alice breaks that promise, he simply publishes her signed transaction proving that Alice is a fraudster, and future Bob's will distrust Alice's trusted identity, thus destroying the value needed to create it. In effect, we now have a distributed green address system. Now Alice could try to mount a double-spend attack on a whole bunch of people at once, hoping to have them all accept the transaction. However as it is the just trust them model works pretty well already. A good usecase for this idea, beyond the obvious fast payments application, is a distributed anonymizer. Alice can now publish her request to anonymize coins, and other trusted identities can make their bids. If Alice accepts a bid from Bob, she will want Bob to send her the anonymized coins *prior* to her transaction going through, thus breaking the temporal connection between the transactions. Now Alice can give Bob the signed payment transaction, and Bob can submit his payment transaction to the network first, knowing that Alice isn't going to try to rip him off. Bob can also have a trusted identity which signed the contract for the anonymizer transaction, and similarly if he rips Alice off, she can publish it for the world to see. A more subtle effect, is this makes sybil attacks more difficult. To pretend to be a thousand identities is going to now require 1,000 * n coins, and attempting to pull this attack off inherently strengthens the bitcoin network. Obviously we can apply this principle to other things like tor nodes as well. -- http://petertodd.org 'peter'[:-1]@petertodd.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJPmW6EAAoJEH+rEUJn5PoEZfEH/ixptlMX9MzP71bCHMkj7YN1 y6GEkc1vNhyHu01NX77vzSqR4trbVnWJeJ5hH8EB5tgYRwmI17XoQW6Iz8yEXXgO JqUKCTBBexGE+F5RfBkizJ9ap5wXwVrAOIMy/KurSdST+PWMXIPQFaGark01uKcG M4VXg3U9fc/0Zz1QyKpRTI5O7ZSBqPzEh/Xf4TujR39nUtaI5mkT/bmA3+Te7oRT 34QO7ryF7U001Xz2VJCfm9AE8mPPZjMavLTs/XvPSqTdliVCZpjGGHzcJ2BPrni5 LEPBsBBxNsuwFGjnRobQwrkPtmYGFntseMLzCJ3iGXWYwedssBg2LLOx9QaXG04= =PftQ -END PGP SIGNATURE- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Peter J. Vessenes CEO, CoinLab M: 206.595.9839 Skype: vessenes
Re: [Bitcoin-development] Adding request/reply id in messages
I agree that it would be nice if the protocol stayed stateless. I also think we should try and keep in our heads the aggregate bitcoin-universe cost of implementing any protocol change; even a very small change, something that truly only takes one hour of time from each bitcoin node client developer to implement, test and bugfix (hah!) Has a cost in the (tens?) of thousands of USD added up across those who need to understand, implement, discuss, etc. Peter On Thu, Apr 12, 2012 at 10:24 AM, Amir Taaki zgen...@yahoo.com wrote: Jeff elaborated the problems very well, but I just want to add this: Your change is essentially relying (trusting) the server to track a piece of information (your state). Anytime you start depending on another node in some way, it is opening yourself up to be exploited. Nodes should be doing their owning state maintainance, not relying on external parties. I am very much against the change. As someone who has implemented the complete bitcoin protocol, I had no problems implementing the blockchain download. In fact, I dislike that nodes have to store the last inventory they sent as part of a getblocks in order to trigger the next round. It's be better if there was no state whatsoever. From: Jeff Garzik jgar...@exmulti.com To: sirk...@gmail.com Cc: bitcoin-development@lists.sourceforge.net Sent: Thursday, April 12, 2012 6:12 PM Subject: Re: [Bitcoin-development] Adding request/reply id in messages On Wed, Apr 11, 2012 at 2:39 PM, Christian Bodt sirk...@gmail.com wrote: Hi, I would like to discuss the following bitcoin protocol improvement proposal: Adding request/reply id in all messages (in the message header, based on what was done for the checksum field) The original reason is that I found it very hard to implement robust blockchain downloading as we are missing context information: The download protocol relies on the other peer sending one (or more) inv reponse(s) to getblocks and sending the hashContinue. But if the other peer doesn't send a response to getblock, send a partial response to getblocks, mixes it with some unrelated blocks inventories or doesn't send the hashContinue it is very hard to detect and handle (e.g. ban the peer and switch to another). This could cause some DoS attacks by misbehaving peers. If the peer is misbehaving, then disconnect. Your protocol change does not offer any clear benefits in this area, as these sorts of attacks/misbehaviors/bugs are still just as possible, and just as damaging (or not). Just disconnect the strange peer! The problems are that 1/ we don't know how many inv messages to wait for after getblocks and 2/ we don't know how to distinguish between result of getblocks and spontaneous inv notifications. The same is true for addr messages (it is both a notification and reply) but this is less of a problem as a lack of response to getaddr doesn't constitute a DoS. The idea would be to add a new requestid field in messages and define the following: Stateless protocols have a lot of value. They are easiest to implement, and easier to prove correct. Existing clients like ArtForz' half-a-node, variants of which are deployed all over the place in bitcoin-land, rely on the stateless-ness to one degree or another. Stateful protocols, too, have their problems as well. One must add code to help remain synchronized between local and remote states, which your suggested change only hints at. NFSv4 and RPC have a long history of dealing with stateful-ness issues. Obviously bitcoin P2P is nowhere near as complex, but the history of NFS development offers several lessons applicable to your proposed change. Overall, IMO your listed reasons for needing this major change (stateless-stateful) do not really justify the change. Handling initial block download can be accomplished in a number of ways, and peer(s) may crash or return odd results. You must handle these cases properly, regardless of the presence of req/reply id's. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Bitcoin-development mailing list
Re: [Bitcoin-development] Signature Blocks and URI Sign Requests
I don't think it's minimally invasive to layer PGP's web of trust on top of Bitcoin, in fact, the opposite. From a certain angle, bitcoin exists as a sort of answer / alternate solution to the web of trust. Digital cash with an existing web of trust in place was a working concept in the mid-1990s, courtesy of David Chaum, I believe. I totally agree on the kitchen sink concern; I would personally like to see something like a one-year required discussion period on all non-security changes proposed to the blockchain protocol. We know almost nothing about how bitcoin will be used over the next 20 years; I believe it's a mistake to bulk up the protocol too rapidly right now. There's a famous phrase from the founder of Lotus about Lotus' engineering process: add lightness. The equivalent for protocol design might be add simplicity. I'd like to see us adding simplicity for now, getting a core set of tests together for alternate implementations like libbitcoin, and thinking hard about the dangers of cruft over a 10+ year period when it comes to a technology which will necessarily include a complete history of every crufty decision embodied in transaction histories. Peter On Tue, Apr 3, 2012 at 1:42 PM, Wladimir laa...@gmail.com wrote: On Tue, Apr 3, 2012 at 8:55 PM, Luke-Jr l...@dashjr.org wrote: On Tuesday, April 03, 2012 2:46:17 PM Gavin Andresen wrote: We should avoid reinventing the wheel, if we can. I think we should extend existing standards whenever possible. I wonder if it's possible to make sigs compatible with PGP/EC ? Or we could take a step back, further into don't reinvent the wheel territory. Why not simply make use of PGP(/EC) to sign and verify messages? It has many advantages, like an already existing web-of-trust and keyserver infrastructure. I still feel like this is sign message stuff is dragging the kitchen sink into Bitcoin. It's fine for logging into a website, what you use it for, but anything that approaches signing email (such as S/MIME implementations and handling different character encodings) is going too far IMO. Wladimir -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Peter J. Vessenes CEO, CoinLab M: 206.595.9839 -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoin.org SOPA/PIPA blackout
It seems to me that the internet as a whole has got this one covered. I say this as someone who thinks that BitCoin needs to choose its battles and craft its reputation extremely carefully; this isn't the most important fight for BitCoin, nor the most deadly. I do think SOPA and PIPA could impact bitcoin, what if, for instance, copyrighted material made its way into the blockchain? Already the DMCA would make it hard for someone publishing blocks online to do anything but cease under a DMCA request. SOPA, at least, would go farther and allow the US to cut all access to 'offending' sites elsewhere in the world. At any rate, I don't think these bills are 'aimed at' BitCoin, and the companies with the most stake are taking the threat quite seriously. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
