So I do not understand how this thread, https://bitcointalk.org/index.php?topic=1736067.0"★★ SWIM's Cannabis Seed Service ★★ Worldwide Delivery ★★ 420 Sale ★★" is allowed on the fourm because it breaks rule 17 I feel like... 17. Trading of goods that are illegal in the seller's or buyer's country is forbidden. Can someone clarify? IANAL, but you know cannabis seed isn't the same thing as cannabis plant material. Depending on how laws are written in varying jurisdictions, it may not be illegal even in places where cannabis plant material is illegal. Even the OP of that thread you linked to has a disclaimer saying that buyers should check out the legal situation where they live before purchasing. |
|
|
|
There is a PR for that, it was something like a 5% performance difference for initial sync at the time; it would be somewhat more now due to other optimizations. It's used in the fibre codebase without autodetection. Please feel free to finish up the autodetection for it.
I would have made patches a long time ago if the whole project wasn't already rotten to the core. So here you're just admitting that you're only here to troll? Like they said, "I could tell you but then I'd have to kill you."
Too much hassle.
There was this other thing that they said, something about talk being cheap. Then there was another one I heard once that went something like 'put up or shut up'. Maybe those are relevant here.
At this point it's pretty clear to me that Troll Buster is just here to spew bile. It's really striking how puffed up he is about his skills and badassery and then when someone asks him to point to a project he's worked on or generally to prove his talk with something more than a google search his reply is all 'hey, look over there!' I'll keep watching this thread because amongst all the chest thumping are some interesting technical details, but I think we can go ahead and recognize that Troll Buster isn't going to be contributing anything more than the chest thumping. |
|
|
|
@TrollBuster You replied with a lot of "translations", but I think gmaxwell put it pretty clearly: Here is the straight dope: If the comments had merit and the author were qualified to apply them-- where is the patch? Oh look at that, no patches.
Some of your "translations" are really questionable: Some of these pieces of advice are just a bit outdated as well-- it makes little sense to bake in an optimization that a compiler will reliably perform on its own at the expense of code clarity and maintainability; especially in the 99% of code that isn't hot or on a latency critical path. (Examples being loop invariant code motion and use of conditional moves instead of branching).
Translation: My code is great, everyone else is wrong, nobody else can possibly improve it. That doesn't seem right. My reading of gmaxwell was a very strongly worded invitation for you to go ahead and improve it. Which wouldn't even hold a candle to the multiple orders of magnitude speedup we've produced so far cumulatively through the life of the project-- exactly my point about micro-optimizations. Of course, contributions are welcome. But it's a heck of a lot easier to wave your arms and insult people who've produced hundred fold improvements, because you think a laundry list of magic moves is going to get another couple times (and they might-- but at what cost?)
If you'd like to help out it's open and ready-- though you'll be held to the same high standard of review and validation and not just given a pass because a micro-benchmark got 1% faster-- reliability is the first concern... but 2x-level improvements in latency or throughput critical paths would be very very welcome even if they were a bit painful to review.
If you're not interested or able-- well then maybe you're just another drunken sports fan throwing concessions from the stand convinced that you could do so much better than the team, though you won't ever take to the field yourself. Tongue It doesn't impress, quite the opposite: because you're effectively exploiting the fact that we don't self-promote much, and so you can get away with slinging some rubbish about how terrible we are just to try to make yourself look impressive. It's a low blow against some very hard working people whom owe nothing to you.
All this bullshit talk is meaningless when your basic level silly choices are all over the place. Couldn't you, like, fix a few of the 'basic level silly choices' in order to strengthen your argument?
As far as I can tell you've been invited to offer improvements rather than just insults, but it seems that you chose to reply with further insults. If, for some reason, you can't provide a patch but can provide some helpful discussion which might lead to improvements then it seems like you might need to alter your approach. I'm not worshipping at anyone's "church" here, I'm just noticing the dynamic: you've been invited to prove the worth of your assumptions, but your reply doesn't seem to be headed in that direction. |
|
|
|
|
What version are you running?
|
|
|
|
Like everyone's asking here what programming language did you use? We understand that if what you're thinking is " its not yet complete or its not that good ", then let us try the program.
I don't think anyone is asking that. Did you read the thread? Or even the OP? The OP author already said he's using Python with the Deuces module and selenium for browser automation. I think the point of this thread is that the OP is discussing the idea of the program. Not sure what you're contributing here other than boosting your post-count.  |
|
|
|
Anyway, about your strategy, I would not comment on it's technical value but more on gambling theories. No strategy will work all the time in any gambling game, you will still lose in the end as. From your description of your strategy, you still assume there is a chance to lose (as expected). So there is a possibility that you will end up losing a lot of games in a row and eat all your bankroll up.
I don't think your application of "gambling theories" is exactly relevant here. In contrast to a game like slots, which is pure gambling (and in which case you're right), poker is actually a game between individuals. There's an element of randomness or chance, but it's not the case that every poker player is guaranteed to approach a loss as their playing goes to infinity (which is the case for slots). I think the OPs idea is interesting because they try to remove further uncertainty by continually going "all in". This sorta flattens out the decision tree and makes the modelling simpler. In any case, you'll observe that in a poker game the house grabs a cut of the pot, and thus guarantees its own win. But beyond this there's no mathematical certainty for any player at the table that playing more will make them approach a loss. If you always bet a constant amount and only play on hands that will win 55% of the time, then you ought to see a profit over time. This, of course, depends on the idea that people will call you with any cards (they won't), and it depends on the idea that you're correctly calculating the a priori odds of wining with that hand. Anyway, this is why a lot of poker players say that poker isn't gambling. And I think they're partially correct. It's definitely not the same animal as dice or slots. |
|
|
|
Usually on Windows you can find it at this location:
C:\Users\YourUserName\Appdata\Roaming\Clamcoin (on Windows 7)
C:\Documents and Settings\YourUserName\Application data\Clamcoin ( on Windows XP)
For linux you can try to look for this location:
~/.clamcoin/
Thank you.  If this file does not exist, then is it something that needs to be created? I am trying to set up a miner to automatically split outputs when I find a block. You may already know this, but if you're new to linux it might be helpful: Files that have names that start with a "." are "hidden" by default. So, in a terminal, you'll have to specify -l (to ls) in order to see them. In a gui file explorer, you may have to click something like "show hidden files". |
|
|
|
But it's certainly correct that the process is completely specified. There's a python library that you can use to play around with keys from numbers, maybe 'ku' (key utils), don't remember.
And what name of this library? I will be very appreciate you Here: https://github.com/richardkiss/pycoin |
|
|
|
@tspacepilot
I calculate the EV with following assumptions:
All players still in the hand when it is my turn are playing.
Only 1 opponent calls.
So basically, the EV is for playing a round i.e against 5 players, while the EV is calculated as if only 1 opponent was playing the hand (since 1 call is assumed)
Therefore, if all 5 enemies decides to go all-in, my winchances are the same (calculations done as if playing against all) but the potential stake is a lot larger than i calculated (my stake*5 + pot, instead of mystake*2 + pot)
As I understand this, you're not doing EV right. It seems like you're saying that you calculate your chances of winning as if everyone calls, but calculate your payout as if only one person calls, then you adjust the payout according to what actually happens. I can see why this is seems like a safe miscalculation. But it's also confusing when you're explaining your approach. Another thought, and maybe this doesn't matter, but I'll say it anyway. People can have a short stack and call you, that affects how much you can win. I t also affects how much you can lose so perhaps it's a wash. About the why of my simulations: At a table with 1 other opponent, an AA hand is a 100% all-in but with 5-6+ opponents, pairs are harder to achieve a +EV on, while jack/ten and same-suits are easier to get value from. Since people leave and enter at will, and balances/pots changes non-stop i feel it is necessary to run simulations before every decision. Regarding the technicalities, I am using the Python module Deuces to handle everything Poker, and the Python module Selenium to handle all interaction with the webpage. I really wanted to be at another poker site, but tinkering with stand-alone poker clients are way above my league I see, I found that module, I didn't understand before if you were writing your own poker module called Deuces. I also saw that the "simulation" code is probably also coming from Deuces, the readme talks about simulating hands. I suppose it's up to me to read the module if I want to know what's being simulated. My question is sorta like this, let's say we're sampling from the following distribution of values [ 1, 1, 1, 0 ]. You can see right away that you'll have a .75 percent chance of choosing a 1. Now, we can establish this empirically by writing some code to simulate sampling and then do it 10K times or whatever and look at our results. However, there's really not a lot of need for the sampling step since we know the distribution to begin with---the sampling step really just tests our ability to write sampling code, we know that if we find that we're approaching anything other than 0.75-0.25 in the long run average, then we're not sampling right. It seems to me that your situation is similar: you know what cards you have---given that you already know the distribution of hands you'll have after 5 cards have been drawn. From there, you also have a joint distribution between your hand and those of N opponents and you can calculate the probability that your hand is better. As far as I can tell, you don't actually need to do any sampling to learn that, do you? Don't you just use some multiplication and division to calculate odds? Anyway, I think that selenium is a nice package for browser automation. I'm pretty sure you can export a screenshot from selenium if you wanted to try OCR (but I don't know if it'll be fast enough for you. It should be smart enough if you are able to constraint the size of the screenshot and if you can train your own model. You only need to recognize a small set of characters. |
|
|
|
Hi,
Thanks.
Still kinda confused how I will end up with 2 lots of coins when I have one wallet and one set of keys...
Well, that's the worst case scenario with a fork, they never come back together and the two chains effectively become two incompatible cryptocoins. In this hypothetical scenario, the two coins share a history up to a certain point at which they diverged. You have private key(s) which are from the shared part of the history. That means that just as one cryptocurrency has now become two, your coins in the original cryptocurrency have now become coins in LeftForkCoin and in RightForkCoin (I love these names). As long as you control your own private keys, you are safely a part of the "winning" coin when and if a "winner" becomes apparent. If there never ends up being a winner and both forks retain their value, you're happy to have both coins. I hope that helps. So what if LeftForkCoin and in RightForkCoin really happens after that SegWit2 will be enabled, Should I really make a hardware wallet early as now and get my bitcoin balances from Coinbase? or this Online wallets have a plan also with this event if it will really happen? I am not a geek to know about this sorry. You should get your private keys from coinbase. I don't know if they allow this, if they don't, you should move your coins to and address you control. That's my opinion. |
|
|
|
I'd like to know how you're calculating EV. Your comment that more people calling leads to greater EV seems pretty suspicious.
The program knows my hand, and the number of opponents playing. It calculates the % i win, the % i lose and the % i tie out of ~55k simulations. More on this below, but I assume that the number of simulations is because you're trying to model the indeterminacy of the opponent's behavior? I guess I'm not completely clear why you'd need to run simulations. If you have a model, can't you just read the parameters and make a decision? I then add the pot to my table balance times two, to also simulate at least 1 call. So, it calculates EV for playing against all opponents for the pot made up of only 1 call, so more calls will make the risk more worthwhile since the odds stay the same but the possible return increases.
So, this makes me think you've got something wrong already. Lets say you go in with a high hand, so you have a high probability of winning. But the more opponents you have against this hand, the less likely it is to win because of how poker hands work. I'm pretty sure that if you're correctly modelling your distribution, you'd find that the chances of AA winning against one opponent are higher than the chances of AA winning against two opponents (and so on). Suspicious is a strong word... I am just having fun with Python, and my interest for gambling. Sorry if I was misunderstood. I'm suspicious of the correctness of your calculations, nothing more. tokeweedis right that most sites aren't going to let you leave and rebuy immediately with less than you left with. You'd have to wait for some time limit to expire in order to re-enter with just the buyin amount.
Yes, exactly. After sitting out for approx. 3mins depending on activity ( i assume ), my balance is cleared from table and i can re-enter. On poker sites I've used, it's more like 20 minutes to an hour. But I guess you know the principal anyway. I still want to hear more about the OP's calculations for EV. Please.
Example calculations: My hand: 9s,td Table/community cards: None (pre-flop) opponents: 4 current pot: 50 balance on table: 200 Simulation ( http://i.prntscr.com/1G1p8s9uQp2MFrN1jZrq-A.png) so 21.18% chance to win 450 (assuming at least 1 call to the all-in of 200) and a 75.93% of losing 200 (if no blinds), and 2.89% chance of a tie that results in a shared pot (0). I hope that helps Erm, not really. I mean, that's a screenshot that shows the output of your program, not how you got there. This is my source for the mathematics I took a brief look here. I'll look more closely later. Thanks for sharing your source. I note right away that this discussion says things like "To answer this, we'll first have to determine how often he calls, how often he raises, and how we fare against each of those. Let's assume that we somehow know ..." it's not so clear to me how you can determine this in real life without a lot of data about particular opponents. I suppose you can do something like what this article does---model some generic opponent---and see how they fare. Is this what you're doing? Providing I have some Python skills, how long will it take to build something like this?
Not long at all, see my above post where i put a link to the python module i use to simulate poker games. It is called Deuces, and it is truly awesome! The tough part is "connecting" to a poker table and be able to act on it. In order to run as many simulations as possible it is vital to get the parameter data asap  Did you link to something other than that screenshot? ---- Responding to your question about connecting to a poker room to get the data: did you try OCR? What have you tried? If your poker program sends the hand data in the clear you should be able to use wireshark to read that straight from the network socket. |
|
|
|
|
To people "it wont' work": I would consider that to be an empirical question. In point of fact, people on low-stakes poker tables aren't necessarily the best poker players. Whether OP's strategy works depends (in part) on the competition. malboroza is almost certainly right about higher stakes players: they'll just leave the table. but with low-stakes players, you never know, they may want to play bingo---i've seen some funny stuff on sealswithclubs back in the day.
tokeweedis right that most sites aren't going to let you leave and rebuy immediately with less than you left with. You'd have to wait for some time limit to expire in order to re-enter with just the buyin amount.
I still want to hear more about the OP's calculations for EV. Please.
|
|
|
|
ice2097, did you try this tool? https://bitcointalk.org/index.php?topic=25091.0It just loops through the file and tries to find concurrent sections which could be keys. Might be useful since you said the file isn't parseable as a wallet anymore. |
|
|
|
Here is some python code to get a hex string into WIF. I think I modified this code a bit but the original source was a blog post called 'bitcoin the hard way". import hashlib
b58 = '123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz'
def base58encode(n):
result = ''
while n > 0:
result = b58[n%58] + result
n /= 58
return result
def base256decode(s):
result = 0
for c in s:
result = result * 256 + ord(c)
return result
def countLeadingChars(s, ch):
count = 0
for c in s:
if c == ch:
count += 1
else:
break
return count
# https://en.bitcoin.it/wiki/Base58Check_encoding
def base58CheckEncode(version, payload):
s = chr(version) + payload
checksum = hashlib.sha256(hashlib.sha256(s).digest()).digest()[0:4]
result = s + checksum
leadingZeros = countLeadingChars(result, '\0')
return '1' * leadingZeros + base58encode(base256decode(result))
def privateKeyToWif(key_hex, compressed=False):
if compressed:
key_hex=key_hex+'01'
return base58CheckEncode(0x80, key_hex.decode('hex'))
I think that explains it as well as any prose I could write up. |
|
|
|
|
I'd like to know how you're calculating EV. Your comment that more people calling leads to greater EV seems pretty suspicious.
|
|
|
|
|
Last time I built bitcoin you could pass a parameter to ./configure "--with-incompatible-bdb" and then use whatever bdb was available on your system. This was really helpful for not having to dig up ancient software. I tend to agree with the thrust of this thread that it would be nice to figure out a way to further mitigate this issue, but it's already been explained upthread how different versions of bdb are going to result in incompatible wallets. Anyway, in the use case where you're not trying to recover an old wallet from years ago, it really is pretty simple to build bitcoin using whatever bdb is available in your distro's repository.
|
|
|
|
Welcome back. This is much different than what it used to be, ever since I started managing it.
That's a good thing. It sorta felt like a zombie process that got abandoned. The auto-pay auto-enroll system was a really beautiful idea: always ontime, etc. But yah, it definitely needed some human attention. |
|
|
|
if I understand well : private key is a combining of random number between 1 and 10^77.
From this private key is derived a bitcoin address with a precise algorithm.
As long as you send BTC to this bitcoin address which has been derived from your private key : you can safely say that you have the control of your fund and that your private key is valid.
can someone confirm?
Correct. If I recall correctly you can actually generate two bitcoin addresses from a given random number. But it's certainly correct that the process is completely specified. There's a python library that you can use to play around with keys from numbers, maybe 'ku' (key utils), don't remember. Anyway, python is convenient for learning, I think, the code is pretty readable and you can use the REPL to explore interactively. |
|
|
|
Hi,
Thanks.
Still kinda confused how I will end up with 2 lots of coins when I have one wallet and one set of keys...
Well, that's the worst case scenario with a fork, they never come back together and the two chains effectively become two incompatible cryptocoins. In this hypothetical scenario, the two coins share a history up to a certain point at which they diverged. You have private key(s) which are from the shared part of the history. That means that just as one cryptocurrency has now become two, your coins in the original cryptocurrency have now become coins in LeftForkCoin and in RightForkCoin (I love these names). As long as you control your own private keys, you are safely a part of the "winning" coin when and if a "winner" becomes apparent. If there never ends up being a winner and both forks retain their value, you're happy to have both coins. I hope that helps. But I do have keys and my wallet seems pretty pro
So, this part is good. |
|
|
|
|
My own suggestion to the OP is to keep track of your own private keys. I'm not familiar with the "Nano Ledger" but I guess it's some kind of hardware wallet. I strongly suggest that the OP get the private key(s) out of his "Nano Ledger" and keep a physical copy of it safe somewhere. Electronic devices can fail, ink on paper can fail too, but having a backup in a non-electronic medium seems wise to me.
I think the other posters mainly answered the other questions in the OP.
|
|
|
|
|
Show Posts
