What would make you think this is a joke?

Those of you who have visited the site before, and came into this thread just to troll, please stop posting your old cached versions of the page. 

That offer has expired.  The page has been updated with a new offer, which I quoted already.  You may need to refresh the page to see it.

Thanks for that.  That's pretty much the response I should have expected.

Circumstantial evidence of hacking in the fact that this user recently added 'franky1' to his trust network.

bitcoinisland.org/join

"franky1" is an investor who seems to enjoy trolling and sabotaging Bitcoin crowd-sourcing efforts.  I have never (as of now) solicited or received any investment from him or anyone else on this forum.  Beyond that, I am not capable of fully explaining him or his motivations.

"franky1" has simply lied on the trust feedback form by claiming that he "risked" 300 BTC with me, as nothing of the sort ever happened.

You can read more about the original Bitcoin Island project, and some more of his fabricated accusations here.  In short, his MO seems to be to make up slanderous nonsense, offer "funds" for "investment," demand irrelevant information and then claim he has been "scammed" when the information is not provided and his "funds" are refused.  Frankly, I'm not sure why anyone would ever consider dealing with him at all.

As for the claim that I wanted to "go away and hide somewhere," I think that's pretty obvious when I was literally crowd-sourcing an effort to buy an island.  I mean, it's not like some genius secret plan, or anything.  I literally post these projects here using my real name and address.  And the reason for my interest in Bitcoin Island should be pretty clear from the information posted right on the site.

But thanks for your interest, regardless.

Small Update:


Google Maps

bitcoinisland.org/join

This is just yet another in a long list of potential block size limit growth schedules.  For more information, please see the original post on Reddit.

The long and short of it is, if you accept Pieter's argument that network bandwidth grows at 17.7% per year, and you accept the argument of Gavin and the majority of miners that the current technological limit to block sizes is 8 MB rather than 1 MB, then it is possible to combine the two proposals in a way that promotes growth in the short term without requiring a large initial jump in block size, yet which converges to a 17.7% growth rate in the long run.

This schedule uses a decaying growth rate for the block size limit in the same way that Satoshi chose a decaying growth rate for the block reward.

I've made a spreadsheet showing three schedules for comparison, annualized and rounded off for clarity.  The first is (roughly) Pieter's proposal.  The second is Gavin's proposal modified to use Pieter's 17.7% annual growth rate.  And the last schedule includes an initial period of high, yet decaying growth rates, converging to a continuous 17.7% growth rate.  All three schedules end once they reach approximately 128 MB, which is my proposed minimum block size (required for everyone on Earth to have the opportunity to perform two transactions per year).  The ultimate maximum size is intentionally left undetermined, for simplicity of comparison.



As you can see, compared to the other two, the decaying growth rate schedule has a few advantages.  First, it reaches 128 MB a full twelve years before Pieter's proposal.  Secondly, there is an initial growth to 2 MB which (based on historical data) will be necessary in order to accommodate transaction growth during the next halving.  Yet, there is no harsh initial jump to 8 MB as with Gavin's proposal.  And, thirdly, the block size with the decaying growth schedule remains below the combined growth of an 8 MB jump with 17.7% annual increases the entire time.  So it remains within the parameters of both initial conditions mentioned above.

you should watch the video:
http://sacredgeometryinternational.com/graham-hancock-and-joe-rogan-discuss-randall-carlsons-paradigm-changing-research


https://en.wikipedia.org/wiki/Younger_Dryas


For those not familiar with Graham Hancock

It's probably not clear to most of you how this is related to Bitcoin, but it is.

We should also distinguish the way legal systems actually work from how they ought to work.  You've offered a lot of opinions on how they ought to work.  How they work instead is that international financiers buy off or threaten all of the judges and they just do whatever they are told.  Legal systems have no duty to protect individual rights.  When push comes to shove, they don't even have the ability to do so.  Trial judges typically don't even attempt to try.  Millions of people live outside of organized legal systems.  And national governments and their dictates have no jurisdiction in international relations, where Bitcoin must reside.


Then your opinion is inconsistent and, therefore, wrong.  It is impossible for any logic-based system to attempt to impose your opinion.  So there is no reason for Bitcoin to even try; and it won't.


Yes, and that's the "system" most of us live under.  Fortunately, Bitcoin isn't a "system".  It's a simple realization of fundamental natural law.  I'm sure, at some point, some will attempt to build reversible "systems" on top of Bitcoin.  And then you and the other 99% can use those, if you prefer.  But, when that happens, they will be as voluntary as Bitcoin is.


Individuals are perfectly capable of enforcing agreements without laws and courts.


I'd argue that most people prefer their currency not to track and front-run them and not to evaporate based on the whims of some third party.  The current bank runs going on in Greece should be evidence of this.

Like I said, Bitcoin is a currency.  It's not a "system".  Systems can be built on top of Bitcoin, and using Bitcoin;  and, eventually, they will be.  But nothing like Bitcoin, which protects the rights of everyone, not just those lucky few capable of navigating corrupt legal systems, can be built on top of any kind of "system" you have advocated so far.

Advantages.


Fair enough.  Satoshi was not prescient.  I think he made it clear that he had hoped for slow, steady growth.  What he got instead was massive early attention and a bubble.  Bitcoin is not unique in that regard, however.  So I think we should try to lay responsibility for "ponzification" of real assets (nay, the entire economy) at the feet of those actually responsible.


Hmm... I think this is a bit controversial.  Mining centralization hasn't seemed to have had any ill effects, so far.  But fair point.


Premature optimization is the root of all evil.


That's actually just not true.  There's good reason to believe it could support 1 billion users, indirectly at least.

I think it's time to have a little discussion about the origins of Sidechains, and to dispute a claim made recently by a certain core developer that they have no application to Bitcoin scaling.

This post was prompted by a thread here regarding the claimed origins of Sidechains and their relation to Mike Hearn's Lighthouse.  I'm going to lay out an argument that this claimed history is not entirely accurate, and perhaps some of you can see how the Lighthouse is relevant to the discussion.

There has been a noticeable PR push over the past several months by Blockstream employees to make the claim that Sidechains 1) were the sole idea of Adam Back (aside from the attributions in the whitepaper itself, of course) and 2) are not useful for scaling Bitcoin.  This is hogwash, as far as I'm concerned.  And it needs to be disputed not only in the interest of historical accuracy, but for the good of the Bitcoin community.

Several years ago, I made a thought experiment.  I asked myself "what is the best way to use Bitcoin as a true local currency, in an isolated community with poor internet access, especially once it has begun to scale to accommodate millions of users?"  Based on Satoshi's original plan of scaling up the block size, this would be a difficult task without relying on SPV wallets, which some consider flawed.  But I decided there should be a way to do so, even with some limitations, and that perhaps these limitations could even be engineered to have economic benefits.

The result of this thought experiment was Bencoin.  Bencoin was simply a method to deposit Bitcoins, off-chain, with a trusted third party representing a separate more localized economy, while still being able to withdraw them at will.  It represented a middle-ground between the then-common practice of trusting a third party with deposited Bitcoins, and using the blockchain directly for everything.  It was basically a low-trust, rather than zero-trust or full-trust, method of handling Bitcoins off-chain (and thus scaling Bitcoin), without the limitations and costs imposed by tracking large blocks.

It did, however, still have other drawbacks.  So I never pursued it beyond the proof-of-concept.  Instead, I began thinking of ways to deposit Bitcoins somewhere else -- not with a third party, but on the blockchain itself.  I started looking into the nLockTime feature, and eventually developed the first native Bitcoin Bond, locking Bitcoins on the blockchain in a way that they could not be spent by a trusted third party without the authorization of the depositor.

This represented an improvement over Bencoin.  The fundamental improvement of Bencoin was that Bitcoins deposited with a third party could be withdrawn at any time by the depositor alone, but the drawback remained that they could still be taken by the trusted third party.  With the Bitcoin Bond, locked Bitcoins can still be withdrawn (after a specified time) by the depositor, and *cannot* be spent by the third party without authorization of the depositor.

All of this was done in public, and is documented in various places on the Bitcointalk forum and the #bitcoin-dev IRC channel.  All of it occurred long before Blockstream was even a glimmer in its founders' eyes.  And the short leap from Bencoin to Bitcoin Bonds to one-way pegged Sidechains is, I think, obvious.

So, knowing this, I found it somewhat interesting when a lot of other history and precursors were mentioned in the Sidechain whitepaper, yet none of this.  I found it only mildly disturbing when the similarity was flatly denied by a Blockstream employee, having been pointed out to him on Reddit when the original Sidechains whitepaper was released.  But, now, I find it outright insulting that Blockstream seems to be engaged in a publicity campaign to downplay the capabilities of "their own" invention.

In fact, it's almost as though Blockstream would rather seize control of this idea and keep it for themselves, instead of allowing for the possibility that the scalability benefits of Sidechains or similar be opened to the entire Bitcoin community.  I'm beginning to think that may actually be what's going on.

Now, I'm not going to argue that Blockstream's proposed implementation of Sidechains is the best option for scaling Bitcoin.  It may not even be a good option, as is.  But it, or an idea like it such as Extension Blocks, is a valid option that should not be brushed aside based on the claims of a single developer that Sidechains have nothing to do with scaling.

These claims are wrong, at least, and disingenous, at worst.  The actual history of Sidechains' precursors is that they have a lot to do with scaling.  And there are likely several ways to implement them in order to enable Bitcoin to scale in a flexible and completely voluntary fashion.

If anything, I hope this post will at least convince you to question the claim that Sidechains or similar have nothing to do with Bitcoin scaling, or are not even a valid option to be considered in the scaling debate.

In an attempt to avoid any coordinated or future censorship, I've also posted a copy of this to Reddit.

Thank-you for your time.

Well, this prediction seems to have some facts behind it now, at least:


And here's another (anonymous) claim to know the "real" DPR.  Again, no idea whether it's legit:


http://www.reddit.com/r/AskReddit/comments/3b0kwl/whats_your_deep_web_story/cshrivc

Whose idea was it to put a Turing-complete scripting language into a browser, anyways?

Between a handful of technologies -- Javascript injection, Heartbleed SSL compromise, and advanced persistent threats living in firmware -- the goddamn NSA and their various collaborators have absolutely decimated the concept of a global censorship-resistant communications network.

"Benjamin Lawsky" is an intelligence agent working out of Chuck Schumer's office.  Don't ever sign up for nonsense "licenses" to use Bitcoin.

I'll just say that I really didn't intend to argue one way or another with this post.  I do have my preferences.  But I just wanted to present a few facts regarding blocksize increase, in a way that perhaps some of you hadn't considered before.  Don't get caught up in the hoopla of choosing sides.  We're all ultimately on the same side.

That's what 20 MB blocks require.  That means, you receive the blockchain, that's 84 gigabytes per month.  You send the blockchain to one peer, that's another 84 gigabytes per month.

If you want any redundancy at all, as a true peer-to-peer network should, for whatever reason at all (resiliency, privacy, etc), you need to start adding on redundant pathways, and more data.

All of that has to fit within the data caps imposed by your internet service provider, along with all of your other internet usage -- all of the Youtube videos, other P2P programs, NetFlix, etc, for everyone who uses your connection.  In the US, the vast majority of home internet connections are limited to less than 400 gigabytes per month, most less than 250 gigabytes.

These caps are independent of your connection speed.  They are arbitrarily imposed by internet service providers.  They may grow with technological advancements, or they may not.

Other, developing parts of the world have to deal with other limitations.  Only in a few, highly-developed regions, are home internet connections both high speed and un-capped.

In response to this, there will be some hand-waving arguments involving splitting up blocks into transactions and getting each transaction from a different peer.  And that's great.  That's certainly an improvement over the current network.  But please understand all of the trade-offs involved.  There are trade-offs.

Bitcoin as a Retirement Account

Proof of concept

OP_CHECKLOCKTIMEVERIFY


One thing you may want to do, from the perspective of using Bitcoin as a retirement account, is "lock" a sum of Bitcoins on the blockchain so that they can't be spent before some future date.  This is a rather old idea, yet has never been properly supported in Bitcoin, for a few reasons.  As far as I'm aware, the closest it has ever come is the proof-of-concept "Bitcoin bond" linked above.

Satoshi did include a field, nLockTime, that can be set in every transaction which will prevent that transaction from being included in the blockchain before that time.  Notice, though, that this isn't quite the same as what you want.  Satoshi had a different use case in mind altogether.

But it can be used to create the behaviour we want, with just a few caveats.  We can use the current behaviour of nLockTime to create a "bond" of sorts, which will pay out only after an approximate future date of our choosing.  To do so requires multiple parties, at least one of which must be trusted not to collude to double-spend before that time.  If you're one of the parties, great!  You trust yourself.  All of the other parties trust themselves as well.  So they can all trust that the transaction will not be confirmed before the agreed-upon time, and will not be double-spent, unless they consent.

So it works, from the point-of-view of a small group of parties that each trust themselves.  The problem (from the point-of-view of my original use case, generic economy-wide bonds) is that no one outside of the group that originally creates the transaction can really trust that the parties will not collude to pay out before the agreed-upon time.

Perhaps OP_CHECKLOCKTIMEVERIFY will be supported soon, the responsibility not to double-spend locked transactions can be transferred to the entire Bitcoin network, and Bitcoin will have a mechanism for true economy-wide "bonds".

Until then, for this kind of use case it doesn't really matter.  If you just want an instrument between two or more parties that will only pay out after a certain approximate date, it can be done with Bitcoin.  So that's one application.

edit:  Found an older thread describing the Bitcoin bond concept.