a common way of identifying people in the internet is to have them sign their messages. But you need to trust that their key actually belongs to who they say they are. People verify each others identities in person, then sign their public keys. Now when they send messages back and forth, they can trust that the real sender actually sent the message (since the sender's public key has been signed by the receivers private key).

Now, you can see that someone might think you are running a scam if you are asking people to sign a random string of characters with a private key. You could basically build up a lot of cryptographic trust, fraudulently, if your random string of characters was actually your public key. You now will end up with a key trusted by many users (and implicitly trusted by many others) which can be used deceive people as to your real identity.

I have an idea to possibly improve bets of bitcoin - it's not something that needs to change with the platform, just the way submitters control their own submissions.

Problem:
Some propositions end up with very small or zero bets on either side. For example, nearly every sports bet the is expiring in the next week have < 0.5 BTC (some have only 0.1 BTC total bet). That, effectively, kills any incentive for someone to place a bet in a contest that is expected to be close. It also kills the return for the submitter and the return for the website.

Solution:
The submitter should place funds on the proposition in proportion to what they think the odds are. Similar to what traditional sports books do, you are seeding the odds to encourage betting. No one will bet on a prop with < 0.1 BTC total, so the submitter will never win. But if the submitter put 5 BTC on each side (thinking that there is an even chance of an event occuring), then many others will feel fine placing 0.1 BTC bets at decent odds. The submitter accepts a bit more risk but allows the market to actually work.


How the platform can incorporate this:
Right now, you don't need to do anything to implement this: "smart" submitters will realize it is in their best interest to create a compelling proposition to earn themselves more BTC. However, the platform can do something like the following during submission:

Do you want to make the initial market to encourage others to bet?
yes/no

How much are you willing to seed the market with?
X BTC

What do you feel the odds of your proposition becoming "true" is?
Y percent

the system then places Y percent of X BTC on yes and the rest on no.

Perhaps this initial seed can be exempt of site fees as well.


This problem can also be fixed by allowing the issue of "floating" shares, but then you get into the whole problem of being registered as an exchange, etc.

mathamagician time - number of blocks per time frame follows a Poisson distribution where variance is equal to the expected number of blocks. So 48 blocks in 8 hours means that you can expect +/- 7 blocks pretty frequently. So +/- 15% is no big deal and extremely common. At 20 TH/s, it is extremely common to see it fluctuate from 17 to 23 TH/s (6 TH/s swing) and common enough to see it fluctuate +/- 30% (from 14 to 26 TH/s).


Note: if total network hashing power decreases rapidly and difficulty remains the same, you'd see an even larger relative variance since you'll have even fewer blocks per time period.

Cartoon picture:

The miner inserts a 0 value transaction into the block. That 0 value transaction contains the hash of the namecoin block (or whatever alt system you're merge mining). Now find the hash of the bitcoin block normally.

If bitcoin difficulty > namecoin difficulty, one of 3 things can happen:

Case 1:
the block hash is < required bitcoin and namecoin difficulty
Result:
nothing happens, increment the bitcoin nonce and find the next hash

Case 2:
the block hash is < required bitcoin difficulty but > required namecoin difficulty
Result:
namecoin network accepts the block (since it contains the hash of the namecoin block and is the required difficulty, so you know that it is valid), but you still need to find a bitcoin block
The accepted block is actually both the namecoin block and the bitcoin block header that verifies that enough work was done to accept the namecoin block.

Case 3:
block hash is > both required bitcoin and namecoind difficulty
Result:
both networks accept the block (why you see a correlation between a namecoin and bitcoin block being found around the same time)


the namecoin transaction hash is bumped whenever you change the namecoin block (new transactions or new block found)

This

When merge mining, every bitcoin block will find a namecoin block. But not every valid namecoin block will be a bitcoin block (when merge mining and as long as bitcoin difficulty > namecoin diff)

This is 100% incorrect. It is a mathematical truth that you will receive more BTC mining p2pool with its internal 10% rejects than you would a pool with a 2% fee if you have an average p2pool node. This is because the 10% "rejects" p2pool reports are internal share rejects in the p2pool network that has nothing to do with BTC production.

p2pool has it's own blockchain independent of BTC's blockchain. p2pool's blockchain finds a block every 10 seconds, and therefore, because of network latency, explains a ~10% chance of collision/orphans in p2pool's blockchain. That does not mean that 10% of p2pool's BTC blocks being rejected.

As long as you have a health node, you will see ~10% rejection rate of internal p2pool shares, but the overall orphan rate of p2pool is always identical to the BTC network orphan rate (~1%).

Example:
Two miners hash in a fee pool and in p2pool. Miner A hashes at 100 GH/s, Miner B hashes at 200 GH/s. Both pools find a block at the exact same rate. block reward is 25 BTC and there are .3 BTC of fees. Ignoring the BTC-wide orphan rate of ~1% but considering the p2pool internal share orphan rate of 10%


Fee Pool:
total reward: 25.3 BTC-0.3BTC-.5BTC=24.5
Miner A= 100GH/s divided by (total hash speed)*reward = 8.2 BTC
Miner B = 16.3 BTC

p2pool
total reward: 25.3 BTC
Miner A = 100 GH/s*10% divided by (total hash speed * 10%) = 8.4 BTC
Miner B = 16.9 BTC


in reality, all payouts are also smaller (on average) by 1% to include the affect of the internal BTC orphan rate which is impossible to get around.

one can use it as an offline wallet to stash their own coins if paranoid. It's only useful if you trust the person that printed them (who knows the private key since they printed it on the certificate to begin with).  They could be interesting gifts.

Got it: so the allowable namecoin addresses start with:
N1, N2, N3, N4, N5, N6, N7, N8, N9, NA, NB, NC, ND, NE, NF, NG, NH, NJ, NK, Mv, Mw, Mx, My, Mz

Maybe VanityPool can have some logic in there to prevent someone from requesting an invalid address.

Maybe the person requesting NPhaux would be willing to get N1Phaux.
./vanitygen -N N1Phaux
Difficulty: 15318045009

multiple ways:
http://printcoins.com/redeem

Update from the vanitygen posts:


Perhaps the NPhaux currently listed as available work on vanitypool website is not a valid namecoin address?

sorry ThePiachu - i quoted the wrong text so my comment made no sense! I'm submitting an issue to samr7, just wanted to tell sangaman that it is a bug in vanitygen, not in vanitypool.

Something might be wrong in vanitygen, the following combinations don't work:
Na, Nb, Nc, Nd, Ne, Nf, Ng, Nh, Ni, Nj, Nk, Nm, Nn, No, Np, Nq, Nr, Ns, Nt, Nu, Nv, Nw, Nx, Ny, Nz, NL, NM, NN, NP, NQ, NR, NS, NT, NU, NV, NW, NX, NY, NZ

but the rest do - this is probably a bug in vanitygen, i'll report it

If a full node is behind a firewall (that you have no control over) and thus cannot accept incoming connections, is it still useful to the network? Or is it just taking up incoming ports on other nodes that would be better if left available for other clients?

You can download:
https://github.com/bitcoin/bitcoin/archive/v0.6.3.zip

(or clone the whole git tree and checkout that tag) and compile it yourself to downgrade, or simply find a compiled binary from that version.

If you use bitcoind or bitcoin-qt version greater than 7 you can use the "-loadblock=<file>" command line option to load a block you downloaded from somewhere like
http://eu2.bitcoincharts.com/blockchain/

there are some instructions there on the site too

I feel like I have to respond before something thinks what he wrote is true. The 30,000 rig will take much more than 50 days to payoff unless you are the only person in the world with the equipment. The difficulty changes every 2016 blocks, so within a few days of the first batch being received difficulty will rise by a factor of 4 (the maximum it can change, see the wiki article on "target") and will continue until it reaches steady state. your 50 days has now become 200 days a few days after receiving your rig, and will probably settle at somewhere around a year or more in the end.

Conversely, will there be a sharp rise in Bitcoin when the reward gets halved? If temporarily doubling the output for one week will cause a crash, imagine the rally that permanently halving the reward will cause! EDIT: *sarcasm*

what was wrong with the math? what's your economic model backing the drop? Look at the market depth:
http://bitcoincharts.com/markets/mtgoxUSD.html

If 10k bitcoins were sold all at once simultaneously with no market rebound would drop the price to $11.60.

I think ASICS won't change the price a lot and presented pretty solid data backing it up, where's your data?

good point. back of envelope calculations:

10million bitcoins exist, in 2k blocks we should add another 10k BTC. so if we mine at double the normal speed, then we'd get an extra 10k BTC than we'd normally get. Assuming market cap stays constant we'd see a proportional drop in value. 10k/10m = 0.1% drop in value. If we mine at 1000% faster rate, we'd see a ~1% drop in value.

just got an RPI to do this - has anyone tried running bitcoind -daemon along with p2pool yet (can it handle it without lag so it can be a headless host?)

Have you tried compiling your own bitcoind or use Raspbian's binary?

We're pre-ordering 256-bit SHA hashing machines. Physical & real products - who said anything about bitcoins?