ETH

Type the transaction ID into blockchain.info and see if you can find it. Also check the address you sent from/to, just to make sure that you have lost funds.

Then check your receiving address on etherscan.io

Also make sure you have synched the blockchain. In command line run:
geth --removedb
geth --light

Once it is sycned(takes a few minutes) restart the wallet.

Ethereum wallet uses shapeshift.io, so I would open a ticket with them.

I think that was probably the original concept, but I'm not sure it fits well with the current direction of bitcoin. Am I supposed to open multiple lightning channels with various peers when on chain transactions cost $XXX?

Can you provide me with your thoughts on how you see lightning working under the following fee scenarios?

a) On chain transactions cost $1
b) On chain transactions cost $10
c) On chain transactions cost $100

It seems like as fee pressure creeps higher, hubs will have to form to limit the amount of peer channels that individuals must open.

Hey housenuts

I'm kinda being serious here but if you have any known bugs with BU please forward them to TC so that he can forward it to the right ppl.

Thx

I'm in the 2-4mb + segwit hf camp.

Taken a step back from BU. That being said, I think BU is an improvement over where we are currently and unfortunately I don't see core agreeing to a hf for a small blocksize increase.

I think that's probably the most logical spot given where everyone is at. Unfortunately, that proposal isn't coded or tested, so there's no real way to get there from here.

Also, nobody's working on it, so it will never get done.

Pretty sure all it requires is to double or triple the blocksize max limit in the current code. Don't see what else is required.

As for segwit, it is coded and tested.

where is BTC going to be in a month

lulz

Lol BU. One failure after another. Lets see how they spin this to be Core's fault.

Quite possible bug was identified by BU devs and core attacked it

https://t.co/bbjneIFSfM

The bug was in the code for over a year: https://twitter.com/petertoddbtc/sta...03197723021312

Anyway, I'm not a developer nor have any education in computer science. From an outside perspective, I see BU protocol, that now twice in the past month has a) unintentionally mined a >1mb block, and b) lost 75% of its nodes because of a 1-year old bug that was never fixed. Yet they claim it's ready for rollout. I don't see how as an average user, I am supposed to trust the BU dev team to the same capacity as Core.

theyll never do it.

for reasons i cant fully understand today, they believe that the 2nd layer solutions will have exactly 100% uptime and the game theory that binds miners/nodes to behaving altruistically with on chain fees can/will be leveraged and replicated in the 2nd layer.


today i dont understand if that works. But Core is convinced it will, and today that's good enough for me.

I was reading something that with current fees, it's too expensive to run lightning network. That doesnt make sense to me, but what reddit said.

And if everything happening off chain and miners not receiving fees, they just stop processing tx unless it met a fee threshold.

Would just mine empty blocks every 10 mins.

This is what BU wants to do.

Huh? No. BU wants blocksize to increase so it is able to process more transactions per block than the current low limit.

Right now fees are so high because only x tx can fit in a block. With BU it will be > x and able to scale to meet the needs based on however many tx there are. With more room for tx, fees can lower.

The issues with BU are:

a) their code and supposed lack of skills.

b) if blocksize get too big it could lead towards mining centralization.

Sure, BU wants the blocksize to increase.

Sure, there will be miners with a high network capacity and relay capacity who will altruistically include as many txs into their blocks as possible.


But it is not entirely clear to me that BU will function as intended in this way for the majority of miners, and more importantly users. Because when you literally uncap the blocksize, you fundamentally alter the game theory behind selecting which TXs to include into your block.

Today with a capped blocksize, miners include what's effectively the highest fee paying txs that fit into the blocksize. Miners include these txs into each block because there is a great deal of economic incentive to do so-- they get more btc. This economic incentive outweighs pushing empty blocks, outweighs selective TX confirmations.

In a BU network, this incentive structure is fundamentally altered. Because the blocksize is completely uncapped, BU miners become the sole arbitrator of tx confirmations. The economic incentive to include the highest paying txs into the block will be weakened because invariably people will be submitting TXs with lower fees. Further, BU miners conceivably can completely manipulate the fee market by refusing to confirm TXs despite an unlimited blocksize by forcing a fee "floor".

What's ironic about BU is that there was a study done by some Princeton CS guys discussing endgame mechanics of blockreward =0btc with a 1mb cap. One of their findings is that it is not entirely clear that placing a highest fee associated with your tx at block reward =0 will be sufficient to incentivize miners to confirm. At face value, this is completely counter intuitive, but it turns out when price of btc reaches a certain level, the value of having your btc tx confirmed far outweighs whatever fee you can attach to your transaction. This is important because the paper argues that miners will begin selectively confirming txs and will no longer confirm the highest paying transactions. Now you can figure which txs these miners will selectively confirm.

One can argue that BU will produce these effects completely unintended. But my personal feeling is that this is not the case. Miners supporting BU are preparing for a future where they are the sole judge and jury for which TXs get added to the blockchain. And that is more valuable than the BTC you attach to your transaction.

Imo this bug is a sign that we need to move away from bitcoin core to BU. The timeline was this:
1. bug was found in BU
2. hotfix was commited
3. bitcoincore saw hotfix, decided to attack it to make BU seem bad
4. false news about bitcoin classic being vunerable
5.
hotfix was released
6. news about hotfix was censored from the forums who had no problem to discuss the attack
7. bitcoincore developers make threats about using zero day attacks if BU majority forks

Normal procedure among nice developers is that you give developers reasonable time to fix the bugs before you release attacks for the bug to the public... Blockstreamcore are clearly not being nice...

hahahahahahahahhahahahahahahahahahahahahahahahahah ahahahahaha

BU declared war a long time ago.
In war, there are casualties.

Maybe it shouldn't be amateur hour over at BU headquarters

https://twitter.com/SatoshiLite/stat...88344371568640

Honestly, I still can't believe anyone who holds Bitcoin could support handing a $20bln network over to the BU devs.

Edit: Just gonna go ahead and leave this here for future laughs

gotem gg ul

no doubt about it, if BU is going to accomplish a hard fork, they are going to have to deal with bugs and withstand attacks.

You must be completely delusional to actually believe this.



It's not just the lack of skill. Also the lack of proper testing and peer reviewing. This isn't a Wordpress plugin, we are talking about a $20 billion network here, it's insane to just merge commits without proper testing/reviewing. Security should be the focus.



Removing the most crucial part of the bitcoin network, the "consensus" part where we all agree on the rules of the network - is a huge security risk itself. "Emergent consensus" actually just means "miners dictate the rules and nodes better be lucky enough to be on their fork".

Nodes setting isn't a vote, it's just a setting on which "fork" you want to end up. So if you set your EB setting to 2MB (because you would like to have 2MB blocks - which is fair!), you can end up being temporarily on the wrong fork. A single miner (even with 0.01% hashrate) can initiate a blockchain split at any moment when he decides to increase his MG setting and mine a block with it. If other miners still have their EB to 1MB, this means that only the EB2 nodes will see confirmations for these transactions. Basically if for example a gambling/poker site has 1-2 conf deposits (which is practically all gambling sites), they risk getting confirmations on transactions that can be still double spent later. While this 2MB MG miner will lose his block reward, he will be able to easily steal all the hot wallets of gambling sites (which is hundreds of coins in total.) Technically orphans happen right now too, but BU makes it a lot easier to do this maliciously.

You could say nodes better just stick with EB1 till the miners will change their blocksize, but then you risk to be on the wrong fork when they actually increase the blocksize (also this emphasize the part where nodes have no vote whatsoever - it's just miners dictating the blocksize.) It gets more tricky when the miners vote isn't even clear. By design, it has no hashrate thresholds or grace periods, which again, is just not safe. It will create multiple forks and without proper replay attack prevention (which they didn't develop), again it's obvious that there will be losses (just like Coinbase/BTC-E lost some ETC.) Personally I think most investors and businesses don't like the idea of having 2 blockchain splits "fighting it out" by speculating on the the market price of each coin. This split is much more contentions than the Ethereum split and will result in much less overall value.

Overall, as a professional security reseacher, I personally just believe the assumption that everyone will be nice and no one will attack the flaws in "emergent consensus" is very naive. It will make 1 till 12 confirmations much less secure (you will need like 13 confirmations to be secure.) And it puts bitcoin in a permanent risky mode where you constantly have to monitor miners and bitcoin splits to figure out which fork is "good".



Additionally, the problem with miners dictating the network rules isn't just miner centralization upon blocksize increase. This change itself is already more centralization. Right now the users and businesses are dictating the network rules by running full nodes. Miners have to follow us to be able to earn money. To give miners (which really is just a handful of mining pool operators!) the power to be the dictators of network rules is insane. Sure, right now they could also change their consensus rules - but no one will follow them - they will be mining a worthless altcoin.

Miners shouldn't be able to dictate the blocksize - because it doesn't just affect them(!) The costs of a (much) higher blocksize is on the users (full nodes.) It also sets a very bad precedent. What if transactions fees will be high in 3 years after halving because the block reward isn't enough? Since miners are the new dictators of the network rules, shall we just let them remove the 21M coin limit and give them a bit more rewards? This sounds ridiculous but make some social attacks by spreading propaganda that this is really needed to "keep the transaction fees low" and they might convince some idiots (just like what is happening now.)



Bitcoin Core's path (which is the technical majority with 100+ developers and used by practically all businesses) is more scientific. It is very clear that we cannot handle all future transactions on-chain without the loss of many nodes and therefor the loss of the most important property of bitcoin "decentralization". Both 1MB and 2MB are absolutely nothing, even 100MB blocks are not that interesting in terms of global transactions (but 100MB would destroy the decentralization of bitcoin right now.) We will need second layers to have REAL scaling, Segwit makes this much easier. The 2MB increase that comes with Segwit is just an additional advantage to have a 2x more transactions throughput - without the risk of a blockchain split that a contentions HF brings with it. Segwit is insanely well tested compared to BU with a testnet for it since 2015.

Segwit has a high 95% threshold because changes shouldn't come easy. The Bitcoin Core developers don't want to be the ones deciding on the network improvements as it is up to the users. Miners will only change it if they see that the community indeed thinks Segwit is good. 95% basically guarantees that there is indeed consensus among the community. IMO it is pretty clear that most businesses and users support Segwit, but it is okay-ish that miners still have doubt. Of course if it's just ends up Ver&Wu blocking Segwit other methods can be considered (I don't think this is the case now.)

Obviously after Segwit, we still need blocksize increases. Since Bitcoin Core is not a company but just a large group of individuals, realistically they cannot fully pledge on future improvements. The idea right now is to have Segwit activated and collect data how the bitcoin network handles the new higher blocksize. For example: if we see that all the nodes still keep running, it's safe to assume the blocksize increase wasn't that bad and a dynamic blocksize increase can be built based on that data.

Segwit and dynamic blocksize HF after that, seems the very obvious way to go. I hope more BU supporters realize this is a more safe and scientific way to improve scalability and the the FUD against Bitcoin Core is mainly based on conspiracy theories.

Recovery seems ok so far: