Bitcoin Forum
May 02, 2024, 01:09:46 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Poll
Question: The bitcoin 0.8.2. build is supposed to block transactions of less than 5430 Satoshi's, Good or Bad move?
It's a good idea
It's a good idea, But not at 5430 Satoshi
It's a bad idea
It's a bad idea, It should be a lower # of btc
It's a temporary fix that should adjust with price
It's a temporary fix that should be revised later

Pages: « 1 2 3 [4] 5 6 7 »  All
  Print  
Author Topic: Bitcoin 0.8.2. What do you think?  (Read 17078 times)
jackjack
Legendary
*
Offline Offline

Activity: 1176
Merit: 1233


May Bitcoin be touched by his Noodly Appendage


View Profile
May 06, 2013, 07:22:36 AM
 #61

Noob question Huh :
Can we just move comma 2 steps right? For example turn 0.05297585 into 5.297585
So, 5.297585 will be equal ~5$ its very convenient. Block rewald will be 2500 BTC
Its like turn BTC to centiBTC.

Because i think, that when bitcoin was created, no one expected that it will be cost ~100$. And now we have some problems with useless micro BTC transactions dusting blockchain, and diffirent opinions about upcoming 0.8.2 client.  Roll Eyes
Oh look.
This.
'Fix'.
Again.
Again.
Again.Again.
Again.Again.Again.Again.
Again.Again.Again.
Again.Again.Again.Again.Again.Again.Again.Again.Again.Again.Again.Again.Again.A gain.Again.Again.Again.Again.Again.Again.Again.Again.Again.Again.Again.Again.Ag ain.Again.Again.Again.Again.Again.Again.Again.Again.Again.Again.Again.Again.Aga in.Again.Again.Again.

Own address: 19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3 - Pywallet support: 1AQDfx22pKGgXnUZFL1e4UKos3QqvRzNh5 - Bitcointalk++ script support: 1Pxeccscj1ygseTdSV1qUqQCanp2B2NMM2
Pywallet: instructions. Encrypted wallet support, export/import keys/addresses, backup wallets, export/import CSV data from/into wallet, merge wallets, delete/import addresses and transactions, recover altcoins sent to bitcoin addresses, sign/verify messages and files with Bitcoin addresses, recover deleted wallets, etc.
1714612186
Hero Member
*
Offline Offline

Posts: 1714612186

View Profile Personal Message (Offline)

Ignore
1714612186
Reply with quote  #2

1714612186
Report to moderator
1714612186
Hero Member
*
Offline Offline

Posts: 1714612186

View Profile Personal Message (Offline)

Ignore
1714612186
Reply with quote  #2

1714612186
Report to moderator
1714612186
Hero Member
*
Offline Offline

Posts: 1714612186

View Profile Personal Message (Offline)

Ignore
1714612186
Reply with quote  #2

1714612186
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714612186
Hero Member
*
Offline Offline

Posts: 1714612186

View Profile Personal Message (Offline)

Ignore
1714612186
Reply with quote  #2

1714612186
Report to moderator
1714612186
Hero Member
*
Offline Offline

Posts: 1714612186

View Profile Personal Message (Offline)

Ignore
1714612186
Reply with quote  #2

1714612186
Report to moderator
jonytk
Member
**
Offline Offline

Activity: 106
Merit: 10



View Profile
May 06, 2013, 10:27:44 AM
 #62

People, i think the solution should be this:

Forbid transaction that includes output less than x for a output address with an actuall amount of less than y.

Where x is 100 times less than the transaction fee and y 100 times more than the transaction fee.
And,
the transaction fee IS the average of the transaction fee included in the last 4380 blocks.(1 month)
with a minimum hardcoded that will change, 0.0001 for transactions of less than 0.01(at the moment)

so for example if the currently average transaction fee is 0.00054
you cannot send less than 0.0000054 to an address with less than 0.054 (it will bounce back as change?)

this will:
1- Encourage the consolidation of addresses for people that have little amounts of coins and many addreses.
2- Not prevent people from making satoshi-transactions (they will pay a fee but they will have to have some balance in the receiving address)
3- Not bloat the blockchain
4- Help in the eventually cleanup of the blockchain: then after an x period, we can cleanup all addresses with less than 100 times the transaction fee safely.(i'm not sure if this last one is possible, but we could alow the sending for free of this satoshis to a address with a minimum balance)

That should deal with the bloated blockchain problem...
people with small amounts of satoshis, and that care enought, can still recover them by sending some btc (over 0.01) to the address and then send it it back or by  alowing the sending for free of satoshis only if they leave the address with 0 balane and are send to a address with a minimum balance.

TL,DR:
Encourage consolidation of addreses, forbid sending satoshis to an empty address, allow sending satoshis (if paying fee) to an address with balance, helping cleanup of blockchain (addresess with 0 balance should be pruned)

temnize
Newbie
*
Offline Offline

Activity: 30
Merit: 0


View Profile
May 06, 2013, 02:39:38 PM
 #63

it isfine
kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1024



View Profile
May 06, 2013, 02:54:23 PM
 #64

I don't care what you think.  This is regulation plain and simple.  This is not what I was led to believe bitcoin was.  If bitcoin can't handle itself then another coin should take it's place.  END OF STORY.
Why didn't you complain when 0.00000000 outputs were made non-standard in the same way some versions ago?  Same problem, same reason to make them non-standard.  Spendable, but only in theory because it doesn't make sense to pay fees to spend them.  You can still send the transactions, and evil miners may mine them just like other dust creating transactions.  I don't want them in the blockchain, so I won't help you relaying or mining them.  That's my choice.  You can't force me to, just as I can't force you to stop behaving badly.

Cause it was your option to pay the fees, miner still had to include them and relays still had to relay. Was that big of a deal to be honest. This is completely censoring.

I think I've found the problem.

You have been operating under the mistaken impression that miners had to include certain transactions, and that nodes had to relay them.

No one has ever had to do anything.  Miners have always been free to set their own policies for inclusion into blocks, and node operators have always been free to set their own relay policies.

This patch makes it vastly easier for miners and node operators to implement their own policy decisions.  Calling it "regulation" or "censorship" is somewhere between Orwellian and Kafkaesque.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
pekv2
Hero Member
*****
Offline Offline

Activity: 770
Merit: 502



View Profile
May 06, 2013, 02:55:03 PM
 #65

This is how I feel about this situation.





http://www.reddit.com/r/Bitcoin/comments/1drs61/bitcoincensored/
Birdy
Sr. Member
****
Offline Offline

Activity: 364
Merit: 250



View Profile
May 06, 2013, 03:02:54 PM
 #66


Sorry, but this is ridiculous.
It may not be the best solution to the problem, but calling it Censorship is way off the road.
Tacticat
Full Member
***
Offline Offline

Activity: 210
Merit: 100



View Profile
May 06, 2013, 03:38:00 PM
 #67

Bitcoin has never been about deregulation as it is based on a decentralized form of regulation, but still regulation.

This change will allow peers in the network decide which transactions they forward and which not based on their value. Nothing more, nothing less.

Miners already have the ability to decide which transactions they include in a block based on a fee, now I find it correct that as a user I have the ability to choose what I forward and what I don't.

Tips and donations:

15nqQGfkgoxrBnsshD6vCuMWuz71MK51Ug
jgarzik
Legendary
*
Offline Offline

Activity: 1596
Merit: 1091


View Profile
May 06, 2013, 03:45:44 PM
 #68

Miners already have the ability to decide which transactions they include in a block based on a fee, now I find it correct that as a user I have the ability to choose what I forward and what I don't.

Correct, though I must add that users already choose what to forward, or not.

Most notably, the client will not relay transactions outside of a very narrowly defined set of "standard" transactions.  The vast majority of possible transactions are not relayed by default.  This policy has been in place for years.


Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
gweedo
Legendary
*
Offline Offline

Activity: 1498
Merit: 1000


View Profile
May 06, 2013, 03:54:39 PM
 #69

I don't care what you think.  This is regulation plain and simple.  This is not what I was led to believe bitcoin was.  If bitcoin can't handle itself then another coin should take it's place.  END OF STORY.
Why didn't you complain when 0.00000000 outputs were made non-standard in the same way some versions ago?  Same problem, same reason to make them non-standard.  Spendable, but only in theory because it doesn't make sense to pay fees to spend them.  You can still send the transactions, and evil miners may mine them just like other dust creating transactions.  I don't want them in the blockchain, so I won't help you relaying or mining them.  That's my choice.  You can't force me to, just as I can't force you to stop behaving badly.

Cause it was your option to pay the fees, miner still had to include them and relays still had to relay. Was that big of a deal to be honest. This is completely censoring.

I think I've found the problem.

You have been operating under the mistaken impression that miners had to include certain transactions, and that nodes had to relay them.

No one has ever had to do anything.  Miners have always been free to set their own policies for inclusion into blocks, and node operators have always been free to set their own relay policies.

This patch makes it vastly easier for miners and node operators to implement their own policy decisions.  Calling it "regulation" or "censorship" is somewhere between Orwellian and Kafkaesque.

Please don't twist my words, every one else understood what I was saying, and it wasn't what you think I was saying. I am not commenting on this subject anymore cause I realized that people here, take the words from the dev team to heart instead of challenging them on this "temp fix" which I have a feeling will be long term, censorship. It quite sad how many people will skew results, or twist words to fit it to what the dev team is saying including members of the dev team. They should all be ashamed of how they conduct business to the community.
kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1024



View Profile
May 06, 2013, 04:54:20 PM
 #70

Cause it was your option to pay the fees, miner still had to include them and relays still had to relay. Was that big of a deal to be honest. This is completely censoring.

I think I've found the problem.

You have been operating under the mistaken impression that miners had to include certain transactions, and that nodes had to relay them.

No one has ever had to do anything.  Miners have always been free to set their own policies for inclusion into blocks, and node operators have always been free to set their own relay policies.

This patch makes it vastly easier for miners and node operators to implement their own policy decisions.  Calling it "regulation" or "censorship" is somewhere between Orwellian and Kafkaesque.

Please don't twist my words, every one else understood what I was saying, and it wasn't what you think I was saying. I am not commenting on this subject anymore cause I realized that people here, take the words from the dev team to heart instead of challenging them on this "temp fix" which I have a feeling will be long term, censorship. It quite sad how many people will skew results, or twist words to fit it to what the dev team is saying including members of the dev team. They should all be ashamed of how they conduct business to the community.

I don't see how I've twisted your words.  They are plain words, and their common meanings aren't unclear.

Before, if you wanted a node with a different mining or relay policy, you had to write your own, or modify the source and recompile.  After, you can tweak a setting in your configuration file and restart.*  Hardly end of the world stuff, and not in any way deserving of a dozen-thread smear campaign on the forums.

P.S.  I didn't have to take anyone's word for what the patch does.  The source code is public, I just clicked the link and read it.

I was thinking of writing a patch to create RPC commands to edit these configuration values without even needing the restart.  Some moron claimed that 95% of bitcoin users weren't competent to edit their config file, which I don't in any way believe to be true.  Still, adding a RPC command would make it settable by anyone that can find the debug window.  It would also allow people to write third party bots to make live adjustments based on whatever data feeds they thought appropriate.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
Shevek
Sr. Member
****
Offline Offline

Activity: 252
Merit: 250



View Profile
May 06, 2013, 05:01:05 PM
 #71

The tiny transactions are being used as a DDOS mechanism. 


Is bitcoin no more a decentralized network!!?? This is a fresh new for me!

Proposals for improving bitcoin are like asses: everybody has one
1SheveKuPHpzpLqSvPSavik9wnC51voBa
Nite69
Sr. Member
****
Offline Offline

Activity: 477
Merit: 500


View Profile
May 06, 2013, 05:15:44 PM
 #72

Is it on the specifications? If it is not, you cannot order miners for some minimum output. Someone can make another client and pool which *conforms* the spec and allows smaller transctions.

But would it be against spec to allow any pool (or miner) to decide what transactions that pool lets in? Ie. a configuration option for minimum transaction output and fee?

I would guess markets would find a suitable minimum they accepts. Of course, there would be some pools which would accept all, but that would be minority. And if only some allows, that itself prevents the DDOS.

Sync: ShiSKnx4W6zrp69YEFQyWk5TkpnfKLA8wx
Bitcoin: 17gNvfoD2FDqTfESUxNEmTukGbGVAiJhXp
Litecoin: LhbDew4s9wbV8xeNkrdFcLK5u78APSGLrR
AuroraCoin: AXVoGgYtSVkPv96JLL7CiwcyVvPxXHXRK9
wumpus
Hero Member
*****
Offline Offline

Activity: 812
Merit: 1022

No Maps for These Territories


View Profile
May 06, 2013, 05:16:46 PM
 #73

But would it be against spec to allow any pool (or miner) to decide what transactions that pool lets in? Ie. a configuration option for minimum transaction output and fee?
Yes. There are configuration options for those. In bitcoind/-qt. No "make another client" needed.

Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
farlack
Legendary
*
Offline Offline

Activity: 1311
Merit: 1000



View Profile
May 06, 2013, 05:32:27 PM
 #74

Most people are missing the point  Undecided


The point is that no one person should be able to tell the populous what to do.


That's the point of bitcoin.. Dividing the groups is bad..


Whats next? 1/100th of fees need to be deposited to dev accounts? upgrade to this or we wont ever upgrade bitcoin again!
tvbcof
Legendary
*
Offline Offline

Activity: 4592
Merit: 1276


View Profile
May 06, 2013, 05:45:20 PM
 #75


I was thinking of writing a patch to create RPC commands to edit these configuration values without even needing the restart.  Some moron claimed that 95% of bitcoin users weren't competent to edit their config file, which I don't in any way believe to be true.  Still, adding a RPC command would make it settable by anyone that can find the debug window.  It would also allow people to write third party bots to make live adjustments based on whatever data feeds they thought appropriate.

Great idea!  I'm sure the solution could (and would) be extended to stream any wallet.dat files found kicking around to a new home pretty quickly.


sig spam anywhere and self-moderated threads on the pol&soc board are for losers.
adamstgBit
Legendary
*
Offline Offline

Activity: 1904
Merit: 1037


Trusted Bitcoiner


View Profile WWW
May 06, 2013, 05:50:46 PM
 #76

Quote
It's a temporary fix that should adjust with price   
It's a temporary fix that should be revised later

This

and, if you want to do a lot of TX for value less then 1 penny just use LTC ?

kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1024



View Profile
May 06, 2013, 06:23:22 PM
 #77


I was thinking of writing a patch to create RPC commands to edit these configuration values without even needing the restart.  Some moron claimed that 95% of bitcoin users weren't competent to edit their config file, which I don't in any way believe to be true.  Still, adding a RPC command would make it settable by anyone that can find the debug window.  It would also allow people to write third party bots to make live adjustments based on whatever data feeds they thought appropriate.

Great idea!  I'm sure the solution could (and would) be extended to stream any wallet.dat files found kicking around to a new home pretty quickly.

That is a general problem with the RPC system.  Sadly, adding a granular permission system to it is beyond what I'm able to tackle right now.  Splitting the RPC calls into public, private and trusted, and having distinct credentials for each level would be quite a bit easier, but still not something I have time for.*

Also, a script to monitor a few data feeds and calculate appropriate fee levels would be pretty simple.  Most people that would actually need such a thing should be able to write their own.

If I were doing it, I would add four new config values, rpcpublicuser, rpcpublicpassword, rpcprivateuser and rpcprivatepassword.  The current values (rpcuser and rpcpassword) would be for the trusted account, just like today.  Another approach would be to leave the current values as the public info, and make trusted values, but this would break everything.  Purely informational calls would require that the user authenticate using any of the three.  Calls that could be annoying, but not dangerous, like settxrelayfee, would be public or trusted.  Calls that could be dangerous, like sendtoaddress, would require the trusted account.  Anyone want a relatively simple project to learn bitcoin development with?

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
nikkisnowe
Member
**
Offline Offline

Activity: 105
Merit: 10


View Profile
May 06, 2013, 06:43:37 PM
 #78

I don't care what you think.  This is regulation plain and simple.  This is not what I was led to believe bitcoin was.  If bitcoin can't handle itself then another coin should take it's place.  END OF STORY.
Why didn't you complain when 0.00000000 outputs were made non-standard in the same way some versions ago?  Same problem, same reason to make them non-standard.  Spendable, but only in theory because it doesn't make sense to pay fees to spend them.  You can still send the transactions, and evil miners may mine them just like other dust creating transactions.  I don't want them in the blockchain, so I won't help you relaying or mining them.  That's my choice.  You can't force me to, just as I can't force you to stop behaving badly.

Cause it was your option to pay the fees, miner still had to include them and relays still had to relay. Was that big of a deal to be honest. This is completely censoring.

Hey Gweedo,
Sorry for being the English police, but do you understand the difference between the words "cause" and "because"?  While your arguments might have merit, you discredit yourself  with  your shitty adolescent understanding of basic grammar.
gweedo
Legendary
*
Offline Offline

Activity: 1498
Merit: 1000


View Profile
May 06, 2013, 06:48:50 PM
 #79

I don't care what you think.  This is regulation plain and simple.  This is not what I was led to believe bitcoin was.  If bitcoin can't handle itself then another coin should take it's place.  END OF STORY.
Why didn't you complain when 0.00000000 outputs were made non-standard in the same way some versions ago?  Same problem, same reason to make them non-standard.  Spendable, but only in theory because it doesn't make sense to pay fees to spend them.  You can still send the transactions, and evil miners may mine them just like other dust creating transactions.  I don't want them in the blockchain, so I won't help you relaying or mining them.  That's my choice.  You can't force me to, just as I can't force you to stop behaving badly.

Cause it was your option to pay the fees, miner still had to include them and relays still had to relay. Was that big of a deal to be honest. This is completely censoring.

Hey Gweedo,
Sorry for being the English police, but do you understand the difference between the words "cause" and "because"?  While your arguments might have merit, you discredit yourself  with  your shitty adolescent understanding of basic grammar.

Yes I do, I was writing this at 2:30am, so I doubt anyone's grammer is of a high level scholar at that time. But what does this have to do with my views, I feel this is so off-topic and actually discredits you since, your attacking that, when the basic views I have talked about many times, and the people that need to understand, understood it.
nikkisnowe
Member
**
Offline Offline

Activity: 105
Merit: 10


View Profile
May 06, 2013, 07:01:01 PM
 #80

You're attempting convince others in this forum to believe in the arguments you're presenting.  Nobody is going to take you seriously when you present your arguments like a 15 year old girl texting her friends.  Simply review your response to me.  Who is going to take your views, versus the developers, regarding the changes to the bitcoin protocol seriously when you can't formulate a proper sentence.
Pages: « 1 2 3 [4] 5 6 7 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!