If you potentially need to send refunds then the only correct way is to ask the user to provide a refund address at the time of payment. The concept of a single guaranteed "from address" simply does not exist in bitcoin. how resolve this problem?
what function rpc-api need use?
i need know sender wallet for refund amount.. |
|
|
|
|
can someone please explain how fermat differs from maidsafe?
|
|
|
|
from: http://bitcoin.stackexchange.com/questions/43827/is-the-lightning-network-a-proof-of-stake-systemCalling Lightning a Proof-of-Stake system is orthogonal to the concept usually labeled as PoS. Him having done so will just generate loads of confusion.
What we usually describe as PoS is a mechanism to achieve distributed consensus among a network of participants. Staking there is providing updates to the whole network's state, where you earn fees for contributing to the validity and the security of the network.
On the other hand, Lightning Network is a system of bilateral smartcontracts, where you may earn a fee by providing liquidity to other users. Nodes along a payment path don't provide any proof whatsoever, they merely forward a payment. There is no global consensus in Lightning, contracts are created, verified, and executed between two or a small number of participants. Any need to create consensus in the case of disagreement is provided by the proof-of-work of the Bitcoin network.
In other words, it's not really proof of stake. You can earn fees, but not "interest". Also, Lightning Network devs are insistent that the fees earned will be tiny because there is near zero cost to entry. |
|
|
|
-- personnal wallet /0'/
-- current account /0'/0'/
-- restaurants /0'/0'/0'/
-- beers /0'/0'/1'/
-- food /0'/0'/2'/
What does this even mean? Are you implying that "current_account" can access the keys of restaurants, beers, and food, in order to present a summary balance for all three? ok, I can see that. But then what if I try to make a spend from "current account"? Does it use a key from restaurants, or from beers, or from food, or from itself? what if "current account" does not have any keys with funds but "beers" does? To me, the concept doesn't really make sense. Now, if you call "restaurants" a wallet, and "current account" and "personal wallet" wallet groups, then that makes sense. So a wallet group could aggregate wallet info in read-only fashion. And the grouping data is basically app-specific and does not have to be portable between wallet software. Admittedly, it would be nice if there were a common format for specifying wallet names, as well as wallet groups. But that's outside the scope of Bip 44. |
|
|
|
-alertnotify=<cmd> Execute command when a relevant alert is received or we see a really long fork (%s in cmd is replaced by message) -blocknotify=<cmd> Execute command when the best block changes (%s in cmd is replaced by block hash) -walletnotify=<cmd> Execute command when a wallet transaction changes (%s in cmd is replaced by TxID) So for individual transactions, you would want to use walletnotify, eg: bitcoind -walletnotify=/path/to/script.php %s Then in script.php, you could do something like: <?php
$tx = $argv[1];
$txinfo = json_decode( `bitcoin-cli gettransaction $tx` );
if( $txinfo['confirmations'] >= 3 ) {
// update mysql if necessary.
}
of course with sanitization, error checks, etc.... ;-) If you are likely to have more than one tx in a given block, a more efficient way to do it can be to include the block-hash with the tx in the db, so you can look up all tx by block. Then use blocknotify instead of walletnotify. edit: and don't forget that the txid can change due to transaction malleability. |
|
|
|
The default is to stop after 20. Unfortunately some wallet software such as very old versions of Copay generated a new address each time the user clicks "receive" button, and therefore may have gaps larger than 20. As far as I know, they all use contiguous addresses. Also, if you need change addresses you must check (relative) 1/n in addition to 0/n. If you're just looking for a quick tool for wallet discovery, you may find this helpful: CLI: https://github.com/dan-da/hd-wallet-addrsWeb: https://mybitprices.info/hd-wallet-addrs.html |
|
|
|
then, after just a mobile phone verification, he will be able to start trading then, I won't be using this service. |
|
|
|
|
and this code should be trusted because.....?
|
|
|
|
I took a quick look at the NAV Coin website. The following text is enough to give me major doubts. NAV Coin is the worlds first fully anonymous cryptocurrency. NAV Coin offers optional anonymous transactions that are sent through our double encrypted network of servers which all run on decentralized block chain technology. fully anonymous... ok cool! except: optional anonymous transactions. fail. imho the the only coin that may ever be able take the mantle away from bitcoin is one that makes all transactions anon by default so that the funds are fully fungible. If anon tx are an optional step then many/most will not use them and thus any anon tx automatically look suspicious and are also easier to de-anon using various techniques because they are only mixed in with a small subset of total tx. I did not even get as far as trying to figure out HOW the anon tech works. The above text alone is enough to sour me on the concept. I don't mean to be a downer, just calling it like I see it. Hi there, Are you are aware that NAV coin is has a fully anonymous transaction system and a fully anonymous chat system. Check it out http://www.navajocoin.org/ They are a great coin to invest in at the moment as well as they are in process of decentralising their anonymous system. Happy trading  |
|
|
|
thx, if you get a chance please try it out with a real wallet (all addresses in wallet) and let me know how it goes for you. Very cool project. I tried the pizza address and that is crazy to see the history. I tried one of mine and it worked well. Nice work.
|
|
|
|
@patatas I almost forgot. I was messing around with toshi for a while before I settled on btcd, and I actually implemented a patch for filtering by address in toshi. I submitted it but they wanted some changes I haven't had time to make, so for now the only way to get it is from my forked repo here: https://github.com/dan-da/toshiThe pull request is here: https://github.com/coinbase/toshi/pull/208 |
|
|
|
Is the API Restful?
The only APIs referred to are those of bitcoin API providers such as blockchain.info, blockr.io, insight.bitpay.com, btcd, etc. Each API differs, but for the most part they are RESTful, yes. What about the scalability?
The bitprices CLI utility is a single threaded, single process program written in PHP. It queries API providers for transaction history and queries bitcoinaverage.com for BTC price history. Transaction history is normally queried once per input address. ( though the internal interfaces support multiple addresses if the provider API does ). The fastest and most scaleable way to run it is to query a local instance of btcd, which has been optimized for this use case in the latest release and supports filtering returned transaction inputs/outputs by the input address. Even still, for addresses with thousands of transactions the queries can take some time. The bitcoinaverage data is cached on disk after the first request each day, so is quite fast. The command line interface could be used with default C++'s compiler?
I'm not sure what you mean. The bitprices CLI is written in PHP and can be executed from any shell environment with a recent version of PHP installed. See the included README. I'm looking for an alternative to Toshi Fork ,having the unrelated inputs.outputs filtered is my first priority.
Then you will probably want to take a close look at btcd. Specifically the searchrawtransactions API. I submitted a patch that includes a new parameter filteraddrs which is a list of addresses. Any inputs or outputs unrelated to those addresses will be filtered out. The patch was included in btcd v0.12.0-beta. Depending on your needs, it might help you. Good project there man!
thx! |
|
|
|
I just made a minor release to the CLI tool and also the web tool. Web Changes: Added an option "Generate Only" to generate a fixed (user-defined) number of addresses without checking if each is used or not. This speeds up processing and is useful for pre-generating addresses and other use cases. CLI Changes: This version adds support for blockr.io as a backend API provider and updates documentation. https://github.com/dan-da/hd-wallet-addrs/releases/tag/hd-wallet-addrs-v0.1.364c2549 bump version to hd-wallet-addrs-v0.1.3 7f22536 Add legacy Copay gap limit warning 7e35d87 update README with blockr.io info 3eec473 add a blockr test case 6c8e2e9 added support for blockr.io API d43d7b8 document --api=roundrobin feature 141c8fc update README with latest usage |
|
|
|
|
consider this:
If bitcoin were easy to change at the consensus level, why would you trust in it?
|
|
|
|
Go into your wallet settings, Advanced, Wallet Information. Find the section Extended Public Keys. There are actually multiple xPubKey if you are using anything except a 1 of 1 wallet. If you are using an M of N wallet with more than one xPubKey and you or your counterparty need to generate addresses in advance, you may find this tool helpful: https://mybitprices.info/hd-wallet-addrs.htmlCan it be derived from an address itself? no. |
|
|
|
i keep mine on a usb thumb drive in a vault, my coins are safe for ever
until the thumb drive stops working. paper is proven to last centuries, properly stored. usb drives, not so much. even better than paper would be engraving/etching on a metal that doesn't rust such as aluminum. Should survive a fire. they sell aluminum or copper tags for this purpose that can be engraved with a regular ball point pen. on amazon. |
|
|
|
nice writeup. minor nits: Segwit was in fact originally planned as a hard fork, but the developers realized that it could be done as a soft fork and doing so would be safer than a soft fork. Segwit is a cludgy hacked together and unready software Better: Segwit is kludgy hacked together software that is not ready. |
|
|
|
|
Show Posts
