Re: [Bitcoin-development] Long-term mining incentives
Thank you for your response, that does make sense. It's going to be interesting to follow what is going to happen! 2015-05-14 3:41 GMT+12:00 Gavin Andresen gavinandre...@gmail.com: On Tue, May 12, 2015 at 7:48 PM, Adam Back a...@cypherspace.org wrote: I think its fair to say no one knows how to make a consensus that works in a decentralised fashion that doesnt weaken the bitcoin security model without proof-of-work for now. Yes. I am presuming Gavin is just saying in the context of not pre-judging the future that maybe in the far future another innovation might be found (or alternatively maybe its not mathematically possible). Yes... or an alternative might be found that weakens the Bitcoin security model by a small enough amount that it either doesn't matter or the weakening is vastly overwhelmed by some other benefit. I'm influenced by the way the Internet works; packets addressed to 74.125.226.67 reliably get to Google through a very decentralized system that I'll freely admit I don't understand. Yes, a determined attacker can re-route packets, but layers of security on top means re-routing packets isn't enough to pull off profitable attacks. I think Bitcoin's proof-of-work might evolve in a similar way. Yes, you might be able to 51% attack the POW, but layers of security on top of POW will mean that won't be enough to pull off profitable attacks. -- -- Gavin Andresen -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Long-term mining incentives
Disclaimer: I don't know anything about Bitcoin. 2) Proof-of-idle supported (I wish Tadge Dryja would publish his proof-of-idle idea) 3) Fees purely as transaction-spam-prevention measure, chain security via alternative consensus algorithm (in this scenario there is very little mining). I don't understand why you would casually mention moving away from Proof of Work, I thought that was the big breakthrough that made Bitcoin possible at all? Thanks, Pedro 2015-05-13 4:10 GMT+12:00 Gavin Andresen gavinandre...@gmail.com: Added back the list, I didn't mean to reply privately: Fair enough, I'll try to find time in the next month or three to write up four plausible future scenarios for how mining incentives might work: 1) Fee-supported with very large blocks containing lots of tiny-fee transactions 2) Proof-of-idle supported (I wish Tadge Dryja would publish his proof-of-idle idea) 3) Fees purely as transaction-spam-prevention measure, chain security via alternative consensus algorithm (in this scenario there is very little mining). 4) Fee supported with small blocks containing high-fee transactions moving coins to/from sidechains. Would that be helpful, or do you have some reason for thinking that we should pick just one and focus all of our efforts on making that one scenario happen? I always think it is better, when possible, not to bet on one horse. On Tue, May 12, 2015 at 10:39 AM, Thomas Voegtlin thom...@electrum.org wrote: Le 12/05/2015 15:44, Gavin Andresen a écrit : Ok, here's my scenario: https://blog.bitcoinfoundation.org/a-scalability-roadmap/ It might be wrong. I welcome other people to present their road maps. [answering to you only because you answered to me and not to the list; feel free to repost this to the list though] Yes, that's exactly the kind of roadmap I am asking for. But your blog post does not say anything about long term mining incentives, it only talks about scalability. My point is that we need the same kind of thing for miners incentives. -- -- Gavin Andresen -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal to address Bitcoin malware
I think what he is saying is that there is no point in having three signatures if they are not segregated in a secure manner. This is to say, if you use your computer as one factor, and a third party website as another, but you use the same computer to access the website, there is no gain in security. Another example would be an android phone. If your computer is compromised and your browser is authenticated to your Google account, you could remotely install an app on your phone. I don't know if I understood/explained myself correctly; I think two factor is better than one and there is a security gain if implemented securely. Cheers! Pedro On 2/3/2015 8:58 AM, Brian Erdelyi wrote: Confusing or not, the reliance on multiple signatures as offering greater security than single relies on the independence of multiple secrets. If the secrets cannot be shown to retain independence in the envisioned threat scenario (e.g. a user's compromised operating system) then the benefit reduces to making the exploit more difficult to write, which, once written, reduces to no benefit. Yet the user still suffers the reduced utility arising from greater complexity, while being led to believe in a false promise. Just trying to make sure I understand what you’re saying. Are you eluding to that if two of the three private keys get compromised there is no gain in security? Although the likelihood of this occurring is lower, it is possible. As more malware targets bitcoins I think the utility is evident. Given how final Bitcoin transactions are, I think it’s worth trying to find methods to help verify those transactions (if a user deems it to be high-risk enough) before the transaction is completed. The balance is trying to devise something that users do not find too burdensome. Brian Erdelyi -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Miners MiTM
the only protection is SSL + certificate validation on client side. However certificate revocation and updates in miners are pain in the ass, that's why majority of pools (mine including) don't want to play with that... Another solution which would have less overhead would be to implement something akin to what openssh does. The OpenSSH client stores a certificate fingerprint, which is then verified automatically upon further connections to the server. The initial connection needs to be verified manually by the operator, though. Certificate validation isn't needed unless the attacker can do a direct MITM at connection time, which is a lot harder to maintain than injecting a client.reconnect. This, combined with your concern about up to date certs/revokes/etc, is why BFGMiner defaults to TLS without cert checking for stratum. Seems to me that it would correctly mitigate the attack mentioned in the wired article. I am surprised that miners are not worried about losing their profits, I would personally be quite annoyed. 2014-08-08 12:37 GMT+12:00 Christopher Franko chrisjfra...@gmail.com: What exactly makes bitcoin less of a target than a scamcoin which I suspect means anything that != bitcoin? On 7 August 2014 20:29, slush sl...@centrum.cz wrote: AFAIK the only protection is SSL + certificate validation on client side. However certificate revocation and updates in miners are pain in the ass, that's why majority of pools (mine including) don't want to play with that... slush On Fri, Aug 8, 2014 at 1:45 AM, Luke Dashjr l...@dashjr.org wrote: On Thursday, August 07, 2014 11:02:21 PM Pedro Worcel wrote: Hi there, I was wondering if you guys have come across this article: http://www.wired.com/2014/08/isp-bitcoin-theft/ The TL;DR is that somebody is abusing the BGP protocol to be in a position where they can intercept the miner traffic. The concerning point is that they seem to be having some degree of success in their endeavour and earning profits from it. I do not understand the impact of this (I don't know much about BGP, the mining protocol nor anything else, really), but I thought it might be worth putting it up here. This is old news; both BFGMiner and Eloipool were hardened against it a long time ago (although no Bitcoin pools have deployed it so far). I'm not aware of any actual case of it being used against Bitcoin, though - the target has always been scamcoins. -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
