Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 13, 2013, 05:13:06 PM |
|
People on IRC also claim that SD gambles against themselves to build their Most Popular Bitcoin Gambling Website brand, which would also bloat the blockchain, but there is no way of proving or disproving that rumor. Well, if you ask around, there is surprisingly few people who actually play SD...
|
|
|
|
HighInBC
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 85
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 13, 2013, 05:17:09 PM |
|
Are we really going to go down the road of deciding who can and cannot use bitcoin?
Any solution should be agnostic of specific vendors. The problem is not SD, how the hell is bitcoin going to scale to meet massive use if we can't handle a single company?
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 13, 2013, 05:20:22 PM |
|
Are we really going to go down the road of deciding who can and cannot use bitcoin?
Any solution should be agnostic of specific vendors. The problem is not SD, how the hell is bitcoin going to scale to meet massive use if we can't handle a single company?
A vendor-specific solution is better than no solution at all. It buys us time to figure out a better solution. And worst case scenario, this problem is short-term anyway - the risk goes away when bitcoin adoption is sufficient to handle it.
|
|
|
|
HorseRider
Donator
Legendary
Offline
Activity: 1120
Merit: 1001
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 13, 2013, 05:24:56 PM |
|
People on IRC also claim that SD gambles against themselves to build their Most Popular Bitcoin Gambling Website brand, which would also bloat the blockchain, but there is no way of proving or disproving that rumor. Well, if you ask around, there is surprisingly few people who actually play SD... I know a local gambler who has write his own script to gamble on SD at thousands of bets per day, as he believes that his script can win money. He once tried to raise a venture capital fund to gamble with SD.....(Of course, a single example cannot disprove that rumor. )
|
16SvwJtQET7mkHZFFbJpgPaDA1Pxtmbm5P
|
|
|
HighInBC
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 85
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 13, 2013, 05:29:40 PM |
|
I know a local gambler who has write his own script to gamble on SD at thousands of bets per day, as he believes that his script can win money. He once tried to raise a venture capital fund to gamble with SD.....(Of course, a single example cannot disprove that rumor. )
Does this person not understand the concept of the odd being stacked towards the house?
|
|
|
|
phatsphere
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 13, 2013, 05:36:30 PM |
|
i haven't read everything, but for now there are a few things granted: miners can do what they want, and they cannot be banned. it's decentralized - period. second, i think we should start thinking more about how to structure the fees. fee must be smaller than the transacted amount, and be at least of 0.1%? additionally, add a certain penalty amount, if you send it to a new address… also, the fee should weight in how old are the past tx out and the general size of the TX. there is a lot to experiment! S.D. is just enabling this discussion. I hope something useful will come out of this and the fee has the right incentives to secure bitcoins scalability.
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 13, 2013, 05:53:45 PM |
|
fee must be smaller than the transacted amount, and be at least of 0.1%? You can't know how much was transacted unless you're the sender. additionally, add a certain penalty amount, if you send it to a new address… All transactions should be going to new addresses! If anything, we should penalize address reuse. also, the fee should weight in how old are the past tx out and the general size of the TX. Already does.
|
|
|
|
HighInBC
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 85
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 13, 2013, 06:27:21 PM |
|
... All transactions should be going to new addresses! If anything, we should penalize address reuse. ...
Nonsense. Address reuse is perfectly valid. When I spend from a paper wallet I send the change back to the same place. I sign the transaction on an offline computer using electrum, then publish it on another. I would have to constantly be printing out change wallets if I did not send the change back. How exactly is address reuse an issue to anyone?
|
|
|
|
knightmb
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 13, 2013, 06:42:04 PM |
|
Are we really going to go down the road of deciding who can and cannot use bitcoin?
Any solution should be agnostic of specific vendors. The problem is not SD, how the hell is bitcoin going to scale to meet massive use if we can't handle a single company?
+1, Bitcoin is a set of rules and as long as your follow the rules, no one should be allowed to pass judgement on how others use it. Unless the rules are changed to combat perceived problems, such as the micro-transactions that SD brings up, everyone is complaining about the problem and not offering up any solutions and thus will never solve the perceived problem. There is no such thing as a technical solution to a social problem. ![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif)
|
Timekoin - The World's Most Energy Efficient Encrypted Digital Currency
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 13, 2013, 07:45:20 PM |
|
... All transactions should be going to new addresses! If anything, we should penalize address reuse. ...
Nonsense. Address reuse is perfectly valid. When I spend from a paper wallet I send the change back to the same place. I sign the transaction on an offline computer using electrum, then publish it on another. I would have to constantly be printing out change wallets if I did not send the change back. How exactly is address reuse an issue to anyone? It compromises the network's privacy (not just your own!). Basic privacy is pretty important when it comes to finances. Additionally, when we upgrade to post-quantum cryptography, reusing an address will likely allow people to compromise your wallet - possibly even other addresses in it (though I'm not so sure on this last bit). Bitcoin is a set of rules and as long as your follow the rules, no one should be allowed to pass judgement on how others use it. Unless the rules are changed to combat perceived problems, such as the micro-transactions that SD brings up, everyone is complaining about the problem and not offering up any solutions and thus will never solve the perceived problem. There is no such thing as a technical solution to a social problem. ![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif) Flooding is a social problem, and that is why Bitcoin uses a social solution (miners who are supposed to filter it). Nobody is "passing judgement" on SD (or maybe someone is, but it's unrelated to this) for being gambling or anything like that. Enabling flooding is simply not possible.
|
|
|
|
solex
Legendary
Offline
Activity: 1078
Merit: 1006
100 satoshis -> ISO code
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 13, 2013, 09:30:29 PM |
|
Nobody is "passing judgement" on SD (or maybe someone is, but it's unrelated to this) for being gambling or anything like that. Enabling flooding is simply not possible.
I agree. SD's business model best runs without internalizing transactions, unlike Coinbase or Mt. Gox, who do internalize. The problem is that SD's model is scalable much faster than the Bitcoin network's capability. SD usage could scale 10x while the network capability might only double in that time. SD brings in a lot of fees, and is "stress-testing" Bitcoin, and highlights the risk of a flooding attack. All these are beneficial to have or know. I did suggest blocking SD yesterday and got criticism for it. I accept that and withdraw that idea. My earlier suggestion stands: which is for fees to somehow rise exponentially for flooding sources on a per block basis. It seems possible to do this, but perhaps it isn't.
|
|
|
|
justusranvier
Legendary
Offline
Activity: 1400
Merit: 1013
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 13, 2013, 09:36:43 PM |
|
The problem is that SD's model is scalable much faster than the Bitcoin network's capability. SD usage could scale 10x while the network capability might only double in that time. This is an artifact of the extremely low transaction volume that makes fees negligible compared to the block subsidy. The network will be more sustainable when the volume is high enough that transaction fees match the block reward because from that point on increase volume will directly translate in the increased revenue for the miners to pay for the necessary capacity.
|
|
|
|
solex
Legendary
Offline
Activity: 1078
Merit: 1006
100 satoshis -> ISO code
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 14, 2013, 12:59:59 AM Last edit: March 14, 2013, 05:39:31 AM by solex |
|
The problem is that SD's model is scalable much faster than the Bitcoin network's capability. SD usage could scale 10x while the network capability might only double in that time. This is an artifact of the extremely low transaction volume that makes fees negligible compared to the block subsidy. The network will be more sustainable when the volume is high enough that transaction fees match the block reward because from that point on increase volume will directly translate in the increased revenue for the miners to pay for the necessary capacity. Fair enough. Then, what is the path to get smoothly to that future? There is no proper fees market for block access at present because fees average <5% of the block reward. A 1MB block accommodates about 2400 transactions (ignoring many inputs/outputs possible). With the block reward about $1150 it means an average fee of $0.48 is required to match the reward in value. Is there a consensus on a "reasonable" fee for a vanilla Bitcoin transaction? Is it closer to 5c than 0.5c or 50c? Probably. So the fees market for block space becomes viable when 10MB blocks are common. This is a while off. Until that time SD (and anything with a similar business model) can flood the network, unless these apps are throttled at the discretion of their owners.
|
|
|
|
justusranvier
Legendary
Offline
Activity: 1400
Merit: 1013
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 14, 2013, 01:13:17 AM |
|
Fair enough. Then, what is the path to get smoothly to that future?
There is no proper fees market for block access at present because fees average <5% of the block reward. A 1Mb block accommodates about 2400 transactions (ignoring many inputs/outputs possible). With the block reward about $1150 it means an average fee of $0.48 is required to match the reward in value. Is there a consensus on a "reasonable" fee for a vanilla Bitcoin transaction? Is it closer to 5c than 0.5c or 50c? Probably. So the fees market for block space becomes viable when 10Mb blocks are common. Ideally replace the hard block limit with an algorithm like time-to-verify, but at least get it 10 MiB so that it's possible to reach the transaction rates that create a fees market. Rely on the block reward, aided by increases in the exchange rate, to subsidize miners while they gradually start mining larger blocks and fund development of protocol optimizations that reduce the resources needed to run at high transaction rates to reduce the burden on full non-mining nodes. This is a while off. It can happen faster than you think. I don't think BitPay, Coinbase, and BIPS are going to slow down the rate they try to sign up new businesses, nor do I expect the growth in new users to slow down. Repeated success causes a snowball effect, and humans are notoriously bad an intuitively estimating exponential growth. Also keep in mind there are plenty of countries where Bitcoin is still completely unknown. The Chinese and Indians are going to want to be able to make transactions on the blockchain too.
|
|
|
|
astutiumRob
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 14, 2013, 02:16:17 AM |
|
Are we really going to go down the road of deciding who can and cannot use bitcoin?
I recently moved to a new laptop following a fatal hardware issue. Install bitcoin, started d/loading the block chain over 2 _days_ later I was sync'd again. Knowing in excess of 80% of that is SD when it's not a service I use or care about is annoying. Now scale that up to more common acceptance of bitcoin - and people wont bother There are only 2 solutions to ease adoption # initial blockchain d/load has to be better handled, like a set of "hubs" with everything to X date in a single downloadable file - with the appropraite hashing/cross-checks to other "hubs" # limitation of the blockchain to what needs to be in it - servcies like SD woudl work perfectly as well with an "account" based system like every other gambling site - this benefits them - people leave their money in the gambling site(s) rather than constantly withdrawing it - means more of it to gamble - this benefits everyone else - as it will limit the number of "public" broadcast transactions Win-Win as they say. The problem is not SD, how the hell is bitcoin going to scale to meet massive use if we can't handle a single company?
Coins change hands many many times before loss/destruction/sitting in a jar forever. This _should_ be no different for bitcoin Sadly the current system is equivalent to everyone having to carry about a photograph of every coin ever exchanged - there are of course benefits - but it's also a problem.
|
|
|
|
ShireSilver
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 14, 2013, 02:36:45 AM |
|
I recently moved to a new laptop following a fatal hardware issue. Install bitcoin, started d/loading the block chain over 2 _days_ later I was sync'd again.
Well, there's your problem. Install Electrum instead. Problem solved. Knowing in excess of 80% of that is SD when it's not a service I use or care about is annoying.
Most of the bitcoin uses out there that other people are using aren't ones that I use or care about. Should I be whining about them? There are only 2 solutions to ease adoption # initial blockchain d/load has to be better handled, like a set of "hubs" with everything to X date in a single downloadable file - with the appropraite hashing/cross-checks to other "hubs" # limitation of the blockchain to what needs to be in it - servcies like SD woudl work perfectly as well with an "account" based system like every other gambling site - this benefits them - people leave their money in the gambling site(s) rather than constantly withdrawing it - means more of it to gamble - this benefits everyone else - as it will limit the number of "public" broadcast transactions
Saying "there are only two solutions" is usually done when there *are* more than 2 solutions but the speaker doesn't want any other solutions to be considered. In other words it is a con job. But I would point out that your proposed solution 1 already exists - see Electrum. Satoshi Dice would not work if you had to have an account. That's its whole point, that you don't need an account. You're asking for a system where it works like 1) insert coin in machine 2) pull lever 3) get results, win or lose 4) repeat 1-3 at will to change to one where it works like 1 ) go to a cashier 2 ) exchange some coins of one type for coins of another type 3 ) go to machine 4 ) insert coin into machine 5 ) pull lever 6 ) get results, win or lose 7 ) repeat 4-6 at will until coins are gone or done 8 ) if wanting to continue play, go to 1 9 ) go to cashier 10) exchange coins of one type for coins of another type and that is clearly retarded.
|
|
|
|
misterbigg
Legendary
Offline
Activity: 1064
Merit: 1001
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 14, 2013, 03:53:49 AM |
|
The problem is that SD's model is scalable much faster than the Bitcoin network's capability. SD usage could scale 10x while the network capability might only double in that time. This is an artifact of the extremely low transaction volume that makes fees negligible compared to the block subsidy. The network will be more sustainable when the volume is high enough that transaction fees match the block reward because from that point on increase volume will directly translate in the increased revenue for the miners to pay for the necessary capacity. An obvious solution presents itself: Lower the hard limit on maximum block size to 200KB, and put it on a slowly increasing schedule back to 1 megabyte over the next two years! ![Grin](https://bitcointalk.org/Smileys/default/grin.gif)
|
|
|
|
TraderTimm
Legendary
Offline
Activity: 2408
Merit: 1121
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 19, 2013, 12:00:59 AM |
|
A fun infographic for new and old users of bitcoin alike: "The blockchain is a shared resource... Won't you help to prevent abuse?"https://docs.google.com/file/d/0BzdbolIn7zf1dEhJNmZYX0VpVTQ/edit?usp=sharing ~1.04 MB - 1024 x 2048 Larger sizes available upon request, share with whoever you like. (The preview on Google Drive makes it look pixelated, but I assure you the original is razor-sharp vector graphics.)
|
fortitudinem multis - catenum regit omnia
|
|
|
hardcore-fs
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 19, 2013, 12:22:46 AM |
|
A far easier way would be to introduce a 'mix' filter, so that 'low value' transactions can take up no more than '%' of a block, backlog them, they will soon reduce them down. Or 'boundary' them, I.E bitcoins between a certain value get delayed a given number of days, before there is an attempt to stuff them in the block.
|
BTC:1PCTzvkZUFuUF7DA6aMEVjBUUp35wN5JtF
|
|
|
Smoovious
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 19, 2013, 12:44:15 AM |
|
A far easier way would be to introduce a 'mix' filter, so that 'low value' transactions can take up no more than '%' of a block, backlog them, they will soon reduce them down. Or 'boundary' them, I.E bitcoins between a certain value get delayed a given number of days, before there is an attempt to stuff them in the block.
:facepalm: Ya know... it is these stupid artificial games played by people who want to control the money supply which sparked the existence of Bitcoin in the first place! Leave it alone. The transaction fee/priority system works. Stop trying to fiddle with it and LET IT WORK. We've become too complacent with the change to reduce transaction fees in the first place, which never should have been done. Now people will have to include reasonable fees again. GOOD! -- Smoov
|
|
|
|
|