Bitcoin Forum
March 19, 2024, 11:13:40 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 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 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 104 105 106 ... 113 »
1101  Economy / Economics / Re: The limited supply model has proven to be a failure on: October 06, 2011, 04:10:03 PM
I had a post count under 1,000 once, but I don't any more.
It's nothing personal, but from experience it seems that people with ridiculous number of post counts take it as their personal duty to respond to just about anyone saying anything on the board whether they've got something valuable to add or not. That's why their replies, generally speaking, don't tend to be very useful or well-thought. And I've seen three examples today already.

Sorry, but if i had 100 posts, not 1000, i would still say that your argumentation is a complete bullshit.

I really admire kjj and BitterTea for wasting time with you. You just don't get simplest things. Your whole point is illogical, false and based on wrong assumptions and facts.

But keep going, just let me grab some popcorn.
1102  Economy / Economics / Re: The limited supply model has proven to be a failure on: October 06, 2011, 01:43:10 PM
Additionally the poll in the topic may very well be rigged, as SMF currently does not support blocking votes of people with less than X posts and registered longer than Y days.
So why can't it be rigged against me then?

Can be rigged both ways. That is the point.
But i would rather suspect it is rigged "your" way.


Also, it is pointless to discuss with Suggester, as he just doesn't get it.
But it's not pointless to come to a thread only to say it's pointless to argue in it?

It's not because you are not getting it.


I'm really thankful to whomever added this fantastic ignore button. Keep barking boys, you gotta have at least 2k posts before Christmas.

I am not in a hurry anywhere. I think i rather won't cross 2k posts in the next year, unless something special happens.

Also, 1k posts in over a year is really nothing extraordinary.
1103  Economy / Economics / Re: The limited supply model has proven to be a failure on: October 06, 2011, 01:16:07 PM
Quote
The current design is a failure so why not simply transform it instead?

Because not many people agree with you. Start your own fucking currency rather than trying to change ours.

Additionally the poll in the topic may very well be rigged, as SMF currently does not support blocking votes of people with less than X posts and registered longer than Y days.

Also, it is pointless to discuss with Suggester, as he just doesn't get it.
1104  Bitcoin / Bitcoin Discussion / Re: bitcoin7.com 'hacked'. Database and wallets 'stolen' on: October 06, 2011, 12:32:23 PM
And BTC/USD went down to 4.60 right away.

Until people (especially exchanges owners) start to take security more seriously, Bitcoin will not take off.

Creating an exchange that doesn't have bank-grade or better level of security is a complete waste of time.
Uh?

Wake up, the exchange was a scam...

Oh, seriously ?

Sorry, didn't have time to read the whole topic in detail.

Anyway, scam exchanges are even worse for the currency than badly secured exchanges, so my point stands.
1105  Bitcoin / Bitcoin Discussion / Re: bitcoin7.com 'hacked'. Database and wallets 'stolen' on: October 06, 2011, 09:05:06 AM
And BTC/USD went down to 4.60 right away.

Until people (especially exchanges owners) start to take security more seriously, Bitcoin will not take off.

Creating an exchange that doesn't have bank-grade or better level of security is a complete waste of time.
1106  Other / Meta / Re: RFC: new forum software specifications on: October 03, 2011, 09:29:03 PM
This has feature-crept a bit too far for my taste, theymos. Have you considered separating out some of these feature sets into separate projects?
The first version of the code will be the best-written code because the programmer will be thinking about all of the required features. Everything after the first version will be messier and less stable. So I want to get as much done as possible in the first version.

I don't want to sound like an ass when I say this, but this is like the anti-rule of software development.

Actually you are quite right, it's the opposite.

After 14 years in software development I can be quite sure that the first version is practically never the best. Sorry, theymos.
1107  Other / Meta / Re: RFC: new forum software specifications on: October 03, 2011, 02:02:53 PM
One feature that I would love to see is a 'pgp fingerprint’ and 'pgp key' fields within the user profile.
If the user has supplied a pgp key, on submission of a new post or editing an old post, the forum provides well-formatted version of the raw post data for singing.  The user then can upload a .sig file as an attachment to the post.

This would be extremely useful for announcements; the forum software could even automatically verify that the submitted signature is valid.
I approve this message.

Twice.

There is a high condensation of cryptogeeks on this forum, such a feature is an obvious obviousness.

Also,
1108  Other / Meta / Re: RFC: new forum software specifications on: October 01, 2011, 12:06:11 AM
So we should implement those features.

No. You just still do not comprehend how many features that is.
Creating your own forum system is a complete waste of time.

Unless you want to spend few years creating it, perfecting it, fixing bugs & cooperating with community (the same as you do with Bitcoin), then forget it.
1109  Other / Meta / Re: RFC: new forum software specifications on: September 30, 2011, 07:37:22 AM
Trust me, advanced board systems such as PHPBB, vBulletin or IPBB offer sooooooooooooooooooooooooooooo many features that you are never, ever going to catch up with them.
The point is not to catch up with them, but to implement the specific features you want.  Those systems are behemoths with all manner of silly features and plugins.

1. I am not sure If you comprehend just how many totally BASIC (no ponies & gadgets, just the basics) features modern forum systems (such as PHPBB) have. It is year of work at minimum for 3 experienced people to implement PHPBB's engine in a secure, performant way. And I am not even talking about the plugins - that's different story.

1a. I know it LOOKS easy. But it totally isn't. Building a good piece of discussion software is a tough job, and other teams (PHPBB, MyBB, IPBB, vBulletin) had years and years and years to perfect their engines. You are simply **NOT** going to produce anything better in a short time (unless you are genius or something). Period.

2. Another point is that people coming to the forum will expect certain set of features they encountered on other forums. If we don't have them, the forum will simply suck donkey arse from the point of view of users.
1110  Other / Meta / Re: RFC: new forum software specifications on: September 29, 2011, 09:15:52 PM
start from scratch? that really should not be necessary.

Absolutely necessary?  Maybe not.  A good way to get the features you want?  Definitely.  

Trust me, advanced board systems such as PHPBB, vBulletin or IPBB offer sooooooooooooooooooooooooooooo many features that you are never, ever going to catch up with them. Also, it can be really difficult to avoid security holes, unless there are many very very experienced people working on it.

The best idea is to take one of the existing popular ones, add some basic plugins and build on top of them.
Also, they can be optimized to be blazingly fast with advanced caching systems using memcache & ramdisks.
1111  Other / Meta / Re: RFC: new forum software specifications on: September 29, 2011, 12:50:45 PM
Slashdot-like meta-moderation system would be neat. I think it is the best on the web.

They actually eleminated 99,9% of spam & trolling using it.

This could come in handly, as we currently have large trolling, spam and too-many-meaningless-posts problem. Slashdot moderation would probably eleminate them all, mostly at least.
1112  Bitcoin / Development & Technical Discussion / Re: Is blockexplorer's total bitcoins in existance accurate? on: September 28, 2011, 01:10:28 PM
What about if a mining pool gets hacked and produces thousands of blocks of which each will yield 0 BTC ? This is a possible attack vector.
If a mining pool is generating blocks that yield 0 BTC, this is going to be noticed immediately and fixed quickly. Adding complexity to the client to reject those blocks doesn't help the mining pool in any way.

Still, shouldn't Bitcoin protocol be more predictable, like there will be exactly X coins in circulation at specified time ?

Not allowing miners to generate more than 50 BTC, while simulataneously allowing them to generate less than 50 BTC is little weird from programmer's point of view. Why should  < 50 BTC blocks be counted as valid, while blocks > 50 BTC be counted as invalid ?

Why wouldn't this work both ways ?
1113  Bitcoin / Development & Technical Discussion / Re: Is blockexplorer's total bitcoins in existance accurate? on: September 28, 2011, 11:27:08 AM
But can they not prevent new coins from coming into existence? Surely as a method of coin destruction it should be patched?

You can't stop people from destroying coins. People can just lose their private keys if they want to destroy BTC.

So you are saying that we should allow miners to generate tons of invalid blocks with 0 BTC as output ?

What about if a mining pool gets hacked and produces thousands of blocks of which each will yield 0 BTC ? This is a possible attack vector.
1114  Bitcoin / Development & Technical Discussion / Re: Proposal: make it so anybody could easily compile the client on: September 28, 2011, 05:18:24 AM

I've tried once to compile it. Gave up.

I don't understand why can't you bundle all the needed libraries and distribute the complete source code with the client?

1) You will get more trust. What's the point of doing code review if you can't compile a binary version from it?

2) You will get more developers involved. I, personally, can't spend several days, figuring out just how to compile it. But if it were a matter of loading it into VS and hitting Build, I might work on small features or optimizations.

And the most annoying is that I don't see any rational reasons not to do it! Why hasn't it been done from the beginning? Are you trying to impose some sort of an artificial "entry barrier"?


P.S. I am specifically talking about Windows.

It is more difficult to compile anything on windows by default.
If you want to EASILY compile things, move to an Open Source UNIX-like system (such as Linux), which is designed for ease of compilation by default.

However, having a proper ./configure script on UNIX/Linux wouldn't hurt. For now it is not possible to do the following on the Bitcoin client sources:

Code:
./configure
make
make install

Which is a little annoying. Other then that, compilation on UNIX is not problematic.
1115  Bitcoin / Development & Technical Discussion / Re: What Guarantees Are There That The Supply of Bitcoin Will Be Limited on: September 26, 2011, 09:06:48 AM
lets suppose automatic upgrade feature is installed and widely adopted, and so this could work for some days

Having an auto-upgrade for the Bitcoin client would not be a good idea.
It might be a good idea for the downloadable reference client (opt-out of course), although obviously not for mining platforms that enforce the security of the network.

Having an automatic update feature opens a whole world of possible security breaches and it could potentially damage the network.

Consider the following scenario:

1. Automatic update servers are cracked,
2. Depending on the attacker (casual thief or government) a trojan OR modifiied client is planted in place of the legitimate client
3. 80% of users download the fake client

Now, there are 2 options:
4a. The hacker steals wallets of 80 percent of the bitcoin users. OR
4b. The hacker uses the modified client to damage the network, split chains, implant child pornography into chain or whatever else

5. ?? ??
6. PROFIT !

Such damage could be fatal to the network and could actually destroy the people's faith in the currency.

So no, having an automatic update feature is definately NOT a good idea.
1116  Bitcoin / Development & Technical Discussion / Re: What Guarantees Are There That The Supply of Bitcoin Will Be Limited on: September 26, 2011, 07:37:40 AM
lets suppose automatic upgrade feature is installed and widely adopted, and so this could work for some days

Having an auto-upgrade for the Bitcoin client would not be a good idea.

+ 1
1117  Bitcoin / Development & Technical Discussion / Re: Transaction fees magically appearing, how to account for them? on: September 25, 2011, 01:33:15 PM
Is there already a RPC API solution for getting the estimated fees OR a feature that blocks the sending if the account balance would become insufficent? Anything planned for the next version? I think this is very important for handling accounts and running bitcoin services!

Unfortunately, there isn't anything like that. Read here:
https://bitcointalk.org/index.php?topic=45259.0

This is the exact reason why i created my fork. There isn't any way to force sending money without any fee currently.
1118  Bitcoin / Development & Technical Discussion / Re: What Guarantees Are There That The Supply of Bitcoin Will Be Limited on: September 25, 2011, 10:21:06 AM
Thanks, I thought there was some deep hidden reason. If that's the case then I understand the OP's question and have one of my own.

If bitcoin did become widely accepted at some point in time it would then be possible to increase the supply of btc based on demand instead of simply relying on shifting the base-10 numeral system down another decimal fraction (i.e. printing more money). Yes?

Let me sum up for you what would happen in short IF the developers increased the money supply:

1. The blockchain would split into the NEW chain (with more inflation) and the OLD chain (with unchanged inflation)
2. Most of people, including me, would abandon the NEW chain and go back to OLD chain
3. Bitcoins from the NEW chain would enter a downward spiral until they would become worthless

Seriously, who would want to be robbed ? And that is exactly what increased inflation is - common thievery.
1119  Bitcoin / Development & Technical Discussion / Re: Is blockexplorer's total bitcoins in existance accurate? on: September 24, 2011, 11:44:03 PM
Looks like a buggy miner subtracted the Tx fee instead of adding it--but why was the block accepted by the network?

Exactly. That could be a serious weakness in the protocol.
Why would all other clients accept such blocks ?

Shoudn't there be a rule that only allows relaying/accepting of completely valid and "full" blocks ?

For example: if a huge mining pool suddenly breaks down and starts producing blocks which earn 0 BTC to the network, then a lot of BTC could be lost in the process.
1120  Bitcoin / Development & Technical Discussion / Re: Is blockexplorer's total bitcoins in existance accurate? on: September 24, 2011, 09:55:44 PM
Sorry for the stupid question, but how did 20 nanobitcoins get destroyed in that block? I thought bitcoins never gets destroyed, they can only become irretrievable?

Did you not see that the generated coins were 49.99999999 instead of 50?

More important questions:

1. Was that expected when the Bitcoin protocol was designed, or is this something new ?
2. Is it proper for a block to generate 49.99999999 bitcoins instead of the usual 50 ? Where did the 0.00000001 bitcoins go ?
3. If it is not proper, why wouldn't the network reject such a block ?
Pages: « 1 ... 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 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 104 105 106 ... 113 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!