Well done domob, the vision becomes reality ... might be sending a tip to id/domob now it is so easy  Thanks, I'm glad you (and others) like it!  What is the spec of this, does it parse full JSONs, etc? As an example, here is one of the first id namespaces, my id/deepceleron with a signed message: {"info": "1DCeLERonUTsTERdpUNqxKTVMmnwU6reu5", "cert": {"address": "1DCeLERonUTsTERdpUNqxKTVMmnwU6reu5", "id": "deepceleron", "info": "deepceleron CA", "authority": "deepceleron", "authbtc": "1DCeLERonUTsTERdpUNqxKTVMmnwU6reu5", "authnmc": "N76D6hEHB55cGPk8QiG6ysgMbXb11b3nAH"}, "sig": "GweBRP+1YnKIMmXuwtsk4zlR7jUuPZxiazfNUbheGRMkomMs4lo/XpNpCDVLujrEynCGYe9dxs/M9nOp98EsXpI="} As you can see, "info" is a Bitcoin address, and other stuff is inside a "cert", and that cert message is signed by the Bitcoin address. |
|
|
|
|
Oops, I've had the wrong sha256sum in the first post since January, updated. I guess that shows how many people have actually tried this out...
|
|
|
|
The signature data is encoded using ASN.1 stream encoding. Although Bitcoin implementations just shove signature bytes where they should go, it would be more correct to actually use an ASN library to make the DER-encoded signatures. That way there would not be mystery undocumented bit-set data such as the tag identifier, which are not just arbitrary bytes, but define the encoding method of the following bytes. I documented this a bit before, walking through each byte of a transaction with the DER docs in hand (although I didn't make a pretty table):
Transaction data format version (uint32_t):
01000000
TXIN:
TX_IN count (number of Transaction inputs, satoshi VarInt):
01
TXIN DATA:
Previous txout hash:
21eb234bbd61b7c3d31034762126a64ff046b074963bf359eaa0da0ab59203a0
Previous txout index:
01000000
Script Length:
8b
Signature Length: (48h = 72 bytes)
48
ECDSA Signature (X.690 DER-encoded):
ASN.1 tag identifier (20h = constructed + 10h = SEQUENCE and SEQUENCE OF):
30
DER length octet, definite short form (45h = 69 bytes) (Signature r+s length)
45
ASN.1[/url] tag identifier (02 = INTEGER):
02
Signature r length (DER length octet):
20
Signature r (unsigned binary int, big-endian):
263325fcbd579f5a3d0c49aa96538d9562ee41dc690d50dcc5a0af4ba2b9efcf
ASN.1[/url] tag identifier (02 = INTEGER):
02
Signature s length (DER length octet):
21
Signature s (first byte is 00 pad to protect MSB 1 unsigned int):
00fd8d53c6be9b3f68c74eed559cca314e718df437b5c5c57668c5930e14140502
Signature end byte (SIGHASH_ALL):
01
Key length:
41
Public Key prefix:
04
Public Key part x
52eca3b9b42d8fac888f4e6a962197a386a8e1c423e852dfbc58466a8021110e
Public Key part y
c5f1588cec8b4ebfc4be8a4d920812a39303727a90d53e82a70adcd3f3d15f09
Sequence Number:
ffffffff
TXOUT:
txout number:
01
Value in base units:
a086010000000000
Script Length (107 bytes):
6b
Script (if we were to run it):
OP_PUSHDATA1 - The next byte contains the number of bytes to be pushed onto the stack:
4c
Bytes (68 = 104 bytes):
68
STACK DATA 104 bytes:
4c554b452d4a522049532041205045444f5048494c4521204f682c20616e6420
676f642069736e2774207265616c2c207375636b612e2053746f7020706f6c6c
7574696e672074686520626c6f636b636861696e207769746820796f7572206e
6f6e73656e73652e
Lock Time (cannot be included before this block):
00000000
|
|
|
|
|
Be mindful that there is no practical reason to "convert" between uncompressed and compressed public keys. Each has their own Bitcoin address - you cannot spend funds sent to the uncompressed public key's address with the compressed public key.
|
|
|
|
I don't know what you are on about in the first post. Click the link: https://bitcoin.org/bin/0.9.1/There are both ZIP and exe files. The zip file you can extract to any directory and run. It includes both the 32 and 64 bit binaries. The exe files are an installer, when you run it, you will be given options to install the program in windows like you would for any other program. Many installers exist, such as NSIS and Installshield. Program authors use these to distribute their programs to non-technical users. An installer creates the start menu icons and uninstall options that you would expect from a program installed in Windows. |
|
|
|
ELI5
Imagine putting your toys in a box. Then you put a lock on the toy box. Only you know the combination to unlock the box. You need to remember the combination in your head, because if you write it down, one of your enemies might find the combination and steal your toys. If you want to give a toy to one of your friends, you will need to use the combination to unlock the box. Once you open the lock, it's not as safe to put the toys back in the box and lock it again. Someone could have seen you enter the combination. The lock might not be designed well, and after you unlock it once, it's easier for someone else to unlock it again. You should put the remaining toys in a new box with a new combination. End of ELI5. BIP38 uses robust, slow, and difficult to brute-force encryption. It does allow users to put in their own password though, and users can make bad decisions. It doesn't prevent you from putting "password" as your password, or trivially short passwords that would be found quickly. |
|
|
|
I'm sorry, I didn't read the whole topic. Is there any way the result to be exported in a text file?
Thanks.
: Installation:- If GPU acceleration is desired, install ATI Drivers v11.10-v11.11 (with SDK 2.5) or only another driver version already verified to work with your GPU, and test that OpenCL is working (with GPU miner software, etc). If drivers with SDK >2.5 have been installed, files may need to be manually removed.
- Download and unzip vanitygen-0.22-win.zip to it's own directory.
- To interact with the program, you need to open a terminal/shell/command prompt in the program's directory. In Windows Vista/Win7 Explorer, hold down the shift key on the keyboard while right-clicking the folder where vanitygen was extracted, and choose Open command window here.
- Test CPU operation. This command line will generate a Bitcoin addresses beginning with 1ABCD in around a minute or less:
>vanitygen 1ABCD - Test GPU operation. This command line will generate a Bitcoin addresses beginning with 1ABCDE in around a minute, using the first OpenCL device in your system:
>oclvanitygen -d 0 1ABCDE
OpenCL GPU device configuration:OpenCL is the language used for talking to a GPU, and is installed with the video card driver. If the above GPU command didn't run correctly, generating over 1Mkey/s, then you should examine your OpenCL configuration. Remove the -d 0 option ("use device #0") from the command line above and run it again, which will list available OpenCL devices. Here's mine: >oclvanitygen 1ABCD
Available OpenCL platforms:
0: [Advanced Micro Devices, Inc.] AMD Accelerated Parallel Processing
0: [Advanced Micro Devices, Inc.] Juniper
1: [GenuineIntel] Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHzBoth a GPU and the system CPU are available in my system; on yours, the GPU may not be the first listed. "Juniper" is this AMD GPU's code name. The first line is the platform number, the second two lines are the available devices under that platform. Change the -d 0 line in the example above to the GPU desired. If no GPU is shown, the video card driver or OpenCL is not installed properly. If you have multiple OpenCL SDKs or implementations installed, more than one platform may be shown, specify the correct one (e.g. -p 1 for the second platform if shown.) Example command lines (oclvanitygen, device 0, default platform):- Search for exact prefix 1ABCDE, keep searching after first match is found (-k):
>oclvanitygen -d 0 -k 1ABCDE - Search for prefix 1ABCDE in any combination of upper or lower case (-i):
>oclvanitygen -d 0 -i 1ABCDE - Search for ABCD anywhere in address (only supported on CPU vanitygen) (-r):
>vanitygen -r ABCD - Search for prefix 1ABCDE, use a seed file to make address generation more secure and random (-s):
>oclvanitygen -d 0 -s RandomSeedFile.txt 1ABCDE - Search for prefix 1ABCDE, keep searching after first match is found, and save all found address to a file:
>oclvanitygen -d 0 -k -o GeneratedAddresses.txt 1ABCDE - Search for many prefixes at once using a text file listing them (newline after each prefix including last):
>oclvanitygen -d 0 -k -f PrefixList.txt - Use all options above including case-insensitive search, and turn on verbose mode for more information:
>oclvanitygen -d 0 -v -i -k -f PrefixList.txt -o GeneratedAddresses.txt -s RandomSeedFile.txt
I found an address, now what?Vanitygen finds an address that matches your search parameters, and provides the private key for that address. The private key is never shown to you in the Bitcoin client; it is used behind the scenes, and is the secret part of your address that you should never give to anyone. The mainline Bitcoin client does not have the ability to use private keys directly, but you can do other things to use bitcoins sent to your new address: - In Bitcoin-qt: Help -> Debug window -> Console. Type importprivkey 5Jxxxxxxxxxxx "my vanity addr"
- Use an alternate Bitcoin client, such as Armory, that has an "import private key" feature,
- Use a web wallet or exchange service that allows you to add a private key to your account (usually insecure and irreversable).
|
|
|
|
Bumping this with a bounty.
Bumping this with an answer. |
|
|
|
If you plan on making a long-term backup, for the purpose of safeguard against data loss, after encrypting with a passphrase, you might consider starting Bitcoin once with a large keypool option such as bitcoin-qt -keypool=2000. This will fill the wallet with future keys that will keep your backup from becoming obsolete for a long time.
|
|
|
|
What's the matter anyway? The upstream is dead? Is there
any development on a p2p datafeed distribution project somewhere?
It would be nice to have a problem description, as I don't regularly run this just to check the services it connects to. I just ran sierrachartfeed, and it updates the 5-day history OK, but I haven't gotten any trades from the live socket stream in the five minutes it's been running. Since it connects and subscribes without error, the live stream is not completely down, it just looks like there is no trade data coming through the live stream socket. This will be something that bitcoincharts admin "tcatm" will have to sort out, as it's probably some internal server problem (if the service hasn't been changed or discontinued). The version number of sierrachartfeed is in the python script. I quit changing the name of the script with a version number included in the name, so that you don't have to alter batch files that call it with your own list of tickers. The version number doesn't matter that much, as only the most recent version works - all the old versions have been broken by changes at bitcoincharts. |
|
|
|
You will read that even with the stupidest random number generator, address reuse was required due to the dual-layer protection of both ECDSA and RIPEMD160 and SHA256 hashes. It appears you are here to troll rather than to learn though. |
|
|
|
Not news. Bitcoins have been stolen, but from completely broken random generators, and by people making their own private key with stupid algorithms. Here's a thread with lots of conversation for you to read: https://bitcointalk.org/index.php?topic=419259.0 |
|
|
|
You can come back to this thread:  |
|
|
|
I'll just consolidate some old quotes of mine here These two statements appear to be in dissonance, but are both true: - The average time to solve a block is 10 minutes
- Half the blocks will be solved in under 7 minutes
Obviously easy to confuse the two when calculating things. So the chance a block won't be found after 10, 20 minutes, etc. (and the 1 in x chance) >>> for x in range(10,131,10) :
print x, '%2.5f%%' % (100*math.exp(-x/10)), '%1.2f' % (math.exp(x/10))
20 13.53353% 7.39
30 4.97871% 20.09
40 1.83156% 54.60
50 0.67379% 148.41
60 0.24788% 403.43
70 0.09119% 1096.63
80 0.03355% 2980.96
90 0.01234% 8103.08
100 0.00454% 22026.47
110 0.00167% 59874.14
120 0.00061% 162754.79
130 0.00023% 442413.39And after how many minutes will half of blocks, 25% of the blocks, etc. not be solved: >>> for x in [ 10*math.log(2), 10*math.log(4), 10*math.log(8), 10*math.log(16), 10*math.log(32), 10*math.log(64)]:
print x, '%2.5f%%' % (100*math.exp(-x/10)), '%1.2f' % (math.exp(x/10))
13.8629436112 25.00000% 4.00
20.7944154168 12.50000% 8.00
27.7258872224 6.25000% 16.00
34.657359028 3.12500% 32.00
41.5888308336 1.56250% 64.00And every day we can reasonably expect a block longer than 49 minutes, every week one longer than 69 minutes, every month 83 minutes: >>> for x in [ 10*math.log(144), 10*math.log(144*7), 10*math.log(144*365.25/12)]:
print x, '%2.5f%%' % (100*math.exp(-x/10)), '%1.2f' % (math.exp(x/10))
69.1572344863 0.09921% 1008.00
83.8548870042 0.02282% 4383.00Note the "long tail" on the chance of not finding a block after x time: ...the probability density function of an exponential distribution looks like this:  Note that the average block time is 10 minutes (1/λ), but 50% of the blocks are less than 6.93 minutes (the median ln(2)/λ). Deepceleron's razor #17: If something is worth saying to a noob, deepceleron has probably already said it.
|
|
|
|
Does anybody have the estimated earnings formula as well as the estimated time to generate a block formula which are used in the gribble bot on #bitcoin-dev etc? Preferably where I can also specify the block reward as well(for altcoin earnings calculation).
If that was too much reading... - Average days per block reward = (0.04971102816 * difficulty) / (megahashes per second)
- Average earnings per day = (megahashes per second / difficulty) * 20.11626066 * block reward
Usage example: average days per block find at difficulty 1 using 7.158388 mHash/s: 0.04971102816 * 1.0000 / 7.158388055 = .006944444 days = 10.000000 minutes Usage example: average days per block find at current difficulty 6978842649 using 7.158388 mHash/s: 0.04971102816 * 6978842649.5924 / 7.158388 = 48464158 days = 132,691 years -note, that mystery constant is exactly (2.0**48) / 65535 / 600.0 * (10.0/1440.0) / 1000000 |
|
|
|
Due to the scheduled halfing of the block reward every four years, the new number is: Average BTC per Day = (megahashes per second / difficulty) * 502.91419New realistic examples using today's network statsRadeon HD 5830: 300 Mhash/s at 3438908.96 difficulty = ( 300 / 3,439,000 ) * 502.91419 = 0.043 BTC per day or 1.32 BTC/month ≅ $16/month BFL Single FPGA Miner: 832 Mhash/s at 3438908.96 difficulty = ( 832 / 3,439,000 ) * 502.91419 = 0.12 BTC per day or 3.65 BTC/month ≅ $45/month You can also use the equation to determine your average time to a block find - the amount of time required for a hashrate to have a 50% chance of generating a block. If you make: 0.01 BTC per day How long to generate the full 25 BTC reward? 2500 days. To find something different, we just rearrange the equation. Let's find how much hashrate would be required to generate a certain income at a given difficulty: For X btc per day, the hashrate required is (X btc per day * difficulty) / 502.91419 = Y MHash/s Thus, to make 1 BTC/day (1/3600th of the daily total reward of 3600BTC): 1 BTC * 6978842650 difficulty / 502.91419 = 13,876,806 MHash
You will see this is correct, it is 1/3600 of the current hashrate:  To do all of this algebra (sorry, work not shown), what we start at is the probability of a single hash solving a block, which is 65535 x 2 -48 x difficulty -1 |
|
|
|
|
The relay fee is also the transaction fee, but it refers to a different use than what you may know. A transaction fee is included with a transaction to encourage and reward miners for including the transaction in the blockchain.
"Relay fee" refers to the minimum fee amount that other clients on the peer-to-peer network require in order to forward transactions to other peers. This fee is in place in order to prevent the broadcast and propogation of DDoS-like spam transactions.
The relay fee is coded in a different place than the transaction fee in Bitcoin. In the past, it has also been set at a different amount than the transaction fee. For a good portion of recent Bitcoin history, the minimum transaction fee used by the Bitcoin client and by most miners was 0.0005 BTC per kB, but the minimum relay fee was coded at 0.0001 BTC. The transaction fee was then lowered, bringing them in sync.
|
|
|
|
I don't know of a coin that isn't simply using the Bitcoin address scheme with just a different network byte. I have blocked the altcoin subforums here because they add so little (such as "coin developers" that can't code), so can't speak with absolute authority, as I haven't been following closely. There is free Python paper wallet code here: https://bitcointalk.org/index.php?topic=361092.0 ; I know the developer. The gmail and immediate desire for off-forum correspondence by a noob likely will result in no bounty ever being paid. |
|
|
|
I was thinking about something else
What if we sold paper wallets containing 1BTC on eBay?
we shipp it with tracking and everything
could paypal put a halt on it then?
They can and arbitrarily do anything they want, refunding the buyer, locking your Paypal account and funds, cancelling your other listings, invalidating past listings and scraping back those funds also, clawing back money out of your linked accounts, sending you to collections. Even with a signed delivery confirmation, a buyer that "disputes" only needs to return your (emptied) piece of paper with tracking to automatically win a dispute. |
|
|
|
|
Show Posts
