<unnamed>

Public Key

npub1jl9phmfrflkqfm34r2mn9yszrwgpmdq8nh4s0y00xr7yy83ug48sumzsyg

Profile Code

nprofile1qqsf0jsma535lmqyac634dejjgpphyqaksrem6c8j8hnplzzrc7y2ncpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsy8drxp

Publishing to

relay.primal.net

nos.lol

relay.damus.io

Last Notes

2023-06-07 14:56:36 UTC

- reply

📅 Original date posted:2013-05-07
📝 Original message:I think it's worth noting that quite a large portion of Linux users
probably get the mainline Bitcoin client from the packages. I think Bitcoin
package maintainers are doing mostly a pretty good job :)
On 6 May 2013 18:13, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Mon, May 6, 2013 at 3:51 PM, Adam Back <adam at cypherspace.org> wrote:
> > Maybe I could hack a pool to co-opt it into my netsplit and do the work
> for
> > me, or segment enough of the network to have some miners in it, and they
> do
> > the work.
>
> Or you can just let it mine honestly and take the Bitcoins. This is
> fast (doesn't require weeks of them somehow not noticing that they're
> isolated), and yields the values I listed as 'costs' if you would have
> otherwise been able to use it to mine the difficulty down to 1. Cost
> is just as much foregone income from the alternative attack you could
> have done instead.
>
> > nor even topological, nor even
> > particularly long-lived.
>
> At least for attacks that drive the difficulty down it does.
>
> If you want to talk about abusing a pool or creating a partition in
> order to create short reorgs— I agree, those don't have to be long
> lived and you can find many messages where I've written on that
> subject.
>
> It's inconsiderate to propose one attack and when I respond to it
> changing the attack out from under me. :( I would have responded
> entirely differently if you'd proposed people segmenting the network
> and creating short reorgs instead of mining the difficulty down.
>
> > Do you know if there is any downwards limit on difficulty? I know it
> takes
> > going slow for a long and noticeable time, but I am just curious on the
> > theoretical limit.
>
> Every 2016 blocks can at most lower the difficulty by a factor of 4,
> thats where the log4 (number of 2016 groups needed) and 4^n (factor in
> cost reduction for each group) come from in the formulas I gave
> previously.
>
> > I dont see the signatures.
>
>
> http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.1/SHA256SUMS.asc/download
>
> The signatures can't be inside the tarball because they sign the tarball.
>
> Seems like the website redesign managed to hide the signatures pretty
> good. They're in the release announcements in any case, but that
> should be fixed. Even when they were prominently placed, practically
> no one checked them. As a result they are mostly security theater in
> practice :(, — so— unfortunately, is SSL: there are many CA's who will
> give anyone a cert with your name on it who can give them a couple
> hundred bucks and MITM HTTP (not HTTPS!) between the CA's
> authentication server and your webserver. Bitcoin.org is hosted by
> github, even if it had SSL and even if the CA infrastructure weren't a
> joke, the number of ways to compromise that hosting enviroment would
> IMO make SSL mostly a false sense of security.
>
> The gpg signatures and gitian downloader signatures provide good
> security if actually used, solving the "getting people to use them"
> problem is an open question.
>
> And I agree, this stuff is a bigger issue than many other things like
> mining the difficulty down.
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and
> their applications. This 200-page book is written by three acclaimed
> leaders in the field. The early access version is available now.
> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
> _______________________________________________
> 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/20130506/39286b04/attachment.html>

2023-06-07 11:42:33 UTC

- reply

📅 Original date posted:2013-04-01
📝 Original message:An attacker would have to find a collision between two specific pieces of
code - his malicious code and a useful innoculous code that would be
accepted as pull request. This is the second, much harder case in the
birthday problem. When people talk about SHA-1 being broken they actually
mean the first case in the birthday problem - find any two arbitrary values
that hash to the same value. So, no I don't think it's a feasible attack
vector any time soon.
Besides, with that kind of hashing power, it might be more feasible to
cause problems in the chain by e.g. constantly splitting it.
On 1 April 2013 03:26, Melvin Carvalho <melvincarvalho at gmail.com> wrote:
> I was just looking at:
>
> https://bitcointalk.org/index.php?topic=4571.0
>
> I'm just curious if there is a possible attack vector here based on the
> fact that git uses the relatively week SHA1
>
> Could a seemingly innocuous pull request generate another file with a
> backdoor/nonce combination that slips under the radar?
>
> Apologies if this has come up before ...
>
>
> ------------------------------------------------------------------------------
> Own the Future-Intel® Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest.
> Compete for recognition, cash, and the chance to get your game
> on Steam. $5K grand prize plus 10 genre and skill prizes.
> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> _______________________________________________
> 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/20130401/8f2483a3/attachment.html>