According to MasterLuc this is where we stop and bleed off to approx 580 in early January. He's been right so many times, if Bitcoin does this Ill be blown away.  so it seems he's right again. We topped at 744 as the img above indicate. The estimate precision on both axis (time and value) is indeed mind blowing. |
|
|
|
China Said to Study Limiting Outflows Via Bitcoin as Yuan Drops : BBG
Link(s)/source(s)? What's BBG? |
|
|
|
Banks won't use btc directly. They will make their own that they can control like fiat.
Fine with them. Their bankcoin won't even compete with Bitcoin. As Bitcoin's main value proposition is that it's not controlled by anyone as a whole, yet you control your own bitcoins. And it mostly eliminates banks as intermediaries. Whatever banks come up with, I strongly suspect it will be worthless garbage. For me, at least. I agree! But it also further drives home the fact that Bitcoin can be made better and more complete with a new version. Still decentralized, but lacking the problems and the stigma The stigma will be there also for the Bitcoin's successor as long as its monetary policy will be ruled by a known algorithm enforced by Nakamoto consensus (or any other valid solutions to the Byzantine General's problem). |
|
|
|
didn't they forget to mention ethereum? p.s. I really appreciate the effort you put in maintaining this thread. keep up the good work! Ahsante sana! you're welcome  |
|
|
|
didn't they forget to mention ethereum? p.s. I really appreciate the effort you put in maintaining this thread. keep up the good work! |
|
|
|
Did this not answer your question? https://bitcointalk.org/index.php?topic=1330553.msg14367997#msg14367997the witness data (signatures) portion of a transaction usually makes up around 75% of the total transaction data size ... so by moving it out the main block and into a separate 'witness block' of data makes available approx. that much space in the main block for other data.
Nope. Because despite the witness segregation in a separate block my full node will receive both txs base data and witness data to perform full validation. And because my node will have to relaying both base data and witness data to any other full node to let them perform full validation. So of the 3 main costs of operating a node RAM/CPU, bandwidth and storage the witness segregation will let me save in terms of storage and bandwidth only once I will decide to discard the witness part of a block, or "witness block" if you will. This has a disadvantage though, namely I could not fully participating to the p2p bitcoin network anymore because I can't provide blocks data to new nodes once I delete the witness part. |
|
|
|
Sorry but I'm actually trying to understand and I don't want to troll anyone. Just check my history to see that I've almost no tendency to trolling.
If you're seriously not trolling then why do you keep on posting about SegWit and bandwidth savings? (for the Nth time SegWit was not created for bandwidth savings so arguing about whether or not you'll get whatever amount of said savings is irrelevant) Could you please explain to me the reason why a discount of 75% is applied to signatures (witnesses) while computing block space limit? |
|
|
|
So it seems that we are still searching for a motivation for the 75% discount applied to witness data.
No we are not. The purpose of SegWit has been explained to you numerous times (and saving bandwidth is not it). It is clear now that you are posting nonsense repeatedly just like all the other trolls. Sorry but I'm actually trying to understand and I don't want to troll anyone. Just check my history to see that I've almost no tendency to trolling. That said, if the 75% it's not due to actual bandwidth savings what are the main reason? Storage saving or future benefits? If it's the former it seems to me that is a little bit disproportionate. |
|
|
|
Suppose that miner node (A) will send only data block to full node (B). B start looking for txs signature in its mempool. Unluckily B does not have all the txs included in the just mined block because its mempool is not perfectly in sync with the one of node A.
What happen then? Will B require those transaction to node A or to some other nodes?
if a method for request missing txs are not implemented then you left out from your description that a full node will have to receive both data block and signature block form a miner node (*). it need both to actually perform txs / block validation.
That sounds reasonable, but I expect the way it will be implemented could be a great deal more efficient if B were to send out requests for missing sigs prior to it's ability to validate a data block. And so the amount of bandwidth that would require needs accounting for, but I can't see that there won't still be an overwhelming saving in bandwidth for non-mining nodes like B. After all, missing tx's that were included in the latest block are only being relayed to B for the first time anyway, so the effect you're talking about sounds pretty marginal. You have just gave a overall description xthin block algorithm. And yes, xthin provide a pretty significant BW saving in the block propagation step (~ an order of magnitude). But as I've already told you that's orthogonal to SegWit, you could implement it now without SegWit. More to the point current Segwit proposal does not implement the aforementioned mechanism and at best of my knowledge there's no plan to include it in the near future. So it seems that we are still searching for a motivation for the 75% discount applied to witness data. |
|
|
|
Because full nodes will no longer recieve the signatures signing tx's, 75% of the data will be discounted (i.e. Not. Counted.), such as the signature data represents 75% of the overall block data.
I think you are wrong. It's impossible to validate a transaction without its signature. Regular nodes still check the signatures, they just don't store them after checking them. we do agree then. Full nodes will receive transactions base data and signature data, after checking them they could discard the signature part. i.e. SegWit will not provide any reduction of bandwidth for full nodes. no we don't, you're still wrong in exactly the same way as before. Full nodes currently download the signatures twice: when they receive relayed unconfrimed transactions, the signature data is provided. When any number of those unconfirmed transactions do become confirmed, the block they're mined in also contains the signature, for a second time. With segwit, there are two types of blocks: data blocks and signature blocks (i.e. witness blocks). The miners store and broadcast both types, whereas full nodes will only store & relay the data blocks. Hence the reduction in bandwidth requirements for full nodes. Suppose that miner node (A) will send only data block to full node (B). B start looking for txs signature in its mempool. Unluckily B does not have all the txs included in the just mined block because its mempool is not perfectly in sync with the one of node A. What happen then? Will B require those transaction to node A or to some other nodes? if a method for request missing txs are not implemented then you left out from your description that a full node will have to receive both data block and signature block form a miner node (*). it need both to actually perform txs / block validation. (*) I don't think there's such a distinction from miner full node and a non miner full node at the prorocol level. |
|
|
|
i.e. SegWit will not provide any reduction of bandwidth for full nodes.
That is not correct - although SegWit has not been designed for this purpose as I've already pointed out (a few times now) bandwidth savings are possible (initially due to already having all the signatures from tx relaying and down the track due to the fact that the new signature types that SegWit will permit are significantly smaller than those currently being used). Sure savings are possible, but at best of my knowledge are not implemented in the current proposal. And more to the point you can obtain even more BW savings using thin blocks independently from SegWit. The fact is that you already have transactions (base + signs) in your mempool does not depend on SegWit. They're there already it's just a matter of using it. edit: grammar |
|
|
|
Because full nodes will no longer recieve the signatures signing tx's, 75% of the data will be discounted (i.e. Not. Counted.), such as the signature data represents 75% of the overall block data.
I think you are wrong. It's impossible to validate a transaction without its signature. Regular nodes still check the signatures, they just don't store them after checking them. we do agree then. Full nodes will receive transactions base data and signature data, after checking them they could discard the signature part. i.e. SegWit will not provide any reduction of bandwidth for full nodes. |
|
|
|
Even initially that is not necessarily true because if a full node is relaying txs (which will contain the signatures) then it may actually already have all of the necessary information to validate the next block it sees (currently full nodes that are relaying txs are often actually seeing the signatures twice).
Bolded part is right, and that's the thing used by thin/xthin block techniques to reduce block propagation BW consumption. SegWit has nothing to do with thin blocks, I could be wrong though. Think a bit harder - if a SegWit block doesn't contain the signatures (those are sent separately as a witness block) and you realise that you already have all the signatures required (from txs that were relayed) then you don't need to request the witness block - do you? Again this isn't the purpose or point of SegWit but it is a potential side-benefit. And what if you have only a few of those txs in your mempool, are you going to require only a part of the witness block? And more to the point does current SegWit proposal implement the algo you described? That said thin/xthin will let you save even more BW because you won't request nothing about txs you already have in your mempool (both base data and witness data (signs + script)). |
|
|
|
Because full nodes will no longer recieve the signatures signing tx's, 75% of the data will be discounted (i.e. Not. Counted.), such as the signature data represents 75% of the overall block data.
I think you are wrong. It's impossible to validate a transaction without its signature. |
|
|
|
Going back to what we were saying, It is clear now that full nodes bandwidth consumption will remain the same even when SegWit soft-fork will be enforced/activated.
Even initially that is not necessarily true because if a full node is relaying txs (which will contain the signatures) then it may actually already have all of the necessary information to validate the next block it sees ( currently full nodes that are relaying txs are often actually seeing the signatures twice). Bolded part is right, and that's the thing used by thin/xthin block techniques to reduce block propagation BW consumption. SegWit has nothing to do with thin blocks, I could be wrong though. |
|
|
|
Full nodes receive a "compacted proof"? Maybe you are referring to "Compact fraud proof for SPV nodes" (*)? Here a relevant quote from SegWit BIP 141: Transmission of signature data becomes optional. It is needed only if a peer is trying to validate a transaction instead of just checking its existence. This reduces the size of SPV proofs and potentially improves the privacy of SPV clients as they can download more transactions using the same bandwidth.
So signature data will be optional only for SPV clients. The elliptic curve digital signature has to be there in its entirety for a full node to be able to validate a transaction. So it seems that 2MB SegWit block is equal to a 2MB normal block bandwidth consumption wise. Hence I suppose my original question is still unanswered, doesn't it? (*) https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#compact-fraud-proof-for-spv-nodes Yes, but the roadmap for Core does feature a stage where what I described happens. I can only apologise if I got the name wrong. Seeing as you're neck deep in github.com/bitcoin, you should look for it, and present it to the thread. Remember, you actually want an answer to this question, don't you? I've got this situation on my hands where I have a life to live, so your subtle assertion that everyone else should be literally researching the answer to your enquiries, when you're evidently more than capable of doing so yourself, without help. When it suits you. Let us know what your findings are  Core roadmap is orthogonal to the issue at hand, IMHO. You don't need to apologize, everybody could be wrong every once in a while. And everybody as a busy life to deal with. Going back to what we were saying, It is clear now that full nodes bandwidth consumption will remain the same even when SegWit soft-fork will be enforced/activated. And speaking of my original question I think that you're misremembering what I was asking, I just restate my question just for a matter of clarity because I'm genuinely in getting a proper response: what's the reason why a discount of 75% is applied to signatures (witnesses) while computing block space limit? Nevertheless I apologize in advance if I'm wasting your time Carlton. |
|
|
|
Maybe I'm wrong but from my understanding of SegWit's BIPs (*) blocks propagation will include also witness data. In fact it's impossible for a full node to validate a block without signatures data, only once validation is performed the full node operator could decide to drop (or keep) the witness data. Before that moment they seem mandatory to me.
Well, despite your belief that it's impossible, I don't think the full nodes do see the signature data... but they do receive a compacted proof that the tx's in a given block were signed. So the miners will be, as you say, coping with <4MB data per block. But ordinary full nodes only see 1MB of that. Hence "segregated". And so ordinary full nodes will use the same BW and storage they do now. Full nodes receive a "compacted proof"? Maybe you are referring to "Compact fraud proof for SPV nodes" (*)? Here a relevant quote from SegWit BIP 141: Transmission of signature data becomes optional. It is needed only if a peer is trying to validate a transaction instead of just checking its existence. This reduces the size of SPV proofs and potentially improves the privacy of SPV clients as they can download more transactions using the same bandwidth.
So signature data will be optional only for SPV clients. The elliptic curve digital signature has to be there in its entirety for a full node to be able to validate a transaction. So it seems that 2MB SegWit block is equal to a 2MB normal block bandwidth consumption wise. Hence I suppose my original question is still unanswered, doesn't it? (*) https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#compact-fraud-proof-for-spv-nodes edit: grammar |
|
|
|
Because Bitcoin has a 1mB limit and a hard fork would be needed to change it, along with all that this entail.
Did u even understand the meaning of this statement ? Why are not you still mining with a client that supports 2mb blocks ?
Coz Classic includes SPV mining which is bad for bitcoin. did they already merge Gavin's pull request? while at it if you don't mind I would like to know your opinion about this Sergio's post: https://bitslog.wordpress.com/2016/01/08/spv-mining-is-the-solution-not-the-problem/since Gavin's proposal is implementing what is described by Sergio as SPV mining. Answered this in various posts a number of times already on the forum. My pool averages around 300ms to process a block change and get new work - that whole double slow process that is the excuse for SPV. -ck's solo pool is under 200ms. As for block sizes. Go to these 2 links (6months and 30days) and see where our average block sizes are vs all the SPV pools. We're at the top, they're at the bottom. http://data.bitcoinity.org/bitcoin/blocksize/6m?t=land http://data.bitcoinity.org/bitcoin/blocksize/30d?t=lA couple hundred more milliseconds per block vs MANY SPV empty blocks and a much lower average block size. Also note the obvious, 300ms is 0.05% of 600s ... Of course, our orphan rates are VERY low. Case closed. thanks for the prompt reply. Frankly I was more worried about blocks propagation time rather than validation time, but I guess that's what Corallo's RLN is made for. |
|
|
|
if you are among the group of people that completely understand SegWit
Not exactly. I do want to have a even better understanding, but the time is just not there. The question was answered by someone else (although you could find this information quickly yourself; i.e. easy question). Despite, as you said, mine is an easy question, still the answer provided is, in my humble opinion, wrong. A 2MB SegWit block is equal to a 2MB normal block in terms of bandwidth consumption. In fact at best of my knowledge full nodes could discard witness data only after having validated a block. For normal txs relying/validation this is not even possible, txs in mempool will get both base data and wit data (for SPV client things are different, though). To make a long story short if a full node operator decide to prune witness data after validation step we have a reduced storage consumption. while bandwidth (BW) usage remain the same. Isn't BW a more scarce / costly resource in respect to storage? That said, I suppose my question remain unanswered, doesn't it? BW is more costly than storage but nothing compares to the cost of orphen risk the miner can discount the TX @75% because he won't include the segwit when propagating the block i guess... Maybe I'm wrong but from my understanding of SegWit's BIPs (*) blocks propagation will include also witness data. In fact it's impossible for a full node to validate a block without signatures data, only once validation is performed the full node operator could decide to drop (or keep) the witness data. Before that moment they seem mandatory to me. (*) segwit BIPs: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0142.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0145.mediawiki |
|
|
|
if you are among the group of people that completely understand SegWit
Not exactly. I do want to have a even better understanding, but the time is just not there. The question was answered by someone else (although you could find this information quickly yourself; i.e. easy question). Despite, as you said, mine is an easy question, still the answer provided is, in my humble opinion, wrong. A 2MB SegWit block is equal to a 2MB normal block in terms of bandwidth consumption. In fact at best of my knowledge full nodes could discard witness data only after having validated a block. For normal txs relying/validation this is not even possible, txs in mempool will get both base data and wit data (for SPV client things are different, though). To make a long story short if a full node operator decide to prune witness data after validation step we have a reduced storage consumption. while bandwidth (BW) usage remain the same. Isn't BW a more scarce / costly resource in respect to storage? That said, I suppose my question remain unanswered, doesn't it? |
|
|
|
|
Show Posts
