|
Can you post a website example?
|
|
|
|
|
This is jaw-dropping!
I successfully self-tested myself on a few websites and I'm especially amazed, because the whole process (or the part that I saw until now) was straight forward and without unexpected behavior or any other obstacles.
|
|
|
|
If you're looking at the entire blockchain history, I suspect you need to figure out what other addresses they've used in the past.
Also, IMO you should make sure you're only counting each "false positive" address once.
My initial intend wasn't actually to show how good or bad the prefix approach works, but simply to get an overview of all transactions and this was rather a by-product.  But now that we are at it: I run a specific analysis which solely targeted the SatoshiDice prefix range and stored all unique addresses that were found on mainnet: http://pastebin.com/DadRD9CLAccording to satoshidice.com there are 15 addresses in use: http://pastebin.com/Pr5juKC0I have absolutely no idea, if the other hits are or were used by SD, but in total 173 unique addresses were found and if those 15 addresses are the only ones used by SD, then the other 158 hits are false positives. Edit: the number of half a million was related to the number of transactions that were sent or received by those 158 "others". Edit: it looks like those 15 addresses were not the only ones ever used and there are some hits with significant volume, e.g. 1dice2xkjAAiphomEJA5NoowpuJ18HT1s. |
|
|
|
|
Hey Luke-Jr,
FYI: I was curious how many non-financial transactions there are and used your prefix list to identify gamble transactions. Then I compared the total number of transactions for SatoshiDice with the sum of the total number of transactions of the 15 addresses listed on satoshidice.com based on the data provided by blockchain.info.
Turns out the prefix based filter identified 11'677'989 transactions at height 327'115 while the actual number based on full hashes was 11'124'066 at height 327'120 +-2.
Under the assumption those 15 addresses are the only relevant ones, then that's about half a million false positives.
|
|
|
|
Counterwallet targeted instructions can be found here: http://imgur.com/a/YWKaV -- in short: submit your wallet's address, copy the unsigned hex of the raw transaction and use "address actions" - "sign transaction" within CW. It looks like not only Luke is pushing forward to 80 byte OP_RETURN, but jgarzik as well: https://github.com/bitcoin/bitcoin/pull/5075Makes me sort of wonder about the underlying motivation and what has changed since the "general consensus" resulted in the reduced length of 40 byte. And this makes me especially wonder, if there are business interests involved that some of the participants of the discussion might be associated with. |
|
|
|
... last time I checked, transactions with OP_RETURN outputs take significantly longer to get included in a block.
I can confirm this: the confirmation delay is still an issue, even today. |
|
|
|
When we were talking about the special transaction handling policies related to Eligius you were saying: Nor should you try to force core devs or pool operators (I think you really mean miners) to do your bidding against their will. And I raised the concern: Without transparency (e.g. published blacklists), I don't see how this is a choice made by miners. You sort of assured to me it is public knowledge: Eligius uses my public spam filter branch, and miners are capable of seeing what they are mining at any given moment in full detail using GBT The policy discussion held last week indicates there was need for further discussion and clarification regarding this topic, but now I found out a similar patch was applied to the gentoo package of bitcoind/-qt: https://bugs.gentoo.org/show_bug.cgi?id=524512That's disappointing. |
|
|
|
|
I'm wondering: is there a reason only uncompressed public keys are allowed?
|
|
|
|
update: got it working with the max confirms limit settings.
Great to hear. Do you have a rough estimate how many outputs per redemption are within the limits? |
|
|
|
Hey SkullCoin, can you paste the hex you are seeing? Edit: this might indeed be a bit long. You may try to use the settings and break it down into pieces, e.g.:  Edit: my local Bitcoin Core Qt client is able to "decoderawtransaction *the-ultra-long-hex*" without error, but I assume blockchain.info (and blockr.io) seems to be capped. |
|
|
|
Is it true that 10 of the 14 RBB people got fired or did they voluntarily leave? Are they now working for Robbie? Does this mean the foundation can operate for 4 months now instead of 49 days?
Good thing they all dumped their dev msc when they received them so we shouldnt expect a huge dump of dev coins now.
Hm.. mind to share on what basis you think this is the case? |
|
|
|
Standard transactions:
OP_RETURN: allow up to 80 bytes Do you know of any other pool that follows your lead? Non-standard transactions:
P2SH, by request at admin discretion, or 100 TBC per 512 bytes rounded up Hm? Eligius will consider P2SH as non-standard? Or non-standard scripts embedded in P2SH? |
|
|
|
FWIW: you probably know the max. length to push was reduced to 40 byte on most pools. A few days ago gidgreen published a small PHP tool to construct OP_RETURN transactions: https://github.com/coinspark/php-OP_RETURNThat being said, abusing the blockchain as message storage is not very popular.  |
|
|
|
I stumbled upon this entry: {
"source_addresses": [
"3Kfotk3zahcW2R94fdXWRtrR7b5Bn98Jy3"
],
"contract_url": "http://chroma.io",
"name_short": "CRYSTAL",
"name": "Margo's Crystal Coin",
"issuer": "Margaret Crable",
"description": "This is a coin that Margaret Crable created. It earns the owner right to one fantasy drawing of a magic crystal.",
"description_mime": "text/x-markdown; charset=UTF-8",
"type": "CryptoToken",
"divisibility": 1,
"link_to_website": true,
"icon_url": "http://chroma.io/chromacoin/coins/crystalcoin/crystalcoin.png",
"image_url": "http://chroma.io/chromacoin/coins/crystalcoin/crystalcoin.png",
"version": "1.0"
}
I assume there is no relation between http://chroma.io and ChromaWallet? |
|
|
|
Haha, thanks for the very fast response L0rdCha0s! So you basically didn't change anything, but from one day to another this behavior emerged? |
|
|
|
|
Show Posts
