I have created a Slack channel at https://bitcoinunlimited.slack.com. At some point, I can probably set up an automatic invitation system. In the meantime, feel free to message me an email address and I will invite you.
Slack channel for Bitcoin Unlimited discussion
- Thread starter TrevinHofmann
- Start date
digitsu
Member
- Jan 5, 2016
- 63
- 149
Would it be possible to get an invite to the bitcoinunlimited slack channel? For some reason, I thought I had already received an invite but I've never been able to sign in.
Last edited:
I tried sending another, but Slack is telling me that an invitation has already been sent. http://i.imgur.com/SNdhIwx.png
Could you check your email again for the invitation link? After registering, you should be able to sign in at https://bitcoinunlimited.slack.com/.
Edit: I was able to resend the invitation from another page.
Could you check your email again for the invitation link? After registering, you should be able to sign in at https://bitcoinunlimited.slack.com/.
Edit: I was able to resend the invitation from another page.
@TrevinHofmann
OK that worked! I'm in! The invite went into my junk email (which is probably what happened last time too but last time I didn't notice). Thanks!
OK that worked! I'm in! The invite went into my junk email (which is probably what happened last time too but last time I didn't notice). Thanks!
Hi Peter, a question for unlimited: I remember that you said the nodes only accept a larger block if it has 4 confirmations, then what should the node do if it only has 1-3 confirmations? Because every block you receive starting as 1 confirmation, is it mean that before it has 4 confirmations, you will have no block added to your local blockchain thus miss all the transactions during these 4 blocks?
@johnyj as I understand it you node will download them as normal, it just wont relay the blocks until it has 4 confirmations, after 4 your node will accept it and continue relaying again, this behaviour is only for blocks bigger than your threshold. If the big block is orphaned before the 4 confirmations (ie 4 smaller blocks confirm before the bigger one) the network ticks along as usual.
The bigger blocks get, the higher the risk of not being relayed and accepted by the network.
The bigger blocks get, the higher the risk of not being relayed and accepted by the network.
@AdrianX Thanks, and what is the impact of transactions then? If all the nodes have to wait for 4 blocks when there is a big block, then the broadcasting of a big block will effectively delay all the transaction confirmation for 40 minutes? If every once a while an attacker broadcast a large block then it will create a 40 minutes stop of the whole network?
@johnyj say you set your block threshold to 16MB the situation you describe, is only applicable for blocks larger than 16MB. And then it also requires the majority of nodes to reject the first block larger than 16MB.
The reality is we're talking about a 1.1MB block being rejected by the majority of nodes who support a 1MB limit. Most miners in today's world wouldn't risk the loss of $10,000 for a marginal increase if they weren't at least 99% confident it was going to be accepted.
If you and enough people who ran a node and set the limit above the 1MB threshold, miners would eventually push past 1MB. And if you set your node to 1.1MB and everyone else set it to 2MB and a miner made a 1.2MB block you and the other 1MB nodes wouldn't relay it until you knew it was 4 blocks deep.
Miners today wouldn't risk $10,000 making a biger block unless they knew with relative confidence it was going to be accepted
The reality is we're talking about a 1.1MB block being rejected by the majority of nodes who support a 1MB limit. Most miners in today's world wouldn't risk the loss of $10,000 for a marginal increase if they weren't at least 99% confident it was going to be accepted.
If you and enough people who ran a node and set the limit above the 1MB threshold, miners would eventually push past 1MB. And if you set your node to 1.1MB and everyone else set it to 2MB and a miner made a 1.2MB block you and the other 1MB nodes wouldn't relay it until you knew it was 4 blocks deep.
Miners today wouldn't risk $10,000 making a biger block unless they knew with relative confidence it was going to be accepted
@AdrianX
I suppose the large block is sent out by an attacker, and in that case miners and full nodes react to it the same way: When they first see this large block, they know it is confirmed by one of the miners, but most of the miners will simply mine small blocks and trying to orphan it (miners are easier to reach agreement on one specific limit), but most of the nodes don't know, so they have to wait until a longer small block chain appear, that's 20 minutes waiting. Or if a small block is added upon this large block, they have to wait another 10 minutes to see if another small block chain take over, and if another small block is further added, another 10 minutes waiting, and so on...
In most of the case, they will wait 20 minutes and return to the small block chain, but this does not sound so funny. The question is: Why do you make this 4 block depth rule at the first place?
I suppose the large block is sent out by an attacker, and in that case miners and full nodes react to it the same way: When they first see this large block, they know it is confirmed by one of the miners, but most of the miners will simply mine small blocks and trying to orphan it (miners are easier to reach agreement on one specific limit), but most of the nodes don't know, so they have to wait until a longer small block chain appear, that's 20 minutes waiting. Or if a small block is added upon this large block, they have to wait another 10 minutes to see if another small block chain take over, and if another small block is further added, another 10 minutes waiting, and so on...
In most of the case, they will wait 20 minutes and return to the small block chain, but this does not sound so funny. The question is: Why do you make this 4 block depth rule at the first place?
Hi @johnyj
the attack you propose only delays transactions there is no economic incentive to execute such an attack and it is very expensive to execute. Miners can already do a similar attack today, they can continuously mine empty blocks refusing to process transactions if successful they may mine a few blocks in a row and delay valid transaction.
Most people recommend waiting for 7 confirmations before concluding a transaction as valid or irreversible.
The 4 block rule is adjustable. You can set it to 0 and accept any block size as valid as long as it meets all consensus rules, you could set it to 9 or 1000 if you want. A high setting like 1000 would almost guarantee that if you set a block limit your node will never accept a block above that size. Personally I think there is enough evidence to set it to 0. But as a conservative I'll set an 8MB limit and continue to follow the network if a block bigger than 8MB receives 8 confirmations.
Bitcoin has always been open code that anyone can change. Hostile changes are protected by the value people place in the blockchain and on bitcoin. The reality is the value in the bitcoin ledger is in the connections to the other people in the network who agree to the same rules and values you do.
We all agree what makes a valid transaction. Small block proponents just agree there is one other criteria, and that is at 1900 transactions per block all valid transactions are valid, but (assuming 2000 tpb = 1MB block then) at, 2100 transactions per block 5% of all otherwise valid transactions are invalid.
Bitcoin Unlimited just moves the block size out of the consensus layer and puts it as a user adjustable setting. It's important to understand that all users still need to follow the consensus rules to be part of the network, but if you happen to set your block limit too low, you won't be kicked out of the network. That why that setting exists.
On the flip side of this, is the Core reality that bitcoin is broken, and cannot be trusted to the decentralised users and miners, and the rules only exist because the centralised authority Core and theymos protects the rules to protect us from ourselves.
the attack you propose only delays transactions there is no economic incentive to execute such an attack and it is very expensive to execute. Miners can already do a similar attack today, they can continuously mine empty blocks refusing to process transactions if successful they may mine a few blocks in a row and delay valid transaction.
Most people recommend waiting for 7 confirmations before concluding a transaction as valid or irreversible.
The 4 block rule is adjustable. You can set it to 0 and accept any block size as valid as long as it meets all consensus rules, you could set it to 9 or 1000 if you want. A high setting like 1000 would almost guarantee that if you set a block limit your node will never accept a block above that size. Personally I think there is enough evidence to set it to 0. But as a conservative I'll set an 8MB limit and continue to follow the network if a block bigger than 8MB receives 8 confirmations.
Bitcoin has always been open code that anyone can change. Hostile changes are protected by the value people place in the blockchain and on bitcoin. The reality is the value in the bitcoin ledger is in the connections to the other people in the network who agree to the same rules and values you do.
We all agree what makes a valid transaction. Small block proponents just agree there is one other criteria, and that is at 1900 transactions per block all valid transactions are valid, but (assuming 2000 tpb = 1MB block then) at, 2100 transactions per block 5% of all otherwise valid transactions are invalid.
Bitcoin Unlimited just moves the block size out of the consensus layer and puts it as a user adjustable setting. It's important to understand that all users still need to follow the consensus rules to be part of the network, but if you happen to set your block limit too low, you won't be kicked out of the network. That why that setting exists.
On the flip side of this, is the Core reality that bitcoin is broken, and cannot be trusted to the decentralised users and miners, and the rules only exist because the centralised authority Core and theymos protects the rules to protect us from ourselves.
@johnyj I think BU users have less to worry about the Core users. Once you've set a block limit it's trust confirmations as usual. If one is in a scenario where low trust and high stakes are involved. Like anonymous money laundering of millions you may want to wait a few confirmations past 7 to guarantee no hiccups should a huge block materializes for some reason.
Who originally promoted this 4 blocks depth idea? I think I have to ask him, seems there are added technical complexity caused by this change. It has nothing to do with core users or BU users, since when nodes are waiting for block depth confirmation, all the transactions can not be processed
rickw
New Member
rickw
New Member
