Well, after some of the clues pirate posted, having big influence at Mt.Gox or some other large exchange, he might be doing Front running which is extremely profitable. Well, trace the coins from deposit addresses to MtGox and/or other exchanges then, if you can.  |
|
|
|
I've done some very analytic research, carefully analyzing all of Pirate's projects, posts, and relationships. I'm 99.9% sure I know exactly what he's doing. Then do it yourself and earn ~10% per week!  What stops anyone else to create the exact same thread you did claiming they have 99.9% certainty by evidence through analysis of whatever that pirate operates a ponzi? They just don't want to tell you... If you really did thorough research, just tell us how much pirate currently has in his hot wallet. |
|
|
|
But then I realized the odds are much greater that your mag goes out of print way before Pirates bank closes up... Well, currently pirate's wallet size is [some numbers]3.76618902 and it's much [higher/lower] than you might think! I won't post numbers though until I did more analysis, also it could be expected that he doesn't have huge bitcoin holdings all the time - after all he claims to be trading with them! |
|
|
|
Since there's currently a lot of fuzz about pirateat40's operations (is it a ponzi? is it legit? where does he get his coins from/back, if he really sells them OTC? how is GPUMax fitting in?), I think one of the best ways to analyze the situation is to get an address that surely belongs to him, hope for combined inputs if he sends something from that address, assume these belong to him as well (as he'd need to have private keys for that) and work our way from there until we have all linked addresses to a single bitcoin address. Also something like this might also be useful for other purposes and I haven't found many projects concerning this (one would be toolongdidntread.com)... After that, we can assume this as his wallet and check the balance, money flows etc. (which is currently a bit beyond what I did so far). The first problem I ran into however is: Is my code so far really correct? I don't want to make accusations or draw conclusions when it turns out that I included an MtGox address out of stupidity... Anyways, here's the code to track any address (supplied in the "trackaddr" list) for multiple inputs. It will iterate over the whole blockchain multiple times until no more new inputs are found. Because of recent blockchain spam, I limited it currently to block 160000 (enough for the address I have so far) and there's probably a nicer way than running ~10 times over the whole chain. I have a fast CPU however, so it doesn't really bother me atm, the bigger concern is if it is really doing what it's supposed to do and has no chance of picking up and including some random other addresses. Code (with Armory's donation address up to block 170000): from armoryengine import *
BDM_LoadBlockchainFile()
topBlock = TheBDM.getTopBlockHeight()
trackaddr = ['1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX']
taintedblocks = []
addratstart = len(trackaddr)
addratend = 0
iterations = 0
transactioncount = 0
while addratstart != addratend:
transactioncount = 0
iterations += 1
addratstart = len(trackaddr)
for h in xrange(0, 170000): #topBlock+1):
if h%10000 == 0:
print '\tScanned %d blocks' % h
print 'Found %d addresses so far.' % len(trackaddr)
header = TheBDM.getHeaderByHeight(h)
txList = header.getTxRefPtrList()
for tx in txList:
foundaddr = False
for nin in range(tx.getNumTxIn()):
txin = tx.getTxInRef(nin)
try:
senderAddr20 = TheBDM.getSenderAddr20(txin)
address = hash160_to_addrStr(senderAddr20)
#print address
if address in trackaddr:
foundaddr = True
print "FOUND TRANSACTION! At block " + str (h)
except:
pass
if foundaddr is True:
for nin in range(tx.getNumTxIn()):
txin = tx.getTxInRef(nin)
try:
senderAddr20 = TheBDM.getSenderAddr20(txin)
address = hash160_to_addrStr(senderAddr20)
trackaddr.append(address)
except:
pass
trackaddr = list(set(trackaddr))
transactioncount += 1
taintedblocks.append(h)
taintedblocks = list(set(taintedblocks))
addratend = len(trackaddr)
print trackaddr
print taintedblocks
print "Went through the blockchain %d times!" % iterations
print "Found %d transactions" % transactioncount
print "Found %d blocks where these transactions were included" % len(taintedblocks)
print "Found %d addresses" % addratend Oh, and I won't post any results (it's easy with armory to include all found addresses to a "wallet" for example and read the spendable balance of that at each block) publicly or in PMs until I have verified this code to be correct! Also pirate seems to be quite paranoid about posting bitcoin addresses belonging to him, so good luck with finding some (unless you're a customer at BTCS&T, then you can of course use your deposit address). Edit: I was using armory 0.76 rc1 - the current 0.81 version throws: Traceback (most recent call last):
File "!findwallet.py", line 29, in <module>
for nin in range(tx.getNumTxIn()):
File "xxxxxxxxx\Armory_0_81\CppBlockUtils.py"
, line 813, in <lambda>
__getattr__ = lambda self, name: _swig_getattr(self, TxRef, name)
File "xxxxxxxxx\Armory_0_81\CppBlockUtils.py"
, line 51, in _swig_getattr
raise AttributeError(name)
AttributeError: getNumTxIn |
|
|
|
|
I get why I should SELL litecoins... why do people BUY them though?!
|
|
|
|
|
I meant client puts up money up-front to service.com (= centralized service instance that is responsible for handing out money). If a client then downloads something, they will very soon report to service.com how much they downloaded from whom. A seeder can then see if the people loading from him are really reporting their traffic or not. This way he can make sure people actually reporting correct amounts of traffic (he knows how much traffic went out per IP/user).
I don't see how a "regular web login system" should help anything against abuse or copyright claims. I personally really like the idea of at least limited anonymity (service.com would know: IP addresses, SSL IDs, Bitcoin flows + amount of traffic (maybe even per file/piece, though that's not necessary) as well as some meta data like bandwidth estimates). Service.com could even ban certain pieces, just like BitTorrent trackers can blacklist Infohashes.
There's no way though to make sure as service provider that people don't use the system for illegal stuff other than hand checking everything and requiring cleartext transfers. I'd rather go the BitTorrent way, where service.com simply has no chance whatsoever of knowing what's behind a piece hash and can only offer to blacklist these upon a court order.
|
|
|
|
5000 BTC to 1PjZWL4QmwHNa4Py16uWJr1T9udNRXXrpm within the next 24 hours and this is my last post in this thread. Edit: cheaper than hazek because I'm probably less annoying...  |
|
|
|
In addition, people getting mandatory withdraws could never happen in a ponzi, since money is always needed to fund the ponzi. If you grow too fast, you risk not being able to pay out big/early investors (which seem to be the more vocal ones in this thread, since they have - hopefully not just "on paper" but after a successful withdrawal - already multiplied their investment) and your system could collapse early. Also for whatever weird reason people see this as a more reassuring fact. On a different note: If anyone is interested in running some blockchain analysis: http://blockchain.info/fb/1gpuma seems to be a payout address to a miner (who also used satoshidice, so don't assume all inputs are from pirate) on GPUMax. http://blockchain.info/fb/1nz2hx for example is with quite high certainty an address controlled by GPUMax and thus pirateat40. Have fun working your way from there!  |
|
|
|
OK, I have checked where the funds go from my deposit address and I can report that the funds in the next step mostly go to addresses that are used heavily with large amounts. Post address or PM please... I won't go as far as calling you a sock puppet, but I'd love to do this research on my own and not just take your word for it. Edit: The "big one" could have been one from MtGox for example. |
|
|
|
the whale manipulations and walls we see on mtgox for past several months i think can be attributed to pirate's business, if not directly by him then by those to whom he brokers bitcoins - those who massively invest in btc through pirate at high premiums most certainly like to see returns on their investments. Post deposit transactions to BTCS&T and trace them to MtGox or  ! Seriously, why all this speculation? |
|
|
|
Moderator = moderating posts Moderator != Judge/Jury/Executioner! |
|
|
|
|
Concerning shorting:
If my bet is him running off with the money, how would I sign and especially enforce a contract with him?! Also this would probably lock up quite some funds of both shorters and people long on him (who would likely rather have their coins "working" at BTCS&T, as the returns there would be even better than going long for a 100% return after a few months).
Oh, and again:
All(!) his transactions are public! This is Bitcoin, not some hidden network of bank to bank transfers! Have some balls, post transactions to pirate's addresses and if he made a mistake somewhere combining lots of his accounts, it will come out - then you could clearly see how much money is invested with him, where it goes etc.
About selling BTC in bulk for cash:
* Why is there so high demand for BUYING BTC from pirate alone and not some other people here too?
* Where does pirate get back his BTC for the USD he got? MtGox? The ppl. he sold BTC to at a price difference?
|
|
|
|
|
I would also guess there won't be more than 1/4th or 1/5th of outstanding shares covered by an active 1 BTC bid, if at all (I also really don't like the "reasonable" timeframe, especially when talking right before about "Each bond you buy can be exchanged for 1 bitcoin face value AT ANY TIME!").
Some hard numbers ("10% of all outstanding bonds can be sold back immediately through an open bid offer @1.0BTC by the operator - we will operate a bot to keep this bid up-to-date every 10 minutes and will rebalance the GLBSE account behind at least every 72h after big sales") that usagi would be comfortable with to commit to (and beat on a regular basis...) would probably be better than having "We'll try our best" as contract...
|
|
|
|
|
I already suggested blockchain analysis, but never even got a single deposit address of pirate (via PM or publicly), so I put that on hold as long as my exposure to him is low enough.
Why should I invest a lot of time and effort only to save someone's ass who invested thousands more BTC with him? Maybe I'll still do the investigation but charge a hefty fee (people here seem to be comfortable with putting up 500 BTC just to be allowed to deposit more money) for the results...
|
|
|
|
Also, whenever the file is downloaded (whether it be by the client or by another node wishing to host the file), the hosts are paid for that week by percentage according to how much data they provided during the download. Who pays and how should/could this be enforced? I'm still thinking mainly about issues with my original plan earlier on: service.com checks hashlists provided by uploaders and pays some standard fees (quite low) for that service.com publishes payments downloaders committed to paying to storage nodes, so storage nodes can check that they are trustworthy If someone wants to check if storage nodes really offer the files they claim, they can anyways try to download them. One of the few questions that remain for me is which protocol should be used (I'd lean towards WebDav), how downloaders verify themselves (so nobody else claims to be "Alice" and spends her money deposited on service.com) while still remaining anonymous (I'd lean towards PGP public/private key pairs) and some other minor things... |
|
|
|
|
I don't know of other insured assets on GLBSE currently... hmmm, maybe PPT.X?
What would it cost me to insure 100 PPT.X bonds against PPT defaulting and not paying out their 32 Bitcents?
|
|
|
|
|
What's your rate to insure against a YARR default?
|
|
|
|
|
GLBSE is however operated in the "real world" paid for in USD and Nefario exists not only in the block chain. The only difference is that you need to pay out in a highly volatile currency that (compared to most other volatile currencies like Zimbabwe Dollars) rather has a trend to shoot UP against USD than down lately making it quite hard for traditional insurance companies who have their assets in fiat currency backing the insured sums and pricing the fees.
Everything else is the same as in any other insurance company and even a bit worse - you won't be able to insure your risk somewhere else in BTC probably, you're probably not licensed to do insurance at all and are an anonymous person on the internet somewhere in a jurisdiction far far away. Still you want/need to charge far more than traditional insurances... I see the dilemma, but I can't give proper solutions either other than really getting in touch with an established fiat money insurance and having a serious talk with them.
|
|
|
|
|
0.5% a month is also still horrendously high if you compare this to some other insurance rates (non-bitcoin) - I can insure my home up to several 10000 EUR for less than 20 EUR a month. Also the idea alone of depositing money at pirate to cover for insurance cases makes me shake my head in disbelief.
|
|
|
|
|
You can NOT check if a client will provide a chunk by salted/random checksumming, only if a client stores a chunk. To check for actual availability, you have to transfer + measure accordingly. If I still get money/other benefits for not uploading anything, I won't (legal hassle, upload bandwidth is scarce).
1 chunk --> 5 nodes is even worse, as I'd have to constantly download and measure speed from 5 nodes just for 1 piece.
IP addresses are dynamic (with IPv4) - if I run that on Amazon EC2 (and now Google's service too), good luck with banning all my IPs! IDs are no problem, as they are being randomly generated anyways and can't even be guaranteed to be unique. Currently it would make no/little sense to steal NodeIDs in the BitTorrent DHT for example. It's easily possible however to do so.
The strain on the network should come from actual transactions, not only "show me that you still store this!" traffic imho. Also I would have inbound traffic...
Again, imagine me storing 5 TB of data in this cloud. 1 MB chunks, stored at 5 nodes at the same time to make sure they are still available all the time (in reality I'd use Solomon Reed but just for this example...). I only download a random (on average) 4 kB part of this file and then cancel the transfer (if I only always load 4 kB fixed, they migh choke anyone trying to transfer more than that, as it isn't a test).
25000000 parts * 4 kB = 100000000 kB transfer per week (100 GB) = ~165 kB/s constant download. I didn't even do the 1 kB = 1024 MB etc. thingie, including other overheads you can expect to have about 200 kB/s constant download just to check that your part files are still available once a week, which is very little (on average just ~4 tests a month).
Sorry, but monitoring the download speeds can ONLY be done by the actual downloaders themselves. Everything else is a HUGE waste of time and ressources.
|
|
|
|
|
Show Posts
