Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

[Cameron Garnham]

First off, I am glad that the idea of dynamic block size adjustment is
gaining some attention, in particular the model that I proposed.

I wanted to take some time and explain some of the philosophy of how,
and why, I proposed this this particular model.

When Bitcoin was first made, there was a 32MB block size limit; this
was quickly found to be open to spam (and potentially DOS, as the code
was not-at-all optimized to support large blocks), and was reduced to
1MB, this was a quick fix that was never intended to last; at some
point the network should come to an understanding, a consensus if you
will, of what (and how much) belongs in a block.
The core point of this is that miners have always, and will always;
hold the power, to decide what goes into blocks; this implicitly,
obviously, includes how large blocks are. Miners are able to come any
sort of agreement they wish, providing the bitcoin clients accept
their blocks as valid.

Say if Satoshi never decided to place the 1MB block limit: It would be
up to the miners to decide what they consider a ‘reasonable’ block is.
However, they would need to find some way to communicate this and
reach an agreement; some protocol.  They, say, could have done this
informally on what is now the bitcointalk forum, or used Twitter.
However, what they really need is indeed a "consensus protocol". Some
simple terms to define what is acceptable and what is not.

Hence, the proposal introducing a consensus protocol for block sizes;
instead of just having a hard limit (enforced by everyone), instead,
we have a constant factor above the average block size over a fixed
intervals that is soft-forked by only the miners. (The next simplest
mathematical construct).
This proposal is entirely a soft-fork and may be implemented without
changing any client code what so ever. In-fact, it could be
implemented by only a simple 51% majority of miners, with-or-without
gaining the wider community consensus. (Assuming that the 1MB block
size rule still applies).
The nice thing about this is that it really is impossible to stop,
for-example, if pre-relaying of block headers is implemented; the
miners could always soft-fork to include the block-size in the
coinbase. The only reason that the miners have not done this yet, is
that there has not yet been a strong will to increase transaction fees.

If we assume the miners will operate in a way to collectively maximize
profit; then we can assume they will not try to maximize utility of
the network (having as many transactions as possible), rather have as
few transactions as the total economy can support the cost.  Meaning
that limiting to much smaller blocks will probably be much more
profitable than having large blocks.

Since there is no requirement for the clients to know about the block
size consensus protocol, this truly can be a
‘bi-directional-soft-fork’, in that the miners can choose to change
the rules at any time, with only a simple 51% majority. Therefore, any
parameters that we pick are always up for debate.

Why the 1.5x over 2016 blocks? -  Using some game theory, and
deduction: I wished to pick the type of agreement that would be
natural for the miners to come to (selfishly).

First, Why 1.5x, this means that only a super-majority of miners can
easily increase the block size. – There is no natural incentive for
miners to produce large blocks that have very few fees.

Second, Why 2016 blocks for adjusting the average:  Miners HATE
unpredictability, for shorter time periods the miner will need to have
infrastructure ready to support potentially much larger block almost
immediately. 2016 blocks is a period that the miners are already well
used to, meaning that it will take slightly less than a month for
blocks of double size to be permitted.

This entire infrastructure can be implemented without needing to
update any clients; once implemented, tested, solid, and well accepted
by the (mining) community then we can revisit increasing the 1M hard
limit. (If we still have demand for it, maybe the average block size
will reduce to say, 100KB).


Cam.






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

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

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

[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"  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 
> *Sent:* ‎Wednesday‎, ‎August‎ ‎20‎, ‎2014 ‎9‎:‎28‎ ‎AM
> *To:* William Yager ,
> bitcoin-development@lists.sourceforge.net
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
>
> On 19 August 2014 21:19:43 GMT-04:00, William Yager 
> wrote:
> >On Tue, Aug 19, 2014 at 8:14 PM, Peter Todd  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

[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"  > 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=isch&q=stealth
> 
> But everyone loves privacy.
> 
> 
> On Fri, Jan 17, 2014 at 8:49 AM, Drak  > 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  > 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 '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 , 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 , 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 peopl

Re: [Bitcoin-development] 0.8.1 ideas

[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

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

[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

Re: [Bitcoin-development] bitcoin.org SOPA/PIPA blackout

[Cameron Garnham]

I think that bitcoin.org should remain apolitical.  However maybe it 
would be good if the blackout to take effect on bitcointalk.org if 
theymos and Sirius believes it is appropriate.


Bitcoin.org should provide bitcoin.




On 17/01/2012 11:59 AM, slush wrote:

>  I agree Bitcoin should avoid making any bold political stands.

I agree on this. Please don't turn Bitcoin project/homepage into some 
political agitation. Not everybody care about political attitude of 
main project developers.


slush

On Tue, Jan 17, 2012 at 1:46 AM, Alan Reiner > wrote:


You guys are representing both extremes of the issue.  In response
to Jeff and Luke-Jr, I don't see how this is /just any other
poltical issue/.  It strikes at the heart of everything Bitcoin is
about.  Barring Bitcoin-specific legislation, I don't see how any
legislation could be more relevant to Bitcoin and the community
around it.

On the other hand, Bitcoin is still a non-entity, and shouldn't
get in the business of making statements.  A central voice for
Bitcoin gives the impression that it is actually centralized, and
one that has opinions.  Plus I wouldn't be surprised if some,
heavily-invested Bitcoin users were of the opinion that
SOPA/PIPA/whatever could be a huge profit for themselves:  once
SOPA kicks in and businesses around the world start getting cut
off for legit or illegitimate purposes, a lot of them could
potentially switch to Bitcoin to keep their business going.  That
could be a huge boon for Bitcoin.  You may not agree it's worth
the tradeoff, but people are selfish and may not actually
understand or even care about SOPA legislation itself.

I think it's /not inappropriate/ for something to be mentioned on
the website about Bitcoin's philosophy being threatened by SOPA,
but I agree Bitcoin should avoid making any bold political
stands.  Users could be reminded that SOPA affects yet another
thing they care about, but it might be better to avoid it
altogether.  If any response is made, it should be a very light one.

-Alan



On 01/16/2012 07:30 PM, Amir Taaki wrote:

Bunk argument. This is an issue that affects bitcoin directly.

Wikipedia has far more need to remain neutral and apolitical than bitcoin 
ever does- you've read Satoshi's politically charged whitepaper or seen the 
genesis block quote.

http://en.wikipedia.org/wiki/Wikipedia:SOPA_initiative/Action

The Wikipedia community decided on a full and global blackout. Bitcoin 
should do the same in unison with the rest of the web- sites like Reddit, 4chan 
and Wikipedia.

It's funny / almost comical how you consign this to being just another 
issue or case of moral alarm. Sad.



- Original Message -
From: Jeff Garzik  
To: Amir Taaki  
Cc:"bitcoin-development@lists.sourceforge.net"  
   
 
Sent: Sunday, January 15, 2012 10:37 PM
Subject: Re: [Bitcoin-development]bitcoin.org    
SOPA/PIPA blackout

On Sun, Jan 15, 2012 at 5:09 PM, Amir Taaki  
  wrote:

How is this not the most important world issue right now?

EVERYTHING is under threat. Go nuclear to show our nerd-rage.

Everybody blank your personal sites too. Americans, take to the streets. 
World, go scream at the US embassy.

There are always issues that raise ire and moral outrage.  I would
rather thatbitcoin.org    stay apolitical -- our users 
will appreciate
this in the long run.





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




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

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Cameron Garnham]

Namecoin makes sense; as we can use the same private keys to spend the
namecoin as spending the bitcoins.

Namecoin happens to be the only secure guaranteed global unique human
rememberable string system that exists.

I suggest that sending bitcoins to a namecoin name is the way to go...
It makes even more sense since namecoin started merged mining.

On 13 December 2011 08:03, Cameron Garnham  wrote:

>
> Sent from my Windows Phone
> De: Amir Taaki
> Enviado: 13/12/2011 0:43
> Para: bitcoin-development@lists.sourceforge.net
> Asunto: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
> > I'm confused about the problem we're trying to solve.
>
> I was in brmlab and wanted to pay 1 BTC for a Club Mate. They had on
> the wall a picture of their QR code and a bitcoin address. I don't own
> a mobile phone so the QR code is
> useless. Then I remembered FirstBits, went to my terminal and typed
> 1brmlab. I got their bitcoin address from the website and copied that,
> then opened my terminal and pasted that in to send 1 BTC.
>
> And
> these proposals for Namecoin, would make bitcoin implementations
> dependent on unproven technology. HTTPS/DNSSEC have been around a long
> time and are responsible for many mission critical systems. There's a
> lot of momentum behind those projects. Namecoin by contrast, could die
> tomorrow. And it isn't a big deal that they're centralised. This is a
> convenience for end users and does not affect the core system much.
>
> tl;dr: usability
>
>
>
> --
> Systems Optimization Self Assessment
> Improve efficiency and utilization of IT resources. Drive out cost and
> improve service delivery. Take 5 minutes to use this Systems Optimization
> Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



-- 
Cameron Garnham:
email: da2...@gmail.com
website: http://da2ce7.blogspot.com
telephone: +61405227831
--
Systems Optimization Self Assessment
Improve efficiency and utilization of IT resources. Drive out cost and 
improve service delivery. Take 5 minutes to use this Systems Optimization 
Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development