1 2015-04-19 02:36:36 <rolandnsharp> Hi everyone, I'm a developer trying to work my way through implementing bitcoin wallets and transactions into my node.js app. I'm using 'bitcore', which has great documentation, but no instructional steps on getting set up.
2 2015-04-19 02:37:37 <rolandnsharp> I'm trying to build a reddit clone that will use bitcoin in replacement of karma.
3 2015-04-19 02:38:23 <rolandnsharp> This is my attempt at creating a wallet when a new user is created: https://github.com/rolandnsharp/bitcoin-reddit/blob/master/lib/users/model/middleware/pre-save.js
4 2015-04-19 02:39:56 <rolandnsharp> I just have no idea where I go from here in terms of connecting to a network and getting bitcoin associated with these keys.
5 2015-04-19 02:57:03 <gmaxwell> https://bitcointalk.org/index.php?topic=1029528.new#new
6 2015-04-19 02:57:04 <gmaxwell> src/qt/locale/bitcoin_da.ts: <translation>En besked, som blev føjet til "bitcon:"-URI'en, som vil gemmes med transaktionen til din reference. Bemærk: Denne besked vil ikke blive sendt over Bitcoin-netværket.</translation>
7 2015-04-19 02:57:13 <gmaxwell> bitcoin ... kinda unfortunate. :P
8 2015-04-19 10:59:56 <Luke-Jr> sipa: thanks, I guess I wasn't very clear on that
9 2015-04-19 17:21:55 <denisx> what was the projectname of matt corallos network for faster bitcoin communication?
10 2015-04-19 17:26:07 <gmaxwell> block relay network.
11 2015-04-19 17:26:40 <gmaxwell> denisx: https://bitcointalk.org/index.php?topic=766190.0
12 2015-04-19 17:27:02 <denisx> gmaxwell: thanks
13 2015-04-19 18:59:25 <aschildbach> I wonder how the floating fee evolved since 0.10 was released. I have a tx here that should be confirmed for a long time, but it isn't: https://www.biteasy.com/blockchain/transactions/d41fc36da1ca0baef1dfaee461930506fcb26995b14f4d9b71a633f721be103c
14 2015-04-19 18:59:57 <aschildbach> It's only 500 bytes, all outputs are well above dust and the standard 0.01 mBTC fee was paid.
15 2015-04-19 19:01:35 <s7r> aschildbach floating fee?
16 2015-04-19 19:01:46 <aschildbach> yes
17 2015-04-19 19:03:12 <s7r> dunno what that is
18 2015-04-19 19:03:31 <s7r> anyway, your tx is to be confirmed very soon
19 2015-04-19 19:03:50 <s7r> https://blockchain.info/tx/d41fc36da1ca0baef1dfaee461930506fcb26995b14f4d9b71a633f721be103c
20 2015-04-19 19:04:21 <aschildbach> Yes I see the priority is high. But it has been received by bc.i 6 hours ago...
21 2015-04-19 19:05:08 <aschildbach> s7r: Floating fees were introduced with 0.10 afaik.
22 2015-04-19 19:05:40 <aschildbach> It has a statistics about what fee was paid and adapts the fee for own transactions to the median (I guess).
23 2015-04-19 19:06:28 <s7r> you have 20.184904 BTC and 9 BTC
24 2015-04-19 19:06:35 <s7r> the 20.184904 BTC says it's already spent
25 2015-04-19 19:08:27 <s7r> there is something wrong with your tx
26 2015-04-19 19:08:34 <s7r> it's a double spend somewhere.
27 2015-04-19 19:09:10 <s7r> https://blockchain.info/address/1HH2gsupMSkKyf4txWmrbRv7hYFuWU3FWp
28 2015-04-19 19:09:35 <aschildbach> s7r: I don't think so. Note its an output that is spent, not an input.
29 2015-04-19 19:09:57 <aschildbach> Unconfirmed transactions can be chained to unconfirmed transactions.
30 2015-04-19 19:10:53 <s7r> I don't see other problem then, I was able to get a lot of txes with even lower value than yours for 0.00001 fee, in relatively 15 - 20 minutes
31 2015-04-19 19:11:38 <aschildbach> Yeah its strange. It should be confirmed within 1-3 blocks.
32 2015-04-19 19:17:05 <aschildbach> It's now confirmed
33 2015-04-19 19:29:28 <JWU42> aschildbach: confirmed now
34 2015-04-19 19:29:31 <JWU42> whoops
35 2015-04-19 19:29:37 <aschildbach> yes
36 2015-04-19 19:29:49 <aschildbach> JWU42: Still I wonder what took so long
37 2015-04-19 19:29:49 <JWU42> https://www.blocktrail.com/BTC/tx/d41fc36da1ca0baef1dfaee461930506fcb26995b14f4d9b71a633f721be103c
38 2015-04-19 19:30:06 <JWU42> the fee
39 2015-04-19 19:30:34 <aschildbach> Ok -- why was is not high enough?
40 2015-04-19 19:30:36 <JWU42> I use a lower fee too - like .00001 per K
41 2015-04-19 19:30:49 <JWU42> sometimes I wait 2-4 blocks
42 2015-04-19 19:31:30 <JWU42> wouldn't have expected you waiting almost 4 hours
43 2015-04-19 19:32:13 <aschildbach> I suspect the floating fee.
44 2015-04-19 19:32:41 <JWU42> me too
45 2015-04-19 19:32:47 <JWU42> Breadwallet uses it as well
46 2015-04-19 19:33:09 <aschildbach> Breadwallet uses 0.00001 per K?
47 2015-04-19 19:33:19 <JWU42> something like that
48 2015-04-19 19:33:20 <aschildbach> Or you mean it adapts to the floating fee?
49 2015-04-19 19:33:23 <aschildbach> ok
50 2015-04-19 19:33:41 <JWU42> it floats but the baseline starts at 0.00001
51 2015-04-19 19:33:49 <JWU42> from what i have seen
52 2015-04-19 21:45:14 <CodeShark> is there any OP code in the script complementary to OP_RETURN that marks the transaction as valid and exits?
53 2015-04-19 21:45:34 <gmaxwell> Thats what OP_RETURN was for.
54 2015-04-19 21:45:45 <CodeShark> but I thought OP_RETURN marks it as invalid
55 2015-04-19 21:45:51 <gmaxwell> It does not.
56 2015-04-19 21:46:11 <gmaxwell> It's turns out that it's pretty bad to return true in a scriptSig.
57 2015-04-19 21:46:15 <gmaxwell> er GAH
58 2015-04-19 21:46:21 <gmaxwell> IT DOES _NOW_ not not.
59 2015-04-19 21:46:45 <CodeShark> there are many instances where it seems being able to return true would be highly convenient
60 2015-04-19 21:46:55 <CodeShark> i.e. using a counter
61 2015-04-19 21:47:49 <CodeShark> push n onto the stack, then conditionally decrement it at points in the rest of the script - return true if it ever hits 0
62 2015-04-19 21:48:42 <CodeShark> why is it so bad to return true?
63 2015-04-19 21:49:56 <CodeShark> unless we return true in this example, we'll have to nest a bunch of OP_IFs, which is more convoluted and makes for a longer script
64 2015-04-19 21:51:29 <CodeShark> avoiding the nesting means we can concatenate clauses easily in our compiler
65 2015-04-19 21:51:46 <gmaxwell> CodeShark: because then I go find all your script pubkeys and sign for them with RETURN_TRUE;
66 2015-04-19 21:53:03 <CodeShark> hmm...but using p2sh fixes that :)
67 2015-04-19 21:53:46 <CodeShark> so it's only bad due to an initially poor design
68 2015-04-19 21:54:39 <gmaxwell> CodeShark: no it doesn't.
69 2015-04-19 21:54:56 <CodeShark> no?
70 2015-04-19 21:55:40 <gmaxwell> You'd have to special case disable the opcode until the scriptPubkey starts executing; nothing less fixes that.
71 2015-04-19 21:57:13 <CodeShark> if every scriptSig was in the format {signatures}{redeemscript} and every scriptPubKey was in the form OP_HASH160 <address> OP_EQUAL (or better yet, just have two forms for the scriptPubKey - either p2sh and only encode a script hash...or arbirary data and immediately return false)
72 2015-04-19 21:57:35 <CodeShark> I think that would cover all conceivable use cases and would be far more elegant :)
73 2015-04-19 21:58:50 <CodeShark> I propose we soft-fork once enough people are already using p2sh
74 2015-04-19 21:59:27 <gmaxwell> Preventing anything but pushes is a superset of disabling an opcode, sure. Though it does mean that cases where you could a more compact signature by computing something on the fly in it would be excluded. (or where you want to get data that you can't just get by pushing)
75 2015-04-19 22:00:06 <gmaxwell> Never going to happen; that would effectively confiscate coins from users; last time I proposed softforking out old scriptpubkey kinds I got death threats.
76 2015-04-19 22:00:46 <CodeShark> we would add a rule that the transaction version of the output would have to be greater than x
77 2015-04-19 22:01:03 <CodeShark> otherwise, revert to the way we do things now
78 2015-04-19 22:01:45 <gmaxwell> Then you're stuck forever carrying the same code in any case, so nothing saved just more complexity. (and crap like people destroying coins accidentally because they used a version too high for the recipents scriptpubkey)
79 2015-04-19 22:02:20 <CodeShark> it adds a little more complexity to the consensus code...but it affords a significant amount of expressive power in the scripting language and promotes a far cleaner invoicing mechanism
80 2015-04-19 22:03:19 <gmaxwell> I think you're conflating all sorts of things; prohibiting old kinds of scriptpubkeys/signatures does nothing to add expressive power or help invoices.
81 2015-04-19 22:03:34 <CodeShark> it affords an op code that returns true and exits
82 2015-04-19 22:04:10 <CodeShark> imagine if you never could do return true; in C++
83 2015-04-19 22:04:36 <gmaxwell> It doesn't. There is no softwork way to add such a thing except via nesting a new scripting system (like p2sh did); and when we do that a RETURN_TRUE would be too small a change to even bother mentioning.
84 2015-04-19 22:04:36 <s7r> I see in BIP62 few known ways to perform tx malleability (change the txid without invalidating it). can we predict how many mutations a txid can have? like create a table of all possible txids of a tx? if the total number is a reasonable number, like > 10.
85 2015-04-19 22:05:05 <gmaxwell> CodeShark: I don't have to imagine, MISRA C forbids multiple return statements in a function.
86 2015-04-19 22:05:22 <gmaxwell> s7r: no, its almost infinite.
87 2015-04-19 22:05:39 <CodeShark> gmaxwell: there's a good reason that constraint was removed in descendent languages
88 2015-04-19 22:05:58 <s7r> thank you gmaxwell. will cut it from the list ;) sorry for jumping in thanks
89 2015-04-19 22:06:22 <gmaxwell> CodeShark: MISRA C is an industrial standard for safe coding. There is substantial evidence that multiple returns lead to software defects.
90 2015-04-19 22:07:04 <gmaxwell> (I agree that its useful for script composition, but supporting a system that reasonable does composition takes a lot more than that.)
91 2015-04-19 22:08:33 <gmaxwell> (supporting composition safely and efficiently is one of the main objectives of Sipa's MAST work)
92 2015-04-19 22:08:58 <CodeShark> I'm not saying it's all trivial to do - but we DO need a better script, methinks, if we ever want to really go beyond the most elemental authorization conditions for transactions. Perhaps this will be one of the most important things that sidechains will be able to accomplish
93 2015-04-19 22:10:25 <CodeShark> I feel the original satoshi script added a huge amount of complexity to the consensus code without really providing great power and expressivity...so it would have been far better to have a far simpler script and a mechanism for updating it or replacing it later without hardforking :)
94 2015-04-19 22:11:23 <gmaxwell> Sure. Sipa has been working on a design where at the top level every script is a monotone boolean circuit over a hashtree of predicates. Part of the goal is so that you can always safely compose scripts, and do threshold signatures with other pariticpants whos scripts you dont' understand yourself.
95 2015-04-19 22:11:58 <gmaxwell> If it had been any simplier it probably also would have not been upgradable. Its clear today how to do that, but this wasn't obvious 5 years ago.
96 2015-04-19 22:13:21 <CodeShark> well, it was obvious that no matter how good a script we tried to create initially would be replaced later on by a more advanced one - and the script wasn't really essentially to the PoW blockchain proof-of-concept implementation
97 2015-04-19 22:13:59 <CodeShark> the scripting stuff should probably be done by people who are real experts in VM, language, and compiler design
98 2015-04-19 22:14:42 <gmaxwell> I don't think that was quite so obvious. Actually the belief by many for a long time was that there would only be one shot, and anything that didn't make it in couldn't be added later; because an ability to modify the system meant the security model failed; but this was all before there was a clear understanding of softforks.
99 2015-04-19 22:15:53 <CodeShark> a one-shot deal would be doomed to failure sooner-or-later since a better protocol that benefits from hindsight would later emerge with such superior features that even the network effect wouldn't be able to save the older one
100 2015-04-19 22:16:19 <gmaxwell> The requirements for script are unlike ordinary language requirements; e.g. most programs aren't pure functions computing boolean predicates which hard mission critical requirements on identical operation, or a requirement that the use be able to be absolutely confident about all aspects of the operation. Most languages have features which make it impossible to reason about the properties of most pro
101 2015-04-19 22:16:25 <gmaxwell> grams in them.
102 2015-04-19 22:16:43 <CodeShark> yes, it's not a trivial problem
103 2015-04-19 22:16:54 <CodeShark> more the reason to defer commitment on it
104 2015-04-19 22:16:58 <gmaxwell> CodeShark: I'm not arguing that, I'm just explaining that what you're saying was 'obvious' wasn't! :)
105 2015-04-19 22:17:24 <gmaxwell> Also without the first system I don't know that we'd ever be able to add one, even given soft forks because then it would be "that obviously doesn't belong in the system".
106 2015-04-19 22:17:49 <CodeShark> those are good points - we do have the benefit of hindsight
107 2015-04-19 22:18:01 <CodeShark> and a stronger argument for these ideas now
108 2015-04-19 22:18:13 <gmaxwell> "Can't you see: the field is called _PUBKEY_ you cannot put a script in there!" :)
109 2015-04-19 22:18:23 <CodeShark> lol
110 2015-04-19 22:20:04 <gmaxwell> There are varrious people who've done worse than what Bitcoin has done, even with the benefit of hindsight. :) In any case, sure I expect that there will be a proposed alternative system which has a lot of nice properties within a year. I'm hiring at least one person to work full time on that, in addition to mark and sipa who've already been working on the subject for a long time.
111 2015-04-19 22:22:32 <CodeShark> what subject? better scripts? or how to upgrade/replace the protocol without breaking the network?
112 2015-04-19 22:22:33 <kanzure> a correctness-oriented approach would be nice
113 2015-04-19 22:22:47 <kanzure> CodeShark: well at minimum you could use those in sidechains without breaking the network
114 2015-04-19 22:23:30 <gmaxwell> On better script system stuff, (focused on compactness, provability, composability, and expresiveness)
115 2015-04-19 22:23:52 <CodeShark> when are we going to have OP_SIDECHAINPROOFVERIFY?
116 2015-04-19 22:24:05 <kanzure> i would be in favor of even more limited expressiveness if it could contribute to the other properties
117 2015-04-19 22:24:10 <gmaxwell> When it's ready. :)
118 2015-04-19 22:24:32 <kanzure> (aka "i'd saw off my left leg to fly")
119 2015-04-19 22:24:38 <CodeShark> is there anything I can see regarding progress on it, gmaxwell?
120 2015-04-19 22:24:48 <gmaxwell> kanzure: one of the cool designs we came up with is that by making the top level a monotone function you can strongly reason about the rest even if you can't understand it.
121 2015-04-19 22:26:55 <gmaxwell> (in particular it becomes trivial to safely soft-fork in new features in the predicates; because you just define an unknown predicate type as return true;
122 2015-04-19 22:26:58 <gmaxwell> )
123 2015-04-19 22:27:19 <gmaxwell> It's so much harder to soft fork in bitcoin script because of the existance of negation.
124 2015-04-19 22:28:00 <gmaxwell> which is why all new softfork features need to be in the form of OP_FOOVERIFY or else there is the psycho p2sh like requirement of running the script twice, under old and new rules. :(
125 2015-04-19 22:28:03 <kanzure> also a specification would be a nice thing to do for that sort of work
126 2015-04-19 22:28:10 <gmaxwell> Obviously.
127 2015-04-19 22:28:26 <kanzure> ACTION leers at satoshi
128 2015-04-19 22:28:44 <gmaxwell> Don't assume there wasn't a specification; could just be that it was never given to you. :P
129 2015-04-19 22:42:51 <CodeShark> is there a limit to the level of nesting of OP_IF? or is it just limited by OP count and TX size limits?
130 2015-04-19 23:02:26 <gmaxwell> No limit beyond what you mentioned. (it's just a counter to tell where it is in the stack; it's free for the implementation to go as deep as you like)
131 2015-04-19 23:14:18 <denisx> can someone activate the processrenaming for freebsd, it is working for years now for me I dont want to clone bitcoin only for that small change