Bitcoin Forum
May 24, 2024, 08:13:29 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 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 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 »
1161  Bitcoin / Development & Technical Discussion / Re: A bitcoin blockchain parser in a few hundred lines of C++ on: July 02, 2013, 06:56:30 PM
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
1162  Bitcoin / Development & Technical Discussion / Re: What stops short forks from taking up everyone's disk space? on: July 01, 2013, 06:16:16 PM
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.
1163  Bitcoin / Development & Technical Discussion / Re: Transaction validation on: July 01, 2013, 06:08:18 PM
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.
1164  Bitcoin / Development & Technical Discussion / Re: Proposal: We should vote on the blocksize limit with proof-of-stake voting on: June 29, 2013, 06:12:15 PM
Yeah, gmaxwell's comments yesterday were extremely helpful.  Smiley
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 Smiley
1165  Bitcoin / Development & Technical Discussion / Re: Proposal: We should vote on the blocksize limit with proof-of-stake voting on: June 29, 2013, 05:52:54 PM
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. Smiley
1166  Bitcoin / Development & Technical Discussion / Re: Proposal: We should vote on the blocksize limit with proof-of-stake voting on: June 29, 2013, 05:18:12 PM
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.. Smiley

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?
1167  Bitcoin / Development & Technical Discussion / Re: Proposal: We should vote on the blocksize limit with proof-of-stake voting on: June 28, 2013, 07:44:54 PM
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. Smiley

But I'm still waiting for the answer to my question: what is your business in promoting bitcoin banks to rule the protocol?
1168  Bitcoin / Development & Technical Discussion / Re: Proposal: We should vote on the blocksize limit with proof-of-stake voting on: June 28, 2013, 04:36:55 PM
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.
1169  Bitcoin / Development & Technical Discussion / Re: Proposal: We should vote on the blocksize limit with proof-of-stake voting on: June 28, 2013, 04:03:34 PM
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.
1170  Bitcoin / Development & Technical Discussion / Re: Proposal: We should vote on the blocksize limit with proof-of-stake voting on: June 28, 2013, 03:54:38 PM
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.
1171  Bitcoin / Development & Technical Discussion / Re: What if the devs are ordered by a US judge to include a government backdoor? on: June 24, 2013, 09:44:08 PM
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
1172  Bitcoin / Development & Technical Discussion / Re: What if the devs are ordered by a US judge to include a government backdoor? on: June 24, 2013, 09:23:34 PM
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
1173  Bitcoin / Development & Technical Discussion / Re: What if the devs are ordered by a US judge to include a government backdoor? on: June 24, 2013, 08:00:26 PM
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.
1174  Bitcoin / Development & Technical Discussion / Re: ECDsa Verification Speed on: June 24, 2013, 05:49:19 PM
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.
1175  Bitcoin / Development & Technical Discussion / Re: ECDsa Verification Speed on: June 24, 2013, 03:04:09 PM
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.
1176  Bitcoin / Development & Technical Discussion / Re: Any way to reduce the size of the Bitcoin dir in windows? on: June 24, 2013, 09:25:07 AM
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.
1177  Bitcoin / Development & Technical Discussion / Re: ECDsa Verification Speed on: June 24, 2013, 09:22:20 AM
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
1178  Bitcoin / Development & Technical Discussion / Re: Deterministic wallets on: June 22, 2013, 07:49:26 PM
OK, then sorry.
I should had read more Smiley

May I ask, do you really need such a hi tech for a business?
It seems like 100x more sophisticated than MtGox
1179  Bitcoin / Development & Technical Discussion / Re: Deterministic wallets on: June 22, 2013, 07:42:08 PM
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
1180  Bitcoin / Development & Technical Discussion / Re: Deterministic wallets on: June 22, 2013, 07:18:23 PM
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". Smiley

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. Wink
Pages: « 1 ... 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 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!