Pages:
Author

Topic: Boycott 0.8.2 (Read 18983 times)

newbie
Activity: 5
Merit: 0
March 26, 2018, 04:52:03 PM
I can no l0nger use bitcoin on either a mac or windows. I cant even install the client on windows without errors and my mac is unuseable with bitcoin-qt. Yes you should boycott it, because the coding is fucking  shit.
Try Linux.

He shouldn't have to try anything. The core development team, doesn't even code anymore they all do work for other bitcoin companies and have lost focus on what is really important.

But... Linux is imo plain old way better than those OS's are. Why should bitcoin bow to inferior operating systems? Popular use is cool, but I'd be happier about 10% of all linux users using btc than 11% of windows users using it. (Note that i have no idea what these numbers actually imply.)

Considering Mac is on par with linux I don't care about either one of them. I have even removed bitcoind from my servers, I built my own client using bitcoinj.

Is posible working with this program in a old computer (if dont have a video card)Huh
Eri
sr. member
Activity: 264
Merit: 250
July 02, 2013, 06:59:48 AM
@Pent and Lucif

This thread isnt the place to discuss projects that dont exist in any form. If you want to suggest your thinking regarding it, may i suggest you start your own thread, and if its that important just link to it from here. While conversation is mostly dead in this thread, id still call this off topic.



Your project doesnt solve the spam problem. 1000 PCs or 1 PC, if you allow spam its going to fill the bockchain with sludge that we cant get rid of. Regardless! reducing spam at the vary least reduces the blockchain size, according to your model that would reduce the amount of space required on each users computer across your distributed network, which we all know is a good thing regardless of whether were talking about bitcoin in general or your project.

The blockchains main purpose is to be a decentralized list of all bitcoins in existence and what address they belong to. It does not serve the purpose of 'storing what amount belongs to who' by perpetually storing old data from old transactions that are no longer relevant to the users. If you wanted to make a project to store the entire blockchain for those that might want it, Go for it. But it doesnt need to be the single main feature of bitcoin and it is far from sustainable regardless of the model used.

Congratulations on your ability to quote and bold something i said in plain english for all to read while at the same time failing to address the issue with exception of you giving me your assurance it will work.

PS. If your really serious about this project then you really need to write something up that has sources for information.
legendary
Activity: 1596
Merit: 1100
July 01, 2013, 09:33:12 AM
As an success example of stopping spam to be a problem - look at Google BigTable.

Has YouTube problems with spam? No.
Does it care about single video to be re-uploaded thousands of times? No.

Bigtable consists of millions cheap servers with regular SATA HDDs. I want this to be implemented in Bitcoin. It will make Bitcoin very powerful and scalable and stop spam to be a problem at all.

All your examples are highly centralized services.

If you want to build something decentralized, that is difficult to shut down or game, then it will look different than those examples.

Bigtable was not built to check for cheating in those millions of cheap servers Smiley

hero member
Activity: 490
Merit: 500
June 30, 2013, 07:57:52 AM
As an success example of stopping spam to be a problem - look at Google BigTable.

Has YouTube problems with spam? No.
Does it care about single video to be re-uploaded thousands of times? No.

Bigtable consists of millions cheap servers with regular SATA HDDs. I want this to be implemented in Bitcoin. It will make Bitcoin very powerful and scalable and stop spam to be a problem at all.
hero member
Activity: 490
Merit: 500
June 30, 2013, 07:49:50 AM
This really isnt the place for this.. but...
This is good place for this, since I'm sure this solution also will solve spam problem. But its primary point is to build scalable, distributed, easy-accessible block chain. I'm sure if it will be built, its capacity will allow to don't take attention to any spam.

Pruning does not break chain integrity. From my somewhat limited knowledge about it, pruning just removes the body of a transaction from a block and leaves the header and its hash alone. As a result blocks can still be verified. Each client would do the pruning themselves, at which point if no copies of a old transaction are floating around then its safe to assume that everyones client removed it, it was no longer needed. Regardless im more then sure there will be a few complete unaltered blockchains around if anyone needs to look up such data. Perhaps thats something your model would work for.

I absolutely don't accept any items in chain to be abandoned. Its a history of evolution. All items in chain must be stored and accessed easily from any point of Internet. This is the main point of DHT storage: scale chain and make it easy accessible. As secondary benefit I see disappear of spam problem (disappear not spam, but problem) and ability to run full chained client on any cheap or expensive hardware.

Regarding IO capacity of HDDs, i cant say because i dont know. But it doesnt seem to be a problem yet. I also think there are more pressing issues.

This. I do know what is IO problems. They hide for a long time and appear instantly choking project in bottlenecks. My primary work is to build distributed storages for heavy random IO operations. I know what is when SATA HDD allows only 10 MBit/sec throughput on random reads. I ask you, all don't put the whole network load on one regular client!

Maybe you should write up a paper about it and see if you can get the devs to look at it and tell you if your going in the right direction.

Probably yes. I will develop one.
Eri
sr. member
Activity: 264
Merit: 250
June 30, 2013, 07:19:47 AM
2. Your 'ultimate storage' grows with more users, but so does the amount of spam produced. It would solve nothing. I like many others would still prefer to store the entire chain.
You answered this by own in 4. 1000s HDD are anyway better than one.

4. Pruning, would remove all spent transactions that are 2(?) transactions back since they wouldnt be needed, dramatically reducing the size of the blockchain. At which point your solution is entirely moot since anyone could store whats left of it without issue.
This is good solution, but this breaks chain integrity. And who said spent outputs will not be needed by anyone?

5. Storage devices are getting cheaper and larger every day and so is memory. im sure if it were needed at some point in the future someone could build a custom board with a crazy amount of memory on it to store the UTXO set. With the speed memory runs at im sure someone could make a slower, cheaper, larger ramdisks for this purpose.

Everybody blindly repeat this following satoshi. But satoshi said this regarding storage space capacity. HDD also have one more very important property which nobody takes into account: IO capacity. Soon, bitcoind will run out of IO capacity of spinning HDD, and later, solid state drives.

I don't propose to discard whole local chain. I propose don't dig it without need on local side.

I know at least one use case where my solution will bring performance benefits.

I know that DHT storage just moves load from disk IO to network IO. But just realize, we have a new block with thousands transactions.

With regular client, EACH NETWORK NODE will have to dig into own local chain and do a key lookup there for each transaction. Thousands or millions of nodes will have to do same hard IO work on each new block.

With regular client + DHT enabled - only few will do this. They will cache lookup results into local DHT cache and answer to others from there. So in this case, only few nodes will perform local chain lookup. Lookup results will distribute along network in mostly cached answers.

As bonus, there will be google-large peta-scale storage for all chain with its glory.a

This really isnt the place for this.. but...

Pruning does not break chain integrity. From my somewhat limited knowledge about it, pruning just removes the body of a transaction from a block and leaves the header and its hash alone. As a result blocks can still be verified. Each client would do the pruning themselves, at which point if no copies of a old transaction are floating around then its safe to assume that everyones client removed it, it was no longer needed. Regardless im more then sure there will be a few complete unaltered blockchains around if anyone needs to look up such data. Perhaps thats something your model would work for.

Regarding IO capacity of HDDs, i cant say because i dont know. But it doesnt seem to be a problem yet. I also think there are more pressing issues.

While torrent like storage of data does have its benefits i dont think its solving anything that cant already be solved. To be honest, what you want to use it for sounds nice, but im not sure if its workable or even needed. The thread you pointed to doesnt contain any of this information your talking about, and im not going to go look.

Maybe you should write up a paper about it and see if you can get the devs to look at it and tell you if your going in the right direction.
sr. member
Activity: 462
Merit: 250
Clown prophet
June 30, 2013, 05:02:12 AM
2. Your 'ultimate storage' grows with more users, but so does the amount of spam produced. It would solve nothing. I like many others would still prefer to store the entire chain.
You answered this by own in 4. 1000s HDD are anyway better than one.

4. Pruning, would remove all spent transactions that are 2(?) transactions back since they wouldnt be needed, dramatically reducing the size of the blockchain. At which point your solution is entirely moot since anyone could store whats left of it without issue.
This is good solution, but this breaks chain integrity. And who said spent outputs will not be needed by anyone?

5. Storage devices are getting cheaper and larger every day and so is memory. im sure if it were needed at some point in the future someone could build a custom board with a crazy amount of memory on it to store the UTXO set. With the speed memory runs at im sure someone could make a slower, cheaper, larger ramdisks for this purpose.

Everybody blindly repeat this following satoshi. But satoshi said this regarding storage space capacity. HDD also have one more very important property which nobody takes into account: IO capacity. Soon, bitcoind will run out of IO capacity of spinning HDD, and later, solid state drives.

I don't propose to discard whole local chain. I propose don't dig it without need on local side.

I know at least one use case where my solution will bring performance benefits.

I know that DHT storage just moves load from disk IO to network IO. But just realize, we have a new block with thousands transactions.

With regular client, EACH NETWORK NODE will have to dig into own local chain and do a key lookup there for each transaction. Thousands or millions of nodes will have to do same hard IO work on each new block.

With regular client + DHT enabled - only few will do this. They will cache lookup results into local DHT cache and answer to others from there. So in this case, only few nodes will perform local chain lookup. Lookup results will distribute along network in mostly cached answers.

As bonus, there will be google-large peta-scale storage for all chain with its glory.a
Eri
sr. member
Activity: 264
Merit: 250
June 30, 2013, 01:02:52 AM
I propose more efficient solution of spam problem.

Don't use hardcode.

Just lets develop ultimate storage which will not give a fuck about spam.

https://bitcointalksearch.org/topic/bitcoin-addon-distributed-block-chain-storage-197810

1. It may sound harsh but your solution seems pointless for now.
2. Your 'ultimate storage' grows with more users, but so does the amount of spam produced. It would solve nothing. I like many others would still prefer to store the entire chain.
3. Current fix = limited/no spam.
4. Pruning, would remove all spent transactions that are 2(?) transactions back since they wouldnt be needed, dramatically reducing the size of the blockchain. At which point your solution is entirely moot since anyone could store whats left of it without issue.
5. Storage devices are getting cheaper and larger every day and so is memory. im sure if it were needed at some point in the future someone could build a custom board with a crazy amount of memory on it to store the UTXO set. With the speed memory runs at im sure someone could make a slower, cheaper, larger ramdisks for this purpose.
sr. member
Activity: 462
Merit: 250
Clown prophet
June 29, 2013, 03:32:06 PM
I propose more efficient solution of spam problem.

Don't use hardcode.

Just lets develop ultimate storage which will not give a fuck about spam.

https://bitcointalksearch.org/topic/bitcoin-addon-distributed-block-chain-storage-197810
donator
Activity: 1218
Merit: 1079
Gerald Davis
June 29, 2013, 02:22:02 PM
To really stop dust, we need to ensure that *every* miner enforces this policy. How is that going to happen?

Maybe the newer clients should be made to reject blocks containing transactions with dust outputs.

That would lead to a hard fork scenario, developers try to avoid that at all costs.  The goal isn't to "really stop" dust but to simply reduce the viability of creating dust.  If the vast majority of miners choose not to include dust transactions then dust transactions will be less common.  Will it go to 0.0000000000000000000000000000000000000000000000000000000000000% of all future transactions?  No but it will be a lot less than when every node and miner by default includes them because there is no simple, effective method of excluding them.

Simple version:
If a majority of nodes and miners want "spam" then it obviously isn't spam.  If a tiny number of nodes and miners relay/mine spam tx then it will be far more difficult to use these and there will be less of them.  Win-win.
legendary
Activity: 1001
Merit: 1005
June 29, 2013, 01:59:18 PM
To really stop dust, we need to ensure that *every* miner enforces this policy. How is that going to happen?

Maybe the newer clients should be made to reject blocks containing transactions with dust outputs.
donator
Activity: 714
Merit: 510
Preaching the gospel of Satoshi
June 29, 2013, 09:03:41 AM
I am baffled at the level of ignorance and plain stupidity of the bashers here.
This is the Main weakness of a democracy: how on Earth can you give power to the people when the people is ignorant.
A true democracy is utopic because it requires an educated and a rational population.

I just hope that the knowledgeable vs conspiranoid ratio of this community is not leaning towards the latter, or the economy will implode.
member
Activity: 108
Merit: 10
Free Dog to good home
June 29, 2013, 04:53:36 AM
Litecoin banned microtransactions a while ago by requiring huge (0.01) fees.  It's still going strong.  Stop whining.

I love tacos!

After reading all of this thread, I have come to these conclusions;

1. OP has a valid argument whether or not anyone agrees with him. To continually try to shut him down is rude and butt-ugly!

2. Posters calling him derogatory names does nothing to address the argument or your own reputation. (I know most of you couldn't give a FF what anyone thinks of them but you should)

3. After explaining "why" something is being done it may need to be explained 40 more times because many will not read the thread to have a clue what is actually being discussed.

4. Even if something will make the system better, some will choose to ignore any facts posted by anyone if you somehow seem to disagree with them.

5. It is mostly irrelevant since a new version is out now.

6.I love tacos! (I need to open a BtcTaco stand yes)

T.
Eri
sr. member
Activity: 264
Merit: 250
June 29, 2013, 02:12:18 AM
I don't understand why this is an issue -

If ver 0.8.2 is a problem, why not use 0.8.1 ?

Or someone recompile the 0.8.2 source with the changes you want/dont want ..

As far as I can see, no one has a central authority to decide anything on bitcoin.

The p2p network continues to work regardless of version ..

or am I wrong ?

You don't even need to recompile, you just edit a text file and restart.

The problem is that some people don't want you to be able to change how your node acts.  They don't want you to have the option to refuse to relay their crap.

That is the reason for all of the fuss.  0.8.2 puts the node operator in charge of the relay policy for their own node.

Right -

So why does this thread exist ? - Why are there so many posts regarding boycotting
a version ? - Does G.Andresen have some special ability to force the bitcoin network
to adhere to this or that or as mentioned recently no longer allowing very small
transactions.  If I'm using version 0.8.0 can I still make very small transactions ??
or is there some central server which has a global config file that all p2p connections
read and thus now prevent these mentioned small transactions ?

"So why does this thread exist ? - Why are there so many posts regarding boycotting
a version ? "
-Because people dont know what they are talking about. They see a bunch of people complaining and saying the same incorrect thing over and over so they think "they must be right!" this whole thing got started because one of the OPs on one of these threads started spouting crap against it before they even knew what it was, and everyone jumped on the crazy train cause they didnt know better.  "if they are that much against it.. they must be right.. "

"Does G.Andresen have some special ability to force the bitcoin network
to adhere to this or that"
-No, he doesnt. His power comes from knowledge. Other people that know whats going on understand and download the updates, if they were bad they would let everyone know. Problem this time, the mob has spoken! and rather then following the people that understand, they are following the ones that dont understand.(ever heard of the phrase, 'the blind leading the blind'?)

"or as mentioned recently no longer allowing very small
transactions. "
-this is complicated, you either
A: Havnt read anything weve said.
B: Read it, but you dont understand enough about bitcoin to understand whats being talked about or the finer points involved.

" If I'm using version 0.8.0 can I still make very small transactions ?? "
-this is complicated, you either
A: Havnt read anything weve said.
B: Read it, but you dont understand enough about bitcoin to understand whats being talked about or the finer points involved.

"or is there some central server which has a global config file that all p2p connections
read and thus now prevent these mentioned small transactions ?"
- OK. With that question, that means you either dont understand enough about bitcoin yet or your making a joke.
- With this change the entire network is setup in a way where everyone can choose what they will and wont pass on for transactions, You now have a choice where you had none before.  - What this means is ...

A: As long as their are enough people willing to pass along garbage data and willing to flood blocks with spam, you will still have the ability to waste you bitcoins to your hearts content.

Or...

B: You can be part of the change to prevent people from being forced to waste money because they simply dont know any better.

 (to clarify, were trying to give you the tools to choose whether to free yourself or be chained to high fees. Your begging to simply be forced to pay high fees that will cost you more money then what your sending or receiving).

Super simple and summed up. 
(with clients before 0.8.2)
-Many tiny transactions = super high fees.
(with client 0.8.2 and after)
-By default, it does its best to prevent people from creating transactions that will waste their money, YOUR money.

Ex, (Clients before 0.8.2) I send you 100 pennies one penny at a time, you try to spend it, the required fee is 1.50$  You have to pay a fee of 1.50$ to spend your 100 pennies. why would you want to be sent 100 pennies 1 at a time if its going to cost you an additional 1.50$ to spend them?
sr. member
Activity: 364
Merit: 252
June 28, 2013, 11:56:21 PM
I don't know how gmaxwell, jgarzik and Gavin put up with this, really I don't.

I just hope they realize that for every one of these screaming lunatics who can't read, there are tens of thousands of us who appreciate their hard work. Thanks, guys.

Indeed, keep up the great work devs Cheesy
donator
Activity: 1218
Merit: 1079
Gerald Davis
June 28, 2013, 09:41:23 PM
I don't understand why this is an issue -

If ver 0.8.2 is a problem, why not use 0.8.1 ?

Or someone recompile the 0.8.2 source with the changes you want/dont want ..

As far as I can see, no one has a central authority to decide anything on bitcoin.

The p2p network continues to work regardless of version ..

or am I wrong ?

You don't even need to recompile, you just edit a text file and restart.

The problem is that some people don't want you to be able to change how your node acts.  They don't want you to have the option to refuse to relay their crap.

That is the reason for all of the fuss.  0.8.2 puts the node operator in charge of the relay policy for their own node.

Right -

So why does this thread exist ? - Why are there so many posts regarding boycotting
a version ? - Does G.Andresen have some special ability to force the bitcoin network
to adhere to this or that or as mentioned recently no longer allowing very small
transactions.  If I'm using version 0.8.0 can I still make very small transactions ??
or is there some central server which has a global config file that all p2p connections
read and thus now prevent these mentioned small transactions ?


You can control what YOUR node does but you can't control what other nodes do.  If your node can't find another node to relay and another miner willing to mine your small, spammy transactions they won't be confirmed.

People like to speak about the Bitcoin network in abstract as if it is the unified system runnning across multiple computers.  The reality is that the "network" consists of thousands of independent nodes.  You can't force another node to do something they don't want to.  Prior to 0.8.2 other nodes had no way to block dust transactions.  Now they do.
newbie
Activity: 24
Merit: 0
June 28, 2013, 08:35:45 PM
I don't understand why this is an issue -

If ver 0.8.2 is a problem, why not use 0.8.1 ?

Or someone recompile the 0.8.2 source with the changes you want/dont want ..

As far as I can see, no one has a central authority to decide anything on bitcoin.

The p2p network continues to work regardless of version ..

or am I wrong ?

You don't even need to recompile, you just edit a text file and restart.

The problem is that some people don't want you to be able to change how your node acts.  They don't want you to have the option to refuse to relay their crap.

That is the reason for all of the fuss.  0.8.2 puts the node operator in charge of the relay policy for their own node.

Right -

So why does this thread exist ? - Why are there so many posts regarding boycotting
a version ? - Does G.Andresen have some special ability to force the bitcoin network
to adhere to this or that or as mentioned recently no longer allowing very small
transactions.  If I'm using version 0.8.0 can I still make very small transactions ??
or is there some central server which has a global config file that all p2p connections
read and thus now prevent these mentioned small transactions ?
kjj
legendary
Activity: 1302
Merit: 1026
June 28, 2013, 03:18:38 PM
I don't understand why this is an issue -

If ver 0.8.2 is a problem, why not use 0.8.1 ?

Or someone recompile the 0.8.2 source with the changes you want/dont want ..

As far as I can see, no one has a central authority to decide anything on bitcoin.

The p2p network continues to work regardless of version ..

or am I wrong ?

You don't even need to recompile, you just edit a text file and restart.

The problem is that some people don't want you to be able to change how your node acts.  They don't want you to have the option to refuse to relay their crap.

That is the reason for all of the fuss.  0.8.2 puts the node operator in charge of the relay policy for their own node.
donator
Activity: 1218
Merit: 1079
Gerald Davis
June 28, 2013, 09:56:57 AM

Hi,

I don't understand why this is an issue -

If ver 0.8.2 is a problem, why not use 0.8.1 ?

Or someone recompile the 0.8.2 source with the changes you want/dont want ..

As far as I can see, no one has a central authority to decide anything on bitcoin.

The p2p network continues to work regardless of version ..

or am I wrong ?

MK

It is not an issue.  You don't even need to recompile or build an alternative client.  Dust is set at 54.3% of min relay tx fee amount.  By default that is 0.1 mBTC (10,000 S) and thus dust is 0.0543 mBTC (5,430 S).  If you disagree with the default all you need to do is add a line to the config file changing the default minimum relay fee amount to a lower (or higher) amount.

Due to a potential zero confirm double spend attack (which only affects clients prior to 0.8.2) and a memory crash denial of service attack (which only affects clients prior to 0.8.3) "boycotting" the latest client is horribly stupid advice.  Users should upgrade to 0.8.3 and modify their config file if they don't like the default values.



newbie
Activity: 24
Merit: 0
June 28, 2013, 09:46:39 AM

Hi,

I don't understand why this is an issue -

If ver 0.8.2 is a problem, why not use 0.8.1 ?

Or someone recompile the 0.8.2 source with the changes you want/dont want ..

As far as I can see, no one has a central authority to decide anything on bitcoin.

The p2p network continues to work regardless of version ..

or am I wrong ?

MK
Pages:
Jump to: