Bitcoin Forum
February 08, 2016, 02:25:47 PM *
News: Latest stable version of Bitcoin Core: 0.11.2 [Torrent]
  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 ... 216 »
481  Bitcoin / Development & Technical Discussion / Re: Is someone monitoring large parts of the network? (evidence+firwall rules) on: March 07, 2015, 12:41:55 AM
What I noticed is, that the seed nodes (from time to time) return dozens of bitcoin addresses from the same subnet (from france).
Can you clarify what you mean by "the seed nodes". Do you mean DNS seeds?  Returning how? Need more details!

Edit: Okay, I see is returning a single 46.105/16 to me. Is this what you're referring to?
482  Bitcoin / Development & Technical Discussion / Re: Slowing down block propagation on: March 05, 2015, 05:27:31 PM
e.g. 1MB block 0% haircut, 10MB block 10% haircut, 1000MB block 95% haircut.  Some polynomial could determine the formulae.
Diminishing fees doesn't work in the long run, as fees can be paid out of band. An alternative that has been proposed is adjusting the difficulty, though this only allows small adjustments.
483  Bitcoin / Development & Technical Discussion / Re: Definition of the priority buckets on: March 04, 2015, 07:28:47 AM
Thats goofy, I missed that. Don't worry: I'm going to go remove that right now.
484  Bitcoin / Development & Technical Discussion / Re: Counting the number of tx in a block without downloading the whole block? on: March 04, 2015, 06:19:46 AM
Is it possible to count the number of tx in a block without downloading the whole block? (e.g. only using the Merkle tree)
No, you can get an upper bound on the size by the depth of the tree if you get the coinbase (or any other) txn,  and a lower bound if you get given a transaction late in the block. You can get an exact measure by taking the rightmost branch and observing the duplicated hashes, but nothing more compact than that.
485  Bitcoin / Development & Technical Discussion / Re: Definition of the priority buckets on: March 04, 2015, 05:39:29 AM
There is no such thing as categories of priority. Priority is either high enough to not be treated as zero, or it's not. And everything is linear in priority after that.

(You're referring to BC.i's behavior, I think.... which has little to no connection to reality.)
486  Bitcoin / Development & Technical Discussion / MOVED: Bitcoin Core 0.10.0 starts very slow. on: March 04, 2015, 05:37:49 AM
This topic has been moved to Technical Support.
487  Bitcoin / Technical Support / Re: Bitcoin Core 0.10.0 starts very slow. on: March 04, 2015, 04:44:50 AM
How long does it usually take for the wallet to open if opened the first time of the day?
Depends on the hardware. On a fast desktop with a SSD, a 60+MB wallet full startup with default settings is under 20 seconds.
488  Bitcoin / Development & Technical Discussion / MOVED: bitcoind 0.10 freeze ubuntu 14.10 on: March 04, 2015, 04:43:41 AM
This topic has been moved to Technical Support.
489  Bitcoin / Development & Technical Discussion / MOVED: Security Alert on: March 03, 2015, 11:30:36 PM
This topic has been moved to Service Discussion.
490  Bitcoin / Development & Technical Discussion / Re: 0 confirmation confidence (of block inclusion) on: March 03, 2015, 12:27:56 PM
Consider me to be uninitiated - is this relevant only if I'm a miner, or if I'm running any full node?
Pfft. If you were a miner 99% chance you've never seen a full node in your life. Any full node can call that rpc, and only full nodes can call that rpc.
491  Bitcoin / Development & Technical Discussion / Re: 0 confirmation confidence (of block inclusion) on: March 03, 2015, 09:53:36 AM
Is there anything in bitcoind RPC (or even an external service, etc) which would let me get an idea about how many miners have a particular transaction in their mempool? Or even some other metric of 0 confirmation transaction confidence?
You can call getblocktemplate to see if your own node is attempting to mine it in the current block.
492  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).
493  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).
494  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.

495  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.

496  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.
497  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.
498  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.
499  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.
500  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.
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 ... 216 »
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!