The code to watch blocks for messages to post on mathgate.info has been running almost a week without crashing, so I feel confident enough to make a separate post about it:

https://bitcointalk.org/index.php?topic=1153512.0

As of the last week or so people can use CLAMspeech to put messages on my website, https://mathgate.info. I'm scanning blocks as they come in to look for transactions sending clams to xMGxkY1RLX69eDrEJCPTEhhSxChraZYjrV. The CLAMspeech part of those transactions are displayed on the pages of the website.

There are 8 message slots and the order is determined by "points". The number of points initially equal the amount of clams sent to my address. The points decay at a rate of exponentially with a half life of 60 days. about 1 point per month. Currently the message in the lowest position has negative points, so that it could be replaced by anyone who sends any amount of clams to my address.

More details are here: https://mathgate.info/clamspeech.php

For people who don't know about clams, the main thread is here. Clams were distributed to bitcoin, litecoin and dogecoin addresses with nondust amounts in May 2014. If you have one of these addresses and haven't yet "dug" your clams, the clams at your address are currently worth about $16.50.

Edit (Sep 10 2015): There's low enough demand for this that most of the ad slots were reaching negative points. I decided to change the way points decay from linear to exponential so that negative points will be impossible. The post above has been edited to reflect this change.

Thanks for the feedback and getting the top spot! I modified the css so that links still have a grey background after being visited. I agree it was potentially confusing before.

People can now use CLAMspeech to put messages on my website, https://mathgate.info. I'm scanning blocks as they come in to look for transactions sending clams to xMGxkY1RLX69eDrEJCPTEhhSxChraZYjrV. The CLAMspeech part of those transactions are displayed on the pages of the website. More details are here: https://mathgate.info/clamspeech.php

I'd consider it experimental at the moment. When I feel more confident in its stability, I'll make a different thread about it. In the meantime, comments are appreciated. Well, if your comment is that my website looks like it's from 1999, then I've already been told that.   I'm more interested in comments about this potential use of CLAMspeech. Even better would be if some of you would try to use it! I initialized the 8 message slots yesterday using a small amount of clams.

It's clear that 2 blockchains coexisting technically can happen. Whether or not it will happen is yet to be determined. Reading these 1MB vs. 20MB threads for the past several months, I think it's quite possible that it could happen. For it not to happen will require one side or the other to accept that they lost this battle, and I see a lot of indications that neither side will be willing to accept they lost.

Even if it's 90% vs. 10%, 10% is enough to sustain a fork as long as it can make it through the first difficulty adjustment.

Ultimately this shouldn't be so scary though. Real consensus requires the freedom to divorce, and maybe the max block size limit is turning out to expose irreconcilable differences.

One interesting side effect of such a divorce is that it will (once again) demonstrate the difference between those who know their private keys and those who don't.

Zweites Erinnerung: 7.6. wieder um 17h im Cafe "Im Viertel" (Blumenstr. 17)

In Mai haben wir ueber Tails gesprochen. https://tails.boum.org/ Ich werde Tails DVDs Sonntag bringen wenn jemand moechte es probieren.

---

Second reminder: 7th of June, 5pm, at the Cafe "Im Viertel" (Blumenstraße. 17)

Last time we talked about the Tails OS (an operating system that routes network traffic through Tor and now includes an Electrum client for Bitcoin). I will bring some Tails DVDs in case someone wants to try it out.

---

Je ne parle pas français. 

Hi. I'm assuming 1P7gsbyDeKTgwrpEC5TduNRGbZV5abuv5D is your address. (To be precise, I assume you have the private key for the address.)

Here's how you can (probably) speed up getting this nonstandard transaction confirmed and making a payment to 1EG... of 0.054... btc.
It's a little technical and will require you to use the Satoshi client's debug console.

1. Create a raw transaction spending the change output from your unconfirmed transaction to the address you want plus the rest of your btc in change back to yourself. (DO NOT FORGET THE CHANGE OUTPUT OR YOU WILL LOSE YOUR BTC.) You should also include an unusually large fee to encourage a miner to take confirm both it and the previous transaction. Here's a partial version with roughly 1.7 mbits as a fee. (It's "partial" because I can't read the full 1EG... address.)

createrawtransaction '[{"txid":"b96f736e798fa221b316ee73ef5a2401a12fdf2a7cd40068fd3f6633df1c9acd","vout":1}]' '{"1EG...":0.05446166,"1P7gsbyDeKTgwrpEC5TduNRGbZV5abuv5D":2.446}'

2. Sign the transaction with the private key for 1P7...

signrawtransaction <OutputFromStep1> [] '["yourprivatekey"]'

3. Send the raw transaction to the network.

sendrawtransaction <OutputFromStep2>

I hope this helps. There may be other tools for doing this than the Satoshi client. I'm only telling you the way I'm familiar with. If you have any questions I should be online for another hour or so.

I've done this kind of thing before...but...

Disclaimer: This post is for informational purposes only. I am not responsible if anything goes wrong.

All bitcoins you have on the block chain before the fork, you will have on both forks at the time of the fork. In essence, you will double your bitcoins (sort of). The best way to prevent this is to not have any bitcoins at the time of the fork. One easy way not to have any bitcoins at the time of the fork is to leave "your" bitcoins on an exchange so that the exchange has the bitcoins. That's how most people in the bitcoin space who don't want to have any bitcoins make sure they don't have any bitcoins.

I need the private key for an address in my wallet. I unlocked the wallet, used dumpprivkey and it gave me something of the form

Kzb...

My understanding is that this is the WIF for a "compressed" private key and is base58 for

x80 (prefix byte) [32 bytes (actual private key)] x01 [4 bytes (checksum)]

However, when I extract those 32 bytes as a big-endian 256-bit number and compute the public key and address from it, I do not get the address I started with.

Am I misunderstanding the format of the private key? If not, maybe I'll generate a fresh empty wallet and post full details with an unused address and the result of dumpprivkey.

I'm using bitcoin-qt 0.9.3 on linux (Tails).
---------------------
Edit: Never mind. I get the right public key. I was computing an "uncompressed address" from it though. I need to compute a "compressed address."

Just to report:

send-email.org had blocked the IP address of the Tor exit node. The other two worked.

His bitmessage client is definitely running, but at this point it seems like overkill to try to debug what's going wrong. He decided to try to use Tor and one of the anonymous email sending services TheButterZone linked to and send the 1mbit to TheButterZone (using the BTC address on your profile page).

This was partly an experiment to see if such a bitmessage/carrier pigeon/email protocol is realistic. I guess it isn't.

Then there must be a bitmessage problem because I know he has the client running. I'll pass this information on.

I haven't heard from him today (but I just woke up). As far as I know it's still an open offer. I will post something when I hear otherwise. The easiest way to find out for sure is to bitmessage him.

Sorry if my post was unclear.

First: I can confirm 1 mbit is 0.001 btc, or 100,000 satoshis.

Second: Thanks to those of you who've offered here and via PM, but the guy is hoping the message can go

him -- (bitmessage) --> you -- (email) --> recipient

bitcointalk.org is (helpfully) explicit about PMs not being private. The bitmessage link is intended to be an important part of the process.

I guess you're right, but I think it's worth 1 mbit to him to let someone else figure this out.

Now I guess the question is whether it's worth 1 mbit to me to figure it out and then bitmessage him pretending to be someone he doesn't know. Hmm. Probably not.

This request will probably sound bizarre, but it's nothing shady.

I know someone who needs to send someone an email, but without the usual metadata being associated with him. I offered to send it for him, but he would prefer that it's sent by someone he doesn't know. You will be able to read the email and it will be clear that it is benign.

He uses bitmessage and can be contacted at BM-2DBQzrbTASC82EaN4AzhuEJWL6z43pPbs8
He will pay 1 mbit to someone if they will simply email the message for him to the address he gives. It is meant to be one-way and the email will start with:


I know 1mbit is small, but it's close to the price of a stamp, so it seems reasonable. Feel free to negotiate the price over bitmessage.

Kudos. Excellent response.

I agree, but I try to be more positive about it. When an organization like Wikipedia asks for identifying information, that's their way of letting me know that the organization is run by evil people. That's useful information to have when deciding where to make donations.

I've been using the Tails OS for over a year now and am happy with them. They've been asking for bitcoin donations recently to support the project. I sent them some mbits.

I think Tails is a project far more worthy of bitcoins than, say, Wikipedia.

https://tails.boum.org/contribute/how/donate/index.en.html

Before playing with your bitcoins outside, always put on a clean pair of socks.

I don't know why they deleted my github account. I haven't asked. I consider it a lesson learned and will move on. I always use Tor (via Tails), and maybe my account got flagged because of that. Some websites are not Tor-friendly.

As you pointed out, OP_RETURN is the standard way to embed timestamped hashes into the blockchain now. I guess to make a promechard using OP_RETURN one could publish txs of the form

input1 (tx corresponding to previous metablock)
...
->
output1 (OP_RETURN with the hash of this metablock)
output2 (output indicating who can publish the next metablock)
...

Using my implementation, the OP_RETURN output isn't needed because the hash of the metablock and the public key of who can publish the next metablock are combined. (That is, output1 and output2 can be combined.) This makes the tx slightly smaller than the OP_RETURN version, but it's a savings of only a few bytes. Using OP_RETURN is more flexible.

I hope at least the code is helpful for someone who wants to learn about secp256k1 and prefers to read lisp.