4

What tool/software can I use to broadcast a raw transaction, which would not reject a transaction because of invalid or double spend?

Bitcoind with RPC has a validation step which rejects any raw transaction where the inputs are not known, or if the inputs are double spending.

Also, I don't want to rely on a third party service like blockchain.info.

5
  • AFAIK It does not exist. Looked for this myself as well. You have to develop your own tool.
    – Emre K.
    Commented May 27, 2014 at 10:24
  • 1
    Seems like the easiest way might be to just comment out the validation code in bitcoind and recompile. Commented May 27, 2014 at 14:18
  • What tool would do this? No tool, because if it was possible, which it is not, you would be able to break Bitcoin.
    – T9b
    Commented May 30, 2014 at 14:49
  • 1
    Thanks god double spend attempts don't break Bitcoin, that would make it rather useless.
    – Flavien
    Commented May 30, 2014 at 15:32
  • 1
    And yes, it is certainly possible, it happens a few hundred times per day: blockchain.info/double-spends.
    – Flavien
    Commented May 30, 2014 at 15:38

2 Answers 2

4

Turns out there are many ways to do this:

-1

There is absolutely no reason trying to broadcast invalid transaction. It is wasting your time and your traffic. Your peer(s) will check it and throw it away. They will not relay it to network. They also can ban your IP-address for some time (1 day?)

May be you want to send valid but non-standard transaction? Or may be you want to have a custom tool, which sends transactions to a network?

    // [...]
    void NetSocket::pushTx ( const QByteArray& data )
    {
      const MyKey32 key ( data.constData ( ), data.size ( ) );  // calculate txid
      outTx.insert ( key, data );                               // store data
      write ( "inv", invPacket ( MSG_TX, key ) );               // send inv packet
    }
    //--------------------------------------------------------------
    void NetSocket::write ( const char* type, const QByteArray& data )
    {
      socket -> write ( packet ( type, data ) );
    }
    //--------------------------------------------------------------
    void NetSocket::procGetdataPacket ( const QByteArray& data )
    {
      Stream d ( data ); d.skip24 ( );               // i do not check header now
      const int count ( d.readVar ( ) );
      xassert ( count == 1 );
      const quint8* ss = d.readAdvance ( 36 );
      const quint32 tag ( *(quint32*)ss );
      const MyKey32 key ( ss + 4 );
      xassert ( tag == MSG_TX );
      xassert ( outTx.contains ( key ) );
      write ( "tx", txPacket ( outTx.value ( key ) ) );
    }
    // [...]
2
  • I think it could very well be that the various bitcoin implementations have slightly different notions of when to accept a transaction or not. the only way to find out is to be able to send a transaction unfiltered to lots of different nodes. Commented May 27, 2014 at 15:01
  • Of course, there is a very good reason. You may be spending unconfirmed outputs, which your client doesn't know about, but still exists on the network.
    – Flavien
    Commented May 28, 2014 at 13:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.