I'm currently doing a few tests with bitcoin core 0.13.2 and I've noticed that decoderawtransaction has a strange behavior when used on some segwit txs (e.g: a24cec50d5cf861d1af4b634f8ed1968c0e9484724bfef5af7f8c383605978c8)

Everything seems ok if I call getrawtransaction in verbose mode for this txid

Code:

> getrawtransaction "a24cec50d5cf861d1af4b634f8ed1968c0e9484724bfef5af7f8c383605978c8" 1

{
  "hex": "02000000000101c564a62f94c025ac80137817d8658aabceaaad30412facecba1bd2255182e1c40000000000ffffffff01ca124c000000000016001443aac20a116e09ea4f7914be1c55e4c17aa600b7024730440220679eaf5e41eee49b38f3112ec90b49a655db21677db4d7fa80de67aeb987161102204024b85730fc106d0b870623fc221946e624413363eb627fe90eb5047d35565c012103335134d7414e1d1a154600b124a96f5ef2c6ca21434d2622469a96bd5262fd5600000000",
  "txid": "a24cec50d5cf861d1af4b634f8ed1968c0e9484724bfef5af7f8c383605978c8",
  "hash": "54ad9b3b24064c4033814ddc712a393cfa4e011eb7ac24374687511cd056eac5",
  "size": 191,
  "vsize": 110,
  "version": 2,
  "locktime": 0,
  "vin": [
    {
      "txid": "c4e1825125d21bbaecac2f4130adaaceab8a65d817781380ac25c0942fa664c5",
      "vout": 0,
      "scriptSig": {
        "asm": "",
        "hex": ""
      },
      "txinwitness": [
        "30440220679eaf5e41eee49b38f3112ec90b49a655db21677db4d7fa80de67aeb987161102204024b85730fc106d0b870623fc221946e624413363eb627fe90eb5047d35565c01", 
        "03335134d7414e1d1a154600b124a96f5ef2c6ca21434d2622469a96bd5262fd56"
      ],
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 0.04985546,
      "n": 0,
      "scriptPubKey": {
        "asm": "0 43aac20a116e09ea4f7914be1c55e4c17aa600b7",
        "hex": "001443aac20a116e09ea4f7914be1c55e4c17aa600b7",
        "type": "witness_v0_keyhash"
      }
    }
  ],
  "blockhash": "0000000000001f21187cb667bdb30109a24bf42821f58b0cedf8c7d5641cbc33",
  "confirmations": 172230,
  "time": 1467400024,
  "blocktime": 1467400024
}

Now, here is what I get if I call decoderawtransaction with the hex of this tx

Code:

> decoderawtransaction "02000000000101c564a62f94c025ac80137817d8658aabceaaad30412facecba1bd2255182e1c40000000000ffffffff01ca124c000000000016001443aac20a116e09ea4f7914be1c55e4c17aa600b7024730440220679eaf5e41eee49b38f3112ec90b49a655db21677db4d7fa80de67aeb987161102204024b85730fc106d0b870623fc221946e624413363eb627fe90eb5047d35565c012103335134d7414e1d1a154600b124a96f5ef2c6ca21434d2622469a96bd5262fd5600000000"

{
  "txid": "54ad9b3b24064c4033814ddc712a393cfa4e011eb7ac24374687511cd056eac5",
  "hash": "54ad9b3b24064c4033814ddc712a393cfa4e011eb7ac24374687511cd056eac5",
  "size": 191,
  "vsize": 191,
  "version": 2,
  "locktime": 0,
  "vin": [
  ],
  "vout": [
    {
      "value": 27203371073.07775233,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_LEFT 7817d8658aabceaaad30412facecba1bd22551 OP_SIZE OP_UNKNOWN OP_UNKNOWN 0 0 0 0 0 OP_INVALIDOPCODE OP_INVALIDOPCODE OP_INVALIDOPCODE OP_INVALIDOPCODE -74 4c000000000016001443aac20a116e09ea4f OP_PICK be1c55e4c17aa600b7024730440220679eaf5e41 OP_UNKNOWN OP_UNKNOWN OP_BOOLOR f3112ec90b49a655db21677db4d7fa80de67aeb987161102204024b85730fc106d0b870623fc221946e624413363eb627fe90eb5047d3556 12 33 3428659 OP_UNKNOWN [error]",
        "hex": "80137817d8658aabceaaad30412facecba1bd2255182e1c40000000000ffffffff01ca124c000000000016001443aac20a116e09ea4f7914be1c55e4c17aa600b7024730440220679eaf5e41eee49b38f3112ec90b49a655db21677db4d7fa80de67aeb987161102204024b85730fc106d0b870623fc221946e624413363eb627fe90eb5047d35565c012103335134d7414e1d1a154600b124a96f5ef2c6ca21434d2622469a96bd5262fd56",
        "type": "nonstandard"
      }
    }
  ]
}

From my observations, everything seems ok for txs with P2WPKH or P2WSH nested in P2SH.
Do I miss something ? Is it a known issue (or temporary limitation or decoderawtransaction) ?

Thanks in advance !

Hi there,

A (stupid) question about segwit : what happens if I use a P2SH script (HASH160 <20-byte-hash> EQUAL) as the witness script of a P2WSH scriptpubkey ? Is it processed as a simple validation of a hash or does it also trigger the evaluation of the P2SH script ?

Thanks in advance !

[A more formal analysis would be welcome.]

FWIW, here are a few observations related to the growth of the utxo set.

EDIT: For a TL/DR, you can jump to the conclusion

The growth rate of the utxo set has increased since late 2013 / early 2014.


(please note this chart counts the cumulated number of utxos in the blockchain (different from the utxo set of bitcoin core) but this observation remains valid for the utxo set in bitcoin core (can be checked with statoshi tool)).


More interestingly, a repeated pattern has appeared since early 2014, showing steps every sunday (around 100k utxos added to the set every sunday).




This pattern is interesting because activity in the bitcoin network is low on sunday in term of number of transactions




or in term of volume




We can also observe huge peaks every sunday in the average number of utxos created per transaction


(max value is the average number of utxos created per transaction at blocks level and is the max value among all blocks created on a given day)


A few months ago, my intuition was that these peaks are "caused" by a small number of actors (bitcoin services ?) reorganizing their utxos or doing some weekly payment. A very quick manual check in the blockchain led me to think that faucets doing weekly payments may play a role here but others actors may also have a role. A more formal analysis would be welcome.

So, please, don't get me wrong. I don't call to a new witch hunt targeting some actors from the ecosystem. Even if these observations are correct, there's no hint of a malicious intent. Actually, it's quite the opposite, if we consider that these transactions occur during low activity periods in the network.

Here's my point:
If the current growth of the utxo set is caused by a small number of actors, it's possible that these actors may change a few things in their model without disrupting their business. For example, if it appears that faucets doing weekly payments are the main cause of the actual growth, may be they could replace weekly payments by monthly or quaterly payments. A payment done every 2 or 3 months may decrease the growth by one order of magnitude. It's by no means a solution to scalability issues but it may be an "easy" way to buy more time and that sounds like a good news.

My 2 satoshis

Just a little game.

Will you find the common denominator of these transactions ?
https://blockchain.info/tx/01b5fc9c33633af82f01eaf2ef94cce21077066a01f05293a64f936ba75bb2a0
https://blockchain.info/tx/2ecc6a57dec613272adbd2bebc3a78259de1ecf964e099a3d5c2765785c606a0

No clue ? Two more examples:
https://blockchain.info/tx/1892c498a9af56157c50ce62ccfb462afe987f3f29d31c36ee3b37f7c688ca3e
https://blockchain.info/tx/b91719b0cf09a119ee052ecf93fb83128168f3f3f309a7d9f60514e7a6cccb7f

Hint: privacy, merged inputs

EDIT 07/03: Answer added into the title of the post

[f2941f...]

I've just found a strange script in the first input of this transaction. It looks like a PS2H inside a P2SH :

scriptPubKey = OP_HASH160 f2941f... OP_EQUAL
scriptSig = OP_PUSHDATA1 98 4c96225... 17 a914ced... 
  with a914ced... = OP_HASH160 14 cede0e... OP_EQUAL

My understanding is that :
- first, we check that hash160(a914ced...) = f2941f...
- then, we check that hash160(4c96225...) = cede0e... (the redeem script acts like a puzzle)

But the script debugger seems to have a very different interpretation which I don't understand. Do I miss something ?

Salut,

Je me pose quelques questions "techniques" sur l'hébergement d'une startup à la Maison du BTC.
Comme ces questions sont assez générales et susceptibles d'en intéresser d'autres, j'ouvre ce thread plutôt que de contacter Thomas ou Eric en Off.

Donc, mes 2 questions du moment:
- Est il possible de domicilier la startup (adresse du siège) à la Maison du BTC ?
- Une startup hébergée à la Maison du BTC est elle soumise à la CFE (Cotisation Foncière des Entreprises) ?
  Si oui, quel est (approximativement) le montant de la CFE ?

Merci d'avance !

Bonjour à tous,

Je viens de pousser sur Github les sources et les specs du projet de protocole de marchandage proposé au hackathon de Juin à la Maison du Bitcoin.
Depuis le hackathon, j'ai cleané le code et complété les specs. Ca ne rend pas du tout justice au travail fait par Thibault sur l'UI de la démo mais ça a nettement amélioré la librairie.

De plus une démo est en ligne pour tester le protocole. Elle simule une online wallet permettant de négocier avec un vendeur qui est un bot minimaliste (négociant au hasard).

Les specs et les codes sources sont sur GitHub:

• Prez Hackathon
• Details & FAQ
• Draft Specifications
• Librairie Python
• Code source Python de la démo : Serveur Vendeur - Wallet Acheteur

Hi there,

The Bargaining Protocol is one of my toy projects, initially proposed at a bitcoin hackathon organized at La Maison du Bitcoin.

To be honest, the main goal of this project was to provide an excuse to hack code implying a bunch of bitcoin concepts (creation/validation of transactions, retrieving data from the blockchain, payment protocol, chain of signatures, ...). But the pitch was a bit more elaborated:

The Payment Protocol (BIP70) has been proposed to offer a better UX and better security on the payment process. Beyond being a payment solution, the Payment Protocol also perfectly matches with a trade model based on fixed prices. But trade models are strongly linked to cultures. Considering that Bitcoin is a global currency, it shouldn't be limited by cultural bias. It should embrace cultural diversity by promoting different models.

The Bargaining Protocol aims to transpose such an alternative model (based on prices negotiation) into the cryptocurrencies world.



This protocol should be a modern digital version of the bargaining process allowing:

• provable negotiations: messages form a chain of signatures which ensures that the terms of the negotiation can't be forged
• trust-free negotiations: at every step, the seller is assured that the buyer owns the funds to cover the pledge

Because of its digital nature, the protocol should also help to build advanced use cases:

• asynchronous bargaining: launch a negotiation, make a pause, complete later
• 1-to-N bargainings: a buyer (seller) can run multiple concurrent negotiations with multiple sellers (buyers)

Foreseen use cases:

• human-to-human negotiations : online bazaars, ...
• computer-to-computer negotiations : automated negotiation of resources (on-demand cloud service provisions), dynamic negotiation strategies (A.I.)
• human-to-computer negotiations : automated negotiation for e-merchants (travel retail, hotels, cars renting, ...), negotiation assistant for consumers, ...

For the record:

• the protocol takes inspiration in the Monotonic Concession Protocol from Games Theory (with some modifications: proposals are not simultaneous but sequential, more permissive stop conditions, ...)
• the protocol is a generalization of the Payment Protocol. Take the Bargaining Protocol. Remove the negotiation phase. Et voilà ! You've got the Payment Protocol (almost)

After the hackathon, I've spent some time to polish the code (i.e. rewrite the code), write draft specifications and release the whole thing on github:

• Hackathon prez
• Details and FAQ
• Draft of specifications
• Python library
• Python source code of the demo : seller's server - buyer's wallet

If you feel in mood for bargaining with a computer, try this DEMO which simulates an online wallet allowing to bargain with a seller (aka "MyStupidBot").

All comments, critics or suggestions are welcome.

Kudos to @thibaultj who gave me a hand to build the first version of the demo during the hackathon.

[involving New York or a New York Resident]

Il ne vous a surement pas échappé qu'un draft de régulation (BitLicense) a été proposé par l'état de New-York.
C'est assez chiant à lire et vous serez surement tentés de vous dire qu'on s'en fout vu qu'on vit en France.
Le problème, c'est qu'à New York, ils se prennent un peu pour le Pape et ont très envie de réguler "urbi et orbi".

Ainsi la section 200.2 (n) stipule

Virtual Currency Business Activity means the conduct of any one of the following types of activities involving New York or a New York Resident:
(1) receiving Virtual Currency for transmission or transmitting the same;
(2) securing, storing, holding, or maintaining custody or control of Virtual Currency on behalf of others;
(3) buying and selling Virtual Currency as a customer business;
(4) performing retail conversion services, including the conversion or exchange of Fiat Currency or other value into Virtual Currency, the conversion or exchange of Virtual Currency into Fiat Currency or other value, or the conversion or exchange of one form of Virtual Currency into another form of Virtual Currency; or
(5) controlling, administering, or issuing a Virtual Currency.

Interprétation: Si vous êtes une startup européenne proposant un service bitcoin en ligne avec des utilisateurs dans l'état de New-York :
- soit vous travaillez en toute légalité en obtenant au préalable une licence,
- soit vous interdisez l'accès à votre service à toute personne habitant dans cette juridiction,
- soit vous décidez de travailler dans l'illégalité avec l'inconnue de ce qui se passera le jour ou votre activité New-Yorkaise se sera bien développée...

Une autre section assez intéressante, la section 200.8 (b)

Each Licensee shall be permitted to invest its retained earnings and profits in only the following high-quality, investment-grade permissible investments with maturities of up to one year and denominated in United States dollars:
(1) certificates of deposit issued by financial institutions that are regulated by a United States federal or state regulatory agency;
(2) money market funds;
(3) state or municipal bonds;
(4) United States government securities; or
(5) United States government agency securities

Interprétation: si vous êtes une start-up européenne qui souhaite obtenir la licence, vous ne pouvez réinvestir vos gains qu'en US dollars, ce qui m'amène à penser que soit le régulateur new-yorkais n'est pas au courant que le devise légale européenne est l'euro, soit il n'envisage pas de laisser des sociétés autres qu'américaines travailler sur le marché New-Yorkais...

Je ne sais pas si des startupers, juristes et/ou l'association Bitcoin France ont déjà commencé à se pencher sur le sujet pour faire remonter des commentaires (à la Fondation Bitcoin ?) mais si ce n'est pas le cas ça semblerait bienvenu dans la mesure où bitcoin est un marché global pour les startups et où il est probable que le texte final servira de modèle à d'autres juridictions américaines.