I just checked in a change to bitcoinj git master that makes it much easier
to create a pull tester jar. Here are instructions for how to do it.
You will need:
- A Java Development Kit (JDK), version 6 or up should work. As Java 6
was released eight years ago, this should not be a
Oh, I forgot to mention something important. Ridiculously, the default
package repository Maven uses was not protected by SSL up until a few days
ago. They made it available via SSL now, but you have to tell Maven about
the new URL. I guess they'll do a new release where SSL is the default
soon.
Thanks for posting that (and implicitly archiving the knowledge). Anything
that makes test improvement easier is welcomed.
On Tue, Aug 5, 2014 at 11:00 AM, Mike Hearn m...@plan99.net wrote:
I just checked in a change to bitcoinj git master that makes it much
easier to create a pull tester
On 08/05/2014 05:11 PM, Mike Hearn wrote:
Oh, I forgot to mention something important. Ridiculously, the default
package repository Maven uses was not protected by SSL up until a few
days ago. They made it available via SSL now, but you have to tell
Maven about the new URL. I guess they'll
No problem.
The pull tester entry point can be found here:
https://github.com/bitcoinj/bitcoinj/blob/master/core/src/test/java/com/google/bitcoin/core/BitcoindComparisonTool.java
(nb: in the near future I will be re-namespacing the library from
com.google.bitcoin to org.bitcoinj to reflect that
It would make more sense to introduce a new script opcode that pushes the
current block height onto the operand stack. Then you could implement
arbitrary logic about which blocks the transaction can be valid in. This
would require that the client revalidate all transactions in its mempool
Glad this was brought up.
Transaction expiration is something that I have wanted to see happen in
bitcoin for a long, long time. The user experience of unconfirming
transactions setting around in limbo is just horrible. Bitcoin software by
necessity has gotten better about attaching fees so
A distinction there is that they can only become invalid via a
conflict— replaced by another transaction authored by the prior
signers. If no other transaction could be created (e.g. you're a
multisigner and won't sign it again) then there is no such risk.
You need to check transaction's
The user experience of unconfirming transactions setting around in limbo
is just horrible. Bitcoin software by necessity has gotten better about
attaching fees so this sort of behavior is uncommon, but that does not
eliminate the problem.
Yes, indeed. I suspect there's a quick hack that
I feel like a lot of this will be driven by implementation, and costs of
changing the implementation. Additional look-backs are of course doable,
but they incur some disk I/O costs. The fields available in memory for
each mempool TX are
uint256 tx_hash; // hash of next field
In general, if a transaction has not made it into a block within 144*X
blocks, there is _some_ reason it is getting rejected by the miners.
This is the crux of my concern: relay policy and miner priorities will
not necessarily always be in sync, and node resource management
shouldn't rely on
On Tue, Aug 5, 2014 at 3:10 PM, Kaz Wesley kezi...@gmail.com wrote:
Any approach based on beginning a transaction expiry countdown when a
transaction is received (as in mempool janitor) seems unviable to me:
...
That's why I think including information in the transaction itself, as
with my
On 8/5/2014 12:10 PM, Kaz Wesley wrote:
Any approach based on beginning a transaction expiry countdown when a
transaction is received (as in mempool janitor) seems unviable to me:
once a node has forgotten a transaction, it must be susceptible to
reaccepting it;
It's hard to argue with
13 matches
Mail list logo
