text:
Is Z-man's PTLC construction implementable using libsecp256k1-zkp?
In a mailing list post Z-man details a PTLC construction which he claims is "is almost entirely a MuSig ritual". My question is whether this MusigTweak is what is called the adaptor (last argument of secp256k1_musig_session_combine_nonces) in secp256k1-zkp? And has in fact been implemented?
How is MusigTweak computed? Is it the per-hop tweaked payment point, which means it will be the payment point for the hop connecting to the payer?
In a way, that wouldn't make sense since MusigTweak takes three arguments, and the payment point is the same for both channel partners. But on the other hand, maybe Z-man is describing how the tweaking works internally in libsecp256k1-zkp, and I can safely just use the tweaked payment point for both peers for the adaptor argument because the implementation will treat the adaptor differently depending in the index of the signer?

My question is whether this MusigTweak is what is called the adaptor (last argument of secp256k1_musig_session_combine_nonces) in secp256k1-zkp?

No, what "Z-man" refers to as MusigTweak is not called the adaptor in secp256k1-zkp. The difference between the normal MuSig ritual and the "almost entirely MuSig" ritual is not the MuSigTweak. The MuSigTweak just determines how keys are aggregated and is called secp256k1_musig_coefficient in the secp256k1-zkp implementation as of commit cad7cc8f34d17166da2dabae20188ea6e747ac69. In the MuSig paper the MuSigTweak is called a_i. The adaptor argument of secp256k1_musig_session_combine_nonces refers to t*G (where G is the base point) in Z-man's description.

And has in fact been implemented?

Yes, almost. What Z-man is describing here is the original adaptor signature scheme. It's not well suited for multi-hop locks (aka Lightning with payment points), because the creating party must know the t when creating an adaptor signature. Therefore, the implementation in libsecp256k1-zkp uses the adaptor signature variant that was introduced in the original Lightning in Scritpless Script mailing list post and in the Anonymous Multi-Hop Locks for Blockchain Scalability and Interoperability paper. If you want to know more about the multi-hop lock protocol, I suggest to have a look at the diagram in the scriptless script repo.
libsecp256k1-zkp has a unit test for a scriptless script atomic swap using that technique.

How is MusigTweak computed? Is it the per-hop tweaked payment point, which means it will be the payment point for the hop connecting to the payer?

The adaptor point t*G is the per-hop tweaked payment point, not the MuSigTweak.


text:
Bandwidth required for Bitcoin going global?
Something that I feel might be the obstacle against Bitcoin going global -- but which I've never seen anyone mention -- is this:
If Bitcoin goes global, I think it's possible that the number of transactions per second will be so high that it will become impossible to download the block chain at typical internet speeds -- it will grow faster than it can be downloaded.
What I'm wondering is: is this a real possibility? If so, how might Bitcoin deal with it?

Bitcoin is global, so I'm not sure what you mean by this.

@RoryAlsop: By "go global" I meant "when everyone is using it".

This is a possible issue.
Currently we have a block limit in size of 1Mb although many pools send out 250Kb to make their block propagate faster to avoid orphaned blocks.
This gives us a cap of 7 transactions per second, data usage of 6Mb per hour or 144Mb a day, almost negligible amount of bandwidth.
Visa on average handles 2000 per second.
So looking at 285 times the amount of transaction is using 40Gb per day in bandwidth.
Most home ADSL2 lines can handle this now.

Holy cow, 40 GB per day means you need 1 MB/s bandwidth just dedicated to Bitcoin 12 hours/day... +1 thanks for the numbers

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes


text:
Can an attacker make it impossible to reclaim disk space
As I understand it, without implementing disk-space-reclamation as laid out in Satoshi's paper the system will not scale because the blockchain contains a history of every transaction.  Bitcoin has been going a few years at below 1 tps and the blockchain is already over 6GB.  At 4000 tps it will be unmanageable.
Again, as I understand it, you can only remove a transaction from the blockchain if both its outputs have been fed into new transactions, and they are buried deep enough in the blockchain.
If I were to split a single bitcoin into 100,000,000 smaller bitcoins and save them for eternity in my "piggy bank" wallets, would that force all miners to save at least that much data for eternity?
In fact, what about the case where a large number of people - without any malice - choose not to spend small amounts of money for a long time.  Would this not also break disk space reclamation?  Has this been modelled?
Thanks!

Remember: 1 block every 10 minutes, and max block size is (today) 1 MB. The blockchain can't grow more than that. The max block size will likely be raised at some point, but I still don't think the blocksize will ever be a "dangerous" problem. Only miners will need to run a full client and S.DICE is already "stress testing" the bitcoin network, so the problem can't really be much worse (and ~6GB in 4 years is almost nothing, imo).

I don't understand!  Each block hashes the Merkle root of all (or at least most) of the transactions that have occurred since the last block.  If a new block is created once every 10 mins and there are 4000 tps that's 2.4 million transactions per block.  Assuming the transactions require (say) 100 bytes then that's a quarter of a gigabyte that must be stored somewhere, every 10 minutes.  Why do you think the problem can't get much worse?  I agree that 6GB in 4 years is almost nothing but we are at under 1 tps at the moment....

The miner decides which transaction he will include in the block. If the miner include too many transactions (so block size > MAX_BLOCK_SIZE) then the block won't be accepted as a valid block.

Defining a MAX_BLOCK_SIZE only solves the problem limiting the transaction rate.  If we want to fix the block rate at 1 block every 10 minutes, but scale to 4000 transactions per second, won't we need to increase MAX_BLOCK_SIZE to a huge value? My question is really: does the fact that all unspent transactions have to be saved for eternity introduce a weakness that will gradually make the system less effective and possibly open it up to attack?

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Private key to WIF
Based on the following link:  https://en.bitcoin.it/wiki/Wallet_import_format , a private key of 256 bits gets transformed into a WIF address that is stored in the wallet.
However, my question here is how did we convert step 6 into step 7? In step 6, the address consists of 74 hexadecimals characters (or 74*4= 296 bits). If we convert this 296 bits address using the code58, we need to divide 296 bits by 6.. ? I believe that some details are not mentioned, any ideas?

You're basically wondering how Base58 encoding works. This site gives a good overview but I will list the details here as well with a more concrete example. For this example, I'll just talk about the encoding, but the version byte (prepended) and checksum bytes (appended) do get added before this encoding is done. This prepending/appending just changes the base data before encoding. The below is how the data gets encoded.
Let's say I have this simple encoding called Base4 encoding. In my encoding:

  0->A
  1->B
  2->C
  3->D

If I have the number 134 (1000 0110 or 0x86) and I want to encode it in Base4, then what I do is repeatedly divide by 4 and use the encoding. Like so:

134 / 4 = 33 remainder 2 -> C
          /
   -------
  |
 33 / 4 =  8 remainder 1 -> B
          /
   -------
  |
  8 / 4 =  2 remainder 0 -> A
          /
   -------
  |
  2 / 4 =  0 remainder 2 -> C

So the Base4 encoding for this byte would be "CABC". Bitcoin does the same thing, but using 58 numbers instead of 4, and a different character for each. The characters chosen in the Base58 encoding are just to avoid confusion when humans transpose the key. For example, there is no I character, because there is already a 1 character, and the two could be confused really easily.
There's just one more thing that's a little tricky. If I were encoding the data 0x0086, I might want the encoding to be slightly different than the above encoding for 0x86 to show that I had an extra 0x00 byte at the beginning. To do this, all you do is add extra data at the left side of the encoding. So, in our Base4, 0x0086 is encoded as ACABC. Similarly 0x0000 0086 is encoded as AAACABC. In standard bitcoin addresses, the version byte prefix is 0x00, and 0x00 is encoded as a 1, so addresses always start with a 1.

Quick query; when you say add 0x00 what does that mean? I know 0x is shorthand for hexadecimal but when you say add 0x00 are you saying add 00 to the start of the hex value? If so why?

0x00 means a null byte.

Right, 0x00 is just shorthand for the byte: 0000 0000. Base58 encoding is just for encoding some number of bytes.

'Adding' might have made it unclear. For any hex string you are encoding: prefix || hex || checksum of first two parts. ANYTHING that is base58 encoded for copy/pasting does this, with a different prefix byte used for each thing you want to represent.
BTC addresses are prefixed with 0x00. Private keys are prefixed by 0x80. P2SH addresses are prefixed by 0x05.

StephenM347's answer is very good, but there is one little detail he got wrong. I'd post this as a comment to his answer, but I don't have enough reputation.
Stephen said:

For example, there is no O character, because there is already a 0
  (zero) character, and the two could be confused really easily.

The wiki says:

A set of 58 alphanumeric symbols consisting of easily distinguished
  uppercase and lowercase letters (0OIl are not used)

A lowercase "o" is used, but the uppercase "O" and the number "0" are both excluded from base 58.

You are right, although I don't see why it the encoding couldn't have used at least one of the two symbols 0/O, providing the other was excluded to prevent confusion. Still, I think this is not really an answer to the question. Suggesting an edit to my original answer since this is is such a small detail, as Nick Odell has done, is a better way to go. Since you are new, your edit will have to be reviewed before it is accepted. Welcome to the bitcoin stack exchange, though, hope you can apply that close attention to detail in future answers!

Ah, thanks for the tip. I didn't realise that I could suggest edits to other peoples' posts. I think the idea of avoiding both is to make it less likely that somebody with no knowledge of base 58 doesn't assume one symbol is the other when copying a WIF key down; they also avoid both the uppercase "I" and lowercase "l". Neither of them looks particularly similar to the number "1", but they could both be easily confused with each other.

Here's an example of how to create a WIF with a private key using Python. It follows the docs and I've commented the code to make it enough to follow.
import binascii, hashlib, base58

# alias method
decode_hex = binascii.unhexlify

# wallet import format key - base58 encoded format
def gen_wif_key(private_key):
    # prepended mainnet version byte to private key
    mainnet_private_key = '80' + private_key

    # perform SHA-256 hash on the mainnet_private_key
    sha256 = hashlib.sha256()
    sha256.update( decode_hex(mainnet_private_key) )
    hash = sha256.hexdigest()

    # perform SHA-256 on the previous SHA-256 hash
    sha256 = hashlib.sha256()
    sha256.update( decode_hex(hash) )
    hash = sha256.hexdigest()

    # create a checksum using the first 4 bytes of the previous SHA-256 hash
    # append the 4 checksum bytes to the mainnet_private_key
    checksum = hash[:8]
    hash = mainnet_private_key + checksum

    # convert mainnet_private_key + checksum into base58 encoded string
    return base58.b58encode( decode_hex(hash) )

simplest way
from bit import Key

# Import wif format:
privKey = Key.('L1VotKmtZRLZSnSPhLhQxfts2aqBMru2APTs4Yuc8TYJ4jNhQoGB')

# Export hex format:

privKey = Key.to_hex()

# Export int format:

privKey = Key.to_int()

# Export to bytes
privKey = Key.to_bytes()

To convert command-line given string to WIF, where the parameter could be hex number or any rational string, you can use this script to get one conversion:
#!/usr/bin/env python3
import base58
import hashlib
import sys

def b58(hex):
    return base58.b58encode_check(hex)

def sha256(hex):
    return hashlib.sha256(hex).digest()

def main():
    k = sha256(str(sys.argv[1]).encode('utf-8'))
    extend = '80' + k.hex()
    print(b58(bytes.fromhex(extend)).decode('utf-8'))

if __name__ == '__main__':
    main()

Save the above file as priv2wif.py and run with 1 parameter. If your string have spaces in it, put whole string into "".
For massive conversion you can use second script in the same folder:
#!/usr/bin/env bash
> output.txt
while IFS= read -r p; do
    ./priv2wif.py "$p" >> output.txt
    echo -n .
done < "input.txt"

Save this file with no extension. You should make input.txt file with one string per line (watch out for CR/LF, as you should use LF only //Linux//) and after running the script you will get all your WIF keys in output.txt one per line.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
How can I define the change address of a transaction using createrawtransaction?
This question is almost the opposite of How to find the change / sender address given a txid?
If I am making a transaction using createrawtransaction how can I define the change (sender) address?

In Bitcoin, change is a normal output which sends the remaining money to one of your addresses. When creating a transaction with createrawtransaction, you have to add change output manually (just like any other output), otherwise that money would go to the miners.

i came with the same question because im not sure how to define the 2nd output. the example shows the output as a single object, not an array.


text:
Is it safe to reuse a Bitcoin address?
Besides the obvious privacy implications, and (according to a bitcointalk.org forum post) the fact that once an address is used your coins that rest on it safety depend entirely on the ECDSA safety (as opposed to your coins being secure if at least two of ECDSA, SHA256 and RIPEMD are secure for any address that were never used to send BTC) - are there any other reasons why it is a bad idea to reuse the same address (for sending as well as receiving BTCs) frequently?

There are both security and privacy related issues that arise from address reuse. Based upon your question you are less concerned with the privacy implications and more concerned with the security implications in this question. I will discuss security first before briefly mentioning why the privacy implications are greater than the security implications.
Address Security
Bitcoin addresses are derived randomly by generating a private and public key pair. When an address is generated both the private and public keys are secret to everyone except the owner of the wallet. At this point your address has 100% security assuming the device that it is stored on is not compromised already. When you provide someone with your bitcoin address to send you funds they do not learn anything about the public or private keys even though the address is derived from the public key. So far so good, right?
The first issue/security risk I will discuss is a specific implementation issue in a mobile wallet library. It is worth knowing how a bitcoin transaction is structured to understand this issue but without getting too technical you may want to read this article about what happened when the same K value is used in multiple signatures. When this issue arose it was trivial to derive the private key protecting the funds in question and attackers were able to steal a reported 55+ bitcoins. As part of a bitcoin transaction the public key associated with the address is revealed to the network.  This allows the blockchain to validate that indeed that public key is associated with the address sending funds. It also validates that the signature provided could only be generated by the private key associated with the public key which was now revealed. If the user that were attacked did not reuse addresses and sent all of the funds stored out of this address to a new address after spending some of the funds, the new address would be 100% secret again. This issue has been fixed and should only represent a concern if you are using a wallet that has not had a proper cryptographic audit.
The next class of security issues I will touch upon is side channel attacks. These kind of attacks can become technical in discussion very fast so I will not go into details but essentially specific hardware platforms can be made to leak information about their current state thus allowing an attacker to determine random values the CPU will generate in the future. This again allows the k value (also known as the ephemeral key) to be leaked and private keys can be recreated. One such side channel attack know to target ECDSA is the FLUSH and RELOAD attack.
Although side channel attacks are unlikely to be performed on someone randomly without targeting it would be much easier to attack someone that is not using privacy preserving techniques. Which leads me to briefly touch on the privacy aspects of address reuse.
Privacy Concerns
The first thing to consider when deciding whether or not to reuse your bitcoin address is that privacy not only impacts yourself when using bitcoin it also impacts everyone else that you transact with. Using blockchain analysis it is trivial to determine which companies you may be doing business with, how much money you could be holding, as well as your complete ledger history of everyone that your address has transacted with.
There has been tracking attempts that also work to associate addresses with each other and "collapse identities" based upon transactions that are public for everyone to see on the blockchain. Addresses that are downstream from your known address could be used to make illegal or purchases that could catch the interest of law enforcement and this could lead them to your doorstep because of association with particular transactions.
Read more about why you should not reuse addresses including 2 real world examples of unscrupulous activity that could occur if someone knew how much money you had stored or earned over a regular schedule (such as payroll).

I think both attacks affecting security here are a bit besides the point: correct implementations aren't going to be vulnerable to either. Vulnerabilities are of course something to be wary of in any case, but it's far more complex than that. Certain types of side-channel attacks are going to be an issue regardless of address reuse (because even when not reusing addresses, keys will be derived from the same seed - and if that derivation has side-channel weaknesses, they apply regardless).

Why address reuse is discouraged:

Reduced security An unused address is protected by ECDSA AND several SHA-256 and RIPEMD-160 operations, but only ECDSA after being used because the public key must be revealed during spending. This has been shown to open up several possible attacks in the past.[1]
Reduced privacy All participants who you give the address to know it is yours obviously.  They can use this information to analyze incoming and outgoing transactions to identify other addresses you own and who you are interacting with, not to mention how much bitcoin you have.  This can be serious for businesses in competition or in situations where a payment might put someone into harms way (politically unpopular donations or as a means for extortion, etc).

[1] More info: https://en.bitcoin.it/wiki/Address_reuse

It is absolutely safe at the moment since ECDSA is considered safe. People rather don't like to reuse to preserve anonymity or make coins harder to steal.
This is because addresses in Bitcoin are not published directly in terms of the public key, but a hash of it. This way nobody can link the hash to the corresponding public key as long as the contained coins are not spend in an transaction. Then the holder of the coins needs to prove ownership by revealing the public key in order to enable others to validate the signature.

Why? Could you please elaborate more this answer? Thank you.

Yes, I'd appreciate if you'd elaborate on that.

I downvoted because the answer does not explain position in enough detail.

"as long as the contained coins are not spent in a transaction" - why?


text:
What exactly happens when a node detects a double spend?
Does the node drop both transactions? Does the node choose which one to keep? What exactly happens? Will both transactions be rejected by the network or will one of them be eventually accepted?

related: How secure is zero confirmations?

When a node hears about a new transaction, they try to accept it to their in-memory pool of transactions. If a node hears about a transaction that conflicts with one of the transactions that is already in their mem-pool, then they simply won't accept it to their mem-pool. The default client also won't forward the transaction on to any other nodes, either.

The node drops the two transactions? The node choose one to keep?

So, essentially, if a node sees a double spend (two transactions trying to spend the same output) they keep the transaction that they saw first.

Both transactions will be rejected by the network or one of them will be eventually accepted?

Assuming they pay the standard fee to get confirmed, a miner would likely include whichever transaction they saw first. So, if more miners see one transaction, it is more likely that one will get confirmed. It's possible miners will solve two blocks at the same time, with conflicting spends of a previous output. In the long run, though, only one spend of an output will stay in the main chain.


text:
What's the point for mining pools to set a higher target?
I'm reading the Mastering Bitcoin 10th chapter, and quote

Similarly, a mining pool will set a (higher and easier) pool target that will ensure that an individual pool miner can find block header hashes that are equal to or less than the pool target often, earning shares. Every now and then, one of these attempts will produce a block header hash that is equal to or less than the Bitcoin network target, making it a valid block and the whole pool wins.

I'm wondering what's the point to set a higher target value? If the pool ask the miners to search the same space wider than the Bitcoin network target, some of the miners' work are wasted for sure.
How does the mining pool split the work?

I think the quote is perhaps a little confusing. Higher target means lower difficulty (easier). Mining requires finding a block which hashes to a value lower than the target, so raising the target makes the job easier, because the search space is bigger.
With a higher target, most shares found by the pool participants will not be valid blocks on the actual bitcoin network. They are just a way of tracking the relative work each participant in the pool is doing, so that the reward can be split fairly (based on the proportion of shares each participant submitted).
However, while searching for shares, some will also be valid bitcoin blocks. These are then submitted to the network and the entire pool is rewarded accordingly. It doesn't take any extra searching to look for both at once (shares and valid blocks), because all valid blocks are also valid shares, by definition.
For more information about mining pool shares, please see: What is a share? Can I find it while mining solo, or only when pool mining?

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Recovering an old wallet created using dice rolls
Years ago in 2016 I created a wallet to pay off some hackers that hacked a friend's PC. There was some small change left, most of which I sold, but I think there's still some BTC there that might be worth a few hundred dollars.
The problem is, I have since uninstalled the app I used (mycellium wallet) and the only thing I have in the way of backup is a list of numbers which represent dice rolls I used to generate the wallet. The list is 12 sets of 6 rolls of a 6-sided die. So something like:
246523
123346
..(12 lines total, 72 numbers)
I searched for some common method to derive a wallet using 72 dice rolls and I'm not coming up with anything. BIP39 uses a 12 word phrase but there is no dice method involving 72 throws to derive it that I can find.. Anyone have an idea what method it might have been? It was back in 2016.


text:
xpub master pub key view only wallet shows different balance than seed generated wallet with same pub key? also different addresses
okay.  Here is what I've done:

generated a new electrum wallet "WEL" on 3/3/24.

In btcpay server imported a view only wallet using xpub key from WEL.   (apparently didn't manually verify addresses)

BTCpay View Only Wallet "WELBTC"   shows a balance.

Seed generated electrum wallet WEL shows zero balance.

If i use pub key from WEL to generate a view only wallet in sparrow or electrum.  Shows balance.  I have verified the xpub is the same in all scenarios.

If I import WEL seed into sparrow or electrum as a hot wallet. Shows no balance.
If I import into sparrow via wallet.dat file.  Shows no balance.

WEL and WELBTC show different addresses and different address formats. (WEL shows 1xlk0u2343.  simple(older style addresses)

WELBTC(view only) shows newer bc1 style addresses.

The seed and xpub are from the same wallet in all scenarios.   Where is the btc and how do I spend it?!
EDIT:  resolved it myself.   Just in case anyone else ever has a similar issue,
I used the "getmasterprivate() command int he electrum console.  and created a new wallet/imported this master priv key into sparrow.   the masterpriv key showed all balances across different address formats.

Hi Dave, could you post the part that you added in the edit as an answer instead? We encourage self-answers when people figure out their own issue as they may help others


text:
How to set up multiple client under the same address?
I want to use my all my computer to run Bitcoins, but is it possible to have it the same address so it generate under one wallet?
Thanks!

What do you mean by "run Bitcoins"? Do you mean mine them? If so, just run one client and run as many miners as you want using that same client.

How to do that?

You can dump the private key from one and import it into the others


text:
Can you mine more bitcoins on amazon aws than it would cost to operate the servers?
Read title.
Creating a soft of self sustainability if you will. It might not be possible?

Short answer: not by a long shot.

Also related - http://bitcoin.stackexchange.com/questions/1063/could-the-ec2-infrastructure-be-used-to-efficiently-launch-a-51-attack

Short nitpick: obviously not. If it did, everyone would do that, and the prices and difficulty would auto-adjust accordingly.

Surely the compute costs would rule it out anyhow?

AWS is rental of server instances.  Servers without GPUs. Bitcoin is not cost effective when mining using CPUs, so nobody has done that analysis for nearly two years because its an obvious money loser and becomes a worse option with each passing day of rising difficulty.
Now EC2 (compute cluster) does use GPUs but NVidia GPUs which don't perform at a fraction of the level of AMD GPUs for the specific purpose of Bitcoin mining. Although it was not analyzed recently, a calculation from a while ago provides numbers in the right ballpark, if not better than they would be today.  In that study costs you more than twenty dollars of EC2 charges to earn one dollar of bitcoins.
Once ASICs ship that difference will increase possibly by an order of magnitude.

http://aws.amazon.com/about-aws/whats-new/2010/11/15/announcing-cluster-gpu-instances-for-amazon-ec2/

http://blog.brycekerley.net/post/5338746136/bitcoin-mining-on-amazon-ec2
Here its explained at best, that it is NOT profitable even on the GPU servers ;)

That post is pretty old though. Exchange rates were different then.


text:
Bitcoin - Green mining
I would like to know whether any work known to bitcoin community, related to 'green mining'. As power consumption is main cost factor in mining, alternate energy sources like, solar / wind powered rigs could also be possible. Thanks.

Was. Power was the main cost factor in GPU mining.  It no longer is with today's FGPA mining hardware, and is even less of a factor with the ASIC hardware so many are patiently waiting on.

This question could be viable with some edits. As it stands, it's soliciting a laundry list of sources, but if it were rephrased properly it could solicit a single answer and I'd consider re-opening it.

One attempt, .... Diablo Mining Company didn't go so well.

http://bitcointalk.org/index.php?topic=77469

So far, the most profitable mining has been in nations whose taxpayers provide subsidized electricity.  Essentially, it is like a form of welfare for Bitcoin mining entrepreneurs.
ASICs have removed that advantage though so it never got to be that big of a deal.


text:
Is the minimum amount of money required to purchase >50% hash power equal to max worth of all existing bitcoins?
20 BFL Bitforce Mini Rigs (each, $30k) will give about 30THash/Sec hash power for $600k. That's way above 60% of hash power of then total 51THash/Sec.
10.694M total Bitcoin * $18.5 current mtgox best ask rate = $197.839M
So, BFL should ship at least 6595 such miners, or price it based on, (total worth of all Bitcoin / no of miners planned to ship).
Does this mean, these miners priced so low, or currently bitcoins comparatively valued so high? Or, these two parameters just unrelated?
Please note that these miners are yet to be shipped.

OK, the question here is worthless anyway for 2 reasons.

Getting 51% hashing power over the network doesn't give you all of the Bitcoins.  All that does is allow you to spend Bitcoins, and then later roll back the blockchain and spend them again.. If you've let the blockchain commit 6 blocks to get a "real" transaction committed, then it's going to take you a while to undo that whole chain as the rest of the network continues to run away from you with the soon to be previous real blockchain.  That's going to be expensive because if one person or group thinks they can do it, then you can bet two people or groups will think they can.. All so you can buy your pizza again with your same bitcoins, and steal some petty amount of money from whomever you spent it with the first time.. Your reward isn't all the money (unless you think you can catch up 4 years of signed blocks.. dunno maybe you could), and even if it was, it wouldn't be worth it.
If you do pull off this Bitcoin coup.. What are you really going to do? It isn't run away with 200 million USD. It's destroy the value of Bitcoin.. at least until balance is restored (in which case, you've stolen nothing). You think Mt Gox is going to let you cash out when you send them the coins from their wallet that you've taken by rewriting the blockchain? Do you think they even could? You think you'll find the market depth to cash it all out? I can tell you now.. You won't.. Even if you use all the exchanges, it won't be there.. You'd be stealing more coins than actually exist. I know I've personally destroyed 280 of them. I've heard of many others destroying more.. You'd get them back in the full rewrite of the blockchain required to steal everything, but the USD behind those doesn't exist on the exchanges.. It never did.. In theory, you could steal the sum of all the asks on all the exchanges if you could undo enough transactions to do so.. If you didn't time it right though, a lot of them are going to go away as the price plummets like it was two July's ago..

Satoshi's genious wasn't making it impossible to cheat the system (although it is very difficult), it was making it so that it was not to your advantage to do so. If you can hit 51% or greater, your best option is to just take 51% of the new coins.. Maybe occasionally you rewind and undo some large transactions you made with your own coins, but if you did that too much, then you've ruined yourself soon enough..

@Lohoris: Regardless of the facts, any answer on SE which starts with "The question is worthless" isn't good.

Right, >50% attacks probably won't get you valuable coins. But they can be pretty handy if you're a government or bank trying to destroy Bitcoin.

@MeniRosenfeld maybe it could be phrased in a more polite way, but the core is really good.

@MeniRosenfeld sure it could be useful if you would like to destroy bitcoins, but in that case it makes no sense to compare the cost to the BTC value. Comparing the cost of such an attack to the value of bitcoins makes only sense if that attack granted you possession of those bitcoins.

@MeniRosenfel, exactly my point too. When someone tries to destroy Bitcoin then they could build much better ASIC chips at the fraction of the cost of BFL minirig's retail price.

@Lohoris: I agree of course that equating the Bitcoin market cap with the total value of all mining hardware is wrong. But Jeff seemed to be implying nobody will ever have an incentive to try doing a hashrate attack, which is simply wrong.

The only reason it looks economical to perform a 51% attack is because no substantial amount of ASIC hardware has started mining on the network yet. Once the existing ASIC orders are shipped out, the total network hash power will be much higher.
Further to that, the ASIC harder suppliers would not ship such a large amount of hardware to a single buyer if they thought it would put the network at risk. Their business model depends on the ongoing success of Bitcoin.

Yes, but ASIC suppliers could not prevent pooling sold miners.

True, but it seems an unlikely idea that a secret consortium would conspire to purchase the majority of ASIC mining equipment in order to bring down the network when they are the ones with the most to gain by keeping Bitcoin popular and successful.

These two parameters are mostly unrelated. There is some proportionality which also depends on many other factors, but equilibrium can always be reached by floating the number of units to which there is demand.


text:
What mining parameters are not modifiable with ASIC miners?
When ASIC mining devices ship, what parameters of mining become hardcoded? How would these ASIC mining devices respond to any changes to mining procedure / algorithms?

Very little of transaction validation logic is done in the ASIC. All that they do is take a block header, rapidly increment the nonce, and see if the hash that pops out is anywhere close to the target. So, as long as the block header doesn't change, none of the ASICs need to change.
Nonce
The 4-byte nonce field might need to change in the near future, because you can only have 4 billion distinct hashes every second. That might seem like a lot, but with ASICs getting 100Ghash/s, it gets a bit awkward. One way around it is to make 25 different coinbase transactions, thus getting you 25 different block headers. You then give each twenty-fifth of the ASIC a different block header. Despite all this, lengthening the nonce field is probably more trouble than it's worth, given that it would require a hard fork.

Changing the timestamp is another way.

"hashes every second" Already taken into account.


text:
Could mining calculations be used to crack private key?
Could mining calculations be used to crack private key, in addition to mining for checking against few million accounts with positive balances? If that possible, at the current mining rate (30TH/s) network can check 1.8 x 10^16 hashes every 10 mins (per block). May be few (<10) of these could be a lucky guess for the corresponding private key, in a year.

No.  The math involved in cracking a private key uses a completely different set of mathematics and source data.  There is no benefit in reusing one for the other.
There is a conspiracy theory going around about the SHA hashes being a big rainbow table for "The Russians" but that crackpot theory has no basis in mathematics or applied usage.  I hope people keep talking about it so I can buy BTC while they are still cheap.  FUD (Fear, uncertainty, doubt) are good to keep BTC's price low while before the market value becomes what it should be.
To be more specific, SHA hashing (mining) is a different set of math used for the ECDSA secp256k1 encryption that in the private key.
Now that ASICs are used, it's impossible to dynamically re-wire the hardware for such a purpose.  In theory FPGA can be reprogrammed for this, and so can GPU/CPUs.
You could keep all your BTC in one address, or you could diversify your risk by keeping BTC in many different accounts (addresses) knowing full well that this will increase your transaction size and therefore your transaction fee.  The choice (to some extent) is yours


text:
Does the getwork id value do anything?
When sending a getwork request, one always includes an id value. Does this value have any meaning? Will it cause problems to have multiple miners use the same id? Furthermore, if I wanted to send some extra information to a mining pool server, would id be an okay place to do it or should I add my own extra field?

If you are talking about the Bitcoin API, getwork only requires data field, which is a place to put your solution.
However, I do believe that you are talking about the id field of a JSON RPC command. It is used to identify a response to a given request. Generally, it might not be the best place to put extra information. There are already a few extensions to the getwork protocol that you might want to use instead.

I'm a little confused about the difference between the Bitcoin API and the JSON RPC API; I'm talking about the command a miner sends to the pool to get (or submit) work. Does this mean that if two miners both use the same id field and both find valid shares around the same time, only the share resulting from the more recent getwork request will be accepted by the pool? And is there a problem with adding an extra field to send extra information (not info supported by any current extension), or will that confuse pool servers?

@ConstableJoe The difference between Bitcoin API and JSON RPC, is the same as difference between HTML and HTTP - one builds on top of the other. JSON tells you how to send your data, it's like an envelope you address. Bitcoin API is like the stuff you put in that envelope - it can be a letter, but also confetti, strings or something else. Generally, you don't want to mess with the envelope when you can mess with its insides.

@ConstableJoe The id is used to identify the message, but from what I found most people just set it to 1 and it works fine. It might be useful when you are sending many packets. Then you yourself would know what you are receiving and so forth. I guess it's mainly useful for asynchronous communication or something.
Adding extra information might confuse the pool. Generally, the pool received an array of data - if it sees a non-empty array, it assumes it's a solution and tries to read it. If it is not formatted like one, the result will most likely be an error.


text:
How much is a mining pool share worth on average?
I know that mining pool shares have no value on their own, but it should be possible to find an average value based on the pool's average payout per share. This site describes the expected payout per share as ([block reward] - [pool operator's cut]) / [difficulty].
It seems to me that a share's "value" would necessarily be related to the difficulty as set by the pool--a pool with shares that are harder to find will have its users find fewer shares, making each share "worth" more. However, the equation above clearly doesn't work with the pool's difficulty, as most pools set difficulty to 1 and a share isn't worth ~48 BTC. How can I reconcile these issues to calculate the expected payout per share of a pool without knowing how many total shares are found?
Edit:
Ah, I think I've figured it out. The difficulty in the equation can be the network difficulty, because that's what makes it more or less likely that a given successful hash (earning a share) in a pool solves the block and earns the block reward. Thus, the network difficulty indirectly limits the value of a share. Is this correct?
Edit Again:
And now I'm back to being confused. If Pool A sets a higher difficulty than Pool B, Pool A's shares are worth more than Pool B's (assuming the same number of miners at a set hash rate) because they're rarer so each share will earn more at payout. How is this taken into account in the equation?

If the global network difficulty is D and the difficulty of shares in the pool is d, then the probability that a share will lead to a valid block is d/D. The reward in this case is B, so the average reward per share is B*(d/D). If the operator's average fee is f (so for example f=0.01 means 1% fee), the average reward miners get per share submitted is (1-f) * B * (d/D).

Thanks for the answer! Can't believe I couldn't figure that out.

Does a share worth more when difficulty is lower? Say the network difficulty is fluctuating. How does a miner that mine when difficulty is lower get more?

Yes, when network difficulty is low, every share has higher probability to be a block and is thus objectively worth more. Whether and how the miner is compensated fairly depends on the specific of the reward method used. I've described the specifics for some method in AoBPMRS.

Variable difficulty mining:
If you are mining at a pool with a higher difficulty, then each share (proof-of-work) is worth more on average. Proving that you worked very hard is worth more than proving that you worked a little bit. Some pools now use variable difficulty, which means the difficulty can change over time. One share at difficulty X has the same average expected return as X shares of difficulty 1. It may be easiest to think of everything in terms of difficulty 1 shares.
Average value of a share (proof-of-work):
Basically each (difficulty 1) share's value is the block reward divided by the network difficulty. That's the average income of a block multiplied by the chance that the share creates a block (one divided by network difficulty). But keep in mind that transaction fees are part of the block reward. That's the bitcoin value of each share. If the pool uses merged mining the share would also have a value for each merged coin. That should also be included.
Example:
As I write this the new coins minted per block is about to drop from 50 to 25 BTC in just a few hours. Looking at http://blockchain.info/charts/transaction-fees the total transaction fees are roughly 25 BTC per day. With roughly 144 blocks per day, that is 0.17 BTC per block, making the total inccome for a block approximately 25.17 BTC.
With a difficulty of 3438908.96015914 that gives us an average value per share of 25.17/3438908.96015914 = 0.0000073191818369147015 BTC.
Assuming a pool that also gives you namecoins through merged mining, a share would have an additional value of approx. 50/1119016.08618347 = 0.000044682110129918345 NMC. With namecoins currently trading at 225 NMC to 1 BTC that puts the total value of a share at 0.000007517768993047672 BTC.
0.000007517768993047672 BTC per share, as opposed to
0.000007269747553550557 BTC which you get with the simplified formula (minted coins divided by difficulty). This 3.4% difference can be worth noting as many would have you believe that the simpler formula shows you the full value of a share.
Disclaimer: I run a pool that pays out transaction fees and namecoins.


text:
How would advancement in ASIC manufacturing process affect mining?
What's the expected performance improvement with the advanced ASICs? When advanced semiconductor manufacturing processes provide high hash rates by consuming low power, and older processes makes mass production cheaper, I'd like to know when approximately, newer ASICs will be able to make older ASICs obsolete.
Following is the semiconductor manufacturing process timeline, from wiki.

45 nm — 2008 32 nm — 2010 22 nm — 2012 14 nm — est. 2015 10 nm — est.
  2017

http://en.m.wikipedia.org/wiki/14_nanometer

I hope this question will help ASIC buyers, to know when should they start worry about latest ASIC announcements..

This is a really loaded question. It's going tot take a while to get the answer written out... but i have had extensive talks with people.... boils down to this: no one knows what will happen to bitcoin (sha256(sha256)) Application Specific Integrated Circuits.

@joe-white, yes, lots of uncertain parameters, and anything can happen..

I would beg to disagree - we will see a similar effect when v2, v3, v4....vn rendentions of ASIC come around.  We will see 10X gains in Hashpower and roughly a 40% drop in power consumption.  This is all pure guesswork and speculation based on other responses I've seen and following the developments of KNC, BitFury, BFL, Avalon, and AsicMiner.
It could be said for that matter that we are already seeing the development of v2 hardware with the advancement of the 28 nm class of ASIC Chips.
There will likely be a cascading effect of shifting retired hardware onto other Alt-chains as difficulty increases on the other off color alt-coins such as PPC, FRC, and TRC.
Right now using cyrptocurrency as a medium of exchange is very new...the ecosystem to spend them does not yet exist...if perhaps other services such as internet providers, mobile phone providers, insurance carriers, and other recurring cost structures will willing to adopt btc as a medium of exchange we would see the increases in usage and thus value (price)
Smaller transistors both allow more transistors to be packed on each asic chip and also require less power overall to perform the same level of hashing compared to the larger obsolete transistor size.  I have read that underclocking allows power consumption to be reduced even further - it could be that these devices see between a 30 to 65% increase in GH rates as implied by the jump between Avalon to BFL to Bitfury to KNC.


text:
Can casual people still mine for bitcoins, now that the difficulty is much higher than it was?
Can casual people still mine for bitcoins? As of October 2012, the difficulty seems very high, being over 3,000,000.
I've seen a ad for bitcoins, and watched the video. It said I could mine for them with my computer, so can I?

related: In the ASIC-age, is it worth starting mining Bitcoin at home?

Well, you can TRY mining. To see how much coins you can expect, check your computer's GPU on the Wiki page, get its hash rate, and plug that into a profitability calculator, such as mine. This can give you an idea of how many coins can you expect to mine and whether you would get any profit from that.
Unfortunately, most likely you won't be able to mine at a profit using a PC. Bitcoin's difficulty is quite high, the reward will be dropping by half soon, and with the introduction of ASIC miners, GPU mining will be outclassed. However, if you are willing to invest some money into custom hardware, you can still start your career as a full-time Bitcoin miner. But again, you ought to check if it calculates for you.
However, if you want to try your luck at a newly emerging trend of using your GPUs to "mine" for split-key vanity addresses, you can check out my Vanity Pool, or its topic on BitcoinTalk. The process is quite similar, but the profit margin can be better.

How accurate are your numbers? So with price of power at 0.22 USD per kwh, a monarch http://www.butterflylabs.com/monarch/ would break even in 9 days on average?

@Pacerier My numbers should be accurate, however the calculator assumes difficulty not rising over a given period of time, which is not the case right now. One should assume a worse case scenario of it rising by a factor of 2 or more when making long-term predictions.

Makes you wonder if that was even good advice considering that btc price skyrocketed in November of this year...if he just wanted to hold onto 10 BTC just in case and stop...he couldve made 12k

Normal people can mine but normal computers can't mine profitably.  At least not any longer.
Right now, in mid-October 2012, some people are doing OK mining on GPUs, particularly those who don't pay directly for electricity.  However, roughly sometime around the end of November the mining proceeds get cut by half instantly -- something that happens every four years.
After that point, there will not be many GPU miners who can continue to mine -- unless, again, they aren't paying for electricity.
Others have bought specialized hardware known as FPGAs (a BFL single is an FPGA).  Those use less electricity than GPUs so they will still mine at a profit.
But a gamechanger is likely coming from ASIC manufacturers. Several are accepting pre-payment on orders now, though not a single ASIC design has shipped yet.
There's no harm that occurs from using your computer (with GPU) to try to learn mining -- if you are looking for a hobby.  But to mine for profit will generally only make sense from the purchase of mining hardware.

If you know your estimated hashrate and power consumption, or can estimate it using the wiki, you can work it out for yourself:
Estimated earnings / sec = Ghps * 1e09 / 2^32 * B / D * exch.rate - elec.cost / 1e03 / 3600 * watts
Ghps = estimated device hashrate in Ghps
B = bitcoin block reward, currently 50 btc, soon to be halved to 25 btc
D = mining difficulty, currently 3072321
exchange rate = btc to your currency exchange rate
elec.cost = cost of your electricity in your currency
watts = the estimated power consumption of your computer + GPU
As long as the estimated earnings are > 0 and you don't have to outlay anything, mining won't cost you.

If you mean getting actual profit without cheap/stolen electricity you should at the minimum have a high-end AMD GPU.

Until about Nov 30th (+/- a few days), after which even high end AMD GPUs are unprofitable unless you have cheap/stolen electricity (or the exchange rate goes up big from here).

Yes, but we are talking about 'now', as this is what OP asked about, not Nov 30th. Besides there is absolutely no guarantee we will see ASICs on time.


text:
What would happen to the Bitcoin network if all miners simultaneously stopped their mining efforts?
If every single Bitcoin miner were to stop mining altogether, how would this effect the Bitcoin network?

Transactions would never acquire any confirmations and the network would be essentially useless. In principle, people could still accept transactions if there were no conflicting transactions, but anyone could perform a transaction and then undo it if they wished to do so.

Transaction fees would accumulate in this situation, eventually creating a huge bounty for mining again.

The only way this scenario could be at all realistic is if the value of a bitcoin dropped very, very low very, very quickly such that even with high transaction fees there still wouldn't be enough incentive to get people to mine enough blocks to bring the difficulty back down. For example, if the total value of all outstanding bitcoins wasn't enough to justify mining a single additional block, it's quite possible that no more blocks would be mined. (Though nobody would care, since all transactions would be effectively worthless.)


text:
What would happen if you send bitcoins to a non-existent Bitcoin address?
If one were to send bitcoins to an address that has not been created yet, what would happen? Would the coins be lost forever? Would they just sit there until the address and key pair are generated?

possible duplicate of Can a bitcoin be destroyed?

If the address hadn't been created yet, how could you send coins to it? How would you know what the address was if it hadn't been created?

There's no such thing as a "non-existent" address.
Other than valid addresses created by a client in which the private key is kept secret there are also are:

Invalid addresses (which will fail the client's sanity checks and thus cannot be used when building a transaction)
There are also valid addresses in which no key exists.  The private key is required to spend the funds.  If the private key was lost or one was never generated (such as for 1BitcoinEaterAddressDontSendf59kuE) any amounts sent to that address are lost and can never be spent.  There is no way to know if a private key exists for 1BitcoinEaterAddressDontSendf59kuE or if it was a purposely created throw-away address.
There are also valid addresses in which no key can exist.  An answer to a related question provides an example.

There is no way to know for sure that a valid address has no private key.  What is known is that a program like VanityGen would not be able to create an address that includes many readable words like the address 1BitcoinEaterAddressDontSendf59kuE contains using the type of computational capacity that exists today.  So it can be assumed beyond any realm of possibility (but not absolutely, positively 100% guaranteed) that bitcoins sent to that address are gone for good.
Related:

Can a bitcoin be destroyed?
How to generate a valid bitcoin address for destroying bitcoins?

The bitcoins would be lost.
It's also very, very, very (times a very big number) unlikely that a randomly chosen address would ever be generated, as such capability would mean that brute force attacks could be performed and Bitcoin as a payment system would no longer be secure.

Yes. By the way this is exactly the point of a paper wallet like you can get from https://www.bitaddress.org/, you generate an address and private key that don't exist anywhere in the digital world, but you do transfer funds to the address. When you need them you add the private key to a bitcoin client to claim it.
Good luck by the way with finding out the private key of an address that was created randomly.

you can, absolutely, send coins to any address, that is, any hash whatsoever.  that is the basis for this project: https://www.btproof.com
what I don't understand is, according to https://en.bitcoin.it/wiki/Address :

A Bitcoin address, or simply address, is an identifier of 27-34
  alphanumeric characters, beginning with the number 1 or 3, that
  represents a possible destination for a Bitcoin payment

which begs the question, if the hash doesn't have to adhere to the above specification, then why have the spec?

I want to note. There is about 2^256 valid private keys. But there is only 2^160 valid addresses. Hash functions are used to convert public key to address. So, it is very-very likely, that for any valid bitcoin address there is a valid private key.


text:
How can I rescan instead of reindex with Bitcoin Core 28?
I want to rescan. I’m using the latest version, Bitcoin Core QT 28, but it looks like reindexing is the only option in this version. Is that right? Or is there still a way to do a rescan instead of reindexing?

Reindexing is a node/blockchain operation. It rebuilds the block index, and re-validates every transaction in the blockchain. It can be done in Bitcoin Core (including version 28.0) using the -reindex command-line option. Depending on the specifications of your machine, this may take hours to several days.
Rescanning is a wallet operation. It goes over all blockchain transactions again, seeing if they may be relevant to your wallet. It can be done in Bitcoin Core (including version 28.0) using the rescanblockchain RPC command (in the GUI, one can use the debug console to give RPC commands). The -rescan command-line option was removed in 23.0: https://bitcoincore.org/en/releases/23.0/


text:
Coinbase Wallet holds my Btc on the Bitcoin Network requiring me to add the Bitcoin Network as a custom without providing RPC URL or Block Explorer
I have 3 Wallets in Coinbase Wallet holding my Btc on the Bitcoin Network.  To access my assets I  have to add the Bitcoin Network to Coinbase wallet as a custom network. Coinbase Wallet has not provided me with the  information to add the Bitcoin Network mainnet (the RPC URL, Chain id and Block Explorer URL) or access my assets. When I  initially opened and deposited to the Wallets I was only given a testnet Network key for viewing the assets. Coinbase Wallet has refused to provide me with the mainnet addition information since April, 2024. Where can I obtain the needed information.

When I initially opened and deposited to the Wallets I was only given a testnet Network key for viewing the assets

Frankly, to me, this looks completely abnormal and like a scam perpetrated by some criminal posing as an assistant or fake broker etc.
What you describe is unlike what I would expect of any normal experience with the real Coinbase.
There's a chance I am unduly sceptical but without further information it looks extremely fishy.


text:
Are sequential blocks more likely to be "empty" if solved by the same entity?
If not SPV mining, so-called "empty blocks" occur if there are no available transactions to include and is usually when the previous block was solved a short period of time previously.
Is there any reason for this to happen more often if the previous block was solved by the same entity?

It is actually less likely to occur by the same miner. The reason for this is the fact that the miner that found the Block will have already validated it, thus it knows which transactions from the mempool were used. If the block is mined by another person their mining software might not have validated the previously mined block yet, which causes them to be unaware of which transactions were included. Thus an empty block is more likely when it was mined by someone else.

No, succeeding blocks by the same entity should never be empty.
Empty blocks occur when another miner finds a block before they have validated the previous block. Before having validated the previous block they don't know which transactions remain unconfirmed. However, if they'd include a transaction that was already confirmed their block would be invalid. Thus, to play it safe, they restart mining on an empty block.
As the miner that created the last block knows exactly which transactions where included from the start, they have no reason to mine empty block and can immediately include transactions.


text:
How can this input address have multiple values at the same time?
For the transaction: https://blockchain.info/tx/ee1658bb4d0de80a91d2e0005218d4cfab7c302a352458bd6afb6376b47fbf81 it looks like there are multiple inputs with different values for the same address. I thought an address only has one value at any given time?

Can you be more specific? That transaction just looks like 1 address in, 2 addresses out; nothing out of the ordinary.

There are multiple rows of the same address. Normally I have only seen any given input address appear once. I realize there is only one address. That wasn't my question. The question is about different bitcoin values for the same input address

What's happening in this transaction is that the same address (1AhN6rPdrMuKBGFDKR1k9A8SCLYaNgXhty) is claiming different outputs. You can see which output it's claiming by clicking on the "Output" link available for each input.
This is a common scenario where a person has their coins spread across several addresses.

Bitcoin balances are associated with addresses, but they are packaged in "outputs". The set of all spendable balances is called the Unspent Transaction Output Set (UTXO set).
Each transaction creates a new transaction output for every recipient that it sends money to. When several payments are sent to the same address, this address will accumulate several distinct transaction outputs.
When you spend bitcoins, your transaction explicitly references which outputs created by previous transactions it spends. Outputs are used up completely when they are spent. This is why transactions need to return change to yourself for the leftover input amount.
This means that the same address could appear more than once on the input side, or if someone is being creative even on the receiving side.


text:
Is there a crowdfunding site for Bitcoin?
Does a crowdfunding site like kickstarter.com exist, which accepts bitcoins instead of dollars?

Questions seeking product or service reviews are off-topic because they tend to attract subjective, low-quality, and spam answers.  However, I think that policy should be changed and rely more heavily on site visitors to downvote low quality answers.  The current answer to this question is outdated but was decent.  I don't know of a better place to look for an answer to this question, and if the policy made asking it okay, it might have a better and constantly improving answer.

For donation-based crowdfunding:

http://www.BitcoinStarter.com
http://www.CoinFunder.com
http://www.nestorbooster.com
http://ignitiondeck.com/id/bitcoin-crowdfunding

There's also:

http://www.Propster.me
http://www.PirateMyFilm.com
http://www.Booster.io

and some day coming back:

http://www.BitcoinChipIn.com

Of course, the "equity" markets for equity-based crowdfunding:

http://www.BitFunder.com
http://www.MPEX.co
http://www.CryptoStocks.com

And a forms of microlending from the crowd include:

http://www.BTCJam.com

and others.
[Update: Thanks to others answering this question as well, I've updated this list with their input as well.]

Almost all of these sites are now defunct

Lighthouse is an excellent decentralised crowdfunding app by Mike Hearn (one of the Bitcoin Core / bitcoinj devs).

check out https://www.reddit.com/r/LighthouseProjects/ for project to fund

Another option, buy/issue shares or bonds: Cryptostocks.com

http://www.bitcoinstarter.com hasn't launched yet, but it does have a webpage where you can submit your email address to be notified when it does launch.

Hi jjwatts! When possible please include more information than just a link. In this case the fact that the site hasn't launched yet should definitely be included in the answer.

The url is dead

BTC Jam  www.btcjam.com
They do quite a bit to verify the users, including using the Web of trust set up for bitcoin-otc.

They are shutting down. Don't accept any new users.

nestorbooster is a crowdfunding site for board games. They accept Bitcoin payments.
http://www.nestorbooster.com

I built https://fundhub.org/ for crowdfunding software, no fees :)

I think it's dead now

We received a lot of requests for this, so we built a Bitcoin extension for IgnitionDeck: http://ignitiondeck.com/id/bitcoin-crowdfunding/
This way, you can use Bitcoin to crowdfund on WordPress.

The free open-source BTCPay Server allows creating crowdfunding apps.


text:
Is there a way to find the coinbase for a given block using only bitcoind commands?
ASICMiner includes hex(Mined By ASICMiner) in the coinbase.
I'd like to generate weekly statistics that include ASICMiner' solo-mining efforts, but I don't want to have to rely on blockchain.info or blockexplorer.com. Is there a way to use bitcoind commands to return the coinbase for a block of given height (or hash)?

I think this is best answered by an example. Let's find the coinbase from a block on the Bitcoin testnet.
First we'll get the hash for a block we want to look at. We'll have a look at the (as I write this) latest block:
> bitcoind getblockcount
81626
> bitcoind getblockhash 81626
0000000000834f3933b50577b854692ed246728a17d10006ced1283a3fd8074c

Now we need to find the hash of the generation transaction from that block. It's always the first one listed. In this example there is only 1 transaction.
> bitcoind getblock 0000000000834f3933b50577b854692ed246728a17d10006ced1283a3fd8074c
[...]
    "tx" : [
        "f1fdeb7ced28f697c97b6a3ed7cc1946e1fc5e062ad8c17d05c88b1767b91b2a"
    ],
[...]

And now we can grab the coinbase from the transaction. The getrawtransaction command's second parameter can be set to 1 to give us individual pieces of the transaction so we can easily find the coinbase. Alternatively we could leave that out and it would give us a single binary blob to navigate ourselves.
> bitcoind getrawtransaction f1fdeb7ced28f697c97b6a3ed7cc1946e1fc5e062ad8c17d05c88b1767b91b2a 1
[...]
"coinbase" : "03da3e012cfabe6d6d18c47c97379852a93158528bb709355a0d38d05fedf072b610bb57442aad4e710400000000000000062f503253482f",
[...]

And there's the coinbase. Now we can check whether it contains pieces of ASCII text or whatever else we want to do with it.

I though "getrawtransaction" would only work for transactions that are in the memory pool? Not for those that have been mined into blocks already...

I see what I'd been doing - I'd been testing getrawtransaction on the genesis block (since I knew that contained a message) - and of course that didn't work.Thanks DrH!

I forgot to add - this method only works for recent blocks.

I think no - it's not possible using the current bitconind.
Unless you want to use not only RPC, but also the bitcoin protocol. Then you can just download each new block from your node (using getdata command) and check it is has "Mined By ASICMiner" in the expected place.
You could also look into the blocks database directly - the blocks are stored on disk by your bitcoin node, in a pretty straight forward format.

-1 "I think" is not an answer, either you know or you do not know.

It is, when you're modest :) But, since you care about words so much: I am very sure that getrawtransaction will not work for old spent transactions. Feel free to -1 the truth one more time, but this just won't fix the world :)


text:
Umbrel Full Node with Raspberry Pi 5 external hard drive running out of space
I installed Umbrel on a Raspberry pi5 and a 1TB external drive that's slowly getting full.

How do I replace the drive with a bigger one?

Could I just plug an additional hard drive to the Raspberry?

That is a good question to ask on a Raspberry Pi forum or Q&A website. For example https://raspberrypi.stackexchange.com/ - I would aim to replace the 1TB drive with a 2TB drive and copy the entire contents across. How you do this depends on how your drive is connected and how many such drives your hardware supports (different models will differ in this respect).

If the new drive is big enough for all Bitcoin data: Maybe. Just reconfigure Bitcoin's data folder and copy contents across (not necessarily in that order!)
If you are thinking two drives together will provide for Bitcoin's needs: No. I think it probably isn't simple to split the storage of Bitcoin-core's data directories across two drives. In principle you could, for example,  make .../blocks/ a mount-point for the second drive, but I wouldn't advise this.
2.0. make a backup of any wallets and test that they can be restored successfully.
2.1. stop Bitcoind
2.2. cd {wherever Bitcoin data directory is configured}
2.3.  sudo mv blocks oldblocks
2.4.  sudo mkdir blocks and fix permissions, ownership etc
2.5.  mount the partition of the second drive at this new blocks folder
2.6.  something not entirely unlike cp -p oldblocks/* blocks/ (you should definitely test this on small test data folders first).
2.7. cross fingers and restart bitcoind
I have not done the above and just made it up off the top of my head. Caveat emptor. I much prefer just replacing the 1TB drive with a 2TB drive - much less risk.

Thanks a lot. I will just replace the drive.
Dos this mean I need to connect a monitor/keyboard to my Raspberry and log in in order to access to (Linux?) commands?
Thanks again.

I am not familiar with Umbrel but most  Raspberry pi operating systems allow you to log on  over the network using a terminal emulator such as PuTTY.


text:
How will a bitcoin ETF be any different from a bitcoin exchange?
The W.Twins bitcoin ETF/trust stock can be converted to real bitcoins. This means that we can buy $100 worth of stock and convert it to maybe 0.5 BTC depending on the current rate. And we can buy 0.5 BTC and convert it to maybe $100 worth of stock depending on the current rate.
Doesn't that make the bitcoin ETF yet another bitcoin exchange like MtGox, BitStamp, etc?
What is the difference between a bitcoin ETF and a bitcoin exchange then?
W.Twins claimed that the ETF shares will reflect the performance of a weighted average price of Bitcoins in the other markets.
Now we all know that's not going to happen. Being yet another exchange, it is subject to supply and demand, which in turn is dependent on the popularity and the ease of deposit / withdrawal of USD among other factors.
We can't say that BitStamp (or MtGox or BTC-e) rate is the weighted average of all the other exchanges can we? It simply has it's own unique rate, due to it's own unique supply and it's own unique demand. Similarly, the bitcoin ETF/trust will have it's own unique rate, due to it's own unique supply and it's own unique demand.
In fact, if we imagine that MtGox has a subsidiary called "MtGox-Trust", and each of our bitcoin in our MtGox account is a "MtGox-Trust" stock that we can sell and buy, then MtGox is effectively now a bitcoin ETF isn't it?
Can someone explain how will a bitcoin ETF be any different from a bitcoin exchange?

Normally, ETFs define a "Creation Units" (CU), for which they are exchangeable electronically with the ETF administrator.  If the size isn't be practical for a retail investor, then the value of any discrepancy is eventually captured by HFT arbitrageurs, thus forcing the prices into alignment.  This tends to be very effective in keeping the prices within transaction costs of eachother.
http://www.investopedia.com/terms/c/creationunit.asp
https://www.flexshares.com/education/what-are-etfs/how-do-etfs-work
According to Crispy's Form S-1 link, if you're able to qualify as an "Authorized Participant", then you can do the redemptions yourself.  Normal people can't do it:

Baskets may be created or redeemed only by Authorized Participants.
  Each Authorized Participant must (1) be a registered broker-dealer or
  other securities market participant such as a bank or other financial
  institution which is not required to register as a broker-dealer to
  engage in securities transactions, (2) be a direct participant in DTC,
  (3) have entered into an agreement with the Trustee and the Sponsor
  (“Authorized Participant Agreement”) and (4) have established a
  Bitcoin custody account (“Authorized Participant Custody Account”)
  with the Trustee. The Authorized Participant Agreement provides the
  procedures for the creation and redemption of Baskets and for the
  delivery of Bitcoins required for such creations or redemptions. A
  list of the current Authorized Participants can be obtained from the
  Trustee or the Sponsor. See “Creation and Redemption of Shares” for
  more details.

and the size is fairly large:

The Shares may be purchased from the Trust only in one or more blocks
  of [50,000] Shares (a block of [50,000] Shares is called a Basket).

If not, and you spot a discrepancy in price, then you can go long the cheap basket vs. going short the expensive basket, and theoretically rely on the "Authorized Participants" to eventually normalize the prices.  In practice, these exchanges are not efficient and continue to exhibit pricing anomalies, so this trade could go very much against you and stay that way for a very long time.
http://www.forbes.com/sites/beltway/2013/09/03/how-bitcoin-spreads-violate-a-fundamental-economic-law/
Why do the price of bitcoins vary wildly between exchanges?
If the W. Twins didn't distinguish between exchanges on their Creation Units , then Gresham's Law tells us that their ETF would become flooded with bitcoin from the cheaper exchanges.  I assume they're smart enough to figure this out, and define their Creation Units such that the CUs reflect the stated investment policy "to reflect the performance of a weighted average price of Bitcoins"
http://en.wikipedia.org/wiki/Gresham's_law

ok so basically you are saying that the shares we bought cannot be directly exchanged for bitcoins right?

Correct.  I've updated my answer to include the actual requirements.  The size of 50,000 shares already rules out pretty much any normal individual.  Requirements 1 & 2 pretty explicitly say you have to be a securities mega-corp to do it; and Requirements 3 & 4 say that you need to set up prior contracts to do it.

Btw, Assuming everyone can exchange the shares directly for bitcoins, will a bitcoin ETF still be able to regulate pricing?

The more who can, the faster the prices self-regulate.  http://en.wikipedia.org/wiki/Arbitrage#Price_convergence

You don't get the bitcoins themselves.  Your investment fluctuates in response to the exchange rate.  From the brothers W:

The investment objective of the Trust is for the Shares to reflect the
  *performance* of a weighted average price of Bitcoins, less the Trust’s
  expenses.

In other words, if the average exchange rate USD/BTC is $230, and you buy $230 worth of the ETF, when the average rate goes to $250, you could sell the ETF shares for around $250 ("less the Trust's expenses").  All of your transactions would have taken place on a US stock exchange, using US dollars.
You could do this yourself, by buying and selling BTC on a variety of exchanges, but your profits would be more than eaten up with the commissions for buying and selling.
The ETF, on the other hand, would presumably have the benefit of volume, and may not even have to invest all incoming funds when there are outgoing funds (from redemptions) at the same time.

Even though the transaction take place in USD, they stated that the ETF stock can itself be liquidated into bitcoins. That means, I can buy $230 worth of the ETF and sell it to the market with the highest rate (e.g. $260) for instant profit right? In fact, if they do maintain the "average rate", I could keep repeating that process since there will always be a market with a higher rate since their rate is set to be at "average".

I didn't see anywhere that people buying ETF shares on the exchange would be able to redeem them directly for BTC.  The Form S-1 filing says that "Authorized Participants" can invest and redeem in BTC, but those would be brokerage houses and the like. Ordinary investors would buy and sell shares at the market value set by the exchange and influenced by the trust's calculation of NAV.

It would certainly be possible to arbitrage between the ETF price and the "best price" exchange, whether or not you can redeem ETF shares directly to BTC. The trick will be to find significant differences after your transaction costs are taken into account. If the ETF takes off, there would be a lot of people buying or selling BTC wherever the prices stray far from the average. Further, the volume available at profitable prices is likely to be fairly low.


text:
Is the value of "satoshi" fixed or dynamic?
BitCoin Wiki (Transactions) states:

...1 BTC = 100,000,000 Satoshi...

Yet BitCoin Wiki (FAQ) states:

..."satoshi"... is smallest denomination currently possible

In the future when the protocol decides to support more decimal places, will the value of "satoshi" change to match the smallest denomination then possible?
Or will the value of "satoshi" fixed at 0.00000001 BTC?

related: What is a 'Satoshi'?

The value of a Satoshi is fixed.
The key word is "currently" (smallest currently possible).
If the divisibility is ever increased, a Satoshi will still be exactly 0.00000001 BTC, even though there exists unit representing an even smaller amount.
There would need to be new names for these new denominations that are even smaller than a Satoshi, but dSatoshi (1/10th of a Satoshi), cSatoshi (1/100th of a satoshi), and mSatoshi (1/1000th of a Satoshi), would likely suffice.

dSatoshi? Oh, please... I can't believe you really think the general public won't laugh at such a suggestion... the Bitcoin community needs a serious reality check, this SI madness must stop.

Having to express Satoshis in terms of fractional SI units is a problem I'd like to have. That said, probably restricting to milli and micro would be enough.

Lohoris is right, we won't use dsatoshi, we'll use nBTC, and then move on to pBTC etc.

Will there ever really be a need for fractional satoshi?

@Thilo: Yes - if not for actual payment, then at least for notation. Heck, even now I quote figures to finer than satoshi precision. What do you think will happen when a BTC is worth $1M? Also consider tx fees, automated microtransactions, and anything that needs high precision. We can make do with satoshis if we're pressed against a corner, but it's just too limiting.

I'm planning to write a TOR like application with traffic paid in bitcoins. To simplify the accounting code, it internally works with the price in BTC/byte, and that price of the order of pBTC. Of course the prices exposed in the UI will be something bigger, like mBTC/GB. I don't expect satoshis to be too large for actual transactions, but applications will store balances that smaller than a satoshi internally.

The system is using integers to represent amounts. 1 satoshi is the smallest unit (integer one). The satoshi is the base unit of the protocol (not the bitcoin).
It would be very hard to change this to support more decimals, but it seems also extremely unlikely that the need arises. With 21 millions bitcoins (i.e. 2,100,000,000,000,000 satoshi) in total, there is already a lot of decimal digits to go around.

will the value of "satoshi" fixed at 0.00000001 BTC?

It is more like the other way around, one bitcoin turns out to be 100,000,000 satoshi.
What could happen is that "one bitcoin" becomes too valuable, and you may want to come up with another name for a more convenient amount, say 0.001 BTC.

If Bitcoin succeeds it is almost certain the divisibility will be increased eventually. Anyway, the OP didn't ask about technical implementation, rather about names of units. And the answer is that yes, a satoshi will remain 10^-8 BTC.

So it's 2.100 Trillion Satoshi's vs 4 Trillion USD in circulation. I think at one point the base unit has to be changed. We'll see. :)


text:
Are my coins gone forever?
I bought in 2013 and wrote down one set of numbers on a piece of paper: 33 characters, starts with 1Dao, ends on CK. I can view those numbers on blockchain dot info. It shows a transfer of 2 bitcoin, but balance zero.
Am I seeing the transaction or my wallet info? However, I can’t find my wallet key. I also wrote down "MM" which I believe to be the name of the wallet?

Balance
If any blockchain explorer shows a zero balance for a Bitcoin address, it means the money sent to that address was all subsequently spent or transferred by whoever has the Bitcoin private key for that Bitcoin address.
Address
A typical early kind of Bitcoin address starts with a 1, and has a random-looking mix of about 34 numerals, uppercase and lowercase characters like this example (do not use!)
17VZNX1SN5NtKa8UQFxwQbFeFc3iqRYhen

later types of address started with "3" (same length) or "bc1" (longer)
If you enter an address into a blockchain explorer, they typically show a list of transactions involving that address.
Transaction-ID
These are usually written as 64 hexadecimal digits composed of digits 0-9 and either A-F or a-f.
If you enter a transaction ID into a blockchain explorer, they typically show the addresses used* in each of the inputs and outputs of that transaction.
Key
Public and private keys are often written as 64 hexadecimal digits composed of digits 0-9 and either A-F or a-f.
Keys are sometimes shown in Wallet Import Format (WIF). This is about 51 characters long and contains a mix of 1-9 A-Z and a-z excluding 0 O I and i.
Wallet
It isn't meaningful to ask about a wallet address because a wallet typically has many addresses and all addresses used are actually or effectively wallet addresses. For normal wallets, nothing identifies the wallet in the Bitcoin network.

* More exactly: derived from relevant locking scripts. But that's a detail.

@Tray, there's no need to post anything that might be a key. Just describe its length, the range of characters in it and whether it starts with one of "1", "3", "bc1" or something like "xpub", "xpriv".

lol just saw your comment Ill delete in a moment .. but can you see what you think ?

See descriptions at end of updated answer. Does the thing you have match any of those?

"33 characters ..starts with 1Dao" would be an address and if several different blockchain explorers agree that the balance is zero then what you have is worth nothing.

The number that starts with a 1 is likely a legacy Bitcoin address. The balance shows 0 which means those bitcoins have moved. In the blockchain viewer you should see a transaction(s) that show where the bitcoins went. If you don't control the private key(s) to the final destination of those coins, you can not recover them.


text:
Is it possible for the network to stop finding valid blocks?
The hashing problem is by design computationally hard, because SHA-256 hashes are for all intents and purposes random strings with no direct link to their inputs, and there's no (known) way to generate a block so that its hash computes to a given output (or, more exactly, satisfies the current difficult criteria). At any given difficulty level, there will only be a certain probability for miners to find a valid block.
Ok. But is there any proof that a valid block will actually exist at a given difficulty level? Is it possible that valid blocks just stop being found if difficulty increases too much? How could the network handle such a situation, if the difficulty level can only change every X blocks?

The simple answer: no.
The not to simple answer: extremely unlikely.
Miners hash an input block, in the hopes of getting a result that satisfies the difficulty requirement, i.e., has a certain number of zeroes in front. Now the possibilities for the miner to vary the input are quite large. There is the 4 byte nonce, there is the order transactions are put into the transaction (for simplicity let's just assume it allows all permutations of the merkle root, 2^256), there's the coinbase in the reward transaction (which also influences the merkle root), there's the timestamp (not that variable but let's say we can vary by two hours => 14 bit) and there's the transaction count (up to 4 byte, that are not independent from the merkle root, but let's assume they are indipendent). So in total we have something in the order of 2^256*2^32*2^32*2^14~=3.49E100 possible inputs to find a block and 2^256~=1.15E77 possible block hashes. (These are all back-of-the-envelope calculation, and probably wrong, but just to give an idea of the scale of this)
Hence we would find ~3.02E23 hash collisions for each hash, and would have to not find a single hash that matches the target. Notice that hash functions are built with the stated goal of making hash collisions really hard (researchers have used super computers for decades to find a single hash collision), and you'll see it is unlikely to ever occur in anyones lifetime.

Now there's also the extraNonce, so the number of inputs is even larger :)

Think of mining like the lottery where the difficulty rate is the amount of numbers in the pool and your mining rate is how many tickets you can buy. The difficulty rate is set with the idea that we want someone to win the lottery every 10 minutes. We add more numbers when they win too quickly and remove numbers when they win too slowly adjusted every 2016 blocks (approx two weeks).
To answer your question, no we will not run out of blocks. In the year 2140 give or take a few, we will have exhausted all the bitcoins, but miners will still make bitcoins via verifying transactions. If the bitcoin survives this long, then most mining will be done by large institutions tied to the bitcoin in some way who have an incentive for all transactions to be properly verified.


text:
Countrywide Internet isolation, inevitable fork
Many countries around the world have provisions for shutting off the Internet as well as isolating itself from the Internet (where networking within borders still flourishes), any transaction processing (mining) going on within that country will only find nodes within that country and start following its own chain.
Is this a correct assumption?
Secondly, if this is a correct assumption, how will the network deal with this once it comes back online?
I foresee alt-chains emerging due to this, and persisting with their own exchange rates, very similar to the different fiat currencies today.
So:

Are my assumptions correct?
What, if any, provisions does the bitcoin protocol have for forks of this size (which wouldn't necessarily be that large, but still have real consequences for people forced to use them)?

possible duplicate of What would happen if a portion of the Bitcoin network was separated from the rest of the network?

Your assumptions are perfectly right. Since there is no information exchange between the two partitions while the network is partitioned, and Bitcoin guarantees liveness, the global consistency suffers (see CAP Theorem). This means that each partition will have its own blockchain fork, unaware of each other. The forks are incompatible not just because the chain is defined to be a single path from a single header block to the genesis block, but also because transactions in the partitions will contradict each other (not least the mining generation transaction in the block).
Should the partition be prolonged the forks may even start to diverge in difficulty, as they will only see the computational power in their own network and adjust accordingly.
As for the merge, this is still being discussed and we do not have a good contingency plan. Letting the system merge the forks by itself, i.e., dropping the fork with the least work in it, would roll back the entire transaction history in that partition. A manual intervention by making the fork persistent (the alt-coin scenario you mentioned) is also not desirable, as it results in an immediate doubling of the funds in circulation, Furthermore it is likely that one of the forked alt-coins is going to whither and eventually be abandoned anyway. For now the best we can do is attempt to avoid prolonged chain forks, but the risks you pointed out are real and worth discussing before it's too late.

Possible solutions, 1) credit based transactions in the event of isolation, such as like Ripple or maybe something more traditional that is simply backed by the main chain. Completely ignoring their local miner's alt-chain. 2) Google's balloon based mesh network that will always be circling the globe within the stratosphere if they do it http://www.google.com/loon/ , this should have better latency than satellite

Ignoring the local chain and using the rest-of-world chain would be a solution only if the partition is not complete. I am assuming that there is no way that users in a partition can exchange any kind of information with the outside world. Google Loon is simply an example of circumventing the partition problem. This is clearly not the intended solution of the OP. In non complete partitions even having some guy manually synchronizing the chains by smuggling a USB stick would be enough to establish some sort of bridge between partitions, but that's not the scenario IMHO.

The answer is simple: if a country blocks off external internet access, its inhabitants effectively cannot use Bitcoin while the country is blocked.
Sure, the protocol will continue with a fork ... but this fork has no hopes of ever "reconnecting" with the main blockchain, so any blocks generated / signed in the fork are useless. The country will have effectively prohibited its denizens from using Bitcoin.
They can indeed use a specialized fork designed for this country, or even the naturally-occurring forked copy, but the value of this fork will not be tied to the value of Bitcoin.
This scenario is not a real problem for Bitcoin, rather it's a problem for citizens of countries that are at risk of being disconnected from the internet. If you believe that your country will never execute such a separation, then you're safe.

okay, alt-chains are an inevitable outcome of this experiment then, with their own exchange rate.

Your assumptions are correct.
If we presume the mining work done in the isolated country is 5% of the global mining power then the chain in the isolated country will fall seriously behind, creating initially a new block only every 200 minutes on average until difficulty adjustment and the work done, nonetheless, will be on a fork which is sure to be abandoned anyway (due to lower work & lower tip height) once the partitioning issue is resolved, or, the first time someone sends over a USB with the main chain on it. That would result in a significant reorganisation in the isolated partition, but, it is curently the best right answer for this to happen.


text:
Bitcoin price speculation resources
Where could I discuss Bitcoin price speculation, and calculating fair spot and future price.
In general for stackexchange sites, the factors for here and now would be "too localized" I think.
So I will try to broaden it. Bitcoin price - being a deflationary currency with a known max number of coins that haven't been mined or minted yet - seems to be functioning like futures converging to a spot price.
The variable factors being perceived difficulty in mining versus advances in hardware to allow mining, if you look at the difficulty charts and their correlation to price, so far.
I think with just these two factors it will be possible to calculate theoretical prices, independent of the buy/sell bidder's market.
Does anyone have any resources on this, or perhaps a better place to discuss this

I'm not sure that an question which requires a list of sites is best for this format. There's not really a definitive answer.

@ColinDean there are plenty of answers across stack exchange sites that do this. Some are even protected by Community

The Speculation board on the BitcoinTalk forum is nonstop speculation.  That would probably be the best place to share your theories and analysis and to collaborate. Enjoy!.
There is a fair amount of discussion that falls under the category of speculation that also occurs on the #bitcoin-otc IRC channel.
And /r/bitcoin on Reddit seems to get its share of "OMG $30 Soon!" posts.


text:
Is it possible to mine with both (2) GPUs in headless mode?
I've got a Mac Pro with two different GPUs in it—one is a new 5850 and the other is some old (stock) Radeon.
I'm wondering if it is possible to mine with both cards simultaneously if the OS is configured to be headless (i.e., neither card is used to display a GUI)?

I have tried the bitminter client for mining and it seems that both of my gpus are used.
You can try downloading it from here


text:
Not generating any blocks on testnet
I am running bitcoind, and I have cgminer solo-mining on it. I am mining on Testnet3. My hash rate (this is an OLD computer) is ~800Khash/s, so according to one online calculator I should be generating a block every 1.5hrs at difficulty 1. The difficulty has been one for quite some time now, and I still haven't gotten any blocks, though I have been mining for much more than 1.5hrs. More like 7 or 8 total I think.
What is wrong?

I don't think the difficulty is really 1; see my question here.

As far as I know, ./bitcoind getdifficulty is the actual difficulty. Also, ./bitcoind getmininginforeports the same difficulty.

I don't think that's true.  If you browse on http://blockexplorer.com/testnet, you'll see that all the difficulty 1 blocks are just over 20 minutes apart.  If the real difficulty were 1, we should see blocks being mined much more often.  The most recent block submitted less than 20 minutes after its predecessor is 153337 which has a difficulty of 11512.  So I think the "real" difficulty on testnet is 11512, unless it has adjusted very recently.

Oh...are you saying that within seconds of the diff being set to 1, a block is found? And I should have to mine for 1.5 hours avg AFTER the diff reset to get a block. Correct?

Exactly.  I've elaborated in an answer.

The difficulty is not really 1.
testnet has a "20-minute rule": if no block is successfully mined within 20 minutes, the difficulty drops to 1 until a block is mined.  Then it reverts to its previous value.  However, it appears that getdifficulty returns 1 whenever the most recent block was difficulty 1, even if it was accepted under the 20-minute rule; this doesn't necessarily match the "real" difficulty.
I've asked a new question about how to find the real difficulty.  But by browsing blocks on http://blockexplorer.com/testnet, the most recent block which was less than 20 minutes newer than its predecessor is 153337, which has a difficulty of 11512.  So most likely the real difficulty right now is 11512, unless it has adjusted very recently.
Thus there are two possible ways for you to mine a block:

Find a block at difficulty 11512.  If your computation was right, this will happen on average once every 2 years with your current machine.
Wait until it has been 20 minutes since the last block, and find a block at difficulty 1 before anyone else does.  Looking at recent timestamps, it appears that difficulty 1 blocks are typically submitted about 20 minutes and 4 seconds after the previous block.  Thus, you have about a 4 second window to find a difficulty 1 block (probably even less due to propagation delays).  Based on your computation, your probability of successfully doing this on any given block is at most about 0.0007, suggesting that you would succeed roughly once every 3 weeks on average (this is probably very optimistic as noted).  Even if you do mine a block within this time, another miner may find a block at roughly the same time; if the next miner to find a block decides to accept his instead of yours, yours will be orphaned and excluded from the chain.

So it is not surprising that you have not successfully generated a block.

I think I'll switch to WorldCoins... They shouldn't be easier to mine than "value-less" testnet bitcoins, but I think they are...

First of all, this might not be impossible. The time to mine a block can vary greatly depending on your luck.
But 7-8 hrs is quite a long time. You should make sure your cgminer is correctly connected to your bitcoind instance. Also, I think bitcoind should be fully synchronized and being up-to-date for mainnet does not mean testnet is up-to-date as well.

If the expected time to mine a block was 1.5 hours, the probability of not mining one in 8 hours would be e^(-8/1.5) = 0.0048.  That would be pretty unlucky.

That's what I'm wondering (if cgminer is set up correctly). I am using version 2.7 or something, because later versions don't support CPU mining. Should I use a different miner?

Also, bitcoind is running ONLY in testnet. It IS up-to-date.