Hello fellow BGLers!

With (as always) incredible help of  https://github.com/janus/ BGL Core code was synced with BTC Core,
including switching to new build systems (CMake even for Windows, etc.)

So here's the latest release 0.1.14 of BGL Core:
https://github.com/BitgesellOfficial/bitgesell/releases/tag/0.1.14
(or links are on official site as well https://bitgesell.ca/downloads/ )

All right guys, this thing i need to explain in a bit more detail.

A few of weeks ago there's some good samaritan appeared and offered some improvements to the bridge https://github.com/BitgesellOfficial/gobglbridge/pull/1 (notably some better retry handling that wouldn't probably completely fix glitches due to using free EVM RPC, but would provide notable improvement, especially for such fast L2 as Arbitrum). The guy was even paid 2 weeks ago by Emma.
As there were indeed issues of constantly throttling RPC API calls (from Cloudflare pages to any kind of error messages), i've checked the code (being afraid of double-spends in retries, etc., that was the focus) and decided to merge the PR. And after questions if the service was redeployed with the latest changes, deployed it at last.

After redeploy (which i didn't announce) in 1.5 days, on 26 of August noticed the bridge was empty. There were gas tokens transferred too and also was a 'virtual bridge' signed by bridge's wallet to mainnet (full amount minus bridge fee). All was fast and calculated. After checking general-level accesses (like SSH etc.) the vector was narrowed down, there was something in serving of static files (supposedly to add security like directory access) made by the mentioned PR. I guessed correctly that it was related to that changing of ServeFile to ServeContent can expose '..' parent directory traversing in the url requested, but could replicate that only locally. Reanalized logs and found how the attack was made -- by requesting bglswap.com/app/<urlencoded path to config> which was successful from first try (was 100% prepared).

I'm 99% sure that PR's author and exploiter is the same person. even if not, somebody watched this closely and knew exactly what to do, it was 100% planned. i know it now looks more simple when explained, but this is still not something like 'dev opened a infected word file received via email'. i admit i wasn't prepared for this level of villainy (offer help and backstab this way).

removed the vulnerability and redeployed code.

what's next?
1. i have some personal BGLs left and also would ask Emma if she kindly can provide some liquidity for the bridge;
2. would reimburse if someone lost funds (please send me txids), all logs are intact;
3. won't be merging a third-party PR even if small cosmetic change;
4. would be good to find someone to help maintain the bridge (but at the moment is looks very hard to find anyone to give access and not being scammed next minutes);

sorry for this situation.
i believe that we can resume operation very soon (few days).

best regards

Hi all!
Rolled up new bridge with support for 4 EVM chains (Eth, BNB, Optimism, Arbitrum)
You're welcome to test it.
Interface is the same for now but planned to be improved.
Please do not use "old bridge" addresses - get a new ones with UI.
At the moment would process stuck old bridge txs and support.

Hi fellow BGLers!

It looks like less than a day left before the next BGL halvening!
congrats to all community members and participants!

There are some updates as well:

1. The release 0.1.10 is here, the code is synced with BTC Core up to Jan 2023.
All thanks to our member janus (just check the commits amount merged, several hundreds)!
Everyone is welcome to test the new build, it's for Linux systems, MacOS and Windows would follow very soon.
https://github.com/BitgesellOfficial/bitgesell/releases/tag/0.1.10

2. For the bridge. Yes, I've got reports that the bridge is misbehaving. Now, I think the reason for this is 'burst' requests in the BSC, that break the nonce tracking and outgoing BSC transfers start to fail. Probably this is connected to raise of the popularity of the project in recent days.

2a. I suggest to make things faster to write at it@bitgesell.ca with link/transaction hash (either in BGL, BSC or Eth) which is transaction YOU did sent to a bridge and that did not got funds trough or returned back.

2b. The bridge code would be stabilized or rewrtitten. The code is open, if you have an idea how to handle nonces in a reliable way easily please feel free to commit or contact. My approach would be to rewrite outgoing txes for Eth/BSC so they would be aligned in the queue and launched one by one, in a separate worker outside of the block scanning ones.

Anyways,
cheers guys!

Hey hey guys!

It's hard times for crypto, how're you all doing?

The release of 0.1.9 is out on GitHub, you can try and test it!
https://github.com/BitgesellOfficial/bitgesell/releases/tag/0.1.9

Big thanks to our maintainer janus for syncing the code with BTC, this is a huge amount of work done.
The testnet (big thanks to Castor198 and his bglnode.online !) should work out-of-the-box right now, as testnet DNS seed is added.

Hi guys

- we're preparing new version with updates synced with Bitcoin Core (up to August 2022 now).
As we've done previously, here's the minimal (non-Qt) package that could be used as node and tested
https://github.com/BitgesellOfficial/bitgesell/releases/tag/0.1.9
Updates for other packages would follow soon.

- bridge is resuming normal operations

Hi, yes, there were no errors when tx were sent from the bridge, but one got stuck somehow in BSC, and several others were already sent but were waiting in mempool queue a result.
Re-broadcasted that one and others were executed. I would check what was the reason for such issue (gas price was ok).
Thanks for pinging me.

Hey Castor, the tx should have been refunded day before yesterday, please check. Sorry it was missed.

I want also to congratulate our team member Emeka who managed to find a thing in the bitcoin source code!
https://github.com/bitcoin/bitcoin/issues/25682#issuecomment-1193296105

Hi Castor, indeed, there were txes sent before return fix was set in place. They were just refunded.

Guys, got the thing about stuck txes, the bridge held much better this time, but one thing emerged recently probably due to RPC provider error or rate limiting,
We would investigate and add handling of such case. All stuck txes would be either propagated or returned (give me 1-2 days max), your BGLs are safe.

Hi guys, I had checked the status tables, there were 3 txes stuck since 29th of June, respective amounts were returned to sender addresses.
The next stability update for the bridge is underway, please understand that it's in testing phase yet, but the stuck funds are safe and would be returned, just not within minutes.

Have a good one!

Hi Castor!
The BGLs were returned from the bridge to address you specified. Checked txes, and indeed some of them were bridge 'payment to itself'.
Please don't use for now combined path like WBGL(Eth)->created BGL address->link this bridge owned address to WBGL(BSC)->WBGL(BSC)

This way of using is really creative by the way but let's keep simple single transfers for now (BGL->WBGL or WBGL->BGL)

Hi everyone!

Update regarding the bridge.
There were a few (5 to be precise) transactions on BSC that were stuck on 14-16 June.
Balances that were sent, were refunded just now, sorry for the delay.
Analyzed all logs, there seems to be the only issue present, it happens when many BGL->WBGL transactions go into same BGL block, then sending in BSC or Eth can bug due to non-reliable nonce increment.
The temporary fix (already deployed) should return BGL funds automatically now when this situation happens, more robust solution would be developed in the next days.
Overall, other than that, bridge did work ok according to logs.

Please leave a msg here or in Discord if you got funds stuck in the bridge (better if you leave transaction id).

Oh, one more thing! It's more of UX issue, but yes, if you sign the bgl address (when going from WBGL->BGL), sign it for the corresponding network! (BSC or Eth). Yes, the signature is the same, but the record would store from which network to listen to transactions. So if you sign with radio button on Eth, and send on BSC, the bridge won't be detecting this tx as the one to be bridged. Maybe this radio button would be removed to avoid confusion, but pay attention.

Cheers!

Hey guys, long time no see!
A new version (0.1. of Bitgesell Core is released, please see GitHub releases page https://github.com/BitgesellOfficial/bitgesell/releases/tag/0.1.8
or the links are on the website https://bitgesell.ca/downloads/ as well (Downloads section). New icon and colors to match new branding included.
There were many fixes and changes ported from Bitcoin codebase (huge work done by https://github.com/janus !)
Feedback/testing is very welcome.

It's worth noting that BGL is going to have it's 2nd halving in less than 24 hours.
Stay tuned, WAGMI

I received mention of successful upgrade of a pool where Stratum v2 is used, but two other pools (our most active ones) just yesterday gave feedback that getblocktemplate needs to be fixed, so would test it and fix asap, then ping the pools
Nice adapted taproot.watch screen btw!

It's a BIP9-enabled soft-fork, pretty significant update, but the older nodes should be able to validate most of the block info (as was with taproot).

However, we need the miners to update asap, because the time window for block version checking is starting right now, we must have 80% of 2-week of blocks having this bit enabled, then the switch would auto-proceed, or we should re-coordinate otherwise.

Guys, I have rebuilt Windows 0.1.6 BGL Core distribution and reuploaded to GitHub releases:
https://github.com/BitgesellOfficial/bitgesell/releases/tag/0.1.6 (.exe installer)

It's built in release configuration, so no dependencies like vcruntime140D.dll etc.
Hopefully it would work fine!

Indeed, that was due to subsystem:Console in linker options, fixed, please install updated version (I have re-uploaded installer .exe file). Thanks for notifying!

Hi BGL community!

We have prepared a new new BGL core distribution, version 0.1.6 for major operating systems.
This one is important: we have synced to the BTC code for up to April 2021 (most credits go
to our fellow dev Emeka, he did huge amount of work).
As BGL is a fully decentralized system: a check is built-in if it would be possible to enable Taproot 6-months before BTC,
The parameters for switch are set as following:

- If 80% of last 2016 blocks upgrade to this taproot-supporting version bit by using latest distribution before 15 June 2021,
  then taproot would be enabled approximately on 1 July 2021 (block 66000).

This event is interesting in several regards, in particular, we can treat it as some forward-production testing for bitcoin to see how it work out (on a lesser scale) but in real (BGL) mainnet.

Some related reading regarding what is taproot:
- https://bitcoinmagazine.com/technical/taproot-coming-what-it-and-how-it-will-benefit-bitcoin
- https://bitcoinops.org/en/topics/taproot/
In short, Taproot and Schnorr signatures provide:
1. Better privacy for transactions, as various scripts, multi-signatures, etc. under most circumstances look like a regular tx on the blockchain;
2. Size reduction for some scripted transactions, like multi-signatures and others;
3. Creating a transactions requiring up to virtually unlimited number of signers.

--------------------------------------------------------------------------------
Please do upgrade your node (esp. if you're running pool) to the latest version
version 0.1.6 (available in GitHub releases)

Linux (BGL node): https://github.com/BitgesellOfficial/bitgesell/releases/download/0.1.6/bitgesell_0.1.6_amd64.deb

Linux (with Qt wallet): https://github.com/BitgesellOfficial/bitgesell/releases/download/0.1.6/bitgesell-qt_0.1.6_amd64.deb
MacOS: https://github.com/BitgesellOfficial/bitgesell/releases/download/0.1.6/BGL-Qt_0.1.6.dmg
Windows (64-bit installer): https[Suspicious link removed]
--------------------------------------------------------------------------------