Please pay attention to the original post.  This isn't a thread to debate KNC generally, the OP is "looking to get a list together of other people who are in the same boat with a view to pursuing joint legal action if KnC don't honor refunds". Please try to confine your responses to addressing that.

I've had to remove many offtopic posts in this thread lately. Please keep in mind that all posts should be strictly related to the original post. (This post will also be removed once people see it).

Sorry if I wasn't clear— It shouldn't take much time regardless of the size because most of the transactions in the block are already validated and waiting in the mempool. Before the software cached that validation it was taking a fair amount of time, but not anymore. Getting most of the validation off the latency sensitive critical path is a big improvement.

Unless something weird has happened it takes ~no time anymore to validate a new block at the tip of the network— its almost all already validated when you receive it.

Yes/No.  A sidechain like functionality could be implemented using multisignature oracles where it's trusted that a majority of signers will abide by the rules and sign only when the sidechain says to sign.  This can be useful for some things— e.g. when there are few users of the sidechain and the signers can just be the users, or for testing.

But it's not possible implement the mining based decentralized version without some script enhancements.

P2Pool already does this for its own blocks.  The problem more generally is that you don't know what other transactions the far end knows (at least not completely) and if you need an extra RTT to fetch the transactions the end result is that the block takes longer to relay than just sending the data in the first place. So in terms of reducing block orphaning and such, it wouldn't be a win.  (It works better in the p2pool case, since the nodes themselves are mining and can be sure to have pre-forwarded any transactions they'll mine)

Perhaps as a general optimization for nodes that don't care about getting the block as soon as possible it might be interesting, though it is possible to optimize latency and bandwidth at the same time through more complicated protocols (see link in gavin's post).

A built in "shortcut" could be exploited by an network attacker who has isolated your node to feed you fake confirmations— so no.  If there is some kind of massive coordinated loss we likely have much worse to worry about (like that hashpower actually being off on a separate partition that will overtake our current chain). Of course "small" losses, like "half" are no big deal— 20 minute blocks rather than 10.

Efforts in altcoins to 'fix' behavior here have traded off security in the common case for security in cases where the system is already broken for other reasons—  in some cases they've been exploited pretty hard as a result, so I don't consider it a good tradeoff at all.

In the current codebase any transaction will be rejected if the transaction is >100k. 100kB times the base fee for non-free transactions is 0.001, so unless you've increased your fees there is already a hard limit ten times lower than you asked for.

E.g. JTR rules mode is a publicly available example... though there are more powerful tools which are non-public.

An example of JTR rules on the single input word "hello world", with the minimal default rules— there are thousands of extra rules that can be enabled, and but even the default set produces a great many examples.


6hello World6
Olleh world0
World0 HELLO
Helling 8world
olleh worlD
helling dlroW
5hello dlroW
world. Olleh
HelloHello worlded
Hello0 world
5world 3hello
Dlrow Hello0
hello worlds
world7 Hello5
Hello3 World9
3hello 3world
hellohello World6
hello6 world5
Hello1 World4
Olleh world6
hello? world.
3hello world3
olleH Worlds
Hello3 7world
Hello9 world
5hello 8world
9hello world.
3hello World3
hellos dlroW
Hello9 world9
WorldWorld Hello8
olleH 3world
olleh world?
Hello5 world6
Olleh 8world
Helloed 6world
1hello World8
helloolleh world1
Hello7 worlD
Olleh World.
Hello6 1world
Hello4 World0
hellohello 1world
Hello5 wrld


Turning on some more rules:


Hello66666 Yworld
Hello07 world1111
HELLO9 world58
HelloR world1914
Hellov world15
dr.hello Qieks
Hello10 world1997
hello45 Wor1d
fqjju world1965
4hellos world1938
hellol world42
hello2012 world40
Hello222222 World14
Hello85 WORLD1
hellof World51
Hll WORLD7
Hello04 World66
Hello999999 2world
<hello> Worldy
Hello44444 world1923
Hello78 'world'
HelloC r[y'g
hello2009 World\
hello71 ld
%hello% Wor1d
Hello55 worlding
hello} World97

Is _already_ modeled by existing cracking software: They already try thousands of schemes like adding characters before and after the words in input phrases.

You are taking a bet that the cracker's parametrization of likely modifications won't include yours— but the community of attackers spends in total more than your _lifetime_ in time thinking about this problem every couple of years, and they have access to stolen password databases to test their theory against the behavior of great many people.  You might get lucky and choose a scheme they don't think of or that they consider too unlikely to search— or you might not, but as a user you are likely to do the likely thing, and not likely to know better.

There are attackers that are already precisely searching patterns like this.  Every sentence in every book in your local library (much less just the memorable ones) is only about 32 bits of entropy. Scheme selection is 8 bits. The prefix template of decimal digits (assuming uniform probability, which you probably won't get with a human selecting them) is at most 26 more bits.  This is not an impressively secure scheme, though you've just convinced yourself that it is.

This is why you should not be using anything like this, the human capacity for self deception is too great.

Just because people might misunderstand: K must be unknown to the attacker. Even if a K value is only used once, if an attacker has knoweldge of K and a single signature with it they can also recover the private key. It's also important that your Ks are not linearly related, or otherwise more sophisticated attacks are still possible.

No, lowering the time lowers the distribution parameter and increases the blocks found at the same time, this is true even if there is no serialization delay. Plus— there is no technical need to have to send N megabytes of data when a block is created, the vast majority can be preforwarded... but only P2Pool makes use of that today.

Would half work? Yes, it would almost certantly be fine today, but it's precisely in cases where you might need to do more work to process a block that the longer times are important.

You also don't need faster interblock times to have faster confirmation. Consider what P2Pool does, if the network enforced participating in a faster share chain for miners and that sharechain enforced transaction inclusion you could have much faster confirmations (though, of course, with reduced security)... importantly, SPV clients and others that don't care about the fast confirmations wouldn't need to pay attention to them— so the benefit could be had without doubling the bandwidth required for SPV nodes.

I'm not sure what you're talking about precisely— obviously double spends will never confirm, so thats not going to be "resolved".

I'm not sure why you think this would be all that advantageous.

You still cannot accept&connect the block without the whole thing, and you cannot verify the later parts of the block without the earlier parts (as blocks very often spend txouts created in the same block)— if you want instead to forward blocks without verifying them, you can do that without any chunking.  This was implemented some time back for the reference software in a pull req by luke but it turned out to not really improve performance much (esp after the ecdsa caching went in).

Yes, but G is security irrelevant for our normal usage in Bitcoin (and generally, except for some contrived examples— e.g. where I need to convince you that I don't know the discrete log of some nothing up my sleeve point X (X!=G), and I picked X long in advance and selected G so that I knew the discrete log of X, but this is contrived and isn't something that I can think of any reason we'd do in Bitcoin.

The term 'fully rigid' comes from safer curves and I complained to DJB that his own curves had no obvious specification for their generator on the site, and (after some back and forth there I gave him a sage implementation of an 'attack' in a contrived protocol) the page was revised to include an argument why the base point selection is irrelevant "What about rigid choices of base points? For each curve considered by SafeCurves, the specified base point is a generator of the specified subgroup. SafeCurves does not place restrictions on the choice of this base point [...]".

You absolutely can. First: whats hackable to _you_ is not whats hackable to some guy with powerful statistical analysis and a fpga cracking farm who, with one unit of effort, simultaneously attacks all users. Secondly, what I was more expressing was an OR case,  that frequently you secrets are either crackable OR they are likely to be lost.  Both of those possible outcomes result in you losing your funds.

A challenge there is that it may be quite hard to get users to understand that your collection of personal information there isn't to send it off to some server or put it someplace public... in querying around I got the impression that lots of people would put random things in those fields, defeating the protection.  It would probably be better than what people are actually doing.

There is another weird consequence is that you lose denyablity when using such a scheme. E.g. if someone does obtain your secrets then your address is effectively a cryptographic commitment to that personal info, it's harder to say "those transactions weren't mine". Thats a little bit into the realm of movie plot threats, but at least some of the people working on encrypted wallets have insisted on "denyability" as a feature, and people have used it as selling point for "brainwallets" (and also as an argument against writing down the key, which is probably the most prudent think you should do— considering the forgetting risk).

Unfortunately ripple is a federated/centralized system that requires opencoin to select a consistent set of trusted signers and for those signers to behave honestly. You can get a lot of scaling advantages if you're willing to trust.

That said— what they're doing doesn't reduce the operating storage requirements for nodes relative to pruned (section 7) Bitcoin... which, fortunately, doesn't change the security assumptions. (it does change the initialization bandwidth, though that didn't appear to be what the thread was asking about)

The inhibition of valid and interesting unusual use cases is enough that those protections had to eventually go in any case. See also: https://github.com/bitcoin/bitcoin/pull/4365

A lot of people have screwed themselves badly this way— you are not a unique and special snowflake, the ways and manipluation people will come up with when they are trying to be "random" is fairly predictable, and that the same properties which make keys easy to remember make them more predictable. Studies of have shown people picking _more_ predictable passwords when explicitly instructed to be unpredictable. Modern password cracking is a statistical study of psychology, powered by "big data" analysis on information culled from huge leaked plaintext password databases and sources like twitter and the forums.

Using a fancy technique may really only be adding a few extra bits of entropy, and worse it's very hard for you to reason about how much entropy you have and an attacker with more powerful statistical tools than your intuition may find your key with only moderate effort.  For this reason it is far better to use a random technique (e.g. dice or a computer CSPRNG) and just add a couple bits directly, then there is no ambiguity.

(Though this is all without regarding the very real risk of forgetting— almost no one is prepared to deal with cryptographic secrets which _cannot_ be recovered if lost, and most people drastically overestimate the strength of their memory)

Whenever a website turns up having a security breach and we find it was using unsalted passwords everyone cries out claiming that the operators are incompetent fools (perhaps even criminally so) and yet thats exactly what a human generated "brainwallet" is— an unsalted hashed password, but worse: they're publicly visible to everyone so someone doesn't even have to compromise a system before they start cracking.