|
Ok, that makes a bit more sense. Thank you for clearing that up for me. Do you have a tip address?
|
|
|
|
Well there is no address in any transaction so you don't need to decode the address (but you will need to decode the output script).
Ok, so when I see the "addresses" array in the bitcoind verbose output, is the bitcoind server doing some calculating for me? There is no such thing as a balance, when a wallet says it has an X balance it means the sum of the value of the unspent outputs it has the ability to spend is X.
I understand that the protocol itself does not keep track of balances, which is part of the reason I'm tackling this issue. When I say "bitcoind getbalance", it sums up all the unspent outputs I have available to me. I'd like to programatically do the same for an arbitrary list of public keys. If I have to parse the scripts then I'll do so, I'm just trying to get a handle on exactly what is required to calculate the available unspent outputs. For now I'll stub out all other script formats besides the "normal" one, and tackle those later. We often talk about "sending coins to this address" but that kinda breaks down at the actual protocol level. All outputs (as in all even "normal" transactions) are scripts. The script defines what is required to spend that output. If you use term like "balance of pubkey" in the case of multisig (either native or P2SH) which PubKey "has" the balance of the output?
Exactly my question. I feel like I'm missing something fundamental here; how would a client calculate a 'balance' to be displayed in this kind of situation? I'll probably have to do some testnet transaction creation to understand a bit more how this all works. If you wanted to limit it to "normal" transactions (PayToPubKeyHash) you could just ignore all outputs which don't match this template
OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
This may be a good first step.
For the moment I'll probably do this just so I can have some info to work with, but eventually I'll need to handle all the cases. |
|
|
|
There are two types of multisig. There is "native" multisig where the script and pubkeyhashes are in the vout however that makes for very large addresses. P2SH was added later. With P2SH the output is a hash of the script and that makes the address compact.
With native multisig there would be multiple pubkeyhashes in the output. With P2SH there is just a single scripthash in the output.
While bitcoin may show addresses understand that addresses are encoded hashes (either PubKeyHashes or ScriptHashes) and they don't exist in the protocol itself. When you provide an address to a client it decodes the address to the reslting hashtype and the Hash is what is actually placed in the output of the transaction.
I'm sorry I'm not quite sure I understand. Maybe if I tell you my intent it'll help understand where I'm lost. I'm trying to write an algorithm to calculate the balance of a public key. I had figured to add up all the inputs and subtract out all the outputs as I scanned along the block chain. From what I gather I'll have to decode the address to the resulting hash type and compare that to the hash that is placed in the output of each transaction I parse? |
|
|
|
Sorry, this I don't know.
Seems like you are talking about specifics of some source code that I am not familiar with.
No I'm referring to the bitcoind output. if you look at the output for the transaction spending "from" the multi-sig, you'll get this: Request: bitcoind getrawtransaction d9a2ef9c07ab71ac12680df72cbbbf6153e7bb7ea511eb8ca764f434d378bbea 1
Response: {
"hex" : "0100000001e90191367cd56649ff96f45be2d21ba7e360aaea496b72c262dec4020826914c01000000fd8c0100483045022100adeac51e47a88cf6d3c1476550f9b34e5dbe5b347ef4ef590b5739a15bd7e0b2022006c24b4231028a8e1ad051aee5cb03884e763962d0d30fa94b51395c5107c79f01493046022100c6c3594f88b6ce4a71bd68a7dc8b0871176573cde99169a0e29611087e61e74102210095606fb6ad2c830013705101ad3762196e5c5c8577a48d9829d236dbb8c9a6e501483045022100b11868f0f99f0bb1e9ad2653358f8a420e29a0f56fb5426903d26d72520ad00f02206d87c4dba546045dddbc4cd3f23f5c53b51f8d53054718b67cdbc4d3601faf58014cad532102de57a0ac92a982903599cc1125f3ad6c360f5e091be2667bd2a07efae637d68a2102f0003265a9c7f5acdb7a40b9b98ace45f3111f421274c7b94f697faa337ac4c02103938fcd91c0a318876975a5648053eccb9ef275a0bade7b79f35d0f90694866652103a145418c25662a857248a9f49ff10ee4a53d28ce144a6954b19a71bbdc68c0c12103cf2e5b02d6f02340f5a9defbbf710c388b8451c82145b1419fe9696837b1cdef55aeffffffff0600a3e111000000001976a914a133373fb270ac403dc1a0bc2ccefcaf25261eef88ac00a3e111000000001976a9145749515e39e6962521072cd322c51939b7d9ff5c88ac00a3e111000000001976a914b87d8c0c149020ca55616a798bf71618b76e31d888ac00a3e111000000001976a914c3323e8f2a4acca83f0a07aaee359f8b0bd3e79488ac00e1f505000000001976a9145cc3df6331431526585aeba326406cfa9add2edd88acb01df5050000000017a9140136d001619faba572df2ef3d193a57ad29122d98700000000",
"txid" : "d9a2ef9c07ab71ac12680df72cbbbf6153e7bb7ea511eb8ca764f434d378bbea",
"version" : 1,
"locktime" : 0,
"vin" : [
{
"txid" : "4c91260802c4de62c2726b49eaaa60e3a71bd2e25bf496ff4966d57c369101e9",
"vout" : 1,
"scriptSig" : {
"asm" : "0 3045022100adeac51e47a88cf6d3c1476550f9b34e5dbe5b347ef4ef590b5739a15bd7e0b2022006c24b4231028a8e1ad051aee5cb03884e763962d0d30fa94b51395c5107c79f01 3046022100c6c3594f88b6ce4a71bd68a7dc8b0871176573cde99169a0e29611087e61e74102210095606fb6ad2c830013705101ad3762196e5c5c8577a48d9829d236dbb8c9a6e501 3045022100b11868f0f99f0bb1e9ad2653358f8a420e29a0f56fb5426903d26d72520ad00f02206d87c4dba546045dddbc4cd3f23f5c53b51f8d53054718b67cdbc4d3601faf5801 532102de57a0ac92a982903599cc1125f3ad6c360f5e091be2667bd2a07efae637d68a2102f0003265a9c7f5acdb7a40b9b98ace45f3111f421274c7b94f697faa337ac4c02103938fcd91c0a318876975a5648053eccb9ef275a0bade7b79f35d0f90694866652103a145418c25662a857248a9f49ff10ee4a53d28ce144a6954b19a71bbdc68c0c12103cf2e5b02d6f02340f5a9defbbf710c388b8451c82145b1419fe9696837b1cdef55ae",
"hex" : "00483045022100adeac51e47a88cf6d3c1476550f9b34e5dbe5b347ef4ef590b5739a15bd7e0b2022006c24b4231028a8e1ad051aee5cb03884e763962d0d30fa94b51395c5107c79f01493046022100c6c3594f88b6ce4a71bd68a7dc8b0871176573cde99169a0e29611087e61e74102210095606fb6ad2c830013705101ad3762196e5c5c8577a48d9829d236dbb8c9a6e501483045022100b11868f0f99f0bb1e9ad2653358f8a420e29a0f56fb5426903d26d72520ad00f02206d87c4dba546045dddbc4cd3f23f5c53b51f8d53054718b67cdbc4d3601faf58014cad532102de57a0ac92a982903599cc1125f3ad6c360f5e091be2667bd2a07efae637d68a2102f0003265a9c7f5acdb7a40b9b98ace45f3111f421274c7b94f697faa337ac4c02103938fcd91c0a318876975a5648053eccb9ef275a0bade7b79f35d0f90694866652103a145418c25662a857248a9f49ff10ee4a53d28ce144a6954b19a71bbdc68c0c12103cf2e5b02d6f02340f5a9defbbf710c388b8451c82145b1419fe9696837b1cdef55ae"
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 3.00000000,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 a133373fb270ac403dc1a0bc2ccefcaf25261eef OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a914a133373fb270ac403dc1a0bc2ccefcaf25261eef88ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"1FhM9RUTswvr1RPPDLC7ddm1d1kMPQ85oD"
]
}
},
{
"value" : 3.00000000,
"n" : 1,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 5749515e39e6962521072cd322c51939b7d9ff5c OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a9145749515e39e6962521072cd322c51939b7d9ff5c88ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"18xXcuLXhJmFcKoiLHqbjcpG4ip66pSf3E"
]
}
},
{
"value" : 3.00000000,
"n" : 2,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 b87d8c0c149020ca55616a798bf71618b76e31d8 OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a914b87d8c0c149020ca55616a798bf71618b76e31d888ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"1HpVjTeSnoqCkoCsX2iwMYqWrDy5UTzGC1"
]
}
},
{
"value" : 3.00000000,
"n" : 3,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 c3323e8f2a4acca83f0a07aaee359f8b0bd3e794 OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a914c3323e8f2a4acca83f0a07aaee359f8b0bd3e79488ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"1Jo6xSw431qX7GoVwc7oMTccLQwhfQVG6w"
]
}
},
{
"value" : 1.00000000,
"n" : 4,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 5cc3df6331431526585aeba326406cfa9add2edd OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a9145cc3df6331431526585aeba326406cfa9add2edd88ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"19TVp7iN6FjSQJTA6DNS9nfauR6PM3Mb8N"
]
}
},
{
"value" : 0.99950000,
"n" : 5,
"scriptPubKey" : {
"asm" : "OP_HASH160 0136d001619faba572df2ef3d193a57ad29122d9 OP_EQUAL",
"hex" : "a9140136d001619faba572df2ef3d193a57ad29122d987",
"reqSigs" : 1,
"type" : "scripthash",
"addresses" : [
"31oSGBBNrpCiENH3XMZpiP6GTC4tad4bMy"
]
}
}
],
"blockhash" : "00000000000000000ce0a18c852d827e4936e800a81c58c3f1f8bfd7103ab5f4",
"confirmations" : 1123,
"time" : 1399840827,
"blocktime" : 1399840827
}
The output has an array of "vouts". Each "vout" has a "scriptPubKey" property, and each "scriptPubKey" property has an array "addresses". I'm curious what the "addresses" array is in the serialized rawtransaction output from bitcoind. |
|
|
|
|
Ok, so it looks like multisig outputs each still only have one address in the "addresses" property of scriptPubKey property of the vout, and the only difference is the script that must be executed to unlock the output.
I guess I wrongly assumed that the vout.scriptPubKey.addresses[] property would list the addresses that can spend the output.
What is this array for? It looks like it always just holds the output public key. Is that correct? In what scenario would this array have multiple addresses?
|
|
|
|
I'm trying to understand the internal workings of a transaction, so I executed the following command against bitcoind bitcoind getrawtransaction fd3d049c9e75f96f9786b965b77b99fa0e7d39fa95e0b126682658299e71ac70 1 Here's the response: {
"hex" : "0100000001359815939bba9941e3bc0f9ffedea4e6b1c5c1885250b54cc11a20bc9c7fae51010000008c493046022100fbb4a90b868bdbd9229d7cc834373b502aa00eebb3d045088e8173be714f6943022100a26707f25a9955c23e71819300c1b32224881d8c09f65333503cb09d4fe62d4a014104558f3b743874639994ea070955847e85824b8bb9327c0297647f468bfd18e669c31ede14c44ae06af1b0bc4ffd06d6ffe564560e9c725b060bfd1ce89c843f2cffffffff028861706b030000001976a9148ca2fb6f0fcc4447764c6e4ed7929ed06f9797de88ac7874a112000000001976a9144640f7994705548593e476856e3680c42a641f8788ac00000000",
"txid" : "fd3d049c9e75f96f9786b965b77b99fa0e7d39fa95e0b126682658299e71ac70",
"version" : 1,
"locktime" : 0,
"vin" : [
{
"txid" : "51ae7f9cbc201ac14cb5505288c1c5b1e6a4defe9f0fbce34199ba9b93159835",
"vout" : 1,
"scriptSig" : {
"asm" : "3046022100fbb4a90b868bdbd9229d7cc834373b502aa00eebb3d045088e8173be714f6943022100a26707f25a9955c23e71819300c1b32224881d8c09f65333503cb09d4fe62d4a01 04558f3b743874639994ea070955847e85824b8bb9327c0297647f468bfd18e669c31ede14c44ae06af1b0bc4ffd06d6ffe564560e9c725b060bfd1ce89c843f2c",
"hex" : "493046022100fbb4a90b868bdbd9229d7cc834373b502aa00eebb3d045088e8173be714f6943022100a26707f25a9955c23e71819300c1b32224881d8c09f65333503cb09d4fe62d4a014104558f3b743874639994ea070955847e85824b8bb9327c0297647f468bfd18e669c31ede14c44ae06af1b0bc4ffd06d6ffe564560e9c725b060bfd1ce89c843f2c"
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 146.87429000,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 8ca2fb6f0fcc4447764c6e4ed7929ed06f9797de OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a9148ca2fb6f0fcc4447764c6e4ed7929ed06f9797de88ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"1Dpcr4DhdAF8HaNKEnYgv9PJgBjErdUdnM"
]
}
},
{
"value" : 3.12571000,
"n" : 1,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 4640f7994705548593e476856e3680c42a641f87 OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a9144640f7994705548593e476856e3680c42a641f8788ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"17QU8RmoQT9T2uQadi24piJ2nE1rDjfn8g"
]
}
}
],
"blockhash" : "000000000000050f650c03af06696d141dfaf39a213d1cd8aa46837fd37e425b",
"confirmations" : 101258,
"time" : 1348383754,
"blocktime" : 1348383754
}
In a multi-sig scenario, I'm assuming the "reqSigs" under scriptPubKey (which is 1 in this example) would be higher than 1 and there'd be multiple addresses in the "addresses" array. So here's my questions - Does anyone know of a multi-sig transaction I could look up on the blockchain to see it's structure?
- How do you determine the target address of the multi-sig output?
I've tried some preliminary googling but can't seem to get a straight answer on the JSON representation of a multi-sig transaction. Thanks. |
|
|
|
|
I'll give 1.6btc for 10 with escrow.
|
|
|
|
I wonder where they went? Maybe a catastrophic system failure? |
|
|
|
|
John's absence is a little disconcerting. He was supposed to be the premier escrow guy. Where's he been?
|
|
|
|
I've got bitcoind running as a daemon and it syncs fine for a while, and then slows down and stops syncing, and then I have to restart it to get it going again. It stopped once on me when there were a few blocks left to be downloaded (can't recall but less than 15 for sure). Upon discovery of a new block elsewhere in the network, my instance fetched the remaining ones as usual and became synchronized. Ok, so it may just be hung up on a given node? I left it going all night and it just listed like 300 orphan blocks, and no new accepts. Upon restart, accepts started rolling in at the rate of about 6 per second. I see this sometimes in my debug.log before it stops: 2014-05-09 11:23:39 ERROR: AcceptToMemoryPool : nonstandard transaction: scriptsig-non-canonical-push
2014-05-09 11:23:50 ERROR: AcceptToMemoryPool : nonstandard transaction: dust Are these potential culprits? No, I don't think so. They are just notifications of rubbish spotted in the network. Ok, so I can ignore those I found a script that modifies tc rules to restrict bandwidth. I ran them, but then later ran so it should be cleared, right? "it should be cleared" isn't clear  . Anyway, that command should list something, otherwise there's no traffic shaping in action. I can show you my script to shape my traffic from tor and bitcoind. I meant that that command should clear any traffic shaping/throttling rules, and my connection should be wide open. I even restarted the server to make sure that no rules were in place. I can throttle/shape once my install is stable. My distro came with berkeley db 5.3, and won't install 4.8, so I had to compile with --with-incompatible-db flag. Would this make a difference? That wallet won't work on older versions of bitcoin core. Besides that, you should be fine. Ok, I just don't know why I get a good bit of the way through, and then just completely stop for hours. It doesn't make sense and I can't find the culprit and I'm at a loss for what to do. My next step is probably to just install from the ppa and see if that fixes it. |
|
|
|
So here's my problem. I've got bitcoind running as a daemon and it syncs fine for a while, and then slows down and stops syncing, and then I have to restart it to get it going again. A couple of questions. I see this sometimes in my debug.log before it stops: 2014-05-09 11:23:39 ERROR: AcceptToMemoryPool : nonstandard transaction: scriptsig-non-canonical-push
2014-05-09 11:23:50 ERROR: AcceptToMemoryPool : nonstandard transaction: dust Are these potential culprits? Second, I found a script that modifies tc rules to restrict bandwidth. I ran them, but then later ran so it should be cleared, right? Third, My distro came with berkeley db 5.3, and won't install 4.8, so I had to compile with --with-incompatible-db flag. Would this make a difference? Fourth, This is a new install because my previous install got messed up (don't chown -R on /usr/bin!). I had my .bitcoin folder backed up, including the blockchain. It looks like the new compile of bitcoind didn't like the old blocks, and so is replacing them with new blocks from sync. Is there something that could have happened here to cause my problem? Finally, I discovered that my swap partition hadn't been mounted and had no swap space. I've re-enabled it and restarted bitcoind but I'm still having problems. What else can I check? I'm on Ubuntu 14.04 server Edit: Also, why do I sometimes see long strings of ORPHAN BLOCK 112, prev=000000000000000033cac1b48e35a41c3834b7678269a5a5e8d3e61b618a6dca in my debug.log? Are there really that many orphaned blocks? Edit2: Here's some more errors I get a bunch: 2014-05-09 12:08:22 ProcessBlock: ACCEPTED
2014-05-09 12:08:24 ERROR: CheckTransaction() : vin empty
2014-05-09 12:08:24 ERROR: AcceptToMemoryPool: : CheckTransaction failed
2014-05-09 12:08:24 Misbehaving: 93.77.226.90:8333 (0 -> 10)
2014-05-09 12:09:13 ResendWalletTransactions()
2014-05-09 12:09:13 Relaying wtx 3e1a26f1814be4146b6574924231d4c0f7fd285660a5d6c001c8d64cff58dc9d
2014-05-09 12:10:12 socket recv error 104
|
|
|
|
|
Agreed; some people don't pay anything for electricity. Lower electricity rates would change this, especially at scale. I just wonder the trade-off in additional cooling and shorter lifespan. For me at .11/kWh, with only a few S1's, it really doesn't make sense.
|
|
|
|
|
I don't really see the benefit of overclocking. I saw that it takes over 100 watts of extra power and only provides 20-25 GH/s. Seems like a bad deal to me.
|
|
|
|
|
They'll still be profitable for another jump or two, depending on your electricity. I've got two hashing away. Sad to see them go...
|
|
|
|
|
So I bought one, and they're great. My question is, can I put two antminer S1's at stock clock on one power supply? The S1 claims to pull 360 watts, so with two I'm pulling 720, which is pretty close to the stated 750W. Is there an inordinate amount of risk in pushing the 750W power supply to that level?
|
|
|
|
|
I received my refund, so John K. gets +1 trust from me.
|
|
|
|
You don't buy these for financial ROI, people. Anybody thinking they would ROI must be thinking of selling them on, themselves.  But as StickMiners go, the NF6 is looking to be pretty sweet - and the price point set in this group buy is pretty good, too. At $114.73/single 11Ghash/s unit, that's about $10.43/Ghash. That makes it cheaper than the AntMiner U1 at $11.22/Ghash and only mildly more expensive than the AntMiner U2; and you'd need 5-6 of those to get the same hash rate. The NF6 makes a nice tidy package for anybody wanting to mine for fun, play with the electronics, etc. If you want ROI, you really need to be looking at the big machines, along with the upfront investment as well as power, housing and cooling needs, etc. Honestly, right now even the big machines are looking like they'll be a big gamble.  People are hip to the game; new stuff is used in datacenters to mine, not sold off, and little guys like me have no real way to get in without a contract with a direct connection to a chip manufacturer. I'm planning out a big solar array that may make it profitable to mine, but even with free electricity a lot of the new stuff coming out won't make back their initial cost before their mining profits approach 0. |
|
|
|
|
Seems a little pricey. @5V, 1.2 amp pulls 6 watts. 11GH/s @ 6 watts looks to pull in about $20, being profitable for about 4 months. Even with free electricity, it'll only pull in around $30 before the profit approaches zero. Good luck with your endeavor, but I think these chips are quickly becoming obsolete.
|
|
|
|
|
Show Posts
