1 2014-02-22 01:26:47 <Belxjander> maybe a dumb question...but is it plausible/possible/too dangerous...
2 2014-02-22 01:26:59 <davvblack> nothing is too dangerous
3 2014-02-22 01:27:11 <gmaxwell> everything is too dangerous.
4 2014-02-22 01:27:23 <sipa> nothing is too everything.
5 2014-02-22 01:27:35 <Belxjander> If a Transaction is registered to the BlockChain, is it posible to have it require a second confirmation transaction referencing it for the funds to actually transfer..the first transaction simply acting as a funds locking mechanism
6 2014-02-22 01:27:47 <davvblack> ...why?
7 2014-02-22 01:27:50 <davvblack> that's already what confirmations do
8 2014-02-22 01:27:59 <davvblack> just wait for two confirmations if you want two confirmations
9 2014-02-22 01:29:28 <Belxjander> I was thinking of a "contract exchange" where both parties in the exchange transfer the BTC but it is effectively BlockChain escrow locked until the second transaction confirms the OTHER transfer of goods/service is complete
10 2014-02-22 01:30:27 <davvblack> Let me find the link on it, but there's a way to spend to an address such that spending FROM that address necessarily releases the other half of the private key to a different transaction, making trades like that safe automatically
11 2014-02-22 01:30:30 <Belxjander> not just cnofirmations by blocks and time
12 2014-02-22 01:30:43 <davvblack> without added complexity of a new protocol
13 2014-02-22 01:31:04 <davvblack> https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains
14 2014-02-22 01:31:10 <davvblack> this example is basically what you are describing, but more elegantly
15 2014-02-22 01:31:13 <Belxjander> davvblack: I'm not so conversant with the underlying code model, and I have only just gotten time to actually take a look under the covers really
16 2014-02-22 01:31:30 <Belxjander> oh good...so there is an existing way of doing that
17 2014-02-22 01:31:30 <davvblack> yeah, it has to do with some pretty deep cryptography that even I don't understand fully
18 2014-02-22 01:31:36 <davvblack> but that page explains it pretty well
19 2014-02-22 01:32:14 <davvblack> that whole article is awesome.
20 2014-02-22 04:26:16 <davvblack> Is there any talk of supporting an immutable txid (ntxid?) in the reference client purely for RPC calls, aka without a hard fork? That might be a nice next step
21 2014-02-22 04:30:08 <warren> davvblack: folks are against there being a separate index for it.
22 2014-02-22 04:30:40 <warren> davvblack: there's a patch to compute it but you can't lookup
23 2014-02-22 04:31:19 <davvblack> â¦. that's such a useful index :/
24 2014-02-22 04:31:39 <davvblack> oh well.
25 2014-02-22 04:31:55 <davvblack> it should at least arguably be an optional index that you can force it to calculate
26 2014-02-22 04:35:12 <freewil> davblack see https://github.com/bitcoin/bitcoin/pull/3656 for the discussion on ntxid
27 2014-02-22 04:35:23 <davvblack> thanks
28 2014-02-22 04:39:32 <jgarzik> davvblack, You get an immutable txid once a transaction is confirmed in the blockchain.
29 2014-02-22 04:41:21 <davvblack> yeah, but you can't easily search for a known ntxid, right?
30 2014-02-22 04:41:29 <davvblack> so the normal use case of an exchange is still awkward
31 2014-02-22 04:42:34 <davvblack> 1) publish transaction 2) getnormalizedtxid on that 3) store ntxid 4) full scan for it? I guess you can just pore through each block as they come in⦠it just seems like it would be better to have an optional index.
32 2014-02-22 04:43:18 <davvblack> actually i guess it's not a huge deal because you can just watch each block for that ntxid, then when it comes in, pull the txid off of it and save that, then look it up by that later
33 2014-02-22 04:44:10 <davvblack> im still reading through this thread too
34 2014-02-22 05:04:33 <davvblack> Has there been a discussion of adding a ttl to transactions instead of having it be global?
35 2014-02-22 05:04:45 <davvblack> ie setting it long so you can set super-low fee low-urgency
36 2014-02-22 05:05:13 <davvblack> or setting it very short so you know you can reuse the same inputs with higher fee very soon if it doesn't confirm (ie, to safely withdraw coin from a service)
37 2014-02-22 05:08:57 <davvblack> it wouldn't even need to be a hard fork as far as I understand it, because it would only control when nodes start broadcasting transactions that would double-spend already accepted transactions.
38 2014-02-22 05:09:22 <davvblack> (though maybe there would be an issue with where to store the ttl itself)
39 2014-02-22 05:09:52 <Luke-Jr> unnecessary
40 2014-02-22 05:10:18 <davvblack> how do you figure?
41 2014-02-22 05:10:57 <davvblack> what is the current way of increasing the fee of an already broadcast transaction while still guaranteeing at most one of them gets included?
42 2014-02-22 05:21:50 <jgarzik> davvblack, an exchange must ultimately manage and watch its unspent outputs. those are the "coins" of bitcoin.
43 2014-02-22 05:22:21 <davvblack> right, i know how outputs work. I'm just talking of the case where they are skirting the low end of 'ok transaction fees' and a certain transaction is not confirming
44 2014-02-22 05:22:24 <davvblack> how do they up those fees?
45 2014-02-22 05:22:24 <jgarzik> davvblack, regardless of malleability, you must guard for double-spending prior to confirmation -- and that goes for withdrawals as well as deposits
46 2014-02-22 05:22:43 <jgarzik> people knew that for deposits, but forgot for withdrawals
47 2014-02-22 05:22:57 <davvblack> I think we're not talking about the same thing here
48 2014-02-22 05:23:24 <davvblack> i just mean that when publishing outgoing transactions, there should be a ttl beyond which you can double spend and the double spend will be relayed by everyone
49 2014-02-22 05:23:57 <davvblack> specifically to facilitate increasing mining fees without waiting for everyone to forget about the initial transaction
50 2014-02-22 05:26:01 <uiop> i think that it's impossible (currently) to ever be able to "forget" about a transaction, since if someone ever manages to mine it it's "good"
51 2014-02-22 05:26:19 <davvblack> yeah, it's ok for the transaction to stay valid
52 2014-02-22 05:26:39 <davvblack> because im deliberately trying to double spend it
53 2014-02-22 05:26:39 <davvblack> i just want people to RELAY it, which they would be unwilling to do while it's still int he pool
54 2014-02-22 05:27:04 <davvblack> basically, i want send a transaction from A->B with a fee of 0 and a ttl of 30 minutes
55 2014-02-22 05:27:39 <davvblack> after that time, it still might be mined, which is fine, but also, i could publish a new transaction from A->B with .0001 fee that will actually be picked up
56 2014-02-22 05:27:39 <davvblack> and the nodes will be willing to relay it because the ttl has passed
57 2014-02-22 05:27:55 <uiop> err, my comment was slightly misguided but still is correct-ish
58 2014-02-22 05:28:22 <davvblack> yeah, it was correct, but not a counterpoint to what i was saying
59 2014-02-22 05:28:30 <uiop> davvblack: yeah, i hear what you're going for
60 2014-02-22 05:29:36 <uiop> off the top of my head, it seems like such a scheme would need it worked into the transaction-validity-test (as computed by miners) a test if this ttl has expired
61 2014-02-22 05:29:52 <davvblack> I think it only needs to be put into the relay code
62 2014-02-22 05:29:59 <davvblack> and wouldn't need to be a hard fork
63 2014-02-22 05:30:04 <davvblack> it's fine if both transactions stay mineable
64 2014-02-22 05:30:05 <uiop> but, is there any way to tell at what time a transaction was issued?
65 2014-02-22 05:30:12 <davvblack> yeah, iirc?
66 2014-02-22 05:31:10 <uiop> what if someone lies? (i.e., is it protected by crypto? what if the issuing computer's clock is skewed? on purpose? etc?)
67 2014-02-22 05:31:24 <davvblack> all good questions
68 2014-02-22 05:32:00 <uiop> kerberos (the protocol) has all kind of problems with clock skew
69 2014-02-22 05:32:12 <uiop> (misc somewhat-relevant remark)
70 2014-02-22 05:32:15 <davvblack> bitcoin is already weak to that iirc
71 2014-02-22 05:32:26 <davvblack> if miners clocks vary by more than 2 hrs they will hard fork
72 2014-02-22 05:32:51 <uiop> kerberos is sensitive within 5 minutes iirc
73 2014-02-22 05:34:10 <robonerd> i'm sensitive all day
74 2014-02-22 05:34:24 <robonerd> ACTION rubs his body
75 2014-02-22 05:37:18 <uiop> robonerd: perhaps ntp desensitizing lotion is in order
76 2014-02-22 05:37:38 <robonerd> no need, i run freebsd and keep it updated
77 2014-02-22 05:37:42 <robonerd> ACTION rubs on
78 2014-02-22 06:33:56 <phillipsjk> looks like FreeBSD uses a log rotator called "newsyslog"
79 2014-02-22 07:50:51 <dansmith_btc> HI, can bitcoind's sendrawtransaction send any arbitrary tx, or is there a limitation like e.g the rawtx inputs must be present in utxo?
80 2014-02-22 07:54:23 <wumpus> dansmith_btc: you can only use it to send transactions that are accepted by the mempool
81 2014-02-22 07:54:47 <wumpus> so AFAIK yes that means the inputs have to be in the utxo set or mempool
82 2014-02-22 07:55:42 <dansmith_btc> wumpus, so if I run bitcoind in an unsynced offline mode, there is no utxo and mempool, and hence I can't do sendrawtransaction, right?
83 2014-02-22 07:56:00 <wumpus> hmm I'm not sure
84 2014-02-22 07:56:32 <wumpus> there is also the orphans map, to be honest I don't know exactly the mechanism there, and whether sendrawtransaction will put your transaction there
85 2014-02-22 08:01:54 <wumpus> but orphans don't get relayed, they just get stored
86 2014-02-22 08:02:25 <wumpus> but I checked: sendrawtransaction will raise an error without relaying your transaction if AcceptToMemoryPool fails, it will not even bother with orphan(missing input) txes
87 2014-02-22 08:41:05 <sipa> wumpus: i recently filed a bug to male sendrawtransaction reporting better
88 2014-02-22 09:16:09 <wumpus> yes it should at least return some reject reason
89 2014-02-22 11:26:32 <jupiterfunk> Hi. Which transaction types are included in Bitcoin RPC call: listunspent ?
90 2014-02-22 11:28:55 <sipa> jupiterfunk: it lists the unspent transaction _outputs_ your wallet has
91 2014-02-22 11:29:38 <jupiterfunk> sipa, outputs from which transaction types besides pay-to-pubkey-hash and pay-to-pub-key ?
92 2014-02-22 11:29:45 <vrs> anyone using armory in here? (#armory is basically empty)
93 2014-02-22 11:30:02 <vrs> it's been stuck at "building databases: 17%" for hours
94 2014-02-22 11:30:26 <sipa> jupiterfunk: anything paid to an address your wallet created
95 2014-02-22 11:30:40 <sipa> jupiterfunk: which can include multisig, if you own all keys
96 2014-02-22 11:31:16 <sipa> vrs: ask etotheipi_
97 2014-02-22 11:31:30 <vrs> etotheipi_: see above
98 2014-02-22 11:32:28 <vrs> version is 0.90-beta
99 2014-02-22 11:33:56 <vrs> or no, actually git
100 2014-02-22 11:56:35 <_syslog> https://bitcointalk.org/index.php?topic=481620.0
101 2014-02-22 12:11:59 <jonyesa> hi!, im experimenting with cryptos and id like to know what this code in main.cpp will do int64 nSubsidy = 200 * COIN; if(nHeight == 10) { nSubsidy = 10000 * COIN; }
102 2014-02-22 12:12:57 <jonyesa> will the rewards always be 200 and in the tenth block 10000?
103 2014-02-22 12:37:24 <chavenorbos> How do I reset my bitcoin testing account? Or wipe all my ACCOUNTS.
104 2014-02-22 12:38:04 <_syslog> remove wallet.dat
105 2014-02-22 12:38:21 <_syslog> you cannot delete address. only rename accounts.
106 2014-02-22 12:38:26 <Whoop> please transfer your coins to someone else prior, test coins need to be mined like real ones also - waste if you're just going to delete them
107 2014-02-22 12:40:37 <chavenorbos> @Whoop where do you want me to send the coins?
108 2014-02-22 12:41:22 <chavenorbos> @_syslog does the wallet.dat include my real coins as well?
109 2014-02-22 12:41:36 <davout> hey
110 2014-02-22 12:41:36 <Whoop> http://tpfaucet.appspot.com
111 2014-02-22 12:41:41 <davout> quick question about locktime
112 2014-02-22 12:41:57 <Whoop> chavenorbos: 1DRnurMWfTWXL9oG8iVED8r6qubqPKw7Vj per that link
113 2014-02-22 12:42:01 <chavenorbos> @_syslog when I create a new ADDRESS after removing the .dat file will it recreate.
114 2014-02-22 12:42:26 <Whoop> urh mimoZNLcP2rrMRgdeX5PSnR7AjCqQveZZ4 rather sorry
115 2014-02-22 12:42:27 <davout> what happens if a miner includes a transaction into a mined block despite lock time saying it can't be included before another year or so? does the block get rejected by other miners ?
116 2014-02-22 12:42:44 <chavenorbos> @Whoop - Do I need to wait for the transaction to CONFIRM before nuking the account?
117 2014-02-22 12:42:53 <chavenorbos> @Whoop - Do I need to wait for the transaction to CONFIRM before nuking the ACCOUNT = DAT FILE.
118 2014-02-22 12:42:57 <davout> or will other miners not care about that and consider the block valid anyway ?
119 2014-02-22 12:43:51 <Whoop> Should be fine to just delete without waiting for >1 confirmation
120 2014-02-22 12:44:01 <chavenorbos> @Whoop they are sent away.
121 2014-02-22 12:44:20 <Whoop> thanks
122 2014-02-22 12:44:28 <chavenorbos> @Whoop are the real coins and the test coins saved in the same wallet.dat file?
123 2014-02-22 12:47:52 <chavenorbos> X last question the wallet.dat is in the testnet3.
124 2014-02-22 13:43:45 <Jere_Jones> Is bitcoind pronounced "bitcoin-dee" or "bitcoin'd"? Or maybe some other way?
125 2014-02-22 13:44:47 <jakov> i usually say dee because its a daemon like sshd httpd
126 2014-02-22 13:44:55 <sipa> i say bitcoin-dee
127 2014-02-22 13:45:07 <Jere_Jones> Cool. Thanks.
128 2014-02-22 13:49:11 <bitblender> :)
129 2014-02-22 13:52:16 <davout> what happens if a miner includes a transaction into a mined block despite lock time saying it can't be included before another year or so? does the block get rejected by other miners ?
130 2014-02-22 13:52:21 <davout> or will other miners not care about that and consider the block valid anyway ?
131 2014-02-22 13:56:41 <gpmnlxdw> how to create a raw transaction to spend from multi input transaction? Must I append redeemScript for each tx?
132 2014-02-22 13:57:00 <gpmnlxdw>
133 2014-02-22 13:58:09 <gpmnlxdw> if it just spend one transaction, I know it should like previous, but how about spend two or more? to repeat the same scriptPubKey and redeemScript consequently?
134 2014-02-22 14:04:28 <sipa> davout: then that block is invalid
135 2014-02-22 14:04:37 <sipa> davec: and no full node will accept it
136 2014-02-22 15:01:11 <vrs> developers, please make your clients more crash resistant because rescanning >10GB of data overheats some people's hardware
137 2014-02-22 15:01:11 <vrs> unrelated to freenode instability, ffffffuuuuuuu
138 2014-02-22 15:02:00 <vrs> crash resistant as in, if anything crashes during a large indexing operation, don't require me to do a full rescan >_>
139 2014-02-22 15:03:21 <Luke-Jr> wumpus: is this disdain for C99 simply because the project is C++?