|
I read everywhere SegWit and 1MB block or SegWit and 2MB block. But these numbers are sort of misleading for traffic estimation since there is also present a witness part?
|
|
|
|
|
No technical objections, only economical ones.
You can't run bitcoin between three full nodes and support a price of hundred thousands dollars per coin.
|
|
|
|
hi all..
i have a simple questio about the fork scenatio.
Now, I have my 10 BTC in my wallet... Core-Wallet exactly.
Tomorrow morning i wake up and i read about fork...
if i understand well, i will find 10btc in all two chain.
The newone and the oldone???
Yes, just don't make any transactions until replay attack vector is blocked. |
|
|
|
|
120 satoshis per byte is good enough, wait few more hours and in the night it will go through. Next time make a 'replace by fee' transaction so you could speed it up.
|
|
|
|
|
Alice puts 2 BTC and Bob puts 1 BTC in 2-of-2 multisig address. When she gets the asset Alice takes 1 BTC and Bob takes 2 BTC.
|
|
|
|
|
What about this, don't count any fees, just declare invalid any block in which OP_RETURN and BIP 9 (user's and miner's) flags are different?
|
|
|
|
Miners can create high fee transactions voting for their favourite proposal and mine them without broadcasting, thus voting for free.
You mean they vote and then distribute the fees back between themselves? Then a mechanism to route fees to miners is needed, like encrypting parts of transaction with specific miners' public keys. |
|
|
|
How long of a period are you proposing?
The length doesn't really matter, there could be occasional misfires and re-votes. However long term it's impossible to gather enough money and media to outsmart the whole world. |
|
|
|
It is not immediately clear to me (and probably other readers too) that you are talking about putting an OP_RETURN output in transactions that people make.
I am sorry for that of course, however one can't put OP_RETURN anywhere else except in transactions. Your idea can be easily gamed. It is fairly trivial for people to make transactions and to essentially spam up blocks full of transactions supporting one proposal over another. Each person can make more than one transaction, so this is not really a good indicator of what user support is.
Nope, if the period is long enough one can't game the whole world on fees amount. You may disagree with me together with another bitcoin founder that this proposal will lead to 'mob rule'. However in this case you will need to deal with your fear of the user base and not with the lack of technical solutions. |
|
|
|
And how is this any better than the current system?
Currently miners decide the future of bitcoin but they don't bring value in and don't have long term attachment to it, so the model is skewed. especially one that takes up more space by needing another output in the coinbase.
You can't get something for nothing. 3 more bytes per transaction for a while seems a reasonable price to solve this deadlock. Also, in what way is this a UASF?
I'll leave the decision if this is UASF to people versed in definitions better than me. Users have no access to what goes into a block for signalling.
Yes but they have access to what goes into transaction. And one of the most important things are their fees. |
|
|
|
|
I guess so. Make an announcement that 01 in OP_RETURN field is a vote for SegWit and 02 - for Bitcoin Unlimited. Then aggregate fees for each option over a period of time.
|
|
|
|
|
There are additional verifications but you can't get something for nothing.
A transaction having 225 bytes is replaced with its 32 byte hash in the block where it is fully spent and the same 32 byte hash in the block of origin.
This is a 3.5 times compression of blocksize, for bigger transactions the ratio increases.
So this kind of blocksize bloat will be very hard to notice.
|
|
|
|
|
Thanks for the answer and for the work you are doing.
There are at least two faults in one sentence, I should have written fully spent transaction hashes and fully spent block numbers.
This would allow a node to receive and to store blocks with fully spent transactions replaced with only their hashes, when synchronizing blockchain backwards from the last block to the first one.
|
|
|
|
|
Add spent transaction hashes and spent block numbers in mined block.
|
|
|
|
Definitely more cpu processing time though.
I agree that giving the user control is the way to go, any change of PoW only kicks the can down the road. What do you think about addition of a database where every miner is defined by his bitcoin address and every set of miners is defined by an unique string. Then any block that includes a transaction containing incorrect string (miner missing in set) is rejected by the network. This way rogue miners will be penalized with lost fees and signaling of code changes can be based on amount of earned fees instead of hashrate. |
|
|
|
Thanks for the hint. I think this code from pybitcointools/README.txt will do the job > h
[{'output': u'97f7c7d8ac85e40c255f8a763b6cd9a68f3a94d2e93e8bfa08f977b92e55465e:0', 'value': 50000, 'address': u'1CQLd3bhw4EzaURHbKCwM5YZbUQfA4ReY6'}, {'output': u'4cc806bb04f730c445c60b3e0f4f44b54769a1c196ca37d8d4002135e4abd171:1', 'value': 50000, 'address': u'1CQLd3bhw4EzaURHbKCwM5YZbUQfA4ReY6'}]
> outs = [{'value': 90000, 'address': '16iw1MQ1sy1DtRPYw3ao1bCamoyBJtRB4t'}]
> tx = mktx(h,outs)
> tx2 = sign(tx,0,priv)
> tx3 = sign(tx2,1,priv)
> pushtx(tx3)
|
|
|
|
|
This question is wrong because without it the Lightning Network is impossible and BTC market cap is a solid zero.
The correct question is can it be done already?
|
|
|
|
|
Show Posts
