Pedro Worcel [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-08-07 to 2015-05-13
💬 Posted a total of 6 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 15:34:52

- reply

📅 Original date posted:2015-05-13
📝 Original message: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 <gavinandresen at gmail.com>:
> On Tue, May 12, 2015 at 7:48 PM, Adam Back <adam at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150514/0556dc6c/attachment.html>

2023-06-07 15:34:51

- reply

📅 Original date posted:2015-05-12
📝 Original message: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 <gavinandresen at 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 <thomasv at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150513/018ff86d/attachment.html>

2023-06-07 15:29:20

- reply

📅 Original date posted:2015-02-02
📝 Original message: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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:29:18

- reply

📅 Original date posted:2015-02-02
📝 Original message: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
>> <joel.kaartinen at gmail.com <mailto:joel.kaartinen at 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
>> <brian.erdelyi at gmail.com <mailto:brian.erdelyi at 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 at lists.sourceforge.net
>> <mailto:Bitcoin-development at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150203/3878832d/attachment.html>

2023-06-07 15:24:59

- reply

📅 Original date posted:2014-08-07
📝 Original message:> 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 <chrisjfranko at 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 <slush at 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 <luke at 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=153845071&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at 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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140808/b550abc2/attachment.html>

2023-06-07 15:24:58

- reply

📅 Original date posted:2014-08-07
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140808/21c667f5/attachment.html>