Pages:
Author

Topic: Bitcoin 0.8.2. What do you think? - page 6. (Read 17081 times)

hero member
Activity: 900
Merit: 1014
advocate of a cryptographic attack on the globe
May 05, 2013, 11:38:23 PM
#35
Good idea, I mean, if I send you 1 satoshi, with the fee structure we're using right now you cannot spend that 1 satoshi (0.0005BTC fee), so I loose 1 satoshi, you get nothing and the blockchain gets bloated. Its a no brainer, well at least until we have a proper fee structure in lace

This.

Worse it bloats the UXTO which puts unecessary load on all full nodes for absolutley not reason.  Nobody is going to spend 1/10 of a cent if it costs 5x as much to spend it.  Nobody so the current rules allow the creation of tx (at no cost) which produce outputs which will "never" (or highly unlikely) to be spent. 

Another way to look at it.  Over 50% of the pruned database consists of tx below the min fee threshold.  Outputs that very likely will never be spent.  Had this rule been in place since the beginning the pruned database would be half the size right now. 

The pruned (not full but pruned) database is the bottleneck to scalability.  The current fee rules don't properly account for the creation of tx which have a "lasting cost".  This rule improves that.

+1

The scare thread in the bitcoin discussion forum was a troll from the start. I had posted a thread with a technical sounding topic in the technical forum a few days prior as I had a legitimate question and didn't want to cause a panic. (I wasn't sure I understood the change.) I think I mentioned ASICMINER in it which is a concern I had -- the troll picked up on that too as he mentioned ASICMINER payouts in his original post. It's unlikely someone would mention that IMO. So all this panic is for naught. The change is worthwhile. (Although it would be good for devs to post announcements about changes in the development forum... or if these forums are too mob-like then at least an announcement should be made that such announcements will NOT be made in these forums and instead to check a specific mailing list). I just happen to watch github because I love bitcoin Cheesy
legendary
Activity: 4298
Merit: 3209
May 05, 2013, 11:27:53 PM
#34
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.

Do you think that we should have a vote, and then force (by some means) Gavin to implement what the majority votes for? Or perhaps do you think that we should have elections for lead developer and vote based on the person's campaign? That sounds like a centralized currency to me. Is that what you really want? How would you solve this controversy and others like it?

I think that if you don't like his software, all you have to do is come up with competing software and show enough people how much better it is. If enough people choose your software, then Gavin's software becomes irrelevant.
legendary
Activity: 1400
Merit: 1009
May 05, 2013, 11:25:08 PM
#33
Once this change goes through an a super majority is using 0.82 I would like to see a "loophole" to the min-fee rules of low priority tx which makes low-priority tx that REDUCE the UXTO exempt.
If a transaction reduces the UTXO set by n outputs, then calculate an effective transaction fee for relaying decision purposes equal to the actual transaction fee + n*minimum fee.
staff
Activity: 4172
Merit: 8419
May 05, 2013, 11:23:42 PM
#32
Kind of a bummer that the poll is a bit misleading—  they're not mined and relayed by default, but miners can still include them. Is that "block"ed?  The value is configurable, so if in two weeks the value of Bitcoin rises and 1 BTC buys an airplane, people can just turn the knob— no need for a new version. etc.
sr. member
Activity: 322
Merit: 250
May 05, 2013, 11:10:08 PM
#31
The majority is speaking... too bad Gavin is sold out to the FEDS.  He has no interest in what the majority wants.

This is the death of btc if this happens... mark my words.

I will mark your words.  This isn't the death of anything.  It prevents the creation of outputs which are unecomical to spend.  Thus they are never spent and remain in the UXTO forever.  This bloats the UXTO.  Current rules don't distinguish between tx which are likely to be respent and tx which are unlikely to be respent.  Tx smaller than the min fee on low priority tx are not being spent.  The blockchain shows that is true, they make no sense to spend them (because generally it costs more to spend them then they are worth).  This rule merely prevents the creation of tx outputs which will never be spent.

The UXTO is the key bottleneck.  Even pruned full nodes need to maintain the UXTO forever.  For fast verification the UXTO will need to be kept into memory.  "Normal" tx tend to be respent A->B->C thus while they increase the size of the unpruned db they don't increase the size of the UXTO.  Without this rule (or something similar) the cost to run a full node will increase exponentially just so people can produce unspendable txs.


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.
donator
Activity: 1218
Merit: 1079
Gerald Davis
May 05, 2013, 11:08:21 PM
#30
There has got to be a better solution.

Like?

It's not like we could actually spend these outputs before, they were always/still are unspendable. Why should we have unspendable BTC? It makes sense to block them for now. Miner's ultimately decide what tx fees we have to pay, years down the line maybe the fees will be low enough in order to allow spending of these pico-transactions.

Once this change goes through an a super majority is using 0.82 I would like to see a "loophole" to the min-fee rules of low priority tx which makes low-priority tx that REDUCE the UXTO exempt.  This would allow cleaning up the pruned blockchain.  In periods where tx volume is low clients could combined large numbers of dust-spam into a single larger output.  Everyone benefits.  Miners benefit because the memory requirements for full nodes are reduced,  users with "fragmented wallets" benefit because they can "defrag" in an economical manner.  Allowing this loophole combined with blocking (at the client level) tx below dust threshold will make the network more robust.

The dust threshold can be reduced (just like min-tx fee on low priority txs has been reduced twice) to keep dust truly dust (i.e. uneconomical spam garbage).
donator
Activity: 1218
Merit: 1079
Gerald Davis
May 05, 2013, 11:04:24 PM
#29
The majority is speaking... too bad Gavin is sold out to the FEDS.  He has no interest in what the majority wants.

This is the death of btc if this happens... mark my words.

I will mark your words.  This isn't the death of anything.  It prevents the creation of outputs which are unecomical to spend.  Thus they are never spent and remain in the UXTO forever.  This bloats the UXTO.  Current rules don't distinguish between tx which are likely to be respent and tx which are unlikely to be respent.  Tx smaller than the min fee on low priority tx are not being spent.  The blockchain shows that is true, they make no sense to spend them (because generally it costs more to spend them then they are worth).  This rule merely prevents the creation of tx outputs which will never be spent.

The UXTO is the key bottleneck.  Even pruned full nodes need to maintain the UXTO forever.  For fast verification the UXTO will need to be kept into memory.  "Normal" tx tend to be respent A->B->C thus while they increase the size of the unpruned db they don't increase the size of the UXTO.  Without this rule (or something similar) the cost to run a full node will increase exponentially just so people can produce unspendable txs.
legendary
Activity: 4592
Merit: 1276
May 05, 2013, 11:03:58 PM
#28
The majority is speaking... too bad Gavin is sold out to the FEDS.  He has no interest in what the majority wants.

This is the death of btc if this happens... mark my words.

It's an unfortunate but genuine truism that 'the majority' are fucking idiots.  I hate to be blunt about it but there is ample evidence.  As an example, reading into things that this action somehow indicates that Gavin, or anyone else, "sold out to the FEDS."

donator
Activity: 1218
Merit: 1079
Gerald Davis
May 05, 2013, 11:00:46 PM
#27
Good idea, I mean, if I send you 1 satoshi, with the fee structure we're using right now you cannot spend that 1 satoshi (0.0005BTC fee), so I loose 1 satoshi, you get nothing and the blockchain gets bloated. Its a no brainer, well at least until we have a proper fee structure in lace

This.

Worse it bloats the UXTO which puts unecessary load on all full nodes for absolutley not reason.  Nobody is going to spend 1/10 of a cent if it costs 5x as much to spend it.  Nobody so the current rules allow the creation of tx (at no cost) which produce outputs which will "never" (or highly unlikely) to be spent. 

Another way to look at it.  Over 50% of the pruned database consists of tx below the min fee threshold.  Outputs that very likely will never be spent.  Had this rule been in place since the beginning the pruned database would be half the size right now. 

The pruned (not full but pruned) database is the bottleneck to scalability.  The current fee rules don't properly account for the creation of tx which have a "lasting cost".  This rule improves that.
sr. member
Activity: 322
Merit: 250
May 05, 2013, 10:54:38 PM
#26
The majority is speaking... too bad Gavin is sold out to the FEDS.  He has no interest in what the majority wants.

This is the death of btc if this happens... mark my words.
legendary
Activity: 4592
Merit: 1276
May 05, 2013, 10:53:12 PM
#25
What we need is someone forking the source code, with the only difference being the transaction limit, should be very easy to do.

I'll give 'bitcoin-legacy.org' to anyone or group who I feel is on the right track on things of this nature and can convince me that they have a chance.  Fair warning though, I feel that the best way forward is to

 - either force the minimum transaction value to a high number or let the following do the job.

 - keep the 1MB block size if not shrink it even further.

 - shit-can all but the most simplistic types of transactions and fully document them.  No 'c++ client defines behavior' BS.

hero member
Activity: 784
Merit: 1000
May 05, 2013, 10:22:26 PM
#24
What we need is someone forking the source code, with the only difference being the transaction limit, should be very easy to do.
legendary
Activity: 1437
Merit: 1002
https://bitmynt.no
May 05, 2013, 09:02:39 PM
#23
nothing  should be blocked, what should be done is strengthening the source code to allow the network to cope.
And switch to another *coin without the 1 MB block limit (this is a hard limit which is impossible to remove, in the same way that there can never be more than 21 million bitcoins) and no fees and by buying more disk and faster network and really fast CPUs to everyone.  Yeah.  Easy!  Because we need spamcoins!
legendary
Activity: 1456
Merit: 1009
Ad maiora!
May 05, 2013, 08:18:05 PM
#22
I don't understand how a self-respecting developer can seriously consider implementing such a horrible hack as a temporary solution.

You are being paid to develop Bitcoin, right? Then come up with a real solution, and not some half-baked, dirty quick fix....

Yeah im gonna have to tend to agree with this guy... There has got to be a better solution.

And this better solution is....?

(come on, guys, you are so smart)
+1 everybody shits on gavin, yet none of them are capable, or even willing to do his job. he's a volunteer, too, you know.

I used to sit on the board of a small non-profit (a community art gallery and workshop) it was incredible how many people, full of anger and hate, would not just criticism, but outright denounce, smear, and insult all of us on the board for any and all decisions we would work on as a group. I began offering the most vocal opponents a seat on the board, it was open to the public and all were welcome of course. NOT ONE STEPPED UP! seems like its a hell of a lot easier to tell someone how to do their job than actually take any responsibility yourself.

that's my 2 uBTC worth, its flying around in space somewhere if you want to pocket it.
hero member
Activity: 882
Merit: 1005
May 05, 2013, 08:03:17 PM
#21

They don't get paid a single satoshi to develop Bitcoin.

Except Gavin.

Oopsie, did not realize that was now the case.
legendary
Activity: 980
Merit: 1014
May 05, 2013, 08:01:41 PM
#20

They don't get paid a single satoshi to develop Bitcoin.

Except Gavin.
sr. member
Activity: 364
Merit: 250
May 05, 2013, 08:00:10 PM
#19
I don't understand how a self-respecting developer can seriously consider implementing such a horrible hack as a temporary solution.

You are being paid to develop Bitcoin, right? Then come up with a real solution, and not some half-baked, dirty quick fix....

Yeah im gonna have to tend to agree with this guy... There has got to be a better solution.

And this better solution is....

(come on, guys, you are so smart)

Maybe you could add another fee for every output below a certain limit (including some coin age magicz?)
Right now there are websites mass-sending single satoshis with send-many or something like this, so the current fee rules aren't appropiate.
hero member
Activity: 882
Merit: 1005
May 05, 2013, 07:58:59 PM
#18
There has got to be a better solution.

Like?

It's not like we could actually spend these outputs before, they were always/still are unspendable. Why should we have unspendable BTC? It makes sense to block them for now. Miner's ultimately decide what tx fees we have to pay, years down the line maybe the fees will be low enough in order to allow spending of these pico-transactions.
hero member
Activity: 602
Merit: 500
May 05, 2013, 07:55:55 PM
#17
I don't understand how a self-respecting developer can seriously consider implementing such a horrible hack as a temporary solution.

You are being paid to develop Bitcoin, right? Then come up with a real solution, and not some half-baked, dirty quick fix....

Yeah im gonna have to tend to agree with this guy... There has got to be a better solution.

And this better solution is....?

(come on, guys, you are so smart)
legendary
Activity: 1428
Merit: 1001
Okey Dokey Lokey
May 05, 2013, 07:51:33 PM
#16
I don't understand how a self-respecting developer can seriously consider implementing such a horrible hack as a temporary solution.

You are being paid to develop Bitcoin, right? Then come up with a real solution, and not some half-baked, dirty quick fix that has such a potential to harm Bitcoin.
Yeah im gonna have to tend to agree with this guy... There has got to be a better solution.
Pages:
Jump to: