Bitcoin Forum
December 06, 2016, 06:06:54 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 [7] 8 »  All
  Print  
Author Topic: Huge increase in satoshidice spam over the past day  (Read 7785 times)
fireduck
Sr. Member
****
Offline Offline

Activity: 366



View Profile
June 14, 2012, 10:00:08 PM
 #121


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.

They seem to be using a % fee.. bigger transactions take bigger fees.  This win  as an example.. 0.01 on the bet, >1btc on the payout.


It is actually max(0.0005, (ins + outs) * 0.000075) so is fairly stupid but is higher for larger transactions.

Code is here: http://code.google.com/r/fireduck-magicpony/source/browse/core/src/main/java/com/google/bitcoin/core/FeeFinderCounting.java

1481047614
Hero Member
*
Offline Offline

Posts: 1481047614

View Profile Personal Message (Offline)

Ignore
1481047614
Reply with quote  #2

1481047614
Report to moderator
1481047614
Hero Member
*
Offline Offline

Posts: 1481047614

View Profile Personal Message (Offline)

Ignore
1481047614
Reply with quote  #2

1481047614
Report to moderator
1481047614
Hero Member
*
Offline Offline

Posts: 1481047614

View Profile Personal Message (Offline)

Ignore
1481047614
Reply with quote  #2

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

Posts: 1481047614

View Profile Personal Message (Offline)

Ignore
1481047614
Reply with quote  #2

1481047614
Report to moderator
1481047614
Hero Member
*
Offline Offline

Posts: 1481047614

View Profile Personal Message (Offline)

Ignore
1481047614
Reply with quote  #2

1481047614
Report to moderator
1481047614
Hero Member
*
Offline Offline

Posts: 1481047614

View Profile Personal Message (Offline)

Ignore
1481047614
Reply with quote  #2

1481047614
Report to moderator
interlagos
Hero Member
*****
Offline Offline

Activity: 497


View Profile
June 14, 2012, 10:09:41 PM
 #122

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 Smiley
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
Hero Member
*****
expert
Offline Offline

Activity: 751


View Profile
June 14, 2012, 10:26:05 PM
 #123


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.

Bitcoin Ubuntu PPA maintainer - donate to me personally: 1JBMattRztKDF2KRS3vhjJXA7h47NEsn2c
http://bitcoinrelaynetwork.org maintainer
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
Maged
Legendary
*
Offline Offline

Activity: 1260


View Profile
June 14, 2012, 10:31:38 PM
 #124

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
Hero Member
*****
expert
Offline Offline

Activity: 751


View Profile
June 14, 2012, 10:34:13 PM
 #125

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.

Bitcoin Ubuntu PPA maintainer - donate to me personally: 1JBMattRztKDF2KRS3vhjJXA7h47NEsn2c
http://bitcoinrelaynetwork.org maintainer
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
wachtwoord
Legendary
*
Offline Offline

Activity: 1484



View Profile WWW
June 14, 2012, 10:53:27 PM
 #126

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 Offline

Activity: 1260


View Profile
June 14, 2012, 11:03:49 PM
 #127

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
Hero Member
*****
expert
Offline Offline

Activity: 751


View Profile
June 14, 2012, 11:06:05 PM
 #128

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.

Bitcoin Ubuntu PPA maintainer - donate to me personally: 1JBMattRztKDF2KRS3vhjJXA7h47NEsn2c
http://bitcoinrelaynetwork.org maintainer
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
interlagos
Hero Member
*****
Offline Offline

Activity: 497


View Profile
June 14, 2012, 11:16:45 PM
 #129

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
Sr. Member
****
Offline Offline

Activity: 434



View Profile
June 14, 2012, 11:20:22 PM
 #130

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
Hero Member
*****
Offline Offline

Activity: 497


View Profile
June 14, 2012, 11:24:29 PM
 #131

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
Sr. Member
****
Offline Offline

Activity: 283



View Profile
June 14, 2012, 11:57:12 PM
 #132

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 Offline

Activity: 1442



View Profile
June 15, 2012, 12:13:27 AM
 #133

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
Hero Member
*****
expert
Offline Offline

Activity: 751


View Profile
June 15, 2012, 12:14:30 AM
 #134

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.  

Bitcoin Ubuntu PPA maintainer - donate to me personally: 1JBMattRztKDF2KRS3vhjJXA7h47NEsn2c
http://bitcoinrelaynetwork.org maintainer
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
Matt Corallo
Hero Member
*****
expert
Offline Offline

Activity: 751


View Profile
June 15, 2012, 12:19:00 AM
 #135

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.

Bitcoin Ubuntu PPA maintainer - donate to me personally: 1JBMattRztKDF2KRS3vhjJXA7h47NEsn2c
http://bitcoinrelaynetwork.org maintainer
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
Raoul Duke
aka psy
Legendary
*
Offline Offline

Activity: 1442



View Profile
June 15, 2012, 12:25:51 AM
 #136

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
Hero Member
*****
expert
Offline Offline

Activity: 751


View Profile
June 15, 2012, 12:28:08 AM
 #137

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).

Bitcoin Ubuntu PPA maintainer - donate to me personally: 1JBMattRztKDF2KRS3vhjJXA7h47NEsn2c
http://bitcoinrelaynetwork.org maintainer
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
interlagos
Hero Member
*****
Offline Offline

Activity: 497


View Profile
June 15, 2012, 12:33:34 AM
 #138

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 Offline

Activity: 1442



View Profile
June 15, 2012, 12:36:39 AM
 #139

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
Hero Member
*****
Offline Offline

Activity: 819


View Profile
June 15, 2012, 01:13:28 AM
 #140

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?

Cheap and sexy Bitcoin card/hardware wallet, buy here:
http://BlochsTech.com
Pages: « 1 2 3 4 5 6 [7] 8 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!