2
|
Bitcoin / Development & Technical Discussion / Mutator Sets: new approach to Decentralized Scalable Privacy
|
on: November 07, 2023, 07:49:36 PM
|
If anyone here that's interested in privacy and scalability has time to watch this talk or read the paper, I'd be curious to hear your thoughts about this approach. Description from youtube: Mutator sets are a solution to the problem of scalable privacy in blockchains.
A mutator set is a cryptographically authenticated data structure that allows for removal and insertion with logarithmic complexity in the number of entries.
In this talk Alan Szepieniec explains *why* a new data structure is needed to build a scalable, privacy-preserving blockchain, and *how* this new data structure works. He also describes the scalability problem that existing privacy-preserving blockchains have run into and the thought process that lead to the design of the mutator set.
Alan Szepieniec has a ph.d. in post-quantum cryptography from KU Leuven and is co-founder of the Neptune Cash blockchain which aims to bring mutator sets into real-world use to deliver a blockchain that achieves scalability, privacy, post-quantum security, and brings ZK-STARKs to layer 1.
Presented at Hackers Congress Paralelní Polis 23.
|
|
|
3
|
Bitcoin / Development & Technical Discussion / Re: consequences of --with-incompatible-bdb ?
|
on: August 23, 2019, 08:34:57 PM
|
as I recall, the blockchain database uses leveldb, but the wallet uses bdb. So if you build with a different bdb version and then create and uses a wallet with that version, then your wallet cannot be opened with a standard ( bdb v4.8 ) version of bitcoin-core. This could be an issue for you years down the road, when maybe you are trying to restore the wallet on some other computer/os.
|
|
|
4
|
Bitcoin / Development & Technical Discussion / Re: Get All Transactions Sent to a Specific Address?
|
on: August 11, 2019, 05:05:41 AM
|
Various answers to this question. 1. bitcoind does not currently have an address index, but may be getting one "soon". See this pull request. 2. There are at least a couple patches to bitcoind that add an address index. But then you've gotta build your own bitcoind and keep it maintained over time. fun. 3. There are at least two 3rd party block explorer solutions that build off bitcoind's data without requiring a custom bitcoind. I'm aware of esplora by Blockstream and bitcore-node by (cough) Bitpay, which apparently is replacing Insight. 4. btcd has an address index and an API called searchrawtransactions that is optimized with a filter to weed out unrelated vin/vout. This is the best combination of privacy and efficiency that I've found, but with a lengthy setup. 5. Various online block explorers offer APIs to search by address. Some even can search multiple addresses at the same time. But of course you lose privacy calling them with your addresses. I've been keeping a list of some of these. 6. my tool, bitprices can use btcd locally or any of the explorer APIs, and can also round-robin between them so no single service gets all your wallet addresses. If/when bitcoind offers a suitable index+api I will support it also. There is also a web frontend.
|
|
|
5
|
Other / Off-topic / Re: GitHub is shitty, why not a decentralized solution?
|
on: August 11, 2019, 04:31:08 AM
|
maybe a decentralized github clone could be implemented on maidsafe? Perhaps using gitlab code as a starting point. Or if not maidsafe, then maybe ipfs or sia for decentralized storage. But my understanding is that maidsafe facilitates decentralized computing, dynamic websites / apps, etc...
yes / no / why?
|
|
|
6
|
Bitcoin / Development & Technical Discussion / jsonrpc-cli - a simple CLI tool for one-off jsonrpc queries and debugging.
|
on: August 05, 2019, 03:56:10 PM
|
I was having issues with c-lightning and spruned a while back and I wanted to execute queries and see the raw http request and response. I couldn't find such a tool, so I made one, jsonrpc-cli. Maybe some others will find it useful when querying bitcoind, etc. This first release has the following significant features: - perform arbitrary jsonrpc requests to any jsonrpc server over http
- pass method name and arguments as command line args
- supports http basic auth
- log raw http request/response to a file
- raw or pretty printed json results, or display other structured formats: yaml, php print_r, etc
- colorized results (syntax highlighting)
- configurable request timeout
- option to display/hide jsonrpc response wrapper/envelope.
- detailed logging of each request
I intend to announce any new releases in this thread. Please report issues or enhancement requests on github.
|
|
|
7
|
Bitcoin / Development & Technical Discussion / Re: Can we call a lightning node with JSON-RPC like we can do for a Bitcoin node?
|
on: June 26, 2019, 03:27:33 PM
|
c-lightning (lightningd) has a json-rpc api. The client is lightning-cli. For available commands: Some (rough) docs are available here: https://github.com/ElementsProject/lightning/tree/master/docIt would be nice if they would be published on a wiki someplace, but google doesn't turn it up... Output of lightning-cli help: feerates style Return feerate estimates, either satoshi-per-kw ({style} perkw) or satoshi-per-kb ({style} perkb).
connect id [host] [port] Connect to {id} at {host} (which can end in ':port' if not default). {id} can also be of the form id@host
listnodes [id] Show node {id} (or all, if no {id}), in our local network view
getroute id msatoshi riskfactor [cltv] [fromid] [fuzzpercent] [exclude] [maxhops] Show route to {id} for {msatoshi}, using {riskfactor} and optional {cltv} (default 9). If specified search from {fromid} otherwise use this node as source. Randomize the route with up to {fuzzpercent} (default 5.0). {exclude} an array of short-channel-id/direction (e.g. [ '564334x877x1/0', '564195x1292x0/1' ]) from consideration. Set the {maxhops} the route can take (default 20).
listchannels [short_channel_id] [source] Show channel {short_channel_id} or {source} (or all known channels, if not specified)
invoice msatoshi label description [expiry] [fallbacks] [preimage] [exposeprivatechannels] Create an invoice for {msatoshi} with {label} and {description} with optional {expiry} seconds (default 1 hour), optional {fallbacks} address list(default empty list) and optional {preimage} (default autogenerated)
listinvoices [label] Show invoice {label} (or all, if no {label})
delinvoice label status Delete unpaid invoice {label} with {status}
delexpiredinvoice [maxexpirytime] Delete all expired invoices that expired as of given {maxexpirytime} (a UNIX epoch time), or all expired invoices if not specified
autocleaninvoice [cycle_seconds] [expired_by] Set up autoclean of expired invoices. Perform cleanup every {cycle_seconds} (default 3600), or disable autoclean if 0. Clean up expired invoices that have expired for {expired_by} seconds (default 86400).
waitanyinvoice [lastpay_index] Wait for the next invoice to be paid, after {lastpay_index} (if supplied)
waitinvoice label Wait for an incoming payment matching the invoice with {label}, or if the invoice expires
decodepay bolt11 [description] Decode {bolt11}, using {description} if necessary
help [command] List available commands, or give verbose help on one {command}.
stop Shut down the lightningd process
check command_to_check Don't run {command_to_check}, just verify parameters.
getlog [level] Show logs, with optional log {level} (info|unusual|debug|io)
fundchannel id satoshi [feerate] [announce] [minconf] Fund channel with {id} using {satoshi} (or 'all') satoshis, at optional {feerate}. Only use outputs that have {minconf} confirmations.
listconfigs [config] List all configuration options, or with [config], just that one.
sendpay route payment_hash [label] [msatoshi] [bolt11] Send along {route} in return for preimage of {payment_hash}
waitsendpay payment_hash [timeout] Wait for payment attempt on {payment_hash} to succeed or fail, but only up to {timeout} seconds.
listpayments [bolt11] [payment_hash] Show outgoing payments
listsendpays [bolt11] [payment_hash] Show sendpay, old and current, optionally limiting to {bolt11} or {payment_hash}.
listpeers [id] [level] Show current peers, if {level} is set, include logs for {id}
close id [force] [timeout] Close the channel with {id} (either peer ID, channel ID, or short channel ID). If {force} (default false) is true, force a unilateral close after {timeout} seconds (default 30), otherwise just schedule a mutual close later and fail after timing out.
disconnect id [force] Disconnect from {id} that has previously been connected to using connect; with {force} set, even if it has a current channel
getinfo Show information about this node
setchannelfee id [base] [ppm] Sets specific routing fees for channel with {id} (either peer ID, channel ID, short channel ID or 'all'). Routing fees are defined by a fixed {base} (msat) and a {ppm} (proportional per millionth) value. If values for {base} or {ppm} are left out, defaults will be used. {base} can also be defined in other units, for example '1sat'. If {id} is 'all', the fees will be applied for all channels.
listforwards List all forwarded payments and their information
ping id [len] [pongbytes] Send peer {id} a ping of length {len} (default 128) asking for {pongbytes} (default 128)
withdraw destination satoshi [feerate] [minconf] Send to {destination} address {satoshi} (or 'all') amount via Bitcoin transaction, at optional {feerate}
newaddr [addresstype] Get a new {bech32, p2sh-segwit} (or all) address to fund a channel (default is bech32)
dev-listaddrs [bip32_max_index] Show addresses list up to derivation {index} (default is the last bip32 index)
listfunds Show available funds from the internal wallet
dev-rescan-outputs Synchronize the state of our funds with bitcoind
pay bolt11 [msatoshi] [label] [riskfactor] [maxfeepercent] [retry_for] [maxdelay] [exemptfee] Send payment specified by {bolt11} with {amount}
paystatus [bolt11] Detail status of attempts to pay {bolt11}, or all
listpays [bolt11] List result of payment {bolt11}, or all
--- run `lightning-cli help <command>` for more information on a specific command
|
|
|
9
|
Alternate cryptocurrencies / Altcoin Discussion / Re: Unbreakable protection in dire need of debunking (Bitcoin bounty)
|
on: May 15, 2019, 05:02:08 PM
|
Brute force / dictionary attack the username/password ok, so despite all ork servers, etc, ultimately the security comes down to strength of user's password, correct? Because with that, the private key becomes assembled (somehow). So in a real world scenario, phishing attacks, keylogging, etc would apply. yes? re brute force attack: do you limit the number of failed login attempts and/or notify user of such? This sounds very interesting. Can you elaborate on that? What did you mean by "every user record modification could contain the private key"? I just meant that if you were to simulate user logins/actions in order to make the contest more "real" and dynamic then each time a user creates or updates a record, it could contain the same 1BTC private key (as opposed to my previous suggestion of splitting the 1BTC into lots of pieces, ie divided between users). no big deal.
|
|
|
10
|
Alternate cryptocurrencies / Altcoin Discussion / Re: Unbreakable protection in dire need of debunking (Bitcoin bounty)
|
on: May 14, 2019, 05:24:52 PM
|
If I understand correctly, the 1BTC private key is stored encrypted inside a SQL database and the encryption key is held by a user on their own device (not on the server).
As such, if an attacker is able to get into the server, even root access, full database dump, etc, they still will not be able to access the private key.
That's a good design, imho. I wish all companies would do it.
So as far as this competition/bounty goes, I doubt anyone will obtain the 1BTC.
That said, the present scenario does not accurately reflect conditions in a production environment.
In production, you would have user records being created and updated.
In this scenario, if an attacker is able to get into your web server, they should be able to modify javascript sent to the client in such a way that the client sends data unencrypted to server (or another server controlled by attacker) when creating or updating a record.
As such, I would propose that for this test/bounty to actually be useful and meaningful, you should modify the test conditions with simulated users that are regularly creating/updating records that contain valid private keys. This would probably require splitting the 1BTC into many smaller pieces.
A patient attacker with server access could sit and wait until they have collected some or all of it.
edit: or every user record modification could contain the private key for full 1BTC. Then a single breach would result in full bounty.
|
|
|
11
|
Bitcoin / Development & Technical Discussion / hd-wallet-derive v.0.4.3 released with path presets for wallet software
|
on: May 13, 2019, 12:24:28 AM
|
It's been a while. This release adds: - Path presets for common wallet software, hardware wallets, and Bip standards such as Bip44, Bip49, Bip84.
- Variables in paths for insertion of coin, account, and change values.
- Iteration can now occur at any path level, not only the deepest level. (needed by Ledger-Live)
- added --gen-words flag to control how many mnemonic words are created. [12..48]
corrected ethereum private key serialization - minor bug fixes
ExamplesLet's say we want to derive addresses for bitcoin-core software. First, we need to find out the preset identifier for this software. $ ./hd-wallet-derive.php --help-presets | head -n 7 +-------------------------+----------------------+-------------------------+------------------+---------------------------+ | id | path | wallet | version | note | +-------------------------+----------------------+-------------------------+------------------+---------------------------+ | bip44 | m/44'/c'/a'/v/x | Bip44 Compat | n/a | Bip44 | | bip49 | m/49'/c'/a'/v/x | Bip49 Compat | n/a | Bip49 | | bip84 | m/84'/c'/a'/v/x | Bip84 Compat | n/a | Bip84 | | bitcoincore | m/a'/v'/x' | Bitcoin Core | v0.13 and above. | Bip32 fully hardened |
If we want only the ids, we could use the command: $ ./hd-wallet-derive.php --help-presets --format=list bip44 bip49 bip84 bitcoincore bither breadwallet coinomi coinomi_bech32 coinomi_p2sh copay copay_hardware_multisig copay_legacy electrum electrum_legacy electrum_legacy_multi hive jaxx ledgerlive multibit_hd multibit_hd_44 mycelium samourai samourai_bech32 samourai_p2sh trezor wasabi
Deriving addresses for bitcoin-core using preset path.Using a preset means that we do not need to know the bip32 path. We can do: $ ./hd-wallet-derive.php -g --key=xprv9tyUQV64JT5qs3RSTJkXCWKMyUgoQp7F3hA1xzG6ZGu6u6Q9VMNjGr67Lctvy5P8oyaYAL9CAWrUE9i6GoNMKUga5biW6Hx4tws2six3b9c --numderive=3 --preset=bitcoincore --cols=path,address
+------------+------------------------------------+ | path | address | +------------+------------------------------------+ | m/0'/0'/0' | 1JsH5tzm2bphJySSLJ13AbFGP8KqJBYvG7 | | m/0'/0'/1' | 19in8KwQy2waqzogwnVRvh2gt7EkHDGtwg | | m/0'/0'/2' | 1CMc7jzi6ewKRzBNSCMkYzY3PU13ck6bxQ | +------------+------------------------------------+
Deriving Change addresses for bitcoin-core using preset path.We can use the --path-change flag for this. requires a preset with variable 'v' present in the path. $ ./hd-wallet-derive.php -g --key=xprv9tyUQV64JT5qs3RSTJkXCWKMyUgoQp7F3hA1xzG6ZGu6u6Q9VMNjGr67Lctvy5P8oyaYAL9CAWrUE9i6GoNMKUga5biW6Hx4tws2six3b9c --numderive=3 --preset=bitcoincore --cols=path,address --path-change
+------------+------------------------------------+ | path | address | +------------+------------------------------------+ | m/0'/1'/0' | 1B6q1KTyaa9yLHV2HTZC1rZaSKMG8KNqsp | | m/0'/1'/1' | 15RF1R9ZaSqgtaTVBDm1ySU5MQ6dZeTpZf | | m/0'/1'/2' | 1DpzhgrgWuRSnQjvLiZHMG2TAjs86znvjj | +------------+------------------------------------+
Notice that that 2nd field has changed from 0' to 1'. Similarly, the coin and account fields of a Bip44 path (or any custom path) can hold variables so that a single path preset works for various situations.
|
|
|
14
|
Bitcoin / Development & Technical Discussion / Re: Convert BIP39 to public key bitcoin by API
|
on: March 14, 2019, 04:45:22 PM
|
It is not a web service, but hd-wallet-derive can perform this for you running locally. eg: $ ./hd-wallet-derive.php --mnemonic="before muscle nice seek sign film west capable cube hundred wisdom lawn" --numderive=5 --cols=path,address -g
+-----------------+------------------------------------+ | path | address | +-----------------+------------------------------------+ | m/44'/0'/0'/0/0 | 12fMUNE8fGstCNxxK7tnRWZQ4BC8qaGvvi | | m/44'/0'/0'/0/1 | 19rG3WrG8yh2mbdoXXHBu1AvkpB19aqjnN | | m/44'/0'/0'/0/2 | 1Bz5mXQShd4rskT7bMcL8x1KyPQ8zxDbeu | | m/44'/0'/0'/0/3 | 16Tyzt9vP7rzjPEaUPrt21psvJgg5weoBN | | m/44'/0'/0'/0/4 | 1KumLyHKAoAEwzGJPK6q4DQBwtZcNfXzq6 | +-----------------+------------------------------------+
You can call it from your program in any language. Hi, I need a Web service that be able to change BIP39 words to other bit coin addresses. I search this website https://iancoleman.io/bip39/ but I could not find the answer. For example I Wana give these words "before muscle nice seek sign film west capable cube hundred wisdom lawn"to code and then have an outcome with public key Bitcoin. Please help me.Thanks.
|
|
|
15
|
Bitcoin / Development & Technical Discussion / Re: Decentralize the network with Mining Share Transactions
|
on: November 01, 2018, 04:47:10 PM
|
Under section 2 I think you should mention that mining pools give pool operators enormous leverage/power when it comes to signaling for soft/hard forks.
Basically, a whole bunch of miners are pointing hash power at the pool. On their own, the miners might never upgrade or signal at all (thus preserving status quo) or might go in different directions like cats. But the pool op can make one little change and suddenly all that hash power is signalling for whatever op wants. Many/most miners do not care enough to switch to another pool as they are driven by profit incentive and changing to another pool requires work/effort.
It's kind of like if I sign up with an insurance company for insurance, but hidden in the fine print is that the insurance company will vote on my behalf in upcoming government elections, so long as I continue as a customer.
|
|
|
16
|
Bitcoin / Development & Technical Discussion / Re: Is Bitcoin infrastructure too Chinese? What should be done technically?
|
on: October 18, 2018, 05:07:35 AM
|
I still think that PoCW will need to be deployed successfully in an altcoin and tested in the wild for a good while before the bitcoin community will seriously consider it.
There are a few folks that take the pool problem seriously and that value real mining decentralization, but I think not enough to make a difference at this time. I'm happy to be wrong on this point of course, but if others thought like I do then only a few innovative coins would have any value right now, and PoS and tokens wouldn't be a thing...
If you get a library of working code and decide to launch an altcoin with it, let me know. I might be able to help out.
|
|
|
17
|
Bitcoin / Development & Technical Discussion / Re: Is Bitcoin infrastructure too Chinese? What should be done technically?
|
on: October 13, 2018, 12:21:57 PM
|
I agree that pools are the biggest problem. They logically result from the winner take all algo. I postulate that in a theoretically ideal POW system, every single participant that contributes cycles/work towards securing the network would be rewarded in direct proportion to their contribution. ie, even if they only calculate 1 hash during a given block and do not match target difficulty. How to achieve that? I have no idea. haha. But I'd like to see more discussion/brainpower/research on it. First question: Is the above scenario ideal/desirable for maximizing distribution of work across non-colluding parties? Or the incentives are flawed somehow? Followup question: What technical obstacles prevent it, and how might they be overcome? (assuming a brand-new system with no legacy code/chain). I will leave these open-ended for now... It is odd, imo, too much concerns about ASICs and zero interest in the situation with pools.
|
|
|
18
|
Bitcoin / Development & Technical Discussion / Re: The duplicate input vulnerability shouldn't be forgotten
|
on: September 24, 2018, 04:10:21 PM
|
As I see it: - The consensus layer protocol needs to be formally specified and versioned. Bugs and all. The spec should be updated before consensus code
- consensus layer code should be changed as rarely as possible. if ever.
I would be very happy to see a software fork that makes a promise to its users that consensus layer code will not be changed except for critical bug fixes. I think this will have a couple of important effects: 1. Foster growth of the bitcoin sub-community whose priority is to resist changes to the protocol. Those who value stability, predictability, immutability in an asset/currency over shiny new things. 2. Create a technical means for this community to have its voice heard. Possibly blocking future soft forks from occurring, or at least keeping the "old ways" alive. my still-running pre segwit node is not affected by this bug. just sayin.
|
|
|
|