1 2017-11-23 12:44:00 <garit> Hi. Few questions about future of bitcoin: when i send small transactions, does it increase the space this coins will need in a blockchain later? Does this increase everyones requirement for space in blockchain? Can collect some btc dust and send it to other person's address and make all his coins unusable(due to extreme fees)?
2 2017-11-23 15:56:58 <cluelessperson> garit: Hi there. Right now bitcoin *is* gaining popularity faster than the technology has developed, but it is coming along. It has just resulted a "fee" market.
3 2017-11-23 15:58:55 <cluelessperson> garit: so transaction fees can be a bit high at times, but still affordable for the most part. Each transaction's data is stored in the blockchain. The typical transaction is ~246 bytes, and no, sending dust to someone doesn't effect their ability to spend.
4 2017-11-23 15:59:41 <cluelessperson> When you spend bitcoin, you actually refer to "inputs" and where to send them. They can easily choose to just not send the dust
5 2017-11-23 18:21:49 <achow101> anyone know what's up with this: https://bitcoin.org/en/posts/bitcoin-knots?
6 2017-11-23 18:22:02 <achow101> luke-jr: do you know (it has to do with knots)
7 2017-11-23 18:31:14 <arubi> interesting. I think it's a good decision
8 2017-11-23 18:31:40 <achow101> arubi: well it was made without any discussion (no PR, no review, etc) and cobra did not sign the commit as is usual practice
9 2017-11-23 18:31:57 <achow101> it was also just reverted
10 2017-11-23 18:32:11 <mlz> probably cobra is being moody again
11 2017-11-23 18:32:12 <arubi> the plot thickens :)
12 2017-11-23 18:32:44 <arubi> fwiw I like knots. been using it for a while and the cutting-edge-ness is nice
13 2017-11-23 18:34:16 <mlz> me too
14 2017-11-23 18:50:17 <buZz> how can i export and import P2WSH addreses?
15 2017-11-23 18:55:52 <arubi> with importaddress, import the script with p2sh set to false
16 2017-11-23 18:56:18 <arubi> but really it's easier to just import all relevant stuff with importmulti and importpubkey
17 2017-11-23 18:56:55 <buZz> how would you prepare an export for importmulti then?
18 2017-11-23 18:57:31 <buZz> oh wait, i see
19 2017-11-23 18:57:34 <buZz> ty :)
20 2017-11-23 18:57:39 <arubi> ah cool :)
21 2017-11-23 19:14:48 <luke-jr> achow101: I'm aware of it to a limited extent. doing thanksgiving stuff now tho..
22 2017-11-23 19:37:28 <garit> cluelessperson: https://charts.bitcoin.com/chart/transaction-size says at 2009 transaction size was about 200B, and now it is about 700B. But this includes the fact of exponential btc growth, that reduces the number of btc needs to be sent
23 2017-11-23 19:39:08 <garit> lets consider this metric: amount of btc that can be sent in one block. initially we would be able to fill the block with 50 btc transactions, later as users would split btc, we would include smaller parts, like 1 btc per source, and later we would send transactions where each source is only a few mBTC
24 2017-11-23 19:39:59 <garit> am i right that such splitting will make each transaction bigger, and would reduce total possible btc transferring capacity of a network?
25 2017-11-23 19:40:44 <arubi> the amount in a transaction is always 8 bytes
26 2017-11-23 19:40:53 <arubi> zero or 21 million btc
27 2017-11-23 19:42:08 <arubi> you just took the absolute minimum at 2009 when folks used bare pubkeys and the redemption would be that ^, but they also had to be paying to a p2pkh script too :)
28 2017-11-23 19:42:16 <arubi> very specific, pretty useless
29 2017-11-23 19:42:50 <arubi> the same tx in p2pkh today is.. 226 bytes I think? segwit makes it a lot smaller
30 2017-11-23 19:43:02 <arubi> well, less weight
31 2017-11-23 19:44:55 <arubi> anyway, dinner. bitcoin.com is a website promoting all sorts of scams, so I wouldn't trust its charts for anything
32 2017-11-23 19:45:51 <garit> arubi: transaction size depends on your source of btc. If you mined them all - you will spend 30B per 50 btc. But if you gained them as 1mBtC pieces, you will spend 30B per 0.001BTC, right?
33 2017-11-23 19:46:31 <garit> https://bitcoin.stackexchange.com/questions/1195/how-to-calculate-transaction-size-before-sending-legacy-non-segwit-p2pkh-p2sh#3011 - about 40 bytes per each transaction input
34 2017-11-23 19:46:43 <arubi> segwit makes it so consolidating two small utxos is as efficient in payment as breaking one to two in non segwit scripts
35 2017-11-23 19:47:32 <arubi> the witness byte's weight being 1/4 of a non witness one is exactly the reason for that ^
36 2017-11-23 19:47:45 <garit> But what are the chances that a person will get the two sequential parts to consolidate them? (they have to have some requirement to be united, right?)
37 2017-11-23 19:48:03 <arubi> no
38 2017-11-23 19:48:08 <arubi> it's just like a normal payment
39 2017-11-23 19:49:24 <garit> so you can get a btc dust in few satoshi per source, unite them all regardless from where they came, and send as one transaction with small requirement to transaction size?
40 2017-11-23 19:50:04 <arubi> yes, the more you consolidate inputs, the larger the effect becomes because you save up on the transaction skeleton bytes too
41 2017-11-23 19:51:23 <garit> This would break the history of this coins, is it like creating a nee coins? Since now all users will point to a nee origin of this coins
42 2017-11-23 19:51:28 <garit> new*
43 2017-11-23 20:29:09 <arubi> garit, no, it's just a normal consolidation of inputs like we've been doing since 2009
44 2017-11-23 20:35:28 <garit> I see, this solves this problem i think. Thanks
45 2017-11-23 20:36:39 <arubi> np
46 2017-11-23 20:36:57 <garit> (I thought by some reason that each coin stores it origin. But if it only stores it last 'place', and origin can be checked by the blockchain, this helps
47 2017-11-23 20:38:33 <arubi> ah, sure. validation and coming up with the valid utxo set is exactly that
48 2017-11-23 20:39:46 <arubi> in the utxo set are coins with the last output still unspent, so if you validated the whole chain up until the last block, then you can just see a new transaction out of the blue and know for sure if it's spending a valid unspent output or not
49 2017-11-23 20:41:19 <garit> so everyone just checks 1 block deep, expecting that people from previous block checked 1 block deep too, and thus everything should be checked
50 2017-11-23 20:42:54 <arubi> no, you check it all for yourself
51 2017-11-23 20:44:10 <arubi> not each time, you just keep track
52 2017-11-23 23:16:57 <firelegend> Hi all. I wanted to legitimately ask what are the future plans of Bitcoin to improve transactions per second and fees?
53 2017-11-23 23:44:59 <garit> firelegend: fees are market controlled, for devs to be able to change them, devs would need to significantly increase the block size, and that's unlikely(it will increase the propagation time of new blocks above the generation time of a new block)
54 2017-11-23 23:46:16 <firelegend> Right, then what about blocks?
55 2017-11-23 23:46:29 <firelegend> More transactions per second(i.e more per block)
56 2017-11-23 23:46:55 <garit> same for transactions per second, it also need an increase of block size . But it cant be easily done
57 2017-11-23 23:47:36 <garit> firelegend: China has about 75% of miners, and china's miners are against the block increase because their internet is slower (that's what i heared)
58 2017-11-23 23:47:49 <firelegend> yeah I dont like that bit there
59 2017-11-23 23:48:04 <firelegend> Ever since I saw the hash rate chart and that big dip
60 2017-11-23 23:48:13 <firelegend> it instilled some unease in me
61 2017-11-23 23:48:57 <firelegend> Has there been any research on compression?
62 2017-11-23 23:49:10 <firelegend> Compress the blocks(this means an overhead) but it saves bandwidth
63 2017-11-23 23:50:06 <garit> firelegend: block are almost like random data, afaik. you cant know in advance even approximately who will send and where and how much, so i doubt it will help
64 2017-11-23 23:50:52 <garit> you can compress only poorly composed data, that is sparse (like text), btc transactions are already quite good (dense, few repeating data)
65 2017-11-23 23:51:00 <firelegend> garit: If chinese miners are opposed to bigger blocks, why did they launch an altcoin? Seems weird behaviour
66 2017-11-23 23:51:34 <garit> probably they arent all the same person and have different opinions, i dont know about altcoin
67 2017-11-23 23:52:28 <firelegend> garit: I was referring to the asic boost version of bitcoin, aka cash
68 2017-11-23 23:53:54 <garit> i dont know about it, sorry