Free, just go ahead and run your unsecured wallets on this service like the OP recommends, I'm sure nothing will be stolen...</sarcasm>

You have been logged in for 26 hours, and have started 16 topics and made five polls.
I have been logged in for for 1710 hours, and have started 71 topics and three polls.

"Wise people talk because they have something to say; fools, because they have to say something." - Plato

I was joking here because I assumed it must have been tested and be operating as documented, but I recently used the script to broadcast 2 satoshi to the service, and after two weeks they still were not mined. I sent a PM to Peter Todd Oct 5 about the service and the usual time he has seen for inclusions, and got no response even though he has logged in since then. Is there any anecdotal evidence of this working, and if so, when?

I had 1600 of these payments by gaming one of the blockchain-spamming bots into sending me btc. I finally decided to consolidate all the payments after revisiting my files full of them, which wasn't too hard, miners were happy to take them with 0.00001 BTC fee per kB, in various transactions from 10k to 100k, which resulted in a final fee of about 20%.

Somebody else attempted to spend one by itself which is likely to never confirm, so I'll double-spend it. It needed to be spent by someone, otherwise the whole transaction which sent it (along with hundreds of other payments the spammer sent) will be unprunable from the blockchain.

The others are spent now.

Posting a private key is like giving the ability to spend the money away to anybody. Addresses should not be reused anyway, so it doesn't matter as long as you know what you are doing.

Here's a transaction fee's worth of private keys with 0.00001 BTC on each then. As long they are going to be spent, I've got 1500+ more...

L4JyPUuq1qcokcunDvZcQceU...

edit: all gone!

I specifically don't, because this would rely too much on the quality of the system random number generator PRNG instead of user-created entropy, which could conceivably link the addresses together and allow for cryptanalysis, especially with low system entropy available or intentionally flawed OS implementation. I could fashion something, but I would need to sweeten the random, maybe by throwing several rounds of scrypt hash XOR SHA hash XOR user entropy per urandom sourced key, with enhanced urandom reseeding while you keep pounding the keyboard.

I have also made this work with MinGW-compiled C scrypt code to make encrypted BIP38 wallets in less than a second vs 8 minutes. The all-in-Python script is written for easy verifiable LiveCD use; the Windows exe might as well be more utilitarian since it can't meet this challenge. However, I am having difficulty getting it packaged with py2exe, which seems to turn the pyd dependency into a pyo, and then the exe bytecode can't find the _scrypt code. Still have some more things to try.

Testnet. https://bitcointalk.org/index.php?topic=341252.0

A deterministic wallet is simply a way of generating addresses. Bitcoin classically generates new private keys using a true random number generator for each address. When a new address is needed to request a payment, it is generated at random and is not related to any other key. A deterministic wallet instead uses a pseudo-random number formula to create addresses, with only the initial seed state being a generated random number. This prevents the wallet backup from becoming obsolete, because any past or future address you created can be recreated from the seed backup.

Pruning is a technique for reducing blockchain disk space consumption, and is unrelated to your wallet addresses. We assume that the blockchain history has already been thoroughly validated by many miners after it is buried under many blocks and that every transaction in it was properly signed by the owner. Therefore, as long as the hash chain in the headers is correct, we don't need to verify the chain-of-ownership of every single bitcoin amount back to its original creation for our own security. This allows an individual client to remove the spent transactions from the blockchain, potentially freeing hard drive space, and even may enable a 'pruned network' p2p client to exchange a lightweight blockchain between peers.

The "plan out there" for pruning was put forth in the original Bitcoin paper: http://we.lovebitco.in/how-bitcoin-works/bitcoin-paper/#ch7 - it is just that nobody has written a complete client implementation that does this yet.

This is a wealth of nonsense that shows a complete lack of understanding of how mining, target, difficulty, or even binary math work, which then conjures up a nonexistent issue.

A SHA256 hash is 256 bits long. 256 bits can represent a number between

0
-and-
115792089237316195423570985008687907853269984665640564039457584007913129639935.

A hash of arbitrary data will return a hash with a value within this interval, seemingly at random, with equal distribution.

Difficulty specifies that a lower number threshold is required to "win", that a found hash value must be significantly smaller than the maximum. If we make the threshold 100 times smaller, only one in 100 hashes will win. The starting point with Bitcoin at difficulty 1 requres a hash value 4295032833.000015 smaller than the maximum, meaning only 1 in ~4.3 billion hashes will meet the difficulty 1 challenge.

The actual difference between steps can be easily calculated. Bitcoin encodes the difficulty target with nearly six significant figures in hex. I won't try to explain how it is actually encoded.

Here we show the next possible difference increment after difficulty 1 is difficulty 1.000015259254738:
>>> (0xffff * 2.0**208) / (0xfffe * 2.0**208)
1.000015259254738


The current difficulty target is:
0x00000000000000001F6973000000000000000000000000000000000000000000
which is difficulty 35002482026.13323

The next possible difficulty target increment is
0x00000000000000001F6972000000000000000000000000000000000000000000
which is difficulty 35002499029.10224

The ratio between these two is 1.0000004857646665, which is enough accuracy that even a one-second difference in the two-week mining period measurement will result in a different difficulty.

It's personal preference unless you want to share your code with others or make consistent interchangeable code. Then you follow PEP8 (If you don't recognize the authority or authors of that document, just note that one of them is Benevolent Dictator For Life):

Lower case for functions and variables: http://legacy.python.org/dev/peps/pep-0008/#function-names

Indentation at four spaces is also specified: http://legacy.python.org/dev/peps/pep-0008/#indentation

Highlight this quote with your mouse cursor, and you will see that as you highlight the indentation, it is not spaces, but tab characters that you cut and pasted here:


I was pointing out the blockchain.info address interface does have a currency selector at the bottom-right that will change all BTC amounts to their fiat equivalent, writing a program to get the info is superfluous unless this snippet goes on to do better things.

You should learn about and implement exception handling when programming for the web. You do not want a flaky website controlled by someone else to be able to crash your program or do unexpected things, nor do you want unparsed user input sent to an API via your program.

https://urllib3.readthedocs.org/en/latest/exceptions.html


PHP will also get you some interwebs:


This uses https://bitcoinaverage.com/api - using this exchange rate API, you could retrieve the list of supported currencies and prompt the user or do sanity checks before API calls.

Bitcoin has limits written in its code that are for the good of the network. Sending payments that are worth less than 1/3 of the fee is a non-standard transaction, fees are required for most transactions, and are based on data size. These are for the good of the network and the people that participate in it by running the Bitcoin client.

Being part of the Bitcoin network by running a full client also means that you must have a complete record of every historical transaction downloaded. It means that you can be flooded by spam transaction on the network that you then must not forward to multiply the attack.

Bitcoin is a consensus system, and the rules about fees are up to the individual clients to honor. There are still some miners that will include the dust transactions, so it is still possible to send someone annoying dust that costs far more in data consumption and network fees than its value.

I've got a link in my sig, something along the line of "how Bitcoin works", which should be just about the right size to read and comprehend.

Here's a private key with 0.00001 BTC on it, no fee required to import it, but also not enough money to send it anywhere.

addr: 19bjqNiSWxMuCcbzcszS37BJfNMKLA7vh1
priv: L3Upbvtaij1xMmG2iXTokSgguAPy3c4fnR81xFcUKc2263hapovb

On Tor, you are allowing someone to be a man-in-the-middle. The exit node can see and intercept all traffic between you and the website, can present a fake phishing site to you, can record all traffic, can wrap SSL in their own certificate, etc. It is anonymous but not secure.

It is more likely that the computer was trojaned though. The PC cannot be trusted, it should be wiped and reloaded. It is not a good idea to let your "friends" use your computer that accesses your Bitcoins, many people would find 600 BTC + more valuable than a friendship.

I simplified it for you.


Replace the tabs in your code with four spaces and rename all the variables to lowercase and then we can start talking..

Addresses are not wallets, and looking up an address on some chaininfoexplorer will not yield the balance you expect.

It's about 1 in 600.5001389 chance a block will be found within a second following another. However a block find faster than the network latency does not always result in an orphan - it is not an orphan if the same miner also found the following block.

That is the problem with orphans, they reduce the strength of decentralized mining against attack, by favoring larger miners and discarding proof-of-works that would otherwise strengthen the difficulty. An extreme demonstration of this was just had on testnet after a reset to difficulty 1 vs difficulty 100k hashrate: Even holding 1% of the network hashrate it was impossible to get your block find published, because the largest miner was finding blocks at nearly one per second and building upon their own chain even though they didn't have a majority hashrate nor were they running an "attack" client.

An attacker can enhance the chance of a malicious block acceptance by not including irrelevant transactions. This is in addition to a 51% attack actually becoming a 49.83% attack with a one second delay between legitimate miners. There is already a multisecond delay in pooled mining between the pool software learning of a new block from bitcoin, and pushing it out to miners, and their miner software flushing the work and getting the new block hashing on hardware.

Even with fast SSDs in RAID1 to store it on, the blockchain costs less than $1 per month in storage media. That is a miniscule cost compared to the Internet connection or dedicated phone line that any business running customer bank transactions would use, or the cost of leasing a credit card terminal from a merchant services provider. One credit card chargeback avoided by using Bitcoin can pay for decades of blockchain storage.

A merchant using Bitcoin for point-of-sale will not have a copy of the blockchain at every cash register. The point-of-sale terminal only needs to show a pay-to Bitcoin address, and a message to the cashier that the payment has been accepted. Everything else will be done in the server room of corporate headquarters or at an outsourced payment processing company.

I have info about using the blockchain for such a raffle picker here: http://we.lovebitco.in/raffle - If using the Bitcoin blockchain and if the reward is not on the order of 100 BTC+, then even a 50% miner who bought 50% of the tickets would not find profit in discarding a block that would make him a lottery loser.

The risk is much higher that the lottery operator is dishonest. The raffle runner can purchase their own tickets with sock puppets for free and can increase the odds that they pay the reward to nobody.

If there are a fixed number of tickets, say 100 0.01 BTC tickets for a 1 BTC prize, than it can be fairer vs operator sock puppets. In this case you are buying a 1% chance of winning regardless of who owns other entries, but it is likely the operator disappears when a legitimate winner actually wins if he is a scammer.

As long as we are pondering useless stuff..

It occurs to me that this could be more compact.

Let's take a random recently-seen address:


This is your min-address format:
4f4d6-1pi9

Instead of block number + firstbits of a block, we can get all the information from the structure of transactions in the blockchain, and then encode it smartly.

We can find the first occurrence of a payment to an address, and then refer to it by block_number->transaction_number->txout_number

We can call this micro-address. It can be the base58 encode of a bitstream-type encoding of the above data:

Most-significant-bit placeholder
1st bit set to 1

block number:

bit 0 - len of block count:
0 - 23 bits
1 - 31 bits

bit 1-24 or bit 1-32:
23 bit length: (blocks 0-7fffff) (blocks 0-524287)
31 bit length: add 00800000 (0-7fffffff + 00800000) (blocks 524288-8912895)

transaction number in block:

bit 0-2: length: number of words + 2 - 3 bits

000: 5 bit length (0-31)
001: 9 bit length (0-511)
010: 13 bit length (0-8191)
...
111: 25 bit length (0-33554431)

vout number:
bit 0-1: length: number of words + 2 - 2 bits

00: 6 bit length (0-63)
01: 10 bit length (0-1023)
10: 14 bit length (0-16383)
11: 18 bit length (0-262143)


for my example address:

block 234822, 0x39546h : 000000000000000006880233f89f572f006fd5dad0d1729d6d81622e8921e15f
transaction #18, 0x11h : fe17ff4c6df314cc708b2bab011a6327b61ffce81b4f7948ca8c6e7d3ee46105
vout #3, 0x02h:  address 1Pi9uP6YMqbvbrQ1b7m6qzAS5ejN7mSwWR

encoding base58(bitstream):
MSB 1:        1
block# bits:  0 00000111001010101000110
trans# bits:  000 10001
vout# bits:   00 00000010

>>> hex(0b1000000111001010101000110000100010000000010)
'0x40e55184402L'

>>> bitcoin.changebase('1000000111001010101000110000100010000000010',2,58)
'329UugoB'


So I get an eight-character micro-address of 329UugoB.

The length here doesn't vary based on how many bitcoin address characters it takes to be unique within a block. It only gets longer after  block 524287 or if there was a huge block and the transaction also had many outs. I'm sure even more optimized encoding could be thought up to minimize the average address lookup bits required.

He doesn't have an idea, that's the point.

The most successful business model are middlemen. They produce nothing, they just move money around and keep a portion for themselves. Take, for example, PayPal - they just transfer money between accounts in their computer system, keeping 3% each time until eventually all the money is theirs. Credit cards, same thing. Casinos, pretty much the same thing too...

Bitcoin has the money transfer mechanism included in the protocol so it doesn't need such middlemen. There are still opportunities such as ATM operators, escrow agents, auction houses. eBay is one of the more clever scams, they never see the money or merchandise, but still bill a percentage of the sales price just for hosting a web page for your item for a week.

Bitcoin is just money. Why should I send you my money? Goods and services. You should have something you would pay for yourself.

Yes, I was tipped a sweet $3 for my time. Judges, mediators, and lawyers also get paid.

That's the trust that I've left against others. Your ad hominem attacks display your lack of reasonable counter-position.

If thanks to me you go away, then thanks to me indeed.

The identical tone and eloquence with the English language in this post vs PMs has removed any remaining doubt for others that you were the author of said messages.