Skip to content
#

Blockchain

blockchain logo

A blockchain is a digitized, decentralized ledger of transactions. Blockchains record a continuously growing list of records, called blocks, which are linked and secured using cryptography.

Here are 12,171 public repositories matching this topic...

ricmoo
ricmoo commented Sep 9, 2020

I've found historic issues regarding the Rinkeby Faucet in this repository, and @karalabe suggested opening an issue to remind him to fix this.

The URL parser for Facebook Post URLs on the Authenticated Rinkeby Faucet does not correctly parse URLs if they end in a / or contains a query string.

Thanks! :)

thsowers
thsowers commented Jan 10, 2019

Visiting https://github.com/diesel-rs/r2d2-diesel has a deprecation notice at the top pointing towards the r2d2 module powered by: https://github.com/sfackler/r2d2, which has great documentation on the package. However on our end there is no documentation on how integration with diesel works. Should we document how to properly use this?

The source in diesel specifies "See the [r2d2 documentatio

alexbosworth
alexbosworth commented Aug 10, 2020

Background

When a node has multiple private channels with the same peer, the hop hints in their payment requests will be populated with multiple channels. The purpose of these hop hints is to specify the next node's key and indicate the fees and cltv delta needed for route construction.

In pathfinding, due to non-strict forwarding, an LND node paying to this destination will only use the

brapse
brapse commented Feb 27, 2020

The blockchain v2 reactor utilizes concurrency to saturate the bottleneck of writing blocks to disk. This concurrency is internal to the reactor where the reactor itself will launch and manage internal state machines running as go-routines. This configuration makes testing difficult as we don't know when messages processed by internal state machines will be processed and when we can assert that th

carlhua
carlhua commented Jul 13, 2020

Clients that support multiple server connections would like to have a way to decide which server connection is best able to handle a query. Servers currently "sort of" expose their load as fees, but there's no real exposure of server load in a useful way. Some parameter should be added to the "server" publication stream that clients can just compare across servers to decide which is most likely to

You can’t perform that action at this time.