I think of it more as a community consensus to make sure Bitcoin works the way it was designed to - that lost coins remain lost. I think when the time comes we'll figure out what is a fair solution.

That said I understand the issues with this deletion, and hence I will not press this further at this point.

It's not to protect the owners. It's to prevent the economy from being shaken when someone breaks ECDSA and wins all the lost coins.

Oh, I'm nowhere near finished. My next pdf will be about ad hominem attacks and the probability of protecting against them with the use of the ignore button.

Not sure who you are talking to, but theymos and I suggested the opposite, deleting expiring coins; and only when the alternative is that they will be commandeered by whoever breaks the signature algorithm.

I support it for people who want a receiving address other than their generic GLBSE claim address. Using this to turn me into a manual exchange server is an abuse of my goodwill, unless otherwise specified.

I've been thinking about this for a while, and have recently commented about it here, completely oblivious to this post of yours. Talk about coincidence.

In this context it should be clarified what a "bitcoin" is. A "split" where all bitcoin balances are multiplied by 1000 (so there are now 21B coins; technically, it just means the word "bitcoin" is now used to denote 100,000 satoshis) is not against the core design and can be considered (not saying it's a good idea).

No, some hard forks are not against the core design and will be necessary eventually. e.g., fixing the difficulty adjustment off-by-one bug, or a new hash function (and/or protocol for including different hash functions) when SHA256 is sufficiently weakened.

I don't plan to issue new bonds in the immediate future. And I didn't say I would support transfers. (If there is though a transfer request I'll consider it.)

Thank you. But going forward with what I publicly and quite unambiguously committed to do really is the least I could do.

It will probably be more than that. But it will also have a different shape than steady exponential growth.

Now you're scaring me.

Anyway, I fail to see the logic of this, as the existence of an NDA is not one of the facts whose sharing was conditioned on signing it.

I would like to mention in this context something which does not get the attention it deserves.

It is plausible that the currently used version of ECDSA will be broken eventually. When weaknesses start to be found people will start moving their coins to more secure addresses. But the lost coins will remain where they are, and when it is finally broken, whoever does it will find himself with a huge treasure of coins. This isn't stable and is not how Bitcoin is supposed to work.

I think we need to consider agreeing that some time after the signature algorithm shows weaknesses, we will delete all old coins to which the keys were lost. It's either that or have them all suddenly move to one party.

Pre-order money for this was never collected, and even had it been, it was to be held in escrow, not used for development.

And why are you getting upset about something that happened 9 months ago?

Edit: I agree.

Not sure what you mean by that.

Looks to me the other way around - in the DownCase the difficulty grows very very quickly.

Furthermore:

In all cases it seems the revenues drop too quickly. Increases in difficulty are due to hardware advances and BTC rate appreciation. The part related to the exchange rate doesn't affect the dollar revenues. Hardware advances are mainly due to Moore's law, which is about x1.5 per year. There can be some rapid growth until the ASIC transition completes, but after that x10 per year is way too much.

Mining has fixed expenses depending on only the hardware and method used. It seems you modeled the profit as exponentially decreasing, where in fact the revenues are exponentially decreasing and from those constant expenses should be subtracted.

I've been looking for a payment plan that simultaneously doesn't cause

1. Unnecessary delays to confirmed bondholders,
2. Monetary loss to yet unconfirmed bondholders,
3. Monetary loss to me, or
4. An organizational mess.

I eventually came up with the following:

I will pay the coupons to confirmed bondholders on a roughly weekly cycle. Blocks for which this was paid will be denoted "partial" at http://bitcoinpuremining.com/.

"Partial" will at any point in time designate a specific amount of paid bonds, which this thread will be updated with.

Every new confirmed bondholder will be paid retroactively the partially paid coupons, and the number of paid bonds will be adjusted accordingly.

At some unspecified future point in time, all unclaimed bonds will be donated to charity and retroactively paid, and the corresponding blocks will be designated as fully paid.


With this in mind, I have paid 0.0034117507 BTC per bond for blocks 209663 to 212015, a total of 49.61709105 BTC to 14543 bonds. This is transaction 2b7e8173010182e8d32a28eb87aed5769b90d75d3a50b547b6dbb089163a8b94.

Some addresses have been changed at the request of the owners.

There is certainly something magic about 50%. With more than 50%, the success probability is always 100%. With less than 50%, success is not guaranteed and the probability depends on the number of confirmations. The magic is clearly visible in the graphs in AoHBDS.

The practical effects of this magic is a subject for more nuanced discussion.

dree12 said that
21 million coins X 100 million satoshis per coin = 2.1 quadrillion satoshis
And not 21 quadrillion as grue said. 2.1 is 10% of 21.

What is fair about it? What about those that don't have a Facebook account because they think Facebook is one of the greatest plagues humanity has ever experienced? What about those who have several Facebook accounts?

No offense but frankly, I think it's horrible. First because you focus on the things that you care about, rather than the things they would care about. Second, because taking a grab-bag of concepts and saying "hey, Bitcoin includes this!" really does nothing to show what is good about Bitcoin and how the pieces of the technology fit together to enable it. Third, because if you do focus on the technologies you love you may as well show your passion for it, provoking interest, but you didn't - the message is pretty dry.

I don't know how much effect does the initial message have on eventual adoption. I'm not an expert or anything but in addition to the PR page on the Bitcoin wiki, you may want to consider the following pointers I originally wrote here:

1. Don't be a spammer. If it's a shop, only contact them if you've made purchases before. If an organization, show that you are actually involved in and care about their cause.
2. Unless they are very much inclined towards the philosophy of Bitcoin, they won't care how great it is to have an Open Source peer-to-peer deflationary cryptographic currency which is not controlled by any possibly malicious single point of failure and that they will be helping promote a better future. These can be mentioned to provide some perspective of what Bitcoin is, but downplayed. They care about what's in it for them, how it will help them in their own lives. They want to know that Bitcoin will give them extra business/donations they can convert to fiat currency which is of known use to them. That's not them being selfish, just practical. If they later choose to be more involved that's an added bonus.
3. They will want to know that with Bitcoin, people can send money easily and with no/low transaction fees.
4. Shops may be interested to know there are no chargebacks with Bitcoin.
5. Make it personal. Let them know how you personally would love to pay them with bitcoins.
6. They will be concerned about the work required to receive Bitcoin payments. Let them know that it's easy and offer to help (it helps if yourself you know a thing or two about Bitcoin and its related services).
7. Be polite, of course.
8. Don't overdo it. They will be put off by too much enthusiasm.

'Cost of neutrally mining' = how much it costs to mine each block without trying to double-spend.

The cost of double-spending is roughly inversely proportional to the probability of success. If the hashrate isn't too high, the probability is exponentially decreasing with the number of confirmations, hence the cost is exponentially increasing. So the needed number of confirmations is logarithmic in the value of the transaction. If the attacker has majority hashrate, the probability of success is essentially 1, so it cannot help us make the attack expensive. The cost to double-spend in this case is roughly proportional to n/(2q-1), where n is the number of confirmations and q is the attacker's hashrate. Thus the number of confirmations needed is linear in the value of the transaction.

Maybe because all this time nobody made an analysis of the Bitcoin transaction graph which prompted an investigation into ways to determine common ownership of addresses . So you can thank Adi and Dorit for that.

Also: http://dilbert.com/strips/comic/2001-10-25/. Many of us have looked at transactions in Blockexplorer, assuming change should be in a random location, but without paying special attention to this, there's hardly any smoking gun saying "This isn't random".

And then we have bigger things to worry about. Anyway, this is a tangent, as I said even if it costs more for the attacker to mine than he gets normally, there still isn't much security to speak of if he's in majority (and if not, the probabilities are what matters).


And I should point out that even if we assume that:

1. The attacker gets no reward from the blocks he mines
2. The attacker has majority hashrate and is guaranteed success

It is still not the case that the cost to double-spend is simply proportional to the number of hashes embodied in the confirmations; the attacker needs to redo these and all the blocks that will be found during the race. The less hashrate the attacker has the longer the race will draw out, so you need to know the hashrate to estimate the cost.

The paper I linked to earlier in this thread, paper and discussion thread.

If we come to the point that we're thinking in terms of the cost per gigahash then we already lost because the amount that can be at stake would be only linear in the number of confirmations, and double spending will be trivial.

Our only hope is if the attacker cannot obtain more than a certain total hashrate, and if that is low enough (as a portion of the network total), his probability of success will be low (exponentially decreasing in the number of confirmations). That will place a real cost on double spending.

Also, if the attacker successfully double-spends, he also gets the normal block reward (coinbase + tx fees) for the blocks he found in the process. Assuming the cost per gigahash is predictable, it should also be about equal to what you would get on average in rewards. In this case there is no cost to double spending (if success is guaranteed). So again there is real hope only if the probability of success is low, and some small hope if the attacker can only secure the needed hardware at above the "normal" cost.

That is an overly simplistic description that doesn't take into account how double-spending actually works.

The two things that matter for the probability of succeeding in a double-spend attempt are the number of confirmations and the attacker's proportional hashrate. If the attacker's hashrate is assumed constant, increasing the difficulty means lower attacker proportion and hence more security. But the relationship is not linear, and cannot be compressed into a single "total gigahashes" figure.

I recommend having a look at my linked paper which provides some discussion of this. And that for securing a system the proper dynamics will be considered, rather than trying to dumb it down to a single number.