Address reuse - Bitcoin Wiki

Ravencoin Open Developer Meeting - 1/4/2019

[14:04] Hi everyone! [14:04] :dabbitwave: [14:04] Hey Everybody! [14:04] Hello 😃 [14:04] Sorry we're getting started a bit late. [14:04] Topics: SLC Meetup (March 15th) [14:04] 👋 [14:04] Roadmap breakdown - posted to github [14:05] IPFS (integration) [14:05] greetings 👋 [14:05] So, SLC Meetup on the 15th! [14:05] Great! [14:05] Hi! [14:06] Hi all — a special thanks to the developers and congratulations on an amazing first year!!! # [14:06] <[Dev] Blondfrogs> Hello Everyone! [14:07] We have a tentative agenda with @Tron , @corby speaking. [14:08] We would like to have nice walkthrough of the Raven DevKit for the meetup. [14:08] We are planning on hosting a meetup in SLC at the Overstock building on March 15th from 6:00pm-9:00pm. It is free admission, but there is a page on meetup.com where people can rsvp so that we have a somewhat accurate headcount for food. [14:08] sup guys [14:08] hey russ [14:09] We are planning on having a few speakers and have allotted a bit of time at the end for people to meet and greet each other. [14:09] can you guys link us to the page somewhere when thats available? 😄 [14:10] free food?! [14:10] todays topic? [14:10] yeah can we indicate pepperoni pizza [14:10] Sounds good to me @Jeroz Nothing ordered yet though. 😃 [14:10] only pepperoni pizza is served at true blockchain meetings right [14:10] :blobhide: [14:10] Absolutely. The itinerary just needs to be finalized and then I'll make a broad post about the rest of the details. [14:11] https://www.meetup.com/Salt-Lake-City-salt-lake-city-Meetup/ [14:11] 😭 so far away [14:11] West Coast! [14:11] @MTarget But there's pizza, so worth the travel time. [14:11] lol [14:12] I'll be watching the stream if its available since i'm from montreal/canada 😛 [14:12] Ah yes, I love $300 pizza 😉 [14:12] as long as I get to see your smiling faces @Tron @RavencoinDev then it's worth the time [14:12] We'll be there. [14:12] We'll be messaging additional details as they get finalized. [14:12] Greeting and salutations! [14:12] sup [14:13] Hey, $300 is considerably cheaper than 2 $3,700,000 pizzas. [14:14] Ok, switching topics... [14:14] yeah its a way to fly, [14:14] question is whether those piza's will be paid for in RVN coin or not :ThinkBlack: [14:14] Roadmap [14:14] It hasn't changed, just added some detail. [14:14] https://github.com/RavenProject/Ravencoin/tree/masteroadmap [14:15] nice [14:15] This now links to a breakdown for messaging, voting, anti-spam, and rewards (dividends) [14:15] will there be any additional RPC functionality coming in the future, thinking in terms of some functions that are only available in ravencore-lib [14:15] apologies if now is not time to ask questions, i can wait for later [14:15] "Phase 7 - Compatibility Mode" - that's new 😮 [14:15] The protocol for messaging is pretty well established, but the rest isn't in stone (code) yet. [14:16] can you give us details on compatibility mode? [14:16] In broad brush strokes. [14:17] The idea is to allow ravend to act as a daemon that looks like a single coin. [14:17] so ravend that only works with the bitcoin asset? [14:18] interesting [14:19] So you start it with an option to only work with a single asset/token account or something? [14:19] hmm compelling what is the reason for this? some kind of scale or performance? [14:19] ^ [14:19] Example: Configure ravend to listen for transfer RPC call for senttoaddress or sendfrom, but for a specific asset. This would allow easy integration into existing system for assets. [14:20] Only the daemon or the whole wallet UI? [14:20] yeah thats great, rpc functions dont allow us to do this yet, if i recall [14:20] or at least we depend more on ravencore lib [14:20] so like asset zmq [14:20] that's smart [14:20] @Tron it also sounds like it makes our life easier working with RPC, instead of core all the time for some functionality [14:21] if i understand correctly anyways [14:21] So you could run numerous instances of ravend each on their own network and RPC port, each configured for a different asset. You would need some balance of RVN in each one to cover transaction fees, then. [14:21] id be curious to know what all the advantages are of this [14:21] one more question, how would i decentralize the gateway between bitcoin mainnet/ravencoin mainnet? in the current RSK implementation they use a federated gateway, how would we avoid this? [14:21] it sounds neato [14:21] Just the daemon. The alternative is to get exchanges to adapt to our RPC calls for assets. It is easier if it just looks like Bitcoin, Litecoin or RVN to them, but it is really transferring FREE_HUGS [14:22] That makes sense. Should further increased exchange adoption for each asset. [14:22] hmm yeah its just easier for wallet integration because its basically the same as rvn and bitcoin but for a specific asset [14:22] so this is in specific mind of exchange listings for assets i guess [14:23] if i understand rightly [14:23] @traysi Gut feel is to allow ravend to handle a few different assets on different threads. [14:23] Are you going to call it kawmeleon mode? [14:23] Lol [14:23] I read that as kaw-melon mode. [14:24] same lol [14:24] so in one single swoop it possible to create a specific wallet and server daemon for specific assets. great. this makes it easier for exchanges, and has some added advantages with processing data too right? [14:24] Still keeping a RVN balance in the wallet, as well, Tron. How will that work is sendtoaddress sends the token instead of the RVN? A receive-RVN/send tokens-only wallet? [14:25] @traysi Yes [14:25] sendtoaddress on the other port (non RVN port) would send the asset. [14:25] This will be a hugely useful feature. [14:25] ^ [14:26] @Tron currently rpc function not support getaddresses senttowallet and this has to be done in ravencore lib, will this change you propose improve this situation [14:26] Config might look like {"port":2222, "asset":"FREE_HUGS", "rpcuser":"hugger", "rpcpass":"gi3afja33"} [14:26] how will this work cross-chain? [14:28] @push We'd have to go through the rpc calls and work out which ones are supported in compatibility mode. Obviously the mining ones don't apply. And some are generic like getinfo. [14:28] ok cool 👍 cheers [14:29] for now we continue using ravencore lib for our plans to keep track i just wondering if better way [14:29] as we had some issue after realising no rpc function for getting addresses of people who had sent rvn [14:29] @push | ravenland.org all of the node explorer and ravencore-lib functionality is based on RPC (including the addressindex-related calls). Nothing you can't do with RPC, although I'm not sure of the use cases you're referring to.. [14:29] interesting, so ravencore lib is using getrawtransaction somehow [14:29] i thought this may be the case [14:29] that is very useful thankyou for sharing this [14:30] look into addressindex flag and related RPC calls for functions that operate on addresses outside your wallet [14:30] thank you that is very useful, tbh i am not very skilled programmer so just decoding the hex at the raven-cli commandline was a challenge, i shall look more into this, valued information thanks as this was a big ? for us [14:31] Ok, things have gone quiet. New topic. [14:31] IPFS (integration) [14:31] GO [14:33] ... [14:33] <[Dev] Blondfrogs> So, we have been adding ipfs integration into the wallet for messaging. This will allow the wallets to do some pretty sweet stuff. For instance, you will be able to create your ipfs data file for issuing an asset. Push it to ipfs from the wallet, and add the hash right into the issuance data. This is going to allow for a much more seamless flow into the app. [14:34] <[Dev] Blondfrogs> This ofcourse, will also allow for users to create messages, and post them on ipfs and be able to easily and quickly format and send messages out on the network with ipfs data. [14:34] It will also allow optional meta-data with each transaction that goes in IPFS. [14:34] will i be able to view ipfs images natively in the wallet? [14:34] <[Dev] Blondfrogs> Images no [14:34] We discussed the option to disable all IPFS integration also. [14:35] @russ (kb: russkidooski) Probably not. There's some risk to being an image viewer for ANY data. [14:35] No option in wallet to opt into image viewing? [14:35] cool so drag and drop ipfs , if someone wanted to attach an object like an image or a file they could drag drop into ui and it create hash and attach string to transaction command parameters automatically [14:35] We could probably provide a link -- with a warning. [14:35] nomore going to globalupload.io [14:35] :ThinkBlack: [14:35] I understand that the wallet will rely on globalupload.io. (phase 1). Is it not dangerous to rely on an external network? Or am I missing something? [14:36] hmm [14:36] interesting, i suppose you could hash at two different endpoints and compare them [14:36] if you were that worried [14:36] and only submit one to the chain [14:36] You will be able to configure a URL that will be used as an IPFS browser. [14:36] Oh ic [14:36] you wont flood ipfs because only one hash per unique file [14:36] <[Dev] Blondfrogs> There are multiple options for ipfs integration. We are building it so you can run your own ipfs node locally. [14:36] <[Dev] Blondfrogs> or, point it to whatever service you would like. e.g. cloudflare [14:36] this is very cool developments, great to see this [14:37] Just like the external block explorer link currently in preferences. [14:37] @[Dev] Blondfrogs what about a native ipfs swarm for ravencoin only? [14:37] We have discussed that as an option. [14:37] @push | ravenland.org Considering having a fallback of upload through globalupload.io and download through cloudflare. [14:37] <[Dev] Blondfrogs> @russ (kb: russkidooski) We talked about that, but no decisions have been made yet. [14:37] yeah, i would just use two endpoints and strcompare the hash [14:37] as long as they agree good [14:37] submit tran [14:38] else 'potentially mysterious activity' [14:38] ? [14:38] if you submitted the file to ipfs api endpoints [14:38] Will the metadata just be a form with text only fields? [14:39] and then you would get 2 hashes, from 2 independent services [14:39] that way you would not be relying on a central hash service [14:39] and have some means of checking if a returned hash value was intercepted or transformed [14:39] i was answering jeroz' question [14:40] about relying on a single api endpoint for upload ipfs object [14:40] We have also kicked around the idea of hosting our own JSON only IPFS upload/browse service. [14:41] I have a service like this that is simple using php [14:41] we only use it for images right now [14:41] but fairly easy to do [14:41] Yup [14:42] Further questions about IPFS? [14:43] contract handling? file attach handling? or just text fields to generate json? [14:44] trying to get an idea of what the wallet will offer for attaching data [14:44] Probably just text fields that meet the meta-data spec. [14:44] ok noted [14:44] What do you mean by contract handling @sull [14:45] We won't prevent other hashes from being added. [14:45] asset contract (pdf etc) hash etc [14:45] <[Dev] Blondfrogs> also, being able to load from a file [14:45] got it, thanks [14:47] Let's do some general Q&A [14:48] Maybe just a heads up or something to look for in the future but as of right now, it takes roughly 12 hours to sync up the Qt-wallet from scratch. Did a clean installation on my linux PC last night. [14:48] Any plans or discussions related to lack of privacy of asset transfers and the ability to front run when sending to an exchange? [14:48] ^ [14:48] Is there a way to apply to help moderate for example the Telegram / Discord, i spend alot of time on both places, sometimes i pm mods if needed. [14:49] Any developed plans for Asset TX fee adjustment? [14:49] also this^ [14:49] @mxL86 We just created a card on the public board to look into that. [14:49] General remark: https://raven.wiki/wiki/Development#Phase_7_-_Compatible_Mode = updated reflecting Tron's explanation. [14:49] @mxL86 That's a great question. We need to do some profiling and speed it up. I do know that the fix we added from Bitcoin (that saved our bacon) slowed things down. [14:50] Adding to @mxL86 the sync times substantially increased coinciding with the asset layer activation. Please run some internal benchmarks and see where the daemon is wasting all its cycles on each block. We should be able to handle dozens per second but it takes a couple seconds per block. [14:50] @BW__ no plans currently for zk proofs or anything if that's what you're asking [14:50] You are doing a great job. Is there a plan that all this things (IPFS) could be some day implemented in mobile wallet? Or just in QT? [14:50] i notice also that asset transactions had some effect on sync time as we were making a few. Some spikes i not analysed the io and cpu activity properly but will if there is interest [14:51] we are testing some stuff so run into things i am happy to share [14:51] @BW__ Might look at Grin and Beam to see if we can integrate Mimble Wimble -- down the road. [14:51] yeees [14:51] @J. | ravenland.org work with the telegram mods. Not something the developers handle. [14:51] i love you [14:51] @J. | ravenland.org That would be best brought up with the operators/mods of teh telegram channel. [14:51] @corby @Tron thnx [14:51] @S1LVA | GetRavencoin.org we're planning on bumping fees to... something higher! [14:51] no catastrophic failures, just some transaction too smals, and mempool issues so far, still learning [14:52] @corby i thought that this may happen :ThinkBlack: [14:52] @corby x10? 100x? 1000x? Ballpark? [14:52] Definitely ballpark. [14:52] 😃 [14:52] 😂 [14:52] Is a ballpark like a googolplex? [14:53] @push | ravenland.org asset transactions are definitely more expensive to sync [14:53] yes yes they are [14:53] they are also more expensive to make i believe [14:53] 10,000x! [14:53] as some sync process seems to occur before they are done [14:53] @traysi ★★★★★ thanks for the suggestions we are going to be looking at optimizations [14:53] But, it is way slower than we like. Going to look into it. [14:53] i do not understand fully its operation [14:53] 1000x at minimum in my opinion [14:53] its too easy to spam the network [14:54] yes there has been some reports of ahem spam lately [14:54] :blobhide: [14:54] 😉 [14:54] cough cough ravenland [14:54] @russ (kb: russkidooski) we're in agreement -- it's too low [14:54] default fee 0.001 [14:54] ^ something around here [14:54] @corby yep we all are i think [14:55] waaay too low [14:55] meaningful transactions start with meaningful capital expense [14:55] though there is another scenario , there are some larger volume, more objective rich use cases of the chain that would suffer considerably from that [14:55] just worth mentioning, as i have beeen thinking about this a lot [14:55] there are some way around, like i could add 1000 ipfs hashes to a single unique entity, i tested this and it does work [14:56] @russ (kb: russkidooski) What would you suggest. [14:57] I had a PR for fee increase and push back. [14:57] Ignore the push back. 0.001 RVN is not even a micro-farthing in fiat terms [14:57] definitely around 1000x [14:57] Vocal minority for sure [14:57] ^ yep [14:57] @russ (kb: russkidooski) That sounds reasonable. [14:57] Couple hundred Fentons [14:58] right now an asset transaction is 0.01 of a penny essentially [14:58] 1 RVN would work now, but not when RVN is over $1. [14:58] yes exactly [14:58] Hi. Late to the party. [14:58] We are also talking about a min fee. The system will auto-adapt if blocks fill up. [14:58] im thinking tron, some heavy transaction use cases would fall out of utility use if that happened [14:58] so whats the thinking there [14:59] is there a way around the problem, bulked ipfs hash transactions? [14:59] 1000x would put us around btc levels [14:59] maybe a minimum 500x? [14:59] @russ (kb: russkidooski) Agreed. [14:59] <[Dev] Blondfrogs> It is time to wrap it up here. Everyone. Thank you all for your questions and thoughts. We will be back in 2 weeks. 😃 [14:59] Small increase and review. [14:59] Thanks all! [14:59] Cheers. [15:00] yeah sorry for 1 million questions guys hope i didnt take up too much time [15:00] cheers all 👍 [15:00] Thanks everyone [15:00] Thanks everyone for participating!!! [15:00] That is what we are here for [15:00] 100x-500x increase, 1000x maximum [15:00] 🍺

submitted by Chatturga to Ravencoin [link] [comments]

How to Mine BiblePay on Linux

This guide is outdated, please refer to:
https://wiki.biblepay.org/POBH_Setup
https://wiki.biblepay.org/PODC_Setup
 
 
 
 
 
 
 
 
IMPORTANT - Evolution Upgrade:
Quick Start https://wiki.biblepay.org/Quick_Start
Evolution Upgrade Information https://wiki.biblepay.org/Evolution_Upgrade
Getting Started with Evolution https://wiki.biblepay.org/Getting_Started_with_Evolution
Generic Smart Contracts https://wiki.biblepay.org/Generic_Smart_Contracts
What is BiblePay Evolution? https://www.reddit.com/BiblePay/comments/bifvpk/biblepay_evolution_what_is_it/
Recommend 2GB RAM or can get stuck compiling (if 1GB RAM can use Swap File) Use Ubuntu 16.04
INFO
https://github.com/biblepay/biblepay-evolution/blob/masteBuildBiblePay.txt
INSTALL COMMANDS
apt-get install build-essential libtool autotools-dev automake pkg-config libssl-dev libevent-dev bsdmainutils apt-get install libboost-system-dev libboost-filesystem-dev libboost-chrono-dev libboost-program-options-dev libboost-test-dev libboost-thread-dev apt-get install libqt5gui5 libqt5core5a libqt5dbus5 qttools5-dev qttools5-dev-tools libprotobuf-dev protobuf-compiler apt-get install git apt-get install curl build-essential libtool autotools-dev automake pkg-config python3 bsdmainutils cmake sudo add-apt-repository ppa:bitcoin/bitcoin sudo apt-get update sudo apt-get install libdb4.8-dev libdb4.8++-dev git clone http://github.com/biblepay/biblepay-evolution prefix=x86_64-pc-linux-gnu cd biblepay-evolution/depends make -j4 # Choose a good -j value, depending on the number of CPU cores available cd .. ./autogen.sh #Note: if echo `pwd` does not return your working directory, replace it with your working directory such as /biblepay-evolution/ ./configure --prefix `pwd`/depends/x86_64-pc-linux-gnu make # See more here: #https://github.com/biblepay/biblepay-evolution/blob/mastedoc/build-unix.md 

SWAP FILE
NOTE: if server is 1GB RAM, before running last command "sudo make", set up a swap file
free #check if swap is 0 dd if=/dev/zero of=/vaswap.img bs=1024k count=1000 mkswap /vaswap.img swapon /vaswap.img free #check if swap is 1024 sudo make 

RUN COMMAND LINE
cd src ./biblepayd -daemon 
OR
RUN GUI
Your GUI program will be located in: /biblepay-evolution/src/qt
./biblepay-qt 
You can also run it in the background (to free up your terminal) if you call it with:
./biblepay-qt & 
To start mining, instructions are the same as for Windows: Go to Tools -> Debug Console
Execute this command (to start mining with 8 threads)
setgenerate true 8 
From there you can use all other commands such as getmininginfo, getwalletinfo, etc. Execute help command to get the list of all available commands.
Note: GUI will be built automatically only if you meet the requirements for qt library, i.e. make sure you ran this line before compiling:
sudo apt-get install libqt5gui5 libqt5core5a libqt5dbus5 qttools5-dev qttools5-dev-tools libprotobuf-dev protobuf-compiler 
BIBLEPAY is now Running!

SETUP CONFIG
Stop BiblePay and set up the config file to get starting nodes to sync with and enable mining:
./biblepay-cli stop cd ~/.biblepayevolution/ vi biblepay.conf addnode=node.biblepay.org gen=1 genproclimit=1 
Escape Key + : (Colon Key) + w + q + Enter (saves file and quits)

addnode --- adds a node to the list of nodes to connect to gen=1 --- turns on mining genproclimit --- sets number of threads to use when mining

Run BiblePay again and fully sync with network
cd ../biblepay-evolution/src ./biblepayd -daemon ./biblepay-cli getinfo 

USEFUL COMMANDS
./biblepay-cli help ./biblepay-cli getaccountaddress "" ./biblepay-cli getinfo ./biblepay-cli getmininginfo ./biblepay-cli setgenerate true 8 ./biblepay-cli sendtoaddress "insertAddressHere" 777 "" "" true ./biblepay-cli stop ./biblepayd -daemon top #CPU usage q to quit 

MINING THREADS: To change number of threads to use up for mining
a. Edit home/yourusername/.biblepayevolution/biblepay.conf file:
genproclimit=X 
and restart BiblePay -or- b. Menu >> Tools >> Debug Console >> Type command:
setgenerate true X 
(Replace X with number of threads Use top command to view CPU usage)

POOL
NOTE: To use the pool you must now use the external miner, not the wallet miner https://whitewalr.us/2019/biblepay-nomp-pool-mining.html
  1. Set up an account on pool website: https://pool.biblepay.org/
  2. Create Worker Username(s) - Workers tab >>> Add
  3. Enable pool and add Worker Username in ~/.biblepayevolution/biblepay.conf file, add these lines and save:
    pool=https://pool.biblepay.org workerid=insertWorkerUsernameHere
4. Restart BiblePay
./biblepay-cli stop ./biblepayd -daemon 
Setup Auto-Withdraw Navigate to Account >>> Account Settings >>> Verify your BBP Receiving Address >>> Click Authorize-Auto-Withdraws

UPDATE:

### Turn off/stop BiblePay
cd /home/yourname/biblepay-evolution/src ./biblepay-cli stop 

### Pull down latest Biblepay code and build it
cd /home/yourname/biblepay-evolution git pull origin master sudo make 

### Turn BiblePay back on and check version number
cd src ./biblepayd -daemon ./biblepay-cli getinfo ./biblepay-cli setgenerate true 8 

UPDATE IN ONE COMMAND:
./biblepay-evolution/src/biblepay-cli stop ; cd && cd biblepay-evolution/ && git pull origin master && sudo make && cd src && ./biblepayd -daemon && sleep 90 && ./biblepay-cli getmininginfo 
Note: the ";" says do this after, regardless of the outcome Note: && says do this after only if previous command finished with no errors

SPEED UP COMPILE:
To speed up the compile time, add -j4 or -j8 after make. This way it compiles using 4 or 8 threads instead of just 1.
./configure LDFLAGS="-L${BDB_PREFIX}/lib/" CPPFLAGS="-I${BDB_PREFIX}/include/" sudo make -j8 
Reference: http://www.linux-databook.info/?page_id=2319

RSYNC stop biblepay from your nodes compile on your fastest machine then rsync with your machines only src folder is required
rsync -avuz /root/biblepay-evolution/src/ [email protected]:/root/biblepay-evolution/src/ 
https://stackoverflow.com/questions/3299951/how-to-pass-password-for-rsync-ssh-command https://www.thegeekstuff.com/2008/11/3-steps-to-perform-ssh-login-without-password-using-ssh-keygen-ssh-copy-id/
people make cron jobs and rsync automatically

OUTDATED

Unofficial Bash Script
https://gist.github.com/anonymous/d1c1d35e3c8f67f5fb2e204479fa5c6b

Official Ubuntu Package
https://launchpad.net/~biblepay-official

Unofficial Ubuntu Package
https://www.reddit.com/BiblePay/comments/7rwqqs/unofficial_ubuntu_packages_available/

Unofficial Mine in One Line
https://www.reddit.com/BiblePay/comments/7ryuk1/mine_in_one_line/
NOTE: DONT RUN ON A COMPUTER WITH COINS -- THIS IS A CLEAN INSTALL SCRIPT

COMPILE WITHOUT GUI: https://bitcointalk.org/index.php?topic=2042657.msg21878317#msg21878317 https://bitcointalk.org/index.php?topic=2042657.msg21878389#msg21878389
ADVANCED:

DOCKER IMAGES (NOTE: I havent tested these, use at your own risk) https://hub.docker.com/gagaha/biblepay/ https://hub.docker.com/cryptozero/biblepay-opt/
submitted by togoshige to BiblePay [link] [comments]

Qtum Quantum Chain Design Document -- Add RPC Calls (Seven)

Qtum original design document summary (7) -- Qtum added RPC call
https://mp.weixin.qq.com/s/JdJLxEIBjD255qey6ITO_g
Qtum's core program, qtumd, runs all core logic including validation and creation of blocks. However, to achieve interaction with qtumd, you need to rely on RPC (Remote Procedure Call). Through RPC, you can interact with qtumd from the outside to implement basic functions such as sending and receiving QTUM and obtaining blockchain information.
The initial version of the Qtum RPC call is compatible with Bitcoin. On this basis, because the Qtum blockchain is different from Bitcoin, and Qtum supports the smart contract function that Bitcoin does not have, it is necessary to add a new RPC or improve the existing RPC to achieve Qtum. Full interaction of nodes.
The following section captures the relevant original design documents (with Chinese translation) for the Qtum RPC call from the early Qtum development team (ps: QTUM<#> or QTUMCORE<#> in the document is the internal design document number):
 
QTUM-35: Add RPC call for off-chain contract execution
Description: In Ethereum there are some contract's that can be executed without needing to be on the blockchain. This is useful especially for retrieving the status and results from a contract, and will make no changes to the on-chain storage or state. We should Add an RPC call to cover this functionality
 
Callcontract [address] [data]
Returns/prints hex encoded return data
 
Task: Add an RPC (Remote Procedure Call) call to run under the chain Description: It is useful to have some contracts in Ethereum that are not working on the blockchain, especially when retrieving the status and results of contracts, and not changing the storage and status of the chain. We should add an RPC call to implement this functionality. Callcontract [address] [data] Return / print hexadecimal encoded return data
 
QTUMCORE-14: Add "callcontract" RPC call for off-chain computations
Description: There should be an RPC call that executes a contract without requiring interaction with the blockchain network, and thus without gas or other fees. Callcontract contract-address data (sender) This should execute the contract locally, and if the contract function returns data, it should be returned/printed by the RPC call. Sender is optional and does not require an owned vout (it can be any valid address)
Task: Add a "callcontract" RPC call for the calculation of the chain Description: There should be an RPC call that does not require interaction with the blockchain network to run the contract, so it does not require gas or other fees. The format is as follows: Callcontract contract-address data (sender) It can run the contract locally, and if the contract function returns data, the RPC call can return/print the data. The sender is optional and does not need to have vout (it can be any valid address).
The above two tasks add a callcontract RPC call interface to implement a local chain call contract, which is convenient for viewing contract status or obtaining contract results without changing any information on the chain.
 
QTUMCORE-7: Add "createcontract" RPC call
 
Description: A new RPC call should be added call "deploycontract" "createcontract". This RPC call will be used to deploy a new smart contract to the Qtum blockchain.
Syntax:
Deploycontract createcontract gas-price gas-limit bytecode [sender-address] [txfee] [broadcast]
If no address is specified, then it should be picked randomly from the wallet. If no outputs exist to spend using that sender-address, then an error should be shown and no transaction created.
Tsfee is optional and if not specified should use the same auto txfee as the rest of the wallet (for example sendtoaddress uses an auto txfee)
Broadcast should default to true. If broadcast is false, then the transaction is created and signed, and then printed to the screen in hex rather than broadcast to the network.
If the sender-address does have an output, but it is not enough to cover the gas costs and tx fees, then any UTXO owned by the wallet should be used by the transaction to cover those fees. (not all funds must come from sender -address, but the sender-address must be vin[0])
After execution, if broadcast is true, it should print the txid and the new contract address.
Task: Add "createcontract" RPC call
Description: Add a "createcontract" RPC call that will be used to deploy a new smart contract on the Qtum blockchain.
grammar:
Createcontract gas-price gas-limit bytecode [sender-address] [txfee] [broadcast]
Among them, sender-address (sender address) is optional. If no address is specified, an address will be randomly selected from the wallet. If there is no output available in the sender-address, an error will be displayed and the transaction will not be created.
Txfee (transaction fee) is optional. If not specified, it should use the same automatic txfee as the rest of the wallet (for example, the automatic txfee used by sendtoaddress)
Broadcast should be true by default. If broadcast is false, the transaction is created and signed, and will be printed to the screen in hexadecimal format instead of being broadcast to the network.
If the sender-address does have an output, but it does not cover the gas charges and transaction fees, then any UTXO owned by the wallet can be used by the transaction to pay for these charges. (Not all funds must come from sender-address, but sender-address must be vin[0])
After running, if broadcast is true, the transaction id and the new contract address are printed.
The above task adds the RPC call createcontract for creating and deploying new smart contracts, and describes the specific meaning of the parameters and their corresponding behavior.
 
QTUMCORE-13: Add "sendtocontract" RPC call
Description: An rpc call should be adding for sending data and (optionally) money to a contract that has been deployed on the blockchain.
The format should be:
Sendtocontract contract-address data (value gaslimit gasprice sender broadcast)
This should create a contract call transaction using OP_CALL.
Value defaults to 0.
If no address is specified, then it should be picked randomly from the wallet. If no outputs exist to spend using that sender-address, then an error should be shown and no transaction created.
Broadcast should default to true. If broadcast is false, then the transaction is created and signed, and then printed to the screen in hex rather than broadcast to the network.
If the sender-address does have an output, but it is not enough to cover the gas costs, tx fees, and value, then any UTXO owned by the wallet should be used by the transaction to cover the remainder. (not all funds must Come from sender-address, but the sender-address must be vin[0])
After execution, if broadcast is true, it should print the txid and the new contract address.
Task: Add "sendtocontract" RPC call
Description: In order to send data or funds to a contract already deployed on the blockchain, an RPC call should be added.
The format should be:
Sendtocontract contract-address data (value gaslimit gasprice sender broadcast)
You can use OP_CALL to create a contract call transaction.
Value defaults to 0.
The sender-address is optional. If no address is specified, an address will be randomly selected from the wallet. If there are no outputs available in the sender-address, an error will be displayed and no transaction will be created.
Broadcast is default to true. If broadcast is false, then the transaction is created and signed and then printed to the screen in hexadecimal format instead of being broadcast to the network.
If the sender-address does have an output, but the output is not sufficient to cover the gas fee, transaction cost, and value, then any UTXO owned by the wallet can be traded to pay the remaining fee. (Not all funds must come from sender-address, but sender-address must be vin[0])
After running, if broadcast is true, the transaction id and the new contract address should be printed.
In order to implement the contract on the chain, the above task adds a sendtocontract RPC call. Its functionality is similar to callcontract and can be used to run contracts. The biggest difference is that sendtocontract implements the chain call, which requires the cost of the Gas, and the running result needs to be verified by the entire network node, and will change the storage state on the contract chain.
 
QTUMCORE-81:create getTransactionReceipt rpc call
Description: We need to create getTransactionReceipt rpc call that returns the same values ​​as here:
https://github.com/ethereum/wiki/wiki/JavaScript-API#web3ethgettransactionreceipt
Most important part is the logs. they can either be stored into a separate db or use one of the existing tx or eth related db.
Task: Create getTransactionReceipt RPC call
Description: We need to create a getTransactionReceipt RPC call that returns the same value as in the following link:
https://github.com/ethereum/wiki/wiki/JavaScript-API#web3ethgettransactionreceipt
The most important part is the log. They can be stored in a separate database, or they can use existing transactions or Ethereum-related databases.
The above task adds a gettransactionreceipt RPC call to the smart contract log to get the contract transaction related logs, which is very useful for understanding the status of smart contracts.
 
QTUMCORE-90: add searchlogs rpc call
Description: we need to add an rpc call to allow us to search the eth event logs, we need to support similar parameters as eth:
https://github.com/ethereum/wiki/wiki/JavaScript-API#web3ethfilter
So it would be: searchlogs(fromBlock, toBlock, address, topics)
fromBlock, toBlock should support latest keyword
Adderss: optional should be an array of one or more addresses
Topics: optional (check the link above)
Unlike eth where you have to call watch, this method should just output the filtered logs
Task: Add searchlogs RPC call
Description: We need to add a PRC call that allows searching for smart contract event logs, and we need to support parameters similar to Ethereum:
https://github.com/ethereum/wiki/wiki/JavaScript-API#web3ethfilter
So its form is as follows: searchlogs(fromBlock, toBlock, address, topics)
fromBlock: toBlock should support the latest keywords
Address: an optional array of one or more addresses
Topics: optional (refer to the link above)
Unlike the Ethereum, which needs to call watch, this method only outputs the filtered log.
The above task adds an RPC for retrieving the smart contract event log to facilitate screening of event logs that satisfy the condition. Users can quickly get the contract status they care about.
 
QTUMCORE-92: add getcode and getstorageat rpc calls
Description: We need to implement Qtum equivalent of these 2 rpc calls:
https://github.com/ethereum/wiki/wiki/JavaScript-API#web3ethgetcode
https://github.com/ethereum/wiki/wiki/JavaScript-API#web3ethgetstorageat
No need to implement callback function for now.
For the default block, we can use block number, or keyword "latest" (default)
Task: Add getcode and getstorageat RPC calls
Description: We need to implement the QTP version of the RPC call equivalent to the following two RPCs:
https://github.com/ethereum/wiki/wiki/JavaScript-API#web3ethgetcode
https://github.com/ethereum/wiki/wiki/JavaScript-API#web3ethgetstorageat
There is currently no need to implement a callback function.
For the default block, we can use the block number, or the keyword "latest" (default)
The above task implements an equivalent RPC similar to Ethereum for obtaining contract code and storing information.
 
QTUMCORE-97: Change validation of contract rpc calls inputs
Description: Change validation of contract rpc calls inputs to accept only hex
Task: Modify the verification of the input value of the contract RPC call
Description: Modify the validation of the input value of the contract RPC call to accept only hexadecimal.
The above task stipulates that the RPC of the verification contract only accepts the hexadecimal data parameters, so that the rpc interface is as consistent as possible.
 
QTUMCORE-123: Add "excepted": to gettransactionreceipt
Description: We need to add the "excepted": field to gettransactionreceipt rpc call which lists "None" if no exception occured, or lists the actual exception that happened.
The same lessons is in callcontract call.
We need the change to be backward compatible, which means it should not break the current logs db, but people who want to see exceptions would have to recreate/reindex the logs db
Task: Add "excepted": field in gettransactionreceipt
Description: We need to add the "excepted": field to the gettransactionreceipt RPC call. If no exception occurs, it will display "None", otherwise it will list the actual exception.
The same is true for Callcontract calls.
We need to modify it to be forward compatible, which means it can't break the current log database, but if you want to see these exceptions, you must rebuild/reindex the log database.
The above tasks enable a number of RPCs associated with smart contracts to throw exceptions that are convenient for the user to understand the wrong running state of the contract and also help developers debug the code.
 
QTUMCORE-124:Add "changeToSender" to sendtoaddress and make sure the "Don't use change address" option also affects sendtoaddress
Description: We need to add "changeToSender" parameter to sendtoaddress rpc call, same as we did for sendtocontract.
Also we need to make sure the "Don't use change address" also affects sendtoaddress
Task: Add "changeToSender" to sendtoaddress and make sure the "Don't use change address" option is also valid for sendtoaddress
Description: We need to add the "changeToSender" parameter to the sendtoaddress RPC call, which is also added to the sendtocontract.
We also need to make sure that the "Don't use change address" option is also valid for sendtoaddress.
Due to the UTXO model, the change of the contract call is easy to confuse the user. Therefore, the above task adds the option of "do not use the change address" for the sendtoaddressRPC, from which the user can choose to return to the original address.
 
QTUMCORE-125: Add callcontract support to "createrawtransaction" rpc call
Description: As requested by some exchanges, which use "createrawtransaction" to create raw transactions before signing on a cold wallet, we need to add
1- raw contract data support to "createrawtransaction" rpc call.
Currently "createrawtransaction" supports two types of outputs in the outputs arguments:
First is "address": x.xxx which created a standard P2PKH output
The second is "data": "hex" which creates an OP_RETURN output
We need to add:
1- "callcontract":
{contractAddress:"address", data:"data", amount:"amount", gasLimit:"gaslimit", gasPrice:"gasPrice"}
Where:
contractAddress: a valid contract address (valid hash160 hex data)
Data: the hex data to add in the OP_CALL output (should validate it's hex data, you can check the validation done in sendtocontract)
Amount (optional): the value of the output (value in QTUM to send with the call), should be a valid amount, default 0
gasLimit (optional): the gas limit for the transaction (same as in sendtocontract), defaults to the default/DGP value
GasPrice (optional): the gas price for the transaction (same as in sendtocontract), defaults to the default/DGP value
After parsing and validation all the values ​​an OP_CALL output should be constructed
Similar to this:
CScript scriptPubKey = CScript() << CScriptNum(VersionVM::GetEVMDefault().toRaw()) << CScriptNum(nGasLimit) << CScriptNum(nGasPrice) << ParseHex(datahex) << ParseHex(contractaddress) << OP_CALL;
Task: Make the "createrawtransaction" RPC call support callcontract
Description: Before some transactions are signed on the cold wallet, use "createrawtransaction" to create the original transaction. At the request of these exchanges, we should add:
1 -- original contract data support for "createrawtransaction" RPC calls
Currently, for the outputs parameter, "createrawtransaction" supports two types of outputs:
The first type is "address": x.xxx, which creates a standard P2PKH output
The second type is "data": "hexadecimal", creating an OP_RETURN output
We need to add:
1 -- "callcontract":
{contractAddress:"address", data:"data", amount:"amount", gasLimit:"gaslimit", gasPrice:"gasPrice"}
among them,
contractAddress: a valid contract address (valid hash 160 hex data)
Data: hexadecimal data added in OP_CALL output (should be verified as hexadecimal data, you can check if it is verified in sendtocontract)
Amount (optional): The value of output (the value in QTUM, sent with this call), should be a valid value, the default is 0
gasLimit (optional): the gas limit of the transaction (same as sendtocontract), the default is the default/DGP value
gasPrice (optional): the gas price of the transaction (same as sendtocontract), defaults to the default/DGP value
After parsing and verifying all the values, you should build an OP_CALL output.
The build method is similar to the following:
CScript scriptPubKey = CScript() << CScriptNum(VersionVM::GetEVMDefault().toRaw()) << CScriptNum(nGasLimit) << CScriptNum(nGasPrice) << ParseHex(datahex) << ParseHex(contractaddress) << OP_CALL;
Prior to the above task, the createrawtransaction RPC call was consistent with Bitcoin and could only be used to send standard transactions. Qtum extends it to compatible contract transactions. From then on, the RPC can be used to create original contract transactions for developers or exchanges.
Summary
The RPC call is the most important way to interact with the qtumd core program. It provides a call interface for getting all kinds of information on the blockchain and local. It is the basis for many applications such as wallets, browsers, and exchanges. A good RPC interface design enables developers to get more accurate information and develop more feature-rich applications. Qtum provides developers with sophisticated RPC calls, making it possible for many third-party applications, such as predicting market projects, Bodhi.
submitted by thisthingismud to Qtum [link] [comments]

How can I see transaction comments?

In the JSON RPC API (https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list) there's a call named 'sendtoaddress' that gets an input for

I've created a number of transactions but cannot see the comments on my bitcoin-qt or blockchain.info.
Any ideas?
submitted by xabbix to Bitcoin [link] [comments]

Boursorama - YouTube BULLS PUSHING Into Resistance!!  BREAKING: Satoshi Moved Bitcoin From Original Address Today??? How Bitcoin Wallets Work (Public & Private Key Explained ... Bitcoin Explained 2017 Pakistan India -Hindi Urdu - YouTube What is Bitcoin? Bitcoin Explained Simply for Dummies ...

Customer sends coins to another bitcoin address: sendfrom "userid" <address> <amount> Customer transfers coins to another customer: move "userid1" "userid2" <amount> You make a sale, paid for with bitcoins in the customer's account: move "userid" "" <amount> 6 "purchased item", and if it succeeds, send them the product. Address - A Bitcoin address. Send bitcoins to it, and it will be forwarded immediately. When bitcoin is sent to the generated bitcoin address, the system will send out IPN to the defined url in your account. Our sendTo system covers 712 mobile networks in 212 countries — we can reach almost all mobile phones, however please test if we can reach your mobile or the mobile you want to send to ... Bitcoin address is an identifier (account number), starting with 1 or 3 and containing 27-34 alphanumeric Latin characters (except 0, O, I). Bitcoin addresses can be also represented as a QR-code. The addresses are anonymous and do not contain information about the owner. From Bitcoin Wiki. Jump to: navigation, search. This page is a Quality Assurance test plan for BIP 16. If you see a test missing, please add it. If you can help test, please edit this page to sign-off on it. Done Test Procedure Tested by Run BIP-16-capable Bitcoin 0.6 on testnet and main net. Send coins using GUI, RCP sendtoaddress, and RCP sendmany commands Result: coins sent in all cases ... Bitcoin Address Generation. Bitcoin addresses can be created using open-source libraries based on algorithmic hash functions. Users, most of the time, need more than one Bitcoin addresses to send ...

[index] [39708] [2166] [18648] [10642] [21357] [14740] [30629] [50909] [16094] [9984]

Boursorama - YouTube

Bienvenue sur la chaîne YouTube de Boursorama ! Le portail boursorama.com compte plus de 30 millions de visites mensuelles et plus de 290 millions de pages v... Bitcoin has become so popular that now everyone is asking one simple question what is bitcoin so this video will explain the following WHat is bitcoin in hin... Bitcoin finally broke sentiment $10,000 price point, but not for too long. Despite the short term volatility it has a huge long term upside potential. In this video a notorious bitcoin bull Tom ... In this video tutorial, I show you how to easily send and receive bitcoin from Coinbase to your blockchain wallet. Sign up for Coinbase and get $10 worth of ... Start trading Bitcoin and cryptocurrency here: http://bit.ly/2Vptr2X Bitcoin is the first decentralized digital currency. All Bitcoin transactions are docume...

#