Search content
Sort by
Showing 20 of 54 results by readerbtc
There is a pretty prominent forum author, AnonyMint (his last incarnation was, I think, "iamnotback"), that mantains the view that pegged sidechains won't work. Here mentions his doubts, but I admit that never really analyzed deeply his argumentation. He basically says the same like Peter Todd, that it's difficult to incentivize mining in a way security is guaranteed.
Thank you, I'll read.Could we agree they are not impossible but you need to put lot of energy and efforts into, to get them more or less safe?
The 'impossible' part for me is the '2-pegged' aspect: there will be a price difference, always, between pure bitcoins and the tokens from the sidechain.
I don't intend to engage in a flame war here. Neither I want Blockstream or whatever hiring killers to murder me. 
But the basic idea is: yes, there are products calling themselves "2 pegged sidechains" but they wont work as advertised.
But the basic idea is: yes, there are products calling themselves "2 pegged sidechains" but they wont work as advertised.
They can't reject XT mined blocks as long as they're a part of the same chain, what you're suggesting is a fork.
I'm not suggesting anything.You mean XT right? I don't think it happens since they are still in the same blockchain.
Ops, thank youYou could edit the maximum allowed block size in the code. Change it to 100 KB and it'll be a soft fork, change it to 100 MB and it'll be a hard fork.
Good example.
Changing the max block size from 1MB to 0.1MB is a softfork, because it makes previously valid blocks (0.1MB-1MB) invalid.
A soft fork would be changing the max block size one produces from 1MB to 0.1MB, while leaving the max block size one accepts unchanged.
Or am I wrong? #sincerequestion
⭐ Merited by ABCbits (1)
How easy is, for a miner, to find the place in the source code where it says "1 Mb" and remove the line?
I mean, if most miners, like 80% hashpower, decide to raise the limit of the block size, they can, right? Core developers are neither necessary for this nor can't do anything.
Or am I missing something? #sincerequestions
I mean, if most miners, like 80% hashpower, decide to raise the limit of the block size, they can, right? Core developers are neither necessary for this nor can't do anything.
Or am I missing something? #sincerequestions
I am investigating the idea, and i saw how it seems it's the transactions that are colored. Can someone explain this choice to me?
What choice?⭐ Merited by pebwindkraft (1)
That checkmultisig reads an extra element could be used in the future to make batch validation faster (as it needs some additional side information), or for other extensions. It's commonly assumed to be a bug that it reads an extra item but might have just as well been another forward compatibility mechanism, or a left over behavior from an earlier approach.
I like bitcoin because it screws my notions of what is software.Quote
Looking from this perspective maybe we shouldn't call this a "bug"? 
This is bug. Definitely a bug. The insect that we did not want to be here.
But this is a bug in a consensus code.
So, this is a bug in an amber
https://upload.wikimedia.org/wikipedia/commons/b/b6/Amber2.jpg
No, this bug should not be fixed
Why not? Sure, it would be a hard fork, but couldn't clients consider block height when executing opcodes and behave accordingly?