Re: [Bitcoin-development] Long-term mining incentives

[Pedro Worcel]

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 :

> On Tue, May 12, 2015 at 7:48 PM, Adam Back  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

[Pedro Worcel]

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 :

> 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 
> 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

[Pedro Worcel]

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] Proposal to address Bitcoin malware

[Pedro Worcel]

Where would you verify that?

On 2/3/2015 10:03 AM, Brian Erdelyi wrote:

Joel,

The mobile device should show you the details of the transaction (i.e. 
amount and bitcoin address).  Once you verify this is the intended 
recipient and amount you approve it on the mobile device.  If the 
address was replaced, you should see this on the mobile device as it 
won’t match where you were intending to send it.  You can then not 
provide the second signature.


Brian Erdelyi

On Feb 2, 2015, at 4:57 PM, Joel Joonatan Kaartinen 
mailto:joel.kaarti...@gmail.com>> wrote:


If the attacker has your desktop computer but not the mobile that's 
acting as an independent second factor, how are you then supposed to 
be able to tell you're not signing the correct transaction on the 
mobile? If the address was replaced with the attacker's address, 
it'll look like everything is ok.


- Joel

On Mon, Feb 2, 2015 at 9:58 PM, Brian Erdelyi 
mailto:brian.erde...@gmail.com>> 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


--
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

[Pedro Worcel]

> 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 :

> 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  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  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=153845071&iu=/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

[Bitcoin-development] Miners MiTM

[Pedro Worcel]

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.

Ta,
Pedro
--
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=153845071&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development