Category Archives: Bitcoin

Removing the wallet from TRB, first thoughts

This article summarizes my first thoughts about the correct way a Bitcoin client should enable its operator to issue transactions. It is based on my reflexion as well as my experience in broadcasting dozens of hand-crafted transactions for which the bitcoin-core built-in wallet repeatedly demonstrated its ineptitude.

As it currently stands, the wallet is an embedded part of the reference implementation. This is problematic for a variety of reasons, the most fundamental one has been exposed by Mircea Popescu in “How to cut the wallet“.

The job of the node is to connect to others via the Internet, and to exchange information with them. The job of the wallet is to prevent others from connecting via the Internet, which makes the tension quite evident.

Today, a Bitcoin client consists of three main pieces:

  1. The network protocol management part, that connects to peers and exchanges data with them;
  2. The data storage and validation part;
  3. The wallet, which uses the previous pieces to create transactions, sign and broadcast them.

The point of this discussion is to show that cutting the wallet entirely off of TRB is (1) desirable, and (2) requires only a small interface for a subset of (a) and (b)’s functionality to allow much better wallets to be built on top of TRB.

There are numerous reasons for which detaching the wallet is, in my opinion, highly desirable:

  • the job of the node and the wallet are very different (there only exists a functional dependence on the former by the latter);
  • as already stated, their coexistence in the same binary creates a fundamental tension between what the node requires, and what the wallet tries to avoid;
  • there exists no valid reason to keep the code for a wallet embedded right in the code that operates a critical piece of infrastructure, except for the current lack of a sane alternative;
  • the wallet code touches a lot of parts in TRB and adds complexity and bloat to the whole thing, I want TRB generating my addresses as much as I want my e-mail client generating my PGP keys;
  • it does a very bad job at crafting transactions with a lot of shitty heuristics, assumptions and places various artificial and unwarranted constraints are enforced on the operator;
  • external wallets, talking to a small and clearly delimited interface of TRB, could be made as very simple overlays managing a set of keys, with as much control given to the operator as his particular use case mandates;

The required interface for an external wallet, at TRB-level, is quite limited:

  • Query the UTXO for unspent outputs given a set of addresses.
  • Put an arbitrary transaction in the mempool, optionally nuking any conflicting ones[1]

While the latter doesn’t present much implementation challenges, the former is a whole different story, depending on the particular way it is implemented. In my opinion, the correct way to implement it would be to index every single UTXOs with its address (or even all TXOs, soyons fous) in order to be able to efficiently return the set of UTXOs (or TXOs if history’s required) for a given set of addresses. A lighter option would be to allow the operator to specify a list of addresses he’s interested in, and index only those.

The second option is what already exists, but it forces the conservation of the “reindexing” logic,  a list of monitored addresses along with a lot of wallet-related code. The first option allows TRB to remove this functionality completely, serve an arbitrary number of wallets, and get rid of any “sensitive” information, such as the list of addresses an operator is interested in.

This TXOs-indexed-by-address is essentially the index Electrum servers are maintaining, different implementations manage to pack this data in 20 to 50gb (the latter being the index packed pretty inefficiently and keeping not only UTXOs but also partial history for all addresses, up to a certain arbitrary count). The indexing of only a specific set of address would obviously come orders of magnitude cheaper but leave the node coupled to the wallet by having to know which addresses are part of the wallet, and which aren’t, or more precisely those which are ~definitely not~ part of the wallet.

Keeping the history indexed by address doesn’t really make much sense to me, it seems to me it’s the wallet’s job to keep the various receipts until they’re binned or archived (which doesn’t prevent a blockchain scan to be performed, should it be necessary to retrieve it again).

Yet another option might simply be to naively scan the UTXO set for any “gimme the unspent outs for these addresses” request the client gets. As of today the UTXO set is ~1.6gb. Obviously this means the transaction history for addresses can’t be directly queried from the node without a full blockchain rescan.

Whatever the approach, the node simply has to output UTXOs, and receive signed transactions as input for broadcast.

To be continued, comments more than welcome !

 


[1] Unlike PRB, which somehow thinks whatever’s already in your mempool has precedence over what you’re explicitly telling it to swallow.

Two cans, one string. Kraken edition.

Mauritius is a pretty boring country, and given the apparent lack of proper casinos I elected to give Kraken a chance and try out their “margin trading” feature[1].

Long story short I ended up opening a short for 20 BTC around 749 EUR per. My lack of faith, disturbing as it was, ended up promptly rewarded with a well-deserved beating. After some additional servings of the same flavour of fail I figured that ending the blood-bath was well overdue.

Equipped with this firm intention, I merrily headed to the Kraken web interface, opened up the “positions” dashboard, and (naively, I confess) clicked the “Close position” button, or whatever it was labeled.

This opened the “New order” screen, with fields pre-filled to perform a margin trade in the opposite direction for the same amount, the logic being that it’d cancel out the existing position, effectively liquidating it.

Having proceeded to innocently click on the inviting “Submit” button I ended up blocked with a “Margin allowance exceeded message”. Pause. What the fuck did it even mean to not have enough margin to close a position? A second attempt yielded the very same result.

My subsequent message to their support plainly stated the issue:

Hello,

I’ve been unable to close a 20 BTC short I opened around ~749 XBT/EUR.
I have more than enough funds on my account to take this loss without problems, yet your interface keeps telling me that closing my position would « Exceed my margin » !

This position is quite clearly in the red which is my responsibility, letting me close it and take my loss is your responsibility. I obviously can’t accept the loss part that’s due to your system not working correctly.
I should obviously not be limited by « margin » considerations when the trade I’m making is reducing my exposure and decreasing the size of my net position.

The position I want closed was opened with the [redacted] order, my account name is [redacted].

Please let me know ASAP.

David FRANCOIS

A day later, after some excuses about “busy”, “working hard to clear the queue”, I got an actual answer from Mike, let’s call him Luc.

Hi David,

I am consulting with our trading specialists at the moment to confirm exactly what the cause of this may be. I do note that you currently have 4 open orders (albeit untouched ones). Can you cancel these orders and then attempt your position closing order again and let me know how it goes?

Best regards,

Mike
Kraken Client Engagement

Luc was indeed correct, I did have four untriggered STOP[2] bids, they had however never been activated (the confusion in the vocabulary between “untouched”, as in “in the book but not yet touched” and “untriggered” as in “in the pending stops, but not triggered, and as such not even in the order book” continued throughout).

So far there were two problems: the first being that liquidating the position apparently required some sort of “margin allowance” in other words “borrowing money”, and the second being that Kraken’s support suggestion was to try something that should have had no effect on one’s ability to borrow money (cancelling orders that hadn’t been activated).

I therefore, logically, answered that:

If your engine has a measure of « allowed margin » that is impacted by these orders and prevented me from closing the position, then that’s obviously a bug on your end that requires fixing on your end, and compensation for the extra loss I’m incurring due to my impossibility to close the position.

After consulting with the “trading specialists”, Luc ended up telling me that, lo and behold, these untriggered orders somehow did indeed count against a borrowing limit, nevermind that closing a position shouldn’t require additional borrowing, and nevermind that I should have theoretically received the bulk of the funds required to buy back the shorted Bitcoins through the very sale of… the shorted Bitcoins!

Hi David,

We have confirmed that your open orders, even while untouched do count towards your total margin borrow limit due to this there was insufficient remaining EUR margin borrow limit for you to place one single order to close your position.

Your original position was a XBT/EUR sell on margin, meaning that the security borrowed for this was XBT so was counted against your XBT margin borrow limit.

Your original closing orders and the further closing position where you encountered the error are all XBT/EUR buy orders on margin which are counted against your EUR margin borrow limit. There is no way for us to tell in advance which pending orders you may have which will close or even reverse an open position so all are counted towards your margin borrow limit.

[Additional servings of apologies for inconveniences and SFYLs]

After pointing out to them how their own documentation plainly contradicted the actual behaviour of their system, they came back with the following gem:

The only problem we acknowledge here is that we could be more explicit in our documentation about the fact that orders placed which will create margin positions are counted towards your Margin Borrow limit as soon as they are created, regardless of whether they have been fully or partially filled yet. We will be updating our support centre documentation on Margin Borrow limits to make sure this is clearer.

So here we are, let’s kick back and let it sink in for a minute.

Ready? The translation reads: “yes, our software doesn’t behave like its documentation said it should, we will update this documentation, but this isn’t a bug[3], because reasons”. In other words: “Fuck you and SFYL lol”.

The gist of the insanity can be enumerated as follows:

  • Liquidating existing positions is somehow subjected to borrowing limits, in addition to those already checked against when opening the position,
  • These “borrowing limits” are computed by also taking into account orders that haven’t activated at all (not untouched, not filled partially, not filled completely, but NOT ACTIVATED AT ALL),
  • When closing a position there’s suddenly no trace of the proceeds of the initial trade which created the position, which in any system that’s not completely insane, would obviously be used in priority when liquidating,
  • Given these insane rules you can put yourself in a position where it is not possible to liquidate a position other by dicking around manually in small chunks and without the ability to place STOPs[4]!

In conclusion I’ll point out once again the fucking elephant in the room: the proceeds of a trade with borrowed assets are somehow not yours to use to make the opposite trade in order to return said borrowed assets. Because Kraken is a special, and because they’ll soon update their documentation to redefine the meaning of the word “borrow”, and because “sorry for the inconvenience, don’t forget to protect your account with a second authentication factor”.

 


[1] Margin trading, for the noobs among us, basically consists in trading funds one doesn’t have by borrowing them, on the premise that one should at least provide enough cash upfront to cover for the variations in value of the resulting position.

For example, should one want to bet on a Bitcoin’s price increase, one could provide 1`000 EUR upfront, borrow 10`000 EUR and buy the equivalent of these 10`000 EUR in Bitcoin. Should the price of Bitcoin appreciate, one could, at any time, liquidate this position by selling the Bitcoin, return the 10`000 EUR to the lender, and pocket the difference as profit. Should one’s prediction end up incorrect, the loss would be accounted against the cash deposit. This is also referred to as “leveraged trading”. Usually, to minimize counterparty risk, the lender can force a position to be liquidated when the net loss gets close the to the deposited cash, also referred to as “collateral”.

[2] Again, for the noobs among us, STOP orders are orders that get automatically activated once the price reaches a certain point, they’re quite useful to automatically take a profit on profitable positions, or cut losses on unprofitable ones.

[3] Once in a while, paedopedia makes itself useful and aptly notes that: “A software bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways”

[4] For example, their “Margin borrow limits” state a Tier-3 trader could borrow 150 BTC and 25kEUR for the purpose of margin trading. If such a trader were to short BTC up to the borrowing limit, and given the current BTC market price (around ~900 EUR per), it would not be possible to liquidate this position in one go without hitting the EUR borrowing limit. In other words one would have to do it manually in at least six passes. And since apparently untriggered STOPs also count against these limits, one would not have the option to place stop-loss or take-profit orders for 100% of the position size. If that doesn’t demonstrate a completely broken design, I don’t know what else could…

BitBet conclusion statement

As the final settlement transaction has been broadcast, the receivership is now considered officially closed. All BitBet customers with outstanding bets have either been fully refunded, or paid out of their winnings.

While the receivership itself was of moderate complexity, my job was made considerably easier by the help and professionalism of Mircea Popescu and Matic Kočevar. I thank both of them very much for entrusting me with this task. I hope they, and the other stakeholders, are satisfied with my service.

The Bitcoin Foundation’s tax, due on the receiver’s fee, has been paid.

BitBet proposed settlement transaction

As promised after the successful sale of the BitBet assets and after the correct reception of the rest of the cash, the final settlement transaction is being put on display as an opportunity for the public to voice any complaints or concerns.

If no valid points are raised that would require modifications by Wednesday the 20th of April the transaction will be signed, broadcast, and the BitBet receivership will be considered closed.

Please not that amounts going to identical addresses are aggregated, the amounts owed to Mircea Popescu have already been deducted.

As usual, questions and comments are welcome.

Second version of the raw transaction.

The raw transaction.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

TXID of the the second version of the unsigned BitBet receivership final
settlement transaction being put on public display today.

ab1e4c34b1108c5e8d7285ff8761ab8a2768b2263bab894a695c3f693521c3fb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJXEoIhAAoJEBMojqsBcTQoDHEH/RDbZ8QNrKiTfQIBDr9e5l8x
yxn573jDVUf9NyfYJDZkF1dgxcWUN7WLu5C2z1MWqA5e9loLrDNGP9YCJzrOeksk
3nvBg6/MOb6l2+Ivaona5bWoeZF2SnZircq+QhFgSMtZUzrw9nOkM87ONW29Zeq6
A96FPVsmI9SgiJS7geRT5Cu4txKov9xbwYG2akVPqF5zT/0XE9L9lz8bGtEd10Zj
XcfuEY6RZfyd77DFx/TeUWzpyDwUZaIRIS5fsUcn10tYQursDZe2zgOMYnVhGFON
YvA0NitGEwgGxi6ThyyYJaylH/94TXGse3ySqeiCX2tSm57Lxf7X9VK2sJRdrnc=
=xz+S
-----END PGP SIGNATURE-----

BitBet receivership third progress report

April 14th update: As discussed in #trilema [1, 2], it appears BitBet owes Mircea Popescu the sum of 0.8 BTC for the seeding of bets that has not been billed to the company yet, as was normally the case. This includes all bets[5] that were seeded after the last report certified by both representatives. This amount has been accounted for in the liabilities.

Erratum: BitBet’s receivership first report mentioned a hot wallet amount that was off by 0.00040948 BTC, the report has been corrected.

State of the receivership process

As planned, the assets auction ended last week. The 86 BTC payment has been received
and confirmed. The actual assets have been transferred, eight bets have been resolved[1], the rest will be refunded.

Assets: 1`040.78385211 BTC, detailed as:
  - Cash: 1`040.78385211 BTC (of which 841.33337474 BTC is currently under my control): 
    (1) Outstanding bets: 942.81955914 BTC,
    (2) Unpaid resolved bets: 8.75451297 BTC,
    (3) Zeroconf bets on unhandled proposals: 1.99978000 BTC,
    (4) Gracious donations: 1.21000000 BTC,
    (5) Sale of the assets: 86.00000000 BTC.    

Liabilities: 961.58027519 BTC, detailed as:
 - House bets paid for by Mircea Popescu: 0.8 BTC
 - Receiver's fee: 13.37 BTC
 - Bettor winnings: 331.01977044 BTC[2]
 - Bettor refunds for unresolved bets: 614.38072474 BTC[3]
 - Bettor refunds for zeroconf bets on un-handled proposals: 1.99978000 BTC
 - Bitcoin transaction fee for the payout transaction: 0.01000001 BTC[4]

Net surplus: 79.20357692 BTC

This net surplus is to be distributed to shareholders. The 5 million MPEx-traded shares are being guaranteed a minimum value of 0.00001 BTC per amounting to a 50 BTC total. This leaves 29.20357692 BTC to be split equally between Matic Kočevar and Mircea Popescu, joint holders of the rest of the 10 million BitBet shares.

See the detailed liabilities table for more information and don’t hesitate to point out any errors or inconsistencies in the comments.

[1] The resolved bets:

[2] The ‘bettor winnings’ item does not include the house bets winnings as a liability anymore (0.67314231 BTC). The sum of the house bet winnings and the bettor winnings differs from the previously reported sum by 115 satoshi as a result of rounding being applied in one case to the lump sum, and in the other case to each one of the amounts that will be paid out.

[3] The ‘bettor refunds for unresolved bets’ does not include the house bet refunds as a liability anymore (2.15000000 BTC)

[4] This particular amount was picked because the payout transaction will be quite large, and because an even number of satoshis was needed for the amount to split among the BitBet representatives.

[5] The bets that were seeded, but not billed to the company:

+---------------------+--------------------------------------------------------------------+
| Seeded              | Title                                                              |
+---------------------+--------------------------------------------------------------------+
| 2016-03-11 17:12:55 | John Kasich gets the Republican Party Nomination                   |
| 2016-03-07 04:31:49 | UK referendum will result in favour of remaining in EU             |
| 2016-03-01 20:21:45 | Bitcoin to top $900 before Sep 2016                                |
| 2016-02-29 16:50:15 | Donald Trump will win the 2016 United States Presidential Election |
| 2016-02-12 06:16:02 | AlphaGo will defeat Lee Sedol overall in March 2016 match          |
| 2016-02-12 06:00:42 | Ethereum to top $1 billion market cap before 2017                  |
| 2016-02-04 17:46:50 | Parties SMER-SD and SNS to win supermajority in Slovak parliament  |
| 2016-02-04 06:42:37 | Ted Cruz will be the Republicans' 2016 Presidential Nominee        |
+---------------------+--------------------------------------------------------------------+

BitBet auction: a winrar is znort987

Update April 8th: The payment has correctly confirmed, BitBet’s new owner can take possession of the actual goods and is kindly asked to issue a receipt to the receiver.

As announced, the BitBet auction has taken place, and after a few deadline extensions and an almost-winner, znort987 (9F1C2534ACEE115E18EF02A5FD5AA2A5E26602B0) ended up being the last man standing.

In order to proceed, he is kindly asked to transfer the sum of 86 BTC to 1DavouTAsveznCFHsz688xvbrRAq4u2qm8. Once the payment is confirmed, the assets will be transferred.

I will then start working on creating the final settlement transaction paying all outstanding liabilities. Once the transaction is ready it will be put on public display for a few days. If no complaints are made or discrepancies pointed out, it’ll be signed and broadcast.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In order to complete the sale of the BitBet assets to 9F1C2534ACEE115E18EF02A5FD5AA2A5E26602B0,
the sum of 86 BTC is to be transferred to the 1DavouTAsveznCFHsz688xvbrRAq4u2qm8 address.

Once the payment is confirmed, the assets will be transferred to their new owner.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJXBvLGAAoJEBMojqsBcTQo1rkH/0tm8u8f91+Tt4JjU7L1ZPj6
CE5MoOSjlLyYoFZyBbH3yJImJseDpvDxO+DA+MDK+SPoS8WEP7bpSLcA7xlwdc7h
kPhvq4klSUSvHcAFXwYpjq/E1QxgPL2+tPVWSgT7eMWmflXKhjBpBtb47cUZwJCz
x9z7KCqhjzcwqSB7iRNJnbuIZv707VYaROd211/4N8AvKanPZLVTUlDOladyCkdS
M9Cyf6nG8RsMkB2blb2jad9FlWgXWb8ZlrifoEp9WFKXeYpw1AeJkhqWl1rTuXrm
uYjWcmuSwOQWF7tC4Fy+bm3YJYdNjOuvzA9weaHo40+DHfFWpayGWogx2X/8bsM=
=wK75
-----END PGP SIGNATURE-----

BitBet auction deadline postponed (slightly)

As Pete Dushenski aptly points out, “the end of Wednesday the 6th of April” doesn’t precisely define a deadline for the BitBet assets auction.

Therefore it appears to me that, in the interest of maximizing the auction revenue, the most sensible course of action is to interpret this as “the end of Wednesday the 6th of April in whatever timezone this event happens last”.

The precise auction deadline is therefore 2016-04-06 23:59:59 GMT-12, which conveniently reduces to “Thursday the 7th of April at noon GMT”.

As already said the auction ends one hour after the last best bid improving the previous one by over one Bitcoin has been posted, or at the specified deadline, whichever comes last.

The conclusion of all of this naturally being:

<mircea_popescu> you’re like totally a noob receiver and everything.

So long Paymium!

As of tuesday the 29th of March I do not work for Paymium anymore, and remain only a shareholder with no control over the operations.

This statement is made to give interested parties the opportunity to make their own determinations regarding their continued or planned involvement with Paymium.

I will remain involved in Bitcoin, as I have been since 2010, when I built the product Paymium operates today.

As an other consequence, any further X.EUR deliveries will be made by SEPA wire.

BitBet receivership second progress report

State of the receivership process

As BitBet’s receiver I am pleased to present this second progress report to all the interested parties. The next progress report will be published after the auction is completed, it will list the final payout amounts and beneficiaries for public review.

Auctioneering of the assets

As of today, the highest bid for the BitBet assets (other than the cash) is 9 BTC, by Stanislav Datskovskiy, aka asciilifeform.

The Twitter account will be included in the package, there is an API access key in the code, control over the domain will also allow the buyer to reset the account password.

BitBet’s hosting is currently provided graciously by Matic Kočevar. The buyer is expected to provide his own hosting setup. I will setup and provide the necessary infrastructure in the interim to keep BitBet online, should Matic Kočevar request so.

In the interest of maximizing BitBet’s assets, the bidding deadline will be extended if necessary. The precise deadline will be the end of Wednesday the 6th of April (as previously stated), or one hour after the last bid that improved the previous best bid by more than one full Bitcoin, whichever comes latest.

State of the assets and liabilities

Assets

My inventory of the assets has shown a discrepancy between their theoretical amount, and the amount I currently have under my control, the difference is 199.45006789 BTC. Mircea Popescu has stated he would have the numbers checked, and provide a complimentary sum, if applicable.

Liabilities

The liabilities I have certified are:

  • Receiver’s fee: 13.37 BTC
  • Bettor winnings: 331.69291390 BTC (335.04334737 BTC before 1% fee)
  • Bettor refunds for unresolved bets: 616.53072474 BTC
  • Bettor refunds for zeroconf bets on un-handled proposals: 1.99978000 BTC

I did not certify Mircea Popescu’s claim to 17.94766149 BTC. The BitBet contract, as signed by Mircea Popescu and Matic Kočevar, explicitly states:

3.2(d) All decisions with regards to any aspect of BitBet, measures taken in regards to any aspect of BitBet operation, any actions, activities or agreements involving BitBet will require unanimous agreement of all the representatives of BitBet. Any such decision, measure, action, activity or agreement which fails to obtain unanimous agreement of all BitBet representatives is void and unenforceable.

As of today, Matic Kočevar still refuses to endorse the decision to proceed with a second payment, as per the contract the decision can therefore only be considered void, and its consequences unenforceable. As a consequence it follows that BitBet may not deduct the amount that was paid a second time from its liabilities to certain winning addresses.

BitBet receivership first progress report

State of the receivership process

After working a few days on the BitBet receivership process I am pleased to present all interested parties with my first progress report. The work I have undertaken during these few days focused mainly on the identification and accounting of the theoretically available assets, as well as the listing of existing claims against BitBet.

As of today, I have received:
– from Matic Kočevar: the deedbot’d DB, codebase, and contents of the hot wallet amounting to 4.83337474 BTC [1, 2]
– from Mircea Popescu: the bitbet.us domain and the sum of 750.5 BTC.

Auctioneering of the source code, database and domain name

The source code, database, and domain will be auctioned as a single package during the next week, bids should be published directly in the comments, the highest bid at the end of Wednesday the 6th of April 2016 will be retained as buyer for the whole package.

After the completion of the auction I will publish a final list of assets, the list of certified claims (after resolving whatever bets can actually be resolved at that point in order to maximize the fee revenue). After that I shall give a few days for interested parties to comment and finally proceed to the actual transfers (Bitcoin and other assets).

State of the assets and liabilities

As of the today, the minimum  value of the assets in my possession is ~755 BTC, while the maximum total amount for the liabilities, should all claims be certified, is ~981 BTC.

Assets:
  - Cash: 954.78385211 BTC (of which 755.33337474 BTC is currently under my control): 
    (1) Outstanding bets: 942.81955914 BTC,
    (2) Unpaid resolved bets: 8.75451297 BTC,
    (3) Zeroconf bets on unhandled proposals: 1.99978000 BTC,
    (4) Gracious donations: 1.21000000 BTC.

  - Non-cash assets for which the value is to be determined during the auction:
    - the 'bitbet.us' domain name,
    - the BitBet database,
    - the BitBet source code.

Liabilities: 981.54108013 BTC, detailed as:
 - Mircea Popescu's bill: 17.94766149 BTC
 - Receiver's fee: 13.37 BTC
 - Bettor winnings: 331.69291390 BTC (335.04334737 BTC before 1% fee)
 - Bettor refunds for unresolved bets: 616.53072474 BTC
 - Bettor refunds for zeroconf bets on un-handled proposals: 1.99978000 BTC

Data used for this report

See the data files in plain text format, or in CSV format.

The lists of Bitcoin addresses to be used by BitBet, as transmitted by Matic Kočevar and clearsigned by Mircea Popescu [1, 2].

April 6th update: additional data as per my response to hanbot’s comment. It includes the outstanding bets as well as the resolved but unpaid ones. It also has the resolution timestamp included.