Topic: Huge increase in satoshidice spam over the past day - page 4. (Read 8789 times)

b) First, by definition short term solution is bad because the work to implement it would have to be thrown out the window soon enough.

The proposal isnt really that much of a short-term solution. It is designed to encourage users to not use more transactions than they need to. Though this is short-term for capping the chain, it should continue to drastically decrease overall chain volume even as that volume increases greatly.

After thinking about this for a while I actually now believe it might be a good idea even long term. Since there is only as many transactions than can be put in the block, the rules might need to be in place for which transaction to include.

The question is do you Matt have a good understanding how to implement this prioritization and how to enforce these rules. I get the impression that miners are the ones deciding what transactions to mine. Can the rules be enforced in the protocol?

Realpra

hero member

Activity: 815

Merit: 1000

Quote from: TangibleCryptography on June 14, 2012, 02:57:33 PM

Any short term solution implies that something it has to be done right now rather then later. Is the situation so dare that the proposal has to be implemented despite all the negatives? And do you think that the current problem is worth getting into regulating of how Bitcoin Network used?

I don't think it is that dire no.

If it was, fee rates would have shot through the roof and killed satoshidice.

What is needed is a long term and scalable solution to higher BTC volumes. Fees will kill spam just fine until then.

Quote from: Realpra on June 14, 2012, 02:55:01 PM

Could we change the nature of blocks so that payments are not made up of only transactions, but also balances?

Bad idea. The power of a 51% attack is limited to only tx denial and double spends. If balances are updated based on tx in most recent block without back validation a 51% attack (or even a minority attacker which can generate multiple blocks in a row) could mint an unlimited amount of fake coins.

Okay, how about this then:
1. The blockchain stays as is.
2. SPV nodes maintain knowledge of the balance of some addresses. They also maintain the documenting tx/block trail leading to this balance.
3. Invalid transactions can then be reported using this information (inputs).

Basically rather than storing chain links you would store chain strands?

The full block chain could then be constructed using strands, SPV nodes can verify and we have a 1-tier network!

Matt Corallo

hero member

Activity: 755

Merit: 515

Quote from: fireduck on June 14, 2012, 02:57:55 PM

Thank you for your careful and considered estimation of the time it will take to implement a feature in my code, which I am almost certain you have never seen. I will treasure it always.

I understand your code may be complicated and it may take time to implement a change to payout methods, but, again, multisend is a very simple change. In any case, I would argue it is a very important change as well that should be very heavily prioritized.

wachtwoord

legendary

Activity: 2324

Merit: 1125

Quote from: SgtSpike on June 14, 2012, 02:58:30 PM

Quote from: wachtwoord on June 14, 2012, 02:44:54 PM

I am curious. Has anyone checked how much more fees are paid to the network because of Satoshi dice (so both the fees they pay themselves and the fees their clients pay). Fees starting torise is a good an healthy thing and Sathosidice could be a catalyst.

So anyone that can show me some numbers?

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.

Yes but the first two I checked manually were 0.0005 and 0.0001 so I was curious anyone has a programmatic solution to automate the process and come up with non-estimated numbers.

Matt Corallo

hero member

Activity: 755

Merit: 515

a) Transactions volume increased dramatically because of a single website, SatoshiDice. Transactions volume size was suppose to reach that level sooner or later, but in decentralized manner. The proposal is a short term solution to the problem, ~~that utilizes the centralized manner of generated transactions~~, and proposing to discourage a website from generating high volume of transactions. The reasoning is that such behavior is abusive and does more harm then good to bitcoin network as a whole.

Essentially.

b) First, by definition short term solution is bad because the work to implement it would have to be thrown out the window soon enough.

The proposal isnt really that much of a short-term solution. It is designed to encourage users to not use more transactions than they need to. Though this is short-term for capping the chain, it should continue to drastically decrease overall chain volume even as that volume increases greatly.

Second, it limits the usefulness of Bitcoin Network. SatoshiDice, or any website with simular behavior, is useful because people who uses it find it so.

Again, no. It doesnt prevent satoshidice from existing, it encourages them to be more friendly to the bitcoin network as a whole.

Any short term solution implies that something it has to be done right now rather then later. Is the situation so dare that the proposal has to be implemented despite all the negatives?

No, but starting a discussion is required to ever move forward Wink

.

Quote from: wachtwoord on June 14, 2012, 02:44:54 PM

And do you think that the current problem is worth getting into regulating of how Bitcoin Network used?

This isnt regulating how bitcoin is used, its another incentive change. Or, more simply, yes.

SgtSpike

legendary

Activity: 1400

Merit: 1005

I am curious. Has anyone checked how much more fees are paid to the network because of Satoshi dice (so both the fees they pay themselves and the fees their clients pay). Fees starting torise is a good an healthy thing and Sathosidice could be a catalyst.

So anyone that can show me some numbers?

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.

fireduck

sr. member

Activity: 392

Merit: 251

Quote from: Matt Corallo on June 14, 2012, 02:49:28 PM

Quote from: Realpra on June 14, 2012, 02:55:01 PM

Of course none of that is a deal breaker. We can do it, but it will likely be a little while before I can get the code in and tested. I'll also have to think about making improvements to our UI to help users make sense of what they will see in these big transactions.

Somehow I dont see how throwing payouts in a cronjob and changing the existing payout functions to just put them in a list of to-be-sent takes more than a few hours to implement.

Thank you for your careful and considered estimation of the time it will take to implement a feature in my code, which I am almost certain you have never seen. I will treasure it always.

TangibleCryptography

sr. member

Activity: 476

Merit: 250

Tangible Cryptography LLC

Could we change the nature of blocks so that payments are not made up of only transactions, but also balances?

Bad idea. The power of a 51% attack is limited to only tx denial and double spends. If balances are updated based on tx in most recent block without back validation a 51% attack (or even a minority attacker which can generate multiple blocks in a row) could mint an unlimited amount of fake coins.

Realpra

hero member

Activity: 815

Merit: 1000

Quote from: Matt Corallo on June 14, 2012, 12:57:11 PM

Quote from: Realpra on June 14, 2012, 12:43:56 PM

Yes except they DO store part of the chain AND they do verify against those parts.

Alone none of the nodes are full, but together they act as a network of full nodes.

You can't verify against part of the chain. You can say "this transaction's signature is invalid" but you can't say "this transaction's input doesnt exist". Also, even if you have a few full nodes to check for this case, they cant prove it unless they send the full chain...

Hmm.. forgot that...

Quote from: Stephen Gornick on June 14, 2012, 02:47:28 PM

Clients could join a swarm when connecting which sort of represents the entire chain. Although clients would only store fractions of it, the entire blockchain is always available. Pretty much like a Bittorrent swarm is still fully functional

Similar to "my idea", but see other guy above.

Basically your idea would work, but to verify the inputs of transaction existed you would have to go through the entire chain in the cloud = huge bandwidth usage.

So: "Houston we have a problem"?

Hiding behind TOR or something becomes hard with "trusted" super nodes and VISA volumes so unless we solve this, BTC will remain a small network forever and/or get busted up by governments.

Could we change the nature of blocks so that payments are not made up of only transactions, but also balances?

We know the block chain is trustworthy due to work proofs -> Just put address balances in it?

Could we do this without forking? "BIP 34" or something?

That way I could store the balances of maybe 1000 addresses and I simply verify transactions going out from them? IE verifying inputs against a partial chain?

Matt Corallo

hero member

Activity: 755

Merit: 515

Incidentally, SatoshiDICE only employs high-traffic addresses (1diceN*) because that is convenient (no need to get a new address for each wager). But there is no dependency on using those addresses. The service can provide a unique Bitcoin address for each wager and it would technically function just as well. If an API for obtaining a wagering address were made available it would be trivial for automated wagering (e.g., martingale bots) and the new user interfaces (e.g., mobile apps reportedly being developed) to switch over to that.

So punshing high-traffic addresses won't necessarily have much of the expected effect.

Agreed, but, again its something that will make people think twice about their system-design. Also, thats why such transactions would be rate-limited and discouraged and not blocked, which allows people to opt into being low-prio. Someone like satoshidice should be perfectly willing to do this as their users are using unconfirmed transactions anyway and it would let them give other users who are using one-off transactions higher priority and have less of an effect on confirmation times for end-users.

Serith

sr. member

Activity: 269

Merit: 250

So far what I gathered from this thread.

a) Transactions volume increased dramatically because of a single website, SatoshiDice. Transactions volume size was suppose to reach that level sooner or later, but in decentralized manner. The proposal is a short term solution to the problem, that utilizes the centralized manner of generated transactions, and proposing to discourage a website from generating high volume of transactions. The reasoning is that such behavior is abusive and does more harm then good to bitcoin network as a whole.

b) First, by definition short term solution is bad because the work to implement it would have to be thrown out the window soon enough. Second, it limits the usefulness of Bitcoin Network. SatoshiDice, or any website with simular behavior, is useful because people who uses it find it so.

Any short term solution implies that something it has to be done right now rather then later. Is the situation so dare that the proposal has to be implemented despite all the negatives? And do you think that the current problem is worth getting into regulating of how Bitcoin Network used?

Matt Corallo

hero member

Activity: 755

Merit: 515

Hi, I am the programmer working on SatoshiDice.

We are absolutely interested in being good bitcoin citizens and doing things in a good and efficient way. However, changing to handling many bets with a single transaction is a complicated change for us. It is certainly doable but has to be done carefully because making sure people get paid properly and accountably is our business. It will also make it confusing for our users. Right now seeing that they payment was correct is simple. They see one output to their address of the correct amount and one output to one of our change addresses. If we combine transactions, they will see a ton of outputs to various addresses.

I understand that people may see more outputs in their transactions, however in most (sane) clients, they only show the single output to the user in the transaction history. Thus, though the amount paid back to satoshidice may be harder to determine directly, I dont see any reason why users care much at all about that amount. If Im betting, its not hard to figure out the amount satoshidice kept by subtracting the amount I gave SatoshiDice from the amount I got back.

It gets even more confusing is the same address is getting payments from multiple bets in the same transaction (which will be a common use case, people bet a bunch at once often).

This admittedly complicates things, but if you really wanna keep it simple and more verifyable, you can simply not combine to-user payouts and keep those in separate transactions.

Quote from: Matt Corallo on June 14, 2012, 12:52:03 PM

Of course none of that is a deal breaker. We can do it, but it will likely be a little while before I can get the code in and tested. I'll also have to think about making improvements to our UI to help users make sense of what they will see in these big transactions.

Somehow I dont see how throwing payouts in a cronjob and changing the existing payout functions to just put them in a list of to-be-sent takes more than a few hours to implement.

Stephen Gornick

legendary

Activity: 2506

Merit: 1010

punishing high-traffic addresses by no means will remove the potential for the problem to occur. The goal is really because people who do use one address usually dont care about confirmation times, so they can gladly still use them and some might. Really its to make people think twice before designing their site in an entirely braindead way.

Incidentally, SatoshiDICE only employs high-traffic addresses (1diceN*) because that is convenient (no need to get a new address for each wager). But there is no dependency on using those addresses. The service can provide a unique Bitcoin address for each wager and it would technically function just as well. If an API for obtaining a wagering address were made available it would be trivial for automated wagering (e.g., martingale bots) and the new user interfaces (e.g., mobile apps for wagering on SatoshiDICE reportedly being developed) to switch over to that.

So punishing high-traffic addresses won't necessarily have much of the expected effect.

wachtwoord

legendary

Activity: 2324

Merit: 1125

I am curious. Has anyone checked how much more fees are paid to the network because of Satoshi dice (so both the fees they pay themselves and the fees their clients pay). Fees starting torise is a good an healthy thing and Sathosidice could be a catalyst.

So anyone that can show me some numbers?

Matt Corallo

hero member

Activity: 755

Merit: 515

Quote from: interlagos on June 14, 2012, 02:29:40 PM

Sorry, but that's the impression I got because you also called them stupid and braindead.

From the quote below it's seems they are also suffering from the same issue you mentioned,
if "use transactions in a more conservative way" means avoiding multisend.
They are a young service and hopefully they will work this out.

Quote from: fireduck on June 13, 2012, 01:59:24 AM

Quote from: titeuf_87 on June 12, 2012, 12:10:37 PM

I realize satoshidice is sometimes slow... but for the past few days I always had to wait at least five minutes before I even know if I won or not. Often times it's even longer.

Is this just me? Or that happens to others too?

Sorry, that was a database change I made. I make it use transactions in a more conservative way which ended up being a good bit slower so it was having trouble keeping up with people's bets. It should be much better now. I really need to track some metrics of bet to result time so that this sort of issue is more obvious to us.

Guessing from their website that is not whats happening. AFAICT, their site posts the result of a bet before sending the coins. Implementing multisend is really dead-simple and would have little effect on payout times if done even close to remotely properly. Doing multisend is a simple as queuing outputs and running a cronjob to send coins, even if they did it every minute, their total transaction volume would decrease by something like 500-1000%

fireduck

sr. member

Activity: 392

Merit: 251

Hi, I am the programmer working on SatoshiDice.

We are absolutely interested in being good bitcoin citizens and doing things in a good and efficient way. However, changing to handling many bets with a single transaction is a complicated change for us. It is certainly doable but has to be done carefully because making sure people get paid properly and accountably is our business. It will also make it confusing for our users. Right now seeing that they payment was correct is simple. They see one output to their address of the correct amount and one output to one of our change addresses. If we combine transactions, they will see a ton of outputs to various addresses. It gets even more confusing is the same address is getting payments from multiple bets in the same transaction (which will be a common use case, people bet a bunch at once often).

Of course none of that is a deal breaker. We can do it, but it will likely be a little while before I can get the code in and tested. I'll also have to think about making improvements to our UI to help users make sense of what they will see in these big transactions.

Matt Corallo

hero member

Activity: 755

Merit: 515

Quote from: Matt Corallo on June 14, 2012, 12:52:03 PM

- SatoshiDice is legitimate. It may not try its hardest to make the most efficient transactions, but you will always have clients who aren't perfect. SD just does what might happen in 2-3 years anyway, but by lots of different users. SD can use the system only within the given limits; if it would do something wrong, transactions would get rejected. Basically it boils down to the underlying protocol restrictions: spammers for example are really hated, but they operate fine within the SMTP-RFC.

a) they arent making a legitimate use. Arguing that it works under the current rules is not a reason to not change the rules to make it not possible.

- Restricting the heavy users won't help either. That's similar to the ISP who advertises with "unlimited downloads" but later throttles you when you download >1GB/month.

Again, the point isnt to restrict, its to encourage them to think twice about what they are doing and encourage them to do simple things like sendmulti which make a huge difference to the load they create across the network.