Voting Pool Withdrawal Process

From Open Transactions
Jump to navigation Jump to search



Customers will normally request a withdrawal of bitcoins from the pool by interacting with the service front end web site or some other software application. When the service receives such a request, it notifies the OT client via the OT client API function: outBailment.

When the OT client receives notice of a user desire to withdraw funds from a voting pool, via any method, it sends an outBailment transaction request to the notary containing the destination Bitcoin address where the withdrawal should be sent, the amount of the withdrawal, and an extraFee value. The extraFee is added to the transaction fee required by the Bitcoin network and is paid directly from the user’s balance and may be zero.

Note: Some customers may wish to have additional restrictions placed on withdrawals, for example to prevent withdrawals to arbitrary Bitcoin addresses, or to require two-factor confirmation of withdrawals, or time delays to allow for notification and manual review of withdrawal requests. All this functionality and more can be provided by users electing to store their deposits in an OT smart contract instead of a standard receipt. Discussion of the capabilities of OT smart contracts is outside the scope of this document.

After the notary receives the outBailment transaction request, it removes the total amount from the user’s balance and places it in the outbox as a pendingBailout receipt.

Type 2 Event - Withdrawal blocking
The notary handling a customer account may fail to respond to a valid withdrawal request

When the auditors see the pendingBailout receipt, they create an entry in their withdrawal database and add the pendingBailout to their queue for the next consensus.

Consensus Round

Transaction Formation

Each time a new consensus is finalized, the auditors begin processing the specified pendingBailouts (if any) by passing the address identifier of the first input to be used, the address identifier of the first change address to be used, and the withdrawal identifier of each output to the Bitcoin wallet via the startwithdrawal API call.

The startwithdrawal API call accepts a list of outBailments to process, and the set of parameters which are needed to ensure the transaction process is deterministic.

When the wallet receives this call, it processes the list and parameters per the transaction construction algorithm and returns a list of signatures and status information for each outBailment.

If the wallet requires the private keys from additional series in order to filful the outBailments, that information will be returned with the status information.

Signature Exchange

The auditor takes the signature list from the wallet and broadcasts it to the rest of the auditors. It also collects signature lists from the other auditors and queues them for delivery to the wallet.

Transaction Fee Accounting

Before the auditor can provide the missing signatures to the wallet, it must ensure the transaction fee has been properly accounted for. While the auditor is broadcasting and gathering signatures, it also sends a txFeeNotice message to each notary from which a withdrawal has been processed, indicating their share of the blockchain transaction fees included in that consensus round.

Blockchain transaction fees are allocated to a specific server by the fraction of total withdrawals in the round which originated from that server. The method of calculating the individual shares should ensure the individual totals add up exactly to the blockchain transaction fees consumed by the transaction.

When the notary receives at least m identical txFeeNotice messages, it then performs a balance adjustment by subtracting the amount from its service account for the pool, and adding that amount to the issuer account for the pool. The auditor cannot release the rest of the signatures to the blockchain wallet until it validates the appropriate balanceAdjustment notice in the audit stream.

Type 0 Event - Transaction Fees Accounting
The originating notary may fail to deduct blockchain transaction fees from its service account and broadcast this receipt in the audit stream

When the auditor validates all needed balanceAdjustment notices, it delivers the signature lists to the wallet via the updatewithdrawal API call. The blockchain wallet then adds signatures to the transaction(s) until it has m, then it broadcasts the transaction(s) to the network. It is not necessary for each wallet in the pool to include the same list of signatures in the transactions they broadcast. As long as all the transactions are valid, the network should accept one version and include it into a block.

Type 2 Event - Transaction Signature Error
All or a portion of the signatures a wallet receives from the other pool members may be invalid for the given transaction.

The startwithdrawal API call returns a list of one or more normalized transaction identifiers (ntxid), where each ntxid is linked to a list of the withdrawal identifiers corresponding to the outputs in the transaction. The auditor updates its withdrawal database with the ntxids, and begins tracking the confirmation status of the withdrawal. It reports all this data to the notary, and each new confirmation of the transaction.


Like deposits, withdrawal transactions are not considered final until maturation_time confirmations have occured. Once the auditor reports a number of confirmations greater than or equal to maturation_time for the blockchain transaction associated with a pendingBailout receipt, the notary replaces that receipt with a completedBailout receipt. When the auditors see the completedBailout receipt in the audit stream they can prune the associated entry from their withdrawal database and stop sending confirmation updates.

Type 2 Event - Failed Withdrawal Transaction
The Bitcoin network may fail to confirm any version of the withdrawal transaction.