|
4
|
Economy / Service Announcements / Re: Encrypted paywall
|
on: November 23, 2020, 07:34:45 PM
|
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. |
|
|
|
|
5
|
Economy / Service Announcements / Encrypted paywall
|
on: November 15, 2020, 03:09:20 PM
|
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. |
|
|
|
|
15
|
Bitcoin / Development & Technical Discussion / Re: Block Batch Filters for Light Clients BIP draft
|
on: November 16, 2019, 07:27:33 AM
|
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. |
|
|
|
|
16
|
Bitcoin / Development & Technical Discussion / Re: Block Batch Filters for Light Clients BIP draft
|
on: November 16, 2019, 12:13:41 AM
|
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? |
|
|
|
|
20
|
Bitcoin / Development & Technical Discussion / Re: Is possible get public key from signature?
|
on: October 15, 2019, 06:06:21 PM
|
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
