Search content
Sort by
Showing 20 of 74 results by phathash
So I had a silly idea back in 2010 for a cryptographic-based, provably-fair service of some sort. Not a new concept in itself, but it may have been worth pursuing further. Domain registered Nov 2010.
PM me if someone wants to give it a new home or if you have any other ideas.
PM me if someone wants to give it a new home or if you have any other ideas.
This is a hard problem. I would imagine a competent exchange would require people with skills (as a minimum) in the following areas -
- legality
- security
- policy
- high frequency programming ("coding" is not enough)
- scalable infrastructure
- legality
- security
- policy
- high frequency programming ("coding" is not enough)
- scalable infrastructure
"Bananas", "collector cards", "beanie babies", "geeks", "Winklevii", "no underlying value", "tulips".
(starts 5:27)
http://theprojecttv.com.au/video.htm?movideo_p=39681&movideo_m=300921
(starts 5:27)
http://theprojecttv.com.au/video.htm?movideo_p=39681&movideo_m=300921
2013-04-13 Virtual money to stop financial meltdowns (Australia)
"Nonsense", "Tulip Mania", "Dodgy", "Strange", "Terrorists", "Drug dealers", "appeals to a certain class".
http://au.tv.yahoo.com/sunrise/video/-/watch/1d0cdb9f-9651-32ac-bfa6-b0c357fbbe2f/virtual-money-to-stop-financial-meltdowns/
Quote
I already indicated bit-coin addresses and part of signed transactions being random, what I was talking about the address occurring multiple times in block chain.
This would require some sort of local index of addresses. This would be bloat. Further, how big would you make the index field size? 4 bytes? This was once considered enough for packet-switched networks.. and looked what happened there!
Satoshi intended for addresses to be only be used once. Future address generation could far exceed addresses used in other protocols (ie IPv6 = 16 bytes).
Mr Smith is correct. Great minds have already thought of such things for us already. In fact, somewhere along the way someone already figured a way to compress public keys to half their original size. No harm in us mere mortals trying to understand however.
Humans read base58 bitcoin addresses (20bytes) as ASCII numerical representations. Saving these into notepad is going to result in 34 bytes and will be compressible given a large enough sample. The block chain is a binary beast and is very efficient. Addresses are saved as 20bytes. If you can compress this (regardless of set size) we are all in trouble.
All other data consists of arbitrary data (ie output values) and indistinguishable (hopefully) random data (cryptographic hashes and signatures).
I suppose if someone embedded structure into the block chain, ie through output values or non-working addresses (no private pair) you could somewhat compress it.
All other data consists of arbitrary data (ie output values) and indistinguishable (hopefully) random data (cryptographic hashes and signatures).
I suppose if someone embedded structure into the block chain, ie through output values or non-working addresses (no private pair) you could somewhat compress it.
You have described a deterministic wallet. I think Casascius came up with this in 2011.
I think a simple example works as follows - start with secret exponent sha256(seed:x), with x being some arbitrary number (ie 0) and then incrementing for each new key pair. "seed" is the secret.
In your case, you are using the addition of two private keys as the seed. You always need to keep at least two adjacent key pairs to keep the chain going. Exploiting any two adjacent keys would reveal all subsequent keys. Such a scenario may be more vulnerable to attack or loss as private keys are likely to be contained within bitcoind wallets (which may or may not be connected to the Internet). Two "secrets" are also required to be remembered.
A traditional deterministic wallet seed is not stored within a bitcoind wallet.
I think a simple example works as follows - start with secret exponent sha256(seed:x), with x being some arbitrary number (ie 0) and then incrementing for each new key pair. "seed" is the secret.
In your case, you are using the addition of two private keys as the seed. You always need to keep at least two adjacent key pairs to keep the chain going. Exploiting any two adjacent keys would reveal all subsequent keys. Such a scenario may be more vulnerable to attack or loss as private keys are likely to be contained within bitcoind wallets (which may or may not be connected to the Internet). Two "secrets" are also required to be remembered.
A traditional deterministic wallet seed is not stored within a bitcoind wallet.
If "generic", grey-market or ASICs using stolen IP eventually come on to the market, I can imagine backyard operations running on wherever electricity could be had cheap or stolen.
For years the web hosting industry had a problem with cowboys operating out of their mom's basement. The difference here, however, is that such a private venture needs not concern itself with uptime SLAs, multi-tiered bandwidth, power conditioning and backups. Just keep those Alibaba-sourced ASICs running on the smell of an oily rag. UL and FCC approval would not even be in the vocabulary of such miners. VESDA fire suppression? Contract your rigs out to Bangkok.
For years the web hosting industry had a problem with cowboys operating out of their mom's basement. The difference here, however, is that such a private venture needs not concern itself with uptime SLAs, multi-tiered bandwidth, power conditioning and backups. Just keep those Alibaba-sourced ASICs running on the smell of an oily rag. UL and FCC approval would not even be in the vocabulary of such miners. VESDA fire suppression? Contract your rigs out to Bangkok.
I prefer the reference client to other implementations. Offline tx would be nice.
Possibly a way to do it with Bitcoin-Qt is to setup a cleanly installed machine/Ubuntu USB flash drive with the full blockchain, take it offline and then copy your encrypted wallet to it. Sign a tx, burn the wallet to CD and copy it to another clean Ubuntu instance. From that second instance you would never sign a tx or message. View only. The decryption key would never be released into memory. Let it download the blockchain. It will broadcast the tx.
Not re-using addresses makes sense, both from a security and potential privacy point of view.
I see #3 on the Bitcoin 400 Rich List has revealed their public key to the world. I take comfort in knowing that this owner would likely become a target first before any of my modest holdings, in the event of an ECDSA crisis. The blockchain could potentially be salvaged under such a scenario, but some coins could be moved without the owner's consent. I understand that not re-using addresses protects coins further by benefiting from the cryptographic hash functions, limiting any potential attacks.
Whilst I don't understand all of the cryptographic axioms and low-level fundamentals of pubic key and hash functions, I do understand their principles and appreciate the mathematics. Mathematics and its proofs are the only thing that my logical brain can completely put its faith and trust in.
However, at times I also have this silly illogical action-outcome monkey brain which tells me I would feel better if I see my keys signing a tx first before I send larger holdings to it. In fact, early on before I understood "change" (and did not consider coin control), I was rather ignorant to the fact that change was being spent to new addresses. Ignorance truly is bliss.
I now like to know the locations of my coins. However, I also don't completely trust myself manipulating the protocol specification (especially not raw txs) and still like to see some burden of proof. I also like using the reference client. I find myself exporting signed txs first before I broadcast, so I know where my change will be spent to!
For these silly paranoid moments, can signing a message and then verifying the message suffice as "proof" that the reference client and network will "accept" future transactions? Whilst I understand the signature functions are practically the same, I am theorising if some unknown bug in the larger majority install base could reject a spend from some weird malformed address. I recall an early version of bitaddress.org had some sort of malformed key issue. Wouldn't want to be in a position where the network would accept a spend to a hashed public key, but prevented its spend.
tldr. Paranoid.
I see #3 on the Bitcoin 400 Rich List has revealed their public key to the world. I take comfort in knowing that this owner would likely become a target first before any of my modest holdings, in the event of an ECDSA crisis. The blockchain could potentially be salvaged under such a scenario, but some coins could be moved without the owner's consent. I understand that not re-using addresses protects coins further by benefiting from the cryptographic hash functions, limiting any potential attacks.
Whilst I don't understand all of the cryptographic axioms and low-level fundamentals of pubic key and hash functions, I do understand their principles and appreciate the mathematics. Mathematics and its proofs are the only thing that my logical brain can completely put its faith and trust in.
However, at times I also have this silly illogical action-outcome monkey brain which tells me I would feel better if I see my keys signing a tx first before I send larger holdings to it. In fact, early on before I understood "change" (and did not consider coin control), I was rather ignorant to the fact that change was being spent to new addresses. Ignorance truly is bliss.
I now like to know the locations of my coins. However, I also don't completely trust myself manipulating the protocol specification (especially not raw txs) and still like to see some burden of proof. I also like using the reference client. I find myself exporting signed txs first before I broadcast, so I know where my change will be spent to!
For these silly paranoid moments, can signing a message and then verifying the message suffice as "proof" that the reference client and network will "accept" future transactions? Whilst I understand the signature functions are practically the same, I am theorising if some unknown bug in the larger majority install base could reject a spend from some weird malformed address. I recall an early version of bitaddress.org had some sort of malformed key issue. Wouldn't want to be in a position where the network would accept a spend to a hashed public key, but prevented its spend.
tldr. Paranoid.
Re: wallet.dat import public key without private key? (view only)
Possibly another option is to have the wallet encrypted with a very strong password, burn the wallet to a CD and then move it to another cleanly installed machine/Ubuntu USB flash drive. From that second machine you would never sign a tx or message. View only. The decryption key would never be released into memory.
I prefer the reference client to other implementations. Offline tx would be nice.
You could spend your coins offline the hard way - disconnect that second instance from the Internet (never to be connected again), sign a tx, burn the wallet to CD and copy it to a third clean instance. Once the third instance has the full blockchain it will broadcast the tx.
I prefer the reference client to other implementations. Offline tx would be nice.
You could spend your coins offline the hard way - disconnect that second instance from the Internet (never to be connected again), sign a tx, burn the wallet to CD and copy it to a third clean instance. Once the third instance has the full blockchain it will broadcast the tx.
Thanks. gcc now at 4.6.3.
However, now receive -
I believe I do have openssl compiled correctly with ECDSA.
Is this worth pursuing?
However, now receive -
Quote
# make
lnk -- parser
.objs/util.o: In function `decompressPublicKey(unsigned char*, unsigned char const*)':
util.cpp:(.text+0x804): undefined reference to `EC_KEY_new_by_curve_name'
util.cpp:(.text+0x820): undefined reference to `o2i_ECPublicKey'
util.cpp:(.text+0x834): undefined reference to `EC_KEY_set_conv_form'
util.cpp:(.text+0x843): undefined reference to `i2o_ECPublicKey'
util.cpp:(.text+0x84f): undefined reference to `EC_KEY_free'
util.cpp:(.text+0x896): undefined reference to `EC_KEY_free'
.objs/util.o: In function `compressPublicKey(unsigned char*, unsigned char const*)':
util.cpp:(.text+0x8b4): undefined reference to `EC_KEY_new_by_curve_name'
util.cpp:(.text+0x8d0): undefined reference to `o2i_ECPublicKey'
util.cpp:(.text+0x8e4): undefined reference to `EC_KEY_set_conv_form'
util.cpp:(.text+0x8f3): undefined reference to `i2o_ECPublicKey'
util.cpp:(.text+0x8ff): undefined reference to `EC_KEY_free'
util.cpp:(.text+0x946): undefined reference to `EC_KEY_free'
collect2: ld returned 1 exit status
make: *** [parser] Error 1
lnk -- parser
.objs/util.o: In function `decompressPublicKey(unsigned char*, unsigned char const*)':
util.cpp:(.text+0x804): undefined reference to `EC_KEY_new_by_curve_name'
util.cpp:(.text+0x820): undefined reference to `o2i_ECPublicKey'
util.cpp:(.text+0x834): undefined reference to `EC_KEY_set_conv_form'
util.cpp:(.text+0x843): undefined reference to `i2o_ECPublicKey'
util.cpp:(.text+0x84f): undefined reference to `EC_KEY_free'
util.cpp:(.text+0x896): undefined reference to `EC_KEY_free'
.objs/util.o: In function `compressPublicKey(unsigned char*, unsigned char const*)':
util.cpp:(.text+0x8b4): undefined reference to `EC_KEY_new_by_curve_name'
util.cpp:(.text+0x8d0): undefined reference to `o2i_ECPublicKey'
util.cpp:(.text+0x8e4): undefined reference to `EC_KEY_set_conv_form'
util.cpp:(.text+0x8f3): undefined reference to `i2o_ECPublicKey'
util.cpp:(.text+0x8ff): undefined reference to `EC_KEY_free'
util.cpp:(.text+0x946): undefined reference to `EC_KEY_free'
collect2: ld returned 1 exit status
make: *** [parser] Error 1
I believe I do have openssl compiled correctly with ECDSA.
Is this worth pursuing?
I know this is developed under Ubuntu, but it would be nice to have working on RH type distros.
I have openssl with ecdsa working, but blockparser won't compile -
Is this something worth pursuing further?
I have openssl with ecdsa working, but blockparser won't compile -
Quote
# make
c++ -- cb/dumpTX.cpp
cb/dumpTX.cpp: In member function 'virtual int DumpTX::init(int, const char**)':
cb/dumpTX.cpp:80: error: expected initializer before ':' token
cb/dumpTX.cpp:84: error: expected primary-expression before 'return'
cb/dumpTX.cpp:84: error: expected ';' before 'return'
cb/dumpTX.cpp:84: error: expected primary-expression before 'return'
cb/dumpTX.cpp:84: error: expected ')' before 'return'
make: *** [.objs/dumpTX.o] Error 1
c++ -- cb/dumpTX.cpp
cb/dumpTX.cpp: In member function 'virtual int DumpTX::init(int, const char**)':
cb/dumpTX.cpp:80: error: expected initializer before ':' token
cb/dumpTX.cpp:84: error: expected primary-expression before 'return'
cb/dumpTX.cpp:84: error: expected ';' before 'return'
cb/dumpTX.cpp:84: error: expected primary-expression before 'return'
cb/dumpTX.cpp:84: error: expected ')' before 'return'
make: *** [.objs/dumpTX.o] Error 1
Is this something worth pursuing further?
Electronic information cannot self-destruct. It can also be easily be duplicated. If the tx has been broadcast with an appropriate fee, and subsequently heard, it is inevitable it will reach the blockchain. The Bitcoin client is quite aggressive at re-broadcasting to other peers. The cat is out of the bag.
If the recipient is well-connected to the network, they might with some degree of confidence accept a 0-confirmed tx if they have heard no double-spends.
If 'thin' clients started to heavily rely a few exit nodes, and peer numbers dwindled, it might be possible to conspire with large pools to somehow repeal a tx before it was broadcast. However, we'd have bigger problems if this were the case.
Irrevocable transactions is alien to to some people. As is the concept of complete and total responsibility for the storage of one's own store of value (wallet). This is probably the price of a distributed crypto-currency. There is no one to point the finger at.
If the recipient is well-connected to the network, they might with some degree of confidence accept a 0-confirmed tx if they have heard no double-spends.
If 'thin' clients started to heavily rely a few exit nodes, and peer numbers dwindled, it might be possible to conspire with large pools to somehow repeal a tx before it was broadcast. However, we'd have bigger problems if this were the case.
Irrevocable transactions is alien to to some people. As is the concept of complete and total responsibility for the storage of one's own store of value (wallet). This is probably the price of a distributed crypto-currency. There is no one to point the finger at.
I thought it notable that a security consultant who works for a bank should choose to mention Bitcoins out of all the usecases for SHA256...
He is taking 15 days to reveal his findings. This is an eternity.
The code has been found to be meticulous. I think we are dealing with some high-level shit here.
Whatever happens with Bitcoin, I look forward to reading about the origin of its development in my life time. It took 30 years for the story of Bletchley Park to be released to the public.
In this era I don't think secrets can be held for that long.
if satoshi is human and humans make mistakes, i think it's possible a large number of his private keys have already been lost permanently.
I've considered that. However, some have speculated quant/s had to be involved. Could this really be the work of one man? Perhaps this group knew exactly what was going to happen. Under such a scenario, such carelessness could not have happened.
The coins have not been spent. They might have a purpose.
Some speculate Satoshi has as many as 1M+ Bitcoins. Could he ever spend them without attracting frenzied tx-attention/investigation or spend them without causing a run on the currency? Could he keep his anonymity?
10 years from now with 18m Bitcoins in existence, Satoshi might have 6% of all Bitcoins. Part of the Bitcoin Oligarchy. However, this is not all bad. Larry Ellison is estimated to be worth $36b and his Randian influence (like it or not) on the world is still limited. If Satoshi was worth $36b in 2022, Bitcoin would have a market capitalisation of $600b. Bitcoin would be causing waves, and each Bitcoin would be valued at $30k each.
Some speculate Satoshi is not an individual, but rather a group. Perhaps this group has good intentions and want to make the world a better place. Curiously, Larry's personal fortune is on par with the endowment of the Bill & Melinda Gates Foundation.
Perhaps "Satoshi" might start offering BTC bounties to make the world a better place. Think X PRIZE? A cure for Malaria?
10 years from now with 18m Bitcoins in existence, Satoshi might have 6% of all Bitcoins. Part of the Bitcoin Oligarchy. However, this is not all bad. Larry Ellison is estimated to be worth $36b and his Randian influence (like it or not) on the world is still limited. If Satoshi was worth $36b in 2022, Bitcoin would have a market capitalisation of $600b. Bitcoin would be causing waves, and each Bitcoin would be valued at $30k each.
Some speculate Satoshi is not an individual, but rather a group. Perhaps this group has good intentions and want to make the world a better place. Curiously, Larry's personal fortune is on par with the endowment of the Bill & Melinda Gates Foundation.
Perhaps "Satoshi" might start offering BTC bounties to make the world a better place. Think X PRIZE? A cure for Malaria?
The "R" in RSA figured a 129-digit number would take 40 quadrillion years to factor, yet it was accomplished in less than 20 years.
Can such predictions really take into account unknown unknowns?
Curious how the US Government completely dropped the case against Phil Zimmermann. Did they realise they were fighting a losing battle against free software? Or could there be something more sinister at play?
Can such predictions really take into account unknown unknowns?
Curious how the US Government completely dropped the case against Phil Zimmermann. Did they realise they were fighting a losing battle against free software? Or could there be something more sinister at play?