Bitcoin Forum
October 18, 2018, 05:32:03 PM *
News: Make sure you are not using versions of Bitcoin Core other than 0.17.0 [Torrent], 0.16.3, 0.15.2, or 0.14.3. More info.
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 ... 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 [57] 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 ... 238 »
1121  Alternate cryptocurrencies / Altcoin Discussion / Re: [VNL] Vanillacoin, a quiet word of warning. on: January 12, 2015, 03:09:41 PM
FWIW, I politely reported the copyright violation (the code being a copy of Bitcoin Core run through an auto-formatter with all the attribution removed) as an issue on the github for the project and john-connor accused me of stalking him and then hid the issue tracker on that github from public view. :-/

I suppose I shouldn't be surprised as it's consistent with the rest of the concerns that resulted in creating this thread-- that there is some ongoing effort to keep that work out of the sunlight.
1122  Alternate cryptocurrencies / Altcoin Discussion / Re: [VNL] Vanillacoin, a quiet word of warning. on: January 12, 2015, 07:54:13 AM
Hah. Looks like poking here had some effect.

So... this code is substantially an older copy of Bitcoin Core (maybe copied from the ppcoin codebase? I see some fragments of that) with the attribution removed (in violation of the software license for Bitcoin core) and run through an ugly auto-formatter.


It also doesn't agree with the binary on the site (linux64 sha256sum b07f40515ee75b768424189942d44af8c68b816bfc3018da65f4af273a283183):

E.g. ECDSA verification in the binary on the site gives this disassembly:

Quote
000000000054bc00 <_ZN4coin3key6verifyERKNS_6sha256ERKSt6vectorIhSaIhEE>:
  54bc00:       48 89 5c 24 e8          mov    %rbx,-0x18(%rsp)
  54bc05:       48 89 6c 24 f0          mov    %rbp,-0x10(%rsp)
  54bc0a:       4c 89 64 24 f8          mov    %r12,-0x8(%rsp)
  54bc0f:       48 83 ec 18             sub    $0x18,%rsp
  54bc13:       48 8b 2a                mov    (%rdx),%rbp
  54bc16:       48 8b 5a 08             mov    0x8(%rdx),%rbx
  54bc1a:       4c 8b 27                mov    (%rdi),%r12
  54bc1d:       48 89 f7                mov    %rsi,%rdi
  54bc20:       e8 bb a1 03 00          callq  585de0 <_ZNK4coin6sha2566digestEv>
  54bc25:       48 89 e9                mov    %rbp,%rcx
  54bc28:       31 ff                   xor    %edi,%edi
  54bc2a:       ba 20 00 00 00          mov    $0x20,%edx
  54bc2f:       48 29 eb                sub    %rbp,%rbx
  54bc32:       4d 89 e1                mov    %r12,%r9
  54bc35:       48 89 c6                mov    %rax,%rsi
  54bc38:       41 89 d8                mov    %ebx,%r8d
  54bc3b:       e8 d0 59 1e 00          callq  731610 <ECDSA_verify>
  54bc40:       83 f8 01                cmp    $0x1,%eax
  54bc43:       48 8b 1c 24             mov    (%rsp),%rbx
  54bc47:       48 8b 6c 24 08          mov    0x8(%rsp),%rbp
  54bc4c:       0f 94 c0                sete   %al
  54bc4f:       4c 8b 64 24 10          mov    0x10(%rsp),%r12
  54bc54:       48 83 c4 18             add    $0x18,%rsp
  54bc58:       c3                      retq  
  54bc59:       90                      nop
  54bc5a:       66 0f 1f 44 00 00       nopw   0x0(%rax,%rax,1)

compared to this source code:
Quote
bool key::verify(
    const sha256 & h, const std::vector<std::uint8_t> & signature
    )
{
    bool ret = false;
    
    if (signature.size() > 0)
    {
        auto ptr_signature = &signature[0];
        
        ECDSA_SIG * ecdsa_sig = 0;
        
        /**
         * Make sure that the signature looks like a valid signature before
         * sending it to OpenSSL (like in the test cases).
         */
        if (
            (ecdsa_sig = d2i_ECDSA_SIG(
            0, &ptr_signature, signature.size())) != 0
            )
        {
            std::uint8_t * pp = 0;
            
            auto len = i2d_ECDSA_SIG(ecdsa_sig, &pp);
            
            ECDSA_SIG_free(ecdsa_sig), ecdsa_sig = 0;
            
            if (pp && len > 0)
            {
                ret = ECDSA_verify(
                    0, h.digest(), sha256::digest_length, pp, len, m_EC_KEY
                ) == 1;
                
                OPENSSL_free(pp), pp = 0;
            }
        }
    }
    
    return ret;
}

Which contains a workaround for the change in OpenSSL behavior that the john-connor was so busily insulting us about. The disassembly shows no calls to d2i_ECDSA_SIG in that function-- the only one in the whole binary is the one inside OpenSSL that was there all along.  Extra fun is the fact that this change appears to have been deceptively backdated in the git repository to December 9th.

Doesn't appear to have any of the GUI code either; I wonder what other ways the source doesn't agree with the binary?
1123  Bitcoin / Development & Technical Discussion / Re: Can you create a Bitcoin address manually? on: January 12, 2015, 12:48:18 AM
5. Use the ECDSA point doubling formula and point addition formula on the generator point to get the public key. This will probably take a few days.
I think this is basically intractable manually if done naively. You're talking hundreds of millions of 32 bit operations. Even if you were able to retire one per second and worked 12 hours per day you're talking 6+ years.

Thats why I suggested a book of pre-generated G multiplies.  You'd also need to do the arithmetic with jacobian coordinates to avoid performing a modular inverse for every operation. Based on timings people gave for sha256 by hand, I think it could be gotten down to a week or so, though fiddling around with the numbers a bit I'm less sure.
1124  Alternate cryptocurrencies / Altcoin Discussion / Re: [VNL] Vanillacoin, a quiet word of warning. on: January 11, 2015, 06:57:10 PM
The last post on it's thread was on February 25 so as far as I'm concerned the coin's already dead. Anyone who read's it's 3 page thread will notice this warning so I doubt the dev will be able to scam many people..
Hm? The announce thread started 2014-12-12 and was locked 2014-12-23.

Interesting, looks like there was another bytecoin style name reuse.
1125  Bitcoin / Development & Technical Discussion / Re: locktime on: January 11, 2015, 05:32:48 PM
What do you mean with "can never be enforced"? If a replacement is broadcasted long before nLockTime expires, it is unlikely
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.
1126  Bitcoin / Development & Technical Discussion / Re: Can you create a Bitcoin address manually? on: January 11, 2015, 07:28:16 AM
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.
1127  Bitcoin / Development & Technical Discussion / Re: Is it possible to keep non-transaction data out of a blockchain? on: January 11, 2015, 07:25:12 AM
x = SHA-256(offchain data)?
So you can refer to arbitrary size data, right?
Sure.
1128  Alternate cryptocurrencies / Altcoin Discussion / [VXC] V.Cash (Was: [VNL] Vanillacoin), a quiet word of warning. on: January 11, 2015, 07:04:43 AM
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]
1129  Bitcoin / Development & Technical Discussion / Re: Is it possible to keep non-transaction data out of a blockchain? on: January 11, 2015, 05:36:18 AM
So I'll encode my data in the transaction amounts
Again, you're limited to a fairly small number of bits at considerable costs, even without any additional artificial limitations.

Quote
can link to a larger amount of data: e.g. 80 bits can be an .onion address
Great; and thats outside of the blockchain, which was the goal of the OP's post.
1130  Bitcoin / Development & Technical Discussion / Re: locktime on: January 11, 2015, 01:27:46 AM
Is there any use for sequence at all (other than backwards compatibility)?  It seems whatever Satoshi intended sequence to be used for can never be enforced.
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.
1131  Bitcoin / Development & Technical Discussion / Re: Is it possible to keep non-transaction data out of a blockchain? on: January 11, 2015, 12:50:06 AM
Granted, all of this does make it significantly more expensive. But it's still quite possible.
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.
1132  Bitcoin / Development & Technical Discussion / Re: locktime on: January 10, 2015, 11:00:09 PM
any more.
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)
1133  Bitcoin / Development & Technical Discussion / Re: Please answer 3 technical questions on: January 10, 2015, 10:28:54 PM
That's all very fine. The "transaction" is useless unless it's confirmed by miners. The energy question (10bn people * 10 transactions per day) still stands.
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.

Quote
The consumer and the retailer don't care about the technical nuance you've described (that a transaction is separate to a confirmation).
They may well not, and so what of it?

1134  Bitcoin / Development & Technical Discussion / Re: Is it possible to keep non-transaction data out of a blockchain? on: January 10, 2015, 09:41:42 PM
To secure the output against misuse one could require that the "pre-hash" be included when a transaction is relayed or when a block is published.  For Bitcoin the ScriptHash = RIPEMD160(SHA256(script)).  So the RIPEMD160 hash would be in the output and the transmitting node would also include the prehash (output of the SHA256 function) with the transaction.   Nodes would take the SHA256 "prehash" hash it and verify it matches the output to confirm the output has a valid hash.  Once a txn was sufficiently deep in the blockchain to make re-orgs unlikely, nodes could discard the prehash.
When someone independantly invents the same idea, you know it must be at least somewhat good. Smiley (uh, well actually, maybe not. Tongue )

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

Quote
Any other ideas?
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).

I'm pretty sure it's impossible.
The impossible presented. I'm glad to be of service.

So you stick your non-transaction data in there as the "prehash".
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).
1135  Bitcoin / Development & Technical Discussion / Re: Please answer 3 technical questions on: January 10, 2015, 09:35:58 PM
Using reason and logic only. Leave the emotion and speculation to the other threads please!!!
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.

Quote
1. Assuming silicon ASICs have now approached their limit, how much energy (in Watts) would be required if there were 10bn people on the planet and there was an average of 10 transactions per person, per day?
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.

Quote
2. Is there any way to get the transaction time down to below 10 seconds? (i.e. suitable for buying a coffee or paying for my groceries)
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.

Quote
3. Is centralization of the network inevitable?
Thats up to the users of Bitcoin.
1136  Bitcoin / Development & Technical Discussion / Re: We should really think about adding Point-to-Point Encryption on: January 10, 2015, 03:25:08 PM
Gmaxwell, I studied the code, and noticed that the "version" message would include the "addrMe" field, which is populated from LocalAddrs, which again contains the own public IP (for example gotten from UPNP). Would that be a concern when using tor? If so, using Tor would be pointless.
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.).

There is no feasible way to MITM diffie hellman. If you can do so, you will get all my BTC if you provide a working way.
So you've flipped to the other side of wrong these days.  MITMing a DH key exchange is trivial, you just _do_.

Quote
I should have mentioned that we need some kind of authentication.
Authentication is basically all the complexity in a system, not something you just can wave away.

Quote
Similar to the way it is implemented in TOR.
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".
1137  Bitcoin / Development & Technical Discussion / Re: We should really think about adding Point-to-Point Encryption on: January 09, 2015, 10:02:51 PM
We have encryption: Use Tor. It's a strongly supported solution which addresses many privacy concerns that plain encryption cannot.

Quote
diffie-hellman handshake
Weren't you trying to sell your "crack" of ECC here some months ago?
1138  Bitcoin / Bitcoin Discussion / Re: A question about Bitsamp Hack and Security in the Blockchain on: January 09, 2015, 10:01:33 PM
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.
1139  Other / Meta / Re: Replacing DefaultTrust on: January 09, 2015, 08:49:07 PM
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.
1140  Bitcoin / Development & Technical Discussion / Re: New HD wallet that tolerates leakage of some child private keys on: January 08, 2015, 11:29:33 PM
And if the nonce is "secret but constant" than you're screwed anyway.
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.
Pages: « 1 ... 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 [57] 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 ... 238 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!