Bitcoin Forum
January 31, 2023, 12:35:11 AM *
News: Latest Bitcoin Core release: 24.0.1 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 »
1  Alternate cryptocurrencies / Altcoin Discussion / Re: Recipe for Simple Money on: December 18, 2022, 09:46:33 AM
If everything is that easy, no one will have a problem. That's not how it works.

Even with how effective those "recipes" is, we can't hide the fact that in the process, there will always be a problem.

Everything was that easy - this recipe has been executed.
2  Bitcoin / Development & Technical Discussion / Re: A useful PoW without replacing Nakamoto Consensus on: December 05, 2022, 06:15:24 PM
Sorry but you've still got this all wrong. Again, number of transactions has no relation to the amount of energy used for mining. There is zero relationship there.

Let's say a block can accept exactly 1000 transactions. Imagine we have two forks Bitcoin1 and Bitcoin2 both of which are valued at $10 per coin and have the same supply.

Bitcoin1 has blocks with a single transaction along with a coinbase output.
Bitcoin2 has blocks with 1000 transactions all paying the minimum fee to cover their transaction size.

Which one do you think secures more energy per block?
3  Bitcoin / Bitcoin Discussion / Re: Who has/had the oldest mined Bitcoin? on: December 05, 2022, 02:40:19 AM


Rather than signing dates, they should sign a hash of the block header that was mined 10 minutes ago. This proves it was impossible for a message to be signed by creating plenty of msgs or whatever. It's exciting seeing an early Bitcoin signature, thanks for the entertainment OneSignature.

this can be "fooled" too


My comment was referring to a single singature, not a chain of signatures. I'll comment a bit on the chain of signatures though. You can always encode a new transfer sequence as a linear chain of onchain outputs i.e. a sequence of single input, single output transactions is the simplest form. People could "define" (I put it in quotes because it's a social construct) the coinbase address to own the block PoW.
This PoW could in theory be agreed on to be transfered with a chain of signatures defines as a chain of outputs. This should work as a concept. The PoW obviously isn't in the address at the head of the chain, but it was never in any of the historical addresses. It's there because of our agreement and the fact that nobody could've tampered with the transfers.
4  Bitcoin / Bitcoin Discussion / Re: Who has/had the oldest mined Bitcoin? on: December 04, 2022, 03:38:19 PM
This is the oldest signature  Smiley  (please post if you have a signature with an older address)

Quote
-----BEGIN BITCOIN SIGNED MESSAGE-----
1E9YwDtYf9R29ekNAfbV7MvB4LNv7v3fGa
-----BEGIN SIGNATURE-----
1NChfewU45oy7Dgn51HwkBFSixaTnyakfj
HCsBcgB+Wcm8kOGMH8IpNeg0H4gjCrlqwDf/GlSXphZGBYxm0QkKEPhh9DTJRp2IDNUhVr0FhP9qCqo2W0recNM=
-----END BITCOIN SIGNED MESSAGE-----
What's the meaning of the message? "1E9YwDtYf9R29ekNAfbV7MvB4LNv7v3fGa" is just an address with ~2mBTC. Could you sign another message? Preferably this one: "Today is December 4th, 2022, and I sign for topic #5421158". Also, money sent to "1NChfewU45oy7Dgn51HwkBFSixaTnyakfj" were paid in public key (block 1,018), so I'd expect a public key instead of an address. How did you end up with the address anyway (I've checked blockchair, and you're right; I just don't understand the point of this conversion).

Rather than signing dates, they should sign a hash of the block header that was mined 10 minutes ago. This proves it was impossible for a message to be signed by creating plenty of msgs or whatever. It's exciting seeing an early Bitcoin signature, thanks for the entertainment OneSignature.
5  Bitcoin / Development & Technical Discussion / Re: A useful PoW without replacing Nakamoto Consensus on: November 24, 2022, 04:35:39 PM
Nobody is going to mine at a loss
You don't know where the price goes. You might have purchased an ASIC, done the logistics, but there's definitely one variable you can't be sure of.

I agree, hence why I added the "(unless they expect greater returns in some reasonable amount of time)" which you left out of the quote.
6  Bitcoin / Development & Technical Discussion / Re: A useful PoW without replacing Nakamoto Consensus on: November 24, 2022, 03:02:49 PM
That's just simply not true.

It is true. Think of it this way. The network asks humans to provide security to the network in terms of energy in each step. Since the amount of energy is nontrivial (the whole basis of Nakamoto security), the network promises some compensation to those that protect the network. Nobody is going to mine at a loss (unless they expect greater returns in some reasonable amount of time) so the network security will be roughly the same as the compensation amount because of the incentives/game theory. At the moment, the compensation is a sum of two variables:
1. subsidy - a fixed reward that mints new coins. This variable is design such that it phases out over time
2. fees - a "tax" to incentivize your transaction to take the space on the chain

With time, the subsidy variable disappears into "basically nothing" value and you're only left with the fees. This directly corresponds to the number of transactions as a lower boundary. The network security will be based on it's usage which means on the number of onchain transactions and the competition to capture the block space (bumping the fees as a bribe mechanism).
7  Bitcoin / Development & Technical Discussion / Re: [Megathread] The long-known PoW vs. PoS debate on: October 03, 2022, 11:12:25 AM
I tried to explain some of the differences in PoW/PoS here https://phyro.github.io/nakamoto/. It doesn't go into theory or touches subjects like coin distribution. It focuses more on the difference in how a new block is added. Let me know if I got some things wrong.
8  Bitcoin / Development & Technical Discussion / Re: [Megathread] Bitcoin Layer 1 Privacy - concepts, ideas, research, discussion on: September 01, 2022, 08:15:09 AM
Thanks for your insights! Regarding this point, honestly no matter how much I love Lightning, it's one of my biggest issues with it.
I've been looking for solutions (like BOLT12: https://bitcointalk.org/index.php?topic=5383567.0) for a while now. The interactive element is eliminated (automated) once you run your own full node, but that is really a non-insignificant hurdle, especially for new users.
It's definitely easier setting a friend of family member up with a pure on-chain wallet, pointed to my private Electrum server instance, at least for the start.

But I've yet to fully look through the solutions Grin, Litecoin and others came up with and judge what looks acceptable and what doesn't.

I can answer about Grin. Please correct me if I'm wrong about BOLT12 as I've only skimmed over it. The main concept of BOLT12 seems to be to share information from A to B directly through some hops, in this case by routing over the lightning network.
The first thing to note in a lightning environment is that you must have something online to sign the transfer which I guess in this case is the lightning node. In Grin, we have a Slatepack standard (https://docs.grin.mw/grin-rfcs/text/0015-slatepack/) which does something similar.
When someone wants to send some coins from address A to B (address is an offchain information) it derives an onion service address from the address and attempts to share the information by trying to communicate with the onion url.
The other party needs to run the listener on the other end by running that onion service so it has a similar online requirement to the lightning network and it hops over Tor rather than the lightning network. This functionality is supported by the wallet.
If it succeeds in finding the service, the two parties exchange the messages over this communication channel, otherwise you receive an encrypted message for that recipient address to copy/paste to them on whatever communication channel you want (yes, manually copy pasting).

I think both LN and Grin are in the process of figuring out which transport methods work best and iterating on these. There will be something better than BOLT12 and there will be something better than Slatepacks, but both are a great start in the right direction.
9  Bitcoin / Development & Technical Discussion / Re: [Megathread] Bitcoin Layer 1 Privacy - concepts, ideas, research, discussion on: August 31, 2022, 06:19:36 AM
I'm not interested in any of these coins to be fully honest; I just want to see which privacy concepts exist, what are the upsides / downsides, and which are best suited for Bitcoin.

The most inline with Bitcoin design would be the Mimblewimble chain format because, unlike other designs discussed in this thread, it achieves better privacy by making the protocol simpler. It also comes with the simplest mixer which, as far as I know, is much more efficient than any mixer on Bitcoin.
I don't think Monero's ring sigs are worth considering at this point. The idea was very interesting years ago, but at least to me, it seems like a relatively bad tradeoff to make today. You're much better off adopting ZCash's newest z2z variant or something like a variant of Lelantus.

Btw, regarding drawbacks listed in Grin. Interactivity is a tradeoff rather than a drawback. Let me list some benefits of interactivity that are overlooked:

1. It allows one transaction flow to create all possible transactions (you can't build a payjoin or other multiparty tx with a noninteractive transaction)
2. Payjoins could in theory become the default behaviour (read more about payjoins here https://en.bitcoin.it/wiki/PayJoin)
3. Any transaction party can decide to bump fees if they want to speed up transaction inclusion in a block
4. Any transaction can provably commit to a document (with a multisig)
5. No more need for a test transaction before sending the money
6. In MW, the receiver proves the ability to spend the output when they receive it. It becomes impossible to send to an address whose private key was lost
7. Parties can pay for their own onchain objects e.g. if the receiver wants to create 7 outputs, they can do so, but they pay 7*output_fee + 1/num_participants*sig_fee

Benefits of interactive-only transactions (Mimblewimble design):

1. Every transaction comes with a cross-input-output-signature-aggregation
2. You get full wallet control - unlike in Bitcoin and other cryptocurrencies where you control only what you spend, you can actually control what you receive
3. No more taint/dust/ads output injection attacks
4. Potential for the unification of onchain and lightning transaction flows (or at least making these very similar)
5. You know which outputs you own can exist since you've created them. This means there's no need to scan the blocks for your outputs if you don't reuse the seed on multiple wallets e.g. a hot wallet on the mobile phone.
6. Since you create the outputs, it becomes possible to label the outputs at creation. Whether that's some kind of graph coloring, note keeping or something else

Drawbacks:

1. Cold storage becomes tedious
2. Exchange integration becomes more painful
3. Interactive experience (not necessary to be online at the same time)

Note that if drawback 3. is so bad that it can't be widely adopted, this means that neither can the lightning network because it also requires interactivity.
Point 1. and 2. are of such nature that a solution needs to be built once so it's really a O(1) cost and after this, you're good to go.
10  Bitcoin / Development & Technical Discussion / Re: [Megathread] Bitcoin Layer 1 Privacy - concepts, ideas, research, discussion on: August 20, 2022, 01:50:54 PM
For true privacy you need to be sure it can only be released when BOTH people agree to release it.

Requirement that both agree to release it is what enables fraud. If I pay you X in exchange for some good Y and you refuse to give me Y after you were paid X, then I should be able to prove (regardless of how you feel about it) that I paid X to get Y. Otherwise you can only ever transact with the people you trust which makes it unusable as a payment system. You have to protect the payer from a fraudulent payee.
11  Other / Archival / Re: Fundamental of Blockchain on: July 28, 2022, 10:29:05 AM
Perhaps most people don't care, but it was the first thing I noticed. There are mistakes on the first slide in the first sentence:
1. there's no space after comma
2. there's a double-space between "in block"
3. there's a space before period
12  Economy / Economics / Re: "Surprisingly, Tail Emission Is Not Inflationary" -- A post by Peter Todd on: July 10, 2022, 10:17:42 PM
But that doesn't hold true in the presence of tail subsidy:  Tail subsidy will always continue to enrich the mining industry (and those close to it in the economy) at the expense of everyone else, creating a "winner" that can't be displaced by diffusion.

I don't see how this isn't true for Bitcoin's model as well. This miner "enrichment" seems to be a function of security in $ value.
It doesn't matter whether the miners get their reward from the block subsidy, transaction fees or a combination of both. If you end up with a secure PoW system, then you must be enriching miners.
As far as I can tell, the only difference is that Bitcoin's long term plan is to do this only through transaction fees. The assumption is that we'll have a constant backlog of high fee paying txs that will substitute the vanishing block subsidy.
Even if this turns out to be correct, the miner reward will stay the same (assuming the same security). I'd argue the fee-only model might be worse on that front because transaction fees directly transfer value from the existing
users to the miners while block subsidy prints new coins. Unless I'm missing something, the latter seems to be less of an enrichment.
13  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Grin | PoW Mining | Electronic transactions for all. Community driven. on: June 19, 2022, 06:21:42 PM
Satoshi made an interesting comment on this very forum in 2010 [1].
I was curious what exactly he was complimenting and while reading the main post from user @Red, I was able to recognize the design structure he wanted to describe. If anyone is interested in a short story that explains what the two were talking about, it is now documented [2]. It's not a mistake I'm posting this here, they were discussing a chain format that takes a step towards a block having only commitments rather than plain data, which is the path Mimblewimble/Grin also take.

In case you spot a mistake, let me know and I'll gladly correct it.

[1] https://bitcointalk.org/index.php?topic=770.msg8637#msg8637
[2] https://phyro.github.io/what-is-grin/commitment_chains.html
14  Bitcoin / Development & Technical Discussion / Re: Silent payments on: May 31, 2022, 07:08:56 PM
Yes, but I guess what @oryhp says is that if you communicate without a secure connection you can't be sure there isn't someone spying on you without you knowing it. Sure, he can take the money, but what's more valuable? Depends on your threat model.  Tongue

I was assuming a secure connection. Nothing works if you don't exchange the receiver address securely... silent payments are slightly better in the sense that they require a single secure exchange as opposed to having a secure exchange for every receiver address. Securing connections shouldn't be that hard today.
15  Bitcoin / Development & Technical Discussion / Re: Silent payments on: May 31, 2022, 10:44:10 AM
The intent of Silent Payments is to minimize address reuse by not requiring to communicate a new address for every transaction. Instead, it allows the party to generate a new address for the other party without interaction. It's basically a non-interactive counterparty address generation, similar to stealth addresses. This is just an overview without implementation details. In theory, if nobody reused addresses, it would not bring any privacy benefits, but in practice a lot of people reuse them. Something to note is that it is in the interest of both parties to not reuse the address. In a transaction, the sender will, most of the time, automatically generate a new address for his/her change output, but if the receiver address is reused, then you know which output is the change output which brings down the privacy not only for the receiver because they reused the address, but for the sender as well because everyone knows which is the change output.
16  Bitcoin / Development & Technical Discussion / Re: Compressed signature on: May 28, 2022, 04:29:18 PM
Sorry for reviving the thread, I wasn't able to find a thread about non-interactive half-aggregation schemes for Schnorr so this topic felt the closest to that.
I think non-interactive half-aggregation of signatures also makes the group of transactions atomic - at least for observers that have not seen transactions prior to half-aggregation. This
"atomic group" feature has some neat properties that I tried to capture here https://gist.github.com/phyro/209dde6bdf756f1a5bbafde7f9ba92db.

This isn't necessarily a good or welcome change for Bitcoin, but it may be worth thinking about what this would enable. Having non-interactive transaction merging through half-aggregation (or perhaps some other method?) might enable some new options including not being able to distinguish coinjoin transactions if they're represented as groups. If coinjoins were through multi txs, then non-interactive aggregation could then act as noninteractive coinjoin. There are some potential downsides e.g. adaptor signatures, joining a tx with higher fees to prioritize yours faster etc..

I'm not a cryptographer, nor do I know the details of how Bitcoin works. Hope someone finds this worth reading.
17  Bitcoin / Development & Technical Discussion / Re: Bitcoin and MimbleWimble on: March 11, 2022, 02:19:07 PM
I thought about MimbleWimble without range proof, where all amounts are known.

Oops, I misunderstood which one we're talking about. I'd have to think more about the transparent version and check Taproot to have an opinion on that.

Maybe they fixed it later in a modified version, I didn't follow up.

This was never addressed on the protocol level at Grin, I'd say mostly because there was no change proposed that would be considered a good tradeoff.

Regarding the "breaking" of Mimblewimble and the supposedly necessary "fix", I think it's important to describe things accurately.

There are 3 main privacy vectors: amounts, addresses and the transaction graph. Mimblewimble solves the first two and doesn't address the transaction graph leak much - the fact
that the whole block is just a header and a single transaction doesn't help much if people can observe deaggregated transactions in the mempool.
However, it comes with two great tools that can help immensely namely noninteractive coinjoin and transaction cut-through. It's rather obvious how Coinjoin helps with privacy,
but the cut-through can also be used for that purpose because it makes some transaction information disappear. A great example of how to combine these two properties to
achieve some interesting mixing service is the Mimblewimble CoinSwap proposal [1]. Given that Mimblewimble is a design and does not address the transaction graph on its own,
I'd argue there's nothing to "fix" here. It's simply how it works. There could be other similar designs that do a better obfuscation of the transaction graph on the protocol level,
but the Mimblewimble as described does not and it never did. Developers have been transparent/honest about it which is why the linked article doesn't "break" Mimblewimble.
I think the author misunderstood what Mimblewimble is and what it is not.

By the way, is it implemented in Monero?

They use the same technology to blind the amounts (CT), but apart from that are quite different.
Mimblewimble is CT + No addresses + Non-interactive coinjoin + Non-interactive cut-through of the whole transaction graph (scalability) + multi-sig only transactions.
Monero is CT+ Stealth addresses + Ringsigs (decoys on the input side of the transaction).

If you're interested to learn more how the two differ, there's this table available [2].

[1] https://lists.launchpad.net/mimblewimble/msg00637.html
[2] https://phyro.github.io/grinvestigation/why_grin.html
18  Bitcoin / Development & Technical Discussion / Re: Bitcoin and MimbleWimble on: March 10, 2022, 05:45:31 PM
you could never be sure if it was a single person owning 1 BTC, was it some channel with two people owning 0.5 BTC each, or maybe there were 10 participants owning something around 0.1 BTC each
Sure, this would be nice, but unfortunately, I think it's a bit of a moot point today because such features are not really used. Hopefully they get more common in the future.

Pedersen Commitments allow non-interactive public key and amount aggregation, that's why they are so important. And because we can always reveal public key for aggregation and spend by TapScript, that could be used to solve limited scripting abilities in Grin.
I may be missing some details about Taproot as I have not looked at it. I'll assume you can somehow construct a rangeproof noninteractively (you need to know both v and r to do that).
Given a commitment P = v*H + r*G, if you reveal the public key either by showing the blinding factor r or X = r*G, you end up with the information that is the same as v*H because you gave out the blinding part of the commitment so you can compute v*H = P - X.
From this, you could figure out v with brute-force by trying amount*H and seeing if you arrive at v*H. I don't see how you'd achieve TapScript or any other scripting capabilities in Grin without throwing away the most important feature of MW which is non-interactive cut-through of the whole history.
To retain the same security model/guarantees, you'd have to find a way to express the scripting language such that it supports algebraic cancelling e.g. create_script - spend_script = 0. Similarly how the secret keys get cancelled out. I may be entirely wrong on this though, haven't spent much time thinking in this direction.
19  Bitcoin / Development & Technical Discussion / Re: Bitcoin and MimbleWimble on: March 10, 2022, 01:01:51 PM
I found this blog post[1] which discuss SNICKER (CoinJoin modification) which doesn't need coordinator. There are few different specification version[2], but each version have awkward trade-off.

I believe the CoinJoin (or CoinSwap for that matter) are incredibly powerful ideas, but their effectiveness is severely hurt by the transparency of the amounts. Even if you achieved a MW-like non-interactive coinjoin for Bitcoin, you'd be able to deaggregate the joint transaction by trying amount combination sums of inputs and outputs.

There may be other ways of reducing the information a transaction gives us. This reminds me of something I've been thinking some time ago. Payjoin breaks the input ownership heuristic. There is however also output ownership information available in today's transactions, specifically the sender will always have an
output which will continue its "change output chain". Whether that's a heuristic worth breaking or not, I'm not sure, but I did document one way of potentially doing it here [1]. I had Grin in mind when I described the idea, but I think it's also applicable to Bitcoin. The main idea is to break the change output chain by
making it as short as possible. The sender essentially leaves the change output chain it was creating. This comes at a cost of another transaction and is not comparable to something like a coinjoin/coinswap. I'm not up to date with all the privacy improving attempts that were made and it's extremely likely this (or similar) strategy was already
discussed. In any case, it might be worth thinking about ways of improving privacy from an angle of reducing the sender's chain continuation pattern.

[1] https://gist.github.com/phyro/496286096cee144b7ff775d3f3b08f2f
20  Bitcoin / Development & Technical Discussion / Re: Bitcoin and MimbleWimble on: March 08, 2022, 05:10:48 PM
Only if you implement all of it. But you can just allow transaction joining and cut-through. Hiding coin amounts is a completely different story, I think we could handle that separately, because range proofs are too heavy.

You're right that the transparent "MW" may give some scalability improvements, but I don't find it nearly as appealing as the confidential version.

People always have to opt-in. You can create the best altcoin in the world, then still you can hide only between users of that altcoin. It is not much different than hiding for example only between the users of Taproot. Of course you can force people, but then you put users in danger, because they never agreed to Segwit/Taproot/MimbleWimble by using legacy addresses, so they may be exposed to new cryptographical risks and implementation risks.

I think a more relevant question is, are users of a system required to opt-in into subsystem features to obtain privacy. Let's define it this way. Does there exist a user in the system which does not have a mask? In the extension block, the answer is yes, many. And yes, Taproot is a similar way to group users into their own anonymity set with a different, more transparent, mask.

You mean Layer Zero? Where Bitcoin will be the lower layer protocol than this new layer? I thought about that in decentralized mining, but it is still work in progress. Or is it simply Layer Two and I misunderstood above/below relations between layers?

I meant L2 and above e.g. can we have a safe shuffling construction on lightning? It's possible these already exist, I'm just not up to date with the research.
Pages: [1] 2 3 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!