2) -1 doesn't mean conflicted, it means the transaction is not only
unconfirmed buy depends on another unconfirmed transaction.
1) Depends on what you mean by trusted. If you are giving the user online
access to something that costs you next to nothing to revoke if there is a
problem later, no pr
For what it is worth, electrum has a lot or possibly all of what you are
talking about since the electrum servers are designed to quickly answer the
queries of light clients. So right now, you could sync up an electrum
server or use an existing public one and send queries to it with json-rpc.
htt
I have a suggestion. If you are concerned about plausible deniability,
then it might make sense to just have the single mnemonic seed lead to a
single xprv key (as usual) and then do a private key derivation from that
based on a password string. The password can be simple, as it is based on
the s
I've thought about this as well, (in addition to making a java
implementation of the electrum server).
One solution would be for the client to combine all the addresses they are
interested in into a single bloom filter and send that to the server.
It would be pretty expensive for the server to ch
I would recommend the following solution as a decent compromise between
complexity and privacy:
1) Encourage electrum server operators to have their servers reachable as
tor hidden services (.onion addresses)
2) Make sure server discovery works well with .onion addresses
3) Make the privacy a user
I have concerns about the performance of the Electrum server software as
well. It seems to load data one block at a time (which normally makes
sense) and I think it is even single threaded on transactions inside the
block.
To try to addresses these issues, I made my own implementation of the
elec
I think our friendly original party worm is just trying to evaluate where
we are currently so arguments can be based on data.
I would tend to agree that there are performance improvements to be made
and would rather do that work than limit the block size.
On Thu, Jul 23, 2015 at 10:28 AM Matt
That is how I read it as well.
On Thu, Jul 23, 2015 at 12:56 PM Marcel Jamin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> He measured the upload capacity of the peers by downloading from them, or
> am I being dumb? :)
>
>
> 2015-07-23 18:05 GMT+02:00 Peter Todd via bitcoin-d
I have done a lot of recent work on local key value stores, mostly for a
java electrum server I am working on.
I'd suggest considering LMDB. One downside is that it is memory mapped so
32-bit systems that need over 2gb of storage are right out. Other than
that, it is quite fast and seems reliabl
