 Show Posts
|
|
Pages: [1] 2 3 4 5 »
|
Why is this project so popular? Are people seeing future growth potential or believe they would use the service themselves?
It's popular because it is *not* a blockchain. It is distinctly different than all other crypto-currencies. Like really, really different. And it does not suffer from the problems that everything based on a blockchain has. That said, it's still quite early, and the jury is out if the actual network meets the hype and marketing sales pitch we have all heard to date. For me, it's the first alt-coin I have taken any real interest in because it is such a unique technology. |
|
|
|
I'm a reasonably smart guy. Not super smart. Just semi-smart. I've been a professional software engineer for over 35 years. I've written a fair amount of bitcoin software in C++ and I feel like I understand blockchains in some level of technical detail. I certainly had no problems understanding the original bitcoin whitepaper. The IOTA whitepaper, on the other hand, that I really could not grok much of it at all. Sure, I get some of the concepts, but it's all couched in some heavy math, technical jargon, and doesn't really explain a whole lot of things I still have questions about. Is there a better non-technical explanation of IOTA out there, one that doesn't resort to just repeating the same marketing hype we have all heard up to this point? Some questions I don't feel like the whitepaper answered, in particular, is a very detailed description of the data layout of the 'tangle'. As a frame of reference, here is an article I wrote years ago which explains, in exact detail, how the bitcoin blockchain is represented down to each individual bit and byte. http://codesuppository.blogspot.com/2014/01/how-to-parse-bitcoin-blockchain.htmlSome questions I have are: * Are all transactions which have ever occurred in IOTA stored without pruning? And, if so, wouldn't this produce a database of unmanageable size at scale? I read the entire whitepaper and not one word seemed to address this most basic of all questions. * IOTA transactions do not appear to be confirmed instantly, like lightning network transactions are. In fact, confirmation all seems super probabilistic. It 'might be confirmed', 'maybe', if you wait long enough and check the score. While I love the 'no fees' aspect of IOTA and that it doesn't require the crazy complex routing of LN, it's still not really superior to the Lightning Network necessarily. * How are rules enforced? What prevents any client from using t his own algorithm for selecting, ranking, processing transactions? I really view the lightning network as the most obvious competitor to IOTA and I'm not yet convinced IOTA is better. Long confirmation times, proof of work, massive data sets, these are all big negatives compared to LN. Now, LN has it's own problems, so it's not super black and white. but it doesn't require proof of work and transactions are confirmed essentially instantaneously since the two parties merely exchange signatures. I would be happy to write my own article that explains IOTA to the layperson, without mathematics or requiring a Phd, but I can't write such an article until I understand it myself. I get that the math and all of that detail is important, and useful, but I really would like to understand the whole network at a much more basic level. How are transactions submitted to the peer-to-peer network? How much of the 'tangle' must be stored by any participant in the network? Do they need a complete copy of the entire tangle and, if not, how does that work? Is there the concept of 'full nodes' and 'spv like nodes'? Do some nodes store the entire database? Do they have a complete copy or an approximate copy? If the databases are fragmented, meaning there is no one singular definitive copy like in a blockchain, how are they merged and reconciled? How do 'light wallets' communicate with the rest of the network? I'm going to keep digging for resources but so far all I have found is either 'marketing speak' (stuff which rattles off the amazing miraculous features of IOTA without any explanation how it works) or technical documents that require a PhD to understand and, even then, seem to ignore many practical questions and issues. |
|
|
|
Anyone care to explain why market cap of IOTA is still so high? the project is obviosuly not THAT good, but for some reason market cap remains in the billion dollar range.
Out of curiosity, just what about the project is 'not that good' to you? I've been in the crypto space for years and this is the only alt-coin which has ever really peaked my interest; almost entirely because this is *not* based on a blockchain. I could be succumbing to marketing hype, but if this project can actually do the things it claims, it's definitely something very revolutionary. Why ETH has such a large market cap with all of it's disastrous problems is the real question IMO. |
|
|
|
|
>. 2x to 5x growth over a coupe of year period ? You are not a very big fan of IOTA then, I think will be x10 in 2 month, lets be realistic and not pessimistic! This is a great project that will take everybody by storms. Lets talk sense and give the benefit of the great technology this is!! Number 1 in CMC soon!
I think I am being realistic. IOTA has **DROPPED** in value by 3x in the past three months! That's hardly a bullish trend!
It's listed on only one exchange.
The wallets that exist are amateurish and buggy.
You cannot use it as a payment network pretty much anywhere.
Virtually no one has heard about it nor is using it.
The tech is unproven. Most of the miraculous claims about the tech are completely unproven and untested in the real world. It's a tinker-toy now that is supposedly going to become the Eiffel tower. That's very speculative.
I doubt it has been seriously attacked yet for vulnerabilities. It's not clear how it would respond to an attack or something like corrupted data in the 'tangle'.
Right now IOTA is priced the same as bitcoin was in March 2013. It does not at all feel as mature as bitcoin was at the same time.
How you can translate a 'dropped in value 3x in the past three months' into a bullish 10x sentiment in the next 2 is hardly what I would call 'realistic'.
|
|
|
|
|
I just wanted to give a word of advice for people who are trying to wrap their brains around what the IOTA token 'should be worth' and it's potential for growth.
I like to think of this way.
Take the total number of IOTA tokens (talking M tokens) which is 2,777 million and divide that by the total number of bitcoin tokens there will ever be (21 million).
This means there are 132 M-iota tokens for each one bitcoin.
Since one IOTA token is, at the moment, worth 0.26 USD, that means to own a share of IOTA tokens equivalent to one bitcoin works out to $34 USD.
So, IOTA tokens are currently trading at the equivalent of a $34 bitcoin and, to wrap your brain around volatility, over the weekend it was as low as $20.
I think it is helpful to think about IOTA tokens this way. If it ever, some day, became 'as big as bitcoin is today', where 132 M-IOTA tokens would be worth $2,060, that would be an additional 60x growth.
That said, it's probably a bit too pie-in-the-sky dreaming to think that will ever be the case. I mean, it could happen, but I wouldn't count on it. I would say that this should probably just be your mental idea of 'moon' someday for IOTA.
All that said, most people would be absolutely thrilled to just see a 2x to 5x growth over a coupe of year period and if IOTA gets any traction, that probably isn't an insane expectation. It's already been 2x higher than it is now once before.
The reality is, no matter how awesome the IOTA tech is, it still needs some kind of adoption / network effect to ever go anywhere. Right now, virtually no one seems to know about it, it's only traded on one exchange, so it still feels 'very early' on this thing.
Personally, I've been a bitcoin maximalist. This is the first alt-coin I have ever made a significant financial investment in. The main reason for me is due to the fact that the underlying tech is so radically different than a conventional blockchain.
Time will tell.
|
|
|
|
|
Just a follow up, I found out that the bulk of my issues were simply properly formed multi-sig addresses; which my parser had not been updated to take into account. I'm now making sure I can fully account for multi-sig addresses. I'm sure other people have noticed this, but as of a little over a month ago there has been an explosion in the use of multi-sig addresses and a shit-ton of bitcoins are moving to them.
|
|
|
|
|
Whether they are 'bogus' or not, my goal is to replicate what blockchain.info reports for these. For most of these blockchain.info does report some valid 'address' for each of these scripts. Essentially I use 'blockchain.info' to debug me own code, so matching their 'interpretation' of the output script signatures is really what I'm trying to do.
Maybe someone who works at blcockchain.info can explain how they interpret all of these rather bizarrely formed script signatures?
This also reminds why I'm not that thrilled with the whole scripting mechanism of bitcoin. Some clear standards on format and layout of input and output data would make things a lot cleaner. Now, with 20/20 hindsight, I wish that bitcoin was completely and utterly hard coded, no scripts all, and any 'experimental' programmable crap was reserved for side chains.
|
|
|
|
So, as I'm researching all of the output scripts that I cannot successfully decode the bitcoin address for, I realize I may going about this the wrong way. I looked for common patterns in the scripts, which normally 99.999% of all output scripts conform to. In the early days of bitcoin people used the full 65 byte public key, then later switched to the 20 byte RIPEMD160 format nearly everywhere. However, there are a number of other formats, including things like multi-sig, script hashes, and others, which create a lot of permutations. I guess what I'm looking for is the following: I want a routine which can accept a transaction output script as raw hex binary data and provide as output the public bitcoin addresses (*exactly* what would show up in blockchain.info as the output address). something like: struct BitcoinAddress
{
uint32_t key[25]; // the 25 bitcoin public key address
};
uint32_t findOutputAddresses(const uint8_t *scriptData, // The raw output script data
uint32_t scriptLength, // The length of the output script.
BitcoinAddress *keys, // The array of keys to return
uint32_t maxOutputKeys); // The maximum number of output keys allowed If someone could implement this in C++ with absolutely *no* external dependencies on any other code of any code (except stdint.h) that would be ideal. I have a routine already that does this, however that routine clearly doesn't take every possible permutation into account and I gather having the magic knowledge to know how to parse the output scripts in every flavor is time consuming. If anyone thinks they can write such a routine and has an interest, I would gladly pay a reasonable bitcoin bounty for the code snippet. It could also be very educational. Again, the requirements are that it accepts the raw binary blob of an output script and returns one, or more, bitcoin addresses which when printed in BASE58 ASCII exactly matches what would show up in blockchain.info. It must be a single source file, C++, and have zero external dependencies on anything other than <stdint.h> Anyone up for that challenge? Up until now the number of keys I failed to parse were fairly statistically insignificant, but that is no longer the case due to recent changes in how people are forming their transactions. I want to finalize my 'end of the year' statistics on the blockchain but, to do so, I cannot let any more public keys slip by unaccounted for. Thanks, John |
|
|
|
I guess I have a similar question. I'm encountering a number of output scripts which have non-standard lengths for the public key. Here is one where the public key is 37 bytes long: https://blockchain.info/tx/49c22f63beb61811ab87b6bfd0b04335e5684bea89d2760213e1f650853cb6f1The data for the key is: 4d 65 73 73 61 67 65 3a 20 68 74 74 70 3a 2f 2f
69 2e 69 6d 67 75 72 2e 63 6f 6d 2f 73 5a 38 64
30 2e 6a 70 67 The first byte is '0x4d' Here is one where the public key is 58 bytes long: https://blockchain.info/tx/d37e9d75ea61dd3f019626f077d74081bca0e80336ae9263cb362c094444c075The data for the key is: 4d 65 73 73 61 67 65 3a 20 42 69 74 63 6f 69 6e
50 61 72 61 2e 64 65 20 44 69 76 69 64 65 6e 64
65 6e 7a 61 68 6c 75 6e 67 20 31 20 76 6f 6d 20
30 37 2e 30 39 2e 32 30 31 32 The first byte is 0x4d as well. I'm not used to seeing public keys in the output scripts of such odd sizes. Why do they appear, and what is the proper rule to convert them into a bitcoin address? Is there a place that documents all of the way these signatures can be encoded (and converted to RIPEMD160 format) from a purely hex-dump perspective? Thanks, John |
|
|
|
Danny, you were so helpful figuring out that compressed public key, maybe you can help me out with this one too. Take a look at this transaction: https://blockchain.info/tx/195c96a25c4e63f641a2ddd920a9d00d2db947752f41c6be6d4cdd21e54f7ae8It has two output scripts, the second one contains a RIPEMD160 hash as follows: OP_HASH160 49206c6f76652077697a6b6964303537203c3300 OP_EQUAL When I run: "49206c6f76652077697a6b6964303537203c3300" through my code to produce the ASCII key, I get: "17ffAqKkfMLF5QAYwFEDkRtF2mJMzrkmpi" as a result. However, blockchain.info says the ASCII address is: "38Mg6NpCDFedAZrz4LtpB4FBBHb5WqwHaN" This looks suspect to me, to begin with, because it doesn't start with '1'. I tend to think that my representation is correct and blockchain.info has a bug. Can you confirm? *EDIT* and here is one more: https://blockchain.info/tx/d37e9d75ea61dd3f019626f077d74081bca0e80336ae9263cb362c094444c075The third output script is only 60 bytes long, and once you remove the push data operator and the OP_CHECKSIG, there are only 58 bytes left. I'm used to getting uncompressed public keys of 65 bytes in length. What does a 58 byte long public key mean? How is it supposed to be interpreted? Thanks, John |
|
|
|
Ok, I got it to work. I just had to make a 'compressed' version of my routine. Here is the code: bool bitcoinCompressedPublicKeyToAddress(const uint8_t input[32], // The 33 byte long compressed ECDSA public key; first byte will always be 0x2 or 0x3 followed by the 32 byte component
uint8_t output[25]) // A bitcoin address (in binary( is always 25 bytes long.
{
bool ret = false;
if ( input[0] == 0x02 || input[0] == 0x03 )
{
uint8_t hash1[32]; // holds the intermediate SHA256 hash computations
SHA256::computeSHA256(input,33,hash1); // Compute the SHA256 hash of the input public ECSDA signature
output[0] = 0; // Store a network byte of 0 (i.e. 'main' network)
RIPEMD160::computeRIPEMD160(hash1,32,&output[1]); // Compute the RIPEMD160 (20 byte) hash of the SHA256 hash
SHA256::computeSHA256(output,21,hash1); // Compute the SHA256 hash of the RIPEMD16 hash + the one byte header (for a checksum)
SHA256::computeSHA256(hash1,32,hash1); // now compute the SHA256 hash of the previously computed SHA256 hash (for a checksum)
output[21] = hash1[0]; // Store the checksum in the last 4 bytes of the public key hash
output[22] = hash1[1];
output[23] = hash1[2];
output[24] = hash1[3];
ret = true;
}
return ret;
}
|
|
|
|
Thanks so much for the detailed response. I looked a little bit further and the output is in the format of a 'compressed public key'. My parser already takes into account the 65 byte uncompressed public key which was only used for a little while in the early lifetime of the blockchain. These compressed public keys are rarely used as well because most of the time the 20 byte RIPEMD160 hash of the public key is what is usually stored in the output script. http://bitcoin.stackexchange.com/questions/3059/what-is-a-compressed-bitcoin-keyHere is the snippet if code I currently use to convert a 65 byte uncompressed public key to a bitcoin address, which matches your explanation. bool bitcoinPublicKeyToAddress(const uint8_t input[65], // The 65 bytes long ECDSA public key; first byte will always be 0x4 followed by two 32 byte components
uint8_t output[25]) // A bitcoin address (in binary( is always 25 bytes long.
{
bool ret = false;
if ( input[0] == 0x04)
{
uint8_t hash1[32]; // holds the intermediate SHA256 hash computations
SHA256::computeSHA256(input,65,hash1); // Compute the SHA256 hash of the input public ECSDA signature
output[0] = 0; // Store a network byte of 0 (i.e. 'main' network)
RIPEMD160::computeRIPEMD160(hash1,32,&output[1]); // Compute the RIPEMD160 (20 byte) hash of the SHA256 hash
SHA256::computeSHA256(output,21,hash1); // Compute the SHA256 hash of the RIPEMD16 hash + the one byte header (for a checksum)
SHA256::computeSHA256(hash1,32,hash1); // now compute the SHA256 hash of the previously computed SHA256 hash (for a checksum)
output[21] = hash1[0]; // Store the checksum in the last 4 bytes of the public key hash
output[22] = hash1[1];
output[23] = hash1[2];
output[24] = hash1[3];
ret = true;
}
return ret;
}
What I'm wondering is how do I take the 33 byte 'compressed' form into account? |
|
|
|
I'm working on my bitcoin parser and I'm running across some cases where I cannot decode the public key in an output script. Here is an example: See the coinbase transaction in block #199,975 https://blockchain.info/tx/870f2daaf1e6bf44fd23c98b152f5f5b45beeb7066eb135840809cb528579e87You will note that the output address that blockchain.info shows is: 1DgaASdtGgUavpNUE8ESBq3gmPbHh2ALnC The hex address for this is: 0x00, 0x8b, 0x1d, 0x6a, 0x31, 0xb0, 0x19, 0xe2, 0xda, 0x16, 0xde, 0x77, 0xf6, 0x0c, 0x62, 0x3b, 0x14, 0x42, 0xd5, 0xec, 0x2e, 0x24, 0x3a, 0x00, 0x61 Normally I find the public key in the output script, but in this case I cannot figure out how/where blockchain.info came up with "1DgaASdtGgUavpNUE8ESBq3gmPbHh2ALnC" for the output script containing: ChallengeScriptLength: 35 bytes long 21 - Push 0x21 bytes on the stack 02 14 71 c3 e2 c3 3f 1a 52 55 a5 14 cb f9 db d3 22 f8 2b 95 78 34 e5 90 ab 99 ff 00 26 30 eb b7 ee ac OP_CHECKSIG Any help/advice on what I'm missing to extract the public key from this output script would be most appreciated. How does this stream of 33 (02 14 71 c3 e2 c3 3f 1a 52 55 a5 14 cb f9 db d3 22 f8 2b 95 78 34 e5 90 ab 99 ff 00 26 30 eb b7 ee)bytes turn into this public key '1DgaASdtGgUavpNUE8ESBq3gmPbHh2ALnC'? Thanks, John |
|
|
|
|
Sorry, I haven't read through the 151 pages of this thread to see if these suggestions have already been made, but I'll add it here.
Two features that would be nice to add to the wallet:
(1) Have a way to filter out dust/spam transactions when viewing your transaction history.
(2) Have a way to view your 'spendable' balance. I have many watch only addresses in my wallet, but just a couple that the blockchain wallet has the private key for.
Thanks,
John
|
|
|
|
Can anyone explain how this transaction malleability bug can be exploited to steal coins from a Bitcoin address? I thought it can only happen if you are an exchange, like Gox or Stamp, and people are making withdrawals.
I can't explain it to you, because it cannot happen. This is a blatant lie, the OP stole everyone's coins and, as the other poster said, anyone stupid enough to leave coins on a hosted site dedicated to selling illegal products deserves to have their bitcoins stolen. |
|
|
|
If you keep your BTC on an illegal goods website run by drug dealers you deserve to get your funds stolen...
Thank you for the most common sense thing ever said on this topic! This should be a 'sig' |
|
|
|
So, I'm a little late to the party, I just heard about this 'coin', but I like the concept as a I do a lot of open source work. I am currently working on an open source bitcoin blockchain parser and analysis tool. https://code.google.com/p/blockchain/ What's the process I go through to become an officially recognized 'devcoin' open source project? |
|
|
|
|
Yes and the big addresses are likely exchanges.
|
|
|
|
|
In my opinion the days-destroyed thing is rather useless, let me explain why. Let's say someone has 1,000 bitcoins in one address which has not been touched for four years. Now, they spend a single satoshi out of it. The bitcoin days destroyed will be virtually nothing, but in reality the actual days destroyed are all 1,000 bitcoins, because the spend transaction, even it's just one satoshi, demonstrates that this address is no longer in hibernation. By virtue of spending anything out of that address the owner has declared that they are in active control of that private key and all of the coins associated with it; so, we can consider all of the coins as alive/active at that point.
My own tools report these statistics, I wish blockchain.info and other sites would display this much more meaningful information.
For what it's worth, I just gathered some statistics about the blockchain yesterday, including zombie/hibernating coins/addresses:
* To date there are 279,535 blocks.
* There have been a total of 30,720,691 transactions performed since day one.
* Those transactions are comprised of 67,717,755 inputs and 75,658,307 outpus.
* There have been 25,397,303 unique public key addresses ever referenced in the blockchain.
* Of these some 22,982,911 of those addressees have a zero balance and have been completely spent. Likely just used for intermediate purposes.
* That leaves just 2,41,392 unique public key addresses with a non-zero balance.
* Of those with a non-zero balance, 1,213,328 of them contain 'dust', balance of less than one millibit. [121btc]
* There are 942,085 addresses with a balance greater than one millibit but still less than one full bitcoin. [87,367btc]
* There are 157,632 addresses with a balance between 1-10 bitcoins. [399,921btc]
* There are 88,328 addressees with a balance between 10-100 bitcoins. [3,277,444btc]
* There are 11,576 addresses with a balance between 100 and 1,000 bitcoins. [2,776,270btc]
* There are 1,344 addresses with a balance of between 1,000 and 10,000 bitcoins. [3,047,203btc]
* There are 97 addresses with a balance larger than 10,000 but less than 100,000 bitcoins. [2,313,516btc]
* There are two addresses with a balance greater than 100,000 bitcoins. [255,455btc]
* 2,023,005 bitcoins reside in addresses which have been untouched in over three years.
* 3,488,959 bitcoins reside in addresses which have been untouched in over two years.
* 4,381,452 bitcoins reside in addresses which have been untouched in over one year.
* 6,144,924 bitcoins reside in addresses which have been untouched in over six months.
* 944,410 bitcoins are in addresses which have had active transactions in the past week.
* 2,401,321 bitcoins are in addresses which have had active transactions in the past month.
* 5,079,095 bitcoins are in addresses which have had active transactions in the past three months.
* 5,887,186 bitcoins are in addresses which have had active transactions in the past six months.
Hopefully this gives you a good idea how many bitcoins are active an in circulation from those which are sitting in cold storage.
It is important to note that these statistics are *not* based on transaction volume. This is based on addresses which are deemed active or inactive in the time period specified.
What I mean by this is if someone has an address that holds 1,000 bitcoins and they spend a single Satoshi, then that marks all 1,000 bitcoins as being 'alive/active' in that time period since the spend transaction indicates that the wallet/address is 'alive'.
|
|
|
|
|
