So more analysis is still in order, but overall, I don't think these dynamics encourage the formation of big miners.
This is encouraging... it sounded yesterday as if you had almost regretted making this thread and were about to pull your own support from the proposal because of this and now it looks like it might be less of a problem than initially thought. I'm having some trouble following the logic of the objection. I dug it from upthread: That said, a problem with any kind of rollover fee is that it assumes that moving fees to future blocks is also moving fees to different nodes.
Put differently; centralizing nodes is a way of avoiding the penalties you're trying to introduce with this protocol.
Put differently again; Paying fees over consecutive blocks gives a competitive advantage to larger mining entities when making larger blocks.
Put triply differently; A node that can reliably get another block within X blocks is less penalized than a node that cannot, where "X" is the number of blocks that the rollover fee is given.
So if the goal is to avoid centralization, then the protocol does the opposite of the intention. If the goal is to make Bitcoin fail-safe, I'm not convinced that Bitcoin isn't already. When blocks fill, we will see higher transaction fees, potentially lengthier times before a transaction is included in a block, and as a result more 3rd party transactions.
TLDR: How does a fee over "X" blocks not incentivize a centralization of nodes?
firstly, what we're talking about here is not, as DumbFruit generalizes, a "rollover fee". It's a disporportional penalty on mining large blocks. I'm not sure wether this changes his argument or its validity. For thinking about this I'm using the following hypothetical mining landscape: 25%, 25%, 5 x 10%. Now I think there are at least 2 interesting questions we can ask: - Do the 2 25% miners (or 2 of the 10% miners) have a higher-than-in-current-system incentive to collude?
- Is Menis proposal making it easier for the 2 25% miners to try to drive out small (as in bandwidth) miners by mining disproportionally large blocks?
Both questions boil down to - Does Menis proposal encourage centralization more than the current system?
Before I go on... am I asking the correct questions? |
|
|
|
I wonder: (With a little thinking the obvious answers come, but please comment if it is wrong).
If the Trezor in its current incarnation does not send the XPUB key(s) to the MyTrezor server,
it does, though (well, not the trezor, but the js wallet): mytrezor.com wallet sends xpub to server to retrieve transaction history.
|
|
|
|
By miner has to pay it, we mean "not paid to miner but to rollover pool instead"? They miner is never paying anything, they are simply not given the reward, yes?
No, by "miner has to pay it", we mean he always has to pay it, even if he receives no on-chain fees. You're both correct, it's a matter of terminology. The miner has to pay it. But he's not paying by spending any of his previous coins, he's paying by having the payment deducted from the reward he collects. If the reward is not sufficient (negative reward after deduction), the block is invalid. So the miner will not include so many transactions that the penalty will make the block invalid. See my previous comment and I hope everything is clearer now. I apologize for not intervening sooner, I had a busy day, maybe this whole exchange could have been avoided... Thanks for clearing it up. I can see now where NewLiberty was probably coming from (either the monero mechanism or your earlier proposal referenced in OP, both of which I didn't look at). Your reward calculation formulas cleared things up. |
|
|
|
I think the current design already incentivize smaller blocks: Smaller blocks get broadcasted much faster and become less possible to be orphaned. If you consider that there are 25 coins to compete for, you would like to broadcast your block as fast as possible once you find it
This is correct but as far as I know, the magnitude of this effect is very small, and not enough to keep block size in check. I agree. Also with IBLT or other block propagation bandwidth conservation techniques (some of which seem to be used by pool interconnects already) this effect can (and will) be nullified. |
|
|
|
mytrezor.com wallet sends xpub to server to retrieve transaction history. However Chrome extension does the device management without revealing any information to our servers. It is completely standalone application, so it does not even reveal your IP to us.
and just to be clear i understand the terms, xpub means "master public key", correct? thanks for clarifying. The master public key for the account, not the entire tree of accounts. I think the terminology used in BIP 32 was: - xpub means extended public key, and generates all public keys for a single private key (i.e. single Trezor account)
- a master public key generates all xpubs for a single seed
[/b][/b] [/list] I don't know how closely everyone follows the same terminology, but you'd think it would be pretty faithful seeing as slush and I think also stick talk on the developers mailing list about this wallet related stuff. that's even more confusing. i thought the xpub is a single root master public key (derived from a single root master private key) from which all child public keys are derived. this same root master public key (xpub) can parent many different branches of child public keys. what carlton said was indeed confusing (there's only one address for each private key, for example). You can derive an xpub for any node in the tree. Can be root node or account level node or even further down. |
|
|
|
I see your point in that the amount of the fees are not part of the calculation of the penalty.
However, why would anyone mine a block for which they will not be paid?
The incentive would remain to move fees off chain, especially as the coinbase reward decreased.
Off-chain fees would not be subject to the seizure and redistribution of the rollover.
Better for the miner to guarantee positive revenue and get it on the side.
I still don't follow you. Why does it matter wether the fee is payed on- or off-chain. The penalty is the same and the miner has to pay it either way. By miner has to pay it, we mean "not paid to miner but to rollover pool instead"? They miner is never paying anything, they are simply not given the reward, yes? No, by "miner has to pay it", we mean he always has to pay it, even if he receives no on-chain fees. Edit: Saying again for clarity - In the current proposal, fees from transactions will be paid to the miner of the current block instantly and in full. The miners can't gain anything by accepting tx fees out of band. The one paying into the rollover pool is the miner himself, as explained below.
|
|
|
|
I see your point in that the amount of the fees are not part of the calculation of the penalty.
However, why would anyone mine a block for which they will not be paid?
The incentive would remain to move fees off chain, especially as the coinbase reward decreased.
Off-chain fees would not be subject to the seizure and redistribution of the rollover.
Better for the miner to guarantee positive revenue and get it on the side.
I still don't follow you. Why does it matter wether the fee is payed on- or off-chain. The penalty is the same and the miner has to pay it either way. |
|
|
|
Es muß aber nicht der Bitcoin sein. Da es sich um OpenSource handelt, kann man sich den Code kopieren und einen Coin Bitcoin2 erfinden. Dann hat man auch eine neue leere Blockchain, mit der man machen kann, was man will.
Die aber erstmal nich so sicher ist wie die bitcoin blockchain. Ich würd jetzt meine assets z.B. nicht mit colored Auroracoins abbilden. Oder das Grundbuch von Venezuela. Da nimmt man die sicherste und zukunftssicherste chain: bitcoin. |
|
|
|
The penalty will be deducted from the funds he collects in the generation transaction
I read that as "from reward, tx fees and rollover pool input". Thanks for that, it was my reading also. Thus TX fees that are not in the block but paid out of band are not subject to penalty...No, that wasn't my understanding (the bolded part doesn't follow from what's said above, does it?). Fees aren't subject to penalty at all. The penalty depends purely on size of block (if I understand correctly). Even if the tx fee was payed out of band, the tx will still contribute to the penalty through increased block size. Yes, it's deducted from the tx fees (can be other tx fees), but it depends (in amount) on the fact that the tx takes up space in the block. In other words: it's not the fee that's penalized (neither in block nor out of band), but the space it takes up in the block. Again: if I understand correctly. EDIT: regarding the discussion about what happens with block reward going to 0: this means that you can't mine a block with only transactions that had their fees paid out of band, because they would take up space and thus effect a penalty, but there'd not be enough on-chain fees to pay for it. |
|
|
|
Can you explain a bit about the mechanism wherein the miner pays into the rollover pool, and why that is different from the 'original proposal'? It is not obvious why this dictinction makes a difference. It seems to still incentivize out of chain payments to miners for transaction inclusion regardless of whether it is paid by the miner, or deducted from the miner's reward, both are dependent on the fees in the block (which aren't there in out of block payments schemes).
I think the penalty is not dependent on the fee: The miner of a large block must pay a penalty that depends on the block's size.
So it still has to be paid regardless of wether or not the tx fee payment was on- or off-chain. This is penalty then ONLY taken from the coinbase reward and not also TX fees? How would this method survive the successive halvings (much less the eventual cessation)? The penalty will be deducted from the funds he collects in the generation transaction
I read that as "from reward, tx fees and rollover pool input". If the penalty exceeds the miner's income of tx fees + minted coins + his share of the current rollover pool, the block is invalid.
I stumbled accross this problem, too and I remember it was adressed upthread, not very far from OP. I just searched, but couldn't find it and I also can't remember why (or wether) this wasn't a problem. I think I wasn't convinced or didn't think it through. But thinking about that a bit, assuming 0 block reward is reached. A block with no transactions in it can always be mined because it doesn't carry any penalty at all. As soon as there's a penalty to be payed there need to be some transactions in the block and the fees they pay must exceed the penalty (otherwise the block is invalid). Is this a problem? I'm not sure, seems to me that depends on the particularities of the penalty function... |
|
|
|
Monero avoids this problem, but most of the rest of this proposal has been implemented and running for quite a long time. Its not new, or novel, except in ways that it is not as good.
When Gavin says "I need to see working code", he probably means code he can directly deploy to his test setup within the framework of bitcoin-core. I can relate to this demand and find it reasonable. |
|
|
|
Can you explain a bit about the mechanism wherein the miner pays into the rollover pool, and why that is different from the 'original proposal'? It is not obvious why this dictinction makes a difference. It seems to still incentivize out of chain payments to miners for transaction inclusion regardless of whether it is paid by the miner, or deducted from the miner's reward, both are dependent on the fees in the block (which aren't there in out of block payments schemes).
I think the penalty is not dependent on the fee: The miner of a large block must pay a penalty that depends on the block's size.
So it still has to be paid regardless of wether or not the tx fee payment was on- or off-chain. |
|
|
|
|
I like this proposal. It takes away much of the destructiveness of hitting the block size limit. Makes 'impact' softer and actually allows for a market to function: with higher aggregate fees (higher tx demand), economically usable blocksize can actually increase, which is not the case with the current 'hard' implementation: no amount of higher aggregate fees will increase block space. That doesn't facilitate a market.
It would be interesting to hear from some core devs. Sounds to me the proposal could be acceptable to Peter Wuille and maybe even Peter Todd, for example, since the solution still offers to deliver economic incentive to develop scaling solutions.
Maybe this really could be (worked into) something with broad consensus.
I understand we will still argue about T, but it will be much easier because the consequences of choosing it wrongly aren't as dire.
|
|
|
|
Ich komme nicht. Muss arbeiten  Viel Spass euch! Mitleid! Ich komme. |
|
|
|
"Die ing-diba hat derzeit kein Problem damit. Bisher hat meines Wissens nach noch keine Bank jemandem das Konto geschlossen wg. Bitcoin."
Vielleicht derzeit nicht, Ende 2012 jedenfalls schon......  https://bitcointalk.org/index.php?topic=99061wo ist eigentlich der Rest des TopicsI stand corrected. |
|
|
|
Eigentlich schliessen alle banken dein Konto sobald sie herrausfinden du hast was mit bitcoins am hut.
quatsch. Die ing-diba hat derzeit kein Problem damit. Bisher hat meines Wissens nach noch keine Bank jemandem das Konto geschlossen wg. Bitcoin. Du neigst wohl etwas zu übertreibungen, oder? Solltest Journalist werden. Da kann man sich eigentlich als ehrlicher bitcoin freund nur bei denen bedanken.Die den coin für Kriminelle zwecke nutzen.
So ein Blödsinn. Da kann man sich als rechtschaffener Bitcoin-Freund bei den Banken bedanken, oder beim Staat oder am ehesten bei den Journalisten die das Image des Bitcoin in diese Ecke drängen. Glaubst du echt der Bitcoin wird in großem Maße zur Geldwäsche benutzt? Ist doch völlig ungeeignet dafür. Man versucht dem Bitcoin ein schlechtes Image anzuhängen. Die Pisser haben die Hosen gestrichen voll. Guckt mal die Scheisse hier an zum beispiel: Bei BITCRIME handelt es sich um ein bilaterales, deutsch-österreichisches Forschungsprojekt, das sich mit der Prävention und Verfolgung organisierter Finanzkriminalität mit virtuellen Währungen beschäftigt und vom deutschen Bundesmininsterium für Bildung und Forschung (BMBF) sowie vom österreichischen Bundesministerium für Verkehr, Innovation und Technologie (BMVIT) gefördert wird. Das Projekt ist auf 25 Monate (Oktober 2014 – Oktober 2016) angelegt. Das Gesamtprojektvolumen beträgt 2,4 Millionen Euro.
Die sollten mal 2.4 Millionen € dafür ausgeben, die Finanzkriminalität und Korruption im Allgemeinen zu verhindern oder zu verfolgen... aber da passiert NIX! |
|
|
|
Naja, werd ich wohl die Hausbank wechseln.
Beste was man machen kann, nutz die Sparkasse nur noch zum Geld abheben. Apothekerpreise und wirst nach Strich und Faden beschissen. Klingt nach so ziemlich jeder Bank. |
|
|
|
is there a way to initialize a Trezor seed w/o revealing the master pubkey to mytrezor.com? is that what python trezor is for? can it be done through Mycelium?
I'm not sure the master pubkey is revealed to mytrezor.com at all. I vaguely remember slush or stick saying it wasn't the case. Does anybody know for sure or can point to the relevant part in the client code? does capture it in advanced settings, or somewhere like that. if "it" is the client side javascript code, the I have no problem with that. Question is: is it sent to the mytrezor.com server? i thought it would have to be b/c that master pubkey is definitely in one their setting windows. No, it isn't. Think of your browsers javascript engine and html document view as providing a runtime for an application. An example where this is easy to see are browser-based paperwallet generators: you can see the private key "on the page", but it's not sent to the server. |
|
|
|
I think they definitly need to have the master pub key for the website to display balances
(Or maybe only the created pub key ?)
Why? It's entirely possible to have the client generate the addresses and send them to the server instead of the xpub key. It might look like 'wasting bandwidth', but it's really 'preserving future privacy' |
|
|
|
is there a way to initialize a Trezor seed w/o revealing the master pubkey to mytrezor.com? is that what python trezor is for? can it be done through Mycelium?
I'm not sure the master pubkey is revealed to mytrezor.com at all. I vaguely remember slush or stick saying it wasn't the case. Does anybody know for sure or can point to the relevant part in the client code? does capture it in advanced settings, or somewhere like that. if "it" is the client side javascript code, the I have no problem with that. Question is: is it sent to the mytrezor.com server? |
|
|
|
|
Show Posts
