Bitcoin Forum
June 29, 2022, 07:05:47 AM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 »
1  Bitcoin / Development & Technical Discussion / Re: Questions about generic signmessage (BIP322) on: December 18, 2020, 03:29:29 PM
I have proposed a rewrite of BIP-322 on the ML:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-December/018313.html

Full text (also included in the ML post, but rendered here)

https://github.com/apoelstra/bips/blob/2020-12--bip322-overhaul/bip-0322.mediawiki
2  Bitcoin / Development & Technical Discussion / Re: Questions about generic signmessage (BIP322) on: November 28, 2020, 09:11:06 PM
tiagocs, pooya87, I think it's important that BIP322 work with arbitrary scripts, for the reasons that gmax has stated. But I also agree that BIP322 is written currently to require very heavy machinery (basically, linking to libbitcoinconsensus to do absolutely anything, and goes out of its way to expose sharp edges of Script. For example, allowing non-low-S signatures and then requiring verifiers to mark this as "inconclusive" appears to serve no purpose.

I wonder if you would support a version of BIP322 which:

1. Required all standardness rules be obeyed (and allowed as an "extension" to validate such signatures, somewhere cordoned off at the end of the BIP where nobody needs to see it)
2. Specified what these standardness rules were/meant
3. Allowed implementations to return "inconclusive" for scripts they did not understand, while still permitting them to implement only templates if they really want.
4. Cleaned up the prose a bunch

The first two rules would let you use off-the-shelf Minscript software (such as this implementation in Python to support all widely used scripts except HTLCs, so even if you did not write a full BIP-322 verifier (which would require libbitcoinconsensus or Core) you would still be able to support a wide array of real-world usecases.
3  Bitcoin / Development & Technical Discussion / Re: Do the “wallet.dat” hashes have salts? on: November 25, 2020, 10:03:06 PM
Unless you have specific information to the contrary, I'd assume the Bitcoin Core repo is more accurate than the wiki, regardless of timestamps.
4  Bitcoin / Development & Technical Discussion / Re: How to build a virtual blockchain on top of a Bitcoin blockchain on: November 22, 2020, 08:58:02 PM
Have you heard of sidechains?
5  Bitcoin / Development & Technical Discussion / Re: How is a public key calculated from a private key using ecc? on: October 02, 2018, 02:03:25 PM
Not to detract from the main point, but if you were implementing this multiplication yourself, using the "powers of two" ladder is a bad idea for security reasons. Specifically, for each 1 bit in your secret key you're adding 2^i*G, while for each 0 bit you're not doing anything. Somebody timing your algorithm could easily determine how many powers of 2 you added, i.e. how many bits in your secret key are 1.

In general, you want to use a multiplication algorithm that never puts secret data into if-conditionals [1] or into array indices [2][3]. It is possible to efficiently do this, which I think is actually even more surprising than the fact that you can do the multiplication in sublinear time.

One such algorithm, though by no means the most efficient one, is as follows (a special case of [4], unless I screwed it up):

1. Compute x' = (x + 2^256 - 1)/2 mod the secp256k1 curve order. The bits of this number have a special property: if you interpret all the 0's as -1's, they also represent the original secret key x. See [5], top of page 9.
2. Compute G, -G, 2G, -2G, 4G, -4G, ..., 2^256G, -2^256G and put them in an array P.
3. Compute the sum of { x_i'*P[2*i + 1] + (1 - x_i')*P[2*i] } over each bit x'_i of x'.

[1] "Don't branch on secret data" is folklore, I don't have a citation for it.
[2] https://cryptojedi.org/peter/data/chesrump-20130822.pdf
[3] http://www.tau.ac.il/~tromer/papers/cache.pdf
[4] https://github.com/bitcoin-core/secp256k1/pull/546
[5] https://eprint.iacr.org/2012/309.pdf
6  Bitcoin / Development & Technical Discussion / Re: Open Timestamps integration in to Bitcoin on: October 01, 2018, 07:24:28 PM
There are OTS libraries for Python, Java, Javascript and Rust. See https://opentimestamps.org/#code-repositories
7  Bitcoin / Development & Technical Discussion / Re: Anonymous Atomic Swaps Using Homomorphic Hashing on: September 02, 2018, 01:39:06 AM

Quote
It is not possible to do a cross-chain atomic swap with only two transactions because you need at least one transaction on each chain, and the first transaction on each chain can be invalidated by publishing a conflicting transaction alongside it.
I doubt it. Using this proposal:

Alice issues tx1 on aliceChain sending m aliceCoins to Bob hash-locked with H(s1) after privately handing Bob (t, H(s1), H(s2))  

Bob does the same by issuing tx2 on bobCahin hash-locked with H(s2), AFTER tx1 is confirmed on aliceChain.

Now Alice should wait for tx2 to get confirmed before spending its outpoint and Bob should wait for Alice spending tx2 (and revealing s2) to be able to calculate s1 = t-s2 and spend tx1's outpoint.

 

I count four transactions in what you described.
8  Bitcoin / Development & Technical Discussion / Re: Anonymous Atomic Swaps Using Homomorphic Hashing on: September 01, 2018, 03:13:52 PM
You can do adaptor-signature based atomic swaps in Bitcoin without Schnorr; see https://eprint.iacr.org/2018/472 which has a full security proof (and security model, which is a nontrivial thing to define for transitive atomic swaps). Adaptor signatures can be used to make arbitrary sets of transactions atomic; and to even add transactions to these sets after the protocol has started. They are definitely not restricted to pairwise exchange, though in practice I expect you'll find it's hard to coordinate much else.

It is not possible to do a cross-chain atomic swap with only two transactions because you need at least one transaction on each chain, and the first transaction on each chain can be invalidated by publishing a conflicting transaction alongside it.
9  Bitcoin / Armory / Re: FRAGMENTED BACKUPS VULNERABILITY!! IF YOU USE THEM, READ THIS!! on: September 25, 2017, 04:53:00 PM
There are two things should be random in SSS.  The coefficients of the polynomial.  And the x-values where the polynomial is evaluated.

This is false. Where did this idea come from?

Quote
Non-random x values is probably relatively benign, since all information about the polynomial is in the f(x) values.  Wikipedia does not even mention that the x values should be random.

What does "probably relatively benign" mean in cryptographic terms?

Quote
Pseudo-random coefficients is certainly a bad idea.

Why is this?
10  Alternate cryptocurrencies / Altcoin Discussion / Re: I have a cryptocurrency idea, where do I get started? on: May 31, 2017, 02:10:37 PM
What is your idea? There is a good chance you can just build it on top of Bitcoin or some other existing project.

Creating an entirely separate currency to implement some technical improvement is a lot of work, entails significant legal risk and moral hazard, and will hamper users' ability to use your system trustlessly.
11  Bitcoin / Development & Technical Discussion / Re: When can Mimblewimble be implemented? on: May 26, 2017, 03:13:24 PM
So....   it looks like finally MimbleWimble will move away from Bitcoin and may launch itself as an independent currency:

http://www.coindesk.com/sorting-hat-time-mimblewimble-weighs-own-blockchain-launch/

MimbleWimble is just a technology; the blockchain which is supporting its own currency is called "grin" (similar to CryptoNote vs Bytecoin except without the scam surrounding it). I really wish these wouldn't be conflated in the public eye, but the reporting seems to do it quite a bit.

Regarding moving away from Bitcoin, I proposed a scheme to the grin developers by which they can softfork in a Bitcoin peg onto their chain (using Confidential Assets it can cheerfully support its own currency alongside pegged bitcoins alongside whatever, they don't affect each others' security but they do share a privacy set) which they seemed quite enthusiastic about.

I'm surprised that there is not a single significant thread discussing mimblewimble in detail, or even a healthy debate going on.

Considering how this feature brings many functionalities that Bitcoin desires for a long time, I was hoping for a wider discussions going on the forum. Instead I just found a few one-page thread and a couple of press releases.

There has been a lot of research and development happening in the Mimblewimble space lately, but it's extremely fast moving and there hasn't been a lot of writing about it. You can follow the mimblewimble-dev mailing list for some of it, but unfortunately the non-boring stuff been largely happening in meatspace. A short list of developments since this thread was started
and I'm sure there's other stuff I'm forgetting.

12  Bitcoin / Development & Technical Discussion / Re: implicit cost of pegged sidechains on: September 26, 2016, 08:09:02 PM
...every coin on Alpha is 100% backed by a locked coin on testnet, and using the peg mechanism you can swap a testnet coin on Alpha for one of its backing coins on testnet.

Could you show the code on how alpha does this? As per my knowledge, since the bitcoin blockchain cannot be monitoring a sidechain, the way to unlock the coins on mainchain is through a  third party federation, the sort of group RSK is building & the technique they plan on using. It would be really useful, thanks.


Alpha is using a third-party federation which processes peg-outs (though the details of this are purely mechanical, it is not too hard to write software that verifies that the federation is doing exactly what it is supposed to and no more). Peg-ins are done by Alpha's consensus code, though I don't know the details of this well enough to point you to the code.
13  Bitcoin / Development & Technical Discussion / Re: implicit cost of pegged sidechains on: September 26, 2016, 04:33:01 PM
When the government of Argentina says they're going to peg the peso to the US dollar that means that if you come and give them a peso they will give you a US dollar in return. That's a 1 way peg.

A 2 way peg would mean you could get a peso for a dollar in the US and you could get a dollar for a peso in Argentina.

With cryptocurrencies a peg can't function this way since there isn't any authority, such as a national government, who can make such a commitment.


So what are we talking about when we say 2 way peg?

We were a bit worried about this point of confusion when we used the word "peg" in the sidechains whitepaper, but it was the cleanest word we could come up with. You're right that in the finance world, a peg between two different assets requires some authority to maintain the peg (and they do so basically by fighting every market movement, at cost to themselves). This is how sidechains work on a technical level, but not on a moral one.

A sidechain peg is not between two separate currencies, like Ethereum and Bitcoin. It is between the same currency on different blockchains. For example, there is a testnet sidechain, Elements Alpha, out there. You can distinguish between "testnet coins on the testnet chain" and "testnet coins on Alpha", and these are technically distinct entities, but every coin on Alpha is 100% backed by a locked coin on testnet, and using the peg mechanism you can swap a testnet coin on Alpha for one of its backing coins on testnet. So there can't be market movements of the coins on one chain relative to the other, except up to time-preference since the peg is slow, otherwise people will arbitrage out any price difference using the peg.


14  Bitcoin / Bitcoin Discussion / Re: Mimblewimble Paper Proposes ‘Near Complete’ Bitcoin Anonymity on: August 21, 2016, 10:05:35 PM
What kind of blockchain analysis could one reasonably expect with this scheme? It seems to make regular blockchain analysis just from looking at the blockchain close to impossible, but what about someone that monitors the network in real time? Couldn't you make the connection between inputs and outputs before they get into a block?

Unfortunately it would probably be reasonable to expect that every unmerged transaction was visible to surveillance companies (although CT does still protect the amounts). Although I'm sure services would pop up that take in transactions, merge them, then publicize them after merging (and it'd be so easy to set up such a service that they wouldn't all be in cahoots or NSA-controlled).
15  Bitcoin / Bitcoin Discussion / Re: Mimblewimble Paper Proposes ‘Near Complete’ Bitcoin Anonymity on: August 07, 2016, 07:25:29 PM
andytoshi,

the "paper" actually says
Quote
Then, to
validate the entire chain, users only need to know when money is entered into
the system (new money in each block as in Bitcoin or Monero or peg-ins for
sidechains [6]) and final unspent outputs, the rest can be removed and forgotten.
which is an act of pruning / removing the history..
so my premiss was that part of the paper was not just about mixing coins, not just about hiding values but also pruning/removing the transaction history.

which. has risks..
Can you describe these risks?

Quote
secondly even if pruning didnt happen, which you suggested the paper never suggests.. my premiss is that you can still analyze the transactions even without knowing the values just by tracking who pays who due to the history remaining.. meaning the only way to be "near complete" anonymity would be to remove the history.

which, has risks..
I did not suggest that "pruning doesn't happen" in the paper. Again, can you describe these risks? What do you mean by "who pays who"? Ignoring the question of associating people to outputs when all outputs are uniformly random curvepoints, how does one even associate the outputs with the inputs?

Quote
no bitcoin code would solve removing links of personal info to a bitcoin address. especially when people publicly hand out personal info freely
EG without any real work, no coercion, no begging or bribing of information, i found this.
1Andrew5Jgks6cziRiqgWShg1nr1igky1r
Andrew Sydney Poelstra
rasied in canada but then went to texas for a bit
That's correct, this is me. But MW does not support using static addresses like this, it is required for people to send me money that I interact with them, and then why would I use the same keys if I have to interact anyway?

Quote
and dont get me started on the concept of relay nodes tweaking the transaction to add in their own address to take a fee.. that in itself can send tx's looping through a collection of nodes owned by one person to add in many addresses to siphon off funds from the transaction itself, or spark a civil war of nodes fighting each other to be the last in line before a mining pool accepts it to ensure other relay nodes dont tweak one address out to replace it with their own..
Why would they loop through themselves? If they want to take all the fee they can do that in one shot. Then good luck for them trying to relay the transaction further with no remaining fee.
16  Bitcoin / Bitcoin Discussion / Re: Mimblewimble Paper Proposes ‘Near Complete’ Bitcoin Anonymity on: August 07, 2016, 04:12:06 PM
I value legit anonymity for many reasons.... but coming on the heels of a major bitcoin heist this seems kinda... ironic/

Bitcoin right now has abysmal privacy properties, and yet even these don't seem have helped in tracking down the executor of the BFX heist. (Perhaps this will change, of course, it is still early days.) It certainly is not going to help getting the money back. In general, people who want to do illegal things are able to be anonymous about it, often taking huge losses in the process -- maybe it costs you 50% to launder money, but if you stole all the money in the first place, this is acceptable. Meanwhile people who are just trying to live their lives cannot afford to be taking huge haircuts all the time, don't get the anonymity that criminals can afford, and wind up being screwed by the poor privacy properties of whatever payment system they're using.

This is definitely something interesting.... however, it is not important at all. Bitcoin doesn't need anonymity. Those who need it have things to hide...

There is an old article by Mike Hearn called merge avoidance which describes many reasons that financial privacy is important for ordinary people. For businesses the consequences are even more severe; you cannot run a business with entirely public accounts.

Add as others have said, "you don't get to choose what things you need to hide".

I think this is the latest innovation of the bitcoin. But I see it is very unfavourable to be realized, because in this way it is able to provide opportunities to those who make transactions that are prohibited and also passed all those who commit corruption. Perhaps this needs to be fixed, so that it can become a good innovation and successful innovation

See my above comment about criminals already being able to hide their activity, since they value this more and have more money to burn.

the link is about removing the transparent ledger(the blockchain(7 years of historic data)).
sorry but removing the blockchain out of bitcoin and instead only handle "unspents" is totally ridiculous.

It is already possible to delete all historic data in Bitcoin and track only the unspent outputs. You will not be able to help others join the network with full security, and you would not've be able to join the network yourself without validating this data. But it hardly seems ridiculous on its face that it could be validated more cheaply than downloading all of it.

Quote
it ruins the "trust" and security that bitcoins cannot be"created" by any other method.
It does not. Can you say more about why you think this? The paper explicitly addresses why inflation remains impossible.

Quote
it ruins the security, simply because each block is created with details of the last block. by removing "blocks" then that removes the security.. thus making it easier to fake new data.
The paper does not talk about removing blocks at all. Did you read it?

Quote
the other point is about hiding values of transactions..
this is also a overall risk because if you cant see the amount someone had. you cant validate what you received is real or not. (bitcoin counterfeiting risk)
Are you familiar with confidential transactions? This is an existing technology that has been in use on the sidechain Elements Alpha for over a year now, and is exactly what the MW paper uses.

Quote
even if they did remove the history of bitcoin data and hide values of transactions publicly so no one can analyze the history. they can still analyze current data and anyone watching a person in particular will still be able to get information about them.
This is largely addressed by the use of OWAS and CT, which again is discussed in the paper itself. (Note that MW's mechanism for doing OWAS is novel and not related to the one in that link.)

Quote
the easier solution is just to move funds to a new address and then anyone watching you doesnt know if its still you or someone else you made a payment to.
Can you paste an address that will allow me to learn the blockchain's chainstate with full security and without complete history, while also hiding its transaction graph even from people who have the full blocks? If not, can you say how somebody would make one?
17  Bitcoin / Development & Technical Discussion / Re: When can Mimblewimble be implemented? on: August 07, 2016, 03:52:39 PM
Because MimbleWimble doesn't support Bitcoin script, it supports far less functionality than Bitcoin and isn't a viable upgrade path for Bitcoin itself.

Having said this, it certainly makes sense that MW should be a sidechain, given that huge amounts of Bitcoin's use is for simple "move money from party X to party Y" transactions, which MW does support. I've been thinking that I might work on this if I can find some spare time. Aside from finding time and people, here is a short list of things I think need to be solved before this could be done:
  • Further review (though I'm increasingly comfortable with the idea). This means somebody needs to do a proper writeup (I might do this in the coming days); I will try to present this at Scaling Bitcoin in Milan to increase its exposure, assuming the real author doesn't appear and that my submission is accepted.
  • Payment channel support. I think I have a way, but it involves unprunable blockchain data whenever a CLTV branch is taken, which is annoying. Should be possible to do better.
  • Figuring out a bunch of fiddly stuff. Like, because input refs can be completely pruned, they should count for more blockspace than outputs, which can only be pruned when spent, which in turn should count for more blockspace than these excess "kG" values, which can never be pruned.
  • Going through the engineering work to spec out the UX for payments; paying requires both sender and receiver to produce data. So should everything happen through a payment protocol? Can we finally get rid of user-visible "addresses"? How should payment channels/Lightning interact with this? Multisig requires interaction among all parties even to receive money, how should this work?
  • I want to spend more time trying to shrink the unprunable data. This can be done interactively, so maybe there is some engineering/UX work that'd make that easy? It can also be done with pairing-based crypto, maybe we should evaluate that option?

This is really exciting stuff, but the paper that was deaddropped by the anonymous author unfortunately leaves a lot of work to get to an actual implementation. Smiley
18  Bitcoin / Development & Technical Discussion / Re: For the super paranoid: How do I get the public key from a private key by hand? on: July 18, 2016, 02:55:04 PM
It's faster in wNAF and using Jacobian coordinates rather than Cartesian. Still nuts though...

Good idea, I might add some tables usable for wNAF.

And you can extend my coordinates to Jacobian by simply adding a third `1` coordinate to everything Smiley.
19  Bitcoin / Development & Technical Discussion / Re: For the super paranoid: How do I get the public key from a private key by hand? on: July 15, 2016, 01:19:43 PM
How much precomputation are you willing to do? Is it OK to use a computer for this? Note that you can verify this multiple ways (by patching some quick-and-dirty code into libsecp, and using sage are my go-tos) and that the precomputation will have nothing to do with your secret key at all, so you can also ask outside parties to verify.

Depending on your answer, this might not be too crazy, and you could do it in less than a day per pubkey. Here's one scheme:

0. As others have mentioned, the public key is derived from the secret key by means of x → x*G, where x, your secret key, is a 256-bit number, G is a standard generator of the secp256k1 elliptic curve, and * means repeated addition of G to itself by the elliptic curve group addition formula.

0a. The formula can be found on Wikipedia and here. I recommend you understand the wikipedia formula algebraically, then go to that link to find more computationally efficient schemes. In particular you'll want to use a coordinate system that lets you avoid doing any modular inversion, because that's a bear to do by hand. (You will eventually need to do this, because the final form needs to be in affine coordinates, but you can put it off to the end instead of doing it at every step.)

0b. The formulae that libsecp256k1 uses are in this Sage script, which if you run, will also check that they are actually algebraically equivalent to the cleaner formula found on wiki and elsewhere. libsecp's computational goals (avoid inversions, strongly prefer addition to multiplication) are similar enough to a human's goals that it's probably faster to just use these than to go researching better ones.

0c. The formulae for doubling and adding distinct points are different. You'll need to double to do the precomputation, but never afterward. So that will simplify your life a bit.

Ok, the actual scheme:

1. Take your secp256k1 generator G, and compute G, 2G, 3G, ..., 15G. Then compute each of these times 16, times 16^2, times ..., times 16^63. (This isn't as bad as it looks since each generation can be gotten from the last by multiplying by 16 again.) To multiply by 16, double 4 times. This is a total of 15×64 = 960 points you need to precompute. Now, I'm not in your head, but I really think your ghosts will allow you to do this using computers, since it's independent of your secret and you can do it multiple ways.

1a. I think it would be funny for the libsecp project to sell books with these precomputed tables, like the books of logarithms that sailors used to use. It's a quick job in sage and LaTeX, if I still think it's funny by the end of this post I'll make a PDF.

2. Now, take your secret key in hex-encoding. This is a base 16 encoding, something like x = a + b*16 + c*16^2 + ... and so on, where all of a, b, c, are between 0 and 15 inclusive. There will be 64 digits, some of which (four of them, on average) are zero. So you can write x*G = (a + b*16 + c*16^2 + ...)*G = a*G + b*16*G + c*16^2*G.

2a. Here's the cool part: the 0*G's you can ignore. Everything else that's multiplied by G in the above formula is in your precomputed table. So you'll have (at most) 64 points that you simply look up, and you have to add them together. 63 additions. To do this in 24 hours, you'd have to do each one in a bit under 23 minutes. This is plausible, but I couldn't do it.


By increasing the size of your precomputed table you can reduce the work from 64 points, but the table gets much bigger. (To halve your work, you roughly have to square the size of the table.) To add 32 points, you'd need 8160 precomputed points; for 16 points you'd need a bit over a million; for 8 it's 35 billion ... for 1 you'd need to write out literally every single point.)


Edit: Here, I have done the precomputation for you. You want page 38, base 16 digits. https://download.wpsoftware.net/bitcoin/todl.pdf



20  Bitcoin / Development & Technical Discussion / Re: Smart contracts in bitcoin on: July 14, 2016, 03:38:14 PM
To answer the OP's question, s/he could use something like a assurance contract, which do a payout after some threshold has been met.

The scheme described there is not really usable because at any point the recipient of the funds can pledge the remainder of the balance, push the transaction through, and immediately get her pledge back. But as best as I can read OP's request, this is the desired behaviour.
Pages: [1] 2 3 4 5 6 7 8 9 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!