so DW was first, and you just copied it. then I copied it...  the question is: what now? are you going to change it? I think we should. Fixed. But now I won't be able to recover funds with DW half of the time :-( |
|
|
|
I was aware that sticking an 0x03 on it no matter what was incorrect, but that was the only way for me to get it to work with DW. I was meaning to do a PR for a while on DW for it, but by the time I got around to it, I couldn't find it for the life of me. Then I forgot about it. I should have added a comment there including my big "  " that I had when I saw this in DW. |
|
|
|
Unfortunately, Electrum does not have testnet functionality, so I had to sacrifice 40 cents while experimenting.
That should motivate you to add testnet support there, at some point  That would involve messing with the servers... and I'm not near good enough to add testnet support to the Electrum server repo... heck, I'm not even good enough to do anything... but I do the best I can. :-) |
|
|
|
No I don't think there is anything wrong in my implementation.
Besides non-zero length prefixes, I have tested it quite much.
I can exchange coins via stealth addresses between DarkWallet and my s/w, including several sends in a single tx, and they never got missed.
So I guess it means that my implementation works?
I think it is more likely that Nicolas did something wrong during the first send.
We can try few more times though, if he wants, just to be sure.
I'm always open for more testing.
BTW, @dabura667, are you working on supporting non-zero length prefixes?
I'd like to test it against a different wallet as well.
I've only got sending working for Electrum. But yes, I have non-zero prefixes working for sending bitcoins. Unfortunately, Electrum does not have testnet functionality, so I had to sacrifice 40 cents while experimenting. Edit: Here's how I got it done in Python. def check_prefix(pre_num, prefix, p_hash): # Check the first 'pre_num' bits of both 'prefix' and 'p_hash' and see if they match
assert len(prefix) * 8 >= pre_num, "prefix length too large"
byte_pos = 0
while pre_num > 8: # This compares the first complete bytes as bytes if the pre_num is higher than 8 bits
if prefix[byte_pos] != p_hash[byte_pos]:
return False
pre_num = pre_num - 8
byte_pos = byte_pos + 1
mask_prefix = (((1 << (8 - pre_num)) - 1) ^ 0xff) & int(prefix[byte_pos].encode('hex'), 16)
mask_hash = (((1 << (8 - pre_num)) - 1) ^ 0xff) & int(p_hash[byte_pos].encode('hex'), 16)
if mask_prefix == mask_hash: # In order to check only the first 'prebits' bits of the byte, we mask both bytes to change all bits past 'prebits' length to 0
return True
else:
return False |
|
|
|
|
Currently any transaction with less than minimum fee will give a warning message preventing send.
However, if you set mintxfee to 0 and then try to send 0.5 BTC with only a 0.50000001 BTC output, the client will send:
Input: 0.50000001
Output: 0.5
Miner's fee: 0.00000001
Because a miner fee is merely the difference between sum of all inputs and outputs. You don't actually set the tx fee. The miners just take all unclaimed bitcoins in the transacions.
|
|
|
|
piotr, I improved my tests and don't find any bug on it.
I don't find the reason why the first transaction would fail.
I will generate a bunch of transaction to your stealth address later today, and we'll see if they all get through.
maybe piotr you are missing a modulo somewhere in your recovery code. Usually when something in bitcoin works some of the time, I find it's because you didn't mod p somewhere. |
|
|
|
If one of those addresses later happen to belong to someone else
The person you quoted was talking about the new Identity feature. So I assume this is referring to the Identity feature. The Identity marker is based on your seed which is a random 32 byte integer. The chances of "one of those addresses late happen to belong to someone else" is very low, close to 0. then it's clear money has in one way or another moved from my hand to that hand
If you had my seed, you would have all my bitcoins... sooooo, I don't think privacy would be a concern... losing all my bitcoins would be the concern. But like I said, the chances of having the same seed is close to 0. If you somehow think this is not the case for stealth addresses, go ahead and try to explain.
Stealth Addresses? He was talking about Identity... If you had my seed, you would also have the private keys to all my stealth addresses as well... so again, the problem would not be with anonymity, but with losing all your bitcoins. I think maybe you are not an English native speaker? Could you try to explain what you're trying to say in detail? the more words you use, the more clues we have to go on when trying to understand you. |
|
|
|
So, I am so done with electrum. I just want my btc out
Can I command prompt the private key from the address and go put my coin at blockchain or can I send it to multibit?
0.02btc if you can help me do this in the next 10-15 mins so I don't have to stress all damn day
On the receive tab of the electrum window find the bitcoin address where you sent the bitcoins, right click it and select private key. You can then copy it and import it into blockchain.info or multibit or whatever. Note: Once you've exposed the private key don't use this electrum wallet file again. You will have to create a new one using the file menu > new/restore command in electrum. Thanks. Got the bitcoin back Don't worry, not using electrum for as long as I live. Swept the entire address and throwing it all away. Nice 5 hour waste by me this morning Glad to hear you got your bitcoins back! :-) Remember, this is a practice you should be using for ANYTHING you are doing that you have NEVER DONE BEFORE with bitcoins: (like switching clients, etc.) 1. send a SMALL AMOUNT first. 2. check to make sure you can recover those small amounts and that you understand how things work. (or IF they work for you) 3. If everything is OK, then move the rest of your funds. You should follow these steps no matter what it is you're doing in Bitcoin. Once you've confirmed that whatever it is you are attempting works for you, THEN you can move the rest of your funds into it. Just know that it's not like the programmers of Electrum made the program that way on purpose, so don't blame Electrum. There was some sort of compatibility problem with Electrum and your machine. This is unfortunate, but myself and many others use it just fine. I find one of the biggest problems with Bitcoin is that the most secure ways to use bitcoins are open source projects without any central company, so no user support teams. Yet if you store your bitcoins in some company's web wallet, they could disappear with it the next day for all you know... But anywho, good luck on your future endeavors in the bitcoin space. |
|
|
|
I dont fully get it.
Why arent we just putting the dust output back into another used wallet address?
Let's say the only bitcoins I have in my whole electrum wallet is 0.50010001 BTC and I received it in 1 transaction to 1 of my addresses. Let's then say I would like to send 0.5 BTC to a friend and the minimum fee is 0.0001 BTC (yes I know right now less than half the network will accept 0.00001 BTC as minimum) If there was no such thing as "dust" I would do the following: Input#1: 0.50010001 BTC used up. Output#1: 0.5 BTC to friend Output#2: 0.00000001 BTC to self Miner's fee: 0.0001 BTC Inputs - (Outputs + Miner's fee) = 0 = OK Then I would be using my output fully. However, there is a rule in Bitcoin that states: "If any one of the outputs is less than 5430 satoshis (0.0000543 BTC) this transaction is spam, don't include it in a block." So the scenario above would create a "dust" transaction. As miner's have to include the whole transaction, and that transaction contains an output smaller than 5430 satoshis. To deal with this, some people have proposed "using another output in the transaction to merge with the dust and make it big enough to send." That would be something similar to if the above wallet ALSO had another usable utxo that was, let's say, 0.01 BTC. The idea states: Input#1: 0.50010001 BTC used up. Input#2: 0.01 BTC used up. Output#1: 0.5 BTC to friend Output#2: 0.01000001 BTC to self Miner's fee: 0.0001 BTC Inputs - (Outputs + Miner's fee) = 0 = OK However, adding a new input to the transaction adds 140 bytes to the transaction (along with the 34 bytes for the change output as compared to including it into the miner's fee) (107 once we get support for compressed addresses). Any transaction under 1024 bytes is ok with the minimum fee, but even if you go over by one byte, (1025) then you should pay 2 x the minimum fee to get proper priority. Which would make the trade off of adding an input in order to save 1 satoshi seem illogical. Anywho, if you can think of a better solution, great. But for now the transaction is like this: Input#1: 0.50010001 BTC used up. Output#1: 0.5 BTC to friend Miner's fee: 0.00010001 BTC Inputs - (Outputs + Miner's fee) = 0 = OK |
|
|
|
If you're technical enough to roll dice to create seeds, wouldn't you just do: 1. roll dice etc. to make 32 byte seed. 2. tack on an extra 0x01 to the beginning of the big endian string. 3. run that through the mnemonic encoder. I would assume anyone who knows enough to roll dice and run the numbers through an offline saved version of bitaddress or brainwallet's converter functions and then convert into electrum mnemonic, would know enough to say, "add a 0x01 at the beginning of the seed before encoding." etc. Interchangeability with other BIP32 wallets would be nice, but tbh, electrum kinda did its own thing for a while, so having electrum's BIP32 also be like "its own thing" wouldn't be too much of a problem. This way we can support all old electrum seeds AND new ones. The only drawback is 1. one extra word. 2. no compatibility with Electrum BIP32 seeds and other BIP32 services. I don't view this as being too much of an issue... but if we don't support backwards compatibility and telling someone who just barely understood the concept of "seeds" to begin with. "oh yeah you need to download an older version from our old versions folder which is here. Most people will most likely 1. ignore such warning. 2. download latest version 3. get error on restore seed. 4. either complain in forums or just give up and throw seed away thinking "I was scammed by bitcoin" I am all for backwards compatibility. Even if it means an extra word and not being able to use mnemonics with other programs. |
|
|
|
Thanks Thomas. I took a look at the open issues. Many of them are just questions, like: "It would be cool if Electrum had contact names" https://github.com/spesmilo/electrum/issues/451This issue open since Nov 22, 2013. At what point is a decision made, should we include this feature, or close the issue? I'm just trying to figure out what to try to work on another example: issue 543, Debura said "I think its a non issue" back in March, and nothing has been done , issue is still open... If you have a good method of eliminating dust transactions (#543) (any transaction with an output less than 5430 satoshis) feel free to send a pull request. it's just that the methods being proposed were generally: Add another input so the change output won't become dust and won't be included in the fee. However, Electrum currently uses uncompressed addresses, so adding a whole new input would most likely push the recommended fee up a tick, so it would be cheaper to just pay the dust in the tx fee. I personally find it to be a non-issue, but if you have a good idea, feel free to submit a PR. |
|
|
|
Ah , ok...so they already got this covered.
How do you suggest I contribute to the electrum project?
Add interesting plugins. Look at how each plugin in the plugins folder interfaces with the main UI using run_hook, and see if you can create any useful plugins first. If they are good enough, they will probably get merged into the main UI. Also if you see any issues that haven't been resolved and you are able to debug them and fix them, please submit the fixes in a pull request. Edit: If you can figure out this one, it'd be awesome. I didn't notice, but all of a sudden the Wrong password UI stopped popping up and only shows up in the terminal. https://bitcointalk.org/index.php?topic=612521.0 |
|
|
|
2.0 will support 2 of 2 and 2 of 3 multisig wallets that are created deterministically. Thomas is also preparing a service to help facilitate multisig as well. Not to mention the Kivy Android GUI project will facilitate that as well. See the roadmap here: https://bitcointalk.org/index.php?topic=427617.0 |
|
|
|
dabura667 you are slightly incorrect.
Elliptic curve point addition is not the same as regular addition.
P + Q = R where
s = (yP - yQ) / (xP - xQ) mod p
xR = s2 - xP - xQ mod p and yR = -yP + s(xP - xR) mod p
In the case of secp256k1 the value of p is a large prime = 2^256 - 2^32 - 2^9 - 2^8 - 2^7 - 2^6 - 2^4 - 1 = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F
He was talking about adding the spend private key (32byte integer) and the shared secret hash (32 byte integer). So actually it is just normal math, not adding two EC points. d + c should always be 32 bytes. It's the addition defined by secp256k1 which is modulo the p value.
Wait a second, d and c is not an addition defined by secp256k1. D and C both are normally integers, not EC Points. I agree with P and Q, but my problem is with d and c. Their addition should give 32 bytes to be a valid private key. Genjix, your source is for the address generation, which is not the part that give me problem. It is the d + c part that I don't understand. But nevertheless, I'll create my test vector with sx, it will simplify the discovery of were my bug is. If you can read Python, here's the method I simplified. https://github.com/spesmilo/sx/blob/master/src/obelisk/bitcoin.py#L1104string_to_number and number_to_string are both methods from the ecdsa python library's util.py |
|
|
|
Mimicking their mistake will only result in unnecessary problems for you.
Shame. Do we happen to have any idea when the btc payment protocol will be released? I have seen a few posts about it around the net but nothing really concrete. Incidentally alsbo do you know what is the minimum amount of btc i am able to send over the network, for example 0.00000001 would cost 0.0001 to send. Does the network accept this? If any outputs of a transaction are less than 5430 satoshis (0.0000543 BTC) it will not be mined. |
|
|
|
http://blockchain.info/merchant/***HIDDEN***/sendmany?password=***HIDDEN***&second_password=***HIDDEN***&recipients=%7B%22***HIDDEN***%22%3A5810%7D¬e=Thank+you+for+using+GratisBitco.in%21 Am I doing something wrong? Or is it a bug in the BlockChain Wallet API? the "." in GratisBitco.in in your message is messing it up. you must encode it with %2E Answer: http://blockchain.info/merchant/***HIDDEN***/sendmany?password=***HIDDEN***&second_password=***HIDDEN***&recipients=%7B%22***HIDDEN***%22%3A5810%7D¬e=Thank+you+for+using+GratisBitco%2Ein%21 |
|
|
|
The order you should modulo with is: 115792089237316195423570985008687907852837564279074904382605163141518161494337 (in hex, 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141) Basically, once you get your number from adding the two private keys converted into integers, modulo against the above number. (this is the order for secp256k1) in python it might look like this. (super simplified using only simple python math opperands. def add_modulo(d, c)
#d and c are 32 byte hex strings
#so first turn them into integers
int_d = int(d.encode('hex'), 16)
int_c = int(c.encode('hex'), 16)
#then add them and modulo the order of the curve (constant)
int_e = (int_d + int_c) % 115792089237316195423570985008687907852837564279074904382605163141518161494337L
#convert into a 64 digit hex number with leading 0s at the beginning. (ie. if int_e was 196, you would have '000...(64 total digits)...0C4')
str_e = '%064x' % int_e
#convert that 64 hex digit string into a 32 byte hex string.
return str_e.decode('hex') When I modulo N, it works fine... but why I have never 31 bytes ? You would place leading 0s to make it 32 bytes... so if your modulo was 31 bytes when converted to hex, you would put 0x00 as the first byte. 0x38DF...(31 bytes total) would become 0x0038DF...(32 bytes total) |
|
|
|
|
What version are you using?
|
|
|
|
https://blockchain.info/api/blockchain_wallet_apiHost your own website, make a php gateway that asks you for your password. Then once it checks your blockchain password, make it ask for a csv file. Then once it parses the csv into a variable in php, follow the "Send to many" instructions at the link above. Then have the site show the transaction just in case, then have it ask for your second password if you have one. Then send the transaction via api. This would take a competent programmer who knew php and was familiar with Bitcoin transactions maybe a couple hours to make and test. Then all you would need is somewhere to host that site so that you could access it on the go. try /r/jobs4bitcoin, I'm sure someone would make it for you, but you'd have to host it somewhere.
|
|
|
|
Thanks, but is not there any web wallet that support data fetching from excel sheet ? So you would rather use a web wallet than secure local wallet? Yes, because I need to get stuffs done on the go. You have large Excel sheets on your phone? |
|
|
|
|
Show Posts
