Burnt coins are added in explorer! We display burnt coins for all period and for each block. Now burnt coins are 0.02% of circulating supply. https://bgl.bitaps.comBurnt coins 1 596.84031323 BGL |
|
|
|
I'd be more concerned about the strength of the encryption.
Encryption AES-CBC with key length: 256 bit |
|
|
|
Service charge flat rate fee 0.0002 BTC for each sale.
I like a lot of things about your paywall but not a fan of having fixed fees and your current minimum of 0.0005 BTC [I know it's not much but it limits smaller sales]. 0.0002 BTC this fee include forwarding transaction miners fee, bitcoin transaction is not free How much you're going to charge for hosting files beyond those periods? At this moment no any fee, we are currently collecting statistics on the use of this service. In the future, the cost of hosting a 1 GB file will be about $ 5 per year. |
|
|
|
Bitcoin encrypted paywall Sell your files, images, notes or other digital goods protected by AES encryption in the browser. Bitcoin encrypted paywall tool, allows you to create payment lock on files or a text message where user need to pay the assigned amount of Bitcoins to access the content. File content, file names and all messages including descriptions are encrypted in the browser. The service does not have access to content on its servers, so your media data is completely protected with AES encryption. Service charge flat rate fee 0.0002 BTC for each sale. Forwarding the payment to the seller's address takes place within 1-3 confirmations of the bitcoin network. Files and media data under 200MB hosted for free within 1 year. Files greater than 200MB hosted for free for 72 hours. The Paywall link has a built-in password. Encryption password is part of this link after # character. All web browsers use URL standard. According to this standard, the part of the URL after the # character is an optional fragment. This fragment is only used on the client side(navigation on page) and web browsers do not send this part of the link to the server. Paywall service never knows or gets a password for server-side content. Decryption occurs only on the client side in the browser. |
|
|
|
|
Many withdrawal requests completed today!
Many new miners joined our pool!
Our congratulations to the entire community and invite to join the BGL mining with https:/pool.bitaps.com.
|
|
|
|
Our pool want to share a good news! In gratitude for choosing our mining pool, we want to give a bonus to all our users! Those participants who are now mining or already have mined coins will receive 200 BGL. Participants registered only in our pool will receive 50 BGL. Let's enjoy to take a part in new BGL coin minning, thank you for choosing our pool! With best regards, Team https://pool.bitaps.com |
|
|
|
Take a look at https://www.npmjs.com/package/jsbtc.jsalmost no dependencies Crypto secp256k1 + wasm. Implemented: bip32, bip39, bip44, bip49, bip84, bip141. NIST random generation tests on the fly for entropy. Shamir's secret sharing for mnemonic. |
|
|
|
In addition to the pool just started Block explorer for this coin, https://bgl.bitaps.com. Please add to official list. Thank you |
|
|
|
Just started mining pool for BGL coin.
https://pool.bitaps.com
- Algorithm: Keccack
- rewards type: PPS (PPLNS will be added same later)
- payouts: daily by request (auto payouts will be added soon)
- pool mining fee: 1.5%
Pool settings: Stratum URL: pool.bitaps.com:8888 User: your_account@email.com.worker1 Password: any Difficulty: variable by default, + manual settings available Support email: support@bitaps.com
|
|
|
|
|
Is any open source miners available?
|
|
|
|
I'm developing now https://github.com/bitaps-com/btcapiserverThis is core for explorers or wallet backends. Python + Postgres. Performance about 12 - 24 hours to initial parse bitcoin blockchain (depends of configurated modules and hardware) Take look maybe my code will be useful for you. |
|
|
|
I doubt there will be much appetite for any commitment structure that requires recomputing the commitment any time the txn list in the block is changed. Particularly any that involves doing it for 5 different kinds of filters and which will go out of date as scriptpubkey types change. The BIP157 design being completely agnostic to the content of the scriptpubkey was an intentional design to conserve storage and optimize for the possibility of eventually turning it into a viable commitment.
The idea of separating filters by address type gives a significant reduction in the amount of required data requested by the light node. Refusing to divide by type will actually give a better degree of filter compression and the overall size will be even smaller than what we can achieve now. Block batch filters total size is smaller then BIP 158 at all total size savings 22% (3.36 GB vs 4.3 GB). We could win another 3-4 percent. But assuming that mostly light nodes use only one type of address, separation provides significant gains in bandwidth reduction. Is the calculation of several additional hashes more important than reducing traffic several times? In case we try use BIP 158 for commitment this is also requires recomputing the commitment any time the txn list in the block is changed. Is additional double sha256 is so big problem? Also I think we can redesign commitment structure to exclude from commitment filter types which have no any affected script types in recent block it will solve problem with out of date script types. |
|
|
|
The proposed protocol seems like it uses a pretty significant fraction of the bandwidth as sending the transaction. It also requires hashing the transactions in the mempool to do the 'short id matching'. The idea is receive transactions flow with stripped data (inputs and outputs converted to distinct set of 4 byte items for specified filter type). And yes transaction flow means a lot of sending the transaction. I got your point about "short id" will think how to implement it more properly. Is there really a particular reason to filter unconfirmed transactions at the expense of privacy--since what txn you fetch is still visible? With BIP 157 when a block matches the user fetches the entire block, at least somewhat preserving the anonymity set. I suppose that most common case light client receive about 2-3 payments daily, so in case we got positive test we be able use TOR with new identity and different nodes to request complete transaction. I think it should protect privacy Or am I missing something? Aside, the graph should show getblocktxn not blocktxn. . Yes. believe the 'getcfproof' message could also work by index instead of txid like getblocktxn does, for a massive bandwidth reduction. getcfproof is not use txid it use block hash. getcfproof is only actual in case we have commitments. In case no block filter commitments we should omit this step. Have you read this one https://github.com/bitaps-com/bips/blob/master/bip-block-batch-filters.mediawiki? any feedback about this draft? |
|
|
|
|
In context of compact signature format r and s 32 bytes, this is not about actual value
|
|
|
|
I don't understand why but people do it, people do crazy things use a lot of IP, scripts, change addresses to prevent blocking to get more and more testnet coins This is one of many examples: https://tbtc.bitaps.com/2NBMEXavJZV2VoBCiRFHEJ8DehgYnfM9wav8.34076971 tBTC 1 736 transactions. We created a testnet faucet to help developers and did not expect to encounter inexplicable greed of people. |
|
|
|
Bitcoin used DER signature format: Format: 0x30 [total-length] 0x02 [R-length] [R] 0x02 [S-length] [S] [sighash]
First step you should parse DER format, R and S is always 32 bytes after DER encoding compact signature = [R][S]
look at static int secp256k1_ecdsa_sig_parse(secp256k1_scalar *rr, secp256k1_scalar *rs, const unsigned char *sig, size_t size) {
const unsigned char *sigend = sig + size;
int rlen;
if (sig == sigend || *(sig++) != 0x30) {
/* The encoding doesn't start with a constructed sequence (X.690-0207 8.9.1). */
return 0;
}
rlen = secp256k1_der_read_len(&sig, sigend);
if (rlen < 0 || sig + rlen > sigend) {
/* Tuple exceeds bounds */
return 0;
}
if (sig + rlen != sigend) {
/* Garbage after tuple. */
return 0;
}
if (!secp256k1_der_parse_integer(rr, &sig, sigend)) {
return 0;
}
if (!secp256k1_der_parse_integer(rs, &sig, sigend)) {
return 0;
}
if (sig != sigend) {
/* Trailing garbage inside tuple. */
return 0;
}
return 1;
}
secp256k1_der_parse_integer used to parse R and S from DER https://github.com/bitcoin/bitcoin/blob/452bb90c718da18a79bfad50ff9b7d1c8f1b4aa3/src/secp256k1/src/ecdsa_impl.h#L99 |
|
|
|
|
Show Posts
