We just had another hiccup with python. For some reason it quit responding to some requests but not others. I double checked to make sure this wasn't a SYN flood, and it doesn't appear to be any sort of attack. I do find it curious how the server likes to do this right before I go to bed though. Go figure.
Is this based on poold.py? That does a thread per connection. If you get too many connections at once, or too many connections total, you can hit your OS's per-process or per-thread thread limits. During the mining pool test I ran, that happened at least once. |
|
|
|
|
0.01 minimum fee will be changed over time.
|
|
|
|
This patch adds the "sendscratchoff" RPC call, which creates transactions that are an electronic attempt at scratch-off cards: http://yyz.us/bitcoin/patch.bitcoin-scratch-card or git://github.com/jgarzik/bitcoin.git#scratch-card To create a scratch-off card for 0.82 BTC from the 'master' account via JSON-RPC: $ bitcoind sendscratchoff master 0.82 '{ "bits" : 64, "salt" : "myawesome.com" }' 1 "my awesome scratch-off"
{
"txid" : "4a16969aa4764dd7507fc1de7f0baa4850a246de90c45e59a3207f9a26b5036f",
"password" : "719d17195638f937"
}
And presumably you will have a fancy print-out or display saying Redeem this card for 0.82 bitcoins!
card# 4a16 969a
presented by: myawesome.com
password 719d 1719 5638 f937Some time later, the holder of this card may redeem their 0.82 BTC with another new RPC 'scratchoff': $ bitcoind scratchoff 4a16969a 719d17195638f937 "myawesome.com"
994dd0219f6dea648a6d5f8d33850114a2a0787e136a36e8b24ccafcd6ff0e59
^^^ transaction that "claims" the scratch-off card
How it works -------------------------------------------------------------------- After re-reading this old thread, a discussion on IRC led ArtForz to note that ByteCoin suggested a way to create bitcoin scratch-off cards within a standard transaction. Unless I've totally bollock's up the works, which is entirely possible, here's how it works: - Our EC private keys are 256 bits
- Generate 64-1024 random bits (def. 64) -- this is your scratch-off password
- Perform a great many rounds of hashing the password, and a user-supplied salt string (default "bitcoin"), to produce 256 bits of data
- Create EC keypair with the resultant 256 bits of post-hash data
- Create transaction, sending n.nn BTC to the hash of the EC public key
- Return 32 bits of transaction hash ("id") and scratch-off password ("password") via JSON-RPC
To redeem a scratch-off, - Retrieve transaction by looking up N bits of the transaction hash ("txid")
- Build raw 256-bit private key, through many rounds of hashing the password ("password") and salt ("salt")
- Create EC keypair from raw private key
- Verify transaction output's pubkey hash matches EC pubkey hash
- Add EC keypair and scratch-off TX to local wallet
- Create transaction that sends bitcoins from scratch-off TX to a new key in your own wallet, thereby "claiming" the card.
- You may now spend those bitcoins, once your claim is confirmed (requires at least 1 confirmation by default)
Because this is an entirely normal transaction, willingly relayed by all existing clients, no outside observer will know that this spend is a scratch-off card, rather than a regular spend to a regular bitcoin address. Variations: (1) Use decimal digits instead of hexidecimal, for id and password. More consumer friendly. Requires a small amount of brute forcing, if one limits the password to 16 digits, to recover the lost bits. (2) If you have a full block chain, and EC pub/private keys, the transaction hash ("txid") is optional. One could simply scan the block chain for an unspent transaction to the given bitcoin address (derived from the password). Credit for all bugs goes to me. Credit for the ideas goes to bytecoin, art, theymos and the authors of RFC 2898. EDIT: Updated to reflect changes through March 23. |
|
|
|
People, there's a simple way for transactions to become instant: as mining becomes large and centralised, a protocol is developed for at least the majority of hashing power to be able to verify that it has received a transaction. Then, an instant verification can be offered to the vending machine simply by confirming that the purchase has been successfully sent to the bulk of the network muscle--it will outrun any attempts to doublespend except under very rare circumstances. That rareness allows the verifier to cover their risk with insurance and/or fees that would be very reasonable.
Yep -- a bitcoin backbone, one might call it. |
|
|
|
Can't you work out how many order and the value the merchant was getting just by looking in the block chain at the number and value of payments to the publicly posted "pay me" address? Surely there's no way around this other than the merchant using a new receiving address for every sale he makes?
Yeah... I can imagine clever ways of obfuscating it such that you can't tell who's getting paid until they actually sign the transaction and spend the output. Make the txout something like: OP_OVER OP_HASH160 OP_XOR <hash160_xor_r1> OP_EQUALVERIFY OP_CHECKSIG
... and to spend the txin is: <scriptsig> <public_key> <r1> (where r1 is a random number used to obfuscate the publicly visible hash160). Or something like that (I shouldn't be thinking about cryptography when I'm this tired). Although not really the same thing, this reminds me of ArtForz' idea for theymos' bitcoin scratch-off cards. Seems like a neat and doable idea. |
|
|
|
I would rather not advertise Silk Road, and frankly wish it would go away. |
|
|
|
|
Good stuff. Glad this is written down somewhere outside the source code.
|
|
|
|
I was thinking this would be mostly about non-breaking changes, such as those patches people are already applying manually and running in production. disagree - breaking change disagree - breaking change (people must rewrite their code to expect the RPC server to appear early) That's more like it  I think this sort of change -- presuming it doesn't break any existing APIs, which I don't think it does -- would be perfect for these "useful patches" nightly builds. Maybe you could setup a Bitcoin cloud build service? I login... add my branch and click generate builds.
Sounds like a great bitcoin business or website for somebody... |
|
|
|
Associated patch summaries... Adds "xlisttransactions" RPC call. This lists all wallet transactions, using logic similar to the GUI's display code. Adds "getblockbycount" RPC call. This dumps the block on the main chain at the specified height, in its entirety. All data fields, including all transactions, are dumped in a single JSON response. A clone of "getblockbycount" RPC call. Same behavior as "getblockbycount" -- dumps block at specified height. Adds a "_fulldump" boolean to the output, indicating whether or not the entire block is present on disk (preparing for lightweight block chain support), hoping to address some objections of satoshi. Add "settxfee" RPC call. This permits changing of the 'paytxfee' variable at runtime. Print a response for every work solution submitted to bitcoind. Since we already logged successful proof-of-work solutions, the only thing remaining was to log when a proof-of-work check failed, which this patch does. |
|
|
|
Onto the topic, we should offer goods and services that are uniquely advantagous when using bitcoin. To a certain extent this means offering goods or services that are illegal or banned in many if not most countries.
I disagree. That's a good way to make bitcoin fail, early in its life. |
|
|
|
I see that it was set to ".8" but that only seemed to be used in printing out the version number. I didn't see uses of it elsewhere, did I miss one?
That's the purpose of the field. Whenever we have a four-dotted release 0.3.20.1, we set pszSubVer. It is part of the overall program version. It is separate AFAICT because satoshi needed an extra field, and the dotted-triple 0.3.20 is already part of a fixed encoding scheme that sets converts X.Y.Z to a single integer number. Presumably you're aware of the network protocol so presumably you can see how it is not feasible to add a fourth qualifier to the encoded version. So, I disagree with your change, it stomps on a field bitcoin has used in the past six months. We can change this if/when the client version becomes separate from the protocol version. cdecker proposed this in https://github.com/bitcoin/bitcoin/pull/63 His implementation was not desirable, but I think the genesis of the idea was sound. |
|
|
|
The subVer field is a string field in the version message. The official client just sets it to the empty string, and it's only used as a filter on the (never used so far) broadcast alerts.
This is incorrect. The client has used this in the past. To get the history behind a single line of code, use "git blame $file" You can see the official client made full use of this field in a790fa46f40d751307f86c37a709eb119768ce5b, and presumably older clients exist that use this field. |
|
|
|
So would my total CPU rate be ~16800 khash/sec?
Yes, that's correct. HashMeter output is per-thread, not a total for all threads. Do you really have a 12-core? If not, I bet you could do better with fewer threads and perhaps another algo. |
|
|
|
- Improve client to be more friendly. We need an addressing scheme that's easy to use for plebs.
- Funding. Influx of money.
Agreed. - Stock exchange to gain funding for business ideas.
A nasty briar patch, IMO. If you ever reach ~50 investors in a single company, you trigger securities laws. And in some countries, you probably trigger securities laws anyway. |
|
|
|
I agree it's a slow news month. It is also worrisome that the recent slashdotting seemed to bring largely an interest in mining, and not so much a horde of people interesting in helping build the bitcoin economy. If bitcoin is to survive, we need good, solid, reputable businesses and interesting applications to attract consumers. We need easy merchant APIs that do not require running a bitcoin P2P node. We need lightweight client mode. A lot of work to do! |
|
|
|
And I don't find any blk....dat file in data :/
I have blk0001.dat and blkindex.dat in /home/lalejand/.bitcoin
Yes, ".bitcoin" is the proper directory for you. I set mine to "data", sorry for the confusion. |
|
|
|
FWIW that may be an automated transfer, so I wouldn't build any assumptions from that. |
|
|
|
|
Delete data/blk*.dat and re-download the block chain, see if that helps.
|
|
|
|
|
Show Posts
