The "value out" in this block #74638 is quite strange: {
"hash" : "0000000000790ab3f22ec756ad43b6ab569abf0bddeb97c67a6f7b1470a7ec1c",
"ver" : 1,
"prev_block" : "0000000000606865e679308edf079991764d88e8122ca9250aef5386962b6e84",
"mrkl_root" : "618eba14419e13c8d08d38c346da7cd1c7c66fd8831421056ae56d8d80b6ec5e",
"time" : 1281891957,
"bits" : 469794830,
"nonce" : 28192719,
"n_tx" : 2,
"tx" : [
{
"hash" : "012cd8f8910355da9dd214627a31acfeb61ac66e13560255bfd87d3e9c50e1ca",
"ver" : 1,
"vin_sz" : 1,
"vout_sz" : 1,
"lock_time" : 0,
"in" : [
{
"prev_out" : {
"hash" : "0000000000000000000000000000000000000000000000000000000000000000",
"n" : 4294967295
},
"coinbase" : "040e80001c028f00"
}
],
"out" : [
{
"value" : 50.51000000,
"scriptPubKey" : "0x4F4BA55D1580F8C3A8A2C78E8B7963837C7EA2BD8654B9D96C51994E6FCF6E65E1CF9A844B044EEA125F26C26DBB1B207E4C3F2A098989DA9BA5BA455E830F7504 OP_CHECKSIG"
}
]
},
{
"hash" : "1d5e512a9723cbef373b970eb52f1e9598ad67e7408077a82fdac194b65333c9",
"ver" : 1,
"vin_sz" : 1,
"vout_sz" : 2,
"lock_time" : 0,
"in" : [
{
"prev_out" : {
"hash" : "237fe8348fc77ace11049931058abb034c99698c7fe99b1cc022b1365a705d39",
"n" : 0
},
"scriptSig" : "0xA87C02384E1F184B79C6ACF070BEA45D5B6A4739DBFF776A5D8CE11B23532DD05A20029387F6E4E77360692BB624EEC1664A21A42AA8FC16AEB9BD807A4698D0CA8CDB0021024530 0x965D33950A28B84C9C19AB64BAE9410875C537F0EB29D1D21A60DA7BAD2706FBADA7DF5E84F645063715B7D0472ABB9EBFDE5CE7D9A74C7F207929EDAE975D6B04"
}
],
"out" : [
{
"value" : 92233720368.54277039,
"scriptPubKey" : "OP_DUP OP_HASH160 0xB7A73EB128D7EA3D388DB12418302A1CBAD5E890 OP_EQUALVERIFY OP_CHECKSIG"
},
{
"value" : 92233720368.54277039,
"scriptPubKey" : "OP_DUP OP_HASH160 0x151275508C66F89DEC2C5F43B6F9CBE0B5C4722C OP_EQUALVERIFY OP_CHECKSIG"
}
]
}
],
"mrkl_tree" : [
"012cd8f8910355da9dd214627a31acfeb61ac66e13560255bfd87d3e9c50e1ca",
"1d5e512a9723cbef373b970eb52f1e9598ad67e7408077a82fdac194b65333c9",
"618eba14419e13c8d08d38c346da7cd1c7c66fd8831421056ae56d8d80b6ec5e"
]
}
92233720368.54277039 BTC? Is that UINT64_MAX, I wonder? |
|
|
|
Jgarzik's been doing a lot of good with his patches. I for one have incorporated his GetBlock and ListTransactions patches into my unofficial builds.
That said, I guess we do need to clarify the legal status of everything he's made now. Jgarzik, could you please publish a license or at least go on record with your feelings about copying and/or modifying your works? Do you require attribution?
If you don't, a lot of people (myself include) will naively (and possibly incorrectly) assume that you intend all of your code and documentation to be released under a permissive (MIT or BSD-style) license.
All of the code I've released is under the same license as bitcoin itself. Copy away, it's open source  I'm undecided about the documentation, but RHorning is way out there: it's ridiculous to think anyone will "take over" the protocol by writing a document and keeping it on their own website. As long as Satoshi distributes the code, he "owns" the network protocol, and I hope it stays that way! |
|
|
|
Don't wanna take credit where it's not due the hashes/sec patch was from lachesis, and the extended-help might have been based on my idea, but the code was somewhat different. |
|
|
|
http://www.copyright.gov/help/faq/faq-general.html#myworkWhen is my work protected?
Your work is under copyright protection the moment it is created and fixed in a tangible form that it is perceptible either directly or with the aid of a machine or device.This applies to all Berne Convention countries, not just the US. I guess it's my own damn fault for assuming that others would follow international legal norms as basic as "the author owns his work."
|
|
|
|
I'm discouraged by your hostile reaction to something that was obviously INTENDED to be helpful rather than harmful. How is taking credit for my work intended to be helpful? are you willing to contribute this documentation under a license such that it can actually be used by the bitcoin project? It is highly demotivating to bother with it when others repost my work under their own names. |
|
|
|
|
This is standard copyright stuff, as practiced in major open source projects. Stop by Debian-legal or Fedora-legal for a while.
But copyright is a sideshow. I put my time and effort into this, and it certainly discourages further work when people have so little care for the work of others.
|
|
|
|
|
Specifications have separate copyrights from actual implementation, which is how many clones and compatible implementations of closed source systems have been created over the years, precisely because they are not derivative works.
But, even ignoring my copyright, is this community really endorsing the word-for-word taking of someone else's hard work, without attribution or permission?
|
|
|
|
|
I think it was implied to be
return "<" + wtx.GetHash().ToString() + ">";
?
|
|
|
|
|
Please do not copy my works without permission.
|
|
|
|
I needed this for some work I was doing, so I figured I would make it public: http://yyz.us/bitcoin/network.htmlThis doc lists each type of network message, gives it a rough description, and lists typical inputs and outputs. Very rough, but better than the other docs out there ('version' message is highly documented! ). |
|
|
|
|
Do you need 'gettransaction', given the existence of 'getblock'?
|
|
|
|
Can you add the date and time associated with each transaction?
Added, as the "tx_time" field in listtransactions version 10. Same patch URL, as always: http://gtf.org/garzik/bitcoin/patch.bitcoin-listtransactionsSample output, with transactions from a local miner & test box: [
{
"address" : "15SXfhMc82xC5pPx9qZhPA6bDrkbgBWBJy",
"label" : "",
"txn_id" : "716d636922c0fe4fa438914bfbccbdd3f440f68718438a5f14a62a954cd3ef49",
"tx_time" : 1281424940,
"category" : "credit",
"amount" : 0.05000000,
"confirmations" : 795
},
{
"address" : "1GudGhcqpDCwrJktYvktPHYCnDe6MHtBSr",
"label" : "",
"txn_id" : "2900f86ade72c8a312cac92f759c7d1efcd30253f32a76323b63d6278ce6da97",
"tx_time" : 1281139947,
"category" : "debit",
"amount" : 50.00000000,
"confirmations" : 1387
},
{
"address" : "1111111111111111111114oLvT2",
"label" : "",
"txn_id" : "d9aae437e71347dcfafd52a514a4b67db83044ae95384611fb127e805a51b9e7",
"tx_time" : 1281068407,
"category" : "generated",
"amount" : 50.00000000,
"confirmations" : 1507
}
]
|
|
|
|
|
What happens when we desire to return additional information, beyond tx-id?
For the sake of future compatibility, it seems like the flag should present a choice between returning (a) just the current 'sent', or (b) a JSON map containing tx-id, and perhaps other things.
|
|
|
|
|
Patch updated for current SVN, r130. Same patch URL, no change in implementation or operation.
|
|
|
|
|
100% agreed with your suggestion, about the need for txn_id association.
However, it seems better to avoid API breakage, because this API is so heavily used. It is almost guaranteed that anyone automating bitcoins is using sendtoaddress.
Either create a "send2" RPC call, or add an "[extended-JSON=0]" parameter to the existing sendtoaddress RPC call, or something similar that preserves existing application data flows.
|
|
|
|
|
Show Posts
