See the other link in the post.

It's quite slow, I'd do it differently now. If there is interest I can write it in C and make it fast and less dumb.

At the moment that particular version seems to only try to make the prefixes visually distinct... but that seems a bit odd in retrospect.

For that many words these constraints may work less well, with the 'ee' dictionary there it only finds 1933 distinct three character prefixes... so that constrains the optimization a lot.

Do you need help generating the wordlist? I wrote some crappy python code for exactly the criteria you are suggesting a few years ago:

https://people.xiph.org/~greg/wordlist.visual.py

What that does is, starting with a dictionary (I prefer to use basic english dictionaries, the one the script is currently coded to use is at this location) picks a set of words such that the first three characters are unique and such that the visual differences beyween the words in the set is maximized.

The problems with it are that it's focused on creating a pgp wordlist size dictionary, and I suspect these criteria may be harder to accomplish for an electrum size dictionary.

Uh. Your 2200TB of storage would, using the most cost effective hardware currently available, cost $130,992 today.  No doubt this will improve substantially in a few years 2016... but "less than $10,000" sounds a bit ambitious (even relative to past storage scaling)... and you've not justified your random division by 20.

But hey, just take that and run with it—   At $10,000-and-growing in hardware costs just to store the data needed to check the validity of blocks efficiently, costs that have no direct income generation, would Bitcoin be a decenteralized system?  I don't believe that it would be.  It would be a distributed system, yes, but one with some dozen of major players and large mining pools in complete control of the system, subject to easy influence by regulators and organized crime, and with everyone else is stuck with them.

That might be the eventual outcome of Bitcoin— just as it seems the eventual outcome of originally-asset-backed government promissory notes was to become today's current unbacked currencies. But even if it is inevitable I'd like to see that outcome forestalled: A Bitcoin who's only selling part is a different set of cronies-in-charge is not especially attractive to the systems of central banks, and not especially attractive compared to payment systems with lower hardware cost and faster confirmations.

We have pruning now now just no way for nodes to find sources for blocks in order to sync up if real full nodes become sparse, so there is as of yet no knob to delete the old history. It's not used at all now except for reorgs, syncing up new peers, and rescanning restored wallet backups. Validation is against the pruned data.

You're not talking about excluding just old systems, you're talking about excluding everything that isn't a commercial-scale price-of-a-cheap-car capital investment in dedicated-to-bitcoin hardware-that-doesn't-even-exist-yet. Requiring reasonably modern, even reasonably high end conventional hardware, is probably not great for decentralization but probably doesn't preclude it, but I think that going beyond that does. Fortunately the same scaling laws your arguing will turn $130k  into $10k will also grant the same capabilities inexpensive systems in suitable time. Maybe.  And when it does we should make use of it. What we shouldn't do is set ourselves up so our only choice is to toss the decentralization that made the system worth having because we let it bloat faster than the technology could keep up with.

Not hardware related. geesh.

It seems like this whole discussion has arisen out of some people on Reddit being (rightfully) unhappy with the description of Litecoin on the Bitcoin wiki, and Ripper234 offering to prevent Luke from editing it if made admin.

But Ripper234, you haven't edited the Wiki since January other than to create the governance page you linked here. Why not try to work out your disagreement with Luke instead of asking for admin access so that you don't even need to try to work with him?  It looks like you've never even edited the page in question.

When there is a disagreement the first recourse should be to expose it and try to work it out... not to ask for admin rights and write essays on governance.   Luke is— for better or worse— one of the more active editors on the Bitcoin wiki and makes a lot of perfectly uncontroversial changes too.
 

I don't think think the wiki needs "governance"— or at least the word sort of implies other people being bent to the will of others— thats not very wiki and it's not very Bitcoin either.  The Bitcoin wiki needs more community love and attention, for sure, but the best way to do that is to get more people involved. Sometimes this takes a bit of community building. Please feel free to reach out to me in cases where you think things aren't going well, and I'll gladly wade in and poke things in the right direction.

Making it work well doesn't take people with special rights— though having some active people with admin rights can sometimes be handy— especially now that the pay-for-edit stuff kills drive by spam dead. More voices trumps more special privileges.

I asked my lawyer to look at it. (Not that I care much about the particular issue, but I am interested if people are letting their politics get in the way of giving solid legal opinions to the community)

I haven't seen that— a node with 8 connections appears pretty stable at about 300MB res, nodes with many in-bounds use about a gig— which is the roughly the same as it was 6 months ago.

Are you sure the people here aren't just running out of address space on 32 bit systems?

"UP purposely entered in JD’s bitcoin address information and initiated the the transfer of bitcoins from his bitcoin address to JD’s"

Except that isn't part of the facts in this case.  UP may have intended to enter a different address, UP may have intended to send a different amount. A reasonable person would not believe that 500 BTC just showing up for no reason were a gift.

Most (all?) states have statutes governing mis-shipped and found property— I would suggest looking there for guidance rather than focusing myopically on UCC which is silent on the matter especially when doing so has clearly resulted in legally incorrect conclusions.

Seriously, you're calming that someone who miswrote $1000 on a payment for $50 would have no remedy?  I suspect someone's JD may have been sent to the wrong address.
 

Are you really anticipating an increase in valuation of 2000x (thats whats required to make a 1e-8 output worth what $0.01 is today) before people have long since lost the relevant keys?
Infinite, unless we add a rule to reject 0 value outputs. If we do the theoretical maximum size is about 44 petabytes.

The ignoring in this patch, fwiw, doesn't appear to change wallet behavior. Once those txn are mined they'll show up in the wallet. Litecoin carries a patch that ignores things in the wallet.

No. This works with high probability with minorities of hashpower for shallow depth if you're talking about shallow burrying, I should have been more clear.

The concern I was trying to highlight is that the separate transaction is just as redeemable if the txns you care about are in the chain or not, so using something like this to secure particular transactions doesn't seem to work until the particular transactions are already secured. So I'm having trouble understanding the motivation the people paying the bond.  "Say I'm an altruist that wants to convince his employer to fund Bitcoin network security, how do I convince my boss that this is a good thing to spend money on?"

It doesn't use much CPU once it has finished synchronizing with the network. Memory usage is about 300mbytes for a non-listening node, make sure you don't confuse virt (address space usage) with res. A 512mb vps is a little cramped, and you won't be able to compile it on it most likely.

Running a full node is the gold standard for node security. What security needs depends on the peculiars of what you're doing. If you're only sending funds to yourself (as you seem to describe!) then you don't have much security requirements (but then again, if you really were doing that you shouldn't be transacting at all).

I would strongly suggest you think very carefully about using VPSes if you'll be holding a non-trivial amount of funds. Anyone involved in the operation of your VPS service could scan the disks and steal your private keys.  There has been at least one high profile case where someone used a backdoor in a provider's management infrastructure to rob a bunch of coins stored on typical-security hosting. 

A corner case to keep in mind if we ever want to prohibit zero value outputs!

Would people who support this also support an alternative which strongly de-prioritized repeated address use? e.g. only relaying one to a few transactions per address in the mempool.

Blacklisting has some enormous systemic risks for the community— but if people behave in ways which make blacklisting effective then it is inevitable, if not because of this this user than eventually some other user.  Since privacy and fungibility are in all of our interests the system should operate in a way that gives people incentives to not behave in ways that damage those (e.g. use fresh addresses).  Plus it creates more fair load-balancing of the available resources: if someone voluntarily discloses that two transactions are theirs, why shouldn't we prevent them from using more than their share of the available capacity?

I ran a patch like this on my own nodes for some time— long before SD existed, though it has since bitrotted due to other changes.  I haven't promoted it because I believed that people who didn't understand it would think I was trying to single out a particular user... which is not the case, the purpose of such a change would be to protect everyone from the damage to the system being caused by singling out people by making singling out less effective against common behavior.

Both of these cases reduce to "miners choose" (because, e.g. under (2) miners can stuff their blocks with 'fake' txn). Miners choose is problematic for many reasons (discussed in detail in many other threads), but this thread is not about the block size, it's about how you can fund miners in ways other that using transaction fees to compete for limited space in blocks since thats not available if the size is not limited. It would be helpful to not knock this thread offtopic. The alternative funding question is interesting regardless of what happens with the block size.

A transaction pays me 1000 BTC in block X.
I want to make sure that payment stays put and isn't reversed.
I contribute to an assurance contract for 10 BTC payable in block >=X+1.

The person who paid me announces a conflicting transaction which pays 50 btc in fees, with child transactions locked at X+1,X+2,X+3,X+4 paying 25, 12.5, 6.25, 3.125, etc.

Miners fork at X, the forking chain collects the 100 BTC in treachery award, additionally they collect the 10 BTC assurance contract.

Sufficiently smart mining software that computes the fork to mine on based on expected returns would be automatically complicit in this attack.

I think this description of having the assurance contracts paid by unrelated transactions is vulnerable to something similar to the POS problem ("proof of stake doesn't work because there is nothing at stake"): miners can mine honest chains or dishonest ones, and get paid all the same.


I'm also still not following the incentives here. Say I am one of the minority with special high value transaction security requirements. And I want to spend X on security, it would be more economical for me to just perform my own mining.. at least then I can be sure my expenditure wouldn't fund the mining of a fork which is not in my interest.  Of course, I have no particular incentive to mine anyone elses transactions if doing so is costly.... and if there are few such parties you wouldn't expect mining to be well distributed...

There is at least a small group of the technical crowd around here who has been aware of your challenges— your excellent lesswrong post has been circulated many times— and every time you post something it generates great excitement on IRC. Seeing you continue on with a productive life is an inspiration to everyone and, speaking for myself usually makes my own difficulties seem a bit more trivial and surmountable— doubly so considering that many of us found your work interesting before your troubles. (E.g. I corresponded with you about RPOW back in 2004.)

More selfishly, I believe having people contributing to the Bitcoin ecosystem from many perspectives is highly valuable— your I/O limitations are a burden no one would choose, but perhaps they give you useful perspectives that others are less likely to have. I'm grateful that you've chosen to continue to spend time in this area and I hope you'll continue to find it fulfilling.  When Pieter created a pull request with your ECDSA optimizations (work which he has since continued and achieved something like a 4x speedup over OpenSSL) I quipped that we were truly in the future: we have a decenteralized cryptocurrency, and one of its developers exists in brain-in-a-jar state.

After your bcflick post I ordered an extra TPM/XMHF capable system (don't want to risk bricking my laptop messing around with it)... I'm pretty excited by that work and eager to see where it goes.

SPV security means trusting the longest chain instead of validating for yourself. Being a "client" or not isn't relevant.

But indeed, I assumed you meant not bothering to validate for yourself rather than validating and then pruning, though only in the context of a hash committed UTXO, so that you can securely query. I would have just called that "pruning". And there is nothing wrong with that.  But I also don't know that there is any great benefit in that— as it substantially increases bandwidth usage. Tradeoffs are fine though.

No, in fact— it isn't, as nodes won't reorganize back infinitely far. (this has its own problems, as a longer fork that branches where nodes won't reorganize to makes the system divergent as newly initialized nodes will be on the 'wrong' chain)

Only N-recently mined ones, which the system makes unspendable for 100 blocks specifically due to this reason.

To autonomously verify it you must query the entire set. If you're assuming self-verified pruned utxo thats fine, if you're assuming SPV security UTXO... not so much.

Who gives a hoot about "home users"? The concern there is that there is enormous invectives for freeloading— if running a full node is so costly that home users cannot run one what makes you think that "millions" of small, medium, and large businesses _will_ instead of just using SPV to accept coins?  It's easy to see how the system can be thoroughly decentralized when it is fairly inexpensive to operate, it's less obvious when you assume it will be a real cost center.

What you're describing is SPV UTXO security, and it's also been brought up many times before. Perhaps you should save for allegations of unimagniativeness for ideas that area actually original.

SPV UTXO security means that the reward for someone who can produce N blocks isn't just reversing the transactions they can make and replacing them, it's on the order of the value of the whole bitcoin economy, past and into the future. They could steal anyones coin, they could freely inflate the supply, etc.

You have the Bitcoin security model wrong: Bitcoin verifies everything because it doesn't trust, except in the very limited fashion that it must because we can't do ordering autonomously. Abandon that and you lose the incentives that make mining secure enough to even think that you could abandon validation.

Perhaps, ultimately, the scaling means that it's a superiority security model, but if you're going to change the security, you could hypothesize even weaker models which are even less costly to operate.