Bitcoin Forum
March 06, 2015, 03:59:58 AM *
News: Latest stable version of Bitcoin Core: 0.10.0 [Torrent] (New!)
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 2 3 4 5 6 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 ... 192 »
481  Bitcoin / Development & Technical Discussion / MOVED: Using to get realtime updates on: August 13, 2014, 05:18:56 AM
This topic has been moved to Service Discussion.
482  Other / Beginners & Help / Re: Grabbing other peoples private keys with bitcoin-qt on: August 12, 2014, 05:08:49 PM
(for example, the heartbleed bug in 0.9 - I might be misunderstanding what exactly is possible, but it was bad enough that 0.9 is insecure).
Bitcoin core has never exposed SSL to the internet in any sane configuration. So no, that wasn't generally possible. For the vast majority of users the fix wrt that was precautionary.
483  Other / Beginners & Help / Re: Grabbing other peoples private keys with bitcoin-qt on: August 12, 2014, 04:18:51 PM
I just grabbed your USD bank account balance balance while grabbing your message.  
484  Bitcoin / Development & Technical Discussion / Re: O(1) block propagation on: August 12, 2014, 03:20:39 AM
Don't also miss

See also the PGP SKS keyserver, which uses efficient set reconciliation.

This change can launch Bitcoin from being a serious competitor to Western Union (today) to a serious competitor to VISA (later next year).

I'm a fan of fancy schemes to increase efficiency (see link) but that is a bit over the top.

The impact is much more modest than you're thinking, especially compared to the kind of forwarding that p2pool and bluematt's relay network already do (send blocks without repeating transactions that the far end already knows you have). The transactions still must be sent and validated. It does avoid the 2x bandwidth overhead of sending it again with the block, and the marginal latency that implies— but so do simpler tools e.g. matt's relay for me has a hitrate of "In total, skipped 140004 of 142773 (0.9806055766846673%)" since last restart.

Unlike some other technologies like fraud proofs these doesn't change the decentralization/scale tradeoff or the bandwidth usage (It's still O(n) with the number of transactions, they're just happening earlier). It's all awesome sauce and all and should be a great thing to have, but that I love this stuff makes it hurt all the more to see it exaggerated. Smiley
485  Bitcoin / Development & Technical Discussion / Re: Blockchain type on: August 11, 2014, 08:15:27 PM
You may find this some interest

Without an articulatable/articulated security model it's not especially interesting to me at least.  We already have a reduced security model available and widely used in Bitcoin which is highly scalable.
486  Bitcoin / Development & Technical Discussion / MOVED: BitUndo? on: August 11, 2014, 08:00:54 AM
This topic has been moved to Service Discussion.
487  Alternate cryptocurrencies / Altcoin Discussion / Re: Creating revolutionary new alt-coin.. Need people to bounce ideas off of on: August 09, 2014, 08:56:20 PM
Beyond having many unpaid debts, this class of idea has been proposed many times before. They don't appear to be good ideas for many reasons that other snazzy POW algorithms fail— no reason to believe them to be optimization free or approximation free, see Andy's asic/pow whitepaper for some more background:  Regardless, considering this class of idea has been proposed before— why would anyone who had the technical chops to work on it (much less the breakthrough required to make it not fail-sauce) work for someone else and not just for themselves?
488  Bitcoin / Development & Technical Discussion / Re: Reading Block directory : Sequential write ? on: August 08, 2014, 11:57:13 PM
Thanks, I understand this solution is fragile.
However, I don't see any solution yet that permit enumeration of blocks of bitcoind with high performance.
RPC is usable, but at enumeration of 300 000 with RPC is 10 000 times slower than using the blk directory directly.
I don't want either to implement a full node in NBitcoin, this is serious business and any subtle incompatibility with core would provoke a fork.
Is there another solution ? If not, is it possible at least, to expect if it were to change in the future, a flag to bitcoind to always store full blocks in directory ? (but don't use it)
Or a getblocks (with 's') in the RPC API ?
You can speak the P2P protocol just to fetch blocks— right now this is the fastest way... Note that I'm not suggesting you implement a full node (you are wise to avoid that), but instead use bitcoind as a filter and fetch blocks over the p2p protocol.

RPC getblock"s" would likely not be a lot faster due to the fact that much of the time is spent on the JSON handling.
489  Bitcoin / Development & Technical Discussion / Re: Reading Block directory : Sequential write ? on: August 08, 2014, 10:37:57 PM
Thats certantly the case today but we make no promise to maintain that in the future, if changing it serve some useful end. The block files are not really a user facing interface. Headers first will make it write to them out of order (but still append only), but pruning may delete whole blocks out from under you and also in the future we may implement things like compression which changes the format.
490  Bitcoin / Development & Technical Discussion / Re: Full node reward - request on: August 07, 2014, 07:53:14 PM
Well, if you're setting up 1000 full nodes then you're doing a lot to help the network, so I'd say you'd deserve a good chunk of donations (we're not trying to force anyone to donate, just allow anyone to prove that a full node is associated with a specific address).
1000 nodes run by one party is very harmful to the network compared to just running one system with more capacity, consolidating node control like that reduces the diversity of voices available to other hosts. Done maliciously it would be called a sybil, done innocently its just a waste.
491  Bitcoin / Development & Technical Discussion / Re: BIP proposal: Canonical Deterministic Signatures on: August 07, 2014, 02:05:04 PM
RFC 6979 is hash-function agile, though it suggests that you use the same hash for its hmac as you use for message hashing in your signature. I believe it's being used by some Bitcoin wallets already, and although the spec is wordy the implementation is pretty straight forward.

It's my general preference to stick with a construction that has has more review absent a good reason not to. E.g. Just do 6979 but with the HMAC-SHA512 used for derivation elsewhere. This way one of the answers to 'oh no I'm giving my private key to this!' is "It's a standard"... obviously this is no excuse for us to not review it too, but it will increase other people's confidence if the specific construction has been widely reviewed.

I also think it's a good idea to have a single spec which defines everything you need in signing, see my BIP 32.5 mailing list post.

It would be good to review what other things are doing. My strong preference would just be to give a simplified explanation of 6979 using HMAC-SHA512,  plus the low-S rule, plus canonical DER encoding. Sipa's canonical encoding BIP can just explain enforcing the canonical encoding rules.  Hopefully we can get everyone behaving consistently, particularly for hardware wallets its important that the _exact_ behavior be verifiable so that you can preclude the possibility of kleptographic backdoors.
492  Bitcoin / Development & Technical Discussion / Re: BIP proposal: Automatic Wallet Backup scheme on: August 06, 2014, 01:26:15 PM
Please do not use a #@$@ number without an assignment. Just call it BIP-oleganza-backup for the moment, until the text is ready.  Otherwise we get a mess of number collisions and people calling things by colliding numbers they picked and not wanting to change them. Smiley (this isn't nitpicking, it's happened multiple times)

Otherwise— this sounds useful! Should it perhaps specify more of the storage service? e.g. how much data can you expect to store, how would such a service be compensated? how would you know which service(s) you're using?

The last in particular seems to be a tough question... but in general we should probably try to specify a "minimum interoperable unit", and I'm not sure if the message alone is terribly interesting.

WRT the spec.  The IV really should be non-determinstic, it's already stored in the encrypted message. With a constant IV an observer can tell with AES block precision where the first modification to an updated copy was (and perhaps some more elaborate attacks, e.g. it would be trivially insecure if the cipher mode selected was CTR—). There is no need for the IV to be deterministic that I'm aware of... If you're worried about embedded device RNG quality, you could recommend that the IV be constructed as H(time||other-random||pubkey).

You appear to have no length encoded for the plaintext. AES-CBC is only capable of encoding an integral number of blocks, so something must encode the plaintext length.  I might suggest it use self-descriptive padding, e.g. there is always at least 1 byte of padding, and last byte says how many bytes of padding there are (up to 16, though perhaps some applications might want more padding to close a size sidechannel?).  Another style of self-descriptive padding I've seen used is to pad with a 0 bit and then all ones until the end, and the receiver drops all trailing 1s and the last 0 (has the advantage of fewer decodings being invalid).

The signature encoding can be made constant length, and probably should be, doing so will save at least one byte (and probably several, depending on how you were planning on having a variable length signature encoding).

Is there a reason to keep the AuthFingerprint?  It can be derived from the message itself and the signature (e.g. how bitcoin's signed message works), omitting it would save ~19 bytes.

Is there a particular motivation for using a digital signature instead of using a MAC?  One reason I could see is that you might want to have multiple servers synchronizing their data without individually talking to the user, like the PGP SKS keyserver— but for that case you'd want to add a sequence number (so you know if an update you're getting is a newer message or not).

Should these encrypted data chunks have a good-until date coded in them? I'd say it could be provided out of band, but not if we wanted it to be authenticated by the signatures (for the imagined synchronization network).

[Hm. Wow, a synchronizing server would be super cool for this, if we had a good way of avoiding abuse.]
493  Bitcoin / Development & Technical Discussion / Re: Rule 30 automaton as hash function on: August 06, 2014, 09:27:50 AM
Cellular automata may actually be difficult to analyze mathematically. Maybe like the game go you mentioned. And proving randomness is really tricky. My guess is that the R30 hash function acts well as a random oracle.
Except you already proved it bad by conventional cryptographic standards in where you find a collision. A good hash-function is not efficiently distinguishable from a random oracle (other than in the trivial sense where it has a compact implementation).

I've struggled a bit watching along worrying that this thread is a train-wreak of everything wrong with amateur cryptography: There are many reasonably well studied and designed functions in this space already (hash functions, and hashcash as proof of work), that benefit from decades of knoweldge and experience in building constructs which are actually irreducible for the purposes they're designed for... This is precisely the kind of effort people are counseled against, and for good reason.

Being difficult to analyze mathematically is pretty much the polar opposite what we want in a cryptographic building block— there is just an extreme danger of a complete break lurking right behind an intellectual speed-bump.  It's often said that anyone can come up with a scheme that they can't crack themselves, but it's perhaps more interesting to note that almost anyone can come up with a scheme with a trivial weakness but which is hard enough to analyze that no one will find it until someone's money (or life!) is on the line.

OTOH, I'm happy people have been having fun; and most of the other POW navel gazing I've seen is even more worthless... I've drafted and canned a couple messages for this thread, struggling with the difficulty in conveying a kind of underlying understanding of what responsible work looks like for cryptographic primitives— telling you to time travel back to 1994 and read sci.crypt with me is not likely to be helpful....

—  but when you get to the point of making claims that the function might actually be useful in cryptographic applications, I feel the need to speak up before another one of these incidents (which was caused by this thread, which went without adequate criticism) happens (read all the messages, not just my first response).

Have fun, by all means— but cryptography is a subtle and difficult science and art. Building a good system is an engineering discipline and having any confidence of security requires formalizing your work and putting in effort which is orders of magnitude more difficult than the basic implementation tinkering. If you don't find that kind of hard core analysis interesting yourself, then sadly it's likely never going to be done for your function. I'd say you were on the right path when you attacked and found a severe cryptographic flaw in your approach, but then something went wrong when you discarded it and continued like it never happened...  If BCT were a forum that I expected competent cryptographic review in, I might also say that something has gone wrong that it's taken this long to get a less than supportive message in this thread.

You were on to something with your attack— why not dig into it more and instead of adding complexity (which might just be obfuscating weaknesses instead of removing them), just assume this is a fun learning experience and see how many other ways you can break the original construct or what other kinds of seemingly-okay-but-really-broken functions you can build in this space?  I think more than anything else doing cryptanalysis and finding holes in functions has increased my appreciation for the enormous challenge that doing good work in this space involves. (I suppose I could say that In one sense there is no science of cryptography except cryptanalysis).

But this is just my curmudgeonly view, offered for your consideration.
494  Bitcoin / Development & Technical Discussion / Re: CoinJoin: Bitcoin privacy for the real world on: August 06, 2014, 09:01:03 AM
This is very safe, however it is not very private. It is essentially not possible to "lose" your coins doing this, however it has been proven that these types of transactions can be traced by inspecting the blockchain.
Don't confuse's completely broken "Shared Send"— they provide no privacy at all for reasons unrelated with this thread. The privacy implications of well constructed CoinJoins are discussed in some depth in the initial post and some other posts in this thread.
495  Alternate cryptocurrencies / Altcoin Discussion / Re: Changing the 21 million bitcoin limit on: August 05, 2014, 11:53:04 PM
The op has been a member here since 2011, I don't know how you could be here and not hold at least a few coins.
Presumably because he purchased the account, note the two year gap in activity and total change in character.

In any case, this is offtopic for the technical discussion area. Any such system wouldn't be Bitcoin. Cheers.
496  Bitcoin / Project Development / Re: [Tracker] Stealth Address Support on: August 04, 2014, 06:58:07 PM
On the Payment Ids issue - if 2 people are sending to me anonymously why not create a "satoshi" string at the end.
For example
Justus owes me 1 BTC as does you for a service -
I work with Justus and have him send me 1.00001234 string and gmaxwell is 1.00001235
Thats pretty inefficient and not very private.  It would be straightforward enough to just allow a suffix on addresses e.g. 

B123456789BCDFG-00001  and encrypt the suffix using the negotiated  ephemeral key and include it in the aux data.
497  Bitcoin / Project Development / Re: [Tracker] Stealth Address Support on: August 04, 2014, 06:50:25 PM
Already we seem to have not learned from the experience with this kind of address in Bytecoin/Monero/etc.—  Payment IDs are an important feature but also a usability challenge with the way they're implemented in BCN/XMR/.... Right now with the way dark wallet implements this if you ask two different parties to pay you with the same address and only one of them does, you cannot tell which one paid you.
How is this any different than the problem we have right now without stealth addresses?

1) Some merchant uses a wallet containing a single address to accept payments (yes, people really do this).
2) They give the address to two customers.
3) Only one customer pays.
4) Merchant doesn't know which customer paid without asking them.

It doesn't make sense to delay stealth addresses because they don't solve every problem.
Virtually all merchants (and, by definition, all competent merchants) use unique addresses in Bitcoin. This is widely supported, widely practiced, etc.   The fact that you can screw it up and a few people do is no excuse to make an uncommon mistake mandatory.

"Stealth addresses" as currently proposed break what already works pretty severely— using a different address per user makes scanning have a quadratic cpu costs in the number of payments you receive. Bytecoin/monero/etc. have payment IDs which address the issue, though the don't have a way to serialize them with the address— so they get accidentally left out a lot, which seems like an easy-to-address shortcoming.

Making stealth addresses "tip jar only" makes them far less interesting. There is no reason that all payments couldn't be done with this kind of address— assuming it was well constructed, and users would be much less private if only a narrow usecase uses them.
498  Bitcoin / Project Development / Re: [Tracker] Stealth Address Support on: August 04, 2014, 05:13:01 PM
There are a great many things that can be done wrong— including the fact that a poorly done reusable-address proposal can preclude adoption of a good and usable one ("We've already got that, low priority to add another one",  "We're not going to spent time on that— as you can see it's not widely used"). An early flaw was already avoided where it would be incompatible with having a third party scan for you or hardware wallets... lots of stuff to possibly get wrong in this space.

Already we seem to have not learned from the experience with this kind of address in Bytecoin/Monero/etc.—  Payment IDs are an important feature but also a usability challenge with the way they're implemented in BCN/XMR/.... Right now with the way dark wallet implements this if you ask two different parties to pay you with the same address and only one of them does, you cannot tell which one paid you.
499  Bitcoin / Development & Technical Discussion / Re: BIP39 HMAC-SHA512 rationale ? on: August 04, 2014, 04:57:50 PM
Still I don't see much utility in this as 2,048 is an insufficient number of iterations to provide more than the cryptographic equivalent of a speed bump.  A single GPU cracker can perform 80M+ HMAC-SHA512 operations per second.  To put it into context iTunes uses 10,000 rounds of PBKDF2 and that is to protect a mp3 account.  Lastpass (password manager) defaults to 100,000 rounds of PBKDF2 and it can be increased by the user.  Key stretching should be as long as possible (but not so long as to disrupt the user).  Since creating or restoring a seed is infrequent the iterations should be as high as possible that it will still complete in a few seconds (or at a minimum a significant fraction of a second).
I provided feedback along these lines too:

What ended up getting proposed there is effectively a fairly insecure brainwallet scheme. I'd personally not recommend people deploy it.
500  Bitcoin / Project Development / Re: [Tracker] Stealth Address Support on: August 04, 2014, 04:47:06 PM
Petertodd claimed to be working on a BIP and reserved a number but hasn't proposed any text.

New address types should not see widespread use without extensive review for cryptographic and privacy weaknesses and functionality footguns. This really needs a clear specification.
Pages: « 1 2 3 4 5 6 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 ... 192 »
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!