This thread is not self-moderated, so only the forum moderators are deleting posts here. Though it ought to be self moderated, because the incessent trolling is really over the top.

See also: https://bitcointalk.org/index.php?topic=29675.msg3490536#msg3490536

Yes, you wrote that and I understood what you wrote— but that precisely what I was saying no to, it's actually less computation _and_ less space.

[As far as the ranting about thread moves, we were having an extensive sidebar about hash based signature in a months old thread that was very clearly about _ECC_, thats all. Nothing personal.]

No, it requires less computation (than the bidirectional enumeration) and much less space for normal choices of parameters. There are a couple additional codewords (usually two for normal parameters) but all the codewords are half the size of that ladder proposal.

You see incorrectly.

Nothing, which is why it would be pointless.

It was probably mined seconds after the prior blocks. The timestamps are only approximate.

Uh, it's called  a Winternitz signature. Google it.

I like lamport a lot— and first proposed we someday add some form of it to Bitcoin back in 2011... though straight up lamport's single use-ness is a major liability (e.g. say you need to resign an input to add fees later, maybe a couple times… oops, compromised your key).

The space overhead is really considerable— even when using Winternitz compression, to the point that it couldn't be a replacement for bread and butter transactions, but I think it would be nice to support.

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.