1 2017-12-25 02:41:29	0|medo|hi i want to be miner
  2 2017-12-25 02:41:33	0|medo|??
  3 2017-12-25 02:42:24	0|Randolf|medo:  You should ask in the #bitcoin channel then.
  4 2017-12-25 02:43:06	0|medo|yes
  5 2017-12-25 02:44:49	0|medo|can you help me to be a miner please
  6 2017-12-25 02:44:52	0|medo|!!
  7 2017-12-25 02:44:53	0|gribble|Error: "!" is not a valid command.
  8 2017-12-25 02:45:08	0|medo|?
  9 2017-12-25 03:00:15	0|Randolf|medo:  The topic you're raising is off-topic here.  Please ask in the #bitcoin channel instead.
 10 2017-12-25 04:17:52	0|goatpig|the multi byte op pushdata, are they big or little endian?
 11 2017-12-25 05:10:18	0|achow101|goatpig: little endian
 12 2017-12-25 05:14:50	0|goatpig|figured it out, thanks
 13 2017-12-25 09:57:34	0|akash_|i am expert in giving suggestion how to stop frauds in bitcoin transaction
 14 2017-12-25 13:24:10	0|ZiNC|Hi.
 15 2017-12-25 13:31:08	0|ZiNC|Are there debug symbols available for download?
 16 2017-12-25 14:24:12	0|Anant|help
 17 2017-12-25 14:24:38	0|Anant|how to exchange bitcoin with other coins?
 18 2017-12-25 14:25:01	0|Anant|earn exchange fees?
 19 2017-12-25 14:26:30	0|sipa|Anant: #bitcoin
 20 2017-12-25 22:02:29	0|LucasMZanella_|Why we must reference the entire txid on a transaction? Could somebody give a feedback on this idea of mine? https://bitcoin.stackexchange.com/questions/66464/why-we-must-reference-the-entire-txid-for-each-output-we-want-to-spend
 21 2017-12-25 22:09:59	0|goatpig|you are introducing some serious complexity and attack vectors with that kind of approach
 22 2017-12-25 22:13:36	0|bitcoin-git|[13bitcoin] 15blockcash opened pull request #12022: test (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/12022
 23 2017-12-25 22:16:31	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #12022: test (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/12022
 24 2017-12-25 22:18:12	0|LucasMZanella_|The only attack I can think of is someone 'mining' a transaction until its txid has the same first digits as another. However there's a minimum number of digits that we can choose that would guarantee a million year of brute forcing
 25 2017-12-25 22:19:47	0|goatpig|not with segwit
 26 2017-12-25 22:20:17	0|sipa|LucasMZanella_: you'd need at least 128 bits
 27 2017-12-25 22:20:35	0|LucasMZanella_|What is different with segwit?
 28 2017-12-25 22:20:39	0|sipa|otherwise the security of referencing old transactions would be below that of the digital signatures
 29 2017-12-25 22:20:50	0|goatpig|the outpoint is taking the wtxid instead of the txid
 30 2017-12-25 22:20:51	0|sipa|so you can probabbly save 16 bytes per txin
 31 2017-12-25 22:20:53	0|goatpig|the wtxid has no sig in it
 32 2017-12-25 22:20:58	0|LucasMZanella_|128 bits is already good, isn't it?
 33 2017-12-25 22:20:59	0|goatpig|therefor it's easy to "mine" a collision
 34 2017-12-25 22:21:07	0|sipa|goatpig: no, txid
 35 2017-12-25 22:21:35	0|goatpig|hmm am i getting confused here?
 36 2017-12-25 22:21:38	0|sipa|yes
 37 2017-12-25 22:21:48	0|sipa|wtxid = inclides witness, txid = no witness
 38 2017-12-25 22:21:52	0|goatpig|oh ok
 39 2017-12-25 22:21:55	0|goatpig|well anyways
 40 2017-12-25 22:22:08	0|sipa|it's also irrelevant in this discussion
 41 2017-12-25 22:22:10	0|goatpig|sw refers to outpoints by the unmalleable id
 42 2017-12-25 22:22:32	0|goatpig|well it's entirely easier to produce collision the txid than the wtxid
 43 2017-12-25 22:22:38	0|goatpig|but sure, that's orhtogonal
 44 2017-12-25 22:22:44	0|sipa|LucasMZanella_: yes, perhaps. it's not worth the effort to change it though
 45 2017-12-25 22:23:21	0|goatpig|you could construct attacks where you force tons of unnecessary hashing per tx
 46 2017-12-25 22:23:34	0|sipa|no
 47 2017-12-25 22:23:59	0|sipa|hmm, nevermind
 48 2017-12-25 22:24:05	0|sipa|you need collision resistance
 49 2017-12-25 22:24:24	0|sipa|goatpig: you're right
 50 2017-12-25 22:24:50	0|goatpig|yeah which has you increase the size of your hash "shortcuts" and kills the size benefit anyways
 51 2017-12-25 22:24:52	0|sipa|LucasMZanella_: disregard what i said; you really need 256-bit hashes in transactions
 52 2017-12-25 22:25:02	0|goatpig|while increasing the cost size of low input tx
 53 2017-12-25 22:25:05	0|LucasMZanella_|How much hashes we need to get a sha256 output to begin with 7 chosen digits?
 54 2017-12-25 22:25:13	0|goatpig|look at miners
 55 2017-12-25 22:25:25	0|sipa|LucasMZanella_: for a collision attack you only need half
 56 2017-12-25 22:25:49	0|LucasMZanella_|Half of what?
 57 2017-12-25 22:25:52	0|sipa|the attacker may be the one doing the reference, which can refer to a transaction that he did a grinsing on before publishing
 58 2017-12-25 22:25:57	0|goatpig|birthday attack
 59 2017-12-25 22:26:26	0|goatpig|well basically you'd mine lots of tx with the starting 7 bytes in the txid
 60 2017-12-25 22:26:32	0|goatpig|then create one tx spending like 1000 inputs
 61 2017-12-25 22:26:35	0|goatpig|however many you get
 62 2017-12-25 22:26:46	0|goatpig|and use the the first input as your collided hash
 63 2017-12-25 22:26:50	0|goatpig|forcing tons of hashing for no reason
 64 2017-12-25 22:26:59	0|goatpig|then to reproduce the attack
 65 2017-12-25 22:26:59	0|sipa|goatpig: it's far worse
 66 2017-12-25 22:27:06	0|sipa|you can create a consensus failure
 67 2017-12-25 22:27:25	0|goatpig|ive thought of that but cant come with an example of that attack on the top of my head
 68 2017-12-25 22:27:35	0|sipa|by creating two transactions with the same starting bits
 69 2017-12-25 22:27:48	0|sipa|and then spending it
 70 2017-12-25 22:28:08	0|sipa|making sure one is valid and the other is invalid
 71 2017-12-25 22:28:27	0|goatpig|you mean while unconfirmed?
 72 2017-12-25 22:28:34	0|sipa|hmm, but the chain provides an ordering of course
 73 2017-12-25 22:28:56	0|goatpig|his proposal is to basically attach a merkle root in there
 74 2017-12-25 22:29:00	0|goatpig|with the "shortcuts"
 75 2017-12-25 22:29:39	0|goatpig|i tihnk that's enough to remain deterministic, therefor avoid consensus failures
 76 2017-12-25 22:29:50	0|goatpig|but it's easily attackable
 77 2017-12-25 22:30:06	0|sipa|fair, it's doable in a way that does not cause consensus failure
 78 2017-12-25 22:30:29	0|goatpig|but there's also the cost of increasing the size of low input tx
 79 2017-12-25 22:30:59	0|goatpig|i guess you could "modulate" this, have tx version that uses this proposal to cut on large tx
 80 2017-12-25 22:31:11	0|goatpig|but even then, taht does not reduce the attack vector
 81 2017-12-25 22:31:41	0|sipa|it's also a terrible hard fork
 82 2017-12-25 22:31:59	0|goatpig|couldnt you softfork that ala segwit?
 83 2017-12-25 22:32:01	0|sipa|(as in: not just miners and nodes, but every piece of software will fail without modification)
 84 2017-12-25 22:32:04	0|sipa|no
 85 2017-12-25 22:32:07	0|goatpig|i guess you can't pull the segwit trick twice
 86 2017-12-25 22:32:07	0|LucasMZanella_|Could be a soft one
 87 2017-12-25 22:32:21	0|sipa|segwit didn't remove any existing structures
 88 2017-12-25 22:32:32	0|sipa|it just added an optional new ones
 89 2017-12-25 22:32:45	0|sipa|truncating txids is not something that fits into that
 90 2017-12-25 22:32:56	0|goatpig|no but (correct me if im wrong) to a not update node, the marker and flag of a segwit tx makes the tx body invisible to the node
 91 2017-12-25 22:33:14	0|sipa|you can't remove the txids without breaking things
 92 2017-12-25 22:33:18	0|LucasMZanella_|Transactions could maintain the structure, but the txid being referenced would be the merkle root. And the 7 digits each would be added inside script
 93 2017-12-25 22:33:47	0|goatpig|at any rate i wouldnt want that kind of change done without a hf
 94 2017-12-25 22:33:47	0|sipa|goatpig: that's just serialization
 95 2017-12-25 22:33:56	0|sipa|i'm not even talking about that
 96 2017-12-25 22:34:20	0|goatpig|sipa: if you can make the content of the tx invisible to older nodes, you can shove anything you want in there basically
 97 2017-12-25 22:34:36	0|sipa|then you don't have any transactions left
 98 2017-12-25 22:34:45	0|sipa|sure, you can move everything to an extension block
 99 2017-12-25 22:34:50	0|sipa|that's always possible
100 2017-12-25 22:35:01	0|sipa|but that doesn't share anything anymore with existing nodes
101 2017-12-25 22:35:19	0|sipa|they wouldn't even see the transactions of the new system anymore
102 2017-12-25 22:36:05	0|LucasMZanella_|Yeah, the old nodes would invalidate the transaction because txid is nonsense
103 2017-12-25 22:36:26	0|goatpig|sipa: a bit too aggressive i guess =D
104 2017-12-25 22:36:31	0|sipa|LucasMZanella_: what is the objective?
105 2017-12-25 22:36:46	0|goatpig|optimize block space usage im guessing
106 2017-12-25 22:37:01	0|sipa|if it's just bandwidth/storage, a new serialization for transaction could be constructed that does what you're saying (and more)
107 2017-12-25 22:37:18	0|sipa|but without actually modifying the transactions
108 2017-12-25 22:37:24	0|sipa|only changing how they're stored
109 2017-12-25 22:37:40	0|sipa|which means that the full txids still count towards the weight limit
110 2017-12-25 22:37:45	0|LucasMZanella_|Objective of what? The idea was to be able to spend from lots of txs without having to add one signature + one txid for each. My idea would reduce txid usage in transactions, and schnoor would reduce signature usage
111 2017-12-25 22:37:58	0|sipa|but still reclaim disk space and bandwidth
112 2017-12-25 22:38:11	0|sipa|in a completely optional and compatible way
113 2017-12-25 22:39:31	0|goatpig|in taht spirit, could there be an alley to use block height + tx# instead of hash for old, buried outputs in the future?
114 2017-12-25 22:39:40	0|sipa|monero uses a pretty extreme version of what you're suggesting iirc; they refer to previous outputs just using the position in the chain when they were created
115 2017-12-25 22:40:22	0|sipa|goatpig: requires a nasty index, unfortunately
116 2017-12-25 22:40:25	0|sipa|but yes
117 2017-12-25 22:41:33	0|goatpig|sipa: index for what purpose? ordering tx per block height? i mean you konw that height won't change if we're talkign blocks with 100k+ confs
118 2017-12-25 22:41:56	0|LucasMZanella_|If you use new addresses everytime someone is going to send you something, then moving a large quantity of your funds is going to take a lot of txids and signatures. Schnoor already condenses signs, my idea was to condense txids
119 2017-12-25 22:42:00	0|bitcoin-git|[13bitcoin] 15janstary opened pull request #12023: update the OpenBSD build guide (06master...06openbsd) 02https://github.com/bitcoin/bitcoin/pull/12023
120 2017-12-25 22:43:27	0|LucasMZanella_|I thought this could be done with a soft fork but now I don't know anymore. I guess old nodes would always miss transactions
121 2017-12-25 22:43:42	0|LucasMZanella_|as you said :)
122 2017-12-25 22:43:53	0|goatpig|LucasMZanella_: you'd have to make the tx body invisible to old nodes
123 2017-12-25 22:43:56	0|goatpig|that's too extreme
124 2017-12-25 22:46:17	0|LucasMZanella_|I thought as using an entire txid and add the merkle root + other txids inside the script, but old nodes would not accept txids inside the script
125 2017-12-25 22:46:38	0|LucasMZanella_|I guess it can only be done with a hardfork by changing the transaction format version
126 2017-12-25 22:46:57	0|goatpig|whichever way you do it, you are introducing computational overhead that is exploitable
127 2017-12-25 22:47:51	0|LucasMZanella_|Yes, but we could make the required n digits vary according to the block difficulty
128 2017-12-25 22:48:30	0|LucasMZanella_|If a person is able to exploit the n digits then he would be able to mine 51% or something like that
129 2017-12-25 22:49:43	0|goatpig|sure but you to consider that it would then proportionally increase the size of tx with less inputs
130 2017-12-25 22:50:02	0|goatpig|cause you are always carrying at least 32 bytes worth of merkle + compressed ids
131 2017-12-25 22:50:05	0|LucasMZanella_|Why it would increase?
132 2017-12-25 22:50:16	0|goatpig|in your current proposal
133 2017-12-25 22:50:23	0|goatpig|a single input tx is already larger
134 2017-12-25 22:50:40	0|goatpig|cause it needs a merkle + 7bytes for 1 compressed id
135 2017-12-25 22:50:41	0|LucasMZanella_|The merkle root would substitute the txid at all in the new transaction format
136 2017-12-25 22:51:05	0|LucasMZanella_|If there is only one input, the merkle root would match the txid being referenced
137 2017-12-25 22:51:07	0|goatpig|you need an id per output + the merkle
138 2017-12-25 22:51:26	0|goatpig|yes but as soon as you hit over 128bits compressed ids
139 2017-12-25 22:51:47	0|goatpig|now 2 inputs tx are larger than the legacy outpoints
140 2017-12-25 22:53:22	0|LucasMZanella_|Can't follow your thinking, I'm confused
141 2017-12-25 22:53:35	0|goatpig|you need the merkle root per tx
142 2017-12-25 22:53:38	0|goatpig|+ 1 id per input
143 2017-12-25 22:53:47	0|goatpig|if your ids are 129bits
144 2017-12-25 22:54:15	0|goatpig|your 2 input tx is now 258bits of outpoints + 256bit of merkle
145 2017-12-25 22:54:36	0|goatpig|currently a 2 inputs is 256x2 bits of outpoints
146 2017-12-25 22:54:49	0|goatpig|not including the outpoint id in there cause it's constant accross models
147 2017-12-25 22:54:56	0|LucasMZanella_|Then for that case the person could use the old transaction format
148 2017-12-25 22:55:34	0|goatpig|now you have discussion of whether that's desirable at all
149 2017-12-25 22:55:41	0|goatpig|having 2 models that overlap
150 2017-12-25 22:56:03	0|LucasMZanella_|Wouldn't the model be inneficient just for 2 inputs?
151 2017-12-25 22:56:18	0|goatpig|it would be inneficient generally for low input tx
152 2017-12-25 22:56:24	0|goatpig|but there's a debate to be had
153 2017-12-25 22:56:39	0|LucasMZanella_|I don't think there's a problem in using 2 different transaction formats
154 2017-12-25 22:56:46	0|goatpig|of how desirable such a massive change (hf and all) is when you compare the complexity to implement and operate vs the benefit
155 2017-12-25 22:57:09	0|goatpig|i have not thought about whether that is a problem or not
156 2017-12-25 22:57:19	0|goatpig|but i'd rather err on the side of caution and not introduce complexity
157 2017-12-25 22:57:20	0|LucasMZanella_|Yes, but if we're going to ever hard fork for some other reason, this could be included
158 2017-12-25 22:58:08	0|LucasMZanella_|I agree with you, but the benefits are huge. Coinjoin, being able to still use one address per transaction, and less fees (the greatest problem)
159 2017-12-25 22:58:21	0|goatpig|if it can demonstrated that it is safe
160 2017-12-25 22:58:31	0|goatpig|and fees arent a problem that needs to be addressed at consensus level
161 2017-12-25 22:58:38	0|goatpig|if they are a problem at all (i dont believe they are)