Pages:
Author

Topic: transaction not accepted (Read 4370 times)

newbie
Activity: 15
Merit: 0
November 04, 2015, 12:25:39 PM
#33
Is there ETA on fixing this issue in newer version of Armory?

High-S signing is fixed in 0.93.3, but if you're after official Mac binaries, you're not necessarily going to get them just yet. Downloads for Linux and Windows are in the top post of the thread "Armory 0.93.3  with BIP62 compliance"

Good news. Thank you.

I have finally managed to send mentioned transaction but during second attempt with much higher fees.
legendary
Activity: 3430
Merit: 3080
November 04, 2015, 12:01:13 PM
#32
Is there ETA on fixing this issue in newer version of Armory?

High-S signing is fixed in 0.93.3, but if you're after official Mac binaries, you're not necessarily going to get them just yet. Downloads for Linux and Windows are in the top post of the thread "Armory 0.93.3  with BIP62 compliance"
newbie
Activity: 15
Merit: 0
November 04, 2015, 09:25:17 AM
#31
Here's a work around that you should be able to use until we release a fix:

When creating a transaction check the box for "create unsigned transaction" and click continue. Export the transaction, then import it and sign it. If you use cold storage you are already doing these steps.

Then instead of broadcasting the transaction, click the link labeled "For more information about this transaction". That opens up a Transaction Info dialog. At the bottom, click the "Copy raw TX (hex)" button.

Paste the raw transaction to https://blockchain.info/pushtx  and click submit transaction.

Basically blockchain has already made the necessary fix to guarantee that the "Low S" is used, and applies it to raw transactions.

You don't need to export it. In expert mode:
- create unsigned tx
- copy to clipboard
- continue
- paste
- sign
- copy raw tx (the button is just there in expert mode so no need to open additional info)
- https://blockchain.info/pushtx
- submit

Unfortunately this has not worked in my case. I have received a message 'Non-canonical signature: High S Value' from blockchain.info.

What else can be done to send this transaction?

Is there ETA on fixing this issue in newer version of Armory?
legendary
Activity: 3430
Merit: 3080
October 22, 2015, 08:13:02 PM
#30
Well, I don't quite get this bug. Even when I'm connected to 11.1 nodes, transactions with Armory confirm ok for me. Got a couple of rejections, but that was a day or two before this thread appeared anyway (and 11.1 nodes weren't very significant on the network then). All been fine since then, and 11.1 is ~ 20% of the network.
legendary
Activity: 1500
Merit: 1002
Mine Mine Mine
October 22, 2015, 03:51:20 AM
#29
Here's a work around that you should be able to use until we release a fix:

When creating a transaction check the box for "create unsigned transaction" and click continue. Export the transaction, then import it and sign it. If you use cold storage you are already doing these steps.

Then instead of broadcasting the transaction, click the link labeled "For more information about this transaction". That opens up a Transaction Info dialog. At the bottom, click the "Copy raw TX (hex)" button.

Paste the raw transaction to https://blockchain.info/pushtx  and click submit transaction.

Basically blockchain has already made the necessary fix to guarantee that the "Low S" is used, and applies it to raw transactions.

You don't need to export it. In expert mode:
- create unsigned tx
- copy to clipboard
- continue
- paste
- sign
- copy raw tx (the button is just there in expert mode so no need to open additional info)
- https://blockchain.info/pushtx
- submit

thx for the workaround ... i was also thinking about manually pushing it out & yes it works.

was working normally till qt upgraded to 11.1

looking fwd to a fix.

thx again guys. got me worried for a couple of mins.
legendary
Activity: 1022
Merit: 1000
October 22, 2015, 03:46:45 AM
#28
In my case armory (last version, bitcoind 0.11.0) armory is often creating the tx with malleated inputs (which were then not confirmed) so txid is invalid and the tx is rejected by any node
sr. member
Activity: 449
Merit: 251
October 22, 2015, 03:08:06 AM
#27
Here's a work around that you should be able to use until we release a fix:

When creating a transaction check the box for "create unsigned transaction" and click continue. Export the transaction, then import it and sign it. If you use cold storage you are already doing these steps.

Then instead of broadcasting the transaction, click the link labeled "For more information about this transaction". That opens up a Transaction Info dialog. At the bottom, click the "Copy raw TX (hex)" button.

Paste the raw transaction to https://blockchain.info/pushtx  and click submit transaction.

Basically blockchain has already made the necessary fix to guarantee that the "Low S" is used, and applies it to raw transactions.

You don't need to export it. In expert mode:
- create unsigned tx
- copy to clipboard
- continue
- paste
- sign
- copy raw tx (the button is just there in expert mode so no need to open additional info)
- https://blockchain.info/pushtx
- submit
full member
Activity: 123
Merit: 100
October 21, 2015, 03:19:41 PM
#26
Here's a work around that you should be able to use until we release a fix:

When creating a transaction check the box for "create unsigned transaction" and click continue. Export the transaction, then import it and sign it. If you use cold storage you are already doing these steps.

Then instead of broadcasting the transaction, click the link labeled "For more information about this transaction". That opens up a Transaction Info dialog. At the bottom, click the "Copy raw TX (hex)" button.

Paste the raw transaction to https://blockchain.info/pushtx  and click submit transaction.

Basically blockchain has already made the necessary fix to guarantee that the "Low S" is used, and applies it to raw transactions.
legendary
Activity: 1064
Merit: 1002
October 21, 2015, 02:57:19 PM
#25

@CircusPeanut I had the issue before updating to v11.1 so I don't think it is caused by v11.1

...
ERROR: AcceptToMemoryPool : nonstandard transaction: scriptpubkey
...
ERROR: AcceptToMemoryPool : inputs already spent
...
ERROR: AcceptToMemoryPool : free transaction rejected by rate limiter


All of these error messages may be wrong. I was getting multiple different issues on my test cases.

I think scriptpubkey was for unnecessary 0x00 padding (a different malleability issue).

I'm pretty sure the ERROR for Low S violation in 0.11.1 is:

ERROR: .... Non-canonical signature: S value is unnecessarily high

How many utxo's are in the wallet? it may be failing due to being to large of a tx in kb. You say you have been mining for a year and havent moved any. Im assuming you have a hefty build up of utxo's. Try sending multiple smaller amounts and see if they go through. If you know your average utxo size try sending that * 100
full member
Activity: 123
Merit: 100
October 21, 2015, 02:52:54 PM
#24

@CircusPeanut I had the issue before updating to v11.1 so I don't think it is caused by v11.1

...
ERROR: AcceptToMemoryPool : nonstandard transaction: scriptpubkey
...
ERROR: AcceptToMemoryPool : inputs already spent
...
ERROR: AcceptToMemoryPool : free transaction rejected by rate limiter


All of these error messages may be wrong. I was getting multiple different issues on my test cases.

I think scriptpubkey was for unnecessary 0x00 padding (a different malleability issue).

I'm pretty sure the ERROR for Low S violation in 0.11.1 is:

ERROR: .... Non-canonical signature: S value is unnecessarily high
full member
Activity: 123
Merit: 100
October 21, 2015, 09:50:00 AM
#23

@CircusPeanut I had the issue before updating to v11.1 so I don't think it is caused by v11.1


There is more than one reason why transactions might not be accepted by core.

To be certain that you are encountering the same issue that I'm fixing right now, you have to find this string in bitcoin/debug.log

ERROR: AcceptToMemoryPool : nonstandard transaction: scriptpubkey

For instance if you attempt a double spend, everything acts the same failing to use "lowS", but you find this in bitcoin/debug.log:

ERROR: AcceptToMemoryPool : inputs already spent

Another one that I think is probably what you encountered is:

ERROR: AcceptToMemoryPool : free transaction rejected by rate limiter

0.93.2 has a bug in it that provides a very old age for inputs when it tries to verify the fee you specified. So instead of telling you that the fee paid is not enough for a transaction with many inputs, it thinks that since all of the inputs very old, it should be free and doesn't warn you need a bigger fee. Then transaction gets rejected by core, and you don't know why unless you look at the log.

Goatpig... please make sure your fix for that gets into this bug fix release.



legendary
Activity: 3430
Merit: 3080
October 21, 2015, 08:33:38 AM
#22
This might be related to the "lowS" fix for a transaction maleability issue. The fix "lowS" fix is in Bitcoin 0.11.1. Armory currently does not apply the "lowS" fix, so Bitcoin 0.11.1 will refuse to relay some Armory transactions.

Does Armory sign all transaction with +ve S, or just some? And is this the first time this has been announced publicly?
legendary
Activity: 3766
Merit: 1364
Armory Developer
October 21, 2015, 06:54:24 AM
#21
To work around this problem when I really need to send asap I make an offline tx - sign it- copy the raw hex - and broadcast it on https://blockchain.info/pushtx it gets broadcasted but 90% the tx changes because of a conflicting tx.

I fixed that in 0.94, but as Holliday puts it, it's been delayed a lot.


There could be closure on this situation soon.

sr. member
Activity: 449
Merit: 251
October 21, 2015, 04:12:43 AM
#20
I have the same issue... but only with some of the transactions I make. I made no changes in paths or whatever and the problem continues after updating Bitcoin Core from v11.0 to v11.1. It has nothing to do with the address I send to or from or the amount send because sometimes it works sometimes it don't  Roll Eyes

@CircusPeanut I had the issue before updating to v11.1 so I don't think it is caused by v11.1

To work around this problem when I really need to send asap I make an offline tx - sign it- copy the raw hex - and broadcast it on https://blockchain.info/pushtx it gets broadcasted but 90% the tx changes because of a conflicting tx.
legendary
Activity: 1120
Merit: 1012
October 20, 2015, 08:53:07 PM
#19
We are working on a fix, and plan to release 0.93.3 with that fix and a few others by the end of the week.

.93? What happened to .94 which was in "testing" since May?

https://bitcointalksearch.org/topic/starting-preliminary-094-testing-headless-fullnode-1059942
full member
Activity: 123
Merit: 100
October 20, 2015, 02:48:08 PM
#18
This might be related to the "lowS" fix for a transaction maleability issue. The fix "lowS" fix is in Bitcoin 0.11.1. Armory currently does not apply the "lowS" fix, so Bitcoin 0.11.1 will refuse to relay some Armory transactions.

For now you should be able to just downgrade 0.10.2 (Edit: Actually 0.11 should work too) to broadcast, however as more nodes upgrade to 0.11.1 some Armory transactions will fail to propagate through the network.

We are working on a fix, and plan to release 0.93.3 with that fix and a few others by the end of the week.
staff
Activity: 3458
Merit: 6793
Just writing some code
October 20, 2015, 01:35:41 PM
#17
Can you post the raw hex of a transaction you are trying to send? I will try to broadcast it from my node. If that works, then there must be something wrong with your bitcoin core installation.

To get the hex, send the transaction normally then right click it in the transaction list and click view details. Then click copy hex and then paste that to a post.
newbie
Activity: 21
Merit: 0
October 20, 2015, 12:31:14 PM
#16
definitely not
legendary
Activity: 1120
Merit: 1012
October 20, 2015, 11:45:26 AM
#15
Are you trying to send dust?
newbie
Activity: 21
Merit: 0
October 20, 2015, 08:35:05 AM
#14
Just now opened Armory again.  Last block received is 4 seconds ago upon opening.  Connected 379749 blocks....  

Just opened Bitcoin qt ...  connected up to date...  379749 blocks of transaction history.     @  9:34 am EST

 Cry

a minute later bitcoinqt goes up to 379750 blocks on its own

on armory at 9:44 it says 379751 blocks... last block received 6 minutes ago...
Pages:
Jump to: