Re: [Bitcoin-development] Fake PGP key for Gavin

2014-03-23 Thread Troy Benjegerdes
On Sat, Mar 22, 2014 at 06:03:03PM +0100, Mike Hearn wrote:
 In case you didn't see this yet,
 
 http://gavintech.blogspot.ch/2014/03/it-aint-me-ive-got-pgp-imposter.html
 
 If you're using PGP to verify Bitcoin downloads, it's very important that
 you check you are using the right key. Someone seems to be creating fake
 PGP keys that are used to sign popular pieces of crypto software, probably
 to make a MITM attack (e.g. from an intelligence agency) seem more
 legitimate.

I find it more likely that fake PGP keys are from corporate industrial 
espionage and/or organized crime outfits. Intelligence agencies will stick
to compromised X509, network cards, and binary code blobs.

Besides, why would an intelligence agency want your bitcoin when they can 
just intercept ASIC miners and make their own?
 
 I think the Mac DMG's of Core are signed for Gatekeeper, but do we codesign
 the Windows binaries? If not it'd be a good idea, if only because AV
 scanners learn key reputations to reduce false positives. Of course this is
 not a panacea, and Linux unfortunately does not support X.509 code signing,
 but having extra signing can't really hurt.

Uhhmm, real operating system use package managers with PGP instead of pre-
compromised X.509 nonsense. https://wiki.debian.org/SecureApt


-- 

Troy Benjegerdes 'da hozer'  ho...@hozed.org
7 elements  earth::water::air::fire::mind::spirit::soulgrid.coop

  Never pick a fight with someone who buys ink by the barrel,
 nor try buy a hacker who makes money by the megahash


--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee

2014-03-23 Thread Troy Benjegerdes
On Sat, Mar 22, 2014 at 03:08:25PM -0400, Peter Todd wrote:
 On Sat, Mar 22, 2014 at 10:08:36AM -0500, Troy Benjegerdes wrote:
  On Sat, Mar 22, 2014 at 04:47:02AM -0400, Peter Todd wrote:
   There's been a lot of recent hoopla over proof-of-publication, with the
   OP_RETURN data length getting reduced to a rather useless 40 bytes at
   the last minute prior to the 0.9 release. Secondly I noticed a
   overlooked security flaw in that OP_CHECKMULTISIG sigops weren't taken
   into account, making it possible to broadcast unminable transactions and
   bloat mempools.(1) My suggestion was to just ditch bare OP_CHECKMULTISIG
   outputs given that the sigops limit and the way they use up a fixed 20
   sigops per op makes them hard to do fee calculations for. They also make
   it easy to bloat the UTXO set, potentially a bad thing. This would of
   course require things using them to change. Currently that's just
   Counterparty, so I gave them the heads up in my email.
  
  I've spend some time looking at the Datacoin code, and I've come to the 
  conclusion the next copycatcoin I release will have an explicit 'data' 
  field with something like 169 bytes (a bakers dozen squared), which will 
  add 1 byte to each transaction if unused, and provide a small, but usable
  data field for proof of publication. As a new coin, I can also do a
  hardfork that increases the data size limit much easier if there is a
  compelling reason to make it bigger.
  
  I think this will prove to be a much more reliable infrastructure for 
  proof of publication than various hacks to overcome 40 byte limits with
  Bitcoin.
  
  I am disclosing this here so the bitcoin 1% has plenty of time to evaluate
  the market risk they face from the 40 byte limit, and put some pressure to
  implement some of the alternatives Todd proposes.
 
 Lol! Granted, I guess I should disclose that I'm working on tree
 chains, which just improve the scalability of blockchains directly. I'm
 think tree-chains could be implemented as a soft-fork; if applied to
 Bitcoin the datacoin 1% might face market risk.  :P

Soft-fork tree chains with reasonable data/memo/annotation storage would be
extremely interesting. The important question, however, is how does one 
build a *business* around such a thing, including getting paid as a developer.

What I find extremely relevant to the **bitcoin-dev** list are discussions
about how to motivate the people who own the hashrate and bulk of the coins
(aka, the bitcoin 1%) to PAY DEVELOPERS, and thus it is good marketing FOR
BITCOIN DEVELOPERS to remind the people who profit from our efforts they need
to make it profitable for developers to work on bitcoin.

If it's more profitable for innovative developers to premine and release
$NEWCOIN-blockchain than it is to work on Bitcoin-blockchain, is that a valid
discussion for this list? Or do you just want to stick your heads in the sand
while VC's look to disrupt Bitcoin?

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee

2014-03-23 Thread Mark Friedenbach
This isn't distributed-systems-development, it is bitcoin-development.
Discussion over chain parameters is a fine thing to have among people
who are interested in that sort of thing. But not here.

On 03/23/2014 04:17 PM, Troy Benjegerdes wrote:
 I find it very irresponsible for Bitcoiners to on one hand extol the virtues
 of distributed systems and then in the same message claim any discussion
 about alternate chains as 'off-topic'.
 
 If bitcoin-core is for *distributed systems*, then all the different altcoins
 with different hash algorithms should be viable topics for discussion.

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development