Hardly. What matters is the protocol fingerprint, not the amount of bandwidth used.
The timing and size of bitcoin packets are unique to bitcoin. It is obvious even over encrypted links such as Tor.[/qupte]
Timing and size can be obfuscated. Nodes randomly delaying and aggregating tx a few seconds won't have a material effect on the network but it will alter any hueristics that don't involve deep packet inspection. Transactions can aggregated, padded, and encrypted. Port can be dynamic between peers even dynamic between each of the peers of each node. Absolutely. But none of that is being done right now, so the answer to $SUBJECT is "yes" |
|
|
|
It makes the protocol more complicated but it is possible to design p2p systems which use random ports and encrypt the payload.
Bittorrent does this and it has been futile to curb (Bittorrent now account for about 50% of internet bandwidth).
peer detection becomes more difficult and anytime you add overhead like that troubleshooting everything else becomes more complicated. Still if push comes to shove it wouldn't be impossible to make Bitcoin traffic undetectable.
Yeah, and we're passing little tiny notes compared to bit torrent's flood of high quality porn. It will be easy to avoid censorship. Hardly. What matters is the protocol fingerprint, not the amount of bandwidth used. The timing and size of bitcoin packets are unique to bitcoin. It is obvious even over encrypted links such as Tor. Or, to put it another way: your cable modem or DSL router's blinky lights go blink-blink each time a bitcoin transaction or block is broadcast throughout the network. |
|
|
|
|
Our DNS seeds are now returning AAAA records.
|
|
|
|
|
It is shocking, shocking that an outsized return from an investment with zero transparency is related to major illegal operations. Who would have thought?
|
|
|
|
Okay, stats are updated! And nguoinhaque was right, I wasn't counting two bets. The actual percentage of blockchain volume is about 45% satoshidice!
Good stuff, thanks for messing around with this. |
|
|
|
Some of this is putting the cart before the horse  You cannot know what is the best allocator until you have an idea of the lifetime and usage pattern of the allocated objects... |
|
|
|
A hot wallet cannot be encrypted while the system is running, by definition.
Well, it can (and should) be encrypted on-disk. At least that makes it more difficult to steal private keys (must steal from memory). |
|
|
|
Who needs a hot wallet to begin with?
The point I am trying to make is, is it really that bad (from a customer service perspective) if withdrawals aren't immediate? Why do the withdrawals have to come from the platform in the first place? Ideally, the platform should not have any private keys on it whatsoever.
Quite true... In the Real Banking World, my withdrawals from a well known brokerage to a well known US bank can take 24-48 hours, or longer on weekends. It only seems logical that dealing with large amounts of withdrawals would lead one to introduce delays for the purposes of security. If you are withdrawing $10,000, it surely seems beneficial to all customers if your withdrawal is delayed a bit to enable additional fraud validations. The bigger the withdrawal, the larger the validation. It costs the same for the network to transmit 10 bitcoins as 100,000 bitcoins... but that does not mean that large values should have the same lax security as small values. Sometimes I think programmers (like myself!) have a mental weakness: programmers want to treat all customers, all transactions, all $Whatever equally. Simple rules make coding easier to validate, debug, and run But when you're dealing with money, the simple obvious truth of "more money means more fraud, makes you a bigger target" means a lot of special-case coding and additional business [non-coding] procedures. |
|
|
|
satoshidice.com ?
It now requires a couple of confirmations. ZipConf would be the most interesting to try this on, as they claim to have developed a system to reduce the double spends significantly for 0 conf transactions. If I understand correctly, ZipConf is essentially a private network, that guarantees only specific sites where they have a backchannel method of verifying transactions besides the P2P network itself. |
|
|
|
Good luck-- I share your view that coming up with better ways of playing zero-sum games is not the way to make the world a better place.
The fact that this statement is coming from the 'lead developer' of Bitcoin does NOT make me feel good about the future of the Bitcoin project. Shows a complete ignorance of markets and economics. Epic epic epic fail.  The fact that Zhou thinks that such markets are a 'zero sum game' as well means that it is a good thing he is getting out. He doesn't even understand what he created. Sad. Personally I think the bitcoin economy would be useless if the only thing going on is currency exchange. A healthy bitcoin economy includes vendors and customers, everyday commerce. |
|
|
|
Even though swapping the crypto layer at runtime is unlikely, function pointers are the more flexible alternative as they allow the developer to choose his crypto layer without having to recompile the bitcoin library.
For any platform where the above would be useful, the following is sufficient: 1) declare the appropriate entry points as "extern"; 2) use the platform's native dynamic linking apparatus. Using additional layer of indirection is completely pointless and has the following disadvantages: 1) it defeats many optimizations that the tool-chain could apply. 2) it defeats many automatic static-analysis and debugging tools. 3) slows down the resulting code (especially if the CPU doesn't have a branch predictor) and increases the energy consumption during execution (more CPU instructions and more cache misses). All true. Nevertheless, a wide swath of very fundamental libs provide hooks for similarly fundamental services, most notably memory allocation and m-t locking primitives. ...regardless, all this is really discussing useless details. The main focus, I hope, should be that cbitcoin is actually doing something unique to bitcoin like parsing blocks and talking network, and not simply wasting a lot of time reimplementing basic software services like crypto or hash or data codec. |
|
|
|
I haven't been a great fan of Bitcoinica in the past. The service introduced, at times, great volatility into bitcoin's price and I felt bitcoin itself was too immature to sustain a leveraged short selling system.
Not true at all. Bitcoin's (so far) highest volatility period, making all others seem insignificant, came and went before Bitcoinica existed. During bitcoinica's lifetime, bitcoin volatility has been lower than during the previous Big Bitcoin Bubble period. |
|
|
|
You can do it with software. It is merely a chain of TX's. One wonders how quickly wallet theft would disappear, if the other major exchanges started rejecting well known, stolen coins. |
|
|
|
sipa just pushed out IPv6 support to bitcoin/bitcoin.git. If you have IPv6 support on your network, please help test. (note - this requires being able to compile the source code yourself) |
|
|
|
Oh, yes, I should clarify. VeriFones use a persistent battery-backed RAM-based file system, so disk space essentially equals RAM. I am referring to the size of the library, not how much memory it allocates. And some of the other devices I've developed for have very limited flash storage where fitting the entire compiled openssl lib takes up significant space.
Then link statically. Or use one of the many embedded tools out there that ensures your lib has only the code your filesystem actually uses. This is a solved problem, and does not exclude OpenSSL use in any way. Also for the VeriFones they don't use GCC so sometimes things take refactoring for their dinosaur compiler to be able to handle it (and makefiles in particular). Of course I understand having outdated tools is sucky, but that's also why you can find these things on eBay for so cheap. The Omni 3200 model has an even older DOS-based compiler, but someone who bites the bullet and makes a working app for it suddenly breathes new life into a $30-on-eBay all-in-one-computer with a printer to boot.
And OpenSSL likely supports outdated OS's and tools... they maintain support for MS-DOS to this day because that remains a common embedded target. |
|
|
|
It is rarely a good idea to reinvent the wheel, when it comes to security-sensitive, time-tested, well-reviewed-by-experts cryptography code. This. Also why is avoiding dependency on OpenSSL important? Something I am missing? If you ripped the code from OpenSSL it would work fine. The devices just don't have gobs of memory for libraries and they have their own compiler that has idiosyncrasies that make it not compile everything that can be compiled in Linux. Cause it is not Linux. This would be a 32 bit CPU, no need for 8 bits. Ummm... OpenSSL is heavily used in the resource-constrained, embedded space, and runs on Windows, Linux, uclinux (embedded linux), VxWorks (an embedded OS), OSX, Solaris, HPUX, OSF1/Tru64, IBM mainframes, ancient MS-DOS systems, netware, and others old and new. It works very well on almost every known 32- and 64-bit platform in existence. It does not require "gobs of memory"; the state structures for AES or SHA algorithms are almost always smaller than 1,024 bytes. Compiled code size is already small and compact. Copying OpenSSL code into your own codebase will not save any memory, regardless of linking style. Libraries are internally split into modules and demand-paged in. At best it will save disk space for unused code, at a cost of always lagging behind whenever security problems in the code are found. |
|
|
|
Why? Just use OpenSSL for bignum and move on. People have already written that part.
Bitcoin-specific data structures for storing blocks, transactions, etc. are the fundamental building blocks.
If he manages to pull this off without a dependency on OpenSSL, his code is going to be able to run on my credit card machines. It is rarely a good idea to reinvent the wheel, when it comes to security-sensitive, time-tested, well-reviewed-by-experts cryptography code. Once bignum has been reinvented, what about ECDSA and similar gadgetry? |
|
|
|
Why? Just use OpenSSL for bignum and move on. People have already written that part. Bitcoin-specific data structures for storing blocks, transactions, etc. are the fundamental building blocks. |
|
|
|
|
Show Posts
