 Show Posts
|
|
Pages: [1] 2 »
|
|
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.102. 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.9Big 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.9Updates for other packages would follow soon. - bridge is resuming normal operations |
|
|
|
There are a few transactions stuck on the bridge now. Please help
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. |
|
|
|
Tx is still stuck into the bridge for 10 days. 5fce97e0fbd67d02fd9a8fffa6f8d4169eafcbbaa4ed01ba651a5f03cd214632.
Hey Castor, the tx should have been refunded day before yesterday, please check. Sorry it was missed. |
|
|
|
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.
Stuck transactions a week ago: dc908734b123c71d3fc45aea9b621c1f274771392e2e18635b401878da10e28e, 32640ba1e33eaa72c58f0eb26ae84e9d6db83f7900d2d3513519b576dc28a8df. Hi Castor, indeed, there were txes sent before return fix was set in place. They were refunded (and hopefully other stuck txes too). |
|
|
|
|
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!
|
|
|
|
Please send stuck funds only to my address BGL bgl1qhfptx6vymtx4xtup5jqcrmfcrg7703v492yvjn, or return funds to addresses for WBGL.
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!
|
|
|
|
I'm trying to follow the Taproot signaling block using this: https://bitcoin.stackexchange.com/a/105854. It should do the job right? Currently, there is still no block signaling for Taproot, assuming the above method which is used by Bitcoin could be applied to BGL. BGL-cli getblockchaininfo | jq '.softforks | .taproot' {
"type": "bip9",
"bip9": {
"status": "started",
"bit": 2,
"start_time": 1626307200,
"timeout": 1629936000,
"since": 67824,
"statistics": {
"period": 432,
"threshold": 237,
"elapsed": 299,
"count": 0,
"possible": false
},
"min_activation_height": 74574
},
"active": false
}The awk script also returns no blocks of Taproot signaling. I also fork the https://taproot.watch/ to match with the BGL taproot activation threshold. https://github.com/vv181/fork-explorer/tree/BGL 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! |
|
|
|
I understand that in case of acceptance, the BGL hard fork will take place and old clients and nodes will not be able to work in the network?
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. |
|
|
|
Unfortunately, I was unable to launch the Windows wallet. At first the system couldn't find the file vcruntime140D.dll. I installed the update for Visual Studio 2015, 2017 and 2019 (vc_redist.x86.exe and vc_redist.x64.exe), after restarting my PC. Now after running the app I get the following error:  So I went back for the Bitgesell Release version 0.1.5 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! |
|
|
|
I downloaded and installed the new version. Why does the client now work like this? I have an additional open cmd window.
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.debLinux (with Qt wallet): https://github.com/BitgesellOfficial/bitgesell/releases/download/0.1.6/bitgesell-qt_0.1.6_amd64.debMacOS: https://github.com/BitgesellOfficial/bitgesell/releases/download/0.1.6/BGL-Qt_0.1.6.dmgWindows (64-bit installer): https://github.com/BitgesellOfficial/bitgesell/releases/tag/0.1.6 (download .exe) -------------------------------------------------------------------------------- |
|
|
|
Some updates regarding the code sync with Bitcoin Core: - we've synced a year of commits with BTC (many thanks to janus!); - the new code includes all things that are in BTC like taproot experimental support; - changes would be merged soon to the repo we now count as official: https://github.com/BitgesellOfficial/bitgesell (all are welcome to join); - one of the seed nodes is working using new build for 2 weeks, logs look ok; - thanks to discord member MrElliwood we also made and tested build for ARM (Raspberry Pi). I made a test build for Ubuntu/Debian incl. Qt wallet, here it is: https://bitgesell.ca/downloads/0.1.4test/deb/bitgesell-qt_0.1.3_amd64.deb(would make more proper versioning for the release. it may also require qrencode for gui wallet to work, tiny library that generates qr codes - run command 'sudo apt install qrencode') Please if anyone could help to run it, check if tx work, address generation etc., it would be very welcome. UPD: windows debug build is available too at https://bitgesell.ca/downloads/0.1.4test/win64/BGL-0.1.4-win64-setup. (add exe to the end of the link or link is removed by forum engine) |
|
|
|
|
