Transcript for #bitcoin-dev 2017/11/23

12:44 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)?
15:56 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.
15:58 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.
15:59 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
18:21 achow101 anyone know what's up with this:
18:22 achow101 luke-jr: do you know (it has to do with knots)
18:31 arubi interesting. I think it's a good decision
18:31 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
18:31 achow101 it was also just reverted
18:32 mlz probably cobra is being moody again
18:32 arubi the plot thickens :)
18:32 arubi fwiw I like knots. been using it for a while and the cutting-edge-ness is nice
18:34 mlz me too
18:50 buZz how can i export and import P2WSH addreses?
18:55 arubi with importaddress, import the script with p2sh set to false
18:56 arubi but really it's easier to just import all relevant stuff with importmulti and importpubkey
18:56 buZz how would you prepare an export for importmulti then?
18:57 buZz oh wait, i see
18:57 buZz ty :)
18:57 arubi ah cool :)
19:14 luke-jr achow101: I'm aware of it to a limited extent. doing thanksgiving stuff now tho..
19:37 garit cluelessperson: 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
19:39 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
19:39 garit am i right that such splitting will make each transaction bigger, and would reduce total possible btc transferring capacity of a network?
19:40 arubi the amount in a transaction is always 8 bytes
19:40 arubi zero or 21 million btc
19:42 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 :)
19:42 arubi very specific, pretty useless
19:42 arubi the same tx in p2pkh today is.. 226 bytes I think? segwit makes it a lot smaller
19:43 arubi well, less weight
19:44 arubi anyway, dinner. is a website promoting all sorts of scams, so I wouldn't trust its charts for anything
19:45 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?
19:46 garit - about 40 bytes per each transaction input
19:46 arubi segwit makes it so consolidating two small utxos is as efficient in payment as breaking one to two in non segwit scripts
19:47 arubi the witness byte's weight being 1/4 of a non witness one is exactly the reason for that ^
19:47 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?)
19:48 arubi no
19:48 arubi it's just like a normal payment
19:49 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?
19:50 arubi yes, the more you consolidate inputs, the larger the effect becomes because you save up on the transaction skeleton bytes too
19:51 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
19:51 garit new*
20:29 arubi garit, no, it's just a normal consolidation of inputs like we've been doing since 2009
20:35 garit I see, this solves this problem i think. Thanks
20:36 arubi np
20:36 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
20:38 arubi ah, sure. validation and coming up with the valid utxo set is exactly that
20:39 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
20:41 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
20:42 arubi no, you check it all for yourself
20:44 arubi not each time, you just keep track
23:16 firelegend Hi all. I wanted to legitimately ask what are the future plans of Bitcoin to improve transactions per second and fees?
23:44 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)
23:46 firelegend Right, then what about blocks?
23:46 firelegend More transactions per second(i.e more per block)
23:46 garit same for transactions per second, it also need an increase of block size . But it cant be easily done
23:47 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)
23:47 firelegend yeah I dont like that bit there
23:48 firelegend Ever since I saw the hash rate chart and that big dip
23:48 firelegend it instilled some unease in me
23:48 firelegend Has there been any research on compression?
23:49 firelegend Compress the blocks(this means an overhead) but it saves bandwidth
23:50 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
23:50 garit you can compress only poorly composed data, that is sparse (like text), btc transactions are already quite good (dense, few repeating data)
23:51 firelegend garit: If chinese miners are opposed to bigger blocks, why did they launch an altcoin? Seems weird behaviour
23:51 garit probably they arent all the same person and have different opinions, i dont know about altcoin
23:52 firelegend garit: I was referring to the asic boost version of bitcoin, aka cash
23:53 garit i dont know about it, sorry