Remember, you must use the install version. And be careful that you're editing the actual files being used.

(ie. if you installed Electrum twice in two different folders, make sure you edited the one that is actually being used with your Electrum.)

If you follow my instructions, you'll be able to send. (I have sent 0 fee transactions on numerous occasions)

What is the version you're using on your online computer?

Also, what are the specs of your offline computer? How many inputs does the transaction you're trying to sign have?

If your online wallet is >=2.0 (aka Github version) then you can not sign transactions using any pre-2.0 version.

If you are using 1.9.8 on your online, then it might be due to too many inputs + low specs on your offline wallet.


I had a reeeeally crappy mini-notebook I was using for offline signing, and when I signed a transaction with 15 inputs, it would freeze for 5 minutes, then the signed transaction would finish.


If it's "hanging" I would recommend just waiting it out... Maybe try signing it, then let it hang for like 30 minutes while you're doing something else, and see if it actually finishes.

(DISCLAIMER: You must have the installed version / the source installed version for this to work. Packaged exe files will not let you mess with the innards.)

1. BACKUP YOUR WALLET FIRST! Just in case.

2. Find the Electrum install folder

3. Navigate to ...\lib\bitcoin.py

4. Open it with a text editor that supports Lf line breaks (hint: Notepad for Windows does not. but WordPad (also comes with Windows) does)

5. Search the file for "MIN_RELAY_TX_FEE = 10000" or just "MIN_RELAY_TX_FEE"

6. Change 10000 to 1000.

7. This makes it so that you can send transactions with 0.00001 BTC fees. But you will still pay whatever is in preferences, so after saving and closing, don't forget to set your preference's fee to "0.00001 BTC per kB"

You can set "= 0" if you want to get rid of the minimum, but be warned that any transaction that is not eligible for a free transaction with a fee less than 0.00001 BTC will not be relayed by most nodes.

Your words, not mine.

Are you 12 or younger? Your manner of snark reminds me of my 12 year old neighbor.

What's the price? The last BTC sold/bought on an exchange?

When demand goes down what happens? Support for current price disappears.

When there's no support and everyone tries to sell all at once in a race to fill whatever bids are left after everyone pulled out their buy orders... what happens? Catastrophic crash into 0, or the lowest order that was on there by the time they're all matched up and no one wants to buy anymore.

explain how people are panic selling? hmm, ok, maybe the same reason Gox was able to steal so much of their users' money. BECAUSE A LOT OF TRADERS HOLD A LIQUIDITY POOL OF BTC ON EXCHANGES SO THEY CAN EASILY GO IN AND OUT BETWEEN EXCHANGES AND TRADE. You know, because traders tend to like to trade, you know.

When your BTC is just a number on an exchange's database, you most certainly can sell your BTC, sir...

so I guess tl;dr: E = MC^2  

Game theory.

Ok, let's say you were able to get EVERY SINGLE HASH OF POWER to cooperate and stop mining at a specific time....

Everyone would sell their bitcoins because blocks would not confirm while you were doing this, AND showing all miners cooperating removes trust of the network... ie. if they can coordinate THIS, then WHAT ELSE could they coordinate? (Think of some alt coins that had "cooperation" from the miners to "roll back" blocks. And see where THAT got them... lol)

But in reality, it would never happen. Everyone knows that the only way they can win is by continuing to mine.

onemorebtc is correct. His answer DOES answer your question.

You are fundamentally misunderstanding how difficulty is calculated. You are asking if "the next hash has to have more than 20 zeroes in left?" (sic) and the answer is "no".

The bitcoin network does not care HOW RIGHT you are, it just cares if you're RIGHT or WRONG.
If you meet the requirement, you are RIGHT.
If you DON'T meet the requirement you are WRONG.

You are not MORE WRONG if you have less zeroes, and you are not MORE RIGHT for having more zeroes than needed. It's just a 1/0, right/wrong, yes/no type problem.

So every single block for 2 weeks could have 55 zeroes, but the Bitcoin network would not care. If they were slow to confirm, the difficulty will go DOWN, not up. If they were fast to confirm, the difficulty will go UP.

Why not just store an HD seed (or Master Public Key if you don't want to store private keys on your table) and just store indexes instead of addresses?

Then when you actually need the address, the local client just calculates the seed/MPK with the CKD function to the index you need.

You are making the assumption that his goal is a 1-of-3 groups of 2-of-2 multisig.

Seeing as his site is not just a simple escrow site, there is a high possibility that each key does not represent one user. One or more of those keys could be a special key used as a case trigger.

By leaving the decision of which multisig to use OUTSIDE the redeemscript, there's a lot of room for attack vectors.

If I knew exactly what the purpose of the contract was for, I could suggest more efficient ways to perform the same task.

I can read Script just fine, thanks. The Script tells me nothing about its goals, just its results.

Actually. The ScriptSig was this:


So BEFORE the redeemscript, he places any combination of 0 and 1. in the tx he used 0 then 1, meaning the first IF would trigger and the second IF would not (and the proceeding ELSE would)...

OP_0 would give the 3rd multisig, OP_1 OP_0 gives the 2nd multisig and OP_1 OP_1 would give the 1st multisig.

Rather than using IF/ELSE embedding (which is hard to negative test effectively) there seems like there would be a better way of doing what he's trying to accomplish... maybe this is the best way... but I won't know unless he tells me what he's trying to accomplish.

OP>
A PM would be fine if you don't want it public. I won't tell anyone.

Slightly OT, but using OP_0 and OP_1 to trigger the redeemscripts IF/ELSEs seems to be something any service's users would be able to alter on their own if they knew the service's inner workings well enough.

I haven't looked into your site much, but would you mind explaining why you decided embedded IF/ELSEs with an OP_0 and/or OP_1 combination before the redeemscript was necessary?

It bugs me in that it seems to scream "inefficiency" at me...

Maybe I'm just crazy... who knows 

The extended private key (starts with xprv) contains all that information, including a fingerprint of the parent.

Tell that to BitWallet devs. They use blockchain.info API.

To OP: lose BitWallet. They're a joke.

２ちゃんで叩かれていつも流れ着くのがreddit…

英語できてよかったと初めて思ったよ…


やっぱ日本(特に２ｃｈのような匿名掲示板)は「とりあえずアンチ」が多くて、真面目に話すにも荒らしがヒドく、やってられない。

最近良くredditで荒らしの話題になりますが、２ｃｈに比べてみたら静かな方だっての是非知ってもらいたい。。。

Dark Wallet doesn't use Stealth Addresses for change.

There is 0 benefit to using Stealth Address for change.

So if I send a 5 BTC input in Dark Wallet to a Stealth Address for 1 BTC... the 4 BTC change will just go to the next change address on my HD wallet change chain. No Stealth.

Man, I don't even know where to start...

You must have an image of Stealth Addresses that are waaaaay more complicated than they actually are.

Let's break it down:

1. Normal Addresses:
How do you maintain privacy?
Not showing publicly and only sending it to people who need to pay you. Not reusing addresses, etc.

2. Stealth Addresses:
How do you maintain privacy?
As far as addresses are concerned, Stealth is as anonymous as a static address can get.. You can post it online and no one can search your balance on a block explorer... PLUS every time someone sends bitcoin to it, a BRAND NEW address (begins with a "1" or "3") is generated.

HOWEVER! 1 and 2 have one thing in common:
Anyone who sends bitcoin to a single use normal address, AND anyone who sends bitcoin to a stealth address can still FOLLOW THEIR COINS FOR AS LONG AS YOU USE THEM.

So if StealthBoB accepted 10 payments for varying amounts to his stealth. No one on bitcointalk can look up his balance from the Stealth Address in his signature, BUT if one of them sends 60 bits to the stealth address, AND Stealth Bob uses it in a transaction along with the other 10 payments received, that person can now see "ok, the transaction signing for my 60 bits I sent (which I know is Bob) also signed for the other 10 inputs for over 10 BTC!!! Bob must have 10 BTC!!!"


This is why Dark Wallet implements CoinJoin. If everyone jumbles their inputs together into lump transactions, that weakness is no longer present (as the assumption that could be made before about ownership of the inputs can no longer be made) and privacy on the address front and on the transaction front is maintained.


Now that you know what a Stealth Address achieves (forces new addresses for each transaction AND prevents anyone who hasn't sent money to it from seeing any of its transactions) it's easy to see how change should be handled.

Just use change addresses like a normal HD wallet. No need to "chain 2 transactions together"... No one is fooled.

If you pay someone and they see you signed a 100BTC input, then sent them 2 BTC... and then sent the 98 BTC change to another stealth address... it would just generate a normal address (beginning with "1") and send it there... Whereas a change address is a one time use address anyways (you don't give out your change address, so it is in effect the same security-wise as an address generated from a Stealth Address.) so you can just generate a new change address and send the change there.


In the end, If there's only 1 input, no matter what you do with the change, ANYONE who knows ANYTHING about bitcoin will assume whatever isn't going to them is going back to the sender.



This brings up a new topic: keeping your inputs in varying amounts and low amounts... THIS is also a big part of privacy.



Also, Using Dark Wallet doesn't turn your bitcoins into darkcoins, btw. "Darkcoin" is a completely separate cryptocurrency from bitcoin, and you must purchase those independantly.

It came to your wallet.

Trezor changes the address it SHOWS, but it stores ALL your old addresses and HIDES them, so that you will not be tempted to reuse them.

Refresh your wallet, and you should see the bitcoins in your balance.

If you don't, then there is a different problem (like someone hacked your BTCJam account or something)

When I say "Accounts" I don't mean private keys. I mean separate branches of the Type 2 tree that can be separated in the Wallet software as separate wallets, but still be recovered by the same seed.

This paper was basically stating that "Because the purpose of Type 2 was to make it easier for auditing by giving people MPKs of individual branches of the hierarchy etc... it leads to over-exposure of many MPKs at many levels, and therefore increases the risk of being compromised... in comparison a Type 1 will only have ONE MPK, and exposing that gets rid of all financial privacy, so people will probably protect it more."

However, mathematically the weakness is exactly the same. Any MPK at any level in the hierarchy combined with any private key from any branch below that MPK can leak the master private key that corresponds with the MPK.

The only difference is that Type 1 lowers your exposure by not allowing for advanced auditing features (which could temp you into giving away sensitive information)

Scammers' thoughts: hmm... bitcoin related? DDOS with ransom note for bitcoin.

Reply: umm, we don't have any money... and our server is covered with DOS protection... soooooo....

Scammers: *Doesn't understand English*


I think they just translate their ransom notes in English and any other correspondence is ignored.

Scum bags.

If you're only using one account of a Type 2, it's actually the same.

The MPK and 1 private key can give you the master private key weakness is still there in Electrum's Type 1 deterministic.

If you were using tons of accounts with 0 hardened keys, then yeah... that would make it more dangerous... I guess.