|
Long chains messed up here. OP would you share what this was? A mixer? A DarkWallet use? Did you get your coins in the end?
|
|
|
|
Yeah, old topic but it was what I ran into when trying to learn something about bitmessage. Bitmessage is definitely not dead. Ok, I'm not an expert and they do a horrible job at PR but the last pull request was merged three days ago and the network is up and running. I received my first messages and running the client for several days did not experience any issues. Edit: Contact me under BM-NB9vUi2crQR9Sa35RkQtFHNkTUKmDvYr  |
|
|
|
|
Is LB interested in hearing about suspicious traders before we get scammed? I tried to chat about that but the new chat feature is a joke. It tells me that somebody will be ready in 30 minutes which is definitely long enough to switch to a different tab. Now when that chat eventually turns ready, it doesn't alert me in any way (why not have the tab at least blink?) and the support patience is less than 30 minutes as the chat gets closed due to **my** inactivity. Anyway, guys, please allow me to report users that offer local trading in many cities at the absolute best rate but when being contacted they start about being out of town and lets do the trade differently. Please add to your TOS that cash offers are only cash and that asking for paypal or anything on a cash offer will lead to account termination. For both sides. It also annoys me that people contact me on my cash offer while living 1000km away.
|
|
|
|
Not sure what BTC100 is at these days but I agree it is US centric. I would even suggest to focus on markets where Bitcoin is unheard of and not on the US or Germany. In the US and Germany it kind of has outlived its purpose.
I think the marketing effect is equal in all areas because in countries where bitcoin is relatively unknown you would have no use for bitcoins anyway. Its slightly more in developed countries but still... its really not on a level where you could say that marketing can stop. At the end this project aims to be an advertising project. Though at the end all that is needed are persons that persuade organizations to accept bitcoins. So its all up to the readers of this thread i guess. I see most sense in going where the donation has the most impact. Not in the sense of the NGO's purpose but in the sense of Bitcoin marketing and for that, a low income country can be a better target with such a donation. Sure, also size matters. Organizations where a dozen or so people discuss the donation will help us more than a one man show. Ultimately I'd like to see Bitcoin to grow evenly all over the world, so I try to promote it where it's the weakest. |
|
|
|
I'd also like to know about that. Can't we pull request new sources of store locations?
I forked from here https://github.com/recoded-co/coinmap is that not the master repo? still live for me? Yeah, seams all ok. It's interesting how there is a bunch of active forks that all failed to change the link. How/Where is the dogecoinmap? And the other hyper-active repos? Are they merge-friendly/worthy or total doge-adaptations? Hmmm, interesting  Ok, dogemap is here: http://dogecoinmap.github.io/ and lists 11 venues, still using the bitcoin favicon. Such empty. Lol Also what happened with the venue count for bitcoin? It dropped by 40 in one day last week? I usually remove more than I add but every single one I remove was a merchant that "right now isn't able to process bitcoin" when I show up. Or never heard of bitcoin. |
|
|
|
|
Not sure what BTC100 is at these days but I agree it is US centric. I would even suggest to focus on markets where Bitcoin is unheard of and not on the US or Germany. In the US and Germany it kind of has outlived its purpose.
|
|
|
|
The Git repo on GitHub seems to have been closed. Why? It's a pity...
I'd also like to know about that. Can't we pull request new sources of store locations? |
|
|
|
Usually this service works within a half hour for me. Every once in a while it takes half a day.
They use coinbase and it was instant for me before yesterday. |
|
|
|
Old post but I can't see the topic being explained anywhere near enough. It should be stated in the BIP32 itself. At http://blog.richardkiss.com/?p=313&cpage=1#comment-93828 Peter Wuille says: Not only revealing an xprv serialized key reveals the entire chain under it. Having an xpub plus any private key beneath it does that too (unless you use prime derivation, which is why it exists).
I had heard that with HD-Wallets, knowing any one xpub key and any one private key for a public key in the xpub key's chain would result in the chain being revealed up and down. So what would I want non-prime keys for? Wouldn't it make sense then to define derivation to be limited to the prime space rather than to default to non-prime for small numbers? Again, did I understand right? Given this example using bitcore … var HD = HDPrivateKey()
var hardened = HD.derive("m/5/5'/5/5")
var simple = HD.derive("m/6/6/6/6")
console.log(hardened.xpubkey)
// [1] output is "xpub6EP1wojrFHh7yDe2pbxiMCbdcyGfvv8eJEt28WYL1v14inWKMzss988YQSHU4KpsAkTEFW6dUGbE9LysJXTJzGHFMLFApoHBK6sntTvjxUC"
console.log(hardened.derive(1000).privateKey.toString())
// [2] output is "f0d658dc1b186862fac071bf280a38ab20d28dffe7843900e899cde2e9c01077"
console.log(simple.xpubkey)
// [3] output is "xpub6EohLkw7QkEdFTdsNg7Jeho4ywsf2CvQBHnBbaenTofnSg2JG5BiBzVo1Bm6L1ru5D5jLuDX71YACig1e2QNeJvy39SKYUEcafYNvegMYon"
console.log(simple.derive(1000).privateKey.toString())
// [4] output is "8b0a7eee9f4220dcda06d048520b0cc1a600b3d52963c84ca2b02434348f84ce"
console.log(simple.privateKey.toString())
// [5] output is "b284d9bdc4a798455dc2c4eb9805376b292d57853e4884f0840c03cb581e609e"
At 1 you would learn the xpubkey m/5/5'/5/5 and all its children but no private key. At 2 you would learn all the xpubkeys and xprivkeys derived from m/5/5'. At 3 you would learn all the xpubkey m/6/6/6/6 and all its children but no private key. At 4 you would learn m and all its children including private keys. There is no need for 5. |
|
|
|
Seems removed ltc,why?
He didn't get any donations in LTC. Search this thread. Also I wonder when he will remove BTC. |
|
|
|
I remember withdrawals from LocalBitcoins being pretty instantaneous. If they were batching them (combining multiple withdrawals together) then it would not be instantaneous (e.g., maybe one trx every 5 minutes).
Why 5 minutes. If they throttle the payout to every 10s, they could still get some transactions at times while no or just one transaction at other times. For a business of that scale it would just make sense. I just did a transaction minutes ago and do not recall a huge delay. The transaction was exclusively made for me though. |
|
|
|
Thanks for your response. And your answer is much more informed then the previous one. And in a sense your right, but your explanation is going into how Bitcoins are transferred rather then my example of a solution to the blockchain length. Your forgetting that Bitcoin is just a program and therefor can be adapted to any new ideas that may come about. I am very well aware of how the Bitcoin program works and have been programming Java Bitcoin key generators for a long time. I understand all your points very well. That being said, I still don't see anything stopping the Bitcoin nodes from creating a "Summary" block of the address that have the money. And then either deleting everything since then, or just using that as the block for new nodes to start from. For example, rather then downloading 25 years of Bitcoin transactions, maybe my new computer node just download everything since the last "Summary" block. The only problem I see is that you will have a trust problem with that "Summary" block. Perhaps the miners can build the "Summary" block and then put a hash of that in the next transaction or something so that each new node can verify the "Summary" block. Maybe someone else out there can build upon this idea.
Actually, now that I think about it it's not that hard. The miners, every 4 years create a summary block as a special block in the blockchain with the info right in it. The nodes then each verify the "Summary" block and if one of the miners tried to create a false amount they would reject the "Summary" block. Therefore the Summary block would be verifiable by everyone and as a new node all you would do is start from that summary block and build from there. Rather then downloading 25 years of data. Now if you want to you still could maybe it could be an option on the client. And for the "Light" clients they just keep up to date from "Summary" to "Summary" rather then the whole thing.
In essence, this is done by pruning, which will come very soon. Pruning does not group transactions to a concluding total which would be a change to the protocol that will very likely never come, as it assumes address reuse which should be reduced and not be encouraged. Pruning does though get rid of transactions that were already spent. You will be able to tell your node how many GB you want to spend on the bitcoin db and it will never exceed that. In turn, you will not be able to serve data for nodes that start up verifying data from the genesis block. (highly controversial daydreaming: I would advocate for a rule that forbids spending of outputs that are older than a year, forcing users to at least move all their bitcoins once per year but I know this will never make it into the code. Benefit would be to get rid of lost coins that will become a problem once sha256 becomes weak and we need to transition to the next better thing. Most likely it will become weak gradually but at some point people will "mine" the biggest wallets out there instead of the next block. With the max age rule, we would get rid of the satoshi dice sins of unspendable satoshis and of all the "lost" coins. Satoshi would have to move his coins which would be a great event but we would only learn that he's still alive and nothing more. If coins are moved from output to output independently, this would not merge a thing. The transactions would also almost always qualify for no transaction fees.) |
|
|
|
Like, how about every 4 years when the reword is halved, run a script that compresses all Bitcoin transactions down to just the addresses that actually have money The problem with your plan is that addresses don't exist on the blockchain, much less have a balance. I think that you are on the wrong forum because your comment doesn't make any sense. Of course blocks have address and balances. They may not be in a list like I'm talking about. But that's just an example. The developers would have to adapt it to work in that situation. There really is no object like a balance of an address in Bitcoin. When you think you spend x from your address, you really spend from prior transactions that spent to your address but to spend it, you don't need the address but its public key and a signature using your private key. If the "address" was a script hash, things are slightly more complicated. You would have to present the script that hashes to said script hash and then provide whatever the script asks for. That might be 3 signatures. So in a sense justusranvier is right and you old maid may check if you are on the right forum. |
|
|
|
|
I urge all interested in bitcoin and in coinmap to be more vigilant. I just removed Galts Gulch Chile, a fiasco and scam that was unveiled as such months ago. Also travelling to Mendoza I had to find out the hard way that places marked as accepting bitcoin were not accepting anymore or had no clue about bitcoin at all. Please, check your neighborhood, give such places a visit and *remove* them instantly if there is any problem accepting bitcoin. You may be supportive when it comes to resolve their issues and add them back later but if today you could not pay with bitcoin and you can't confirm that yesterday it worked, there is no value in having them on coinmap.
|
|
|
|
|
Is the project dead? Bitcoin is ranked 170 and a lot of information is missing all over the place!?!?
|
|
|
|
never click any link even if it is sent from localbitcoins.
Sadly, this is what I follow, too. I consider myself an expert but I don't feel comfortably secure in determining the source of an email fast enough to make it worth clicking on a link that came by mail rather than to hop over to the browser and open the service manually. Stay safe out there … |
|
|
|
Yes for now the wallet has to specify outputs explicitly. BIP70 doesn't have any kind of generation support in it at the moment. Besides, they are supposed to expire after a while to let wallets forget keys.
Well, the idea is out there. Judge for yourself: http://thisapp.io/ connects bitcoiners with merchants in a way that clients pay the merchant that in turn deducts it from money that was handed to him by a promoter. Imagine the promoter fronting $1000 to a café. It might take 100 transactions until the debt is settled. It might take less. Sure it would be possible to work with a static address or a hand full of addresses but what would really make sense would be to use a generator that the promoter transfers to the merchant who in turn presents addresses to his clients. WRT NFC - you can also use Bluetooth to transfer the payment request. Andreas Schildbach's wallet and derivatives support this.
Ah, true, haven't thought of that. Wonder how commonly they are used, though. |
|
|
|
I do not see the rise of cryptocurrencies as a zero sum game. I think the healthiest future will be one of many competing currencies. Bitcoin will thrive by remaining competitive. A store of value needs to be a public ledger and gold did that quite well. If you have any amount of stores of value, you will have horrible qualities as store of value for each of them. Check out https://www.youtube.com/watch?v=gKkfhi8Eaiw . I love this video as it opened my eyes in many aspects. I don't mind alt-coins for payment networks or other things but not as store of value. Lets figure out how to do sidechains. |
|
|
|
I am enjoying seeing my free XRP turn into a healthy sum of $$$ carry on boys!!!
I could have picked up this free give-away, too but refused to do so as I only see it hurt bitcoin. I won't let them buy me to run around as just another XRP shill. Yeah, I'm invested in Bitcoin but that is because I know what it is and I studied it before sending money to Japan to get some. Not because Satoshi gave it to me for free. |
|
|
|
It depends on your use case. BIP70 challenges the user to sign a transaction paying the outputs you define. If you already know the extended public key, you're can derive the address yourself.
As far as I understand BIP70, it does not contain a full transaction ready to be signed as it only provides the addresses to send to and not where it will come from. I had asked if these addresses could also be provided in the form of a generator (extended public key) instead of just a limited amount of addresses. I want to request a million payments over the next years, so I don't want to upload a million addresses (derived from my extended public key) but rather a generator. |
|
|
|
|
Show Posts
