Gavin's bitcointools are nice for dumping blocks, but they require you to shutdown bitcoind, because bitcoin sets DB_PRIVATE flag, preventing outside users from using the multi-user database  See "getblockbycount" branch of git repository https://github.com/jgarzik/bitcoinHere is sample command usage and output for block at height 71995: $ /spare/repo/bitcoin.hacks/bitcoind -datadir=/garz/bitcoin/data getblock 71995
{
"hash" : "00000000002d1a4380793affbc610885aa2e0b224eeedd64ffe108044ec7d434",
"ver" : 1,
"prev_block" : "000000000103fcffbd8020ff7459f3635eb41102ee3b22fa466a7fdfc05bad58",
"mrkl_root" : "9d436c694968454ea0d17f4aece3b829930027c3cb918e5107a1605aa2eeae33",
"time" : 1280823515,
"bits" : 469830746,
"nonce" : 2918845955,
"n_tx" : 4,
"tx" : [
{
"hash" : "f85e77e4379694c8d2c1232d6fddfc7792073fb8484bdac37a9ba5ed1d245c57",
"ver" : 1,
"vin_sz" : 1,
"vout_sz" : 1,
"lock_time" : 0,
"in" : [
{
"prev_out" : {
"hash" : "0000000000000000000000000000000000000000000000000000000000000000",
"n" : 4294967295
},
"coinbase" : "045a0c011c0143"
}
],
"out" : [
{
"value" : 50.00000000000000,
"scriptPubKey" : "0xAD2D2527C630A3CF951703C4F44BB70F8C7524823F7095253D9412A1E9CAD1782B6B83228083A02485C20BC1870FB1A06C09DB768A5D27326A3E2FD859E7799204 OP_CHECKSIG"
}
]
},
{
"hash" : "38431f2f029a37a74a5b5bf0327f41a67b83aef8ad60a2efe918a8f1f0e7df1b",
"ver" : 1,
"vin_sz" : 1,
"vout_sz" : 1,
"lock_time" : 0,
"in" : [
{
"prev_out" : {
"hash" : "d9b308ca3484b7be6599c5050fec2cd2d31e654a0d2560989ffd28590bef6e6a",
"n" : 0
},
"scriptSig" : "0x01D82CD24A2C12E108087B9D9F81C49EF550F24D12668381D1D333D383B8EEB717200209F92E3246912CE4965E728963DF65FA63D9CCA10513CEF35C9BDCDC8018695F20024430"
}
],
"out" : [
{
"value" : 50.00000000000000,
"scriptPubKey" : "OP_DUP OP_HASH160 0x403FC36C7A1B5A9390F29343F4317F148A3ACB18 OP_EQUALVERIFY OP_CHECKSIG"
}
]
},
{
"hash" : "c61a96af68cce7329a450c18e3ac359d3052bda9187515a42fa7d262405213bd",
"ver" : 1,
"vin_sz" : 1,
"vout_sz" : 2,
"lock_time" : 0,
"in" : [
{
"prev_out" : {
"hash" : "1ff50ec1208497b333972da7dfdb2ba92c18da901df997d630b32981a013b783",
"n" : 0
},
"scriptSig" : "0x0132831D85F7395034FD537CADFB5BC3DF134347E73BD76352D31314686785B17320024351730466BEC02AD0A9D1F2BFBF4F246AFA8EE4B1BEE3FA8B83801B8301AF5820024430 0x51342C8A6D8C38C33413C63BE8CA93AD060BEA212D961EA63F4C76013E81978A06934604515C7941A729450A508CF556AD6B5061ADABF74C8F881C44B2405CDA04"
}
],
"out" : [
{
"value" : 0.05000000000000000,
"scriptPubKey" : "OP_DUP OP_HASH160 0xE183BC5BB9CEF757C51BCD8B864A8F2210114373 OP_EQUALVERIFY OP_CHECKSIG"
},
{
"value" : 0.4300000000000000,
"scriptPubKey" : "OP_DUP OP_HASH160 0x209F7B58DC860A2B0D2547FE659D78DFFC68FA77 OP_EQUALVERIFY OP_CHECKSIG"
}
]
},
{
"hash" : "d561a3594fcf97dd1a1abe7a1eda15c8e335aaaecf97f959de0595298d87c6d5",
"ver" : 1,
"vin_sz" : 1,
"vout_sz" : 2,
"lock_time" : 0,
"in" : [
{
"prev_out" : {
"hash" : "c61a96af68cce7329a450c18e3ac359d3052bda9187515a42fa7d262405213bd",
"n" : 1
},
"scriptSig" : "0x01DCDA3BAD3620FE246F2D973D6128123FC5F054121624852D98CEA4A3333128D00021025FFA265DA89861FC609792AD193204FCF0B2C1823B2D23052BCBD468274367BA0021024630 0x53B6705A0E13FD31A87C4F5F43ABDA77995B7CDA87B521043488254B16A122AFE99EA0BAE780CA19C6DCB733ECA9F42404B1F77951703B4057362704C126BD2304"
}
],
"out" : [
{
"value" : 0.05000000000000000,
"scriptPubKey" : "OP_DUP OP_HASH160 0x388E046D522A5EFDBFD272EAE11E9718F8C10FA0 OP_EQUALVERIFY OP_CHECKSIG"
},
{
"value" : 0.3800000000000000,
"scriptPubKey" : "OP_DUP OP_HASH160 0x1FC4B63556EB262B048F4A908875A62E338F7364 OP_EQUALVERIFY OP_CHECKSIG"
}
]
}
],
"mrkl_tree" : [
"f85e77e4379694c8d2c1232d6fddfc7792073fb8484bdac37a9ba5ed1d245c57",
"38431f2f029a37a74a5b5bf0327f41a67b83aef8ad60a2efe918a8f1f0e7df1b",
"c61a96af68cce7329a450c18e3ac359d3052bda9187515a42fa7d262405213bd",
"d561a3594fcf97dd1a1abe7a1eda15c8e335aaaecf97f959de0595298d87c6d5",
"b626f3cd7c1fd229bffbec34fab2700bc31659dbf2a74f7916701a18490125b4",
"dd74eea07e9bf2744655a9bab3a8cdbc5fe9a0c86ad18f42a2c259d40a83decb",
"9d436c694968454ea0d17f4aece3b829930027c3cb918e5107a1605aa2eeae33"
]
}
|
|
|
|
Oh boy, that will make it fun  Well, hopefully I can generate a block within the next 2 months now. Sheesh. But, with it going up it's a good thing. More CPU power to try and take over. Or it means someone is actively taking over ;-)  Sadly this will make it even harder to get new people in, if they don't actually see any progress in the first few weeks/months of "usage". Guess most testers wont stay long enough to generate anything. IMO that's good news. It shifts the emphasis over to adding value to the currency, rather than minting. |
|
|
|
[edit] I see it will show generated coin, so that is useful actually. Also, the current getreceivedbyaddress & getreceivedbylabel seem to be buggy in which transactions they show to begin with.
Buggy, how? Maybe they are just confusing, like they were to me, initially? getreceivedby* are by-address or by-label totals, not individual transactions. listtransactions was created while trying to implement web services for bitcoin. The only alternative I can see for tracking transactions, outside of listtransactions, was watching individual bitcoin address totals. getreceivedby* is not reliable, in that regard. |
|
|
|
Ah ok, does this new function also list individual transactions from IP to IP transfers? I took a glance at the source to get a rough view of what it's showing, didn't know it got into that much deeper detail.
It should present a list very similar to the GUI-presented display. |
|
|
|
A transaction can be written that requires two signatures to spend it next. You write a payment that requires the signature of both the recipient and the sender to spend it. To release the escrow, you give the recipient the signature for your half, or the payee can return it by giving you his signed half. There's no mediator in this simple case. The recourse is to refuse to ever release it, essentially burning the money.
Due to that recourse, it is unlikely to be used as an escrow mechanism |
|
|
|
It depends on whether or not you want to rely on trusting a 3rd party. mybitcoin.com would in theory have access to all private keys and thus could spend my money. Where as a full local client is more secure.
That is an over-generalization. For inexperienced "Aunt Tillie" users, www.my-bitcoin-site.com is far more likely to have given thought to encrypting and backing up the wallet. A website is more likely to have a more intelligent bitcoin P2P firewall scheme in place. |
|
|
|
2) How much per month for that instance? EC2 is a very expensive provider for a very big sites that can afford paying good money for good infrastructure. By "infrastructure" I mean their elastic computing API, load balancing, storage and content delivery services. My current record with cheap VPS is 3100 khashes/sec for $5/mo.
Which VPS provider? |
|
|
|
|
Content-Length is definitely not sent on Fedora 12 and Fedora 13, will investigate further. Will check RHEL/CentOS too.
|
|
|
|
Frankly, I think the official bitcoin client should be for more sophisticated users, and "average users" should be directed to user-friendly services like http://www.mybitcoin.com/ that do not require additional software to be installed. IMO websites and existing browsers should be all one needs to fully participate in the bitcoin economy. |
|
|
|
Given how hard they are to generate, in my opinion (if I worked 24 hours a day for 3 weeks, I'd certainly expect more than 50 cents)... I'd have to say that 1 BTC is worth about $800. I'll trade my 5 BTC for a PS3.
Given there's no realistic way to determine the value of something which is randomly generated, I'm giving up on it.
The value of bitcoins are determined by the market. See https://mtgox.com/ and http://www.bitcoinmarket.com/ for current exchange rates, which should give you a concrete idea of value. |
|
|
|
For shorter splits, immature generated coins on the shorter chain will disappear when the chains merge, but that would be about the worst consequences for honest users (unless you were unlucky enough to get an invalid coin from somebody trying to cheat).
It doesn't have to be someone trying to cheat. You can be honest, and yet unlucky and get caught on the other side of a network split. If you generate and spend coins on the unlucky side of the network split, the consequences are the same as for dishonest users. |
|
|
|
bitcoin requires the Content-Length header, but several JSON-RPC libraries do not provide it. When the Content-Length header is absent, bitcoin returns 500 Internal Server Error.
Can you be more specific about which JSON libraries don't provide Content-Length ? It'd be nice to document that. The two JSON RPC libs available at CPAN (Perl), and a compliant C lib that I wrote locally to verify the behavior. |
|
|
|
|
A good way to prevent long-chain takeover is to store the signature of the last-known "good" block in each bitcoin release binary.
|
|
|
|
My first obstacle is the missing ecdsa.h (Elliptic Curve Digital Signature Algorithm) file. It's listed in the man pages for CentOS, but missing from the package, WTF?
Anyway, I guess I can copy it from somewhere else, hopefully I'll have some binaries for us all soon.
Yes, ecdsa.h is considered patent-encumbered, so Red Hat and other distros turn off ec-dsa. Yes, Virginia, this means that bitcoin potentially has patent problems. |
|
|
|
Thanks for the pointer, interesting, but not what seems to be affecting me. Here's my current code (running on Google App Engine)
postdata = jsonrpc.dumps({"method": 'getbalance', "params":'','id':'jsonrpc'})
req = urllib2.Request('http://127.0.0.1:8332', postdata)
userpass = 'user:a'.encode('base64')[:-1]
authheader = "Basic %s" % userpass
req.add_header("Authorization",authheader)
handle = urllib2.urlopen(req)
json_response = handle.read()
self.response.out.write (json_response)
This yields a HTTPError: HTTP Error 500: Internal Server Error
This is a verified bug in bitcoin. bitcoin requires the Content-Length header, but several JSON-RPC libraries do not provide it. When the Content-Length header is absent, bitcoin returns 500 Internal Server Error. |
|
|
|
I'm not sure about that list; this is what I see: [jgarzik@bd bitcoin.hacks]$ grep '(strCommand ==' main.cpp
if (strCommand == "version")
else if (strCommand == "verack")
else if (strCommand == "addr")
else if (strCommand == "inv")
else if (strCommand == "getdata")
else if (strCommand == "getblocks")
else if (strCommand == "tx")
else if (strCommand == "block")
else if (strCommand == "getaddr")
else if (strCommand == "checkorder")
else if (strCommand == "submitorder")
else if (strCommand == "reply")
else if (strCommand == "ping")
|
|
|
|
|
FWIW, there exists -mstackrealign and -mpreferred-stack-boundary=NUM
|
|
|
|
As usual, system security is as strong, as it's weakest link's.
And I found, that the current process of distributing the binaries for Bitcoin payment system makes that payment
system too risky to convert real quantities of real money into bitcoins.
There is only one "official" site distributing binary. That makes the entire Bitcoin
payment system as secure as desktop of the user who have write-access to sourceforge.
I hope he trusts his desktop and network. But why should I? Even if I distrust his computer
and compile by myself, that does not protect the majority, which I believe, just downloads
the binary.
This is very true. It is a major weakness that Satoshi does not PGP-sign the hash signatures posted on the front page of http://www.bitcoin.org/. |
|
|
|
What sort of legal recourse would there be for somebody who engages in a contract (to simplify, presume both the "borrower" and "lender" are in the same country or even the same state) for a loan and then the borrower stops paying back? For those transactions in a legal tender, that question is fairly obvious, but does it apply to Bitcoins or to "alternate currencies"? How would you get garnishments to be done for Bitcoins, or would it have to be done in the legal tender "at current exchange rates" as of the date of the judgement?
Seriously, I don't know the answer to this, or to the legal enforceability of a Bitcoins denominated contract. It also seems like a legal vector that could be done "by the establishment" to discredit Bitcoins as well, if such contracts were held to be invalid. I would presume this applies to other alternative currencies, and it would seem like there should be some sort of case history on this topic. I just don't know where to even start looking for such a legal precedence.
A contract denominated in bitcoins is as enforceable as any other contracts. It's a written agreement between multiple parties, nothing special about that. If I want to write a contract that purchases cows in exchange for bananas, that's perfectly legal and as enforceable as any other contract. |
|
|
|
|
Show Posts
