Bitcoin Forum
April 26, 2024, 11:16:47 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 »
1  Economy / Service Announcements / Re: [ANN] bitaddress.org Safe JavaScript Bitcoin address/private key on: November 16, 2023, 06:47:17 AM
Looks like some bitaddress wallets might be vulnerable to "randstorm" vulnerability in BitcoinJS lib.   Anyway bitaddress.org is named here:

https://www.unciphered.com/blog/randstorm-you-cant-patch-a-house-of-cards

Something that bitaddress users might want to check into.
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:

Quote
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:

Code:
lightning-cli help

Some (rough) docs are available here:

https://github.com/ElementsProject/lightning/tree/master/doc

It would be nice if they would be published on a wiki someplace, but google doesn't turn it up...

Output of lightning-cli help:

Code:
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
8  Bitcoin / Development & Technical Discussion / Re: Can you shcedule payments with a wallet? on: May 15, 2019, 07:01:22 PM
If I wanted to do it, I would use bitcoin-core with a script that calls sendtoaddress from cron. 

There may be other ways, but I think that is the most straightforward and trustless.
9  Alternate cryptocurrencies / Altcoin Discussion / Re: Unbreakable protection in dire need of debunking (Bitcoin bounty) on: May 15, 2019, 05:02:08 PM
Quote
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?

Quote
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

Examples

Let's say we want to derive addresses for bitcoin-core software.  First, we need to find out the preset identifier for this software.

Code:
$ ./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:

Code:
$ ./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:

Code:
$ ./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.

Code:
$ ./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.
12  Bitcoin / Development & Technical Discussion / Re: How to create a Bech32 (bc1) address with PHP standalone? on: May 01, 2019, 03:25:39 PM
Bitwasp is not of much help in this regard.

I'm not sure why you say this.  bitwasp has a bech32 example.

 hd-wallet-derive uses bitwasp and spits out bech32 as well as p2sh and legacy addresses for a given key.  You can check the source if you like.

I do think that bitwasp makes it harder than need be.  See this issue.
13  Bitcoin / Development & Technical Discussion / Re: Need commandline tool generate bech32 on: May 01, 2019, 03:01:40 PM
https://github.com/dan-da/hd-wallet-derive
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:

Code:
$ ./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.
19  Bitcoin / Development & Technical Discussion / Re: Step by step guide to go from public key to a Bech32 encoded address on: September 03, 2018, 09:35:48 AM
nice.  why not add to bitcoin wiki?
20  Bitcoin / Development & Technical Discussion / Re: Getting rid of pools: Proof of Collaborative Work on: August 28, 2018, 07:17:38 AM
bump.  any updates on this?    code or design wise...
Pages: [1] 2 3 4 5 6 7 8 9 10 11 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!