1 2017-11-02 13:39:25 <paulo_> hello
  2 2017-11-02 13:39:40 <paulo_> does the client accept empty (coinbase-only) blocks?
  3 2017-11-02 13:41:09 <arubi> of course
  4 2017-11-02 13:42:10 <arubi> oh ghost43, did you manage eventually?  invalidateblock and reconsiderblock are probably what you want
  5 2017-11-02 13:42:26 <paulo_> I'm a 51% attacker who mines starting from an old block of height N. I mine only empty blocks and catch up with the main chain. Will this cause all transactions from height N to unconfirmed?
  6 2017-11-02 13:42:34 <paulo_> *unconfirm
  7 2017-11-02 13:43:28 <arubi> yes
  8 2017-11-02 13:44:33 <ghost43> arubi: thanks! I've only wanted to do this atm to test a certain behaviour of bitcoind, and ended up reading 2-3 source files instead :D
  9 2017-11-02 13:44:52 <arubi> hehe, I know exactly what you mean :)
 10 2017-11-02 13:45:44 <paulo_> arubi: okay. so let's say the mempool of all clients are full from all the unconfirmed transactions. A few transactions are booted out of the mempool. have I essentially reversed transactions?
 11 2017-11-02 13:46:41 <arubi> why would transactions leave a mempool?  also understand that there is no singular mempool.  each node tracks its own
 12 2017-11-02 13:47:09 <paulo_> arubi: the nodes prioritize transactions by feels when the mempool is full
 13 2017-11-02 13:47:12 <paulo_> *fees
 14 2017-11-02 13:47:54 <ghost43> he's essentially asking that if the local mempool size is 300 MB, and a reorg forces 1000 MB worth of txs out of the best chain, then are several 100 MBs of txs lost for most nodes
 15 2017-11-02 13:48:14 <arubi> any tx that was in a block previously now becomes unconfirmed but is otherwise valid.  unless you also double spend one of the old ones, all txs can get confirmed again
 16 2017-11-02 13:48:32 <arubi> but yes, if an ancestor was lost entirely, I suppose you can say it's also reversed
 17 2017-11-02 13:49:03 <paulo_> okay. there is no limitation as to how old a block I can mine from?
 18 2017-11-02 13:49:23 <arubi> you can mine them all starting from block 1, included
 19 2017-11-02 13:49:31 <arubi> block 0 is genesis and consensus
 20 2017-11-02 13:49:33 <ghost43> paulo_: if even a single node has an enormously large max mempool configured, he can rebroadcast all txs to the whole network
 21 2017-11-02 13:50:39 <paulo_> I can keep extending a side chain if I wanted to?
 22 2017-11-02 13:50:52 <ghost43> no one can stop you from doing that
 23 2017-11-02 13:51:03 <arubi> right, but it's better for your pocket to extend main chain
 24 2017-11-02 13:51:11 <paulo_> and the network will accept this as a side chain?
 25 2017-11-02 13:51:30 <arubi> not unless it's the same length
 26 2017-11-02 13:51:39 <ghost43> the network won't care much, unless you catch up and overtake the best chain
 27 2017-11-02 13:52:18 <ghost43> they won't download your blocks and after some time probably the headers either
 28 2017-11-02 13:53:00 <arubi> (or more) you're competing against difficulty.  headers are enough to know if it's the longest chain or not by difficulty
 29 2017-11-02 13:54:22 <paulo_> "they won't download your blocks and after some time probably the headers either" - at which point, exactly, will the side chain be ignored?
 30 2017-11-02 13:55:26 <arubi> paulo_, you'll be sending the block headers to your peers, and headers are enough to tell the total work done on that chain of blocks
 31 2017-11-02 13:55:46 <arubi> if it's less than the best chain we know about, there's no reason for us to download those blocks past the fork
 32 2017-11-02 14:10:44 <paulo_> so eventually, If I keep mining the side chain, it's difficulty will go lower. and the client will ignore lower difficulty blocks?
 33 2017-11-02 14:13:02 <arubi> they're checking for total work done, it's both length and total work
 34 2017-11-02 14:14:40 <paulo_> I'm trying to understand when it's safe to ignore a side chain, at the same time preventing a network fork.
 35 2017-11-02 14:17:00 <arubi> a node will follow the block it heard about first.  if it hears about another valid one for the current height, it'll just keep it but still follow its current one.  if it hears about a better chain it'll switch to it but still keep it's previous one
 36 2017-11-02 14:17:30 <arubi> you said you're going to start from very early, so you'll need to catch up until at least the current height to be considered by currently synced nodes'
 37 2017-11-02 14:21:58 <paulo_> "if it hears about a better chain it'll switch to it but still keep it's previous one" - and the client will save side chain blocks, until the side chain's difficulty decreases?
 38 2017-11-02 14:23:49 <arubi> I don't know exactly, but if there are two competing forks with the same difficulty I think it's best to keep track of them both
 39 2017-11-02 14:25:13 <paulo_> I'd want to save new side chain blocks, just in case it becomes the main chain. But at the same time, I don't want to be spammed by extensions to old sidechains.
 40 2017-11-02 14:25:37 <arubi> right, that's the reasoning I believe
 41 2017-11-02 14:28:49 <paulo_> what is "total work done"?
 42 2017-11-02 14:30:27 <paulo_> i know that hashes need to be lower than the target as POW, but I don't understand how they can be totaled
 43 2017-11-02 14:30:59 <arubi> each 2016 blocks is a retarget, and you sum up the work done in each of these periods
 44 2017-11-02 14:31:14 <arubi> 1 work is one hash256
 45 2017-11-02 14:31:43 <arubi> well, approximately right, large numbers and all
 46 2017-11-02 14:34:53 <paulo_> hmmm.
 47 2017-11-02 14:35:39 <arubi> paulo_, at each of these periods a new target is calculated, and miners commit to that new target in a field in the block header
 48 2017-11-02 14:36:13 <arubi> so it's easy to just sum these all up as you look at the headers.  it doesn't matter what the exact hash of the block was in a period, all blocks are treated as the same work
 49 2017-11-02 14:37:06 <arubi> all blocks in a period*, so what I mean is, a block's work is known by the bits fields in the block header
 50 2017-11-02 14:39:20 <paulo_> so side chains are tagged as ignored during retargets?
 51 2017-11-02 14:40:36 <arubi> I don't know exactly the threshold to ignore blocks outside our chain, but I'm guessing that if the block is in a shorter chain than ours, then we don't really need it
 52 2017-11-02 14:41:36 <paulo_> okay. I'm trying to figure out what exactly "shorter" is.
 53 2017-11-02 14:41:46 <arubi> less work
 54 2017-11-02 14:47:33 <paulo_> you look at the target to determine work, right?
 55 2017-11-02 14:49:49 <paulo_> I keep trying to extend a side chain, eventually it's difficul
 56 2017-11-02 14:51:10 <paulo_> I keep trying to extend a side chain, eventually its difficulty will decrease since i'll be doing it slower, hence less work. If there is less work compared to the main chain, further extensions to the side chain will be ignored. Is that right?
 57 2017-11-02 14:55:51 <arubi> yes, that's what I think
 58 2017-11-02 14:56:32 <arubi> I mean, just extending some low diff chain and broadcasting it will be a successful attack if nodes would default to keep it all
 59 2017-11-02 14:58:57 <paulo_> coinbase transactions are spendable after 100 confirmations, I guess it's safe to assume that after 100 blocks, it's considered permanent
 60 2017-11-02 15:00:14 <paulo_> i mean no need to save sidechains older than 100 blocks
 61 2017-11-02 15:01:32 <eck> also consider that if your sidechain has a lower difficulty target than the main chain, by definition that means that you're mining blocks slowly, which makes it hard to catch up even just in terms of block height
 62 2017-11-02 16:45:58 <devrandom> hi.  I have a message stuck in the bitcoin-dev mailing list for a couple of days (titled "Introducing a POW through...").  any pointers on how to get it released?
 63 2017-11-02 16:46:49 <devrandom> I meant to say "in the bitcoin-dev moderaton queue"
 64 2017-11-02 18:28:51 <puchu> hi
 65 2017-11-02 18:29:14 <puchu> how can i manually rebroadcast a transaction from the qt client?
 66 2017-11-02 18:30:54 <execute> what's happening to bitcoin testnet?
 67 2017-11-02 18:33:48 <wumpus> puchu: right click, copy transaction data, go to debug console, type sendrawtransaction <paste>
 68 2017-11-02 18:34:06 <wumpus> (so right click in the transaction list on the transaction you want to send)
 69 2017-11-02 18:34:22 <wumpus> you can also paste the raw hex into e.g. blockchain.info/pushtx or similar
 70 2017-11-02 18:42:51 <puchu> wumpus: thanks
 71 2017-11-02 19:46:05 <jonasschnelli> puchu: there are also standalone dependency free push clients
 72 2017-11-02 19:46:17 <jonasschnelli> https://github.com/laanwj/bitcoin-submittx
 73 2017-11-02 19:46:26 <jonasschnelli> https://github.com/libbtc/libbtc
 74 2017-11-02 19:52:10 <puchu> thanks
 75 2017-11-02 19:52:47 <puchu> do you also know if its possible to replace a none confirmed transaction with a transacation that has a lower value created with the same UTX
 76 2017-11-02 19:53:18 <puchu> @jonasschnelli
 77 2017-11-02 19:53:25 <jonasschnelli> puchu: Most miners/nodes do only allow BIP125 replacements (replace by fee)
 78 2017-11-02 19:53:29 <jonasschnelli> puchu: so the fee must be higher...
 79 2017-11-02 19:53:35 <jonasschnelli> You can add an input though
 80 2017-11-02 19:53:52 <jonasschnelli> You can lower the value of your change output as an example...
 81 2017-11-02 19:53:54 <puchu> but the transaction value (neto) has to stay the same?
 82 2017-11-02 19:53:57 <jonasschnelli> but the tx fee must rise
 83 2017-11-02 19:54:32 <jonasschnelli> you can add input and outputs as long as the fee rises in the in BIP125 way
 84 2017-11-02 19:54:43 <puchu> or is it possbile to decrease it?
 85 2017-11-02 19:55:03 <jonasschnelli> puchu: the fee or the output value?
 86 2017-11-02 19:55:08 <puchu> output value
 87 2017-11-02 19:55:46 <jonasschnelli> You can reduce the output value... sure. That will result in increasing the fee
 88 2017-11-02 19:55:57 <puchu> i broadcasted it multiple times but it doesnt show up on any blockexploerer
 89 2017-11-02 19:56:30 <puchu> no i mean i sent for exmaple 1BTC with 0.001BTC fee and replace it with the same UTX0 but with 0.5BTC+0.002BTC fee
 90 2017-11-02 19:57:03 <jonasschnelli> Have you signaled BIP125 RBF in your original TX?
 91 2017-11-02 19:57:04 <jonasschnelli> Otherwise your doing a double-spend
 92 2017-11-02 19:57:24 <puchu> nope. yeah i do a double spend but i want the later one to get confirmed
 93 2017-11-02 19:57:34 <puchu> to get the first marked as none valid
 94 2017-11-02 19:58:00 <jonasschnelli> I see.... that's non-trivial.. maybe have a look at petertodd's double-spend tool (never used, .. don't ask me for further support)
 95 2017-11-02 19:58:10 <puchu> is the second transaction broadcasted at all?
 96 2017-11-02 19:58:15 <puchu> i mean relayed
 97 2017-11-02 19:58:44 <jonasschnelli> Almost all nodes do only accept "replacemenets" if the original transaction has signaled BIP125 RBF.
 98 2017-11-02 19:58:47 <puchu> usig raw-tx broadcast tools give me an error
 99 2017-11-02 19:58:56 <puchu> there was no RBF
100 2017-11-02 19:59:13 <puchu> and RBF only allows to increase the fee nothing else, the other parts have to stay the same
101 2017-11-02 19:59:21 <puchu> as the name says replace by fee
102 2017-11-02 19:59:23 <jonasschnelli> no
103 2017-11-02 19:59:43 <puchu> really?
104 2017-11-02 20:00:01 <jonasschnelli> BIP125 RBF does allow to add inputs and outputs as long as your fee increases (in a certain way)
105 2017-11-02 20:00:08 <jonasschnelli> Have a look at BIP125
106 2017-11-02 20:00:28 <jonasschnelli> There is another way to get your tx unbstuck...
107 2017-11-02 20:00:30 <jonasschnelli> By CPFP
108 2017-11-02 20:00:44 <jonasschnelli> Not sure if applicatble to your TX
109 2017-11-02 20:01:53 <jonasschnelli> You can spend the unspend output of your "stuck" tx in another tx that pays a "high fee"
110 2017-11-02 20:02:17 <jonasschnelli> (only possible if one of the outputs belongs to a key owned by you)
111 2017-11-02 20:02:53 <puchu> yeah i have one change key
112 2017-11-02 20:03:09 <puchu> so would have to send this to another transaction
113 2017-11-02 20:03:17 <puchu> transaction/address
114 2017-11-02 20:05:16 <jonasschnelli> yeah... just do a follow up tx with the output of the stuck tx... make sure you pay a high fee
115 2017-11-02 20:05:26 <puchu> high = ?
116 2017-11-02 20:05:38 <jonasschnelli> heh... difficult question
117 2017-11-02 20:05:45 <puchu> current the client recommends 0.002btc/kb
118 2017-11-02 20:05:49 <puchu> is 0.003 high?
119 2017-11-02 20:06:28 <jonasschnelli> haven't checked my estimator... just double the value if you want a simple answer
120 2017-11-02 20:06:44 <puchu> okya i jsut wanted to go with 4 :D
121 2017-11-02 20:07:06 <jonasschnelli> a miner must then be interested to collect that fee,... but can only if he also includes your original tx in the new block (==CPFP)
122 2017-11-02 20:09:43 <puchu> okay thanks i tried it , if it doenst make it i will end up with the original transaction
123 2017-11-02 20:10:44 <puchu> the mempool is completly crouded
124 2017-11-02 20:16:29 <puchu> jonasschnelli: thanks for your help
125 2017-11-02 20:17:23 <puchu> jonasschnelli: i know what a CPFP is but i never tried it. maybe i should create a third one with the UTX0 from the last CPFP :)
126 2017-11-02 20:17:37 <puchu> at least blockchain doesnt show my tx
127 2017-11-02 20:17:48 <puchu> blockchain.info
128 2017-11-02 20:51:44 <jonasschnelli> puchu: maybe give us (or PM) your txid(s)?
129 2017-11-02 21:02:49 <puchu> the first one is confimed :(
130 2017-11-02 21:03:09 <puchu> it is as it should be ;)