Thats unsafe. It will cause random, surprise, state divergences; along with attacker triggerable ones. Such a thing needs a consensus system to decide on what the requirements are. This is what we have mining for. Consider an attacker who floods the network concurrently with many different spends all the time. Miners have no idea that other people got different spends (and can even be prevented because the information is simply out of their lightcone). Even if they have some awareness, they have no idea what the majority of the network is accepting. We have mining precisely to resolve this ambiguity in the state of other people's systems.

With pen and paper it could be done maybe a week of hard work, at least if you also allowed yourself a table (like a big printed book of precomputed EC points).

You'd probably want to run the whole computation multiple times to be sure you didn't make an error.

Sure.

Greeting, this evening john-connor showed up on the Bitcoin Core github with some rather aggressively ignorant minunderstandings of basic cryptographic consensus concepts: https://github.com/bitcoin/bitcoin/pull/5634#issuecomment-69481908

Having no clue who he was I looked at his github account and googled a bit and found that he is the, seemingly pseudonymous, author of "Vanillacoin".

Vanillacoin was previously discussed on this forum, https://bitcointalk.org/index.php?topic=890388.0 but he locked the threads in order to shuffle the users (victims?) off to someplace out of the light of day-- never a good sign, (nor is his BCT newbie account, for that matter).  The "vanillacoin" software has no source code available, it is binaries only (very much not a good sign, and usually severe malware concern; and an ultimate form of centralization), there are source links but they go to a basically empty github repository. There is a whitepaper, which like the comments on github show some general software development background they show no real sign of sophisticated understanding around decenteralized systems for adversarial networks or cryptocurrencies.

I don't know anything more about it, but I figure sunlight tends to be a good disinfectant; and with the threads locked it probably wasn't fair of me to say nothing while I was privately thinking "hm, that all smells pretty fishy".  Of course, the guy was a bit rude to me and also wasted my time-- so feel free to factor that bias in however you like. I'm just reporting my impression as a regular community member. You now know what I know.

[I'm the last person to play altcoin-cops... I mostly avoid this stuff except for the rare cases that are technically interesting: The drama can sink unbounded time and usually, when it comes to the more misguided altcoin cryptography, the only sane policy seems to be "If you see something,say nothing and drink to forget": there is too much crazyness and risk of being attacked for being critical of someones latest scheme. But if it shows up in my face, I can't quite stomach saying nothing at all.]

Cheers,


[Edit: Vanillacoin changed names to V.Cash]

Again, you're limited to a fairly small number of bits at considerable costs, even without any additional artificial limitations.

Great; and thats outside of the blockchain, which was the goal of the OP's post.

It's potentially useful in your own protocol, at least. Not _everything_ that reads a transaction is the blockchain. It could potential gain some productive use (beyond the binary max or not for locking) in a softfork.

It basically makes a data storing party have a huge (e.g. dozens fold) disadvantage against normal users, even if you give them large computation, and at that point economic pressures are likely more effective.  Pragmatically it may change how things work legally.  People might order a newspaper to censor an old classified in its archive, they're not so likely to do ask the censoring of 50 articles each which leak one letter; at some point the "message" is really embedded in the decode instructions rather than the data elsewhere.   You've gone from outputs in a transaction being able to code kilobytes with modest overhead, to, say, a couple hundred bytes with huge overhead.

There was some code stubbed out to do that, but it was never implemented as far as I recall. Do you have a reason to believe they actually were? (if you don't I don't want to waste time spelunking through old code)

Okay, so not only do you not search first, you apparently choose not to read: I just explained that the energy used by mining at a given security level is unrelated to the volume of transactions. It is the same regardless if there is one transaction or one hundred million transactions. The amount of energy related to the count of transactions is zero. So, there you go: If you insist on getting a binary answer to your ill poised question instead of learning, the answer is zero.

They may well not, and so what of it?

When someone independantly invents the same idea, you know it must be at least somewhat good. (uh, well actually, maybe not. )

I called this P2SH^2: http://sourceforge.net/p/bitcoin/mailman/message/30705609/

Yes, I have a more powerful scheme that doesn't _ever_ distribute the pre-image, it goes as follows:

First some super sloppy background so the rest makes sense to people who don't know it (you can skip if you're familiar with pairing crypto):

A BLS signature is a simple signature scheme for pairing cryptography which uses groups where computational discrete log is believed intractable but the decisional discrete log problem is tractable. BLS signatures have the important property that a signature is _unique_ for a given pubkey,message tuple there is only one signature possible. Pairing crypto works like ECC, but you have an additional operation pairing(point, point)  that can be used to solve the decisional discrete log problem.

The construction of a BLS signature is,

G is a generator of the group, I'm writing it additively here.
H(y) is that converts y to a point on the curve such that the discrete log is not known. (e.g. it's some direct bit coercion not y*G)

secret key: x
pubkey:  xG
sign:  sig = x H(message)
verify:  pairing(H(message), pubkey) == pairing(sig, g)

Verification is basically answering the question "Is sig the ECDH value for the pair of points pubkey and H(message)".

Here is how you can use this to suppress the convert channel:

H2 = sha256 or what have you, random collision resistant hash.

secret key:  x  == data you want to encode
pubkey:  xG  == assuming the data is the size of the order of the group this is a one way computable bijection, if the data you wanted to encode was a a secure hash, so is the pubkey.
proof:  proof = x H(H2(pubkey))

Proof now shows that pubkey is a point you know the discrete log of,  hardness of the discrete log in the group shows you can't pick some data embedding pubkey as you wouldn't know the discrete log.

You transmit {pubkey, proof}

You can't do this trick using regular ECDSA/schnorr signatures as far as I can tell because the non-uniqueness allows you to use knowledge of the nonce as a trapdoor.

This reduces your covert channel to only the small bits that you can afford to grind into it with guess and check. If the values already have to meet some computational criteria (e.g. you always have to grind) then any additional grinding is a multiplication on that, so with a linear cost to honest users that exponential cost channel can be made as computationally expensive as you like.

Better: a complete failure of the cryptosystem only reintroduces the covert-channel, it doesn't compromise the security of your P2SH.

Downside:  The proof adds another group-element (e.g. 32 bytes for 256 bit security) size amount of data, and the verification takes on the order of 1ms. Hashing (required at spending time) requires a point scalar multiply, which is also slower than a classical hashing function (though much better than a half ms).

It may be possible to construct something similar with RSA signatures; but I haven't tried and the cost of deterministically generating a private key (hashing your message) may be problematic... and obviously the size would be unattractive. I think basically the same can be done with any unique signature scheme where the signature leaks no information about the private key (E.g. doesn't work with a lamport signature, though they're trivially unique).

The impossible presented. I'm glad to be of service.

Yes, but you can verify this prehash only for blocks on the tip, not the history. and forget about it. So I think that fits at least some definitions of "out of the blockchain". (Though as I just demonstrated even that weakness can be closed.)

Anything here works better with a somewhat narrow definition of "out of a blockchain". Even with outputs fixed signatures still end up with a covert channel (though something with very limited functionality could also make it arbitrarily narrow, again using unique signatures), but most of my thought in this space has been centred around eliminating high bandwidth covert channels for data that all participants are strongly forced by the system to store.

There are also other things that can be done here.  A utxo is, roughly,   txid:vout -> {scriptPubkey, value}.   You could instead store H1(txid:vout) -> Enc(H2(txid:vout), {scriptPubkey, value})   to locally blind yourself to this data until the very moment it's needed (when a block shows up that actually spends the output).

Let me match your request with another request: If you want to get useful answers please do some research first. Your questions betray misunderstandings of the most basic bitcoin concepts. When you post you consume other people's time.

The energy requirement for processing a transaction are very small and are completely unrelated to mining ASICs. Mining ASICS do not process transactions. They provably expend energy to make reversal of the history of transactions infeasible and for a given security level consume the same amount of energy regardless of the transaction level.

You are confusing transaction time and transaction confirmation time. Bitcoin transactions are basically instantaneous (just the time it takes to communicate the data) but it takes time for the transaction to become irreversible. The same is true for other payment mechanisms, e.g. credit card transactions can often be reversed for months, checks take weeks to clear... Making a 1:1 comparison is hard because Bitcoin is used in different ways from traditional payment systems (including anonymously). But it is not the case that the 10 minutes mean time between blocks itself has any fundamental implication for buying coffee.

Thats up to the users of Bitcoin.

Study harder.  It doesn't in that case.  (And, even if it did make such a colossal goof the other advantages of using tor would still persist.).

So you've flipped to the other side of wrong these days.  MITMing a DH key exchange is trivial, you just _do_.

Authentication is basically all the complexity in a system, not something you just can wave away.

It's unclear of what you mean here; if you mean the way the tor network prevents MITM/sybil attacks between it's own participants; thats accomplished via centralized "directory authorities".

We have encryption: Use Tor. It's a strongly supported solution which addresses many privacy concerns that plain encryption cannot.

Weren't you trying to sell your "crack" of ECC here some months ago?

For all I "know"- in a strong sense-- Bitstamp sold those coins to an innocent third party.  (Or, if implicating Bitstamp is indeed too crazy for you: The hacker could have directly sold them to an unaware third party; and half the coins flowing there could actually be unrelated to Bitstamp.)

Be mindful of what you know, vs what you think you know.  Part of the value of the system is that it minimizes importing human judgement into its operation.  If it does that then there is no clean boundary, and risk analysis is much more costly.

It would be nicer if it could tell you about which of the recommendations you've communicated with before (maybe with links to some past threads where you've posted after them)... but sadly if you're new to the forum that data doesn't exist.

It's actually okay to do this so long as your keys are truly unrelated you never reuse keys!  I ... don't know why you would ever do this! but there is some madman that appears to be doing this on the Bitcoin blockchain.

(well, okay, I can give an example of why you might do this:  If I don't have to compute kG, I can do a signing operation in under 1 microsecond, or about 100x faster.  But its still darwin award grade stupid.)

The reason I brought it up is that it just to illustrate that the reduction argument wasn't complete. It's probably not possible to make it complete given the shortcomings for provable security for ECDSA in general, I wouldn't fault your paper for it; only to note that risk isn't _completely_ eliminated by the proof.

There is no facility to directly do this in the Bitcoin protocol, nor is there ever likely to be. The Bitcoin network is not a free file server, nodes provide data to other nodes for facilitating the operation of the Bitcoin system-- and normal operation has no need for a lookup by height.

You should run your own node and then you can trivially query it over the json rpc (or rest in Bitcoin v0.10).

Can you please help me understand how this would be useful in practice? The amount of tolerated leak is linear in the size of the scriptpubkey. Just giving a party random address also achieves that. Using the homomorphic derivation is attractive for cases where the linear size is not acceptable.

This is explicitly called out in the specification, it is not folkore or a revelation.

Very interesting observation!

Though it's arguably more fragile in one sense that you may think you can release a private key securely but really you cannot because if you leak too much you are broken. It's difficult to write software which will only act a small non-zero number of times e.g. it crashes and forgets that it's already performed one disclosure, certainly the user cannot be counted on to remember such things.  So I think it would be an obvious improvement and might well be worth an increase in the resulting master public key size just for additional robustness, I don't know that in practise it would safely permit intentional use of it.

Your security argument rests on 1MDLP, but we actually use these keys in the context of ECDSA. Inability to solve the DLP (or 1MDLP) does not provably result in the security of ECDSA, and ECDSA reveals another (random) linear relationship with the keys in question; it's concealable that it could undermine the security of the scheme. For example, imagine if the nonce were secrete but constant.  Off the cuff, I do not see a reason that this is problematic for the security of your construction. Though in an abundance of caution we specifically constructed BIP32 to avoid constant any linear relationship out of concern for potential interactions with ECDSA which we were unable to prove did not exist.

Absolutely. The implementation with the wrong signing RNG generating recent discussion was absolutely equally exposed for newly created keys as well.  It's just that the ratio of newly created wallets to signatures from existing ones is low (and perhaps the thefts related to new wallet with bad keys more latent).