>
> Sorry for the delays, I'm currently traveling and working - in my real job
> - at the same time.
>
Martin, I'm frankly astonished by the quality, extent, and speed to which
you are responding to posts from a non-developer newbish user. I appreciate
it and it will take me some time to digest your answer fully, but honestly
I feel like I should be paying you for professional support. Hopefully I
can find a way to contribute back someday.
The third posting's currency is impossible to categorize. What are the
> units supposed to be? USD? EUR? JPY? Remember there's no constraint in an
> account that there ought to be a single currency, or even a single cost
> currency for the same currency. Maybe I could add that further constraint
> to an account to make the interpolation more powerful, but it's not like
> that now, accounts can contain a mish-mash of different things (see the
> one_commodity plugin).
>
Again I am probably not understanding fully, but if you are using an
automatic booking strategy then it could just reduce the next things in the
queue/stack whatever they are and just pass them to the other account as
long as the constraints on the other account allow for it. This is actually
what I would want (unless someone can tell me that is a bad idea). For
example if I have an inventory of BTC with both USD and EUR cost-bases and
I want transfer them to another wallet (asset account) I don't care what
the units of the costs are in. I will have to deal with currency conversion
at some point if I sell, but hopefully I can just defer that problem. Is
this what the "NONE" booking strategy does?
As for constraints on the accounts, I think that is a great idea. Can't you
already enforce valid commodities for an account already without the
plugin? E.g.:
2018-08-14 open Assets:BTC:Wallet BTC
Constraining the cost currencies could be useful too, it might look
something like:
2018-08-14 open Assets:BTC:Wallet BTC {USD,ETH}
I'll get you the details of what version I am running etc. to figure out
why we have differences in the source of errors.
Best,
~Sam
On Tue, Aug 14, 2018 at 12:09 AM, Martin Blais <[email protected]> wrote:
> On Mon, Aug 13, 2018 at 10:37 PM Samuel Lotz <[email protected]>
> wrote:
>
>> Hi Martin,
>> Apologies that its not very understandable, I honestly was a little
>> confused myself.
>>
>> Your solution works for me exactly as I want, however, then I am losing
>> the convenience of using the booking method (LIFO in my case). I tried this:
>>
>> 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"
>> Expenses:Fees:BTCMining 0.00105853
>> BTC @ BTC
>> Assets:BTC:Coinbase -0.00144853
>> BTC {}
>> Assets:BTC:Jaxx 0.00039
>> BTC {}
>>
>> But I get an error in bean-check.
>>
>> I would imagine that this would have the same effect because the cost
>> basis for the lot would be filled in automatically, but I figured
>> disambiguating would help like this:
>>
>> 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"
>> Expenses:Fees:BTCMining 0.00105853
>> BTC @ BTC
>> Assets:BTC:Coinbase -0.00144853
>> BTC {USD}
>> Assets:BTC:Jaxx 0.00039
>> BTC {USD}
>>
>>
>>
>> But it books the cost-basis of the BTC in the Jaxx account as
>> 9885.214421538461538461538462 USD :
>>
>
> Yes, it makes sense, see below
>
>
>
>>
>> --> bean-doctor context ledger.beancount 107
>> Hash:972251de2efc72a4e7f2a2c4654440cb
>> Location: /home/salotz/tree/personal/studio/projects/index/
>> troubleshooting.general/beancount/issue_000/ledger.beancount:107
>>
>> ------------ Balances before transaction
>>
>> Expenses:Fees:BTCMining
>>
>>
>> Assets:BTC:Coinbase 0.01878653 BTC {2661.48 USD,
>> 2017-06-14}
>>
>> Assets:BTC:Jaxx
>>
>>
>>
>> ------------ Transaction
>>
>> 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"
>> Expenses:Fees:BTCMining 0.00105853 BTC @ 0.00000000 BTC
>> ; 0 BTC
>>
>
> There are no other legs with BTC, so it fills in a price of zero.
> (Note that a legitimate argument could be made as to whether an
> automatically filled in price of zero should raise an error.)
>
>
>
>> Assets:BTC:Coinbase -0.00144853 BTC {2661.48 USD, 2017-06-14}
>> ; -3.8552336244 USD
>>
>
> This gets matched against the inventory, so against the 0.01878653 BTC
> {2661.48 USD, 2017-06-14} position, and reduces it.
> The weight of that posting of -3.8552336244 USD
>
>
>
>> Assets:BTC:Jaxx 0.00039000 BTC {9885.21 USD, 2017-06-14} ;
>> 3.855233624400000000000000000 USD
>>
>
> Now this is an augmenting leg, and we must squeeze 3.8552336422 USD 's
> worth of 0.00039000 BTC, which means they must be worth 3.8552336422 /
> 0.00039 each, so you get 9885.21.
>
> Everything is at it should.
>
>
> Tolerances: BTC=5E-9
>>
>> ------------ Balances after transaction
>>
>> * Expenses:Fees:BTCMining 0.00105853
>> BTC
>>
>> * Assets:BTC:Coinbase 0.01733800 BTC {2661.48 USD,
>> 2017-06-14}
>>
>> * Assets:BTC:Jaxx 0.00039 BTC {9885.214421538461538461538462
>> USD, 2017-06-14}
>>
>> Maybe I am mistaken and this is correct but it doesn't seem to me since
>> then if you sold the position in the Jaxx wallet it wouldn't be booked
>> against the original cost-basis that was calculated when the lot was bought.
>>
>
> I don't understand this question.
>
>
>
>>
>> I've attached a minimum working example for a lot of test cases and their
>> results written in the comments. It may not be of much use to you though,
>> but when I don't understand something I tend to go for the enumerative
>> brute force and try to understand the results and compare.
>>
>
> So you start from this:
> 2017-06-13 * "Coinbase" "Test buying bitcoin"
>
> Expenses:Fees:Trading 1.99 USD
>
> Assets:BTC:Coinbase 0.01878653 BTC
> {2661.48 USD}
>
> Assets:Checking -51.99 USD
>
> The first one looks like it should match,
>
> ;; 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"
>
> ;; Expenses:Fees:BTCMining 0.00105853
> BTC
>
> ;; Assets:BTC:Coinbase -0.00144853
> BTC {}
>
> ;; Assets:BTC:Jaxx 0.00039
> BTC
>
>
> ;; RESULT: Bean check error on the directive: no position matches
>
> because there's a single lot in the inventory and it should be able to
> infer the currency fro that.
> That should be doable (not a bug, but definitely a possible improvement).
> It doesn't match because of this check:
> https://bitbucket.org/blais/beancount/src/tip/beancount/
> parser/booking_full.py?fileviewer=file-view-default#booking_full.py-579
>
> I'll file a ticket to make this case work:
> https://bitbucket.org/blais/beancount/issues/324/when-
> matching-against-a-single-lot-infer
>
>
> ;; 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"
>
> ;; Expenses:Fees:BTCMining 0.00105853
> BTC
>
> ;; Assets:BTC:Coinbase -0.00144853
> BTC {USD}
>
> ;; Assets:BTC:Jaxx 0.00039
> BTC
>
>
> ;; RESULT: bean-check directive error: does not balance as BTCMining leg
> is not balanced
>
> This is normal; the 2nd posting is in USD, and then you have two
> augmenting postings in BTC with nothing else to reduce them.
> Two currency groups (USD, for the 2nd posting, and BTC for the sum of the
> 1st and 3rd, each unbalanced).
>
>
>
>
> ;; 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"
>
> ;; Expenses:Fees:BTCMining 0.00105853
> BTC
>
> ;; Assets:BTC:Coinbase -0.00144853
> BTC {}
>
> ;; Assets:BTC:Jaxx 0.00039
> BTC @ BTC
>
>
> ;; RESULT: bean-check syntax error
>
> That one actually gives me the same error as the first, no position
> matches against the second posting.
>
>
> ;; 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"
>
> ;; Expenses:Fees:BTCMining 0.00105853
> BTC
>
> ;; Assets:BTC:Coinbase -0.00144853
> BTC {USD}
>
> ;; Assets:BTC:Jaxx 0.00039
> BTC @ BTC
>
>
> ;; RESULT: bean-check directive error: does not balance
>
> Same problem as the second (BTC @ BTC should not be allowed, BTW, makes no
> sense).
>
>
>
> ;; 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"
>
> ;; Expenses:Fees:BTCMining 0.00105853
> BTC
>
> ;; Assets:BTC:Coinbase -0.00144853
> BTC {}
>
> ;; Assets:BTC:Jaxx 0.00039
> BTC @ BTC
>
>
> ;; RESULT: bean-check syntax error
>
> Again, I get a position not matched error, not a syntax error.
>
>
> ;; 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"
>
> ;; Expenses:Fees:BTCMining 0.00105853
> BTC
>
> ;; Assets:BTC:Coinbase -0.00144853
> BTC {USD}
>
> ;; Assets:BTC:Jaxx 0.00039
> BTC @ BTC
>
>
> ;; RESULT: bean-check directive error: doesn't balance
>
> Same as the second case, you're correctly matching against the inventory,
> but the currency groups aren't in balance
>
>
>
> ;; 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"
>
> ;; Expenses:Fees:BTCMining 0.00105853
> BTC @ USD
>
> ;; Assets:BTC:Coinbase -0.00144853
> BTC {}
>
> ;; Assets:BTC:Jaxx 0.00039
> BTC @ BTC
>
>
> ;; RESULT: no error. Books no cost-basis BTC to the Jaxx wallet. Books BTC
> to expenses
>
> That's expected. You /always/ have to provide the cost basis explicitly on
> an augmenting leg, unless it's possible to interpolate it because it's the
> only missing number. Your comment hints that you might think the cost basis
> numbers somehow translate between postings... they don't. The total cost
> basis is used to balance with the other legs, but the per-unit cost is LOST
> in this balancing.
> Here the first two legs are interpolated - the second one is first matched
> against the inventory contents (interestingly enough, this works despite
> the absence of the USD disambiguation, I have to investigate), the first
> one has the corresponding price filled in. The third one is alone in BTC
> and is interpolated to a price of 0 (again, it's debatable whether this
> should generate an error, I'm starting to think it should).
>
>
> ;; 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"
>
> ;; Expenses:Fees:BTCMining 0.00105853
> BTC @ USD
>
> ;; Assets:BTC:Coinbase -0.00144853
> BTC {USD}
>
> ;; Assets:BTC:Jaxx 0.00039
> BTC @ BTC
>
>
> ;; RESULT: no error. Books no cost-basis BTC to the Jaxx wallet. Books BTC
> to expenses
>
> Same
>
>
>
> ;; 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"
>
> ;; Expenses:Fees:BTCMining 0.00105853
> BTC @ USD
>
> ;; Assets:BTC:Coinbase -0.00144853
> BTC {}
>
> ;; Assets:BTC:Jaxx 0.00039
> BTC {}
>
>
> ;; RESULT: bean-check error
>
> The third posting's currency is impossible to categorize. What are the
> units supposed to be? USD? EUR? JPY? Remember there's no constraint in an
> account that there ought to be a single currency, or even a single cost
> currency for the same currency. Maybe I could add that further constraint
> to an account to make the interpolation more powerful, but it's not like
> that now, accounts can contain a mish-mash of different things (see the
> one_commodity plugin).
>
>
> ;; 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"
>
> ;; Expenses:Fees:BTCMining 0.00105853
> BTC @ USD
>
> ;; Assets:BTC:Coinbase -0.00144853
> BTC {USD}
>
> ;; Assets:BTC:Jaxx 0.00039
> BTC {}
>
>
> ;; RESULT: bean-check directive error: too many missing numbers for
> currency group USD
>
> Normal. But this should have yielded the same error as the preceding case
> but somehow it managed to infer the third leg was USD too and we have two
> numbers to fill-in / interpolate (on the first leg, and the third one).
> Not possible.
>
>
>
> ;; 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"
>
> ;; Expenses:Fees:BTCMining 0.00105853
> BTC @ BTC
>
> ;; Assets:BTC:Coinbase -0.00144853
> BTC {USD}
>
> ;; Assets:BTC:Jaxx 0.00039
> BTC {}
>
>
> ;; RESULT: bean-check error
>
> Same
>
>
> ;; 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"
>
> ;; Expenses:Fees:BTCMining 0.00105853
> BTC @ BTC
>
> ;; Assets:BTC:Coinbase -0.00144853
> BTC {USD}
>
> ;; Assets:BTC:Jaxx 0.00039
> BTC {USD}
>
>
> ;; RESULT: no error. Books no cost basis to BTCMining, books correct
> amount to Jaxx
>
> ;; but with a cost-basis of {9885.214421538461538461538462 USD}
>
> If you write no {} there will never be any cost basis... on an augmenting
> leg if you want cost basis you need to provide it explicitly.
> I can probably stop here, I think you'll have an eureka moment just now.
>
>
>
>
> My conclusions are that in a single transaction directive it is not
>> possible to automatically (i.e. not specify the position to reduce against)
>> split an inventory reduction into an expense and an asset transfer and keep
>> the original cost-basis.
>>
>
> On an augmenting posting held at cost (e.g., adding a positive number of
> units of a currency with a {} spec), you always need to either provide an
> explicit cost basis for it, or that being the only number missing in its
> currency group, in which case it can be interpolated.
>
> Per-unit cost basis numbers are /never/ transferred between postings. Only
> the total is used to balance the postings within each currency group.
>
>
>
>
>>
>> I tried splitting it into two transactions and this seems to work
>> swimmingly, so this is the way I will do it for now until the booking
>> capabilities are more advanced.
>>
>> I really appreciate your responses.
>>
>
> Sorry for the delays, I'm currently traveling and working - in my real job
> - at the same time.
>
>
>
>
>>
>> ~Sam
>>
>> On Sun, Aug 12, 2018 at 4:20 PM, Martin Blais <[email protected]> wrote:
>>
>>> On Sat, Aug 11, 2018 at 10:39 PM <[email protected]> wrote:
>>>
>>>>
>>>> I lied I was missing the new error message:
>>>>
>>>> /home/salotz/tree/personal/studio/projects/index/finance/
>>>> ledger/ledger.beancount:1161: Transaction does not balance:
>>>> (0.00105853 BTC)
>>>>
>>>> 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"
>>>> Expenses:Fees:BTCMining 0.00105853
>>>> BTC
>>>> Assets:BTC:Coinbase -0.00144853 BTC {2661.48 USD,
>>>> 2017-06-14}
>>>> Assets:BTC:Jaxx 0.00039 BTC @
>>>> 9885.214421538461538461538462 USD
>>>>
>>>>
>>>> Upon investigation in bean-doctor:
>>>>
>>>> ------------ Balances before transaction
>>>>
>>>> Expenses:Fees:BTCMining
>>>>
>>>>
>>>> Assets:BTC:Coinbase 0.004151 BTC {2247.70 USD,
>>>> 2017-05-24}
>>>> Assets:BTC:Coinbase 0.01878653 BTC {2661.48 USD,
>>>> 2017-06-14}
>>>>
>>>> Assets:BTC:Jaxx
>>>>
>>>>
>>>>
>>>> ------------ Transaction
>>>>
>>>> 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"
>>>> Expenses:Fees:BTCMining 0.00105853
>>>> BTC ; 0.00105853 BTC
>>>> Assets:BTC:Coinbase -0.00144853 BTC {2661.48 USD,
>>>> 2017-06-14} ; -3.8552336244 USD
>>>> Assets:BTC:Jaxx 0.00039000 BTC @ 9885.21
>>>> USD ; 3.855233624400000000000000000 USD
>>>>
>>>>
>>>> Residual: (0.00105853 BTC)
>>>> Tolerances: BTC=5E-9
>>>> Basis: (-3.8552336244 USD)
>>>>
>>>> ------------ Balances after transaction
>>>>
>>>> * Expenses:Fees:BTCMining
>>>> 0.00105853 BTC
>>>>
>>>> Assets:BTC:Coinbase 0.004151 BTC {2247.70 USD,
>>>> 2017-05-24}
>>>> * Assets:BTC:Coinbase 0.01733800 BTC {2661.48 USD,
>>>> 2017-06-14}
>>>>
>>>> * Assets:BTC:Jaxx
>>>> 0.00039 BTC
>>>>
>>>>
>>>> It seems that it is booking the lot from Assets:BTC:Coinbase all to
>>>> Assets:BTC:Jaxx because of the use of that syntax, and then the mining fee
>>>> leg is unbalanced and not considered at all.
>>>>
>>>
>>> I read what you wrote three times and I don't understand what you're
>>> saying.
>>> In any case, here's how this works: in this transaction:
>>>
>>> 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"
>>> Expenses:Fees:BTCMining 0.00105853
>>> BTC
>>> Assets:BTC:Coinbase -0.00144853 BTC {2661.48 USD,
>>> 2017-06-14}
>>> Assets:BTC:Jaxx 0.00039 BTC @
>>> 9885.214421538461538461538462 USD
>>>
>>> - The first posting "weighs" for 0.00105853 BTC
>>> - The second posting "weighs" for -0.00144853 BTC x 2661.48 USD
>>> = -3.8552336244 USD
>>> - The first postings "weights" for 0.00039 BTC @
>>> 9885.214421538461538461538462 USD = 3.8552336244 USD
>>>
>>> So it has two currency groups to balance:
>>> 1. USD, with the two legs cancelling each other out: -3.8552336244 +
>>> 3.8552336244 = 0, so we're goot.
>>> 2. BTC, of which there is a single leg and the amount (0.00105853)
>>> exceeds the tolerance, so BTC is not balanced.
>>> So you get an error.
>>>
>>> One way to achieve what you want is this: keep the cost basis in Jaxx
>>> and book your expenses as BTC without cost basis
>>>
>>> 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"
>>>
>>> Expenses:Fees:BTCMining 0.00105853 BTC @ USD
>>>
>>> Assets:BTC:Coinbase -0.00144853 BTC {2661.48 USD}
>>>
>>> Assets:BTC:Jaxx 0.00039 BTC {2661.48 USD}
>>>
>>> Unfortunately, you cannot leave more than one number to be interpolated
>>> in each currency group.
>>>
>>>
>>>
>>>
>>>> So I tried:
>>>>
>>>> 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"
>>>> Assets:BTC:Coinbase
>>>> -0.00144853 BTC {}
>>>> Expenses:Fees:BTCMining
>>>> 0.00105853 BTC @ USD
>>>> Assets:BTC:Jaxx
>>>> 0.00039 BTC @ USD
>>>>
>>>> And to reverse the autofilling of the amount:
>>>>
>>>> 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"
>>>> Assets:BTC:Coinbase
>>>> -0.00144853 BTC {}
>>>> Expenses:Fees:BTCMining
>>>> Assets:BTC:Jaxx
>>>> 0.00039 BTC @ USD
>>>>
>>>>
>>>> But I get this error for both:
>>>>
>>>> /home/salotz/tree/personal/studio/projects/index/finance/
>>>> ledger/ledger.beancount:1163: Too many missing numbers for currency
>>>> group 'USD'
>>>>
>>>
>>> Beancount only supports a single interpolated number by currency group
>>> to balance.
>>> It's a very complicated answer to explain why, but essentially revolves
>>> around the fact that the problem is underconstrained.
>>>
>>>
>>>
>>>>
>>>> Not sure what to do at this point except for booking the mining fee in
>>>> a separate transaction.
>>>>
>>>
>>> Cryptocurrencies offer a particular challenge in that reductions at cost
>>> basis are made as often as expenses for some users.
>>> Beancount isn't particularly well adapted to that (but nothing else is
>>> either).
>>> See another recent-ish thread on Bitcoin.
>>>
>>>
>>>
>>>
>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Beancount" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to [email protected].
>>>> To post to this group, send email to [email protected].
>>>> To view this discussion on the web visit https://groups.google.com/d/
>>>> msgid/beancount/0a916715-69ab-4337-b327-c256aa3e1f3b%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/beancount/0a916715-69ab-4337-b327-c256aa3e1f3b%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "Beancount" group.
>>> To unsubscribe from this topic, visit https://groups.google.com/d/
>>> topic/beancount/Qvbcq-Sk5NY/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> [email protected].
>>> To post to this group, send email to [email protected].
>>> To view this discussion on the web visit https://groups.google.com/d/
>>> msgid/beancount/CAK21%2BhMnx3Yk%3DJKurxaV2ZGNz0Eq87iYYPBYfPoBe
>>> X_hwn%3DuLw%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/beancount/CAK21%2BhMnx3Yk%3DJKurxaV2ZGNz0Eq87iYYPBYfPoBeX_hwn%3DuLw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Samuel Lotz
>>
>> [email protected]
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Beancount" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To post to this group, send email to [email protected].
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/beancount/CAEZ4YMUYkT5Qd1BYmJakw-vf9ivQsTi%
>> 2B1e1iAUhZiqHcO52DNg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/beancount/CAEZ4YMUYkT5Qd1BYmJakw-vf9ivQsTi%2B1e1iAUhZiqHcO52DNg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Beancount" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/beancount/Qvbcq-Sk5NY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> [email protected].
> To post to this group, send email to [email protected].
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beancount/CAK21%2BhP%2BH7gi3zEpWj1Twgo7A94xz-
> pMLGD5ahQD-6kq0D6FBA%40mail.gmail.com
> <https://groups.google.com/d/msgid/beancount/CAK21%2BhP%2BH7gi3zEpWj1Twgo7A94xz-pMLGD5ahQD-6kq0D6FBA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
Samuel Lotz
[email protected]
--
You received this message because you are subscribed to the Google Groups
"Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beancount/CAEZ4YMW1m59snz_ujp9_H3hpDvJDv8a5xMAVugwtoq%2BrWVHobQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
