Marius Hanne

Thanks for bringing it up, I'll look into it. Need to sync a fresh blockchain though, so it's gonna take a bit... You're using the utxo backend on postgres?

Does this fix your issue? Still couldn't test it with the real blockchain, but it would make sense...

Hmm, strange... My node finally synced to that block, and went over it without any problems. I'm on commit 5f508d35bf2e42e355446d8ed11304dff0b88be5 now, with ruby 2.1.1p76 and postgres 9.1.14 on debian 7.8...

Ah, now I could reproduce it - somewhat, because for me it fails in the transactions_context/prev_out check, but in the same block... ``` DEBUG storage: => main (305001) DEBUG storage:...

Hi, I'm sorry but there isn't a gem for the bitcoin node yet. It needs some patches from my git repo that aren't in bitcoin-ruby upstream, and I couldn't figure...

Transactions should go through the queues after all. Processing each tx in the mempool as it comes in locks up the whole process too much / unpredictably long. Even if...

This is as far as I got with it: https://github.com/jruby/jruby/issues/1261 Didn't know about jruby-openssl, might be worth a try!

Can confirm. Even though the code looks like it should be doing the right thing: https://github.com/tip4commit/tip4commit/blob/master/app/models/project.rb#L137

Actually, there seems to be a deeper problem here. I sent two transactions to http://tip4commit.com/projects/108 - first 0.1 and then 0.01. The 0.01 tx was accepted into a block first,...