Bitcoin Forum
July 16, 2024, 03:26:17 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 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 »
1241  Bitcoin / Development & Technical Discussion / Re: Please do not change MAX_BLOCK_SIZE on: June 04, 2013, 06:49:31 PM
Do you like it ?
man i really don't care about your trolling.
really.
you might even write a poem for me, and trust me: I wont read it Smiley
1242  Bitcoin / Development & Technical Discussion / Re: Please do not change MAX_BLOCK_SIZE on: June 04, 2013, 06:37:55 PM
"Don't be silly" is simply not a proper way to reply to somebody whose a person in the family has recently died.
It is, if it was an answer to an argument/excuse on an arbitrary change of the bitcoin protocol.
I understand how broken you can be at such moments, but bringing it as an argument on whether we should increase a block size, or not... Please.
1243  Bitcoin / Development & Technical Discussion / Re: Please do not change MAX_BLOCK_SIZE on: June 04, 2013, 06:31:42 PM
Now you are just being a rude son of a bitch (not a troll).
I would have been rude if I was lying to have someone really close to me died recently.
But since it really happened, and you feel sorry for Gavin, but not at all for me and my mom, then I can only tell you back: fuck you!
Still, the code does not care about who died and someone has to take the stake and develop it further in the right direction.
1244  Bitcoin / Development & Technical Discussion / Re: Please do not change MAX_BLOCK_SIZE on: June 04, 2013, 06:18:05 PM
Well, then please refer me to the post that addresses my last question: Does Gavin's salary paid by the Bitcoin Foundation create a conflict of interest?
Or another question: Does Bitcoin Foundation try to discourage development of off-chain transactions technologies, in favour of increasing the block size?
If you're going to ask that question it's also reasonable to demand that everybody who is opposed to raising the limit disclose whether or not they are developing or invested in competing cryptocurrencies or transaction processing systems.

That is also a conflict of interests.
Well, feel free to disclose your motives.
I've already stated it that I own some mining shares, so I have an obvious incentive to keep the limit on.
Though, which you probably won't believe, my main motivation comes from a sincere care about this fine project and its future, and not from the few extra percent benefits of my mining operations.
1245  Bitcoin / Development & Technical Discussion / Re: Please do not change MAX_BLOCK_SIZE on: June 04, 2013, 06:03:52 PM
I've been derailed the last week by a death in the family, and still need to finish up some payment protocol work.
Please, don't be silly.
I'm sorry for your lose, but should I be bringing the deaths in my family as well? I've surely had some recently, but it's just not an argument for a bitcoin development board.

As for the wiki page, or pros/cons list - I've been there and I am now old enough to know that the only reason anyone would refer me to such a means, is if he wants to get rid of me.
So thanks, but I won't use it.
1246  Bitcoin / Development & Technical Discussion / Re: Please do not change MAX_BLOCK_SIZE on: June 04, 2013, 05:55:14 PM
Meanwhile just address some points presented in this thread and don't feed other trolls, if it's not too much to ask.

Every point presented on this subject has already being addressed. Multiple times.
Well, then please refer me to the post that addresses my last question: Does Gavin's salary paid by the Bitcoin Foundation create a conflict of interest?
Or another question: Does Bitcoin Foundation try to discourage development of off-chain transactions technologies, in favour of increasing the block size?
1247  Bitcoin / Development & Technical Discussion / Re: Please do not change MAX_BLOCK_SIZE on: June 04, 2013, 05:28:40 PM
Meanwhile just address some points presented in this thread and don't feed other trolls, if it's not too much to ask.
I think we must give him some time to consult the answers with the lawyers first Smiley

Without an explicit written permission, he seems to be only entitled to giving replies on whether he is a nazi, a troll, or a coward.. Wink
1248  Bitcoin / Development & Technical Discussion / Re: Bitcoin source code is a giant mess on: June 04, 2013, 04:43:39 PM
2. Excessive use of C++ subclasses and operators makes it hard to read code. You see a << b, but it actually goes to a very specific place which is not entirely obvious where.

Streaming operators << and >> have always been the standard way of doing I/O in C++ so are you saying these operators are being used for something *other than streaming*?


I have nothing against using << as a streaming operator. The problem is that it's much harder to search for any operators in use (be it "<<" or "+"). Especially when you pointer-dereference operator overload. Or implicit copy constructors. Yes, code may look elegant for a mathematician, but inside an app where you have tons of multi-word symbols, operator density or implicitness is painful.

When you have "[a add:b]" instead of "a + b" it's much clearer what is going on and you can quickly find all occurrences of -add: method call.
+1
I also hate these symbols, because of the same reason.
You just cannot find a function that implements it. And worse; it can either be in a header, or in a cpp file... and it can be overridden/inherited, so: good luck looking for it!
1249  Bitcoin / Development & Technical Discussion / Re: Bitcoin source code is a giant mess on: June 04, 2013, 03:08:16 PM
Really?  Well, then I was wrong all my life, believing that C++ was backward compatible with C... Smiley

You are wrong - C++ is *not* backwards compatible with C only as *close as possible*.
Close enough to have a working goto... Smiley
1250  Bitcoin / Development & Technical Discussion / Re: Please do not change MAX_BLOCK_SIZE on: June 04, 2013, 03:03:18 PM
Yeah, keep trolling guys. I surely care Smiley
1251  Bitcoin / Development & Technical Discussion / Re: Please do not change MAX_BLOCK_SIZE on: June 04, 2013, 02:55:51 PM
Obviously none of you is going to address jdillon's key argument, that is:
Bitcoin Foundation is doing (more or less consciously) everything to:
1) get bitcoin under control of the US government.
2) disturb anyone in solving the scaling issue by other means than increasing the block size
1252  Bitcoin / Development & Technical Discussion / Re: Bitcoin source code is a giant mess on: June 04, 2013, 02:35:17 PM
Coding in C and never using goto, is like driving a car and never using its last gear. Safe for poor drivers... Wink

Bitcoin is written in C++ (which is not even close to C as any C++ programmer knows).
Really?  Well, then I was wrong all my life, believing that C++ was backward compatible with C... Smiley
1253  Bitcoin / Development & Technical Discussion / Re: Bitcoin source code is a giant mess on: June 04, 2013, 02:28:10 PM
Coding in C and never using goto, is like driving a car and never using its last gear. Safe for poor drivers... Wink
1254  Bitcoin / Development & Technical Discussion / Re: Please do not change MAX_BLOCK_SIZE on: June 04, 2013, 01:39:18 PM
But if you're convinced miners would not go above the 1Mb limit, why are you afraid of replacing a hard-coded constant by voluntary/decentralized/p2p/spontaneous-order limits?
Because I'd prefer this community to stay united, in order to protect the network, instead of starting a war on who has a bigger hashing board.

Besides, I cannot resist the feeling that there is some hidden agenda and it hasn't been necessarily planed to leave the default at 1MB, but rather to sneak the patch through, without doing too much noise around it, hoping that nobody would notice. Just a fact that the lead developer is getting paid by the very same people who have a vast interest in making bitcoin nodes unavailable for an average citizen of the world - it itself indicates at least a possible conflict of interest, though some people might just simply call it a corruption.
On top of that, nothing has been consulted with the community. Gavin jumps into the thread with an announcement "The block size will be raised" because "that is the overwhelming consensus among the people who are actually writing code and using Bitcoin for products and services that it needs to happen."
What the hell? Smiley Are we supposed to just believe that whoever he talked to in San Jose was a good statistical representation of the worldwide bitcoin community and so the bitcoin community surely wants him to lift the limit from the protocol, and they want him to do it ASAP?
1255  Bitcoin / Development & Technical Discussion / Re: Please do not change MAX_BLOCK_SIZE on: June 04, 2013, 10:23:40 AM
like piotr_n says, people are either stupid or ignorant.
I actually said the opposite. You wish they were, but I doubt that they are... Smiley
1256  Bitcoin / Development & Technical Discussion / Re: Please do not change MAX_BLOCK_SIZE on: June 04, 2013, 10:19:02 AM
Well then we can only hope that none of the existing pools will choose the "force your competition out of business" model, and so if Bitcoin Foundation want to turn bitcoin's main chain into a paypal replacement, they will have to start from investing in a mining hardware, prior to building the data centers for running the nodes.
1257  Bitcoin / Development & Technical Discussion / Re: Please do not change MAX_BLOCK_SIZE on: June 04, 2013, 09:54:38 AM
...

That has nothing to do with microtransactions, normal growth in "macrotransactions" will bump up against the limit in a year or three.


So why the rush? Why not let the merchants and users ask for change when the need arises?

You have to understand where he's coming from. He and the Bitcoin Foundation are pushing Bitcoin as a system to do payments on the internet; the recent San Jose conference had the tagline "The future of payments" after all.

It's a lot harder to convince people that investing time and money into implementing Bitcoin for payments is a good idea with a 1MB limit on transactions. Removing the blocksize limit entirely and making it something that miners decide solves that problem from that perspective: regardless of what the demand from transactions are at least one entity will always be able to meet that demand at a cost approaching the cost of bandwidth and servers. That's why Gavin likes to talk a lot about "free market forces" and "competition" when it comes to mining, and has said before he's happy to see the smallest 20% or so of miners and full-node operators get forced out of business by rising costs every year.

From the perspective of someone who wants to accept Bitcoin payments on their online store letting the majority of miners decide what the blocksize is solves the uncertainty of how much transactions will cost. They connect directly to miners to send their transactions and don't care if Bitcoin is controlled by six people or six million. From the perspective of someone investing in Bitcoins because they want a decentralized store-of-value, AKA electronic gold... well they might see things differently.
I still don't see it how they are going to convince the miners to drop the 1MB limit.
Is there even a single mining pool that would not want to see 1MB limit at work, at least for awhile?
When they see it, when they see the size of the incentive the limit gives them, it will make them even more motivated to never unlock it.

Counting on the pool operators that they will just unconsciously start mining version 3 blocks, just because it will be a default setting in bitcoind version 0.8.4 onward...
One would need to think that these people are either stupid or ignorant, which I don't think they are.
1258  Bitcoin / Development & Technical Discussion / Re: Please do not change MAX_BLOCK_SIZE on: June 04, 2013, 09:33:32 AM
Dedicated servers are so cheap these days you can easily set up a machine in a random country.
Yeah - like the guy who once had Liberty Reserve.. Smiley
1259  Bitcoin / Development & Technical Discussion / Re: Please do not change MAX_BLOCK_SIZE on: June 04, 2013, 08:45:43 AM
I believe the last objection raised was that a higher block size limit would make it impossible to mine anonymously, but I think that has been debunked with the notion of "read the firehose of transactions non-anonymously, then broadcast just new block header + coinbase + listof(truncated transaction hashes) anonymously."

If this 2nd change works then Bitcoin will be massively scalable and can become the success everyone wants.
You are right - if it works, then Tor mining should be easier, though the scaling issues of a home node still remain.

Anyway let's at least hope that they will prove the debunking thesis working, before touching the number.
Though after learning that decentralization is not considered as particularly important, I am not so certain about it... Smiley


Why don't you want Bitcoin to have this chance to succeed?
Because for me Bitcoin has already succeeded and increasing the block size is playing with lethal forces that we don't even understand.
So it has succeeded, but if you act irrationally, you can easily screw it up.
1260  Bitcoin / Development & Technical Discussion / Re: Please do not change MAX_BLOCK_SIZE on: June 04, 2013, 08:26:28 AM
Why you assume that it would need to be Google/Facebook/Baidu Credits?
Why do you think that a bitcoin backed payment processor cannot be built as just yet another lightweight P2P network, protected by a cryptography?

Why do you guys keep repeating that one would be forced to give all his private keys to a bank?

And what blockchain-pruning has to do with making mining available via Tor?
Pages: « 1 ... 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!