Re: [Bitcoin-development] Mechanics of a hard fork

2015-05-07 Thread Cameron Garnham
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

While being in the Bitcoin community for a long time, I haven't been
so directly involved in the development.  However I wish to suggest a
different pre-hard-fork soft-fork approach:


Set a 'block size cap' in the similar same way as we set difficulty.

Every 2016 blocks take the average size of the blocks and multiply the
size by 1.5x, rejecting blocks that are larger than this size, for the
next 2016 period.

I would of-course suggest that we keep the limits at min 100kb and max
(initially) 990kb (not 1mb on purpose, as this should become the new
limit), rounding up to the nearest 10kb.

A: we don't have pressure at the 1mb limit, (we reduce the limit in a
flexible manner to 990kb).

B: we can upgrade the network to XYZ hard-limit, then slowly raze the
soft-limit after being sure the network, as-a-whole is ready.

If we on-day remove the block-size limit, this rule will stop a rouge
miner from making 10mb, or 100mb blocks, or 1gb blocks.

This could be implemented by the miners without breaking any of the
clients, and would tend to produce a better dynamic fee pressure.


This will give the mechanics to the miners to create consensus to
agree what block-sizes they believe are best for the network, and
allows the block-sizes to dynamically grow in response to larger demand.



On 5/8/2015 10:35 AM, Pieter Wuille wrote:
 On May 7, 2015 3:08 PM, Roy Badami r...@gnomon.org.uk wrote:
 
 On Thu, May 07, 2015 at 11:49:28PM +0200, Pieter Wuille wrote:
 I would not modify my node if the change introduced a perpetual
 100 BTC subsidy per block, even if 99% of miners went along
 with it.
 
 Surely, in that scenario Bitcoin is dead.  If the fork you prefer
 has only 1% of the hash power it is trivially vulnerably not just
 to a 51% attack but to a 501% attack, not to mention the fact
 that you'd only be getting one block every 16 hours.
 
 Yes, indeed, Bitcoin would be dead if this actually happens. But
 that is still where the power lies: before anyone (miners or
 others) would think about trying such a change, they would need to
 convince people and be sure they will effectively modify their
 code.
 
 
 
 --
- 

 
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
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlVMKZYACgkQBJ8cMDO159aTiQEApTITEBrhE1DRbj/w+GncNeqB
0hGvmIBa1z0hGww0kaMBAOhxjn/K5leRJgdt1fKhNEDKKHdeCOIX3QRgry90D3NO
=p0+H
-END PGP SIGNATURE-

--
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: Encrypt bitcoin messages

2014-08-19 Thread Cameron Garnham
We should aim to use perfect forward secrecy between all nodes by default.

This forces the attacker to do a MITM attack that is far more expensive on
the large scale.

I don't see why this is seen as so controversial.  It is relatively cheap
to implement on our side,  and has a dramatic increase of cost for any
attackers.

Cam.
On 20/08/2014 5:49 am, Un Ix slashdevn...@hotmail.com wrote:

  Excuse the ignorance, but there is something I’m not getting in this
 discussion.

 Given it’s a published protocol, with available source code running on an
 open P2P network, why would any messages between nodes benefit from being
 encrypted? Surely all the data being processed by the network is known to
 any persistent client node(s)?

 Seems like that solution is orthogonal to the root problem, where
 attackers could monitor the network and deduce IP addresses by e.g. mapping
 senders of transactions.

 *From:* Peter Todd p...@petertodd.org
 *Sent:* ‎Wednesday‎, ‎August‎ ‎20‎, ‎2014 ‎9‎:‎28‎ ‎AM
 *To:* William Yager will.ya...@gmail.com,
 bitcoin-development@lists.sourceforge.net

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256



 On 19 August 2014 21:19:43 GMT-04:00, William Yager will.ya...@gmail.com
 wrote:
 On Tue, Aug 19, 2014 at 8:14 PM, Peter Todd p...@petertodd.org wrote:
  In any case, my suggestion of enabling hidden service support by
 default
  adds both encryption and reasonably good authentication.
 
 
 Enabling hidden service support by default would introduce an insanely
 huge
 attack surface.

 Hence my suggestion of separating that surface by using the standalone Tor
 binary, which runs under a different user to the Bitcoin Core binary.

 And you're conflating two different things; using Tor is valuable to
 Bitcoin because it would provide some anonymity. The encryption aspect
 is
 pretty much useless for us.

 First of all, without encryption we're leaking significant amounts of
 information to any passive attacker trying to trace the origin of Bitcoin
 transactions, a significant privacy risk.

 Secondly the upcoming v0.10's fee estimation implementation is quite
 vulnerable to Sybil attacks. Authentication and encryption are needed to
 make it secure from ISP-level targeting to ensure that your view of the
 network is representative. Tor support used in parallel with native
 connection is ideal here, as neither the Tor network nor your ISP alone can
 Sybil attack you. It's notable that Bitcoinj has already implemented Tor
 support for these same reasons.
 -BEGIN PGP SIGNATURE-
 Version: APG v1.1.1

 iQFQBAEBCAA6BQJT8/mSMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
 cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhRZjCAC4PSpQ68qgtFMR77xf
 zXZLr/iMKX6yyJwXRj+vGi+0Ng/sv9NlYjYnDeflom37WlpGo/sCOFcVWImhnS2d
 kUFoUH92iXwRuEt/SN/LrHghkLWOxtVu9wa49eS/piGZFF3JWllk82MgdBZ6vjNw
 B6WuInEIurK+h8rUbAi2HjFkxVN0K0SsrFt/P0tHj10ABcMealBRoJh2Jx7fLNdS
 uTKddqeLyThEpLGNti3k+lhwQ2dA5RUBq6q3GUS/hWvTHRnU+viGMJSYv62LXRN5
 t87BXRY/R9UBpnudf3TIlPtOuIWcv2LhlXVjvbDDQqwJkvB3Qf4ejE3RZ28S5IUr
 OBQH
 =Gy7X
 -END PGP SIGNATURE-



 --
 Slashdot TV.
 Video for Nerds.  Stuff that matters.
 http://tv.slashdot.org/
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


 --
 Slashdot TV.
 Video for Nerds.  Stuff that matters.
 http://tv.slashdot.org/
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Stealth Addresses

2014-01-17 Thread Cameron Garnham
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

One of the possible words that haven't been proposed is 'personal' where
bitcoin addressed are commonly incorrectly called public address.

Maybe 'personal account' or even 'personal address' would imply that the
balance on such an account shouldn't be assumed to be public knowledge.

Cam.


On 17/01/2014 5:59 pm, Drak wrote:
 That could also work. Still, didn't we want to ditch the word address?
 Could be a privacy key...
 
 On 17 Jan 2014 09:15, Mike Hearn m...@plan99.net
 mailto:m...@plan99.net wrote:
 
 I must say, this shed is mighty fine looking. It'd be a great place
 to store our bikes. But, what colour should we paint it?
 
 How about we split the difference and go with privacy address? As
 Peter notes, that's what people actually like and want. The problem
 with stealth is it's got strong connotations with American military
 hardware and perhaps thieves sneaking around in the night:
 
https://www.google.com/search?tbm=ischq=stealth
 
 But everyone loves privacy.
 
 
 On Fri, Jan 17, 2014 at 8:49 AM, Drak d...@zikula.org
 mailto:d...@zikula.org wrote:
 
 Peter I agree with you about  reusable addresses, but aren't
 we also trying to get away from the word address entirely?
  How about calling it a payment key or reusable payment key
 instead? using stealth is just asking for bad press imo.
 
 
 On 16 January 2014 21:28, Peter Todd p...@petertodd.org
 mailto:p...@petertodd.org wrote:
 
 On Wed, Jan 15, 2014 at 04:05:27PM -0800, Jeremy Spilman wrote:
  Might I propose reusable address.
 
  I think that describes it best to any non-programmer, and
 even more
  so encourages wallets to present options as 'one time use' vs
  'reusable'.
 
  It definitely packs a marketing punch which could help drive
  adoption. The feature is only useful if/when broadly adopted.
 
 I'm very against the name reusable addresses and strongly
 belive we
 should stick with the name stealth addresses.
 
 You gotta look at it from the perspective of a user; lets
 take standard
 pay-to-pubkey-hash addresses: I can tell my wallet to pay
 one as many
 times as I want and everything works just great. I also can
 enter the
 address on blockchain.info http://blockchain.info's search
 box, and every transaction related
 to the address, and the balance of it, pops up immediately.
 
 What is that telling me? A: Addresses starting with 1 are
 reusable. B:
 Transactions associated with them appear to be public knowledge.
 
 Now I upgrade my wallet software and it says I now have a
 reusable
 address. My reaction is Huh? Normal addresses are reusable,
 what's
 special about this weird reusable address thing that my
 buddy Bob's
 wallet software couldn't pay. I might even try to enter in
 a reusable
 address in blockchain.info http://blockchain.info, which
 won't work, and I'll just figure
 must be some new unsupported thing and move on with my life.
 
 On the other hand, suppose my wallet says I now have
 stealth address
 support. I'm going to think Huh, stealth? I guess that
 means privacy
 right? I like privacy. If I try searching for a stealth
 address on
 blockchain.info http://blockchain.info, when it doesn't
 work I might think twig on Oh right!
 It said stealth addresses are private, so maybe the
 transactions are
 hidden? I might also think Maybe this is like
 stealth/incognito mode
 in my browser? So like, there's no history being kept for
 others to
 see? Regardless, I'm going to be thinking well I hear
 scary stuff
 about Bitcoin privacy, and this stealth thing sounds like
 it's gonna
 help, so I should learn more about that
 
 Finally keep in mind that stealth addresses have had a tonne
 of very
 fast, and very wide reaching PR. The name is in the public
 conciousness
 already, and trying to change it now just because of vague bad
 associations is going to throw away the momentum of that
 good PR and
 slow down adoption. Last night I was at the Toronto Bitcoin
 Meetup and I
 based on conversations there with people there, technical and
 non-technical, almost everyone had heard about them and
 

Re: [Bitcoin-development] 0.8.1 ideas

2013-03-13 Thread Cameron Garnham
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


I think that the course of action is quite simple:

1.  Upgrade all the clients to implement the lock limits. (in code,
not at the DB exception layer).  A bit of research is needed to work
out exactly what these limits are so we can maximise the number of
transactions.

2. Fix the DB layer, and test that all the clients can support 1MB blocks.

3. Once we are confident that the network supports 1MB blocks, set a
date where the lock limits are removed.

For me, everyone signed up to bitcoin thinking that there was a 1MB /
block limit.  The lock limits were unexpected, and could be considered
extremely uncontroversial to remove.

The discussion of larger blocks (i.e.  1MB ),  that I happen to
disagree with,  is not relevant to the discussion of the removal of
the lock limits.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlFBF0QACgkQBJ8cMDO159aWbwEAs8Ldt8hRpzjS4HdrH3U9Jnaq
MWhifXqkJuVC0TVCz3EBAOAfSogdSS7rJvtfV8FqTIox1ek/xJxuHvZdonUnQN1K
=I5Cf
-END PGP SIGNATURE-

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Signing release binaries

2012-07-29 Thread Cameron Garnham
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I'm not a vendor, however I have a code-signing key for windows; I could
sign the windows installer and binary.

On 30/07/2012 3:15 AM, Luke-Jr wrote:
 On Sunday, July 29, 2012 10:17:51 AM Mike Hearn wrote:
 I guess Gavin would be the final signer.
 
 Considering that Gavin is not interested in participating in any way in the 
 stable versions, I would prefer to see someone else responsible for OS-vendor 
 signing.
 
 
 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and 
 threat landscape has changed and how IT managers can respond. Discussions 
 will include endpoint security, mobile security and the latest in malware 
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAlAV8ZYACgkQBJ8cMDO159ZNVgD+KsQUlNcTDSmTGaHvLbAw0Cxy
OCDfnsFbaiLoX2xWP3MBAOnN/QvcYY8f2WzMfI+N1PfnydRYGxlkA2JZ2Nrtnxcv
=qeUe
-END PGP SIGNATURE-

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP 21 (modification BIP 20)

2012-01-31 Thread Cameron Garnham
On 1/02/2012 00:12, Gavin Andresen wrote:
 RE: BIP 21 versus BIP 20:  I like BIP 21; simpler is better.
 
 RE: signing and dating URIs:  good ideas.  I think we should agree
 that there is consensus around BIP 21 and then after there is some
 experience with signing/dating URIs you should write follow-up BIPs .
 

If we had a self signed URI, we could just pay directly to the public
key (or calculate the bitcoin address from it).  It
would no longer require a bitcoin address in the URI.


0x33B5E7D6.asc
Description: application/pgp-keys


0x33B5E7D6.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development