Search content
Sort by
Showing 20 of 408 results by fbueller
Re: Derive in batches, addresses of an xpub programmatically.
Quote
You could always check out the extension for libsecp256k1 https://github.com/bit-wasp/secp256k1-php
(Note for googlers: the default branch does NOT compile for PHP5. Run Code:
git checkout v0.0.8
in directory - secp256k1-php , before ./configure)Thanks for this, but I can't figure out how to use or even understand it. Plus the examples in the README are for the latest branch which doesn't work with PHP5. So have no examples or documentation
. Anyhow, this looks like what I want? :
Quote
Public Key tweak by addition
secp256k1_ec_pubkey_tweak_add(resource $context, resource $publicKey, string $tweak32) takes the given $tweak value, converts it to a point, and adds the point to the $publicKey point. The result is written to the provided $publicKey memory location.
This function is useful for deterministic key derivation.
secp256k1_ec_pubkey_tweak_add(resource $context, resource $publicKey, string $tweak32) takes the given $tweak value, converts it to a point, and adds the point to the $publicKey point. The result is written to the provided $publicKey memory location.
This function is useful for deterministic key derivation.
btw What is 'tweak' here ? Googling doesn't seem to help.
My Goal is to just generate public keys from an xpub. any guidance would be much appreciated
ty
Did you miss the tests directory
Don't install it too use its functions directly - bitcoin-php will adapt between it and PHPECC, so you don't write code any differently. Re: Derive in batches, addresses of an xpub programmatically.
hd-wallet-addrs seems to wrap `bitwasp/bitcoin` which has advanced several versions since then (bitcoin-lib-php has been retired), including one that sped up elliptic curve operations a bit. You could always check out the extension for libsecp256k1 https://github.com/bit-wasp/secp256k1-php
I maintain `bitwasp/bitcoin`which is available through composer. It lets you do quite a lot, and no bitcoind required. https://github.com/Bit-Wasp/bitcoin-php/blob/master/src/Address/AddressFactory.php#L87 contains the function to check an address.
Track created outputs from new blocks which fund the scriptPubKeys your application knows about, removing them if they are reorged out, otherwise update the confirmation count if the chain is elongated by one block.
Once an output gains 6 confirmations, notify your application to process them further.
Once an output gains 6 confirmations, notify your application to process them further.
You can't do this with Ledger AFAICT, it uses HD wallets under the hood.
They're BIP39 passphrases, so there isn't a way to convert the key you have to a suitable passphrase.
You could write your own vanitygen to derive hierarchical keys where the derived path for Ledger (they probably follow a BIP for this) happens to match the prefix you use, and load that onto the ledger wallet.
I'm still not sure why you would want to do this either - only the first derived key will match your vanity prefix, and unless you start using the HD chain it's a wasted exercise IMO!
Key re-use is bad, mkay.
They're BIP39 passphrases, so there isn't a way to convert the key you have to a suitable passphrase.
You could write your own vanitygen to derive hierarchical keys where the derived path for Ledger (they probably follow a BIP for this) happens to match the prefix you use, and load that onto the ledger wallet.
I'm still not sure why you would want to do this either - only the first derived key will match your vanity prefix, and unless you start using the HD chain it's a wasted exercise IMO!
Key re-use is bad, mkay.
They have an order book, tap into exchanges to facilitate payments, and maybe act as a market maker.
Shapeshifts JS code is relatively easy to work with to fulfill the payment side of things. You probably don't want to reinvent the wheel if it's just for you.
Shapeshifts JS code is relatively easy to work with to fulfill the payment side of things. You probably don't want to reinvent the wheel if it's just for you.
Re: Is it possible to integrate a reputable Bitcoin wallet service in a website?
Im planning to build a peer to peer marketplace website where the users themselves will be the buyers and sellers, I want each user to have his/her own Bitcoin wallet to enable each of them to send, receive and view their individual Bitcoin wallet balance on the website.
However, I dont want to use a bitcoin wallet service which I would build from scratch myself or hire a developer to do it for me, instead, I would prefer if Im able to integrate an existing reputable Bitcoin wallet service provider (e.g. Bitgo, Blockchain, Coinbase e.t.c) in my website.
If the integration is possible, I would not have to worry much about securing the users Bitcoin wallets on the site against hackers, making sure the users' wallets are secured would be the problem of the Bitcoin wallet service provider I'm using. I, the website owner/admin, don't want to have access to the users' wallet without their permission, I believe this integration will enable me to achieve that as well.
I welcome replies that answethe r this question or ideas that are better than what I'm asking. Thanks
However, I dont want to use a bitcoin wallet service which I would build from scratch myself or hire a developer to do it for me, instead, I would prefer if Im able to integrate an existing reputable Bitcoin wallet service provider (e.g. Bitgo, Blockchain, Coinbase e.t.c) in my website.
If the integration is possible, I would not have to worry much about securing the users Bitcoin wallets on the site against hackers, making sure the users' wallets are secured would be the problem of the Bitcoin wallet service provider I'm using. I, the website owner/admin, don't want to have access to the users' wallet without their permission, I believe this integration will enable me to achieve that as well.
I welcome replies that answethe r this question or ideas that are better than what I'm asking. Thanks
Thank you for the final remark - the fact you are concerned with the safety of your customers fund is encouraging.
AFAICT, you could use something like BitGo, but still you are still trusted to orchestrate transactions which take place between users. What if you lied one day?
I have a suggestion. Don't offer a wallet. Securely accept with seller recipient addresses, and have buyers pay directly to them. With bitcoin, if you're the platform, it's possible to avoid handling the coins in any capacity. This is the only safe way to not let your people down.
Wallets are not designed to be integrated anywhere. Leaving OAUTH2 credentials which can call the 'sendMoney' API call... you're gonna have a bad time. (worse, I've seen bitcoin wallets offering static API keys for use in integrations. I wept.)
Re: How to come from a secret exponent to a Bitcoin private key?
Hey Guys,
I just made a batch file which gives out random secret exponents (like on offlinebitcoins.com) into a text file.
Does anyone of you know a programm or some other really fast way how to transform this list with secret exponents into a list with their Bitcoin private keys?
Best regards,
Patrick
I just made a batch file which gives out random secret exponents (like on offlinebitcoins.com) into a text file.
Does anyone of you know a programm or some other really fast way how to transform this list with secret exponents into a list with their Bitcoin private keys?
Best regards,
Patrick
A secret exponent in this context usually means the number multiplied against the generator point.. which IS the private key.
Are you looking to encode it differently, or what are you trying to do?
Something great is the bitcoinconsensus.h library, for verifying transaction signatures. Check https://github.com/bitcoin/bitcoin/blob/master/src/script/bitcoinconsensus.cpp This can be installed as a shared library, and language bindings expose this functionality to other languages.
Eventually, we'll have a full consensus library, which will make building these tools much easier and safer.
Eventually, we'll have a full consensus library, which will make building these tools much easier and safer.
⭐ Merited by ETFbitcoin (1)
Why not go for python-bitcoinlib, or pybitcointools? They include functions to do this.
The procedure you need is:
- Serialize the public key, paying attention to whether the private key requires compression for public keys.
- Hash the serialized public key with RIPEMD160(SHA256(X))
- Base58_check encode the hash, using \x00 as the version byte.
The procedure you need is:
- Serialize the public key, paying attention to whether the private key requires compression for public keys.
- Hash the serialized public key with RIPEMD160(SHA256(X))
- Base58_check encode the hash, using \x00 as the version byte.
What exactly are your requirements here? Most wallets aren't engineered in the way blockchain.info do it. They're essentially a bank for your keys, locally decrypting your wallet and sending coins. A lot of wallets won't take the risk of offering that service.
The closest to your setup is probably calling bitcoin-cli. Otherwise, look at some of the other wallet API's. Typically, you also need to use a scripting language to create a signed transaction and broadcast it through the API.
The closest to your setup is probably calling bitcoin-cli. Otherwise, look at some of the other wallet API's. Typically, you also need to use a scripting language to create a signed transaction and broadcast it through the API.
Hash the string and split it up into 8 4-byte chunks, using those as your indexes.
Code:
Seed : 41414141414141414141414141414141
Domain : bitcointalk.org
Hash : f245bd5620ee79314f48d9e9641a5406bd03745f6ac516e2801ef6ccbfe40ced
Path : 1917173078h/552499505/1330174441/1679447046/1023636575h/1791301346/2029260h/1071910125h
Address : 13viHo9wVRY8TyTW9YJfGKTaGiJSksPmCV
Domain : bitcointalk.org
Hash : f245bd5620ee79314f48d9e9641a5406bd03745f6ac516e2801ef6ccbfe40ced
Path : 1917173078h/552499505/1330174441/1679447046/1023636575h/1791301346/2029260h/1071910125h
Address : 13viHo9wVRY8TyTW9YJfGKTaGiJSksPmCV
Insight servers are open, but you need to find them. Simple curl requests will do.
Stratum servers (they power electrum) do the same, but you can find a list of them using IRC. Stratum offers SPV proofs for a transaction, so you can prove it was in the blockchain and they're not feeding you lies.
I wrote a PHP library for working with stratum servers. https://github.com/Bit-Wasp/stratum-php
It might be worth writing a library in JS to talk to stratum servers, I haven't seen one yet.
Edit: Avoid using the BC.I API. They've had extraordinary number of problems. Just use something that talks to a full node.
Stratum servers (they power electrum) do the same, but you can find a list of them using IRC. Stratum offers SPV proofs for a transaction, so you can prove it was in the blockchain and they're not feeding you lies.
I wrote a PHP library for working with stratum servers. https://github.com/Bit-Wasp/stratum-php
It might be worth writing a library in JS to talk to stratum servers, I haven't seen one yet.
Edit: Avoid using the BC.I API. They've had extraordinary number of problems. Just use something that talks to a full node.
⭐ Merited by ABCbits (4)
When I send you money, I am only sending it to a Bitcoin address; I don't know your public key.
I know that.
Any public key that hashes to that Bitcoin address can spend the money.
But this is wrong. The public key is provided in the scriptSig, and that's what signatures are checked against. It's also how the hash is checked in the first place.
You can find a public key that collides with the hash, and pass the first part of a p2pkh script. If the hash passes, all that's left is OP_CHECKSIG, which still wouldn't pass with the dodgy key.
⭐ Merited by ABCbits (2)
I expect the hash test is first is to avoid unnecessary resource consumption. If the hash of the public key doesn't match, it won't even try to verify the signature.
If two public keys can share an address, a signature from the respective private key is still required to actually spend funds, no?
P2SH might be worse off because of HASH160. P2PKH still requires an OP_CHECKSIG, whereas if you find a script tailored to you that collides with a script-hash address, you could spend those funds using your version of the script. Either case still requires a SHA256 collision however, making this prospect unlikely.
If two public keys can share an address, a signature from the respective private key is still required to actually spend funds, no?
P2SH might be worse off because of HASH160. P2PKH still requires an OP_CHECKSIG, whereas if you find a script tailored to you that collides with a script-hash address, you could spend those funds using your version of the script. Either case still requires a SHA256 collision however, making this prospect unlikely.
OP is confusing two different serialization artifacts.
Outputs look like this:
[fixed 64bit integer][output script]
When writing a parser, your software needs to know how long the output script section is, so the length comes before it.
That way the system knows when it has finished, or if there was a problem. Assuming it's a valid transaction, the network
knows the 64bit integer is actually the number of satoshis, and second part is the output script.
The contents of output script are expressed as Bitcoin Script. This involves different length serialization, one involving PUSHDATA opcodes.
As OP saw, inside the output script, there's a public key with 0x41 (=65) as a length. If we start to use larger pieces of data, this would look like:
PUSHDATA1 0xff [256 byte long input]
PUSHDATA2 0xffff [65535 byte long input]
You don't have to explicitly declare the pushdata opcodes for short length, but for multi-byte length encoding, you use PUSHDATA1/2/4.
Outputs look like this:
[fixed 64bit integer][output script]
When writing a parser, your software needs to know how long the output script section is, so the length comes before it.
That way the system knows when it has finished, or if there was a problem. Assuming it's a valid transaction, the network
knows the 64bit integer is actually the number of satoshis, and second part is the output script.
The contents of output script are expressed as Bitcoin Script. This involves different length serialization, one involving PUSHDATA opcodes.
As OP saw, inside the output script, there's a public key with 0x41 (=65) as a length. If we start to use larger pieces of data, this would look like:
PUSHDATA1 0xff [256 byte long input]
PUSHDATA2 0xffff [65535 byte long input]
You don't have to explicitly declare the pushdata opcodes for short length, but for multi-byte length encoding, you use PUSHDATA1/2/4.
Re: Simple logic to avoid confusing tx fee with transaction amount
It's possible the person wasn't using Bitcoin Core at all, and crafted the transaction themselves.
I just find it unlikely someone would spend 9x 30BTC outputs in a raw transaction that was only a test, and ignore the absurdly high fee warning .
I just find it unlikely someone would spend 9x 30BTC outputs in a raw transaction that was only a test, and ignore the absurdly high fee warning .
There seems to be a consensus of some people here that PoS is not secure, but I didn't see anyone elaborate as to why. Is it the monopoly problem or is there something else?
Please (really, pretty please) don't send me to Google it. I'm a newb, I admit, but I also spent a while reading the PoS vs. PoW posts and articles, and couldn't find any other consensus argument beside the monopoly problem.
Please (really, pretty please) don't send me to Google it. I'm a newb, I admit, but I also spent a while reading the PoS vs. PoW posts and articles, and couldn't find any other consensus argument beside the monopoly problem.
IIRC there are some academic papers on the topic, however I don't have any interesting links to hand.
There are some deep problems with POS. The election of who should stake *should* be a lottery that participants have no control over. One vulnerability arises because the election process relies on the block chain to generate entropy. Elected people get to write to the block chain, thus changing who should stake next.
Without something like POW, it's possible for someone to retroactively take the block chain, alter it so *they* are chosen, and then they can create the next block. He can even produce a block that allows him to stake again.. and so on.
POW prevents this, making more difficult with every block to rewrite the chain. POS doesn't have anything like this, the CPU power required to grind variations of the chain which favour the attacker is rather small.