|
How about instead of just selling the source code. Open source the code, and then start a business that hosts the bot for people for a price. I bet you make a lot more than just selling the bot.
|
|
|
|
Someone knows why an account value (to sell it to pyra) can go from 0.2 to 1.2 and viceversa?
BTC volatility, the sell price is set in dollars and converted to bitcoins. |
|
|
|
I think you need to add an arrow too, if a women should figure out how to do it. That's not even funny. Do you talk about women like this in real life? He clearly doesn't talk to any women. I love dudes like that, they hate on women but after a woman talks to them they stutter and stumble. ALSO TO THE MOD THAT DELETE MY JOKE AD, PLEASE DON"T. |
|
|
|
Not meant to be trustless? Bitcoinj was trustless i thought it connects to peers and not some random api on the net unless its for a price feed which is irrelevent. What do u mean by this?
It connects to peers but it doesn't verify blocks like bitocoin-core does, as well as bitcoinj doesn't have the entire blockchain. Without those two things you can't be trustless. SPV are just meant to get your unspent outputs, sign transactions and broadcast your transactions. Bitcoin-core actually keeps the network healthy by verifying blocks. Now you can make it trustless by running your own bitcoin-core and have bitcoinj only connect that. @gmaxwell This shows how much work we work we have to do as a community as people don't understand the important differences. I know you are probably going to say "People don't need to know how it works" but having the different levels of security laid out can't hurt. Bitcoinj actually supports full verification at this point given you use the PostgresFullPrunedBlockStore or MySQLFullPrunedBlockStore as your BlockStore. Bitcoinj has two modes it has SPV and full verification. I clearly stated the SPV mode in all my post. To be honest though I don't think bitcoinj's full verification passes all the test. I don't know haven't really looked at the project much in the last year. |
|
|
|
Not meant to be trustless? Bitcoinj was trustless i thought it connects to peers and not some random api on the net unless its for a price feed which is irrelevent. What do u mean by this?
It connects to peers but it doesn't verify blocks like bitocoin-core does, as well as bitcoinj doesn't have the entire blockchain. Without those two things you can't be trustless. SPV are just meant to get your unspent outputs, sign transactions and broadcast your transactions. Bitcoin-core actually keeps the network healthy by verifying blocks. Now you can make it trustless by running your own bitcoin-core and have bitcoinj only connect that. @gmaxwell This shows how much work we work we have to do as a community as people don't understand the important differences. I know you are probably going to say "People don't need to know how it works" but having the different levels of security laid out can't hurt. |
|
|
|
No, but you are concerned about scalability while I don't know what you are doing, that is the key word that I would use a 3rd party api. Lowest overhead and easiest to be scaling with.
"Scalability" is ultimately limited by the Bitcoin network, which-- by definition-- a Bitcoin full node can handle. Interposing a 3rd party does not necessarily improve scalability-- it likely reduces it, especially since you're talking about unpaid services, so there is nothing to fund your utilization-- and using a third party service necessarily reduces security, more so than SPV, and necessarily adds additional points of failure: the reliability of third party blockchain services has been very low. I'm sad to see that no one seems to have noticed the Baron link I gave above. It's a full order processing solution based on a local full node. It deserves more attention. Your right in one aspect and you are wrong in another aspect. Scalability is not ultimately limited by the bitcoin network, but also by connections/users. Bitcoin-core I think is becoming less and less used by companies just because it is so heavy and not scalable. It really tops out at only a few 1000 connections, even raising the file limit from 1024 (default for most linux systems) to higher and higher numbers doesn't help anymore. Then you probably need to run a bitcoin proxy as I have been using, that manages connections and limits. This causes another problem which we have seen time and time again, that if you do a withdraw and don't say it could take 12-24 hours to process, and it doesn't show up on the network in a few seconds. The idea that company is now a scammer, is what consumes the mind. So now you are not able to use the the programical instant withdraw that only the bitcoin network as a bootstrap startup without risking your reputation. I believe we are failing as a community in many ways about this, I recommend 3rd party apis because that is the only solution currently. There are no other full nodes that can handle this unless you enter the enterprise stage. I don't think anyone wants to do that unless they have to. I think as btcd, tosh.io, and bitcoin-core grow we will see many forks addressing this problem. Until then there is really no way to be trustless and scale. |
|
|
|
Hi, I am a developer with a lot of experience in C++, Java and Python. I am familiar with BitcoinJ and similar frameworks that help you interact with the Bitcoin network. I am trying to accept Bitcoin payments for a project and I would like to avoid using third-party services such as Blockchain's Payment API, Coinbase and BitPay. I'm thinking of working with "btcd" or "Bitcoinj". I have a prototype that uses the PostgresFullPrunedBlockStore. It works perfectly except when the service is down for a while. It misses transactions and syncing the blockchain doesn't seem to help. I end up not getting notified of "relevant" transactions that occurred when my service was down, despite syncing the blockchain. I do realize that I can easily interact with "bitcoind" using RPC and add new addresses but I don't want to rely on bitcoind for that. I'm thinking of potential scalability issues. What do you think would be the right approach here? I'm hoping to come up with a generic solution so that I can open-source it and other people can integrate it into their own systems. I have one potential solution in mind. Let me know if you see any problems with this. 1- Join the network, wait for new blocks from peers
2- Loop indefinitely and wait for new blocks from peers. Receive block N:
2a- Look at the block, check the transactions included in the block, are they relevant?
2b- If they are relevant, note the unspent output and store it (making the assumption that its inputs are valid, if they weren't, it wouldn't be included in the block and propagated? Is this a safe assumption to make?)
2c- Sweep the address and send it to cold wallet
2d- Increment the balance of the user
What's wrong in using a 3rd party API ? its not trustless Bitcoinj isn't trustless either  How? Does it force u to connect to an online api? If not it is trustless in the context we care about SPV clients are not suppose to be trustless so it isn't trustless in any context, it is convenience. Security is given up for convenience. Unless you want to run a full node in front of the bitcoinj library and force bitcoinj to only connect to that. Then it is trustless. Yes, it is not. It isn't unreasonable to trust some full-nodes you are running, though.
No, but you are concerned about scalability while I don't know what you are doing, that is the key word that I would use a 3rd party api. Lowest overhead and easiest to be scaling with. |
|
|
|
|
Every bitcoin client will force you to wait for 1 confirmation because you need at least 1 confirmation to be able to spend the output.
You can't have low fees because you are spamming the bitcoin network when you send many little payments, the fee will let miners accept it into a block.
|
|
|
|
Hi, I am a developer with a lot of experience in C++, Java and Python. I am familiar with BitcoinJ and similar frameworks that help you interact with the Bitcoin network. I am trying to accept Bitcoin payments for a project and I would like to avoid using third-party services such as Blockchain's Payment API, Coinbase and BitPay. I'm thinking of working with "btcd" or "Bitcoinj". I have a prototype that uses the PostgresFullPrunedBlockStore. It works perfectly except when the service is down for a while. It misses transactions and syncing the blockchain doesn't seem to help. I end up not getting notified of "relevant" transactions that occurred when my service was down, despite syncing the blockchain. I do realize that I can easily interact with "bitcoind" using RPC and add new addresses but I don't want to rely on bitcoind for that. I'm thinking of potential scalability issues. What do you think would be the right approach here? I'm hoping to come up with a generic solution so that I can open-source it and other people can integrate it into their own systems. I have one potential solution in mind. Let me know if you see any problems with this. 1- Join the network, wait for new blocks from peers
2- Loop indefinitely and wait for new blocks from peers. Receive block N:
2a- Look at the block, check the transactions included in the block, are they relevant?
2b- If they are relevant, note the unspent output and store it (making the assumption that its inputs are valid, if they weren't, it wouldn't be included in the block and propagated? Is this a safe assumption to make?)
2c- Sweep the address and send it to cold wallet
2d- Increment the balance of the user
What's wrong in using a 3rd party API ? its not trustless Bitcoinj isn't trustless either |
|
|
|
|
I talked to a mod friend, they said you never contacted them in regards to that issues. As well as they said both accounts happen to use the same IP Address.
|
|
|
|
If you can run a daemon you dont need to rely on any third partys.
You can create an account for each address in your daemon and use getbalance account to check that specific address balance.
Addresses need to be created on that daemon or imported and an account needs to be assign to that address.
Then once you have 100000000000000 keys on your wallet, you'll need 30 GB for the blockchain, and 500TB for your wallet.dat file... lol Someone here that actually has a wallet with over 2 million addresses generated. It actually doesn't take up that much space. Plus you can use tools to remove private keys from your wallet. |
|
|
|
|
Use regtest, you can make unlimited amounts of testnet coins.
|
|
|
|
Even if someone were to make such a program it is unlikely that it would get integrated into the forum as (per what theymos said above) it could potentially turn the forum into a money transmitter. I would also assume that the bounty would likely be lowered if the "hold" were to be released as 300 BTC was worth a lot less when the post/thread was made then it is now. I also disagree that this would be a good idea as it would likely create huge amounts of spam and would potentially create new scams when people tip eachother in order to look generous so others will end up tipping them even more money. It would also make the forum an even bigger target for potential hackers Well you can do it in a non-spammy way, build an extension that adds a tip button and then the extension can display it as well. This would also remove the forum completely from being responsible. Also if you are building an extension you can do it completely in javascript, so if you want to make it a plugin it would be pretty easy as well as you can block it if you want no part. Also this could block you from being tip. I am talking about the spam that it would encourage people to post if a tip function were to be enabled. Anytime someone would tip someone for a good comment, many others would post in the thread with likely useless garbage with the hopes that the person who tipped will tip someone again Well the forum is also mostly spam in that way. So I don't see how that would change with tipping function. If anything I think it could make people want to post quality. |
|
|
|
Paper wallets can never be hacked You chose easy of use over security. |
|
|
|
It is coyote's thing - he only makes promises.
Yes I'm starting to figure that out, I hope he can back up his promises on this one, or he will face one hell of a backlash, its one thing scamming people with a shitcoin, but putting a name like he has to this one will defo be well out of order. Just remember he was in for 6 yrs doing this exact thing, he is only a talker. Plus come coyotes meet a werewolf, and then their bite is nothing. |
|
|
|
I do not want to rely on a separate process. I want my daemon to be self reliant. You should have mentioned up front that intentionally getting hax0red was part of the design requirements. Some people don't have any idea how bitcoin works but they use their programming certificates as "I know everything yet I am still asking". Now I know why I left this forum for while. |
|
|
|
Even if someone were to make such a program it is unlikely that it would get integrated into the forum as (per what theymos said above) it could potentially turn the forum into a money transmitter. I would also assume that the bounty would likely be lowered if the "hold" were to be released as 300 BTC was worth a lot less when the post/thread was made then it is now. I also disagree that this would be a good idea as it would likely create huge amounts of spam and would potentially create new scams when people tip eachother in order to look generous so others will end up tipping them even more money. It would also make the forum an even bigger target for potential hackers Well you can do it in a non-spammy way, build an extension that adds a tip button and then the extension can display it as well. This would also remove the forum completely from being responsible. Also if you are building an extension you can do it completely in javascript, so if you want to make it a plugin it would be pretty easy as well as you can block it if you want no part. Also this could block you from being tip. |
|
|
|
|
Show Posts
