Matt Corallo (OP)
|
|
June 13, 2012, 11:21:47 PM Last edit: June 14, 2012, 12:00:38 AM by Matt Corallo |
|
Over the past ~24 hours, the number of satoshidice transactions has increased hugely, leading to transaction memory pools (currently) at around 9000 transactions. Satoshidice spam is already a huge % of current transactions, but now its just ridiculous. Is it time to start deprioritizing transactions which use very common addresses?
|
|
|
|
Maged
Legendary
Offline
Activity: 1204
Merit: 1015
|
|
June 13, 2012, 11:46:22 PM |
|
And we have set a new record for us today. We have had over 30,000 bets today and still a good chunk of an hour left in the day (GMT days).
Previous high was 19,000 on June 4th.
|
|
|
|
FreeMoney
Legendary
Offline
Activity: 1246
Merit: 1016
Strength in numbers
|
|
June 14, 2012, 12:18:35 AM |
|
SD pays a fee on all tx correct? What fee? Whatever it is x30000 seems meaningful.
|
Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
|
|
|
Matt Corallo (OP)
|
|
June 14, 2012, 12:26:27 AM |
|
Paying a meaningful fee to miners has no effect on the thousands and thousands of bitcoin users who have to store the transactions on their disk...
|
|
|
|
SgtSpike
Legendary
Offline
Activity: 1400
Merit: 1005
|
|
June 14, 2012, 12:27:52 AM |
|
No, it is not time to start deprioritizing anything. It is time to start prioritizing pruning of the blockchain.
|
|
|
|
Matt Corallo (OP)
|
|
June 14, 2012, 12:30:54 AM |
|
No, it is not time to start deprioritizing anything. It is time to start prioritizing pruning of the blockchain.
Sadly, chain pruning is by no means easy. Pruning the index of transactions (blkindex.dat) isnt hard, and is likely to be done in the next release or the release thereafter. However, pruning blk0001.dat really can't be done without making pretty significant changes to the way bitcoin downloads blocks.
|
|
|
|
SgtSpike
Legendary
Offline
Activity: 1400
Merit: 1005
|
|
June 14, 2012, 12:33:34 AM |
|
No, it is not time to start deprioritizing anything. It is time to start prioritizing pruning of the blockchain.
Sadly, chain pruning is by no means easy. Pruning the index of transactions (blkindex.dat) isnt hard, and is likely to be done in the next release or the release thereafter. However, pruning blk0001.dat really can't be done without making pretty significant changes to the way bitcoin downloads blocks. Best get started then!
|
|
|
|
Matt Corallo (OP)
|
|
June 14, 2012, 12:39:33 AM |
|
Best get started then! Sadly, the most realistic way of doing it involves shipping chain snapshots as a part of the client download. This introduces more trust in the decentralized network, which really isnt a good thing. Hence why people are not eager to start working on chain pruning: many users will reject it. Note that it also makes it very, very difficult for people to run old nodes (they wont sync properly), which in light of recent node statistic generation by luke, is looking like a very, very poor idea for network security. In any case, chain pruning isnt coming soon as doing it really isnt pretty and could result in some pretty bad things for the network as a whole.
|
|
|
|
SierraDooDah
Newbie
Offline
Activity: 23
Merit: 0
|
|
June 14, 2012, 12:44:31 AM |
|
Having the entire chain does more disservice than service to the bitcoin concept. I would think that only the unconfirmed transactions would be in the chain..and the ones that don't confirm after 96 hours should roll off as well. IMHO the chain should be used as a means to manage transactions and not as an audit trail.
Sierra
|
|
|
|
SgtSpike
Legendary
Offline
Activity: 1400
Merit: 1005
|
|
June 14, 2012, 12:46:00 AM |
|
All your sad posts are making me sad now.
I suppose then, the best thing to do is find out how the free market copes with an exponentially increasing blockchain size. It had to happen eventually anyway...
I suspect we'll see many more users move to a light client in the coming months. I already removed the full satoshi client from all of my computers except one, simply because it really does take a toll on the machine it is on.
|
|
|
|
Matt Corallo (OP)
|
|
June 14, 2012, 12:46:29 AM |
|
Having the entire chain does more disservice than service to the bitcoin concept. I would think that only the unconfirmed transactions would be in the chain..
That's the point of chain pruning, sadly chain pruning is only mostly feasible. and the ones that don't confirm after 96 hours should roll off as well.
So if you dont spend your coins in 96 hours you lose them? IMHO the chain should be used as a means to manage transactions and not as an audit trail.
Thats simply not the way bitcoin was designed.
|
|
|
|
SierraDooDah
Newbie
Offline
Activity: 23
Merit: 0
|
|
June 14, 2012, 12:48:09 AM |
|
"So if you dont spend your coins in 96 hours you lose them?"
I knew my statement leading up to that was an issue as soon as I walked away from my computer...
|
|
|
|
Matt Corallo (OP)
|
|
June 14, 2012, 12:52:06 AM |
|
All your sad posts are making me sad now.
I suppose then, the best thing to do is find out how the free market copes with an exponentially increasing blockchain size. It had to happen eventually anyway...
Bitcoin was actually doing fairly well and the chain size was only increasing at a moderate rate (largely DeepBit, which still refuses to use multisend, which would cut down on their volume by a ton) up until SatoshiDice. Realistically, if satoshidice employed more sane methods of operation (multisend would be very easy and would have a pretty large impact on pure transaction volume, but really they should allow users to carry balance and withdraw when they want, the way pretty much every other bitcoin site does it) they would have a relatively tiny impact on the chain compared to what they have now. The only reason the chain grows the way it does is because people like satoshi dice (and pretty much only satoshidice) refuse to put in an extra 10 minutes of coding time. I suspect we'll see many more users move to a light client in the coming months. I already removed the full satoshi client from all of my computers except one, simply because it really does take a toll on the machine it is on.
Running light nodes is the way the network is going anyway, and thats fine, but forcing everyone to do so purely because people are lazy and stupid is really poor.
|
|
|
|
SgtSpike
Legendary
Offline
Activity: 1400
Merit: 1005
|
|
June 14, 2012, 12:56:53 AM |
|
All your sad posts are making me sad now.
I suppose then, the best thing to do is find out how the free market copes with an exponentially increasing blockchain size. It had to happen eventually anyway...
Bitcoin was actually doing fairly well and the chain size was only increasing at a moderate rate (largely DeepBit, which still refuses to use multisend, which would cut down on their volume by a ton) up until SatoshiDice. Realistically, if satoshidice employed more sane methods of operation (multisend would be very easy and would have a pretty large impact on pure transaction volume, but really they should allow users to carry balance and withdraw when they want, the way pretty much every other bitcoin site does it) they would have a relatively tiny impact on the chain compared to what they have now. The only reason the chain grows the way it does is because people like satoshi dice (and pretty much only satoshidice) refuse to put in an extra 10 minutes of coding time. I suspect we'll see many more users move to a light client in the coming months. I already removed the full satoshi client from all of my computers except one, simply because it really does take a toll on the machine it is on.
Running light nodes is the way the network is going anyway, and thats fine, but forcing everyone to do so purely because people are lazy and stupid is really poor. Oh, come on, it's not forcing anybody! It only encourages them.
|
|
|
|
nedbert9
Sr. Member
Offline
Activity: 252
Merit: 250
Inactive
|
|
June 14, 2012, 12:59:14 AM |
|
All your sad posts are making me sad now.
I suppose then, the best thing to do is find out how the free market copes with an exponentially increasing blockchain size. It had to happen eventually anyway...
Bitcoin was actually doing fairly well and the chain size was only increasing at a moderate rate (largely DeepBit, which still refuses to use multisend, which would cut down on their volume by a ton) up until SatoshiDice. Realistically, if satoshidice employed more sane methods of operation (multisend would be very easy and would have a pretty large impact on pure transaction volume, but really they should allow users to carry balance and withdraw when they want, the way pretty much every other bitcoin site does it) they would have a relatively tiny impact on the chain compared to what they have now. The only reason the chain grows the way it does is because people like satoshi dice (and pretty much only satoshidice) refuse to put in an extra 10 minutes of coding time. I suspect we'll see many more users move to a light client in the coming months. I already removed the full satoshi client from all of my computers except one, simply because it really does take a toll on the machine it is on.
Running light nodes is the way the network is going anyway, and thats fine, but forcing everyone to do so purely because people are lazy and stupid is really poor. Matt, can you comment on the armory dev's proposal for chain pruning facilitated by an balance alt-chain?
|
|
|
|
Matt Corallo (OP)
|
|
June 14, 2012, 01:11:58 AM |
|
Matt, can you comment on the armory dev's proposal for chain pruning facilitated by an balance alt-chain?
I have to admit I havent spent a huge amount of time thinking about it, but its definitely an interesting concept. It does carry with it some of the issues of alienating old nodes which may have issues finding peers which have a full chain to give them, but I believe that is inherent in any chain-pruning method anyone has come up with so far. It does complicate bitcoin as a whole very greatly, forcing everyone to follow multiple chains (or...I cant think of a way to switch over to a new chain cleanly without hard-forking) and heavily complicating verifying the initial checking (probably ending up moving the initial download verification to the same trust-model as SPV nodes, which is ok, but not ideal). These complications only further the effort alt-client devs have to put in, which is already pretty huge and alt-clients are pretty important for the health of the network. In the end, I dont really see anyone jumping to implement it, so I dont see it happening any time soon, but if it does happen, it will provide some interesting new features.
|
|
|
|
Serith
|
|
June 14, 2012, 01:49:01 AM |
|
but really they should allow users to carry balance and withdraw when they want, the way pretty much every other bitcoin site does it) they would have a relatively tiny impact on the chain compared to what they have now. The only reason the chain grows the way it does is because people like satoshi dice (and pretty much only satoshidice) refuse to put in an extra 10 minutes of coding time.
There is an advantage in using blockchain such as transparency, anyone can verify how the site operates. EDIT:I never used Satoshi Dice, but I like the idea of honest lottery.
|
|
|
|
Matt Corallo (OP)
|
|
June 14, 2012, 01:51:14 AM |
|
There is an advantage in using blockchain such as transparency, anyone can verify how the site operates.
The same result can easily be achieved without forcing users to add at least 2 transactions per bet.
|
|
|
|
theymos
Administrator
Legendary
Offline
Activity: 5376
Merit: 13407
|
|
June 14, 2012, 02:12:33 AM |
|
It seems that Deepbit doesn't dynamically increase tx fees like the Satoshi client does. The Satoshi client would keep blocks at around 250 kB.
|
1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
|
|
|
etotheipi
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
June 14, 2012, 03:01:56 AM |
|
Matt, can you comment on the armory dev's proposal for chain pruning facilitated by an balance alt-chain?
I have to admit I havent spent a huge amount of time thinking about it, but its definitely an interesting concept. It does carry with it some of the issues of alienating old nodes which may have issues finding peers which have a full chain to give them, but I believe that is inherent in any chain-pruning method anyone has come up with so far. It does complicate bitcoin as a whole very greatly, forcing everyone to follow multiple chains (or...I cant think of a way to switch over to a new chain cleanly without hard-forking) and heavily complicating verifying the initial checking (probably ending up moving the initial download verification to the same trust-model as SPV nodes, which is ok, but not ideal). These complications only further the effort alt-client devs have to put in, which is already pretty huge and alt-clients are pretty important for the health of the network. In the end, I dont really see anyone jumping to implement it, so I dont see it happening any time soon, but if it does happen, it will provide some interesting new features. [For reference: the idea I proposed is a special blockchain pruning method that allows nodes to verifiably query any address balance with only a couple kB download -- and the pruned data would be maintained & enforced on a second/alternate blockchain using merged mining] Theoretically, the alt-chain created for this purpose is strictly optional. No one is "forced" to do anything -- they only use it if they want to participate in creating/exchanging/verifying/downloading address-balance information. One major benefit of the idea is how perfectly non-disruptive it is. I agree that it would be complex. But there's a lot of alt-chains already in existence that use merged mining, which probably provides 90% of the template that would be needed. I don't mean to imply that there's anything easy or quick about it... just that a lot of work has already been done. Otherwise, there's two options that both have serious downsides (compared to using an alt-chain). But maybe some brainstorming can resolve it: (1) Overlay network like what stratum is trying to do. Issue: requires some trust of other nodes, and malicious nodes can really muck up the network. (2) Modify the main blockchain, forcing block-headers to include a valid balance-tree hash to be accepted. Issue: requires a hard fork. However, there's a dozen other things that could go in as long as we're doing a hard-fork, anyway. If there's any inclination to believe it will have to be done at some point, earlier is better...
|
|
|
|
|