Re: [bitcoin-dev] Proposal for Palindromic (Reversible) Mnemonics
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 security of the seed, just as long as the user feels they need for deniability. A simple reverse scheme like you describe would just be another thing a person would know to check if given some seed so I don't see it as providing much value, but I could be missing something. On Mon, Dec 3, 2018 at 10:45 AM Steven Hatzakis via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi All, > > I've developed a method to check if a mnemonic is also valid when the > words are put into reverse order (not the entropy), where a given 12 or > 24-word mnemonic could be valid both in little endian and big endian > format. I've coined these "Palindromic Mnemonics", but perhaps more > user-friendly is "reversible mnemonics." > > Purpose: > A checksum-valid reversible mnemonic allows two separate vaults to be > connected to the same mnemonic string of words, where all a users must do > is enter the words in reverse order (the last word becomes first, second to > last becomes second, and so on) to access the secondary (reversed words) > vault. This utility could provide multiple use-cases, including related to > combinations with passphrases and plausible deniability, as well as > conveniences for those wishing to use a separate vault tied to the same > string of words. > > Security: > For any randomly generated 12-word mnemonic (128-bits of security) the > chances of it also being reversible are 1/16 (I believe), as a total of 4 > bit positions must be identical (4 bits from the normal mnemonic and > another 4 bits from the reversed string must match). For a 24-word > mnemonic, those values increase to 8 bits which need to match 8 bits from > the reversed string, leading to about 1 in every 256 mnemonics also being > reversible. While the message space of valid reversible mnemonics should be > 2^124 for 12 words, that search must still be conducted over a field of 2^128, > as the hash-derived checksum values otherwise prevent a way to > deterministically find valid reversible mnemonics without first going > through invalid reversible ones to check. I think others should chime in on > whether they believe there is any security loss, in terms of entropy bits > (assuming the initial 128 bits were generated securely). I estimate at most > it would be 4-bits of loss for a 12-word mnemonic, but only if an attacker > had a way to search only the space of valid reversible mnemonics (2**124) > which I don't think is feasible (could be wrong?). There could also be > errors in my above assumptions, this is a work in progress and sharing it > here to solicit initial feedback/interest. > > I've already written the code that can be used for testing (on GitHub user > @hatgit), and when run from terminal/command prompt it is pretty fast to > find a valid reversible mnemonics, whereas on IDLE in Python on a 32-bit > and 64-bit machine it could take a few seconds for 12 words and sometimes > 10 minutes to find a valid 24-word reversible mnemonic. > Example 12 words reversible (with valid checksum each way): > > limit exact seven clarify utility road image fresh leg cabbage hint canoe > > And Reversed: > > canoe hint cabbage leg fresh image road utility clarify seven exact limit > > > Example 24 reversible: > > favorite uncover sugar wealth army shift goose fury market toe message > remain direct arrow duck afraid enroll salt knife school duck sunny grunt > argue > > And reversed: > > argue grunt sunny duck school knife salt enroll afraid duck arrow direct > remain message toe market fury goose shift army wealth sugar uncover > favorite > > > My two questions 1) are how useful could this be for > you/users/devs/service providers etc.. and 2) is any security loss > occurring and whether it is negligible or not? > > Best regards, > > Steven Hatzakis > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Building a Bitcoin API and query system.
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. https://github.com/kyuupichan/electrumx/blob/master/docs/protocol-methods.rst On Tue, Aug 28, 2018 at 5:36 AM Blockchain Group via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hello everyone, > > I am C++ & Node.js developer. I want to propose making a new Bitcoin API > that supports fast quering of Bitcoin blocks and transactions without the > need for syncing with all previous nodes. > > In a typical case where I want to build a full fleged Bitcoin explorer cum > wallet system on my end with external APIs, I need to sync my node and then > query for the information I need to show separately. I am proposing a > unified method of finding/quering the blockchain data with a standardized > template containing minimal information about the actual mined block or > transaction yet satify the need of what I want to query. > > I am working on making a template and a support mechanism on Node.js. I > want to propose it as an improvement (BIP). It will be a great help to > future web developers who want to make something similar. > > Thanks > Sumit Lahiri. > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Few questions regarding ListTransaction
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 problem. 0-conf is great. If you are pre-pairing shipments and will be able to pull the box from the ship stream if there is a problem, also no problem. If you are sending some other non-reversible thing like crypto, then you might want to be careful. It really depends on the value of your things and your tolerance of risk. In my opinion, an zero-conf transaction is way way better than a credit card preauth or a check in hand. On Tue, Apr 10, 2018 at 1:34 PM Maksim Solovjov via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi, > > I have few questions regarding ListTransaction RPC call and I hope you can > help me. > Documentation for the RPC call is here: > https://bitcoin.org/en/developer-reference#listtransactions > > 1. What does it mean for a transaction ( with 0 confirmations ) to be > *trusted* or not? > There is such field in the response of ListTransaction > As far as I know bitcoin - nothing is trusted unless there are some > numbers of confirmations. > How does this value is set to true or false? > > 2. When does *confirmations* can be -1 ( conflicted )? > What does it mean to have conflicted transaction? > Is it about Transaction Malleability? Double Spend? or both? > > 3. *walletconflicts*. What if I add watch-only address to my bitcoind > process. > This address will not be a part of my wallet. > Now, someone will pay me to this address and someone else will make > Transaction Malleability ( for the sake of example, lets assume this second > one will be confirmed, not the original one ). > Will I get a first transaction in *walletconflicts* array when > ListTransaction will return me second transaction in the response? > > Thank you in advance! > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin Node Speed Test
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-dev bitcoin-dev@lists.linuxfoundation.org: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 23 July 2015 10:19:59 GMT-04:00, slurms--- via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: This does not support the theory that the network has the available bandwidth for increased block sizes, as in its current state 37% of nodes would fail to upload a 20MB block to a single peer in under 20 seconds (referencing a number quoted by Gavin). If the bar for suitability is placed at taking only 1% of the block time (6 seconds) to upload one block to one peer, then 69% of the network fails for 20MB blocks. For comparison, only 10% fail this metric for 1MB blocks. Note how due to bandwidth being generally asymetric your findings are probably optimistic - you've measured download capacity. On top of that upload is further reduced by the fact that multiple peers at once need to be sent blocks for reliability. Secondly you're measuring a network that isn't under attack - we need significant additional margin to resist attack as performance is consensus-critical. -BEGIN PGP SIGNATURE- iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsRCj AAoJEMCF8hzn9Lnc47AIAIQbznavjd2Rbqxeq5a3GLqeYoI4BZIQYqfWky+6OQtq yGRKaqPtGuES5y9L0k7efivT385mOl87PWnWMy61xxZ9FJgoS+YHkEx8K4tfgfA2 yLOKzeFSar2ROCcjHYyPWa2XXjRbNmiLzfNuQyIBArg/Ch9//iXUUM+GG0mChF5k nUxLstXgXDNh5H8xkHeLi4lEbt9HFiwcZnT1Tzeo2dvVTujrtyNb/zEhNZScMXDc UOlT8rBLxzHlytKdXt1GNKIq0feTRJNbreBh7/EB4nYTT54CItaaVXul0LdHd5/2 kgKtdbUdeyaRUKrKcvxiuIwclyoOuRQp0DZThsB262o= =tBUM -END PGP SIGNATURE- ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Electrum Server Speed Test
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 electrum server. It doesn't support UTXO (yet) but happily interacts with all the clients I've tested. It is heavily multithreaded, uses mongodb as a key value store and bitcoinj for block and transaction parsing. https://github.com/fireduck64/jelectrum You can hit a running instance at: b.1209k.com:50002:s or b.1209k.com:50001:t A synced node uses 347G of mongodb storage. Here are the recent blocks imported, with number of transactions and import time. http://pastebin.com/cfW3C2L6 These times are based on having mongodb on SSD. The CPU is 8 core Intel(R) Xeon(R) CPU E5430 @ 2.66GHz I'd be happy to help with anything you need to evaluate it. On Thu, Jul 23, 2015 at 9:01 AM Slurms MacKenzie via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Similar to the Bitcoin Node Speed Test, this is a quick quantitative look at how the Electrum server software handles under load. The Electrum wallet is extremely popular, and the distributed servers which power it are all hosted by volunteers without budget. The server requires a fully indexed Bitcoin Core daemon running, and produces sizable external index in order to allow SPV clients to quickly retrieve their history. 3.9Gelectrum/utxo 67M electrum/undo 19G electrum/hist 1.4Gelectrum/addr 24G electrum/ Based on my own logs produced by the electrum-server console, it takes this server (Xeon, lots of memory, 7200 RPM RAID) approximately 3.7 minutes per megabyte of block to process into the index. This seems to hold true through the 10 or so blocks I have in my scroll buffer, the contents of blocks seem to be of approximately the same processing load. Continuing this trend with the current inter-block time of 9.8 minutes, an electrum-server instance running on modest-high end dedicated server is able to support up to 2.64 MB block sizes before permanently falling behind the chain. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Making Electrum more anonymous
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 configurable setting:
- None - Allows any server connection type
- SSL - Requires SSL at least, no plain text
- Tor - Requires tor, no direct TCP
- Multi-Tor - Uses a variety of tor paths to reach a variety of servers
(maybe configurable number of servers)
Default should be 'SSL' probably.
On Wed, Jul 22, 2015 at 3:20 PM Eric Voskuil via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
I should add that the obvious resolution to this set of problems is to
use a distinct Tor route for each Bitcoin address, not to reinvent Tor
and reproduce its community. So ultimately this is easy to implement,
but the downside is performance.
But it's important to keep in mind that poor-performing perfect privacy
for address monitoring is trivial to achieve - just sync the full
blockchain.
Presumably if you don't trust a server to protect your privacy, you also
don't trust it with your money. So any robust privacy optimization would
at least be designed to support partial (SPV) chain clients. It would
also need to support wallet restoration from backup.
The level of privacy will always be a performance trade-off. The ideal
solution would allow a client to balance privacy against performance.
e
On 07/22/2015 09:30 AM, Eric Voskuil wrote:
Hi Thomas,
The scheme is essentially onion routing. The set of {M} are entry nodes
and the set of {S} are exit nodes. The weaknesses are as you would see
in an analogous TOR implementation:
(1) The lack of relay nodes {R} make collaboration between any subset of
{M} and {S} trivial.
(2) OR is a mixnet, so the size of the network matters a lot.
(3) The directory is a perpetual weakness.
(4) Content is visible to the exit node (or the final service). This
means each address must be passed via a distinct route to prevent
correlation.
e
On 07/22/2015 08:51 AM, Thomas Voegtlin via bitcoin-dev wrote:
Hello,
Although Electrum clients connect to several servers in order to fetch
block headers, they typically request address balances and address
histories from a single server. This means that the chosen server knows
that a given set of addresses belong to the same wallet. That is true
even if Electrum is used over TOR.
There have been various proposals to improve on that, but none of them
really convinced me so far. One recurrent proposal has been to create
subsets of wallet addresses, and to send them to separate servers. In my
opinion, this does not really improve anonymity, because it requires
trusting more servers.
Here is an idea, inspired by TOR, on which I would like to have some
feedback: We create an anonymous routing layer between Electrum servers
and clients.
* Each server S publishes a RSA public key, KS
* Each client receives a list of available servers and their pubkeys
* For each wallet address, addr_i, a client chooses a server S_i, and a
RSA keypair (K_addr_i, k_addr_i)
* The client creates a list of encrypted requests. Each request contains
addr_i and K_addr_i, and is encrypted with the pubkey KS_i of S_i
* The client chooses a main server M, and sends the list of encrypted
requests to M
* M dispatches the client's requests to the corresponding servers S_i
(without the client's IP address.)
* Each server decrypts the requests it receives, performs the request,
and encrypts the result with K_addr_i
* M receives encrypted responses, and forwards them to the client.
* The client decrypts the encrypted response with k_addr_i
What do you think? What are the costs and benefits of such an approach?
(Note: this will not work if all servers, or a large fraction of them,
are controlled by the same entity that controls M)
Thomas
___
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
