Bitcoin Forum
March 01, 2015, 04:40:42 PM *
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 ... 192 »
1  Bitcoin / Development & Technical Discussion / Re: Interesting github forks? on: February 28, 2015, 04:09:06 PM
If Satoshi had agreed with that point of view, it seems unlikely he would have released Bitcoin under the MIT License. 'Course it's hard to disagree with your sentiment regarding the quality of most altcoins....
Any other choice would be giving the copyright holders of the software an elevated level of authority over the system, which would defeat the point-- even if it would be arguably desirable. Besides, it isn't like anonymous parties have tremendous recourse available via civil complaints; plus 99% of altcoins don't care: The MIT license required basically nothing but preserving copyright notices and most altcoins actually violate the license (because they search and replace out all the attribution).
2  Bitcoin / Development & Technical Discussion / Re: Interesting github forks? on: February 28, 2015, 10:05:14 AM
Many contributors have own coins.
I believe that is incorrect. The only non-trivial contributions that I can think of there is jtimon (freicoin).
3  Bitcoin / Development & Technical Discussion / Re: Pruning OP_RETURNs with illegal content on: February 28, 2015, 02:18:20 AM
Honestly I think new non-P2SH outputs should be made invalid at some point in the future not because of illegal activity but because if used for arbitrary data it bloats not just the blockchain but the far more critical UTXO set.
On the other hand, if those pubkeys are actually pubkeys and not arbitrary data, you can do Diffie-Hellman with them.
That's a useful property.
It's true but that data can be provided in a way thats optional-- aux data that may or may not come along with the blocks-- or even completely externally.  It's not like you can expect to grab other people's random pubkeys and do things with them and have anything but doom come of it. ("What do you mean you didn't know, I sent you a message!" "No you didn't." "Yes I did, it was right here." "Thats not my house, thats the neighbors flower bed." "Yea, so? it was accessible to you! plus it was encrypted with your key!" "and thats not my key!" "Sure it is, I took this random key you used in 1997 and added four to it, you could have decoded that"...)

* I think the problem is more universally described as can a blockchain be constructed such that non-transaction data is limited only to outputs that can be pruned without affecting blockchain validation.  I believe the answer is no.  It can be made harder to accomplish but it can't be made impossible.
The answer is yes. In two ways:  The easier but less useful way is to point out that Zero Knowledge proofs for general computation are known to be possible (and are verging on practical for non-trivial problems now).  In theory I could give you a blockchain tip, a utxo set for it, and it's total work behind it, along with a ZK proof that the chain was completely valid, and that the utxo set agrees. This meets your criteria.

The other way depends exactly on what you mean by "blockchain validation". Basically, do you ever consider signatures prunable? e.g. when they're burried deep in the chain.  We do know how to make txout scriptPubKeys "provable a hash". If signatures are pruned and all txouts are hashes then there are basically no non-trivial sidechannels left.

4  Bitcoin / Development & Technical Discussion / Re: Is bitcoin v0.10's new libsecp256k1 safe & without mathematical backdoors? on: February 27, 2015, 11:11:22 AM
It really is upsetting how many THINGS bitcoin building depends on.
Take a breath. Okay. Now, lets walk through this.

How many things a version change in some code not controlled by it can screw up or introduce vulnerabilities in.
Fairly few, in fact-- if you use the gitian build system there is no uncontrolled upgrade of any dependency in the system. You will build a bit identical binary to all other users, and all updates to dependence can be audited and tested before being deployed.

I know all the cool kids are using boost, but did a crypto project really need the vulnerability to version rot?
Boost has only ever been used in a fairly limited capacity in bitcoin, mostly importing C++ features from the future, some of which are very useful to writing safe reviewable code. (the one big exception to that is the use of boost-asio). C++11 and better have incorporated many of the features, and Bitcoin Core has been phasing out most boost usage; though a preference to retaining compatibility with older operating systems is delaying the move completely. That said, we've had fairly few issues with boost version incompatibility (presumably because so little of it is used).

I know all the cool kids are using OpenSSL but did we really have to wait until a version upgrade broke our consensus before we implemented a consensus library to get past it?
Work on libsecp256k1 began something like a year ago, along with work to isolate  the consensus behavior from openssl (as part of BIP62).  In spite of your considerable knowledge of cryptography and systems programming you have not made, as far as I can tell, a single contribution to these efforts. The fact of the matter is that only a few users care, even most of the people who regularly contribute to Bitcoin Core have not contributed to these efforts. And the work must be done very carefully. The update broke consensus was detected within hours of the openssl release through code review (not user reports), and did not effect binaries or other binaries built with the gitian build system, because it captures and fixes the environments.  Which certainly made it easier to move forward with a subset of BIP62, since it validated the things that those of us who care about these things have been saying for some time and got more people willing to step up and do some review.

I know all the cool kids are using autodeps, automake, autoconf, etc, but those still change often enough to distrust them for a crypto project.
Your complaint there seems surprising. When a distribution tarfile is created all the autofoo stuff is fixed as shell scripts and doesn't even need to be installed on the host.  The pre-autotools enviroment for Bitcoin was a catastrophe. Keep in mind that Bitcoin is not some UIless library, it's a fairly complex end user application with graphical support and several optional components.  Though even without that, the autofoo stuff makes cross compilation work well-- which is important for being able to do things like the gitian build system providing binaries for three platforms from a single host.

(And pretty much no build system is going to save you from something getting screwed up here or there and needing to "make clean" to put everything right)

And then there's C++.  A language in which arbitrary and unexpected behavior can be lurking behind every overloaded operator, implicitly called constructor/destructor on procedure entry/exit, etc.
Yes, C++'s opacity is annoying, but what can you say?  Bitcoin Core never had a single remote code execution bug, in a complex codebase with a lot of moving parts. Had it all been written in C it is much less likely to have been as correct as it was, it would have been harder to understand at a high level (even if the fine details were more clear); and I say this as someone who profoundly dislikes C++.  C++'s mostly only awful when code is inflicted on you by others, it offers many sins, but they're answerable by "well, don't do that."

And the STL, which leaks copies of information in deallocated memory all over the place if you're not extremely careful.  Still, you've got explicit memory management so you CAN avoid leaking copies of information in deallocated memory if you are very careful, and that's more than I can say for most "modern" or "more convenient" languages.
Careful here, your "plain C" also spews data all over the place. Go look at your stack. The compiler optimizes out most efforts to clean it up, and randomly spills things into place you never though they'd be. You can achieve the same control over leaking data in C++ as exists in C (as in: not perfect), all the STL objects can use custom allocators that zeroize. This is used in Bitcoin Core.

And the STUPID depending for a binary format on a database that changes its binary format with EVERY new release, which has forced us to maintain our own archived copy of an obsolete database that has had security bugs fixed SINCE we did!  The only reason our wallets aren't vulnerable is because we used them to store encrypted data in the first place.
Yes, BDB is lame. Though its only new major releases which break the format. Old releases have still received fixes (especially important since the latest releases have changed software licenses).  It's not a security concern not because of encrypted data but because it's a local database for the wallet, it's not exposed to the outside world. Several abortive attempts have been made to replace it, it's a big project. (not in terms of lines of code, but in terms of cost of mistakes.)

As an old cryptogeek this is a nerve-wracking codebase.  Don't get me wrong, the code is good - but doing all this, and trying to stay secure given the limitations and version changes of all these tools, is like dancing on a tightrope over a fire.  I vastly prefer C, where every operation is visible and every operator does exactly one thing.  In C it's easy to know when things AREN'T happening.
I generally prefer C too. But I would have a hard time arguing for it for the vast majority of Bitcoin Core's code. The automatic safety possible in modern C++ has served it very well.  There are some parts, like the nitty gritty cryptographic consensus parts which already need to be so simplified, so analyzed, so straightforward in their operation, and are so important to expose to strong analysis tools (that don't generally work on C++ owing to its awful undecidable grammar) that the balance likely tilts back the other way, but we'll see how that plays out as those parts are factored out of the main codebase.

5  Bitcoin / Development & Technical Discussion / MOVED: Google Cloud Blockchain Datastore on: February 27, 2015, 10:42:39 AM
This topic has been moved to Project Development.
6  Bitcoin / Development & Technical Discussion / Re: Pruning OP_RETURNs with illegal content on: February 25, 2015, 11:09:33 PM
It may be absurd that there is reason to be concerned about such things, but there is reason to be concerned none the less.  Sometimes the world is absurd.
7  Bitcoin / Development & Technical Discussion / MOVED: What if all possible bitcoin wallets are owned? on: February 25, 2015, 11:07:34 PM
This topic has been moved to Beginners & Help.
8  Other / Beginners & Help / Re: What if all possible bitcoin wallets are owned? on: February 25, 2015, 11:07:00 PM
It is my understanding that bitcoin wallets are created through a hash table with 64 bits of alphanumeric characters.
Your understanding is incorrect. There is no hashtable involved anywhere, and Bitcoin addresses have 160 bits of data.
9  Bitcoin / Development & Technical Discussion / Re: An easy way to remember a bitcoin address on: February 25, 2015, 01:41:43 AM
FirstBits didn't require centralized trust.
In practice it did, because it required an unprunable copy of the whole blockchain to do anything with it. So everyone used it with various services and eventually the services returned inconsistent results (due to differently mishandling reorgs).

There are lots of things that can be done which are merely decentralization theater, sometimes because the design obfuscates the hidden decentralization, in other times because they're  not practical without it.  I'd say that was true for firstbits in practice, its true for the scheme here too though I believe it could be improved to be SPV-ish; but that still leaves the other downsides.
10  Bitcoin / Development & Technical Discussion / Re: bitcoind JSON RPC performance declining over the blockchain? on: February 24, 2015, 10:53:42 PM
it blocks all RPC calls, including ones that wouldn't have to be blocked (such as getdiff or get new address)
The random RPC blocking you're describing sounds somewhat like what happens when you have a RPC client that leaks keepalives. With the default settings Bitcoin core has only 4 threads for handling rpc queries (as additional threads consume a fair amount of memory and people would like to run this stuff on 500 mb VPSes) and once it has that many keepalive connections open further ones will block. Many RPC client libraries leak connections, leaving open old keepalives for a long time with no intent to use them again. If this is your issue, you can forstall it (at some memory cost) by increasing the rpc thread count, or avoid it by disabling keepalive (-rpckeepalive=0)... (or better, fix your client to not leak keepalives).

If that isn't your issue, you could try actually reporting your problem (especially with a reproduction), since no one has done so.  In particular, I keep a testing wallet running with tens of thousands of addresses and many thousands of transactions haven't observed what you're describing; so I cannot tell if your comment on block updating is a red herring or not (accepting a new block really must block most RPCs, but should also only take a second).  Not sure why people are going on about software being "unsuitable" when they can't even be bothered to report issues they've had. It certainly isn't going to magically adapt to your use-case if you snark in threads burred on forums instead of reporting issues (much less contributing to improvements).

With respect the thread here, I benchmarked a node here processing over 5500 tx/s in aggregate during IBD, including the signature validation and all.  Considering that the network as a whole is limited to <10, I think this is pretty good. If there is an actual performance issue you'll need to setup a reproduction in isolation from your application in order to figure out where it is. Just saying it's slow for you is very much not helpful; we need to know what RPCs, called in what pattern, are taking what amount of time-- and ideally have just some script to reproduce it, otherwise there is just an endless loop of "seems fast to me".
11  Bitcoin / Development & Technical Discussion / MOVED: JSONRPC - not working with Bitcoin - others are 100% working on: February 24, 2015, 06:00:11 AM
This topic has been moved to Technical Support.
12  Bitcoin / Technical Support / Re: JSONRPC - not working with Bitcoin - others are 100% working on: February 24, 2015, 05:59:33 AM
YES I have set correct because other coins are working from external source.
You probably don't. Read your debug.log.
13  Bitcoin / Bitcoin Discussion / Re: Bitcoin is an Electronic Bearer Bond and the US government will not like it! on: February 24, 2015, 03:39:11 AM
2011 called, looking for its concern troll-posts back.

Back in 2011 this kind of thing was a reasonable concern. It's much less so today.
14  Bitcoin / Development & Technical Discussion / Re: An easy way to remember a bitcoin address on: February 24, 2015, 01:05:00 AM
The exception is stealth addresses which I have great hope once we resolve the OP_RETURN problem.
There is a whole host of separate problems there, including needing to witness the whole blockchain to scan for payments (it breaks SPV and/or makes you again depend on a central server)

The usecase you're describing is addressed by the payment protocol.  You give people a payment uri.

For human recognition, encoding an address on an identicon is more appropriate. In fact, I'm also looking out how I can make an identicon safe from lookalike attacks.
You cannot generally. Look alikes can be ground. There is a nice example of this for openssl picture fingprints that I'm having trouble finding.

Also, BIP39 lists are created by making it hard to confuse between two words. What is important in this case is not the string metric, but the "sound" metric of the words. Assuming words were wisely selected in bip39 dictionaries, we should be relatively safe.
There are plenty of lookalke/soundalike/mean-alike words in it e.g. [choice, choose], [drip, script, trip], [risk, brisk], [load, road] (just picked single words at random and found the first obvious matches; what-- no one ever confuses "r" and "l" sounds?).

If I can find another feature for identifying the address, a partial merkel tree would be enough for solving your issue about the need of having the whole blockchain.
That would, in fact, be an improvement over firstbits.

I don't want any registration needed, so I won't do that.
The process you described fundamentally requires registration. Before I can give you a short address I must have registered one in the blockchain.
15  Bitcoin / Development & Technical Discussion / MOVED: - where are the private keys? on: February 24, 2015, 12:12:33 AM
This topic has been moved to Service Discussion.
16  Bitcoin / Development & Technical Discussion / Re: An easy way to remember a bitcoin address on: February 23, 2015, 11:40:37 PM
Basically this idea existed more or less before in the form of the ill fated 'firstbits'; I consider this proposal to be ill-advised for the same reasons.

Addresses should generally not be reused. Reusing addresses harms the your security and privacy as well as the privacy of all Bitcoin users. Extensive address reuse contributes to systemic risks which endangers the system (what happens when RPG wielding ninjas show up at mining farms with demands to not mine transactions belonging to their enemies?  If regular transactions are conducted so that they are indistinguishable to their author's enemies we never need to find out). While the community may not go so far as to prohibit reuse, building infrastructure that rewards it is not a good plan.

These short addresses are immediately subject to lookalike attacks-- a popular address is "wolf larceny tape butter" ... great, I go and create "golf larceny tape butter", "wolf larceny ape butter", "wolf larceny tape butler" and so on... I spam these clones out in various places or just trust human error to guide things along, and now I'm receiving funds from other people. We don't even need an attacker here, all outputs are constantly being assigned addresses, the space of working addresses dense-- instead of the very intentionally sparse case which we have with addresses today where its nearly impossible to send to an incorrectly entered address.

As you note, the security here is totally undermined by a reorg. So beyond chance reorgs breaking things for people and causing their funds to go off to be lost in space, now there is a great incentive to reorg that didn't exist before. (there also is some fun nuisance perversion like miners selling high value vanity positions in blocks with this particular scheme; spamming up the chain to make sure to register the really goods one, sometimes requiring large indexes.).

One could not resolve these addresses without a copy of the entire blockchain or at least a forever growing unprunable database (as with firstbits) which would need to be accessable to each and every wallet. In practice most people would depend on centralized services to resolve these (as  they did with firstbits), and in practice the services will eventually return wrong results, even without intentional fraud (as with firstbits).  Of course, any of these services would be prime targets for compromise; a well timed replacement could redirect huge flows of funds.

This also requires a separate registration step, which reduces the scalability of the system due to additional overhead, and makes the system less instant gratification. You end up with something where you have to pay fees to establish an 'identity' just to receive funds to pay the fees with. Necessitating multiple use modes.

Less critically the use of a particular fixed wordlist is culture/language laden and has seemed to be somewhat problematic for BIP39; though I mention this only in passing.
17  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.10.0 has been released on: February 23, 2015, 10:04:38 AM
You sure this issue related ONLY to 32 bit systems? I mean it already know bug witch was tested and the cause of it clearly tracked to 32bit address limitations? I sow it one time even with ~2000 Mb free RAM... (4 Gb physical RAM, win 32bit, 3.5 Gb available due 32bit limitations, ~2 Gb free)
Yes, and I explained why (the fact that 32 bit systems needs a lower limit was also well known in advance; Bitcoin imposes a hard cap of 1024 on 32bit systems... but it sounds like from your report that this is not low enough). Large cache settings (e.g. 4096MB) are extensively tested on 64 -bit hosts.

In theory initial block download one time event, but in practice (i use btc about 2 years now) i already do this 3 times:
- my very first initial block download
- redownload after strange client crush (it was one of 0.8.x versions - not sure about exact reason, it not repeated and i upgrade ver soon) because of database corruptions
- redownload (actuality was DB reindex + some redownload) after big power flux in my city (result in sudden hard reboot) while client sync blocks from last few days - resulting in another blockchain corruption
Getting corrupted is a separate issue, that shouldn't happen. Any issues causing that should be fixed. FWIW, if you end up corrupted a reindex will work which tends to be faster and less IO intensive because it leaves the blocks in place (doesn't have to write the blocks again)... not a reason to not fix the corruption on unclean shutdown, but perhaps it's a helpful bit of advice for you.

Well seems if you got over 1k transactions in a mixture of wallets seems to crash client
Can you try restating this? What does "in a mixture of wallets" mean?  I've personally tested Bitcoin core with wallets with tens of thousands of transactions without issue, but I'm not sure precisely what you're doing, or what you mean by crash.
18  Bitcoin / Development & Technical Discussion / Re: Size of raw transaction? on: February 23, 2015, 06:32:39 AM
Doof, impressive that you managed a response even less useful than mine.
19  Bitcoin / Development & Technical Discussion / MOVED: official pay-demo on: February 22, 2015, 10:48:44 PM
This topic has been moved to Service Discussion.
20  Bitcoin / Development & Technical Discussion / Re: Size of raw transaction? on: February 21, 2015, 11:24:49 PM
For my project it's *imperative to use specific outputs when sending coins.
Well, you've given no information there. I'm afraid you may be mistaking the human participants on the forum for a search engine or mechanical turk. We don't generally answer questions in a vacuum.

* You may whine, bitch, complain, argue, stomp, stamp and even tantrum that this is some how wrong/bad/undesirable/ect...  Though it won't change project design goals and the problem would still remain.
You can insult people on the forum and provide inadequate information but that isn't likely to get your questions answers. Congrats on the self-defeat there.

You can set all the design goals you want, but no matter how many insults you hurl that isn't going to change the design of the Bitcoin system and so if it happens that what you're trying to accomplish turns out to be at odds with it, it's not going to work well, or will result in funds loss, etc.  It sounds like your understanding is currently pretty limited (e.g. not knowing how the size of a transaction works), you might want to attempt to understand the system a bit better before setting immutable design constraints and defending them with insults.  Just a thought.
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 ... 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!