sorry, what do you mean by "blockchain parser"? of course it doesn't need any external dependencies, since it doesn't even seem to bother about needing sha256 at any place. but myself, I cannot imagine a bitcoin blockchain parser that would not need to use sha256
|
|
|
What stops those blocks from needing to be kept around indefinitely? Nothing. Once you store a block on disk, it will stay there forever - that's the most common implementation. But you should note that mining blocks consts money, so people won't do this just to eat up your disk space - they prefer to mine a new block to earn 25BTC. They can though try to create branches forking at low block numbers (where the difficulty is low), but most clients won't accept such an old blocks, so they won't store them in disk neither.
|
|
|
Hi, I made a raw transaction that bitcoin-qt validated (returned the hash with sendrawtransaction) and (I think) broadcasted The problem is that the miners don't include it
That transaction is quite standard and has 0.03 BTC for fee so I don't get why... Is it possible that bitcoin-qt validates a tx that miners don't accept? I think not because miners use bitcoind too, so the same rules should apply
Irrelevant note: it's on testnet
if it did not end up in the node's wallet, it wont be re-broadcasted. the most possible explanation is that you did not have enough connections at that moment, so your tx did not reach any miner. restart your client, wait for it to connect to a few nodes and then redo the sendrawtransaction - eventually it should get mined. if not, you can post it in here, and we can have a look.
|
|
|
Yeah, gmaxwell's comments yesterday were extremely helpful. But it's not the first time I saw him talking bullshit, so I'm used to this. @jdillon, you want to use self-moderated threads so nobody could tell you again that your idea is stupid? way to go, man - that's how smart people solve problems
|
|
|
Ah, that's who you are. Yeah /ignore
That's exactly what I am talking about. A guy who fixed a bug in the official bitcoin client, by adding one line of code: a hero who saved the network from an extremely dangerous DoS attack. A guy who dared to suggest that we should extend the net protocol to be able to prevent similar attacks in a future: a troll /ignore You guys are just pathetic.
|
|
|
The guy who last week saved the Bitcoin network from an extremely serious DoS attack that could have easily taken down a large fraction of the network goes to the trouble of writing an intelligent and detailed response and you obviously don't even read it? Then you go off on conspiracy crap? Troll. What? He saved the network? That's the best joke I've heard for days.. First of all, the DoS attack was not on the network, but on a buggy official client, which I don't even use myself, so I couldn't care less. Moreover, yesterday on IRC I even proposed a simple improvement that would solve this kind of problems once and for all (fetching data length, along with the hash), but nobody did care about it, including the guy, who among others was extremely impolite to me, so I have just adopted myself to his standards. Now you get it?
|
|
|
Unfortunately you are quite wrong there. Pools can easily peer with each other with dedicated connections on fast servers to ensure that blocks propagate quickly to other pools and we can expect more of this in the future So what? Rich people, or exchange owners, can also easily "peer with each other". That's not an argument - I'm all for people peering witch each other. But I'm still waiting for the answer to my question: what is your business in promoting bitcoin banks to rule the protocol?
|
|
|
One more comment, on lifting the max block size, which I myself was bitching about. Today I am tending to say that I was wrong - it won't matter. I see it now that most miming pools keep the limit at 250KB and even if you remove the hardcoded 1MB from the client, they will still keep their soft limits at whatever level they want - and it will be rather lower than higher. Anyone who decides to mine bigger blocks is betting against himself, because bigger blocks need more time to propagate over the net, thus naturally having a bigger chance to get orphaned. Measure a difference between propagating 250KB vs 25MB block and you will not think twice of which one your mining pool prefers.
This is a brilliantly designed "ecosystem" that is regulating itself - therefore, seeing it at work, I am against any additional regulations.
|
|
|
Bitcoin is hopeless if majority of miners are evil. I don't think this will happen. I am just responding to jdillon's accusation: Sorry, I wasn't talking to you. It was more of a general comment, because I see it all the time (in other threads, but also outside the forum) that people are complaining about, or just using a term: "evil miners". There is no such thing! IMHO, miners are the least who would want this currency to not succeed. And people trying to overthrow the designed "bitcoin government", because they believe they found a more fair solution for the democracy, or whatever - it's just silly, not to use again the wold "stupid". They either don't understand what they are talking about (meaning: they don't know shit about how bitcoin works) - or they are expecting a miracle... I don't see a third option. Miners are the government of this currency: like it or not, it is the fact and you cannot do anything about it. If they decide to increase or decrease a block size, or whatever else, they can just do it and no developer, nor any other self proclaimed genius, will be able to stop them - face it! If bitcoin users didn't follow any miners' decision - as I said: that would be their suicide. Moreover "evil" is a religious term, so please if you are people of science, stop using it and start thinking in terms of what is technically possible, instead of what you think you should do in order to go to heaven.
|
|
|
I'm honestly tired reading all these silly accusations about how miners are evil and how we should resist against them. It's just so stupid that I cannot even quantify the level of its stupidity.
First of all, miners are not evil - they are the power of the network by design and they should do their job, part of which being: decision making about the protocol. And second, even if you wanted to, you cannot resist their power, because they are the power of the network by design.
You don't like the miners' ruling the bitcoin - invent your own virtual currency, one that has it designed otherwise. In the virtual currency invented by Satoshi in 2009, miners are supposed to rule and so they do rule - you can't change it, it's impossible. And if you don't like this idea, then obviously you have not yet found a digital currency that is suitable enough for you.
Myself, I am going to stick to the miners' ruled currency, because I do find this idea as a proper way to go.
|
|
|
The government doesn't need a backdoor. They can walk in the front door, ie, the open transaction ledger.
the thing is that walking in the front door each time they'd like to check is just to expensive. plus some people have guns
|
|
|
I'm just saying. feel free to get adventage of whatever tools you find useful to find it, but trust me, if I had an actual incentive and a proper access, I bet I can beat them all, starting from the most expensive ones. it's just a matter of time people indeed is a harder part, though as I said, ppl ale subjective to different illusions that you can use in a source code. especially those ppl who don't care, because they have such a great tools
|
|
|
call me a guy with a tinfoil hat again, but as a guy who spent a big part of his life coding C, I dare to say that it is fairly easy to sneak into such a big source code a backdoor, i.e. in a form of some exploitable stack overflow.
if the attacker is smart, it is as simple as changing one innocent character, at some place in the code he's made, to hide the actual purpose though still suggesting just a mistake. like putting "," instead of ".", "O" instead "0" or "l" where you needed "1"... I've wrote so much code in C that I could think of tons of expressions that would actually work completely different than one thinks they do at the first sight.
this is especially dangerous when they have just included a few tens of pull requests, so no sane person is really going to go carefully through all of them.
corrupting binaries would be the most stupid way to go, since this one can be actually found quite easily, thanks to bitcoin's fine gitian building solution.
|
|
|
I managed to get it to compile in Visual Studio. 32bit right now because 64bit OpenSSL seems to be giving me some linker trouble (_ prefix on the BN_* functions). Haven't had the time to look at that yet.
We can only appeal to spia to make a version without openssl/gmp dependencies, which would be just perfect.
|
|
|
A faster and smaller alternative to OpenSSL would be nice, but does sipa's library implement all of the OpenSSL quirks that are necessary to implement a full bitcoin node? The only thing except ECDSA are SHA256 and RIMP160 hashing funcs, but both are easy to implement without OpenSSL. Though from what I heard, they are currently busy adding some X509 stuff, so eventually it will need OpenSSL even more. Unless Terminator will get Gavin's ass first, in which case there may be some more time to see the reference code with no OpenSSL dependency.
|
|
|
My C:\Users\[username]\AppData\Roaming\Bitcoin directory has ballooned up to approx. 17 GB and I feel like this is larger than it needs to be...
You might have the old block database, which you won't need anymore. I don't remember though which folder it was, but it should be a second that has a few gigs of files. Also I believe if you have NTFS (and most windows users do), you can order your system to compress the folder - that would also save you some space.
|
|
|
Regarding that secp256k1 library,
I've been trying to get it to compile in Visual Studio, but there are some issues with it, namely the secp256k1_fe_mul_inner and secp256k1_fe_sqr_inner inner have a sysv_abi calling convention, that VS doesn't understand and it's using __int128 that VS doesn't support.
Maybe I can get something to work via MingW, but I'll save that for another day.
Edit: defining field 10x26 looks promising.
It works fine in mingw. You just need some changes in the config script and a slightly different Makefile. See build_windows.txt in my fork: https://github.com/piotrnar/secp256k1
|
|
|
OK, then sorry. I should had read more May I ask, do you really need such a hi tech for a business? It seems like 100x more sophisticated than MtGox
|
|
|
I personally don't see a reason to swap wallet format between different wallets. And even if there was, I'm sure someone can build a converter. So I personally don't really care about a compatibility of my wallet with other wallets - especially that I keep my wallet it simple
|
|
|
This however is the wallet where we expect to see different implementations. The purpose of the standard here is to enable interoperability across implementations. I think the JSON file I provided is a reusable piece of data for any other implementation's unit test and the algorithm I wrote helps to clarify what is evtl. not obvious in writing. Let me know if more is needed to have "a" reference.
I should probably read a bit more before asking what is the "interoperability across implementations". Means being able to transfer keys and key hierarchies from one wallet to an other even if they use different implementations. Now I understand. So you are saying that it should be 'Final' already. OK - I'm with you, assuming that it works, though please don't ask me to test it.
|
|
|
|