Search content
Sort by

Showing 20 of 26 results by kn_b_y
Post
Topic
Board Development & Technical Discussion
Re: Mining At Bitcoin Limit
by
kn_b_y
on 01/10/2016, 00:00:35 UTC
I think the block reward is going to become an irrelevance well before 2140.

The miners are currently collecting fees of 0.3-0.4 coins per block, and it's rising over time. And this amount is what the block reward will be in about twenty years time. So the cross-over point (when fees outstrip block rewards) is probably going to come sooner than then - and most of us will still be alive.

It might happen that 2nd layer stuff (payment channel networks such as lightning) and block size increases (which few will be able to argue against as network rates and storage capacity get higher) will exert a downward pressure on fees. But despite this, as demand increases I'm sure the fees will increase well beyond the current value if bitcoin manages to remain the most strongly backed crypto-currency.
Post
Topic
Board Bitcoin Technical Support
Re: Private Key lost one character
by
kn_b_y
on 29/09/2016, 22:37:10 UTC
I missed the recent activity in this thread.

Here's another script that substitutes replacements from the base58 character set for each character in the bad wif, and then inserts all base58 chars at each position in the string.

So it should deal with all private keys that have one missing character plus one mistranscribed character.

It takes about 15 minutes to run on my old, slow laptop, but I've included progress output so that you can tell something is at least happening.

Code:
import bitcoin.base58
from bitcoin.core import b2x, x
from bitcoin.core import Hash
import sys

def replace_char(string, char, i):
    return string[:i]+char+string[i+1:]

def insert_char(string, char, i):
    return string[:i+1]+char+string[i+1:]

def verify_wif_checksum(wif):
    byte_string = b2x(bitcoin.base58.decode(wif))
    private = byte_string[:-8]
    checksum = byte_string[-8:]
    return checksum == b2x(Hash(x(private)))[:8]

def candidate_wifs(corrupted_wif):
    candidates = set()
    for i in range(len(corrupted_wif)):
        #print("%i of %i" % (i, len(corrupted_wif)),)
        sys.stdout.write("%3i of %3i : " % (i, len(corrupted_wif)))
        for char in bitcoin.base58.B58_DIGITS:
            sys.stdout.write(char)
            candidate_wif = replace_char(corrupted_wif, char, i)
            for c in insertion_candidates(candidate_wif):
                candidates.add(c)
        print()
    return candidates

def insertion_candidates(corrupted_wif):
    candidates = []
    for i in range(len(corrupted_wif)):
        for char in bitcoin.base58.B58_DIGITS:
            candidate_wif = insert_char(corrupted_wif, char, i)
            if verify_wif_checksum(candidate_wif):
                print("\nFound: %s" % candidate_wif)
                candidates.append(candidate_wif)
    return candidates

# Provide a WIF private key with a single missing character.
# Wrong Char              v
corrupted_wif = '5HueCGU8rkjxEXxiPuD5BDku4kFqeZyd4dZ1jvhTVqvbTLvyTJ'
#  Should be:   '5HueCGU8rMjxEXxiPuD5BDku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ'
#  Missing Char                           ^
for candidate_wif in candidate_wifs(corrupted_wif):
    print(candidate_wif)
Post
Topic
Board Development & Technical Discussion
Re: Question about Lightning Network
by
kn_b_y
on 16/07/2016, 01:18:23 UTC
I'm not sure if I'm understanding you correctly but you seem to ask, 'What happens if 3 (the second, the thirth and the fourth) of them work together?'
 - Suggesting that 'person one' is the victim.

But then, 'All of that only works under the assumption that three of them work together to cheat the fourth person.'
 - Here 'person four' is the victim.

You're talking about this film, I assume: https://www.youtube.com/watch?v=8zVzw912wPo

At about the 25 minute mark?

If so, your question would be clearer to me if you rephrased it using the names Alice, Bob, Carol and Dave.

Post
Topic
Board Development & Technical Discussion
Re: simple python bitcoin public key to address
by
kn_b_y
on 08/06/2016, 22:23:38 UTC
I think this code should work. You'll need python-bitcoinlib - https://github.com/petertodd/python-bitcoinlib

Code:
from bitcoin.wallet import CBitcoinSecret, P2PKHBitcoinAddress
from bitcoin.core import x
privkey = '0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'
secret = CBitcoinSecret.from_secret_bytes(x(privkey))
address = P2PKHBitcoinAddress.from_pubkey(secret.pub)
a = str(address)

-- edit --

Apologies, I just read the title of the thread properly. The above code is for private key to address.

Public keys might be trickier to deal with, depending on whether they are compressed or not.
Post
Topic
Board Development & Technical Discussion
Re: How does bitcoin work? (mathematical prespective)
by
kn_b_y
on 18/05/2016, 14:46:27 UTC
I would add - familiarise yourself with Adam Back's proof of work scheme, hashcash.

I still find it incredible that someone can produce a small block of data and a number and then by using that information alone they can prove to you that they had access to a year's supply of supercomputing resources.
Post
Topic
Board Development & Technical Discussion
Re: Private keys, Public Keys and Bitcoin Addresses
by
kn_b_y
on 18/05/2016, 14:18:21 UTC
Any public key that hashes to that Bitcoin address can spend the money.

But this is wrong. The public key is provided in the scriptSig, and that's what signatures are checked against. It's also how the hash is checked in the first place.

You can find a public key that collides with the hash, and pass the first part of a p2pkh script. If the hash passes, all that's left is OP_CHECKSIG, which still wouldn't pass with the dodgy key.

deepceleron is correct.

The public key is indeed provided in the scriptSig, but this is not what signatures are checked against.

The scriptSig (containing the signature and the public key in P2PKH) is provided by the spender. It is the scriptPubKey in the output of the transaction that is being spent from that does the checking.

In the case of P2PKH, the scriptPubKey makes no mention of the public key - just the address.
Post
Topic
Board Bitcoin Discussion
Re: Craig Wright relents aka Satoshi (air quotes) in Public Apology!
by
kn_b_y
on 05/05/2016, 21:44:39 UTC
apparently the email conversations Craig had with them were extremely convincing. That is something that is extremely difficult to fake - coming off as being the exact same person as they talked to 5 years ago, just as a general feeling.
I don't understand that part. The Satoshi era is before my time, but I have gone back and read some of his old posts here, and he came across to me as someone with a good command of the English language. Where-as Wright comes across as not very articulate in his blog. Does anyone else feel the same way?

I agree.

Satoshi's posts seem open and read clearly.
https://bitcointalk.org/index.php?action=profile;u=3;sa=showPosts

Craig Wright's site (https://web.archive.org/web/20160502203753/http://www.drcraigwright.net/posts/) didn't.

  • Try getting a contextual menu, and you see a dialogue box with terse message reporting, 'Sorry, not sharing images!'
  • All code snippets are published as images. Perhaps he doesn't like sharing his code easily either - or is he afraid of web-crawlers?
  • Littered with tacky brochurish images of the man - betraying a narcissistic streak, perhaps.

I suppose these are all matters of taste. And will be excusable to some people.

What is not excusable is his plagiarism mentioned this week on this forum (https://bitcointalk.org/index.php?topic=1457039.msg14734784#msg14734784).

See here:
https://medium.com/@jprichardson/did-satoshi-steal-my-blog-post-76a68cdda4f3#.t4h9a0m94

And compare:
https://web.archive.org/web/20160502203810/http://www.drcraigwright.net/generating-bitcoin-address/
(from CW's blog published a week or so ago)
and
http://procbits.com/2013/08/27/generating-a-bitcoin-address-with-javascript
(posted by developer JP Richardson nearly three years ago)

Some still say he's Satoshi. They also need to admit that the man is a rogue too.

Post
Topic
Board Bitcoin Discussion
Re: Craig Wright relents aka Satoshi (air quotes) in Public Apology!
by
kn_b_y
on 05/05/2016, 20:53:51 UTC
I guess I have a few theories on that, if he actually did have personal knowledge, but nobody here seems to believe anything I say so I'm not going to waste my time saying them  Lips sealed  

Don't be so hard on yourself. I find your opinions much more stimulating than chopstick's.

I find it interesting that chopstick back-pedals from:


Am I completely off base here??


Yes, your whole post is delusionary speculative nonsense.


to:


Am I completely off base here??


You might be right about some things, but wrong about others.


Who knows, in the future he/she might even change it to:


Am I completely off base here??


I'm sorry. And goodbye.

Post
Topic
Board Bitcoin Discussion
Re: BREAKING NEWS: EXTRAORDINARY CLAIMS REQUIRE EXTRAORDINARY PROOF
by
kn_b_y
on 03/05/2016, 22:32:15 UTC
Any link to this video? I checked since last night but did not see any available.
I want to pick to pieces his facial expressions and body language to get a read on this guy.

visit youtube and search on 'satoshi'. it's there.
Post
Topic
Board Bitcoin Technical Support
Re: Private Key lost one character
by
kn_b_y
on 28/04/2016, 11:51:07 UTC
Seems like kn_b_y solved your problem  Grin
@kn_b_y: nice work man, just a little tip: try to avoid posting real private keys... The address you generated was empty (luckily), but still used, so if it's part of a wallet of yours, it might be a good idear to "freeze" it, so you don't accidently receive any coins in it...

Though I noticed the generated address was incorrect - a potential hazzard!

So I've edited the post.
Post
Topic
Board Bitcoin Technical Support
Re: Private Key lost one character
by
kn_b_y
on 28/04/2016, 10:02:13 UTC
Seems like kn_b_y solved your problem  Grin
@kn_b_y: nice work man, just a little tip: try to avoid posting real private keys... The address you generated was empty (luckily), but still used, so if it's part of a wallet of yours, it might be a good idear to "freeze" it, so you don't accidently receive any coins in it...

Thanks. I'm available for work.  Wink Anybody??

Yeah, I too was curious to see if the address had been used before and noticed some activity.

It's not a key I generated. It's the one from deepceleron's post which is also used in the WIF docs at:
https://en.bitcoin.it/wiki/Wallet_import_format
Post
Topic
Board Bitcoin Technical Support
Merits 3 from 1 user
Re: Private Key lost one character
by
kn_b_y
on 28/04/2016, 01:09:54 UTC
⭐ Merited by ETFbitcoin (3)
Here's a script in python which uses deepceleron's idea of using the checksum to filter out bad candidates.

It does depend on python-bitcoinlib.
https://github.com/petertodd/python-bitcoinlib

Code:
import bitcoin.base58
from bitcoin.core import b2x, x
from bitcoin.wallet import CBitcoinSecret, P2PKHBitcoinAddress
from bitcoin.core import Hash

def insert_char(string, char, i):
    return string[:i+1]+char+string[i+1:]

def verify_wif_checksum(wif):
    byte_string = b2x(bitcoin.base58.decode(wif))
    private = byte_string[:-8]
    checksum = byte_string[-8:]
    return checksum == b2x(Hash(x(private)))[:8]

def candidate_wifs(corrupted_wif):
    candidates = []
    for i in range(len(corrupted_wif)):
        for char in bitcoin.base58.B58_DIGITS:
            candidate_wif = insert_char(corrupted_wif, char, i)
            if verify_wif_checksum(candidate_wif):   
                candidates.append(candidate_wif)
    return candidates


# Provide a WIF private key with a single missing character.
corrupted_wif = '5HueCGU8rMjxEXxiPuD5BDku4kFqeZyd4dZ1jvhTVqvbTLvyTJ'
#   Should be:  '5HueCGU8rMjxEXxiPuD5BDku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ'

for candidate_wif in candidate_wifs(corrupted_wif):
    print(candidate_wif)

It should hopefully output any candidate private keys.

For example:
5HueCGU8rMjxEXxiPuD5BDku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ
Post
Topic
Board Development & Technical Discussion
Re: Doubling or half ot the private key range
by
kn_b_y
on 24/04/2016, 11:21:48 UTC
bitcoin private key range

n = 1 to FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140

and

p = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F

bitcoin public key

x =  592152c398d6c719636a03a6dad64246a5a6814aa62c156b0ce5332f6759b031
y =  72dd2e1d26c233337760c49122a1df67d0aa792b453f97bd29765c83b47ba01d

x = 79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798
y = 483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8

x= c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5
y= 1ae168fea63dc339a3c58419466ceaeef7f632653266d0e1236431a950cfe52a

x = e493dbf1c10d80f3581e4904930b1404cc6c13900ee0758474fa94abe8c4cd13
y = 51ed993ea0d455b75642e2098ea51448d967ae33bfbdfe40cfe97bdc47739922


Need to double (or) half the range of private key , so how to convert the bitcoin public key into doubled (or) half private key range

 
n = 1 to ( FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140 * 2 ) OR

n = 1 to ( FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140 / 2 )

Thank all

Seems to me you could halve the range by performing the bitwise OR operation on your private key, forcing it to be an odd number.

But you can't use Secp256k1 and double the range becuase for any value above FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140 you'd be cycling over the same public keys.
Post
Topic
Board Development & Technical Discussion
Re: How to calculate public key manually?
by
kn_b_y
on 19/04/2016, 23:10:28 UTC
Here's some working python code that generates the point of the public key for private key = 2
Code:
# Inversion using Extended Euclidean algorithm.
def EEA_invert(a, b):
    r = {}; s = {}; r[0] = a; r[1] = b; s[0] = 1; s[1] = 0
    i = 1;
    while True:
        if r[i]==0: break
        q = r[i-1]//r[i]; r[i+1] = r[i-1] - q*r[i]; s[i+1] = s[i-1] - q*s[i]
        i += 1
    return s[i-1] % b

# Bitcoin's EC parameters: see https://en.bitcoin.it/wiki/Secp256k1
G = '79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8'.replace(' ', '')
gx, gy = int(G[:64], 16), int(G[64:], 16)
p = 2**256 - 2**32 - 2**9 - 2**8 - 2**7 - 2**6 - 2**4 - 1

# Calculate differential at the generator point.      
slope = (3*gx**2)*EEA_invert(2*gy, p) % p

# Calculate x, y.
x = (slope**2 - 2*gx) % p
y = (slope*(gx - x) - gy) % p

print(hex(x), hex(y))
which yields:

Code:
('0xc6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5',
 '0x1ae168fea63dc339a3c58419466ceaeef7f632653266d0e1236431a950cfe52a')
Post
Topic
Board Development & Technical Discussion
Re: Insert Text inside transaciont
by
kn_b_y
on 07/04/2016, 12:42:39 UTC
A cheaper way however would be to only embed a hash of your message into the blockchain, while the message itself would be broadcast via some other channel.


And this method would, of course, have the added feature of privacy - if it was required.
Post
Topic
Board Development & Technical Discussion
Re: Why does the Bitcoin protocol send transactions twice?
by
kn_b_y
on 07/04/2016, 12:14:03 UTC

The main reason why this isn't very feasable at the moment is due to tx id malleability (as the ECDSA signature is included in the tx id and the same tx can be signed with a different valid signature because ECDSA approach used by pretty much all Bitcoin wallets includes a "random" number).

I see. So if I get it right, this could lead to a double spend, by creating two similar (inputs, outputs # of coins) transactions with separate txids?



No. That can't happen. Only one of the transactions can be added to the blockchain.

The danger is that a maliciously malleated transaction (and not the one you created) will be confirmed, meaning that the txid won't be as you expected.

In more esoteric uses of bitcoin it is sometimes necessary to create and presign transactions which spend from transactions that have not yet been broadcast. This is known as chaining.

In such cases the txid of transactions appearing earlier in the chain must be guaranteed (ie unalterable). If a txid is altered all successive transactions in the chain will fail (because they will refer to outputs from transactions with txids that do not exist).
Post
Topic
Board Development & Technical Discussion
Re: op_codes usability in payment channels?
by
kn_b_y
on 31/03/2016, 23:02:14 UTC
I assumed that funding a channel via op_cltv and op_csv were required only to setup the channel

I have experimented with implementing payment channels using python-bitcoinlib and unless I'm mistaken timelocked transactions are not used during channel setup. The setup is just a regular payment to a multisig address. However, a timelocked refund (which is not broadcast if the payment channel is otherwise closed) is used to prevent funds from being taken hostage.

Watch the lightning guys explain it (skip to six minutes for payment channel stuff):
https://www.youtube.com/watch?v=8zVzw912wPo
Post
Topic
Board Development & Technical Discussion
Re: Segwit details? SEGWIT WASTES PRECIOUS BLOCKCHAIN SPACE PERMANENTLY
by
kn_b_y
on 18/03/2016, 12:28:11 UTC
Are you suggesting fixing malleability by storing transactions as they are now and omitting signatures from the txid calculation? In effect, a hard fork.

Yes.  That fix should be done by a hard fork: because the code will be much cleaner, and because hard forks are safer than soft forks. (More precisely: ensuring that old versions are inoperable after 3-4 releases is safer than deploying changes to the protcol without alerting users, and letting them discover later that they must upgrade to understand why their transactions are not confirming anymore.)

I've seen enough in this thread to convince me that that approach would make deployment a disaster for bitcoin. People would lose funds.

One example gmaxwell gives: all presigned nlocktime transactions would be broken. For users keeping these in storage they may well represent a lot of security. Gone... the moment a new version of the software no longer sees the transaction as being valid.

As far as I see it, if malleability can be fixed in such a way that older versions of the software still see immalleable transactions as valid transactions then, well…  do it.
Post
Topic
Board Development & Technical Discussion
Re: Segwit details? SEGWIT WASTES PRECIOUS BLOCKCHAIN SPACE PERMANENTLY
by
kn_b_y
on 18/03/2016, 11:24:56 UTC
* Malleability could be fixed by just skipping the signatures (the same data that SegWit would segregate) when computing the txid.  
That _is_ segregation of the signatures up to completely non-normative ordering of data transferred. Segwit could just as well order the data into the same place in the serialized transactions when sending them, but its cleaner to not do so.

On the contrary, rearranging the data in transactions and blocks is an unnecessary and ugly hack to get that effect.  It means hundreds of lines of new code scattered all over the place, in the Core source and wallets, rather than a few lines in one library routine that everybody else can copy.


I think I can see what you are arguing against, but not what for.

Are you suggesting fixing malleability by storing transactions as they are now and omitting signatures from the txid calculation? In effect, a hard fork.
Post
Topic
Board Development & Technical Discussion
Re: Segwit details? SEGWIT WASTES PRECIOUS BLOCKCHAIN SPACE PERMANENTLY
by
kn_b_y
on 17/03/2016, 21:13:29 UTC
A strong malleability fix _requires_ segregation of signatures.

No, none of the alleged benefits of SegWit requires segregation of signatures:

* Malleability could be fixed by just skipping the signatures (the same data that SegWit would segregate) when computing the txid.  

* GREATER bandwidth savings could be obtained by providing API/RPC calls that simple clients can use to fetch the data that they need from full nodes, sans the signatures etc.  This enhancement would not even be a soft fork, and would let simple clients save bandwidth even when fetching legacy (non-SegWit) blocks and transactions.  

* Pruning signature data from old transactions can be done the same way.

* Increasing the network capacity can be achieved by increasing the block size limit, of course.

(Thanks for answering this one question about malleability fix I had. So it can simply be done by omitting sigs from the txid hash input, cool. If not, please let me know)

It seems to me many people have a problem with segwit because of the "hackish" softfork and/or because of the change of the economic model (2 classes of blockspace).

If we did the points listed by JorgeStolfi above as a hardfork, would that be an option for the proponents of segwit? Seems to me such a hardfork could gain wide consensus, maybe wide enough to be considered safe by everyone? It would certainly appeal to the people who just want a simple blocksize increase and it should (I don't know, though) also satisfy the people who want segwit now.

What would be missing compared to segwit? fraud proofs? change of economic model?


Maybe you should read gmaxwell's posts about doing a hard fork to change that calculation. They are a few posts above this in this thread.
Yes. Well said.

It's unsettling how often information that has already been provided is left ignored or unreferenced.

More excusable for the one-off contributors, I realise, but not for those whose apparent strong interest in the issues lead them to post again and again.

Sometimes it's been like wading through treacle, but I'm glad Gregory Maxwell contributed (don't know anything about bitcoin developers, and had never heard of him until today) and what he wrote about the different methods of fixing transaction malleabilty, and their implications, particularly made an impression.

I'd recommend reading his posts in full. Advisory notice - he does lose his patiance occassionally! And for balance, read those he references and those who reference him. And if that prevents just one unecessary post, I'll have done my