Search content
Sort by
Showing 13 of 13 results by rlirs
What will happen to the layer2 blockchain network, after ETH completes the upgrade to POS. once ETH offers cheap gas fees and transactions become faster. Layer 2 solutions are still being used. I also like and hold matic but I don't know what its future holds when upgrading eth.
Ethereum will become big cloud computing company with the usual censorship once they switch to POS
I am already investing few hundred thousands in bitcoin, although I bought them long time ago for much less. Any extra money I would get I would invest them in developing my own crypto - distributed hash chain.
Re: How many confirmations required for btc received to be safe from double spend?
<Snip>
The chances of having a transaction of 3+ confirmations rejected or double spent isn't something I would worry about for normal Bitcoin usage. By normal I mean receiving $100s or even $1000 worth of BTC. If I were to ever receive millions or billions one day, I would wait for at least 6 confirmations. Not sure if that will even happen though. 
1 confirmation can be problematic and it doesn't have to involve a scam or double spend by the other party. The block could be orphaned. You see 1 confirmation, you release the money or goods, and the block your transaction got mined in gets rejected by the network. Then you are back to no confirmations. You weren't scammed and probably your transaction will be mined just fine in one of the upcoming blocks.
If there is no double spend, most likely a transaction will get included in both competing blocks so when one block is orphaned then another block would still have your confirmation. If that does not happen then, yes, the transaction will get included in subsequent blocks.
Although Bitcoin paper considered an attacker when doing probability calculation, competing blocks can be mined randomly without ill intentions. These competing blocks will be broadcast to the network and someone sending large amount should watch for a possible blockchain reorganization. If my transaction has one or two confirmations and there are no competing blocks that don't have my transaction then I am pretty sure that my transaction went through.
You could validate block difficulty, but how would you validate someone's mempool size? But since you said it doesn't need to be validate it, what would happen if majority miner claim have big mempool or majority miner claim have small mempool?
In addition there is no financial incentive for miners to attack blockchain.
Regarding maximum block size, there are possible financial reason to do it such as,
1. Lower block size could force people to pay more transaction fee.
2. Higher block size could be used to attract investor with PR "Bitcoin now is scalable and can adjust to network condition" which increase Bitcoin price.
1. Lower max block size can have minimum size set to the current Bitcoin block max size so it cannot get worse than what it is now.
2. If it does increase Bitcoin price than I would not complain
. If it does not then the incentive to claim big mempool for miners is gone.In real life different miners would set mempool size to different values, there will be conflicting interests, and in the long run it will be close to what majority of nodes see.
But I am not in favor of increasing max block size as I believe it would affect decentralization. But theoretically it is an interesting topic.
There is no need to validate any precise value that will change anyway. When averaging over 2016 blocks the result will get close to average mempool size that other nodes see.
There is no point in having a requirement that does not have to be followed.Additionally, it opens opportunity to,
1. Bloat blockchain (by claim have big mempool).
2. DoS attack on Bitcoin node (by claim have big mempool).
3. Network congestion (by claim have small mempool).
Using average mempool size is no different than using average difficulty. Some blocks mined in much less than 10 minutes, some in more than 10 minutes but the average value comes out fine. In addition there is no financial incentive for miners to attack blockchain.
It would be more interesting to hide sender, not receiver. Maybe silent payments together with help of miners can break connection with senders.
Use a mixer then, end of story. No need to complicate it with miners and coinbase transactions.Try it, use a mixer for your bitcoins and sell them on some exchange. Lots of exchanges blacklist bitcoins from mixers.
Quoting part of the OP:
I still don't understand how silent payments improve anonymity. Doesn't Alice still have lots of outputs in different addresses? Didn't she have the same problem before?
Therefore, that allows user A to receive payments on completely delinked addresses using only one public address.
Isn't this already happening? Well, not exactly with one public address, but with one master public key. You can create nearly unlimited addresses which aren't linked and there's neither interaction from the sender.I still don't understand how silent payments improve anonymity. Doesn't Alice still have lots of outputs in different addresses? Didn't she have the same problem before?
I was thinking the same. If Bob can communicate with Alice using her original address, she can send him one of her newly generated addresses and he can send funds to that new address. Silent payments are not needed if they can communicate between each other. Advantage of silent payment would be if Alice receives many payments and cannot reply to senders.
It would be more interesting to hide sender, not receiver. Maybe silent payments together with help of miners can break connection with senders. Let's say we added a rule to Bitcoin that when a sender sends 1 coin to some kind of null address then miner will include that transaction plus new type of transaction without inputs (similar to coinbase transaction) that pays back 1 coin to new silent payment address of the sender that only miner knows. We are assuming that miner will not reveal that information. In case miner cheated and sends coin to somewhere else, the sender probably can raise an alert(I have not thought of all the math) and honest nodes will reject that block. If lots of senders participate it will work like a mixer.
Why not make the block size simply depend on some fraction of mempool size...
Simply stated, there is no "the mempool". Every node has a mempool and every mempool is assumed to be different.Why not make the block size simply depend on some fraction of mempool size...
Simply stated, there is no "the mempool". Every node has a mempool and every mempool is assumed to be different.
Of course every miner will set mempool size to a different value before mining the next block. That is why I said the mempool as miner (who will produce the next block) sees it. Once block is mined that value becomes the mempool size for blockchain at that block index.
Why not make the block size simply depend on some fraction of mempool size, say 1/10? Add a field to each block to record what miner sees as memory pool size then average it for the last 2 weeks. Then approximately each transaction in the mempool will get included in the next 10 blocks.