taler-docs

Documentation for GNU Taler components, APIs and protocols
Log | Files | Refs | README | LICENSE

bitcoin-limitation-manual.rst (2269B)

      1 ..
      2   This file is part of GNU TALER.
      3   Copyright (C) 2026 Taler Systems SA
      4 
      5   TALER is free software; you can redistribute it and/or modify it under the
      6   terms of the GNU Affero General Public License as published by the Free Software
      7   Foundation; either version 2.1, or (at your option) any later version.
      8 
      9   TALER is distributed in the hope that it will be useful, but WITHOUT ANY
     10   WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
     11   A PARTICULAR PURPOSE.  See the GNU Affero General Public License for more details.
     12 
     13   You should have received a copy of the GNU Affero General Public License along with
     14   TALER; see the file COPYING.  If not, see <http://www.gnu.org/licenses/>
     15 
     16   @author Antoine d'Aligny
     17 
     18 Bitcoin Depolymerizer Limitations
     19 #################################
     20 
     21 The Bitcoin blockchain operates differently from fiat currencies and traditional bank accounts.
     22 Consequently, certain design choices must be made to integrate it with GNU Taler.
     23 
     24 Creditor Address
     25 ================
     26 
     27 In the GNU Taler model, accounts are unique, and transactions occur between a unique creditor and a unique debtor account.
     28 
     29 Because Bitcoin aims to provide a form of pseudonymization, it does not follow this one-to-one model. We use a single Bitcoin address as the identifier for a unique account. To fit the Taler model, we must designate one of the transaction inputs (vin) as the debtor. We always consider the first input of the transaction as the incoming source, and the corresponding scriptPubKey of that input's origin vout as the debtor account.
     30 
     31 If you want to perform KYC verification to prove ownership of a Bitcoin address, you must manually create a transaction that uses the corresponding address as the first input.
     32 
     33 Boucing transactions
     34 ====================
     35 
     36 When a withdrawal is malformed, an adapter should attempt to return the funds to the debtor. We have chosen to implement this logic for depolymerizer-bitcoin, even though it is not a perfect solution.
     37 
     38 Under this logic, we return all funds to the address we identified as the debtor (the first input). If you share an address with other users (which is common on third-party platforms or exchanges), it may be difficult for you to identify the returned funds as yours.