Let's collect 'em here.
Both existing visuals and ideas for new ones are welcome.
Both existing visuals and ideas for new ones are welcome.
Last edited:
Visual arguments on the blocksize cap, dev decentralization, etc.
- Thread starter Zangelbert Bingledack
- Start date
Block size
Animated block size
Developer decentralization
Animated developer decentralization
Bitcoin Unlimited
Satire
Animated block size
Developer decentralization
Animated developer decentralization
Bitcoin Unlimited
Satire
Last edited:
@Peter R
https://prezi.com/9z87yigefti5/test/
This is just a dummy test I slapped together in a few minutes to give some idea of how an explanatory presentation could work within Prezi.
Fullscreen it and click the right arrows to see the presentation frames in order. The technical info isn't meant to be precise (nor is it meant to suggest that user-selected limits are the way to go, that's just filler text) and the visuals are crude, but imagine how something longer and much more polished could be used in, for example, a narrated video. Something like this could even be expanded to constitute an entire visual wiki of the debate, or of BU, or both, and made into a whole series of videos that examine specific parts as they walk through paths in the wiki.
The advantage of Prezi is you can keep everything in perspective, delving into fine points without getting lost in them. Although I used the zooming at the end for dramatic effect, I think it's an effective way of covering many subtle points and how they interrelate, using diagrams and even video embedded within, then zooming out to help the viewer not fall into the trap of "small game" thinking, always keeping the big picture in mind. Which is I think one thing the debate is sorely lacking.
https://prezi.com/9z87yigefti5/test/
This is just a dummy test I slapped together in a few minutes to give some idea of how an explanatory presentation could work within Prezi.
Fullscreen it and click the right arrows to see the presentation frames in order. The technical info isn't meant to be precise (nor is it meant to suggest that user-selected limits are the way to go, that's just filler text) and the visuals are crude, but imagine how something longer and much more polished could be used in, for example, a narrated video. Something like this could even be expanded to constitute an entire visual wiki of the debate, or of BU, or both, and made into a whole series of videos that examine specific parts as they walk through paths in the wiki.
The advantage of Prezi is you can keep everything in perspective, delving into fine points without getting lost in them. Although I used the zooming at the end for dramatic effect, I think it's an effective way of covering many subtle points and how they interrelate, using diagrams and even video embedded within, then zooming out to help the viewer not fall into the trap of "small game" thinking, always keeping the big picture in mind. Which is I think one thing the debate is sorely lacking.
Last edited:
actually the guy in the cartoon throwing all the money in the air should have a beard and pony tailBlock size
Animated block size
Developer decentralization
Animated developer decentralization
Satire
@cypherdoc
I wondered about the Llama in the lower left corner of raisethelimit's cartoon. Shouldn't that actually be a thirsty Alpaca?
I wondered about the Llama in the lower left corner of raisethelimit's cartoon. Shouldn't that actually be a thirsty Alpaca?
Here are some concepts or clusters of concepts that are hard to grasp and could really use visual arguments to make them spread:
- The ideas of market governance and how BU (straight unlimited or user-selected caps) would work
- Peter R's paper on how a fee market exists without hard blocksize cap (visualization of the logic with some kind of mechanical analogy would be the holy grail)
- Investors being the ones in control (or how overall checks and balances work among miners/nodes, devs, investors, exchanges, and other infrastructure in a way that makes this clear)
- Layers of investor control of Bitcoin
- How fork arbitrage would work
- Why speculation is a good thing
- The societal role of investors
- The Forkology 101 & 102 concepts showing different views on governance
Last edited:
I think fork arbitrage should be communicable with an animated GIF of some sort. Maybe a price ticker above each fork and something that shows how the miners abandon the fork with the falling price, thereby causing new blocks to be found more slowly, further dropping the price. This is also something that Core Dev doesn't appear to understand, so it might have the most bang for our buck.
Right now BU txns are mined on both chains and the client just pops from one to the other with no effect on the final balance. Its pretty awesome to see. Really makes u believe in the anti fragile nature.
But it will make arbing forks hard... you'd have to first mix your coins with a coinbase coin on only that fork. Basically u coinjoin with them first to uniquify your addr to only 1 chain.
But it will make arbing forks hard... you'd have to first mix your coins with a coinbase coin on only that fork. Basically u coinjoin with them first to uniquify your addr to only 1 chain.
Well you could just add 1 to the signature for example. But whoever does it tacitly admits that they are the fork... and is not backwards compat with the history, so who's going to do it?
Anyone who wanted to fool around could undo that and reapply the sig on the other side just to screw things up. Instead you'd have to break the transaction itself so the valid sig does not match a valid transaction...
Anyone who wanted to fool around could undo that and reapply the sig on the other side just to screw things up. Instead you'd have to break the transaction itself so the valid sig does not match a valid transaction...
@theZerg
I'm not sure what you mean by backward compatible with the history. Are you basically saying the only way to make fork arbing work is to have everyone coinjoin their coins before they can move them?
Also, doesn't fork arbing inherently involve address reuse? You're ultimately going to want to transact twice using the same private key (and same with spinoffs for that matter).
I'm not sure what you mean by backward compatible with the history. Are you basically saying the only way to make fork arbing work is to have everyone coinjoin their coins before they can move them?
Also, doesn't fork arbing inherently involve address reuse? You're ultimately going to want to transact twice using the same private key (and same with spinoffs for that matter).
Last edited:
what I mean with "backward compatible with the history" is that one fork would basically have to hard-fork. It would have to add code that decodes the txn in today's way if block < N and decodes the txn in another way if block >= N. Its just another way of tacitly admitting "we are not the real bitcoin".
"Are you basically saying the only way to make fork arbing work is to have everyone coinjoin their coins before they can move them?"
If you want to move them on BOTH forks, you don't have to coinjoin. When you want to move the same coins differently on each fork, then you need to coinjoin on one of the forks with a newly mined coin. This creates a txn that is invalid and therefore ignored on the other fork.
So, yes, your idea of sending your coins to an arb exchange via a single txn on both forks, and then letting that arb exchange coinjoin them is the easiest way to do it. But requires trust.
Another way would be to have a "faucet" of newly mined coins that gives out a fraction of a penny for free. Once you have one of these coins in your wallet, you could use the "advanced feature" where you can select your input coins to mix that fraction of a penny into your other addresses.
"Are you basically saying the only way to make fork arbing work is to have everyone coinjoin their coins before they can move them?"
If you want to move them on BOTH forks, you don't have to coinjoin. When you want to move the same coins differently on each fork, then you need to coinjoin on one of the forks with a newly mined coin. This creates a txn that is invalid and therefore ignored on the other fork.
So, yes, your idea of sending your coins to an arb exchange via a single txn on both forks, and then letting that arb exchange coinjoin them is the easiest way to do it. But requires trust.
Another way would be to have a "faucet" of newly mined coins that gives out a fraction of a penny for free. Once you have one of these coins in your wallet, you could use the "advanced feature" where you can select your input coins to mix that fraction of a penny into your other addresses.
@theZerg
1) Fork
2) Wait for one block to be mined by a friendly miner
3) That miner sends one satoshi to every address in existence (BU protocol temporarily removes the dust limit to allow this). Though that sounds like a lot of tx data so it might take several blocks(?) during which funds are frozen?
4) Presto!
With coin control I assume you're talking about sending a fraction of a penny to every wallet, or letting people use the faucet as they need. Seems messy though as how do you know for sure what's a wallet, and if users must do it it becomes cumbersome. Maybe somehow the BU client could do this automatically? But setting up the faucet could only happen once a friendly miner mines a block, which might take hours or more, so users' funds might be effectively un-decouple-able for an undetermined amount of time.
Do I have these points right?
I think by the time exchanges are actually engaged in fork arbing, that perception issue is mostly dealt with. After all, the very idea of fork arbing is that the investors decide what Bitcoin is.
Good, I think that's OK for fork arbing because there is no way to do the arb process without trust anyway.
Very interesting! Even without exchanges arbing or even in the case where arb results in two viable forks, this makes it seem like a fairly simple matter of:
1) Fork
2) Wait for one block to be mined by a friendly miner
3) That miner sends one satoshi to every address in existence (BU protocol temporarily removes the dust limit to allow this). Though that sounds like a lot of tx data so it might take several blocks(?) during which funds are frozen?
4) Presto!
With coin control I assume you're talking about sending a fraction of a penny to every wallet, or letting people use the faucet as they need. Seems messy though as how do you know for sure what's a wallet, and if users must do it it becomes cumbersome. Maybe somehow the BU client could do this automatically? But setting up the faucet could only happen once a friendly miner mines a block, which might take hours or more, so users' funds might be effectively un-decouple-able for an undetermined amount of time.
Do I have these points right?
Yes you are mostly right. But one thing to consider is that mined blocks are only spendable after 100 blocks (or its 100 on regtest anyway). So there is a pretty significant undecoupleable gap.
- Idea for a diagram -
Show the "checks and balances" of governance within Bitcoin, including miners, investors, nodes, devs, users, exchanges, infrastructure companies, and merchants. Who has what kind of influence over whom? In format it might look something like those silly checks and balances charts:
Of course the viewer will walk away appreciating the power of investors, and appreciating how BU is what is needed, though that would not be intentional but rather a consequence of depicting the power structure correctly.
- A further idea -
Do two charts side by side, showing how BU changes the structure, or perhaps better to say how it reveals the structure. The way consensus works in Core/XT/BU could also be shown with this, or with additional variations.
Here's another diagram that might play into this somewhat:
[doublepost=1447973142][/doublepost]- One more idea -
Diagram showing how consensus among the 5 Core devs is a completely different kind of consensus than that of the nodes/miners/users, and also how alternatives like XT and BU don't take away choice even if they have "dictators" but in fact do the opposite. These are basic errors people are making that would be impossible to continue entertaining in their minds after they see them visually worked out.
I have no idea about a good actual format for this one.
Show the "checks and balances" of governance within Bitcoin, including miners, investors, nodes, devs, users, exchanges, infrastructure companies, and merchants. Who has what kind of influence over whom? In format it might look something like those silly checks and balances charts:
Of course the viewer will walk away appreciating the power of investors, and appreciating how BU is what is needed, though that would not be intentional but rather a consequence of depicting the power structure correctly.
- A further idea -
Do two charts side by side, showing how BU changes the structure, or perhaps better to say how it reveals the structure. The way consensus works in Core/XT/BU could also be shown with this, or with additional variations.
Here's another diagram that might play into this somewhat:
[doublepost=1447973142][/doublepost]- One more idea -
Diagram showing how consensus among the 5 Core devs is a completely different kind of consensus than that of the nodes/miners/users, and also how alternatives like XT and BU don't take away choice even if they have "dictators" but in fact do the opposite. These are basic errors people are making that would be impossible to continue entertaining in their minds after they see them visually worked out.
I have no idea about a good actual format for this one.
Last edited:
Here's a rough draft of a two-part simplified governance chart for Bitcoin, the first showing what devs, miners, nodes, and investors can do for each other, and the second showing how they can thwart each other in case of abuse:
Themes:
1) Investors hold the ultimate power over Bitcoin. Note that in the "checks and balances" chart I meant to say that investors can render the project worthless and give value to another implementation/fork.
2) The developers' power is an ephemeral sort, contingent on their continuing to satisfy the desires of those who run their software.
Simplifications:
1) Miners and nodes are also usually investors in some sense, but this is not reflected in the diagram.
2) Users ("shoppers"), merchants, exchanges, and other infrastructure are not mentioned.
3) Government power is not mentioned.
4) No distinction is made between miners and mining pools.
5) No distinction is made among short-term traders, long-term investors, and venture capitalists.
6) Non-monetary uses of Bitcoin are not mentioned, such as smart contracts and colored coins.
7) Most importantly, forks are only covered tangentially and there is no mention of BU yet.
Feel free to edit the diagram here or as desired. Suggestions welcome!
Themes:
1) Investors hold the ultimate power over Bitcoin. Note that in the "checks and balances" chart I meant to say that investors can render the project worthless and give value to another implementation/fork.
2) The developers' power is an ephemeral sort, contingent on their continuing to satisfy the desires of those who run their software.
Simplifications:
1) Miners and nodes are also usually investors in some sense, but this is not reflected in the diagram.
2) Users ("shoppers"), merchants, exchanges, and other infrastructure are not mentioned.
3) Government power is not mentioned.
4) No distinction is made between miners and mining pools.
5) No distinction is made among short-term traders, long-term investors, and venture capitalists.
6) Non-monetary uses of Bitcoin are not mentioned, such as smart contracts and colored coins.
7) Most importantly, forks are only covered tangentially and there is no mention of BU yet.
Feel free to edit the diagram here or as desired. Suggestions welcome!
Image or animation idea:
~Bitcoin Dev Decentralization~
The One Ring, labeled "Bitcoin Core" or just "Core," fall into lava and melts, dispersing into a multiplicity of competing implementations. The ring being round like @Peter R's animated pie chart (posted above) may help.
Optional variation with Golem reaching for the ring in vain. This would make it very polemical; putting someone's face/name on Golem would be way too vindictive so I strongly advise against it, though someone would probably alter it that way if the image became popular. Note that in the movie Golem falls into the lava and dies, so really please don't do this.
Last edited:
