<p>Well, what that is called is a hack.  It is a hack to make the system work in a way that is wasn't meant to work.</p>

<p>By definition, hacks aren't thought out very well and often aren't the optimum method -- if not outright flawed.  But they do in many instances, fix the immediate need.</p>

<p>In most every bet to BitLotto and SatoshiDICE there is an output address for change.  These services can't know if that change was meant to be the alternate pay-to address or if it was just the change.   One Satoshi would be a bad choice for this "special indicator" as that happens naturally quite often.  An amount that doesn't occur very often would be an amount like "0.00543210".  The frequency of change being 0.00543210 is much, much lower than it being 0.00000001 BTC.</p>

<p>But the chance is not zero.  If I have a coin with 0.25543210 BTC on it and I sent a 0.25 wager, I'll get back 0.00543210 as change.  Since that change is for an address in my own wallet, then even though SatoshiDICE might send the winnings to that change address I'll still receive them.  But the normal mode for these services is to always pay back to a sending (input) address, so returning to the change address frequently becomes a service issue as it is harder to understand how it works.   So ideally, this special number is one that wouldn't normally get be used for change.</p>

<p>But if instead I had actually made both a payment of 0.00543210 to someone and a bet to SatoshiDICE in the exact same transaction, then the winnings would go to that someone and not back to me.  If I know that 0.00543210 is of special significance with SatoshiDICE I'll know to never make a transaction with that amount in it when I'm also including a SatoshiDICE bet.  If the number were something else, like 0.00814271, that also would be infrequently used naturally, but it also wouldn't be one that I would recognize and might accidentally be an amount I would pay in this hypothetical bet statement that I combine with real-world payments.</p>

<p>So I'm going to come to the conclusion that to eliminate even the extremely rare chance that the payout goes to the wrong party, these services chose an easily recognizable amount so that it might save a person from making that mistake.  This amount would also preferable be a low value so that it doesn't suck too much betting capacity from the bettor's wallet with each use.</p>

<p>What is an amount that serves both those aims?  0.00543210.</p>

CC BY-SA 3.0
2012-11-01T21:37:49.473Z
This seems to hinge on the idea that an automatic change value of 0.00543210 is much less frequent than 0.00000001. Is there any data or rigorous proof that this is the case?

I would hope that transaction-composing algorithms avoided the creation of tiny 0.00000001 outputs, because compared to larger outputs they'll bloat future transactions. That would make 0.00000001 outputs rarer in practice, and thus ideal for signaling.
Quizzical
CC BY-SA 3.0
2012-11-01T22:43:30.020Z
The aim of the coin selection algorithm of the Bitcoin.org client is primarily to minimize the amount of change.  Thus lower amounts for change are more frequent than larger amounts.
Stephen Gornick
CC BY-SA 3.0
2012-11-02T22:19:47.150Z
Looking at source, that doesn't seem true down to one satoshi. See [wallet.cpp#L1006](https://github.com/bitcoin/bitcoin/blob/master/src/wallet.cpp#L1006), which avoids creating change less than `CENT` (defined [util.h#L36](https://github.com/bitcoin/bitcoin/blob/master/src/util.h#L36) as 1000000 satoshis) for min TX fee reasons. Both 0.00543210 and 0.00000001 are under this, so maybe equally unlikely and subject to same TX fee concerns. Maybe SatoshiDice didn't understand this when choosing 0.00543210?
Quizzical
CC BY-SA 3.0
2012-11-03T14:40:06.183Z
Oh, I hadn't known about that sub-CENT avoidance.  Cool.  As far as the origin, this hack was introduced by BitLotto before there was a SatoshiDICE.  But it is a hack that has flaws and thus using it is not recommended.
Stephen Gornick
CC BY-SA 3.0
2012-11-01T21:17:37.057Z
2012-11-01T21:17:37.057Z
Stephen Gornick
<p>SatoshiDice and BitLotto allow players to customize where winnings are sent by including an extra 0.00543210 BTC payment to the desired address as part of the entry transaction. </p>

<p>Is there a technical reason they don't use a single satoshi (0.00000001 BTC) value instead?</p>

CC BY-SA 3.0
2012-11-03T14:41:53.133Z
That is a bad hack.  No service, including both BitLotto and SatoshiDICE, should be offering this.
Stephen Gornick
<transactions><satoshi><gambling>
Is there a reason SatoshiDice & BitLotto use 0.00543210 BTC, and not 1 satoshi, to customize pay-to addresses?
Quizzical
# Is there a reason SatoshiDice & BitLotto use 0.00543210 BTC, and not 1 satoshi, to customize pay-to addresses?

(Asked by: username_0 on 2012-11-01)

SatoshiDice and BitLotto allow players to customize where winnings are sent by including an extra 0.00543210 BTC payment to the desired address as part of the entry transaction.

Is there a technical reason they don't use a single satoshi (0.00000001 BTC) value instead?

**Tags:** transactions, satoshi, gambling

> **Comments:**
> **username_1**: That is a bad hack.  No service, including both BitLotto and SatoshiDICE, should be offering this.  

---

## 1 answers

### Answer by username_1 on 2012-11-01. Score: 6 | Accepted answer

Well, what that is called is a hack. It is a hack to make the system work in a way that is wasn't meant to work.

By definition, hacks aren't thought out very well and often aren't the optimum method -- if not outright flawed. But they do in many instances, fix the immediate need.

In most every bet to BitLotto and SatoshiDICE there is an output address for change. These services can't know if that change was meant to be the alternate pay-to address or if it was just the change. One Satoshi would be a bad choice for this "special indicator" as that happens naturally quite often. An amount that doesn't occur very often would be an amount like "0.00543210". The frequency of change being 0.00543210 is much, much lower than it being 0.00000001 BTC.

But the chance is not zero. If I have a coin with 0.25543210 BTC on it and I sent a 0.25 wager, I'll get back 0.00543210 as change. Since that change is for an address in my own wallet, then even though SatoshiDICE might send the winnings to that change address I'll still receive them. But the normal mode for these services is to always pay back to a sending (input) address, so returning to the change address frequently becomes a service issue as it is harder to understand how it works. So ideally, this special number is one that wouldn't normally get be used for change.

But if instead I had actually made both a payment of 0.00543210 to someone and a bet to SatoshiDICE in the exact same transaction, then the winnings would go to that someone and not back to me. If I know that 0.00543210 is of special significance with SatoshiDICE I'll know to never make a transaction with that amount in it when I'm also including a SatoshiDICE bet. If the number were something else, like 0.00814271, that also would be infrequently used naturally, but it also wouldn't be one that I would recognize and might accidentally be an amount I would pay in this hypothetical bet statement that I combine with real-world payments.

So I'm going to come to the conclusion that to eliminate even the extremely rare chance that the payout goes to the wrong party, these services chose an easily recognizable amount so that it might save a person from making that mistake. This amount would also preferable be a low value so that it doesn't suck too much betting capacity from the bettor's wallet with each use.

What is an amount that serves both those aims? 0.00543210.

> **Comments:**
> **username_0**: This seems to hinge on the idea that an automatic change value of 0.00543210 is much less frequent than 0.00000001. Is there any data or rigorous proof that this is the case?  I would hope that transaction-composing algorithms avoided the creation of tiny 0.00000001 outputs, because compared to larger outputs they'll bloat future transactions. That would make 0.00000001 outputs rarer in practice, and thus ideal for signaling.  
> **username_1**: The aim of the coin selection algorithm of the Bitcoin.org client is primarily to minimize the amount of change.  Thus lower amounts for change are more frequent than larger amounts.  
> **username_0**: Looking at source, that doesn't seem true down to one satoshi. See [wallet.cpp#L1006](https://github.com/bitcoin/bitcoin/blob/master/src/wallet.cpp#L1006), which avoids creating change less than `CENT` (defined [util.h#L36](https://github.com/bitcoin/bitcoin/blob/master/src/util.h#L36) as 1000000 satoshis) for min TX fee reasons. Both 0.00543210 and 0.00000001 are under this, so maybe equally unlikely and subject to same TX fee concerns. Maybe SatoshiDice didn't understand this when choosing 0.00543210?  
> **username_1**: Oh, I hadn't known about that sub-CENT avoidance.  Cool.  As far as the origin, this hack was introduced by BitLotto before there was a SatoshiDICE.  But it is a hack that has flaws and thus using it is not recommended.  

---

