https://onename.io/

This is the only service I think that is close to what you're saying.

They use Namecoin to register Bitcoin addresses and offer an API to query the Namecoin blockchain and look up the bitcoin address by just querying the onename ID.

Your service could implement onename... but unfortunately, there will always be services that only offer bitcoin addresses, and onename is an opt-in service.

I think Bitcoin is still very small, so people are trying to find out what works best.

If you want to make something new that everyone will use, then awesome.

Also beware: If you have 10,000 addresses and you're trying to put them into one, I'd assume you have 10,000 inputs... just your inputs alone would be over 1.8 Megabytes... which is larger than the block limit!!!

you will need to bunch your bitcoins together in transactions of less than 100 kB... which by the way, would be at the most 552 inputs and 2 outputs.

So if I were you, look at all the utxos you have, and bunch them together in groups of 527 inputs and send them to another address (so 1 output) and be sure to leave AT LEAST 0.00096 BTC miner's fee. (literally, anything less than 0.00096 BTC for a 96 kB transaction and it will be treated just like a no fee transaction...)

Any transaction over 100000 bytes will not do well...

if you have 10,000 utxos and put 527 in each transaction. you will need 19 transactions to pool them together in one address, then you'll be left with 19 utxos... if you want to pool those together 1 transaction is ok...

So your endeavor will require about 20 transactions to do.

Good luck, and have fun ;-)

I highly recommend against writing your own crypto...

What language are you trying to code in?

Importing 10,000 addresses one at a time is horribly painful. Blockchain.info only allows you to add one key at a time, and you must enter your password every time.

I found a company that was having unauthorized transactions from their corporate bitcoin address in small amounts over a long period. I asked to review their code, and the guy they hired to code the system had basically used H( tx ) where H is 281 rounds of sha256 as a "deterministic" k and had secretly stolen the private key by looking at the blockchain. (as the tx was public knowledge and the only secret was the iteration count... which he knew.)

Using your check twice method, signing the same tx twice would give the same k... but still be unsafe.

You, me, and my brother exchange pubkeys and decide on a prefix and scan keypair, we can now create a static multisig address that anyone can pay to but it will generate a new multisig address for each transaction. So like the Darkwallet donation address is p2sh multisig, a team of bloggers could post a stealth multisig that's 2 of 3 etc. but looking up that address will not get you anything on the blockchain.

Use case could be a company that needs 2 of 3 signatures from 3 execs high up, but they don't want to reveal the entire funds of the company, plus they don't want to continue to give out new addresses every single time. Just one static address that is not lookup-able on the blockchain, and will give them new addresses for each transaction.

Nope, this function parses it perfectly fine. I could replace i with (multi_n - 1) but since i ends the for loop with (multi_n - 1) anyways I left it there for simplicity's sake.

Edit:

Here's a stealth address I put together, it's a 2-of-3 p2sh multisig stealth with a 10 bit prefix at the end of it.

You can run it through my commit and it generates the outputs properly.


Decoded into hex to make it easier to read with spaces:

https://github.com/dabura667/electrum/blob/sendstealth/lib/bitcoin.py#L191

You are basically comparing the prefix to the trailing bytes at the end of the stealth address.

If the stealth address ends with a 0x00 that means a 0 bit length prefix.

if it is 0x0B then there will be two bytes tagged on to the end (because you need at least 2 bytes to represent 11 bits and 0x0B is 11)

so the sender takes the OP_RETURN script and hashes it with the nonce until the first 11 bits match the 1st 11 bits of the prefix bytes (the two bytes at the end of the stealth address)

This makes it easier for the receiver to find their payments, as the obelisk server stores all the stealth OP_RETURNS in a table along with the hash value given by double sha256ing the script + nonce.

So instead of checking every single one (like they do now) You can narrow it down to specific transactions.

The higher the prefix bit count, the harder it is to send to you but most people will probably only pick like a 3-4 bit prefix just to make synchronizing a tad faster. Higher the bitcount the less anonymity the stealth address has. (in fact, I think a 32 bit prefix that just tells the sender to place the 4 byte prefix AS THE NONCE and use that as an optional fully transparent re-usable address is one use case imo, as you can paste it statically on a website but you won't be reusing addresses when people send to you.

Anywho, any other questions?

http://www.reddit.com/r/Bitcoin/comments/2akdl5/howto_use_your_own_dice_rolls_to_generate_an/

This is better imo.

https://github.com/spesmilo/electrum/blob/master/plugins/cosigner_pool.py

This plugin was first committed on August 22nd.

If someone writes a plugin for it, sure...

But Electrum will support multisig 2FA of its own... so there's no need to implement that.

lol. If you know the private key, you don't need the signature to calculate the public key.

aka "the order of the curve" of secp256k1 (the curve bitcoin uses)

https://en.bitcoin.it/wiki/Transaction_fee#Sending

A transaction may be safely sent without fees if these conditions are met:

• It is smaller than 1,000 bytes.
• All outputs are 0.01 BTC or larger.
• Its priority is large enough (see the Technical Info section below)

So because of #1 in that list, I would say 1,000.

If your tx doesn't meet the above 3 requirements, then it will check the fee. If the fee is less than MIN_RELAY_TX_FEE (currently set to 0.00001 BTC on most nodes) than they remove the transaction from their mempool and don't pass it along.

Yes I am aware of how it works, I am just wondering where the "latest" repo is. (with support for compressed keys etc)

And if possible I would like some binaries... but not a requirement.

I'm reeeeally sorry for giving up my epic quest of searching various keywords on this thread / clicking through the pages...

But if someone could make a new post that actually updates the OP with the latest news (I mean, this thread's OP makes no mention of all the functionality you guys are speaking of) on vanitygen, I'd appreciate it much more...

I am looking for a compiled version for Windows 7 64bit that a trusted member of the community has up on github or something... or a link to a well known repository...

that supports compressed addresses with oclvanitygen.

If there's any wiki-type page with all the necessary info on vanitygen and the latest patches / versions... I'd appreciate it. Thanks, and sorry again for failing at weeding through this thread.

This is not supported in Electrum for technical reasons.

The password you enter at the creation of the wallet only protects for sending bitcoin and viewing the seed / private keys.

Looking at your balance can not be password protected for technical reasons.

I have a question:

On the screen with the sign, save buttons, there are 2 white text boxes, the upper box should have a bunch of rows of gibberish and the lower one should have 1 or 2 rows with bitcoin addresses on them.

How many rows of gibberish are in the upper white text box for the one bitcoin transaction that fails.

What are the exact output amounts of the transaction? Was one of the change outputs less than 0.0000546 BTC?

Then once you have 100000000000000 keys on your wallet, you'll need 30 GB for the blockchain, and 500TB for your wallet.dat file... lol