<p>The miner which confirms current blocks on testnet is malleating transactions. I can confirm this. <a href="https://i.sstatic.net/dudi4.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/dudi4.png" alt="enter image description here"></a></p>

<p>But what is the problem? Current consensus rules allow this. Trust me. I am an expert in malleability :)</p>

CC BY-SA 3.0
2017-04-05T16:08:51.640Z
Finally, thank you!! who do we report this to?
Ben Muircroft
CC BY-SA 3.0
2017-04-05T16:10:37.637Z
Bitcoin is decentralized. There is no central authority to complain and send reports. This is normal behaviour. May be somebody is testing something.
amaclin
CC BY-SA 3.0
2017-04-05T16:11:16.277Z
for the last 2 weeks?
Ben Muircroft
CC BY-SA 3.0
2017-04-05T16:12:06.960Z
I do not see any problems here at all.
amaclin
CC BY-SA 3.0
2017-04-05T16:13:13.300Z
the problem is that i never see the malleated txs broadcast over the network (i only see the original txs)
Ben Muircroft
CC BY-SA 3.0
2017-04-05T16:17:06.733Z
It is your problem, not a bitcoin network problem :) nobody can help you because current clients do not relay HI-S transactions. So, they exist only on miner's node until confirmed in block
amaclin
CC BY-SA 3.0
2017-04-05T16:20:59.993Z
Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/56604/discussion-between-amaclin-and-ben-muircroft).
amaclin
CC BY-SA 3.0
2017-04-05T16:07:04.470Z
2017-04-05T16:07:04.470Z
amaclin
<p>Someone (let's call her Alice onwards) is messing up with testnet transactions, it happened to one of mines earlier today. </p>

<p><strong>What's happening</strong></p>

<p>Alice is changing the <code>s</code> representation of the EDCSA signature (<a href="https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm" rel="nofollow noreferrer">See ECDSA signature generation algorithm</a>) from at least one of the inputs of the transactions. By doing so, the signature is changing, but still valid, and thus the <code>txid</code> changed.</p>

<p><strong>How is she doing so?</strong></p>

<p>As explained in the <a href="https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki#low-s-values-in-signatures" rel="nofollow noreferrer">BIP62</a>, there are two valid representations of the <code>s</code> value, depending on how big the value is. Moreover, depending on the result the <a href="http://83f50b79edcc984387c62af876b42cdef0ae6c8a22ce0e74d541b7337d1fc15" rel="nofollow noreferrer">DER encoding may also be changed</a>.</p>

<p>Alice is simply modifiying  one of the the <code>s</code> values from one of the original transaction signatures, by performing a subtraction between the order <code>n</code> of the curve (that is <code>FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141</code> for the <a href="https://en.bitcoin.it/wiki/Secp256k1" rel="nofollow noreferrer">Secp256k1</a>), and the value <code>s</code>.</p>

<p>Example:</p>

<p>Lets say that the <code>s</code> component of a signature from one of out transactions is <code>s = 37c0af486123367bc7839d507894bd30cba3f61e0d1bbf54727e43199864452c</code>, if we substract <code>s</code> to <code>n</code>:</p>

<pre><code>s' = n - s = c83f50b79edcc984387c62af876b42cdef0ae6c8a22ce0e74d541b7337d1fc15
</code></pre>

<p>That is a valid representation of <code>s</code>.</p>

<p>Since <code>s'</code> starts by <code>0xc8</code>, which is bigger than <code>0x80</code>, the DER encoding will need a leading <code>0x00</code>:</p>

<pre><code>00c83f50b79edcc984387c62af876b42cdef0ae6c8a22ce0e74d541b7337d1fc15
</code></pre>

<p><strong>Who is doing so?</strong></p>

<p>It could be a miner, just as you suggested, but it could also be a normal node. </p>

<p>If its a miner, it could be doing the modifications just before including the transactions the block he is mining. On the other hand, if a normal node (better connected than you) receives the transaction, modifies it, and broadcast it, it could be included in a block instead of your original transaction. Notice also that, since you have been broadcasting the original transaction from your node, you are not likely to be aware of transactions trying to double spend it, since your neighbours (to which you have sent the original transaction) will drop the double-spending attempt and do not forward it to you.</p>

<p><strong>What can you do?</strong></p>

<p>You can forward the transaction from a different source that the one you are using to monitor the network, and do not rely transactions from the latter, in order to see what's going on. Moreover, you can monitor the network using the <code>UTXO</code> you are trying to spend (<code>prev_txid</code> + <code>index</code>) instead of the <code>txid</code> from the transaction you just created. If another transaction appears spending from the same source, you will know.</p>

CC BY-SA 3.0
2017-04-05T15:23:19.147Z
I am seeing all txs change id not just mine! I am collecting every txid I see broadcasted and putting them in an array called seen, then when a block happens i look for each tx on the block in my seen array. seen:0/63, seen: 0/45, seen: 0/87 etc.... all txs on testnet3 are changing txid
Ben Muircroft
CC BY-SA 3.0
2017-04-05T15:39:10.100Z
I know, as I said it happened to me also, I just considered all the possible cases.
sr_gi
CC BY-SA 3.0
2017-04-05T15:47:01.653Z
i updated my question, and if you give me about 20 minutes to add further proof i think it will suprise you!
Ben Muircroft
CC BY-SA 3.0
2017-04-05T16:06:19.410Z
I have posted indeniable proof in the question
Ben Muircroft
CC BY-SA 3.0
2017-04-05T16:14:22.907Z
Sorry, but what is the problem? Bitcoin transactions are malleable. The miner can use this technique and is using it now. Just live with this knowledge.
amaclin
CC BY-SA 3.0
2017-04-05T16:22:36.873Z
@ben-muircroft I don't get the point, no one is telling you that you are not right, just explaining you why it is happening.
sr_gi
CC BY-SA 3.0
2017-04-05T16:24:12.603Z
yeah i understand that. but i don't understand how I'm suppose to match a malleated txid in a block to the original tx
Ben Muircroft
CC BY-SA 3.0
2017-04-05T16:27:29.033Z
If what you want to do is just identify them, you can check which UTXO both transactions are spending, that is, which previous tx id and index both transactions are trying to spend. There will be two transactions spending from the same source, one in the block, and another one that you had received though the network.
sr_gi
CC BY-SA 3.0
2017-04-05T16:31:51.690Z
but i never see the malleated txs. I only see the malleated txid in the block so i don't know what outupts the malleated tx has
Ben Muircroft
CC BY-SA 3.0
2017-04-05T16:33:39.147Z
But you know the inputs of the transaction you have seen, you have to check with transaction in the new generated block is spending from the same previous output.
sr_gi
CC BY-SA 3.0
2017-04-05T16:37:28.240Z
but seen as I never see malleated txs broadcated i don't have anything to check
Ben Muircroft
CC BY-SA 3.0
2017-04-05T16:39:19.023Z
Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/56605/discussion-between-sr-gi-and-ben-muircroft).
sr_gi
CC BY-SA 3.0
2017-04-06T11:24:10.657Z
you were correct also about there being extra tx info inside blocks
Ben Muircroft
CC BY-SA 3.0
2017-04-05T13:50:59.443Z
2017-04-05T19:17:59.510Z
2017-04-05T19:17:59.510Z
sr_gi
<p><strong>Related</strong> <a href="https://bitcoin.stackexchange.com/questions/52539/how-confirm-my-own-doublespend-transaction-got-confirmed">How confirm my own doublespend transaction got confirmed</a></p>

<p>This is not about double spends and I believe that the related question is not about double spends ether!</p>

<p>On bitcoin's testnet3 I am seeing (using <a href="https://github.com/bitpay/bitcore-p2p" rel="nofollow noreferrer">https://github.com/bitpay/bitcore-p2p</a>) many tx change id</p>

<hr>

<p>scenario:</p>

<ol>
<li><p>I send some tBTC using <a href="http://testnetwallet.com" rel="nofollow noreferrer">http://testnetwallet.com</a></p></li>
<li><p>I see a utx with txid of XXXX broadcast onto the network with my inputs and going to my test address (everything looks cool)</p></li>
<li><p>I carry on monitoring looking at <strong>all broadcast-ed txs</strong></p></li>
<li><p>a new <strong><em>block</em></strong> happens.</p></li>
<li><p>I look through the txids in the block but do not find my txid</p></li>
<li><p>I query my receiving address on some block explorer web service and see that my tx's txid got renamed to YYYY</p></li>
<li><p>I go and look at the <strong><em>block</em></strong> again and see YYYY is in its tx array!</p></li>
<li><p>I discontinue monitoring <strong>all broadcast-ed txs</strong></p></li>
</ol>

<hr>

<p>I am starting to think that it (tx malleability) is happening when the miners are including the txs into the blocks!</p>

<p>I never see a tx with txid YYYY broadcasted <strong>NEVER</strong> (I am seeing every transaction!) this suggests that the txid is being altered!</p>

<p>I have been seeing this happen now for over 2 weeks and not found anyone talking about it apart for the first person today (4th april 2017) In the related question.</p>

<hr>

<p>I have been trying many things in my code to stop relying on the txid to identify if my tx has 6 confirmations. But, I am finding it impossible to <em>...update</em> my tx with its new txid!</p>

<p>I have been trying (many times in different ways) to ask peers (p2p peers) getdata for each unrecognizable txid in new blocks, but a lot of the time the peer seems to disconnect ....</p>

<blockquote>
  <p><strong>My question is:</strong> What should I be doing in this situation?</p>
</blockquote>

<p>Note: I'm trying not to use 3rd party services</p>

<p>also related: <a href="https://bitcoin.stackexchange.com/questions/52575/how-did-blockr-io-see-this">How did blockr.io see this?</a></p>

<hr>

<h1>UPDATE</h1>

<p>I am seeing all txs change id not just mine! I am collecting every txid I see broadcasted and putting them in an array called seen, then when a block happens i look for each tx on the block in my seen array. </p>

<p>for the last ten or so blocks today I have console.logged on each block</p>

<p>seen:1/52 by 73 peers
seen:0/4 by 73 peers
seen:0/35 by 73 peers
seen:0/22 by 73 peers
etc...</p>

<p>99% of all txs <strong>(everyones)</strong> on testnet3 are changing txid</p>

<p>I am listening to max peers 150</p>

<h1>PROOF THAT THIS IS HAPPENING TO EVERYONE'S TXs</h1>

<p><code>
{ hash: '00000000000017f2a1d8ff44f149e7ead61a38e1a03217c33762ed9ace3c0c7d',
  validProofOfWork: true,
  validTimestamp: true,
  prevHash: '000000000000178c28b96e945965b9311ea4005a66e8c5c2701d30f928a498d8',
  txs: 
   [ '775b7b0bf9345cbee62e3af57e1660a6fd92d0a089fd0694e4804a7190dd4a05',
     '1133ba34f4ef95af8a53c9698877cf8b7dc0e03d3095c371c0e2a1b8cd395ce2',
     '14df326c04bf2da2edbd4f9f04810916b95144eeef67570458c06449d3a56fc4',
     'b969a4bdab4b6a5ea91500b4230c3eadc9aa807cca000ecce6686450d2676b42',
     'fa5acc2feecae6a603673c6a817f79fa3a4dd1516d50c59014772c80500b7063',
     '0cd386804b65a3fb826557881dc3b50c1b298b7f0a0372da8faec97a2744d0e0',
     '24ca695bac05c4500a596415b70bd199c935308f7a90ccfc8ae01d7b96e6b115',
     '8125ed124dd4d0b3af98bc6028905fb329ff311c22f484be41bf9def8ea7b63e',
     '4f1e5a894be245d2a68c79e2b73dde54dbeaa8bb2e872b9b1115f40c0b93585b',
     'aee4a615c617d71c544930d5dbacdb62d66fb089d556d84cbe92682295895d91',
     '545b2164e6bc2e764a702eac1bd69e625c6100c8cbeaa9528c16cd74eb144ecb',
     '450c86ef90858943f6b6ba284da3987191880b2b534749d3ae762d7c9060bb7c',
     '83d9107d90c36b0302af47f2b7e7bece30aaf20431dcdf251faa025d31f02fa8',
     '4785a7fb5b0a6106152dc80d2c028b2aa80cb9b4f0ce81985b8c672a34561703',
     '232a70178859760c5cd75ae054c503af9db4515d92a47b9da17ca5c81cee5d34',
     '5c218f9e957cfd7fa97dbbdd29a81673d4c91b3441279c23607a7d3889533855',
     'b2472c88eb6c7a38476444c22cb560793624216e1e36354b406f15b09dd8316b',
     '5a7f3652282429eedf7bd2a6d0a8404e7844515f4139d14f8d7ed1e871efd373',
     '5147d190550b44eddad2d8ea6cdd022e47fe71a2517458b69c07c2424fd08bb2',
     '8e64ee1dcde8feb6b39ee043ecc43be719d0999ad181acee4d01e9d603976ff1',
     '0223ed8beb7d466d9d4026665d2ba58a97cbd1e6641be22f16d23be2b4574688',
     '18efc474f89835fb9eb1fa9ed1fc1dc296621aae3b727aab64f4f80ff76a098f',
     '8f38f6030a0471c7bef2b1e1757a6db0b63edf07aab3fe12a7e85d86b35c5eb5',
     '6b88744cba8f7661e64c67cd554d07a1b1981fe10614647a18b101520d289816',
     '6aee3deb7c0cb7247c2a85f14f96f8cb8447dee00e98a72ace80cbb850f5a709',
     '67de891a99a4c62fc90af91f5d880f9c2be80c1fc55bc444d10b74b63dd1ae1a',
     '62f955cf10d52f34a0b7bf2328c5095051d8dcf5009b65dd53632d54de4a515c',
     'c42685086053a0b2d989453b6f0cb17a1b60642ac963acc782b5269c8e563b89',
     'e2c2114e7cd15e47a84a4a48e7c1adbb29daff0f85afb5be6015a17271859909',
     'cc834a0f20e43f4eb05638398e8cfc61bfaaa303dcd82705be2c9cbf80189ded',
     '10907000e1062dc63c817b995683a4a7433836f450f763c910fe6191aa555f24',
     'a5bf7009e9c97b1b7652d3f5ed4067c1eeb40d1625e2fadb6ffb11ca18a27e74',
     '40c3ffce0140a9db634e4b869e79848f4316fd40528e48b0899e2b5606075ef2',
     '22b9db7c0ee380ec0c4eed97788dbf6f75fedbec569fb84a6c0d27bf36923cfa',
     'f4906eda20607d733ae55caf3274fa91d5c2f20506881857af59be4d8bb0af25',
     '98dfd83a0506b7a56e7cc6b1c91623a38ecf504c9b78c658bb8a6e5c56f7af72',
     'cd2711ab3400f03cb3830e6d7401058c99f5b3c0c438fe78180785582994b884',
     '566251b6b27cfbca202678f87ab6ebe5e6a71f306dea8e4035bca96207e630c1',
     '68eb0e868ebc4f0388c130bac9adcfb26fb526d8fdd7af6646ddcb9969e045df',
     '1cc856b20b1a66702782b4063caa1cce1cfd9a77600d53dbb727bc8d59cdeee3',
     'd5312340a7bd04a732ea6da056fa4a32ef92558a30160cb63c457b9d72603823',
     'd6cadd383605ab45e1cab2499349724d8973b160cd85e226115cbb30df383d44',
     '30a09d4abd5f3f52d47b7a7d2da05c5e0db2e40d93ae26a3d8b772227dffed48',
     'efb6889c4507f2e7ccb781dc5982e14d111b696098acaa450a286b100322ca5d',
     'cb7d6e3b904b49f01c85de319d4f3ed5ecc80aa3048dfbb97bb7300bc2fb4bd1',
     'bb70bd40d0d9d2ceda243172a10c05b2f9099d4ea6c62414e6c04c0309e5f7d1',
     '7912e77605eddb2e18a5baac16326f5ee3f31ebee5ed5badec7f9327dda75a7e',
     '75255b0e2000c546b5f9e3836a8ed483b401280f993b5320f433507b7dad4981',
     '77af8d90ecca1b09f072b244a032775f025a82c148ae8393a56bdf2f055e687f' ] }
</code>
look at the block: <a href="http://tbtc.blockr.io/block/info/1115996" rel="nofollow noreferrer">http://tbtc.blockr.io/block/info/1115996</a></p>

<p>next lets pick a random tx from the block that could be anyones tx:</p>

<p><a href="http://tbtc.blockr.io/tx/info/a5bf7009e9c97b1b7652d3f5ed4067c1eeb40d1625e2fadb6ffb11ca18a27e74" rel="nofollow noreferrer">http://tbtc.blockr.io/tx/info/a5bf7009e9c97b1b7652d3f5ed4067c1eeb40d1625e2fadb6ffb11ca18a27e74</a></p>

<p>you will see that this tx has two outputs lets look at one of the addresses an output leads to:</p>

<p><a href="http://tbtc.blockr.io/address/info/mjSujFSUn1uCVHkD4bDj5cs3mZrp8ayec5" rel="nofollow noreferrer">http://tbtc.blockr.io/address/info/mjSujFSUn1uCVHkD4bDj5cs3mZrp8ayec5</a></p>

<p><strong>Oh what a surprise! it has 1 confirmed tx and one unconfirmed tx</strong></p>

<p>unconfirmed:  <a href="http://tbtc.blockr.io/zerotx/info/8d7778e2238db427149f0c7fa46a572e0ea5c3ae9eeefe78c0ec9e4b795f0d38" rel="nofollow noreferrer">http://tbtc.blockr.io/zerotx/info/8d7778e2238db427149f0c7fa46a572e0ea5c3ae9eeefe78c0ec9e4b795f0d38</a></p>

<p>confirmed: <a href="http://tbtc.blockr.io/tx/info/a5bf7009e9c97b1b7652d3f5ed4067c1eeb40d1625e2fadb6ffb11ca18a27e74" rel="nofollow noreferrer">http://tbtc.blockr.io/tx/info/a5bf7009e9c97b1b7652d3f5ed4067c1eeb40d1625e2fadb6ffb11ca18a27e74</a></p>

<p>the inputs and outputs are all the same on both!</p>

<p>I just pucked that out randomly from a random tx in a random block today happend a few minutes ago!</p>

<p>If you go through each of those txs then they will 99% all be like that!</p>

CC BY-SA 3.0
2017-04-04T19:10:24.410Z
testnet i suppose to act just like mainet. something is clearly broken with some/many miners on testnet... so testnet is currently useless for testing.
Ben Muircroft
CC BY-SA 3.0
2017-04-05T17:22:33.510Z
I would say just the opposite.  Malleability is equally possible (and legal) on mainnet.  It just so happens that nobody is doing it on a large scale right now, but they certainly could.  So any application you design needs to be able to handle it appropriately.  Whoever is doing this on testnet is doing us all a favor by forcing us to handle this important case that we might otherwise ignore or dismiss.
Nate Eldredge
CC BY-SA 3.0
2017-04-05T17:34:47.970Z
i understand now
Ben Muircroft
<development><block><testnet><transaction-malleability>
testnet3 frequent tx malleability
Ben Muircroft
# testnet3 frequent tx malleability

(Asked by: username_0 on 2017-04-04)

**Related** [How confirm my own doublespend transaction got confirmed](https://bitcoin.stackexchange.com/questions/52539/how-confirm-my-own-doublespend-transaction-got-confirmed)

This is not about double spends and I believe that the related question is not about double spends ether!

On bitcoin's testnet3 I am seeing (using <https://github.com/bitpay/bitcore-p2p>) many tx change id

---

scenario:

1. I send some tBTC using <http://testnetwallet.com>
2. I see a utx with txid of XXXX broadcast onto the network with my inputs and going to my test address (everything looks cool)
3. I carry on monitoring looking at **all broadcast-ed txs**
4. a new ***block*** happens.
5. I look through the txids in the block but do not find my txid
6. I query my receiving address on some block explorer web service and see that my tx's txid got renamed to YYYY
7. I go and look at the ***block*** again and see YYYY is in its tx array!
8. I discontinue monitoring **all broadcast-ed txs**

---

I am starting to think that it (tx malleability) is happening when the miners are including the txs into the blocks!

I never see a tx with txid YYYY broadcasted **NEVER** (I am seeing every transaction!) this suggests that the txid is being altered!

I have been seeing this happen now for over 2 weeks and not found anyone talking about it apart for the first person today (4th april 2017) In the related question.

---

I have been trying many things in my code to stop relying on the txid to identify if my tx has 6 confirmations. But, I am finding it impossible to *...update* my tx with its new txid!

I have been trying (many times in different ways) to ask peers (p2p peers) getdata for each unrecognizable txid in new blocks, but a lot of the time the peer seems to disconnect ....

> **My question is:** What should I be doing in this situation?

Note: I'm trying not to use 3rd party services

also related: [How did blockr.io see this?](https://bitcoin.stackexchange.com/questions/52575/how-did-blockr-io-see-this)

---

# UPDATE

I am seeing all txs change id not just mine! I am collecting every txid I see broadcasted and putting them in an array called seen, then when a block happens i look for each tx on the block in my seen array.

for the last ten or so blocks today I have console.logged on each block

seen:1/52 by 73 peers
seen:0/4 by 73 peers
seen:0/35 by 73 peers
seen:0/22 by 73 peers
etc...

99% of all txs **(everyones)** on testnet3 are changing txid

I am listening to max peers 150

# PROOF THAT THIS IS HAPPENING TO EVERYONE'S TXs

`{ hash: '00000000000017f2a1d8ff44f149e7ead61a38e1a03217c33762ed9ace3c0c7d',
validProofOfWork: true,
validTimestamp: true,
prevHash: '000000000000178c28b96e945965b9311ea4005a66e8c5c2701d30f928a498d8',
txs:
[ '775b7b0bf9345cbee62e3af57e1660a6fd92d0a089fd0694e4804a7190dd4a05',
'1133ba34f4ef95af8a53c9698877cf8b7dc0e03d3095c371c0e2a1b8cd395ce2',
'14df326c04bf2da2edbd4f9f04810916b95144eeef67570458c06449d3a56fc4',
'b969a4bdab4b6a5ea91500b4230c3eadc9aa807cca000ecce6686450d2676b42',
'fa5acc2feecae6a603673c6a817f79fa3a4dd1516d50c59014772c80500b7063',
'0cd386804b65a3fb826557881dc3b50c1b298b7f0a0372da8faec97a2744d0e0',
'24ca695bac05c4500a596415b70bd199c935308f7a90ccfc8ae01d7b96e6b115',
'8125ed124dd4d0b3af98bc6028905fb329ff311c22f484be41bf9def8ea7b63e',
'4f1e5a894be245d2a68c79e2b73dde54dbeaa8bb2e872b9b1115f40c0b93585b',
'aee4a615c617d71c544930d5dbacdb62d66fb089d556d84cbe92682295895d91',
'545b2164e6bc2e764a702eac1bd69e625c6100c8cbeaa9528c16cd74eb144ecb',
'450c86ef90858943f6b6ba284da3987191880b2b534749d3ae762d7c9060bb7c',
'83d9107d90c36b0302af47f2b7e7bece30aaf20431dcdf251faa025d31f02fa8',
'4785a7fb5b0a6106152dc80d2c028b2aa80cb9b4f0ce81985b8c672a34561703',
'232a70178859760c5cd75ae054c503af9db4515d92a47b9da17ca5c81cee5d34',
'5c218f9e957cfd7fa97dbbdd29a81673d4c91b3441279c23607a7d3889533855',
'b2472c88eb6c7a38476444c22cb560793624216e1e36354b406f15b09dd8316b',
'5a7f3652282429eedf7bd2a6d0a8404e7844515f4139d14f8d7ed1e871efd373',
'5147d190550b44eddad2d8ea6cdd022e47fe71a2517458b69c07c2424fd08bb2',
'8e64ee1dcde8feb6b39ee043ecc43be719d0999ad181acee4d01e9d603976ff1',
'0223ed8beb7d466d9d4026665d2ba58a97cbd1e6641be22f16d23be2b4574688',
'18efc474f89835fb9eb1fa9ed1fc1dc296621aae3b727aab64f4f80ff76a098f',
'8f38f6030a0471c7bef2b1e1757a6db0b63edf07aab3fe12a7e85d86b35c5eb5',
'6b88744cba8f7661e64c67cd554d07a1b1981fe10614647a18b101520d289816',
'6aee3deb7c0cb7247c2a85f14f96f8cb8447dee00e98a72ace80cbb850f5a709',
'67de891a99a4c62fc90af91f5d880f9c2be80c1fc55bc444d10b74b63dd1ae1a',
'62f955cf10d52f34a0b7bf2328c5095051d8dcf5009b65dd53632d54de4a515c',
'c42685086053a0b2d989453b6f0cb17a1b60642ac963acc782b5269c8e563b89',
'e2c2114e7cd15e47a84a4a48e7c1adbb29daff0f85afb5be6015a17271859909',
'cc834a0f20e43f4eb05638398e8cfc61bfaaa303dcd82705be2c9cbf80189ded',
'10907000e1062dc63c817b995683a4a7433836f450f763c910fe6191aa555f24',
'a5bf7009e9c97b1b7652d3f5ed4067c1eeb40d1625e2fadb6ffb11ca18a27e74',
'40c3ffce0140a9db634e4b869e79848f4316fd40528e48b0899e2b5606075ef2',
'22b9db7c0ee380ec0c4eed97788dbf6f75fedbec569fb84a6c0d27bf36923cfa',
'f4906eda20607d733ae55caf3274fa91d5c2f20506881857af59be4d8bb0af25',
'98dfd83a0506b7a56e7cc6b1c91623a38ecf504c9b78c658bb8a6e5c56f7af72',
'cd2711ab3400f03cb3830e6d7401058c99f5b3c0c438fe78180785582994b884',
'566251b6b27cfbca202678f87ab6ebe5e6a71f306dea8e4035bca96207e630c1',
'68eb0e868ebc4f0388c130bac9adcfb26fb526d8fdd7af6646ddcb9969e045df',
'1cc856b20b1a66702782b4063caa1cce1cfd9a77600d53dbb727bc8d59cdeee3',
'd5312340a7bd04a732ea6da056fa4a32ef92558a30160cb63c457b9d72603823',
'd6cadd383605ab45e1cab2499349724d8973b160cd85e226115cbb30df383d44',
'30a09d4abd5f3f52d47b7a7d2da05c5e0db2e40d93ae26a3d8b772227dffed48',
'efb6889c4507f2e7ccb781dc5982e14d111b696098acaa450a286b100322ca5d',
'cb7d6e3b904b49f01c85de319d4f3ed5ecc80aa3048dfbb97bb7300bc2fb4bd1',
'bb70bd40d0d9d2ceda243172a10c05b2f9099d4ea6c62414e6c04c0309e5f7d1',
'7912e77605eddb2e18a5baac16326f5ee3f31ebee5ed5badec7f9327dda75a7e',
'75255b0e2000c546b5f9e3836a8ed483b401280f993b5320f433507b7dad4981',
'77af8d90ecca1b09f072b244a032775f025a82c148ae8393a56bdf2f055e687f' ] }`
look at the block: <http://tbtc.blockr.io/block/info/1115996>

next lets pick a random tx from the block that could be anyones tx:

<http://tbtc.blockr.io/tx/info/a5bf7009e9c97b1b7652d3f5ed4067c1eeb40d1625e2fadb6ffb11ca18a27e74>

you will see that this tx has two outputs lets look at one of the addresses an output leads to:

<http://tbtc.blockr.io/address/info/mjSujFSUn1uCVHkD4bDj5cs3mZrp8ayec5>

**Oh what a surprise! it has 1 confirmed tx and one unconfirmed tx**

unconfirmed: <http://tbtc.blockr.io/zerotx/info/8d7778e2238db427149f0c7fa46a572e0ea5c3ae9eeefe78c0ec9e4b795f0d38>

confirmed: <http://tbtc.blockr.io/tx/info/a5bf7009e9c97b1b7652d3f5ed4067c1eeb40d1625e2fadb6ffb11ca18a27e74>

the inputs and outputs are all the same on both!

I just pucked that out randomly from a random tx in a random block today happend a few minutes ago!

If you go through each of those txs then they will 99% all be like that!

**Tags:** development, block, testnet, transaction-malleability

> **Comments:**
> **username_0**: testnet i suppose to act just like mainet. something is clearly broken with some/many miners on testnet... so testnet is currently useless for testing.  
> **username_1**: I would say just the opposite.  Malleability is equally possible (and legal) on mainnet.  It just so happens that nobody is doing it on a large scale right now, but they certainly could.  So any application you design needs to be able to handle it appropriately.  Whoever is doing this on testnet is doing us all a favor by forcing us to handle this important case that we might otherwise ignore or dismiss.  
> **username_0**: i understand now  

---

## 2 answers

### Answer by username_3 on 2017-04-05. Score: 3 | Accepted answer

Someone (let's call her Alice onwards) is messing up with testnet transactions, it happened to one of mines earlier today.

**What's happening**

Alice is changing the `s` representation of the EDCSA signature ([See ECDSA signature generation algorithm](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm)) from at least one of the inputs of the transactions. By doing so, the signature is changing, but still valid, and thus the `txid` changed.

**How is she doing so?**

As explained in the [BIP62](https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki#low-s-values-in-signatures), there are two valid representations of the `s` value, depending on how big the value is. Moreover, depending on the result the [DER encoding may also be changed](http://83f50b79edcc984387c62af876b42cdef0ae6c8a22ce0e74d541b7337d1fc15).

Alice is simply modifiying one of the the `s` values from one of the original transaction signatures, by performing a subtraction between the order `n` of the curve (that is `FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141` for the [Secp256k1](https://en.bitcoin.it/wiki/Secp256k1)), and the value `s`.

Example:

Lets say that the `s` component of a signature from one of out transactions is `s = 37c0af486123367bc7839d507894bd30cba3f61e0d1bbf54727e43199864452c`, if we substract `s` to `n`:

```
s' = n - s = c83f50b79edcc984387c62af876b42cdef0ae6c8a22ce0e74d541b7337d1fc15

```

That is a valid representation of `s`.

Since `s'` starts by `0xc8`, which is bigger than `0x80`, the DER encoding will need a leading `0x00`:

```
00c83f50b79edcc984387c62af876b42cdef0ae6c8a22ce0e74d541b7337d1fc15

```

**Who is doing so?**

It could be a miner, just as you suggested, but it could also be a normal node.

If its a miner, it could be doing the modifications just before including the transactions the block he is mining. On the other hand, if a normal node (better connected than you) receives the transaction, modifies it, and broadcast it, it could be included in a block instead of your original transaction. Notice also that, since you have been broadcasting the original transaction from your node, you are not likely to be aware of transactions trying to double spend it, since your neighbours (to which you have sent the original transaction) will drop the double-spending attempt and do not forward it to you.

**What can you do?**

You can forward the transaction from a different source that the one you are using to monitor the network, and do not rely transactions from the latter, in order to see what's going on. Moreover, you can monitor the network using the `UTXO` you are trying to spend (`prev_txid` + `index`) instead of the `txid` from the transaction you just created. If another transaction appears spending from the same source, you will know.

> **Comments:**
> **username_0**: I am seeing all txs change id not just mine! I am collecting every txid I see broadcasted and putting them in an array called seen, then when a block happens i look for each tx on the block in my seen array. seen:0/63, seen: 0/45, seen: 0/87 etc.... all txs on testnet3 are changing txid  
> **username_3**: I know, as I said it happened to me also, I just considered all the possible cases.  
> **username_0**: i updated my question, and if you give me about 20 minutes to add further proof i think it will suprise you!  
> **username_0**: I have posted indeniable proof in the question  
> **username_2**: Sorry, but what is the problem? Bitcoin transactions are malleable. The miner can use this technique and is using it now. Just live with this knowledge.  
> **username_3**: @username_0 I don't get the point, no one is telling you that you are not right, just explaining you why it is happening.  
> **username_0**: yeah i understand that. but i don't understand how I'm suppose to match a malleated txid in a block to the original tx  
> **username_3**: If what you want to do is just identify them, you can check which UTXO both transactions are spending, that is, which previous tx id and index both transactions are trying to spend. There will be two transactions spending from the same source, one in the block, and another one that you had received though the network.  
> **username_0**: but i never see the malleated txs. I only see the malleated txid in the block so i don't know what outupts the malleated tx has  
> **username_3**: But you know the inputs of the transaction you have seen, you have to check with transaction in the new generated block is spending from the same previous output.  
> **username_0**: but seen as I never see malleated txs broadcated i don't have anything to check  
> **username_3**: Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/56605/discussion-between-username_3-and-username_0).  
> **username_0**: you were correct also about there being extra tx info inside blocks  

---

### Answer by username_2 on 2017-04-05. Score: 3

The miner which confirms current blocks on testnet is malleating transactions. I can confirm this. [![enter image description here](https://i.sstatic.net/dudi4.png)](https://i.sstatic.net/dudi4.png)

But what is the problem? Current consensus rules allow this. Trust me. I am an expert in malleability :)

> **Comments:**
> **username_0**: Finally, thank you!! who do we report this to?  
> **username_2**: Bitcoin is decentralized. There is no central authority to complain and send reports. This is normal behaviour. May be somebody is testing something.  
> **username_0**: for the last 2 weeks?  
> **username_2**: I do not see any problems here at all.  
> **username_0**: the problem is that i never see the malleated txs broadcast over the network (i only see the original txs)  
> **username_2**: It is your problem, not a bitcoin network problem :) nobody can help you because current clients do not relay HI-S transactions. So, they exist only on miner's node until confirmed in block  
> **username_2**: Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/56604/discussion-between-username_2-and-username_0).  

---

