1 2015-03-29 00:00:07 <Chillum> then when I restarted it it went back to block 1
  2 2015-03-29 00:00:29 <phantomcircuit> Chillum, compile from source?
  3 2015-03-29 00:00:46 <Chillum> yes
  4 2015-03-29 00:00:53 <Chillum> arm7
  5 2015-03-29 00:01:39 <Chillum> like this: http://pastebin.com/kfU9qiZa
  6 2015-03-29 00:01:51 <Luke-Jr> phantomcircuit: there are at least 3 GBT<->Stratum proxies..
  7 2015-03-29 00:02:52 <Luke-Jr> Eloipool's gmp-proxy.py (maybe not the final GBT spec?), slush's stratum-server, and BFGMiner
  8 2015-03-29 01:08:37 <roybadami> I have no idea how to propose changes to the text in Bitcoin Core (other than it is presumably a lot of work to translate even a minor change into a large number of languages).
  9 2015-03-29 01:09:17 <roybadami> But I just notices that the dialog after sending coins refers to the total amount including fee as the 'net' amount (when it clearly should be 'gross')
 10 2015-03-29 01:29:59 <Luke-Jr> roybadami: just change it and submit a pull request to cfield's trivial branch
 11 2015-03-29 01:37:56 <phantomcircuit> Luke-Jr, so there are
 12 2015-03-29 01:38:03 <phantomcircuit> (not documents anywhere obvious btw)
 13 2015-03-29 03:13:27 <phantomcircuit> Luke-Jr, i see there's an explanation at the bottom of BIP 0022 on why transactions are included in full
 14 2015-03-29 03:13:34 <phantomcircuit> instead of just transaction hashes
 15 2015-03-29 03:13:40 <phantomcircuit> but i have to say i still dont see why
 16 2015-03-29 03:14:03 <phantomcircuit> is it so the miner can decide not to mine a transaction sent by the pool based on it's local rules?
 17 2015-03-29 03:18:18 <Luke-Jr> phantomcircuit: that's related to submissions; I suppose nothing forbids transactions omitting data, but I'd discourage it for transparency
 18 2015-03-29 03:18:38 <Luke-Jr> phantomcircuit: also, without data it makes it impossible for clients to merge the tx list with his own and mine the combined block
 19 2015-03-29 03:18:50 <Luke-Jr> (since clients need to avoid conflicting spends)
 20 2015-03-29 03:18:56 <gmaxwell> phantomcircuit: e.g. with it as is the pool can't do selfish mining attacks without the miner's help (or at least indifference) because the miner can submit locally.
 21 2015-03-29 03:19:57 <newtoirc> Hi,  I'm looking for a way to read bitcoin-qt block-chain/transaction data directly from disk instead of through RPC.  I've found my bitcoin data directly but am unsure which of the many files to load into my berkeley db tool.  Is there an easy answer?
 22 2015-03-29 03:22:24 <phantomcircuit> Luke-Jr, the dependency stuff could list all of the dependencies not just the mempool ones
 23 2015-03-29 03:22:42 <phantomcircuit> which would allow the client to merge the lists without the full transaction
 24 2015-03-29 03:22:54 <Luke-Jr> phantomcircuit: yes, that may be a good idea to do anyway, since sidechains may not use the same tx format :/
 25 2015-03-29 03:26:00 <phantomcircuit> gmaxwell, i was thinking of separating the block and transaction policy synchronization
 26 2015-03-29 03:26:29 <phantomcircuit> there's definitely some complications there potentially though
 27 2015-03-29 03:35:09 <Luke-Jr> phantomcircuit: if you mean simply combining a template from bitcoind with one from the pool (potentially omitting transactions), that's something I've done some work implementing
 28 2015-03-29 03:50:03 <phantomcircuit> Luke-Jr, a bit more than that
 29 2015-03-29 11:58:19 <fanquake> ;;blocks
 30 2015-03-29 11:58:20 <gribble> 349794
 31 2015-03-29 15:04:31 <paulo_> "There is from address". How does the network know which address to deduct from?
 32 2015-03-29 15:05:50 <sturles> It doesn't deduct from an address.
 33 2015-03-29 15:06:58 <sturles> The input(s) are references to outputs from previous transactions, and everything is spent.  The client will output change to a new address, if you don't spend all of it.
 34 2015-03-29 15:08:31 <paulo_> is there an explanation for the double hashes?
 35 2015-03-29 15:09:14 <paulo_> oh wait, google gives answers
 36 2015-03-29 15:17:45 <dgenr8> "There is no from address" is a confusing over-reduction.  Only wallets with the keys to particular from-addresses can spend them.  It's just that the network needs more information than just an address, to actually spend them.
 37 2015-03-29 15:19:03 <dgenr8> In the language of tax season, it needs the "specific lots" of the transactions that created the coins (no FIFO or LIFO here).
 38 2015-03-29 15:42:26 <Luke-Jr> paulo_: double hashes? O.o
 39 2015-03-29 15:42:53 <paulo_> hash = Sha256(Sha256(data))
 40 2015-03-29 15:43:00 <Luke-Jr> dgenr8: it's not over-reduction at all, no. and trying to do bitcoin as "specific lots" is misguided.
 41 2015-03-29 15:43:07 <Luke-Jr> ah
 42 2015-03-29 15:43:53 <Luke-Jr> paulo_: basically the whole address and wallet concepts are abstractions on top of a low-level protocol that has neither
 43 2015-03-29 15:44:50 <Chillum> bitcoin still needs to be in an address to send from it, so saying there are no from address is an over simplification. Call them outputs if you like, they are still attached to a given address
 44 2015-03-29 15:44:57 <Luke-Jr> addresses are merely invoice tokens (they receive payment, and nothing else), while wallets control a balance abstracted from a list of UTXO serial numbers with values
 45 2015-03-29 15:45:10 <Luke-Jr> Chillum: no, bitcoins are never in an address, and never sent from an address.
 46 2015-03-29 15:45:42 <Chillum> I am familiar with your position. Regardless of how the core works, there are other parts of bitcoin.
 47 2015-03-29 15:46:00 <Chillum> addresses are real things that people use, even if at the center of the protocol they are not considered
 48 2015-03-29 15:46:15 <Luke-Jr> Chillum: addresses are real things people use .. to receive, and nothing else
 49 2015-03-29 15:46:40 <Chillum> an address is derived from a private key. Are you suggesting we don't use private keys to send?
 50 2015-03-29 15:47:13 <Luke-Jr> that's a technical detail
 51 2015-03-29 15:47:24 <Luke-Jr> the private key is part of the wallet, it isn't part of the address
 52 2015-03-29 15:48:40 <Chillum> the private key is part of the wallet and addresses are derived from it. So addresses come from the wallet
 53 2015-03-29 15:48:54 <Chillum> an address is a public representation of a private key
 54 2015-03-29 15:49:19 <Luke-Jr> no, an address is a unique and opaque invoice identifier that can be paid to
 55 2015-03-29 15:49:39 <Luke-Jr> how the wallet produces the address, is a technical detail irrelevant to usage
 56 2015-03-29 15:49:50 <Chillum> it is derived deterministically from the private key from the wallet
 57 2015-03-29 15:49:53 <Chillum> I understand the technical point you are making, I think it is overly semantic and unhelpful to someone trying to understand things
 58 2015-03-29 15:50:38 <Luke-Jr> Chillum: no, my point is that *you* are trying to make a technical/semantic point that is not helpful ;)
 59 2015-03-29 15:50:57 <Luke-Jr> that it is derived from the private key, is not a relevant factor to how it is used
 60 2015-03-29 15:51:26 <Luke-Jr> that's the irrelevant technical/semantic detail
 61 2015-03-29 15:51:37 <Chillum> the reality is when I get bitcoin it comes from one or more key/pairs and though key/pairs link on a 1-1 basis with addresses
 62 2015-03-29 15:51:50 <Chillum> the reality of bitcoin is that from addresses exist and are relevant
 63 2015-03-29 15:51:55 <Chillum> regardless of how the core protocol works
 64 2015-03-29 15:52:38 <Chillum> I understand that they are outputs and not addresses
 65 2015-03-29 15:52:41 <Luke-Jr> Chillum: no, they don't. even if there is a 1:1 basis between keys and addresses, there isn't a 1:1 basis between people and keys
 66 2015-03-29 15:52:46 <Chillum> but those outputs map to addreses
 67 2015-03-29 15:52:57 <Luke-Jr> no, they map to scripts
 68 2015-03-29 15:53:05 <Chillum> nobody said anything about 1-1 between people and keys
 69 2015-03-29 15:53:09 <Luke-Jr> which can be satified by a wallet, which can have many different users
 70 2015-03-29 15:53:33 <Luke-Jr> Chillum: addresses refer to people more than they refer to keys
 71 2015-03-29 15:53:45 <Chillum> no they don't
 72 2015-03-29 15:53:58 <Chillum> each private key has an address
 73 2015-03-29 15:54:01 <Luke-Jr> the address identifies the recipient and purpose of the payment. it doesn't identify the key, that's just a technical relationship only.
 74 2015-03-29 15:54:07 <Chillum> it can be shared by people or one person can have many
 75 2015-03-29 15:54:46 <Chillum> I am not going to debate this. I understand your position, I just don't agree with it
 76 2015-03-29 15:56:28 <Luke-Jr> fine, but you're still wrong. :x
 77 2015-03-29 15:57:13 <andytoshi> Chillum: #bitcoin please
 78 2015-03-29 15:58:03 <Chillum> No need, I am done the conversation
 79 2015-03-29 15:59:05 <Chillum> I am not finding this channel as interesting as I had hoped
 80 2015-03-29 17:16:40 <gribble> pong
 81 2015-03-29 17:16:40 <paulo_> !ping
 82 2015-03-29 19:26:53 <StephenM347> Does anyone know, do NOMP pools disallow multiple workers to use the same payout address?
 83 2015-03-29 20:00:38 <Fistful_of_Coins> is there a timeout for multisig transactions?
 84 2015-03-29 20:00:59 <Fistful_of_Coins> for ex. i sign and need some other dude to sign in antartica, how long does he have for the tx to go through
 85 2015-03-29 20:01:25 <belcher> no timeout inherent in the btc protocol, the intermediate transaction parts are never broadcast on the network anyway
 86 2015-03-29 20:01:29 <belcher> only the final fully-signed tx
 87 2015-03-29 20:02:07 <Fistful_of_Coins> ok,
 88 2015-03-29 20:03:00 <Fistful_of_Coins> so is there a way to cancel a multi sig
 89 2015-03-29 20:03:05 <Fistful_of_Coins> if one party hasnt signed yet
 90 2015-03-29 20:03:22 <belcher> depends on the underlying communication protocol you have
 91 2015-03-29 20:03:41 <belcher> if you're using bitrated.com for example, i think that has a timeout
 92 2015-03-29 20:04:31 <Fistful_of_Coins> so it's a layer on top it seems
 93 2015-03-29 20:04:42 <Fistful_of_Coins> something that needs to be implemented on an individual case
 94 2015-03-29 20:05:22 <Fistful_of_Coins> how would they do it, since they'd need multi signs to move the coins anyway
 95 2015-03-29 20:05:36 <Fistful_of_Coins> making it useless if they have multiple signing keys
 96 2015-03-29 20:07:39 <Fistful_of_Coins> can't we sign it to be sent before a itme
 97 2015-03-29 20:07:40 <Fistful_of_Coins> ah
 98 2015-03-29 20:07:41 <Fistful_of_Coins> yes
 99 2015-03-29 20:07:42 <Fistful_of_Coins> thats it
100 2015-03-29 20:08:23 <belcher> what is your question?
101 2015-03-29 20:08:58 <Fistful_of_Coins> can i write a tx script that prevents a TX being added to a block if a  certain block has been passed?
102 2015-03-29 20:09:34 <Fistful_of_Coins> block height has been passed, ie. make a tx and if we are past block that dates to march 26, then tx isnt added
103 2015-03-29 20:10:37 <Fistful_of_Coins> send 4 BTC before date = b{locknumber 5 blocks ahead}
104 2015-03-29 20:13:16 <Fistful_of_Coins> so this would require all sigining parties to sign before date 5blocks ahead
105 2015-03-29 20:20:32 <pipeep> Is there a way to script getting the lastest bitcoind binary from https://bitcoin.org/bin/ ?
106 2015-03-29 20:20:56 <pipeep> I don't want to screen-scrape it because that might be fragile, and might end up giving me a RC
107 2015-03-29 20:39:08 <jhogan42> I'm running a bitcoin node w/txindex=1; anyone know why I wouldn't be able to view the blockchain's genesis transaction?  http://pastebin.com/NXiktTei
108 2015-03-29 20:47:55 <hearn> the genesis tx is special
109 2015-03-29 20:47:58 <hearn> it does not exist in the db
110 2015-03-29 20:52:26 <jhogan42> hmm; then where's the bit about the Times headline?  I guess that's part of the block rather than the transaction?  thanks hearn.
111 2015-03-29 20:52:44 <hearn> it's a part of the genesis coinbase, yes
112 2015-03-29 20:52:49 <hearn> which is in the genesis block
113 2015-03-29 20:52:58 <hearn> however that block (and thus the coinbase in it) is special in the code
114 2015-03-29 20:53:06 <hearn> is there any particular reason you want it?
115 2015-03-29 20:53:41 <jhogan42> Got it.  Thanks.  No, just learning my way around the innards of bitcoin, and trying to fill gaps in my knowledge.
116 2015-03-29 20:53:56 <jhogan42> don't know a priori what will yield interesting insights :-)
117 2015-03-29 21:09:32 <Luke-Jr> pipeep: you shouldn't automate using untrusted binaries..
118 2015-03-29 21:09:51 <Luke-Jr> (and if you were verifying signatures, you'd have the gitian.sigs repo to base filenames off..)
119 2015-03-29 21:18:34 <dgenr8> Fistful_of_Coins: txes don't have a lockafter time today, but i think you make a good case for it
120 2015-03-29 21:22:07 <dgenr8> hearn: another RBF problem for your missive -- it gives signers of each individual input the power to nullify the whole tx
121 2015-03-29 21:31:52 <Luke-Jr> dgenr8: that's a pretty big issue - now an attacker could participate in a CoinJoin, double spend it, and either keep his own bitcoins, OR cause others' to lose theirs…
122 2015-03-29 21:32:10 <Luke-Jr> (assuming SE)
123 2015-03-29 21:34:15 <gmaxwell> "SE"?
124 2015-03-29 21:35:04 <gmaxwell> Luke-Jr: if a join input it spent out from under it, its isomorphic to a participant not signing, you respond by retrying. (and whatever mechnism your introduction method has to punish non-signers)
125 2015-03-29 21:35:16 <Luke-Jr> Scortched Earth
126 2015-03-29 21:35:54 <Luke-Jr> gmaxwell: the difference is when merchants respond to that spend by burning their portion to fee
127 2015-03-29 21:36:00 <gmaxwell> yea, thats why PT had previously proposed SE acceptability be signaled or something.
128 2015-03-29 21:36:31 <Luke-Jr> oh, and just require non-SE txns to wait for confirmation? I guess that works
129 2015-03-29 21:37:05 <gmaxwell> Right.
130 2015-03-29 21:51:38 <hearn> hah, that's really cool: https://getaddr.bitnodes.io/nodes/network-map/
131 2015-03-29 21:58:17 <Taek> perhaps I have missed something, but what's the significance of where the nodes appear spacially?
132 2015-03-29 22:09:19 <phantomcircuit> Taek, it's grouped by AS number (ie ip transit provider)
133 2015-03-29 22:15:58 <phantomcircuit> Luke-Jr, why the sigoplimit sizelimit for block messages?
134 2015-03-29 22:16:23 <phantomcircuit> i would assume the miner would know those limits since they're network rules
135 2015-03-29 22:21:38 <Luke-Jr> phantomcircuit: in case network rules change, or the pool has additional restrictions (eg, to ease relaying of blocks)
136 2015-03-29 22:22:41 <phantomcircuit> Luke-Jr, those limits changing would mean a block version number bump
137 2015-03-29 22:22:57 <phantomcircuit> i guess technically you cant rely on that
138 2015-03-29 22:23:18 <phantomcircuit> it seems kind of reasonable to though
139 2015-03-29 22:24:20 <phantomcircuit> too*
140 2015-03-29 22:35:31 <phantomcircuit> Luke-Jr, excuse me while i reinvent the wheel one step at a time
141 2015-03-29 22:47:50 <Luke-Jr> phantomcircuit: a pool using a lower limit does not change consensus rules at all
142 2015-03-29 22:48:20 <phantomcircuit> Luke-Jr, why does the pool even care though?
143 2015-03-29 22:48:46 <Luke-Jr> phantomcircuit: relay/propagation time for blocks is one possible reason
144 2015-03-29 22:48:56 <Fistful_of_Coins> can't there be something like a transaction will not be included if it is received after block X? and it needs to have multi sig as well
145 2015-03-29 22:49:20 <phantomcircuit> Luke-Jr, it kind of seems like there's a bunch of other potential rules and that these fields cover just the two most obvious ones
146 2015-03-29 22:49:32 <Fistful_of_Coins> that way you could cook up a txn with your sig, pass it on to other signer who has to sign it before block X
147 2015-03-29 22:49:58 <phantomcircuit> like what if i require all the transactions in a block to spell out "deadbeef" when you look at the first byte of the transaction id
148 2015-03-29 22:50:29 <Luke-Jr> phantomcircuit: that would be a silly rule..
149 2015-03-29 22:50:47 <Luke-Jr> Fistful_of_Coins: intentionally not
150 2015-03-29 22:51:49 <phantomcircuit> Luke-Jr, an extreme example
151 2015-03-29 22:51:52 <phantomcircuit> but you see my point?
152 2015-03-29 22:52:10 <Fistful_of_Coins> if the first signer signs the TX doesn't he sign the script as well? forcing it to be the same
153 2015-03-29 22:52:10 <Luke-Jr> phantomcircuit: not really
154 2015-03-29 22:52:28 <Fistful_of_Coins> Luke-Jr: why is it intentionaly not?
155 2015-03-29 22:52:50 <phantomcircuit> Luke-Jr, how about the pool requires all the transactions which are dependent on future transactions to be in the start of the block
156 2015-03-29 22:53:06 <phantomcircuit> or for the transactions to be arranged such that they're processed faster by bitcoind
157 2015-03-29 22:53:08 <Luke-Jr> Fistful_of_Coins: breaks fungibility
158 2015-03-29 22:53:38 <sipa> Fistful_of_Coins: it means, as a receiver of coins, you need to check their blockchain inclusion (and that of their ancestors) to judge the risk of them being invalid
159 2015-03-29 22:53:42 <Luke-Jr> phantomcircuit: there's a limit to what is viable to have in a non-script protocol
160 2015-03-29 22:54:04 <sipa> Fistful_of_Coins: as in normal circumstances, a transaction that is not being double-spent will remain valid across a reorganization
161 2015-03-29 22:54:36 <sipa> Fistful_of_Coins: but if the transaction becomes invalid, it may not be possible to include it in a reroganized branched (and its descendants)
162 2015-03-29 22:54:52 <sipa> Fistful_of_Coins: so there is an inherent principle that if a transaction is once valid, it must remain valid
163 2015-03-29 22:55:04 <Fistful_of_Coins> sipa: and how does it break it? You sign a tx, you don't broadcast it until second signer has signed...
164 2015-03-29 22:55:26 <Luke-Jr> Fistful_of_Coins: "broadcast" is not something the consensus system is aware of
165 2015-03-29 22:55:27 <sipa> Fistful_of_Coins: i'm talking about any feature which makes a transaction that was once valid, invalid
166 2015-03-29 22:55:51 <phantomcircuit> Luke-Jr, that's what i was thinking
167 2015-03-29 22:55:52 <phantomcircuit> ok
168 2015-03-29 22:59:01 <Fistful_of_Coins> so is there any way with the blockchain and txn scripts to make a multisig transaction be signed by both signers within a given timespan ?
169 2015-03-29 22:59:21 <Fistful_of_Coins> maybe returning it to origin if late, or something like that
170 2015-03-29 22:59:49 <sipa> Fistful_of_Coins: have a pre-signed but unbroadcast timelocked transaction to return the coins