|
|
|
|
|
|
|
|
|
|
|
It is a common myth that Bitcoin is ruled by a majority of miners. This is not true. Bitcoin miners "vote" on the ordering of transactions, but that's all they do. They can't vote to change the network rules.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
interlagos
|
 |
June 14, 2012, 10:09:41 PM |
|
However for the end user it might create certain complications under specific circumstances. Imagine Alice accumulated some amount of coins from her signature address on this forum. She then decided to make a few payments and go to the party, so she sent a few transactions all from the same address in a short amount of time: one to bitmit, one to her friend and one to her mother she promised long time ago, then she shut down her computer and went partying. Now with these rules in place (considering 1 tx from 1 address per block) her last two transactions were lost and she wouldn't figure this out until after she starts her computer again to re-broadcast them, which might take a few days or until her mother calls and asks where is the money  Yep. But thats why the actual tx/mempool is variable. I think 1 is probably too low for the reason you point out here. But I dont see many people needing more than 2-3 at maximum for any given use-case. A sane default, IMHO, would probably be around 3. I'm still concerned this will have more impact on legitimate users or small businesses who process their transactions manually than on high volume makers. New rules do not discourage the volume itself but using the same address in that volume. So the change seems to be targeted to the current implementation of SatoshiDice rather than being a more generic solution. Under new rules SatoshiDice will have to change that's for sure and there are two ways: 1) use sendmulti which is benevolent 2) use new addresses for each bet which is basically bypassing the new rule. They have already admitted that they want to be a good citizens and they will put efforts to implement sendmulti, so introducing new rules just for them (or rather against them) doesn't make much sense. On the other hand players which choose to be malevolent will simply bypass the new rule by using new addresses if they wish to. So is it really worth the time and effort, which otherwise could be spent on thinking about proper pruning solutions? |
|
|
|
|
|
Matt Corallo (OP)
|
|
June 14, 2012, 10:26:05 PM |
|
Well, if SD is doing 30k transactions a day, and paying a 0.0005 BTC fee on each one, that'd be an additional 15 BTC of fees for the network each day.
AFAIK SD only pays fees because of limitations in bitcoinj, not because they have to or want to. |
|
|
|
Maged
Legendary
 Offline
Activity: 1204
Merit: 1015
|
|
June 14, 2012, 10:31:38 PM |
|
How to solve this in 48 hours: release a client that requires a mandatory .01 BTC fee/transaction and get the major pools to use it. SD would be forced to change to sendmany, or fail within 2 days. It would also be a completely generic solution.
|
|
|
|
|
Matt Corallo (OP)
|
|
June 14, 2012, 10:34:13 PM |
|
How to solve this in 48 hours: release a client that requires a mandatory .01 BTC fee/transaction and get the major pools to use it. SD would be forced to change to sendmany, or fail within 2 days. It would also be a completely generic solution.
And it would also alienate a huge user-base which like bitcoin because of its 0 fees. |
|
|
|
wachtwoord
Legendary
Offline
Activity: 2324
Merit: 1125
|
|
June 14, 2012, 10:53:27 PM |
|
Don't do anything. When the system is failing (I doubt it will) miners will start to require ever increasing fees (hopefully proportional to the amount of the transaction, I have always hated minimum fees and still hope that will be removed) until a stable equilibrium is reached.
* In brackets are my personal opinions which are really quite irrelevant
|
|
|
|
|
Maged
Legendary
Offline
Activity: 1204
Merit: 1015
|
|
June 14, 2012, 11:03:49 PM |
|
How to solve this in 48 hours: release a client that requires a mandatory .01 BTC fee/transaction and get the major pools to use it. SD would be forced to change to sendmany, or fail within 2 days. It would also be a completely generic solution.
And it would also alienate a huge user-base which like bitcoin because of its 0 fees. So fuck 'em. 0 fees were never sustainable. That being said, one option is for miners to offer a webpage where you have to enter a captcha and a transaction id and it'll let that transaction through into that miner's next block for free. Even better, this could be installed into clients and any miner who wishes to trust that the captcha server isn't lying about the captcha being entered successfully can subscribe to that feed. It seems that the thing we're trying to discourage is automated transfers, and that would do that. |
|
|
|
|
Matt Corallo (OP)
|
|
June 14, 2012, 11:06:05 PM |
|
So fuck 'em. 0 fees were never sustainable.
The point of this thread is to get the same result entirely without fucking them. It seems that the thing we're trying to discourage is automated transfers, and that would do that.
Not at all. Im trying to discourage high transaction load generated by sites with low userbase compared to that load. |
|
|
|
|
interlagos
|
|
June 14, 2012, 11:16:45 PM |
|
It seems that the thing we're trying to discourage is automated transfers, and that would do that.
Not at all. Im trying to discourage high transaction load generated by sites with low userbase compared to that load. The userbase for SD seems to be proportional to the load they generate. Also will it affect MtGox if many users happen to withdraw from a single address in MtGox wallet? |
|
|
|
|
|
Frozenlock
|
|
June 14, 2012, 11:20:22 PM |
|
Clear you mind. Return to the point when you discovered Bitcoin with a
fresh mind. Got it? No more minor BIP-x or anything, just Bitcoin.
Now, what would be better for the network? 100 transactions a day, or
100 000 000?
How about 10 transactions?
Bitcoin needs *more* transactions, not less. Last year at the same time
there was even talks about how the block limit was way too large,
resulting in almost non-existent fees.
I agree we can want to find better ways to store the data, but getting
less transactions is not the goal. In fact, if Bitcoin is to be even
mildly successful, there will be a lot more.
|
|
|
|
|
|
interlagos
|
|
June 14, 2012, 11:24:29 PM |
|
I think the only reasonable way to encourage sendmulti is to make it cost less in terms of fees compared to doing it separately, which as I understand how it works already, no?
|
|
|
|
|
|
BoardGameCoin
|
|
June 14, 2012, 11:57:12 PM |
|
Bitcoin needs *more* transactions, not less.
Enough said. Delaying transactions for high-volume addresses will only cause cascading delays for senders/receivers to those addresses. This then has an adverse affect on user experience, potentially for the very service or cause new users came to bitcoin for. Additionally, we want to support an increasing velocity of money in the bitcoin economy, which currently is moving at a glacial pace, even with SD. Blockchain's cost per transaction shows that at current USD exchange rates, even with SD volume each transaction is costing the network $.75. Why are we spending so much time complaining about a growth that is truly moderate compared to what the network will need to support? Hell, I hope that within a few years there will be 100+ bitcoiners in every major city, and potentially even a few towns that use bitcoins for market day... If we can't restructure to handle the minor load of satoshi dice, how are we going to support that large but STILL MINOR increase in volume? Less *oh noes! lets keep us the bandwidths and disk spaces* and more preparing for the future.... we need a roadmap with a defined timeline and approach for blockchain pruning. We may even need a longer term plan for sharding, possibly via a tiered blockchain approach. I'm not sure what the solution is, but I am sure that one will be needed. -bgc |
I'm selling great Minion Games like The Manhattan Project, Kingdom of Solomon and Venture Forth at 4% off retail starting June 2012. PM me or go to my thread in the Marketplace if you're interested. For Settlers/Dominion/Carcassone etc., I do email gift cards on Amazon for a 5% fee. PM if you're interested. |
|
|
Raoul Duke
aka psy
Legendary
Offline
Activity: 1358
Merit: 1002
|
|
June 15, 2012, 12:13:27 AM |
|
I'm not trying to flame but what I've been thinking since this thread began is: lazy Bitcoin dev is lazy.
If developers think blockchain size is turning into a problem maybe the answer is you should start thinking about how to prune it, not how to reduce the amount of transactions.
It's in times like this that I wish I was smarter and could help, but unfortunately that's not the case.
PS: I'm very thankful to all the developers. If it wasn't for them I wouldn't be able to take part on a movement that will change how we perceive money forever.
|
|
|
|
|
|
Matt Corallo (OP)
|
|
June 15, 2012, 12:14:30 AM |
|
Bitcoin needs *more* transactions, not less.
Yep, the people complaining that their chain sync is taking too long are all wrong, they should be happy its slow. Don't get me wrong, I like natural growth, and I think it would be great if bitcoin's huge recent increase in chain size was all because we were getting new users or having increased liquidity in the market. But, sadly, thats not true. I think the only reasonable way to encourage sendmulti is to make it cost less in terms of fees compared to doing it separately, which as I understand how it works already, no?
Sadly the fees SatoshiDice pays are essentially nothing, so they dont really care. In fact, AFAIK, the only reason they pay the fees they do is because bitcoinj doesnt (yet) support calculating minimum relay fees the way the satoshi client does. |
|
|
|
|
Matt Corallo (OP)
|
|
June 15, 2012, 12:19:00 AM |
|
I'm not trying to flame but what I've been thinking since this thread began is: lazy Bitcoin dev is lazy.
If developers think blockchain size is turning into a problem maybe the answer is you should start thinking about how to prune it, not how to reduce the amount of transactions.
It's in times like this that I wish I was smarter and could help, but unfortunately that's not the case.
PS: I'm very thankful to all the developers. If it wasn't for them I wouldn't be able to take part on a movement that will change how we perceive money forever.
The issue is less of "there is a huge volume of transactions, oh no!!!" and more of "there are people in the community who, for whatever reason, are doing actions that are forcing other transactions into long confirmation time when their transactions dont really need confirmed immediately" so the solution is "lets give transaction-creators a way to say that their transactions are really lower priority than other 0-fee transactions and thus dont let their transactions force people who want to send money without paying not suffer as a result" additionally "lets tweak the incentive structure so that we further discourage bad actors in the community." Im not saying pruning isnt going to eventually be implemented, it probably will (in the form of shipping pruned chain snapshots), but in addition to that, there are things we can do to make it not as rough a transition right now. |
|
|
|
Raoul Duke
aka psy
Legendary
Offline
Activity: 1358
Merit: 1002
|
|
June 15, 2012, 12:25:51 AM |
|
OK. I will solve the first time users problem downloading the blockchain...
In the next 2 weeks I'll work on a page where everybody can order the blockchain in a medium of their preference and get it in the mail paying only 2% markup on the chosen medium price+shipping(Worldwide). DvD, HDD,USB flash disk, their choice. I'll get it and send it to them with the most recent blockchain snapshot possible.
This was something I've been thinking about for the last couple of months. Now is the time to do it, I guess.
|
|
|
|
|
|
Matt Corallo (OP)
|
|
June 15, 2012, 12:28:08 AM |
|
OK. I will solve the first time users problem downloading the blockchain...
In the next 2 weeks I'll work on a page where everybody can order the blockchain in a medium of their preference and get it in the mail paying only 2% markup on the chosen medium price+shipping(Worldwide). DvD, HDD,USB flash disk, their choice. I'll get it and send it to them with the most recent blockchain snapshot possible.
This was something I've been thinking about for the last couple of months. Now is the time to do it, I guess.
Any there goes all the excellent decentralized aspects of bitcoin. Its also easier to point people to eg. tcatm's chain snapshots (see below) and have them use -loadblock (only available in 0.6.99/0.7). |
|
|
|
|
interlagos
|
|
June 15, 2012, 12:33:34 AM
Last edit: June 15, 2012, 09:48:22 AM by interlagos |
|
Bitcoin needs *more* transactions, not less.
Yep, the people complaining that their chain sync is taking too long are all wrong, they should be happy its slow. Don't get me wrong, I like natural growth, and I think it would be great if bitcoin's huge recent increase in chain size was all because we were getting new users or having increased liquidity in the market. But, sadly, thats not true. Even if we prevent the blockchain from growing completely right now, it won't make the experience of those users any better, they would still need to download 180000+ blocks. Any attempts to "improve" things a little bit in the current design would probably be a waste of time.EDIT: If there are more efficient ways to download and parse the existing blockchain I'm all for that! |
|
|
|
|
Raoul Duke
aka psy
Legendary
Offline
Activity: 1358
Merit: 1002
|
|
June 15, 2012, 12:36:39 AM |
|
OK. I will solve the first time users problem downloading the blockchain...
In the next 2 weeks I'll work on a page where everybody can order the blockchain in a medium of their preference and get it in the mail paying only 2% markup on the chosen medium price+shipping(Worldwide). DvD, HDD,USB flash disk, their choice. I'll get it and send it to them with the most recent blockchain snapshot possible.
This was something I've been thinking about for the last couple of months. Now is the time to do it, I guess.
Any there goes all the excellent decentralized aspects of bitcoin. Its also easier to point people to eg. tcatm's chain snapshots (see below) and have them use -loadblock (only available in 0.6.99/0.7). That's easier when you are talking about 3 or 4 GB. When you think it will be 50 or 100 GB soon it makes sense to order an HDD with it. And as far as I know the client will check the blockchain validity when starting, no? Also, I'm not jealous. Any other guy is free to grab the idea and do it. I don't wish to be the only one doing it. It can get tiresome for almost no reward. |
|
|
|
|
|
Realpra
|
|
June 15, 2012, 01:13:28 AM |
|
This is all so wrong:
1. The current network is larger than what 5 super computers?
2. You can't handle an absolutely small amount of transactions?
3. Solution: Throttle BTC with fees/blocking/self-prioritizing txs?!?!
NONONONONONO!
This is a serious issue: The BTC network is not scaling AT ALL due to horrible design.
So was my idea with SPV nodes keeping balances documented with input/outputs viable or not?
That way they store a fraction of the chain, but can do everything a full node network can in swarm fashion?
|
|
|
|
|
