Re: [Bitcoin-development] BIP0032
Yeah, I tried implementing it based on the document there and the code that is available in sipa's repo on GitHub but it's not enough. I'm waiting until there is an implementation of this concept before moving on it. From: Michael Gronager grona...@ceptacle.com To: bitcoin-development@lists.sourceforge.net Sent: Monday, May 27, 2013 2:39 PM Subject: Re: [Bitcoin-development] BIP0032 Which again means that the statement regarding Audits through the Master Public key, M, is wrong - only incoming and outgoing transaction of _publicly_ derived wallets will be part of the audit... Privately derived wallets cannot be obtained, though you could, without loss of security, share also the addition points from privately derived wallets: (m/i')*G, but there is no concept of a single public master key. == Audits: M In case an auditor needs full access to the list of incoming and outgoing payments, one can share the master public extended key. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key. == -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development-- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] message dissemination
cool paper: http://phys.org/news/2013-01-algorithm-message-dissemination-decentralized-networks.html#jCp -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP 32 HD wallets, accounts should be labels not numbers
Can this be amended? I think it makes much more sense to allow people to input labels not numbers at this level. General category names for different accounts is much more human than numbers, and you can still use incrementing numbers if you prefer. -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 32 HD wallets, accounts should be labels not numbers
ok, also what is the reasoning behind serialising points using a compressed format before going into the hash function? I'm looking at the sec1-v2.pdf and the compression format is a little confusing. I think the octet string for X is 32 bytes (using q = curve.order) and secp256k1 is a prime field so we follow step 2.2.1 From: Pieter Wuille pieter.wui...@gmail.com To: Amir Taaki zgen...@yahoo.com Cc: bitcoin-development@lists.sourceforge.net bitcoin-development@lists.sourceforge.net Sent: Monday, December 3, 2012 2:54 PM Subject: Re: [Bitcoin-development] BIP 32 HD wallets, accounts should be labels not numbers On Mon, Dec 3, 2012 at 2:49 PM, Amir Taaki zgen...@yahoo.com wrote: Can this be amended? I think it makes much more sense to allow people to input labels not numbers at this level. General category names for different accounts is much more human than numbers, and you can still use incrementing numbers if you prefer. There is no way to iterate over all strings. The intention is that a wallet application can detect a new account that becomes in use (e.g. during disaster recovery), so the accounts get assigned incrementing numbers. I wouldn't mind adding the ability to do non-standard derivations using arbitrary strings, if this recoverability property is not desired. -- Pieter -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 35: add mempool message
My thoughts: The extension is simple. It's only really useful for the use-cases listed if the majority of nodes implement it. As I view the proposal, it is perfectly simple and uncomplicated. If it's implemented, then I suggest to just increment version and make it part of the protocol. On the flipside it is another notch in complicating an already diffuse protocol, but it seems a rather benign offense in that regard compared to other changes (past and future). - Original Message - From: Pieter Wuille pieter.wui...@gmail.com To: Jeff Garzik jgar...@exmulti.com Cc: Bitcoin Development bitcoin-development@lists.sourceforge.net Sent: Thursday, August 16, 2012 6:56 PM Subject: Re: [Bitcoin-development] BIP 35: add mempool message On Thu, Aug 16, 2012 at 01:32:04PM -0400, Jeff Garzik wrote: Consensus was we should do a BIP for all P2P changes, so here it is... feedback requested. https://en.bitcoin.it/wiki/BIP_0035 I like the idea of being able to query the memory pool of a node; the implementation is straightforward, which is good. Maybe effectively using the command can be added? I suppose it is interesting in general for nodes to get a memory pool refill at startup anyway. 1) Upon receipt of a mempool message, the node will respond with an inv message containing MSG_TX hashes of all the transactions in the node's transaction memory pool. An inv message is always returned, even if empty. I'm not sure about this last. What is it good for? inv packets can always be sent, even not in response to others, so it is not that this gives you an acknowledgement the mempool is updated? 3) Feature discovery is enabled by checking two version message attributes: a) Protocol version = 60002 b) NODE_NETWORK bit set in nServices This seems safe, although it forces other full implementations that want to expose protocol version 60002 (or later) to also implement this. What do they think about this? I would like to suggest to allocate an extra service bit for this. We still have 63 left, and this is a well-defined and useful extra service that was not yet provided by any earlier node. Doing that would also mean that mempool-providing survices may be discovered before connecting to them, as the service bits are carried around in addr messages. Any opinions about that? -- Pieter -- 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] BIP 35: add mempool message
MSG_MEMTX solves the issue of not knowing whether a given inv is in response to a mempool command or not. I don't buy the argument that always sending a response inv makes things easier because code should always be able to handle misbehaviour from the remote node (ommiting the inv). However I would argue that it is good to have it, as it makes designing flows of logic much easier (first send this, wait for response, do this, ...). - Original Message - From: Stefan Thomas m...@justmoon.de To: bitcoin-development@lists.sourceforge.net Cc: Sent: Thursday, August 16, 2012 8:21 PM Subject: Re: [Bitcoin-development] BIP 35: add mempool message This seems safe, although it forces other full implementations that want to expose protocol version 60002 (or later) to also implement this. What do they think about this? BitcoinJS will implement it, it's a useful feature and there is no reason not to support it. Two comments from my end: - This is just a thought, but I wouldn't mind using a new inv_type for this, e.g. MSG_MEMTX. I could conceivably see a future where broadcast and relay txs are stored in a very fast local cache whereas the general mempool is stored in a slower data structure. By being able to distinguish incoming getdata requests I can save a few milliseconds by querying the right storage right away. Might also help with things like telling apart broadcast/relayed transactions from the response to a mempool request for purposes like DoS scoring etc. Not a big deal by any means, but I also don't see a downside to it. inv_types are not a scarce resource, we have four billion of them available. For now clients would just treat MSG_TX and MSG_MEMTX interchangeably. - If a node doesn't have anything in it's mempool it sends back an empty inv message. This is either ambiguous (if other things also send empty inv messages in the future) or arbitrary (why should an empty inv be associated with a mempool request of all things.) Instead why not respond with an inv message that contains a single element of type MSG_MEMTX and hash 0. That would a very direct way to indicate that this response is associated with a mempool request. I'm not married to either suggestion, just trying to add my perspective. One thing you notice when reimplementing Bitcoin is that Bitcoin's protocol leaves out a lot of information not for space reasons, but because the reference client's implementation doesn't happen to need it. Sometimes however this locks other clients into doing things the same way. If we can make the protocol a bit richer, especially if this doesn't cost any extra bytes, then we should consider it as it might help some implementation down the road make a neat optimization. On 8/16/2012 7:56 PM, Pieter Wuille wrote: On Thu, Aug 16, 2012 at 01:32:04PM -0400, Jeff Garzik wrote: Consensus was we should do a BIP for all P2P changes, so here it is... feedback requested. https://en.bitcoin.it/wiki/BIP_0035 I like the idea of being able to query the memory pool of a node; the implementation is straightforward, which is good. Maybe effectively using the command can be added? I suppose it is interesting in general for nodes to get a memory pool refill at startup anyway. 1) Upon receipt of a mempool message, the node will respond with an inv message containing MSG_TX hashes of all the transactions in the node's transaction memory pool. An inv message is always returned, even if empty. I'm not sure about this last. What is it good for? inv packets can always be sent, even not in response to others, so it is not that this gives you an acknowledgement the mempool is updated? 3) Feature discovery is enabled by checking two version message attributes: a) Protocol version = 60002 b) NODE_NETWORK bit set in nServices This seems safe, although it forces other full implementations that want to expose protocol version 60002 (or later) to also implement this. What do they think about this? I would like to suggest to allocate an extra service bit for this. We still have 63 left, and this is a well-defined and useful extra service that was not yet provided by any earlier node. Doing that would also mean that mempool-providing survices may be discovered before connecting to them, as the service bits are carried around in addr messages. Any opinions about that? -- 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
[Bitcoin-development] BIP 22 - getmemorypool
Hi, luke-jr wants me to split this BIP into 3 separate BIPs because he says that other devs felt it was too unfocused and covered too many topics. However this discussion took place on IRC, and I never saw any of it to ascertain what happened (BIP 1 says drafts should be evaluated on the mailing list). I think a discussion of BIP 22 perhaps did happen on the mailing list, but I don't remember it. Sorry if that's the case. Anyway before granting the permission to allow this proposal to be pared down, and new BIPs granted for the non-core parts of this proposal, I want to know what people think. I'm not a miner myself, so I'm prescient of my lack of knowledge in the topic. https://en.bitcoin.it/wiki/BIP_0022 Thanks -- 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
[Bitcoin-development] script tests - invalid script in script_valid.json?
Hi! Is this a valid script? [1 0 1, WITHIN NOT] The first value (1) is tested to make sure it is between the lower (0) and upper (1) value. This evaluates to true, placing on the stack a single byte of [01]. NOT then inverses this to a 0 byte false value of []. What am I missing here? Thanks -- 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] script tests - invalid script in script_valid.json?
oh, bitcoin... Thanks justmoon :D - Original Message - From: Stefan Thomas m...@justmoon.de To: bitcoin-development@lists.sourceforge.net Cc: Sent: Sunday, July 29, 2012 1:33 PM Subject: Re: [Bitcoin-development] script tests - invalid script in script_valid.json? OP_WITHIN is lower-bound-inclusive, but upper bound exclusive, so 1 0 1 WITHIN is false. bool fValue = (bn2 = bn1 bn1 bn3); https://github.com/bitcoin/bitcoin/blob/master/src/script.cpp#L854 On 7/29/2012 6:31 PM, Amir Taaki wrote: Hi! Is this a valid script? [1 0 1, WITHIN NOT] The first value (1) is tested to make sure it is between the lower (0) and upper (1) value. This evaluates to true, placing on the stack a single byte of [01]. NOT then inverses this to a 0 byte false value of []. What am I missing here? Thanks -- 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 -- 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
[Bitcoin-development] OP_RESEVERVED and IsPushOnly
Meh, probably harmless, but... As best I can tell, OP_RESERVED does absolutely nothing (a NOP). CScript::IsPushOnly(...) counts this as a push operation. -- 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
[Bitcoin-development] Merge branch on github
Hey, https://github.com/bitcoin/bitcoin.org/pull/46 I tried to keep it professional, and non spammy. -- 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
[Bitcoin-development] Berlin Hackathon
Video from the event: http://www.youtube.com/watch?v=EQ2rb4pHH1g The Hackathon is over, thanks for all the participants and sponsors! I had loads of fun, and there were lots of great ideas flying around! Thanks especially to: - IN-Berlin, for providing the space to hold the hackathon! - Sponsors: bitstamp.net, bitcoin2012.com and localbitcoins.com - Room77 (the restaurant at the end of capitalism), for hosting the afterparty and the burgers pampero - Jury: yossarian + other people who attended the presentations The results - winner first 1. Offline transactions for BitcoinJ/Android bitcoin wallet: Andreas Schildbach and grazcoin - Ability for Android Wallet to do offline transactions 2. Bitcoin Pong: genjix - Multiplayer pong, where you can win (or lose) bitcoins 3. acceptbit.com: Jeremias Kangas and Stefan Thomas - an ultra-safe merchant tool, where you can accept payments without sharing your private keys 4. BitcoinJ Multisig: yellowhat and PK - way to do multisig transactions for BitcoinJ/Android 5. Double-spend monitor: genjix - tool to monitor double spends 6. Bitcoin-autosave: Mike Hearn - BitcoinJ improvements (Mike did also loads of other stuff, and helped with winner project too) 7. Live-calculator: genjix - Tool for btc accepting restaurants 8. Bitcoin mages: genjix - Strategy game, where you play for bitcoins 9. Embed block message: genjix - simple tool for embedding messages in block chain Source code genjix: https://gitorious.org/bitcoin-hackathon acceptbit.com: https://github.com/kangasbros/electrumpos Bitcoin Wallet: https://github.com/livne/Bitcoin-Wallet-for-Android (branch hackathon) Other Participants, send jeremias your bitcoin addresses please The next hackathon will be organized before bitcoin london conference, Wed 12th and Thur 13th september, london. -- 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] bitcoin.org - remove hackathon
Yes, but then they should not be sponsors. There's a very good reason why Wikipedia does not have advertisements. That is, the fear of advertisers influence on the neutral content. It is inevitably a corrupting influence. I want a good fun conference like the hackathon we just held. - Original Message - From: Andreas Petersson andr...@petersson.at To: bitcoin-development@lists.sourceforge.net Cc: Sent: Tuesday, July 17, 2012 11:25 AM Subject: Re: [Bitcoin-development] bitcoin.org - remove hackathon Am 17.07.2012 11:17, schrieb Amir Taaki: Like I really do not wish to sell a speaker slot, but if I have to (to pay the bills) then it will be obvious due to scheduling and disclaimers that speakers are sponsors. Personally, i really don't mind sponsored speakers. If they have somewhat relevant topics they keep the event from becoming a circlejerk. for example i would really like to hear about payments innovation outside bitcoin. -- 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
[Bitcoin-development] Electrum mailing list
https://lists.sourceforge.net/lists/listinfo/electrum-discuss -- 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
[Bitcoin-development] Bitcoin Wallet for Android
Hey, I just saw this added to the clients page. One of the conditions we set for that page was that all the clients must have the entire sourcecode available for review, and users should be able to run it from the sourcecode. Is the sourcecode for this client available for review? I couldn't find it. Otherwise, we should make a separate section for non-opensource clients. -- 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] Bitcoin Wallet for Android
OK thanks. I just went and made those sections then saw your posts. Anyway we have a section for proprietary clients now. Please tell me if anything looks disagreeable, http://bitcoin.org/clients.html One thing I'm going to do is randomise the positioning order within sections upon refresh. - Original Message - From: m...@henricson.se m...@henricson.se To: bitcoin-development@lists.sourceforge.net Cc: Sent: Monday, July 9, 2012 11:19 AM Subject: Re: [Bitcoin-development] Bitcoin Wallet for Android Sources are available here: http://code.google.com/p/bitcoin-wallet/ Mats Quoting Amir Taaki zgen...@yahoo.com: Hey, I just saw this added to the clients page. One of the conditions we set for that page was that all the clients must have the entire sourcecode available for review, and users should be able to run it from the sourcecode. Is the sourcecode for this client available for review? I couldn't find it. Otherwise, we should make a separate section for non-opensource clients. -- 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 -- 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] Random order for clients page
JS randomisation is bad. People shouldn't need JS to view a webpage. Only you have a problem with this page. I don't see why Bitcoin-Qt needs to be first either when it dominates the front page. It is perfectly fine as it is. You are not a developer of any alternative clients, and this is a webpage for Bitcoin clients. I have made a change to remove a source of disputes, and make the process more fair and equal. Your suggestion to remove the clients page is your bias towards thinking that there should be only one Bitcoin client that everyone uses (the one which you contribute towards). If you want to suggest removing the clients page, then fine, lets also remove all reference to Bitcoin-Qt from the front-page and turn it into a http://bittorrent.org/ style website. Fact is that the other clients are rapidly becoming stable and mature, and the ecosystem is diversifying. The argument that the other clients were not up to scratch held maybe a few months ago, but not now. - Original Message - From: Gregory Maxwell gmaxw...@gmail.com To: Amir Taaki zgen...@yahoo.com Cc: bitcoin-development@lists.sourceforge.net bitcoin-development@lists.sourceforge.net Sent: Monday, July 9, 2012 5:04 PM Subject: Re: [Bitcoin-development] Random order for clients page On Mon, Jul 9, 2012 at 11:54 AM, Amir Taaki zgen...@yahoo.com wrote: Took me a while, but finally got it working. Entries on the clients page are randomly ordered when the page is generated. https://github.com/bitcoin/bitcoin.org/commit/6850fc8c83494d6ec415ea9d36fb98366373cc03 We should regenerate the page every 2 days. This gives fair exposure to all the clients listed. If you had authored this as a pull request rather than making the change unilaterally I would have recommended leaving it so the reference client was always first. I also would have suggested that it use JS randomization instead of jekyll in order to get more even coverage, though I think thats a more minor point. Some people were concerned when this page was created that it would just be a source of useless disputes. I think its becoming clear that this is the case. I think the cost of dealing with this page is starting to exceed the benefit it provides and we should probably consider removing 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] Random order for clients page
This page really does matter to alternative clients. If you measure the click through statistics, then they are a significant portion of the traffic. By removing this page, you are directly stunting Bitcoin's growth. The only thing that's changed between now and this morning is: - Addition of Bitcoin Wallet for Android - Randomisation of entries I actually got permission from everyone involved before making the page.If you want to remove the page, then we should see a vote by: - laanwj - gavin - sipa - jgarzik - BlueMatt - Diapolo - luke-jr - you - jim from multibit - gary rowe - ThomasV - me - etotheipi - Andreas Schildbach - justmoon - Mike Hearn You're proposing to remove the page. You know, and I know and I know that you know that nobody visits the Wiki. Your proposal is not move to Wiki really but remove from bitcoin.org. Keep bitcoin.org for Bitcoin-Qt only which is against the stated goals of the rest of your team members (gavin, sipa, jgarzik). Have you tried the new clients? I've tried all 4, and they are all well written. Try the new version of Electrum, https://gitorious.org/electrum/electrum - it's more featureful and secure than Bitcoin-Qt what with deterministic wallets, brain-wallets, prioritising addresses, frozen addresses, offline transactions - none of which Bitcoin-Qt has. MultiBit is also very good with QR integration and the ability for merchants to quickly set themselves up. It's full of guiding help text, and has this paradigm to allow people to work with keys. Bitcoin Wallet for Android has one of the best bitcoin UIs I've seen and is extremely well thought out in how the user navigates through the software. The Bitcoin network could function perfectly fine with Electrum nodes and miners. You would still have miners and we wouldn't have the problem now with huge blocks because miners would be economically incentivised to keep blocks small. But that's another discussion. Technically speaking, the randomisation is fine now. It achieves its intended effect, as the page is regenerated daily. This does not need to be a source of arguing. I see no problem with having this page be a neutral overview of the main clients (as we all agreed together in the beginning): - Source must be public, and users must be able to run from source. - Description should be non-spammy and neutral sounding. Cover the negative aspects. Randomisation of the order simply makes that fairer. Alphabetical is not a good option (as others have suggested) because it can be gamed. There is absolutely no reason to remove this page unless you think bitcoin.org is only for Bitcoin-Qt which is against the wishes of gavin, sipa, jgarzik, and the long-term stated goal of bitcoin.org as a neutral resource for the community. - Original Message - From: Gregory Maxwell gmaxw...@gmail.com To: Amir Taaki zgen...@yahoo.com Cc: bitcoin-development@lists.sourceforge.net bitcoin-development@lists.sourceforge.net Sent: Monday, July 9, 2012 6:46 PM Subject: Re: [Bitcoin-development] Random order for clients page On Mon, Jul 9, 2012 at 12:09 PM, Amir Taaki zgen...@yahoo.com wrote: JS randomisation is bad. People shouldn't need JS to view a webpage. JS randomization doesn't imply needing JS to view the page. It implies needing JS to see it in random order. You could also combine it with the server-side randomization if you care about non-js being non random, though I don't think it matters. As others have pointed out I don't generally think the randomization is good in principle, but if its done it should at least achieve its goals. Only you have a problem with this page. I don't see why Bitcoin-Qt needs to be first either when it dominates the front page. It is perfectly fine as it is. I'll let other people speak for themselves, but I did consult others before reverting your last batch of changes. More generally, we have pull requests in order to get some peer review of changes. Everyone should use them except for changes which are urgent or trivially safe. (Presumably everyone with access knows how to tell if their changes are likely to be risky or controversial) You are not a developer of any alternative clients, and this is a webpage for Bitcoin clients. I have made a change to remove a source of disputes, and make the process more fair and equal. Your suggestion to remove the clients page is your bias towards thinking that there should be only one Bitcoin client that everyone uses (the one which you contribute towards). I'm strongly supportive diversity in the Bitcoin network, and some alt client developers can speak to the positive prodding I've given them towards becoming more complete software. If I've said anything that suggests otherwise I'd love to be pointed to it in order to clarify my position. Unfortunately none of the primary alternatives are yet complete, the network would be non-function if it consisted entirely of multibit or electrum nodes
Re: [Bitcoin-development] Random order for clients page
By that time in the future, when there are many clients, there should just be a flat list or no list at all. - Original Message - From: Nils Schneider n...@nilsschneider.net To: bitcoin-development@lists.sourceforge.net Cc: Sent: Monday, July 9, 2012 6:33 PM Subject: Re: [Bitcoin-development] Random order for clients page I don't think that's a good idea as it can easily confuse or annoy users when things move around. The ordering should be preserved as much as possible so users can remember where they found a client they liked (e.g. 2nd row, 1st column and screenshot with light and blue colors). Making them search the entire page is inefficient and will just get worse once there are many clients on the page (and I think that's the goal). On 09.07.2012 17:54, Amir Taaki wrote: Took me a while, but finally got it working. Entries on the clients page are randomly ordered when the page is generated. https://github.com/bitcoin/bitcoin.org/commit/6850fc8c83494d6ec415ea9d36fb98366373cc03 We should regenerate the page every 2 days. This gives fair exposure to all the clients listed. -- 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 -- 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
It would be nice if Bitcoin was engineered this way from the start. The amount of workarounds, special cases and code bloat to deal with the fact that txs are non-unique was a massive headache for me. From: Mark Friedenbach m...@monetize.io To: Jeff Garzik jgar...@exmulti.com Cc: Bitcoin Development bitcoin-development@lists.sourceforge.net Sent: Friday, July 6, 2012 6:56 PM Subject: 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. But those issues are solvable through other, non-backwards incompatible means. For example, mandate that a transaction hash, output index refers to the first such pair that is not already spent. No? Mark -- 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] New P2P commands for diagnostics, SPV clients
Why though? The bottleneck is not network traffic but disk space usage/blockchain validation time. - Original Message - From: Mike Hearn m...@plan99.net To: Jeff Garzik jgar...@exmulti.com Cc: Bitcoin Development bitcoin-development@lists.sourceforge.net Sent: Friday, June 15, 2012 3:43 PM Subject: Re: [Bitcoin-development] New P2P commands for diagnostics, SPV clients Yes, the format is something that must be hashed out (no pun intended). Need input from potential users about what information they might need. Matts point that a branch-per-transaction may duplicate data is well made, that said, I suspect a format that tries to fix this would be much more complicated. How about see this project as a three part change? First step - add the mempool command and make nodes sync up their mempools on startup. Second step - if protocol version = X, the block message consists of a header + num transactions + vectorhash instead of the full transactions themselves. On receiving such a block, we go look to see which transactions we're missing from the mempool and request them with getdata. Each time we receive a tx message we check to see if it was one we were missing from a block. Once all transactions in the block message are in memory, we go ahead and assemble the block, then verify as per normal. This should speed up block propagation. Miners have an incentive to upgrade because it should reduce wasted work. Third step - new message, getmerkletx takes a vectorhash and returns a merkletx message: merkle branch missing the root + transaction data itself for each requested transaction. The filtering commands are added, so the block message now only lists transaction hashes that match the filter which can then be requested with getmerkletx. -- 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] Near-term scalability
less expensive. This is no more real or less artificial then an imposed licensing fee or the like and it is not subject to market forces. Sure, the market is not always efficient nor desirable. This seems more like a social question though about choice and information. I do strongly feel that users should have more control over their technology, and a say in how Bitcoin operates. It is our job to present the choices and inform them to make good decisions. If we think how to implement this with a social component of the users operating the network rather than hard and fast rules, I think that's the preferrable way. Part of the problem is that Satoshi didn't totally anticipate the growth of the network. The block reward (the subsidy) is too high, which is why transactions can afford to be so cheap. What would happen if blocks required a cumulative fee of XN BTC for N transactions before being accepted? - Original Message - From: Gregory Maxwell gmaxw...@gmail.com To: Amir Taaki zgen...@yahoo.com Cc: Sent: Friday, June 15, 2012 8:43 PM Subject: Re: [Bitcoin-development] Near-term scalability On Fri, Jun 15, 2012 at 2:38 PM, Amir Taaki zgen...@yahoo.com wrote: Forcing users to switch addresses per received payment to work around a bad fee system would be a braindead decision. You might love software and playing with web plugins, but not everyone does. Artists like Rap News can right now simply throw up an address and begin accepting donations. That's a hugely powerful and impactful selling point for Bitcoin. And that use case does not need fast confirmations! This is making the point. there are no artificial barriers to entry beyond the base cost. This network would always be competitive and strictly operate based on market dynamics. The users of bitcoin can collectively choose how expensive operating a full node is by accepting validation rules that allow it to be more or less expensive. This is no more real or less artificial then an imposed licensing fee or the like and it is not subject to market forces. -- 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] Proposed new P2P command and response: getcmds, cmdlist
Introspection/command discovery is nice, but I would prefer it to be immediately done in the first version exchange so no assumptions as to how a network is operating need to be made. I like the idea of a flat list of commands. It might make sense to have meta-commands that alias to groups of commands. i.e original for the current core subset up to (and including) pong. The aliases could exist in a text definition file which is held on github or bitcoin.org/ - Original Message - From: Jeff Garzik jgar...@exmulti.com To: Bitcoin Development bitcoin-development@lists.sourceforge.net Cc: Sent: Saturday, June 16, 2012 2:13 AM Subject: [Bitcoin-development] Proposed new P2P command and response: getcmds, cmdlist Outside of major features advertised network-wide in nService bits, P2P protocol lacks a good method of enumerating minor features or extensions. The version number increment is coarse-grained, and is not self-documenting. A simple extension which lists supported commands is added, as demonstrated in this pull request: https://github.com/bitcoin/bitcoin/pull/1471 Another option is for verack to return this information at login, eliminating the need for a separate command/response. -- 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. 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] SatoshiDice and Near-term scalability
Did anyone try sending them an email asking them to stop or offering help to fix their site? What did they say? I'm sure they would try to be accomodating. - Original Message - From: Jonathan Warren jonat...@bitcoinstats.org To: bitcoin-development@lists.sourceforge.net Cc: Sent: Saturday, June 16, 2012 4:35 AM Subject: Re: [Bitcoin-development] SatoshiDice and Near-term scalability Yes, I measure mainnet confirmation times on a regular basis. http://bitcoinstats.org/post/tx-confirmation-times-June2012.png Before fairly recently, fee-paying transactions never took anywhere close to this long to be confirmed. Jonathan Warren (Bitcointalk: Atheros) -Original Message- From: Jeff Garzik [mailto:jgar...@exmulti.com] Sent: Friday, June 15, 2012 1:17 PM To: bitcoin-development@lists.sourceforge.net Subject: [Bitcoin-development] SatoshiDice and Near-term scalability Hard-fork requires a very high level of community buy-in, because it shuts out older clients who will simply refuse to consider 1MB blocks valid. Anything approaching that level of change would need some good, hard data indicating that SatoshiDice was shutting out the majority of other traffic. Does anyone measure mainnet normal tx confirmation times on a regular basis? Any other hard data? -- 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
[Bitcoin-development] Fw: Punishing empty blocks?
That's a cool idea. Very meta. From: Peter Vessenes pe...@coinlab.com To: Stefan Thomas m...@justmoon.de Cc: bitcoin-development@lists.sourceforge.net Sent: Monday, May 28, 2012 4:54 PM Subject: Re: [Bitcoin-development] Punishing empty blocks? One of the issues here though is that it would be nice if miners published their own tx rules -- it might be hard to impute them from data. I had started a thread about this on bitcoin.org some time ago, and I don't recall what the general outcome was. I had imagined an open service whereby a miner could publish a short string in their conbase tying to the service and the service would have different metadata, including the miner's transaction guarantees. We offered to host this before, and would still be willing to host such a service. Peter On Sat, May 26, 2012 at 7:52 AM, Stefan Thomas m...@justmoon.de wrote: Zooko is spot on - slower confirmations will give people a reason to set higher fees. As soon as fees reach a level where they matter, even botnet operators will be looking into ways of including transactions for some extra profit. In the meantime slightly slower confirmations aren't a problem. Consider that even if it takes four blocks to get your transaction included instead of one, once it is included, you still benefit from every new block in terms of security. So if you're looking for six confirmations for example, even a three block delay will only be a 50% delay for you. And of course there are techniques for instant transactions which continue to be refined and improved. As for the proposed solutions: Punishing 1-tx blocks is complete and utter nonsense. It's trivial to include a bogus second transaction. Any additional challenges towards miners like hashes of the previous block are at best useless. If I was running a botnet, I'd just grab that hash from a website (pretty good chance Blockchain.info will have it :P) or mining pool or wherever and keep going undeterred. At worst they may affect scalability one day. You might imagine a peer-to-peer network of miners who for cost reasons don't download all blocks anymore, but verify only a percentage of them at random. They might then exchange messages about invalid blocks including a proof (invalid tx, merkle branch) why the block is invalid. This is just one idea, the point is that assumptions about what a legitimate miner looks like may not always hold in the future. Finally, there is an ethical aspect as well. If a miner wishes not to include my transaction that is his choice. He has no more an obligation to sell his service to me than I have to buy it from him. If I really, really want him to include my transaction I will have to offer to pay more. If we as developers think that confirmations are too slow or that more blocks should include transactions, then the right measures would be: - Educating users about the relationship between confirmation speed and fees - Raising the default transaction fee Every market has a supply curve, so it is economically to be expected that there will be some miners who don't include transactions, simply because they are at that end of the supply curve where it is not worth it for them to sell their service. All markets must have a certain tension - there must be miners who don't include transactions for there to be users who want their transactions included more quickly. In other words there must be somebody not confirming if confirmations are to have value. If you interfere with that all you'll accomplish is keep transaction fees below market level, which will make the transition from inflation-financed hashing to transaction-financed hashing more painful and disruptive. Cheers, Stefan -- 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 Google+ -- 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
Re: [Bitcoin-development] BIP 33 - Stratized Nodes
A bloom filter seems like an interesting idea. However this proposal is concerned mainly with the initialisation stage, whereas this bloom filter is for pushed blocks. This proposal still updates new transactions and blocks in the same way, and it's not inconceivable to later use a bloom filter to make that part more efficient (although it's questionable if pushing this server side would be a good idea as it would now need to track an additional client state). From: Mike Hearn m...@plan99.net To: Amir Taaki zgen...@yahoo.com Cc: bitcoin-development@lists.sourceforge.net bitcoin-development@lists.sourceforge.net Sent: Wednesday, May 16, 2012 5:46 PM Subject: Re: [Bitcoin-development] BIP 33 - Stratized Nodes Thanks for getting this started. With regards to the specific proposal, I don't believe it's the best option and still plan to eventually implement the original design outlined more than a year ago in this thread: https://bitcointalk.org/index.php?topic=7972.msg116285#msg116285 Namely that you use a new protocol command to set a Bloom filter on a connection. Only transactions matching that filter will appear in relayed inventory. Blocks that are requested will arrive as a header plus transaction/merkle branch pairs. Clients are expected to maintain and track the block chain as per usual, but instead of downloading the whole chain and then dropping the irrelevant transactions, that filtering is done server side. By strengthening or weakening the Bloom filters you can choose your preferred point on the privacy/bandwidth-usage spectrum. It is a fairly simple change to the Satoshi and BitcoinJ codebases but still allows clients to gain confidence in their balance by examining the chain, and this is true even in the presence of a hijacked internet connection (you can't trust pending transactions that way, but you can still trust confirmed transactions). The filters would be applied to each data block in each script rather than having a specific knowledge of addresses. In this way you can select for things like multisig outputs or outputs which don't use addresses / pubkeys to authenticate. I could write a BIP for this alternative protocol if somebody else wants to implement it. I was going to wait until I had time to do both BIP and implementation, but I think some simple optimizations to BitcoinJ can keep its performance good enough for the short term. -- 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 33 - Stratized Nodes
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. Stratized nodes do discovery as normal. Service nodes are explicitly chosen like IRC servers are for IRC clients. 4) What are the economic motivations to run a stratized server? Other than cheating people of course. None. Same as BitTorrent super-nodes, Tor relays or email servers. People don't need economic motivation for everything. 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. That's a bad idea. I prefer to keep each request minimal to prevent resource starvation and simplify the protocol (while shifting the onus onto the client). Also the history can be resolved with multiple services while the data is being downloaded and sorted. -- 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
[Bitcoin-development] Bitcoin intro and talks in Berlin (11th May at 20:00)
c-base is holding a day on p2p technologies on the 11th. From 20:00 will be the section on Bitcoin. If you want to do a talk, then email me (gen...@riseup.net) and I’ll add you to the schedule. -- 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] new bitcoin.org clients page
This is like the most annoying thing about email. Often with group emails, we'll be having a conversation then someone will click reply instead of group reply and the convo will go on for a while. Eventually I'll realise the persons are missing and add them back in. On Yahoo mail (which I use for spam/mailing lists), to do reply all involves clicking a tab, scrolling down and clicking Reply All. Normally I instead go through the steps of reply, delete To, re-enter bitco... select drop down, click send. Anyone know how to make reply all the default in mutt? And how can I exclude it from re-including my own email when I do a group reply so I don't get the same email again. - Original Message - From: Jeff Garzik jgar...@exmulti.com To: grarpamp grarp...@gmail.com Cc: bitcoin-development@lists.sourceforge.net Sent: Wednesday, May 2, 2012 7:29 PM Subject: Re: [Bitcoin-development] new bitcoin.org clients page On Wed, May 2, 2012 at 12:58 PM, grarpamp grarp...@gmail.com wrote: Try Reply to All That puts the sender in 'to' and list in 'cc', which dupes to the sender and eventually blows out the to and cc lines as everyone chimes in and doesn't trim. 'reply to' solves most of that. assuming the list sw can do it. Reply-To Munging Considered Harmful http://www.unicom.com/pw/reply-to-harmful.html -- 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. 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
[Bitcoin-development] new bitcoin.org clients page
Check it :) https://github.com/bitcoin/bitcoin.org/pull/34 -- 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] new bitcoin.org clients page
Are we looking at the same list? Because here is the order I added: Bitcoin-Qt, Armory, Electrum and MultiBit. Maybe try CTRL-F5 to force a refresh of your browser. Also about the descriptions: yeah I know. I think it's better to put this up first and then have everyone submit their own descriptions and screenshots. Otherwise it'll be a nightmare to coordinate until everything is perfect. I did message you on IRC today but maybe you were offline. I didn't copy paste the Armory description from the website because it really sounds too spammy like a sales pitch. Here I was trying to give an even handed balanced overview of all the clients. For each client I was trying to empaphise a 'theme'. Bitcoin-Qt is stability. Armory is advanced. Electrum is convenient. MultiBit is ease of use. From: Alan Reiner etothe...@gmail.com To: Amir Taaki zgen...@yahoo.com Cc: bitcoin-development@lists.sourceforge.net bitcoin-development@lists.sourceforge.net Sent: Monday, April 30, 2012 7:23 PM Subject: Re: [Bitcoin-development] new bitcoin.org clients page Hey, looks good! I'm glad to see them sorted alphabetically :) A couple comments: I don't think the entries for wallet security and backups accurately describe Armory. Wallet Security should say Encrypt/Offline or something to to that effect -- after all, offline wallets are the holy grail feature of the Armory. And backups should say something like One-time Printable if it fits within the box. Otherwise, I really like the layout and design. Although despite the fact I enjoy being first on the list, I think Bitcoin-Qt should still go first. It is the reference client, and I think it's relevant that it is the de-facto client for the majority of users, and the one with the most quality control and stability. -Alan On Mon, Apr 30, 2012 at 1:50 PM, Amir Taaki zgen...@yahoo.com wrote: Check it :) https://github.com/bitcoin/bitcoin.org/pull/34 -- 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
[Bitcoin-development] bitcoin.org luke-jr/multiclient branch
Hi, Can we pull this? It's been there for almost 20 days now. https://github.com/bitcoin/bitcoin.org/pull/32 My comment: As a first step, this should probably be pulled right away and then any improvements can be made after. Lets get the ball rolling rather than debating the colour of the bike-shed! http://hackerspaces.org/wiki/The_Bikeshed_Anti-Pattern Although I agree with Mike Hearn - far better would be a grid of 4 columns and X rows. Each box has a linkable title, a picture and then 850 word blurb from the project. I mean where would libbitcoin fit in here? I'd want to say the design philosophy behind it and that there's Python bindings - a circular peg that doesn't fit in the square boxes of this table. Although whatever, that's not important. I'm just happy to see MultiBit, Electrum and Armory get exposure. Anyone that wants to see what it looks like can add this to their hosts file: 176.31.24.241 bitcoin.org Then navigate to http://bitcoin.org -- 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
look at the first line of the if statement
// Check for conflicts with in-memory transactions
CTransaction* ptxOld = NULL;
for (unsigned int i = 0; i tx.vin.size(); i++)
{
COutPoint outpoint = tx.vin[i].prevout;
if (mapNextTx.count(outpoint))
{
// Disable replacement feature for now
return false;
// Allow replacing with a newer version of the same transaction
if (i != 0)
return false;
ptxOld = mapNextTx[outpoint].ptx;
if (ptxOld-IsFinal())
return false;
if (!tx.IsNewerThan(*ptxOld))
return false;
for (unsigned int i = 0; i tx.vin.size(); i++)
{
COutPoint outpoint = tx.vin[i].prevout;
if (!mapNextTx.count(outpoint) || mapNextTx[outpoint].ptx !=
ptxOld)
return false;
}
break;
}
}
From: Peter Vessenes pe...@coinlab.com
To: Peter Todd p...@petertodd.org
Cc: bitcoin-development@lists.sourceforge.net
Sent: Thursday, April 26, 2012 6:11 PM
Subject: 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
[Bitcoin-development] AreInputsStandard() mistake
Hey, Only a small thing - I think the first check in that function should be an assert. There is a problem if that function is called a coinbase tx. -- 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] Adding request/reply id in messages
This is a bad idea. The bitcoin protocol is (mostly) stateless. Stateless protocols are more secure. From: Pieter Wuille pieter.wui...@gmail.com To: Gavin Andresen gavinandre...@gmail.com Cc: bitcoin-development@lists.sourceforge.net Sent: Thursday, April 12, 2012 5:01 PM Subject: Re: [Bitcoin-development] Adding request/reply id in messages On Thu, Apr 12, 2012 at 11:41:05AM -0400, Gavin Andresen wrote: On Wed, Apr 11, 2012 at 2:39 PM, Christian Bodt sirk...@gmail.com wrote: 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) That seems like a perfectly reasonable protocol improvement to me. Anybody else have an opinion? If there is a reasonable use for it, I have no objections. However: the bitcoin P2P protocol is not fully request-reply based, and trying to use it that may be be less intuitive than how it looks. For example, doing a second identical getblocks request will not result in more inv replies, as the client prevents retransmits. This is not a large problem, but maybe such an extension should also include an extra denied message, which is sent if the client is unwilling to answer (and may also be used to report transactions that are not accepted into the memory pool, for example). -- Pieter -- 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 Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Adding request/reply id in messages
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 Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP 16 changes (list inside)
Hi, Is this an accurate and precise summary of the changes needed for P2SH and BIP 16? == Block validation (starting with ProcessBlock) == * SigOpCount is now a LegacySigOpCount (CheckBlock) * Main body of AcceptBlock() and rest of ProcessBlock() is unchanged. * AddToBlockIndex() unchanged * Some nice efficient improvements to SetBestChain(), but not related to BIP 16 * ConnectBlock() has new SigOp calculation. * No important changes to FetchInputs()/ConnectInputs() == Script == * Solver has special case to check for TX_SCRIPTHASH. Returns hash of input eval script * Another Solver which a) returns signature of pubkey script or b) TX_SCRIPTHASH - finds redeem script in KeyStore and returns it. * ExtractAddress(es) * VerifyScript: ** After running input script (scriptSig), copy stack ** Evaluate script as normal ** if block date (fValidatePayToScriptHash) and output script (scriptPubKey) is P2SH: *** scriptSig must be only push operations *** evaluate last item of copied stack as a script using the copied stack as the stack * SigOpCount (used inside CBlock::ConnectBlock main loop) does scoring checksigs and multisigs. ** Newly added DecodeOP_N to normal SigOpCount == Address == * Set main hash160 data with a beginning byte (nVersion) of 0x05 -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP 18 (or not?)
Hi, luke-jr withdrew BIP 16 and put forwards support for BIP 17. So now there's a consensus to move forwards. However he submitted BIP 18 to me today. From looking it over, I'm not even sure the idea is tenable nor see the purpose when we are adopting BIP 17. Personally I'd rather not see a high turnover in protocol design when something works (now that we have viable multisig transactions) even compromising on the position of a perfect design. https://en.bitcoin.it/wiki/BIP_0018 Usually for a BIP, someone submits it to me, I review to see whether the idea is technically sound (not making judgements on the validity), the community discusses the idea and I evaluate the support at the end to change the status. In general I try to accept all BIPs in the interests of fairness, rather than holding a vote or being the executioner. Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to bitcoin-development@lists.sourceforge.net. This gives the author a chance to flesh out the draft BIP to make properly formatted, of high quality, and to address initial concerns about the proposal. Following a discussion, the proposal should be sent to the Bitcoin-dev list with the draft BIP and the BIP editors b...@bitcoin.org. This draft must be written in BIP style as described below, else it will be sent back without further regard until proper formatting rules are followed. I don't think BIP 18 has followed this discussion before being accepted. Neither have many other BIPs as we're a small community, and so far we avoided this unneeded level of bureaucracy. However I think this is a good thing to do here. Should BIP 18 be accepted into the repo or not? The BIP editor will not unreasonably deny a BIP. Reasons for denying BIP status include duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy. For a BIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly. (quotes from BIP 1) -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] JSON-RPC is BIP territory or not?
Hi, I got sent this BIP: https://en.bitcoin.it/wiki/BIP_DRAFT:_getmemorypool#JSON-RPC_Method:_getmemorypool What is your opinion on this? Is it BIP related? It is a implementation-specific non-bitcoin-protocol proposal. My understanding of BIPs is that they apply across bitcoin implementations and largely focus on the most generic use-cases (like the URIs) and the protocol. Things which affect all clients, and allow the system to function as a united whole. That BIPs especially focus on the protocol, and that something like this is outside the mandate of the BIP process. For instance, we could imagine a future scenario. Bitcoin-Qt is currently based off bitcoind's codebase. However wumpus built the client in mind with an abstraction layer to enable multiple backends (a good design). In our hypothetical situation, there are 3 different backend codebases using Bitcoin-Qt. I do not think a proposal to mandate a changing to Bitcoin-Qt's abstraction layer or a change in the UI placement would be appropriate BIP material. OTOH, many clients do need to make use of URIs and the BIP process is totally correct, as it standardises a behaviour which is needed for interoperability of the network and community. Thoughts?-- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Duplicate transactions vulnerability
I support BIP 30. I gave it a thought. The other ways of resolving this issue, all have various niggles. This is the best way. From: Pieter Wuille pieter.wui...@gmail.com To: Zooko Wilcox-O'Hearn zo...@zooko.com Cc: Bitcoin Dev bitcoin-development@lists.sourceforge.net Sent: Wednesday, February 29, 2012 4:47 PM Subject: Re: [Bitcoin-development] Duplicate transactions vulnerability On Tue, Feb 28, 2012 at 06:41:31PM -0700, Zooko Wilcox-O'Hearn wrote: Could you spell out the attack explicitly? Presumably there aren't a lot of people with the malice energy to perform the attack but not to figure it out for themselves. I, however, have the niceness energy to think about it for a few minutes but not to figure it out for myself. If in your opinion it is realistically dangerous to post it publicly, would you be so kind as to include me in the private sharing of the explanation? It's not exactly a secret anymore, as the patch also references it. Russell O'Connor described the attack on his blog: http://r6.ca/blog/20120206T005236Z.html -- Pieter -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development-- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP 21 accepted, new BIP 19
BIP 21 had broad consensus among the major implementations: https://en.bitcoin.it/wiki/BIP_0021 BIP 19 is a document to propose adding a new payment type to the scripting system's template list. https://en.bitcoin.it/wiki/BIP_0019 I haven't fully evaluated it completely but it seems solid. My only thoughts is that it uses a bunch of arithmetic operators which can behave in strange ways.-- Try before you buy = See our experts in action! 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-dev2___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N
excuse me if it was already discussed, but maybe using satoshis instead of decimal bitcoin would be better ? choice? We all know about pains with proper handling decimal numbers across of all implementations - and it's not only about json-rpc. Yeah well it's up to the people who are making this stuff to decide :) On Tue, Jan 31, 2012 at 3:27 PM, Amir Taaki zgen...@yahoo.com wrote: BIP 20 really has no support among implementations such as Bitcoin-Qt, Electrum, MultiBit or Bitcoin-JS. As the most active and visible user facing GUI projects (all with some form of URI Scheme), their opinion carries the most weight. To a lesser degree Bitcoin-Qt has the large majority of users too (although that's a line of reasoning I'd discourage). Normally we should probably Reject BIP 21 and re-submit a new standard (for history's sake), but as a) BIP 21 is largely a copy paste of BIP 20 sans some sections b) it is still a draft, probably the best thing here is if you all agree on something to run it by BlueMatt and then we'll make it the new BIP 21. I can see a consensus forming on most parts. Just the send private key is contentious, and there's the topic of adding a time to expire field for merchants (this is a very good idea IMO). Also BIP 20 is problematic because it is incompatible with about every standard on the web. All the HTML, URI and everything uses decimal numbers alone. I see no reason for breaking with tradition. Note that everytime I have to write Color or Vectorize (as a British speaker) in my code, I die a little inside. But it's convention and American English = International English. Also it would be cool if all code used a *real* international language (like Esperanto) but the world ain't perfect! We live in a decimal-counting English-speaking Windows-using God-worshipping world! (no offense to decimal-counting English-speaking Windows-using God-worshipping world- I do half those things too :) -- 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 -- 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
[Bitcoin-development] Fw: Quote on BIP 16
(oops sorry greg- replied to you by mistake) That address he gives is 77 characters/bytes (same thing). What I'm asking is how can it be so small. I know that it's encoding a script, but then I started trying to imagine what kind of script and to me it seems that 2 public keys are too large for those 77 characters when encoded. That is the example quoted on the forums: 57HrrfEw6ZgRS58dygiHhfN7vVhaPaBE7HrrfEw6ZgRS58dygiHhfN7vVhaPaBiTE7vVhaPaBE7Hr Could it be a mistake? - Original Message - From: Gregory Maxwell gmaxw...@gmail.com To: Amir Taaki zgen...@yahoo.com Cc: bitcoin-development@lists.sourceforge.net bitcoin-development@lists.sourceforge.net Sent: Sunday, January 29, 2012 5:19 AM Subject: Re: [Bitcoin-development] Quote on BIP 16 On Sat, Jan 28, 2012 at 11:52 PM, Amir Taaki zgen...@yahoo.com wrote: How could you have a 70 byte long address without a P2SH scheme? Is this a mistake? ... No it's not a mistake. P2SH _prevents_ needing long addresses. Lets unpack the acronym pay to script _hash_. Hashes only need to be 128-256 bits in size or so to have acceptable security, so you don't need something longer than that for paying to a hash. Note that gavin is saying 70 characters, not bytes. Without some form of P2SH then only way for you to make a personal choice of asking people to pay to a two-factor protected account or two a multiparty trust that manages the finances of an organization is using some form of P2S, pay-to-script. In other words, you'd have to have an address that encodes a full script specification for the sender to pay to, instead of just encoding its hash. As a result these addresses would be much longer (and potentially very long). The minimum size of a two address involving encoded script would be on that order, but they get bigger quite quickly if you add more options to the script (actually 70 sounds quite small, it should be more like 100 for a minimum two pubkey script). In addition to the unworkability of very long addresses as described by gavin (amusingly I am unable to copy and paste the quoted example in one go) a P2S solution has several problems which you might consider more or less important: (1) They are highly vulnerable to invisible substitution. E.g. I can trivially take a P2S address, change one or two characters and get a script which is redeemable by anyone. With P2SH you have to do computation which is exponential in the number of unchanged digits to get a look alike address. (2) The sender is fully responsible for fees related to the enlarged transactions. Even if _you're_ willing to take the txn-processing time and fee burden of a 30 person joint trust address, random e-commerce sites will not be and will randomly reject your addresses. (3) They create another input vector for non-trivial data which must be inspected and validated, potentially presenting an attack surface. (4) They leave the complicated (long) release rules in the transaction outputs. When a transaction is mined we can't be sure if it will ever be redeemed. The outputs are unprunable. In a future world where many nodes prune output space is far more important than input space and it would make sense to require more fees for it because we're never sure how long it would need to be stored (making it an attractive target for someone who wants to make Bitcoin unusable by spamming it with worthless data). P2SH reduces output sizes to the absolute minimum without inflating the total data size. -- Try before you buy = See our experts in action! 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-dev2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Controlled block generation in fuzzer for testing blockchain
I added the ability to do controlled generation of blocks to gavin's fuzzer https://github.com/genjix/bitcoin/tree/fuzzer bitcoind -daemon bitcoind setfuzzpreviousblock 0019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f bitcoind setgenerate true It will start hashing the block with the previous hash field set to 0019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f and the target as 0x1dff On completion it will dump the hex value of the block to debug.log and exit. You can then feed that block to your implementation in whatever controlled manner you wish (i.e with libbitcoin I made a simple tool in a few lines to read the hex and send it via the network in localhost). If anyone wants the libbitcoin tool then let me know and i'll paste it over on IRC. -- Try before you buy = See our experts in action! 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-dev2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Quote on BIP 16
Gavin said: Part of the controversy is whether really long bitcoin addresses would work-- would it be OK if the new bitcoin addresses were really long and looked something like this: 57HrrfEw6ZgRS58dygiHhfN7vVhaPaBE7HrrfEw6ZgRS58dygiHhfN7vVhaPaBiTE7vVhaPaBE7Hr (or possibly even longer) I've argued no: past 70 or so characters it becomes a lot harder to copy and paste, a lot harder to scan an address with your eyes to see if you're paying who you think you're paying, harder to create a readable QR code, harder to upgrade website or database code that deals with bitcoin addresses, etc. There is rough consensus that very-long addresses are not workable. How could you have a 70 byte long address without a P2SH scheme? Is this a mistake? -- Try before you buy = See our experts in action! 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-dev2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Quote on BIP 16
2 compressed pubkeys - Original Message - From: Amir Taaki zgen...@yahoo.com To: bitcoin-development@lists.sourceforge.net bitcoin-development@lists.sourceforge.net Cc: Sent: Sunday, January 29, 2012 4:52 AM Subject: [Bitcoin-development] Quote on BIP 16 Gavin said: Part of the controversy is whether really long bitcoin addresses would work-- would it be OK if the new bitcoin addresses were really long and looked something like this: 57HrrfEw6ZgRS58dygiHhfN7vVhaPaBE7HrrfEw6ZgRS58dygiHhfN7vVhaPaBiTE7vVhaPaBE7Hr (or possibly even longer) I've argued no: past 70 or so characters it becomes a lot harder to copy and paste, a lot harder to scan an address with your eyes to see if you're paying who you think you're paying, harder to create a readable QR code, harder to upgrade website or database code that deals with bitcoin addresses, etc. There is rough consensus that very-long addresses are not workable. How could you have a 70 byte long address without a P2SH scheme? Is this a mistake? -- Try before you buy = See our experts in action! 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-dev2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Try before you buy = See our experts in action! 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-dev2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] GetBlocksToMaturity
Why add 20 to COINBASE_MATURITY there? The underlying protocol accepts spent transactions at 100 (COINBASE_MATURITY) so this seems more like a measure to put people off spending until 120 confirms. If you are determined enough to hack your client, you can still spend before 120 but after 100. Why is this? Did Satoshi overestimate how many competing races there would be between mined blocks?-- Try before you buy = See our experts in action! 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-dev2___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP 0020: URI Scheme
BIP 0020 is the old URI scheme BIPisized. ATM it is Draft status. I do not know enough about the discussion back last year to know whether to move it to Accepted status or not. My feelings are that having a re-decision (even if it was accepted last year) is healthy since it makes no sense to have a standard before a standardisation process existed. For now, it is Draft status until there's a general agreement. -- Try before you buy = See our experts in action! 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-dev2___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Fuzzer?
Hey, I heard there is a fuzzer in the works? Where can I find more details of this? I'm going to write one for libbitcoin, but if one already exists then I'd rather build on and use that. Something simple like: - Set previous block hash, set current target - Start hashing - Connect and send to specified host (i.e localhost) That way I can force re-organisations and stress the blockchain algorithm. Should be trivial for me to build, but worth asking anyway :) Thanks -- 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
[Bitcoin-development] Meeting 10 Jan 2012 at 21:00 UTC
Hey, Will get around to that write-up. Here is the page for next Tuesday: https://en.bitcoin.it/wiki//10_Jan_2012 Feel free to add talking/discussion points to the agenda. -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Meeting 21:00 UTC #bitcoin-dev Freenode IRC
This meeting is to discuss the new OP_EVAL changes coming to bitcoin. A good summary of the past discussion so far by justmoon can be found: http://privatepaste.com/4088b049af Hopefully this can become a weekly thing. For now this is to discuss and inform about the coming changes to bitcoin. -- Where: Freenode IRC #bitcoin-dev When: 21:00 UTC (16:00 New York time) until 22:00* What: OP_EVAL Bitcoin is starting decentralising as any healthy free thinking community should. Projects are thiving and the economy is growing. New ideas are being realised and will edge out old models disruptively. My hope is that we don't all become fractured. By having weekly regular meetings, projects can harmonise in lock step. Concepts and algorithms can be proposed and debated. You'd be surprised what having a scheduled regular platform can achieve. A soap-box on an island in central waters. For me, I don't have time to wade through IRC discussions, forum posts and mailing lists. At least if the important things are discussed in one place it makes bitcoin development and the system more accessible. Before meeting: - A wiki page is created for in advance of a weekly meeting. - Announced on forums/mailing lists. - Throughout the week talking points are added to the meeting page. After: - Log of discussion is posted online. - I will type an accessible summary for the community at large on http://bitcoinmedia.com/ - Next weekly meeting is scheduled. Amir Taaki *We can go over this hour, but this is to stop meetings dwindling off topic into banal banter and stay focused. -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Protocol extensions
Has anyone considered 'snapshot' frames (blocks). Message to node: getsnapshot: hash Node responds with a 'block' message. Then the hash for that particular snapshot is hardcoded into the sourcecode. It would replace the checkpoints and use the last hash in that list. Validating blocks is pretty fast right up until block 135k, which is where time taken balloons and starts become exponentially slower. As blockchain grows linearly, resources needed grows exponentially if you think about it. From: Alan Reiner etothe...@gmail.com To: bitcoin-development@lists.sourceforge.net Sent: Sunday, December 18, 2011 6:06 PM Subject: Re: [Bitcoin-development] Protocol extensions The whole point of having headers built at a constant size and generation rate is to minimize the amount of data needed to understand of the blockchain while simultaneously maximizing integrity/security in the presence of untrusted nodes. Barring the 50%-attack, you only need a couple honest nodes out of 50 to stay safe (as long as you're waiting for your 6 confirmations). In fact, I would argue that a full node (Satoshi client), has the same level of security as a headers-only client... because they both base all their verification decisions on computations that end with comparing hashes to the longest-chain headers. In the case that an attacker figures out how to isolate your node entirely and start feeing you poisoned blocks, then you are vulnerable with any kind of node, full or lightweight. I don't see where the reduced security is. The only issue I see is that a truly light-weight, headers-only node will be having to download an entire block to get one transaction it needs. This would be significantly alleviated if nodes can start requesting merkle-trees directly, even without merkle-branch-pruning. If a node can ask for a tx and the tx-hash-list of the block that incorporated that tx, he can easily verify his tx against his no-need-to-trust-anyone headers, and doesn't have to download MBs for every one. As for blockchain pruning... I think it's absolutely critical to find a way to do this, for all nodes. I am swayed by Dan Kaminsky's scalability warnings, and my instinct tells me that leaving full verification to a select few deep-pockets nodes in the future opens up all sorts of centralization/power-corporation issues that is contrary to the Bitcoin concept. It is in everyone's best interest to make it as easy as possible for anyone to act as a full node (if possible). As such, I believe that the current system of minimizing TxOut size is the right one. TxIns take up 0 bytes space in the long-run when taking into account any blockchain pruning/snapshot idea (except for nLocktime/seq transactions where the TxIn might have to be saved). -Alan On 12/18/2011 12:09 PM, theymos wrote: On Sat, Dec 17, 2011, at 05:27 PM, Jordan Mack wrote: I don't like the idea of a header only client, unless this is just an interim action until the full block chain is downloaded in the background. Development of these types of clients is probably inevitable, but I believe that this breaks the most fundamental aspects of Bitcoin's security model. If a client has only headers, it cannot do full verification, and it is trusting the data from random anonymous peers. A headers-only client is much better than trusting anyone, since an attacker needs 50% of the network's computational power to trick such clients. For everyone to keep being a full node, hardware costs would need to constantly go down enough for all nodes to be able to handle enough transactions to meet demand. If hardware doesn't become cheap enough quickly enough, either some people would be unable to handle being full nodes, or the max block size wouldn't rise enough to meet demand and transaction fees would become noncompetitive. -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___
Re: [Bitcoin-development] [BIP 15] Aliases
This is maybe the best idea. I added it: https://en.bitcoin.it/wiki/BIP_0015#IP_Transactions Things I like about this: - IP transactions are useful, but have a security flaw. This mitigates their security problems. - The code for IP transactions is already in Satoshi client. If other clients want to add IP transactions, then it can be done with minimal fuss/bloat. I feel that for any protocol extension, less is more. The less code needed, the better the extension. Not always but generally we want to avoid bitcoin protocol bloat which *will* happen far in the future. The only way to mitigate how spaghettified the standard will be in the future, is by careful cautious planning now. - We can have a proxy node running 24/7 for us, serving our public keys in lieu of us. From: theymos they...@mm.st To: bitcoin-development@lists.sourceforge.net Sent: Thursday, December 15, 2011 7:59 PM Subject: Re: [Bitcoin-development] [BIP 15] Aliases Bitcoin already has code and a protocol for transactions to IP addresses. Why not reuse that for dynamic address lookup? Just a few changes are necessary to enable complete u...@server.com handling: - Extend the protocol so that reply messages can be signed by a fixed public key - Extend checkorder messages so they can specify an account to send BTC to. Or standardize on how to put the account into the message field. - Enable DNS lookups for IP transactions. The DNS-only proposals could also be used here to avoid having to use the IP transaction protocol sometimes. The public key for signing reply messages can be gotten from TXT records. This will be safe with DNSSEC and Namecoin. With plain DNS Bitcoin could take a SSH-like approach and ask the user to verify the public key the first time it is used, remembering it later. DoS attacks are already handled by the IP transactions code: the same IP address is always given the same bitcoin address until it pays to that bitcoin address. -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development-- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] [BIP 15] Aliases
I wrote this pre-draft: https://en.bitcoin.it/wiki/BIP_0015 It's merely a starter for discussions. Aliases are a way to lookup bitcoin addresses so I can type gen...@genjix.net instead of 1jkddsjdskjwnk2j3kj232kjdkj -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
I'm confused about the problem we're trying to solve. I was in brmlab and wanted to pay 1 BTC for a Club Mate. They had on the wall a picture of their QR code and a bitcoin address. I don't own a mobile phone so the QR code is useless. Then I remembered FirstBits, went to my terminal and typed 1brmlab. I got their bitcoin address from the website and copied that, then opened my terminal and pasted that in to send 1 BTC. And these proposals for Namecoin, would make bitcoin implementations dependent on unproven technology. HTTPS/DNSSEC have been around a long time and are responsible for many mission critical systems. There's a lot of momentum behind those projects. Namecoin by contrast, could die tomorrow. And it isn't a big deal that they're centralised. This is a convenience for end users and does not affect the core system much. tl;dr: usability -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Lock protocol version numbers
From talking with Patrick Strateman (phantomcircuit), he suggested this idea (which I will elaborate more on in the BIP): User-agent strings are a good starting point, however they aren't easy for parsing so we'll make a small modification to them. We need a hierarchy from protocol, variant, gui, flavour, build /Satoshi:314700/bitcoin-qt:0.4/ How does that sound? In BitcoinJ's case: /BitcoinJ:0.2/AndroidBuild:0.8/ Thoughts: - Do we need a freely defined comments field? /BitcoinJ:0.2[iPad; U; CPU OS 3_2_1]/AndroidBuild:0.8/ /Satoshi:314700/bitcoin-qt:0.4[Ubuntu Oneiric]/ From: Christian Decker decker.christ...@gmail.com To: Mike Hearn m...@plan99.net Cc: Amir Taaki zgen...@yahoo.com; bitcoin-development@lists.sourceforge.net bitcoin-development@lists.sourceforge.net Sent: Saturday, November 5, 2011 2:45 PM Subject: Re: [Bitcoin-development] Lock protocol version numbers On BitDroid I stopped updating the protocol version at 31700 and set the string to be both Version and Client, just like BitcoinJ :-) On Sat, Nov 5, 2011 at 3:32 PM, Mike Hearn m...@plan99.net wrote: BitCoinJ already sets the subver field to its name and version. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Lock protocol version numbers
Hey, Can we lock the version numbers to be the protocol version (which changes rarely) and instead use the sub_version_num field + revision number for individual builds? Satoshi 0.4 BitcoinJava 120311 bitcoin-js 6 Like so. Otherwise we will have version bumping insanity :) -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Lock protocol version numbers
Point taken. About the sub_version_num though. I prefer to let the field by defined clients however they wish, with just a guideline suggestion that IDENTIFIER VERSION is a format they should follow. The idea being that different projects would have different release scheduling schemes and it'd be restrictive to lock people into the popular major.minor system. So for the current bitcoin to find out the version number of other clients (if it was needed), it would have to parse the number from the string: Satoshi 0.5 Although there would be little reason for this with a sane protocol versioning scheme. If we're agreed then I'll start on that BIP. From: Gavin Andresen gavinandre...@gmail.com To: Amir Taaki zgen...@yahoo.com Sent: Wednesday, November 2, 2011 9:34 PM Subject: Re: [Bitcoin-development] Lock protocol version numbers Good idea. Sounds perfect for a BIP On Wed, Nov 2, 2011 at 5:23 PM, Amir Taaki zgen...@yahoo.com wrote: Hey, Can we lock the version numbers to be the protocol version (which changes rarely) and instead use the sub_version_num field + revision number for individual builds? -- -- Gavin Andresen-- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Lock protocol version numbers
Bitcoin is the protocol. The client protocol identifier needs a unique name. It is not a public name that anybody ever sees except protocol developers. For instance with libbitcoin, there might be several clients using it, but they'd all have the same protocol identifier. I think calling it Satoshi is apt homage to the person who made the original client reference protocol. Satoshi BitcoinCommunityOriginal ... Take your pick. From: Luke-Jr l...@dashjr.org To: bitcoin-development@lists.sourceforge.net bitcoin-development@lists.sourceforge.net Cc: Amir Taaki zgen...@yahoo.com Sent: Wednesday, November 2, 2011 10:46 PM Subject: Re: [Bitcoin-development] Lock protocol version numbers On Wednesday, November 02, 2011 6:33:12 PM Amir Taaki wrote: Satoshi 0.5 What is Satoshi 0.5 anyway? 0.5's server is bitcoind and GUI is Bitcoin-Qt; the wx GUI client is gone, which is more or less what Satoshi referred to in the past...-- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Bitcoin Wiki
Anybody know how to contact MT about getting it back online? I still haven't finished copy-editing the BIPs and need access to them since there's a new one to be added. -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] My thoughts on DoS code
Hey, The Zen of Python is relevant here: http://www.python.org/dev/peps/pep-0020/ In the face of ambiguity, refuse the temptation to guess. If a node incorrectly implements the standard then it should be shunned immediately. Not only is this more secure, but it will ensure long term compatibility between different implementations. Gavin argues that being a bit lenient makes it easier for people working on other implementations. I'd argue the opposite being the only person that's working on a full node implementation. Lucky I know my way around the code, so I don't have to guess. But if I did not things would be much harder. Imagine you're trying to interact with this protocol and then randomly it will suddenly disconnect you because of accumulated errors that have been building up. Everything should be strict, explicit, unambiguous and loud. I propose a new message type: error Payload is a uint64_t error_code and var_str reason. Before disconnecting a node you can send it an error message. The error_code is the main class of error- i.e version_sent_twice. Reason is just an implementation specific string that can add context. Other possible fields: uint8_t seriousness (debug, info, warning, error, fatal) uint8_t action_taken (disconnect, blacklist, .etc) -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
