Bitcoin Forum
October 01, 2023, 10:39:23 PM *
News: Latest Bitcoin Core release: 25.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 »
1  Bitcoin / Development & Technical Discussion / Re: CoinCovenants using SCIP signatures, an amusingly bad idea. on: March 02, 2015, 07:21:22 PM
Just add a rule to require all SCIP inputs must be sent to standard pubkey hash outputs, so covenant is not possible. However, this will eliminate all "good use" of covenant.

You could provide the hash preimages in the scriptSig to the covenant.
2  Bitcoin / Development & Technical Discussion / Re: Individual Block Difficulty Based on Block Size on: February 17, 2015, 07:18:17 PM
I think you're misunderstanding the problem as this isn't about transaction selection. The issue is, should someone who is mining a more difficult block (say, 2x the normal difficulty) continue mining against an older block even after hearing about a 1x new block? To a nave first-order approximation, they stand to benefit from doing so because a 2x block would beat out the 1x block and the would be able to steal the fees of the transactions in the 1x block. Of course there are a lot of assumptions wrapped up in that nave assessment, nor is it clear that it is a reflectively stable outcome (if the 1x miners knew you would do this, how would that change their strategy? how would that change of strategy affect the profitability of this attack? etc.)
3  Bitcoin / Development & Technical Discussion / Re: Individual Block Difficulty Based on Block Size on: February 17, 2015, 03:48:01 PM
Yes, but it is not immediately obvious what effect that has on mining incentives. Someone needs to actually work out the possible mining strategies here.
4  Bitcoin / Development & Technical Discussion / Re: Individual Block Difficulty Based on Block Size on: February 17, 2015, 02:15:06 AM
Work calculations would need to follow the declared work of the block -- e.g. a 3x block is valued at 3x the work.
5  Bitcoin / Development & Technical Discussion / Re: Individual Block Difficulty Based on Block Size on: February 16, 2015, 12:08:29 PM
This is a challenge for the distant future, if ever. It seems pretty likely the value of the currency at the next halving will be at least double its value at the last halving (which was only 12 USD), with 3 more doublings already provided for at today's price.

It's a problem today in contexts such as sidechains where there is no block subsidy. That's why we were looking at this exact proposal internally at Blockstream (alas, I can find no public descriptions of the idea, so we've been scooped!). I share gmaxwell's concern that there seem to be an infinite number of possible curves to use, and it is not even obvious what metric should be used to rate them. It would be ideal to show that for various distributions of priority/fee-per-kb in the mempool that there exist Nash equilibrium mining strategies which result in a stable block size. The block size adjustment algorithm must also do something to mitigate centralization pressures of larger block sizes -- larger blocks make better connected miners have larger apparent hash rates than they actually do, due to differences in propagation time. Neither of these are well formalized yet, and there may be other requirements remaining to be discovered.

A few minor notes: since the difficulty is specified in the block header, it is possible for the miner to choose a block size which is possibly greater than the actual block size by adjusting their reported difficulty (the bits field of the PoW). Additionally, for bitcoin you have the question of whether or not to adjust the subsidy by the same factor. Arguments for and against adjusting the subsidy have to do with whether you want there to be a near-term cost to adjusting the block height.
6  Bitcoin / Project Development / Re: 10 BTC bounty for first AT *atomic cross-chain transfer* with Script clone on: October 27, 2014, 02:00:55 AM
You can do atomic trade with regular old bitcoin script. Would that qualify for this bounty?
7  Bitcoin / Development & Technical Discussion / Re: User assets, peer-to-peer exchange, off-chain accounting & transitive txn in btc on: September 02, 2014, 08:48:30 PM
There will be an update coming soon. Although we were unable to secure funding from the community, Jorge and I are working together with others on a currently stealth-mode project that includes aspects of Freimarkets. We are also working on an update to the whitepaper to include all the advances that have come in the last year. Our mental model of how Freimarkets would be implemented has diverged a bit for the better from what we wrote down a year ago.
8  Other / Off-topic / Re: ALSA IceBucketChallenge (Ice Bucket Challenge) I challenge ALL OF YOU! on: August 31, 2014, 07:17:08 PM
Guys this is pretty despicable. ALS is a real disease that afflicts hundreds of thousands of people worldwide, and affects the lives of millions of people connected to those with the disease. This challenge -- whatever you may think of the specifics -- has helped raise $100m for research. That is phenomenal! I don't know how any one with a good heart can criticize that.

And yes, we all know someone that was afflicted by this disease. This community owes a huge debt to Hal Finney and I would suggest anyone who cares about bitcoin to take the challenge or make a donation of any size in honor of that man and our debt.
9  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Freicoin: demurrage crypto-currency from the Occupy movement (crowdfund) on: August 06, 2014, 12:21:18 AM
http://freico.in

"This Domain Name Has Expired"

Well, that isn't a good sign.

Expired credit card on the auto-renew. Sadly, the junk registrar I used auto-switched to a spam parking host with a very high TTL. A few days out and the DNS caches still haven't cleared out...
10  Alternate cryptocurrencies / Altcoin Discussion / Re: Sidechains, Treechains, the TL;DR, welcome to join discussion. on: August 03, 2014, 10:26:26 PM
ex0du5, the point is that the bitcoin validators can do full validation of the side chain via a constant-time SNARK validation, even one whose rules they don't know.
11  Alternate cryptocurrencies / Altcoin Discussion / Re: Sidechains, Treechains, the TL;DR, welcome to join discussion. on: August 03, 2014, 07:41:08 PM
In the most general, sidechains will use SPV Proofs to send satoshis from the regular Bitcoin chain to the sidechain, and allows the sidechain to eventually send the satoshis back to the main chain once the owner of said coin is finished utilizing the sidechain. While in the sidechain, the main chain knows nothing of whats happening to the coin, the sidechain is the one tracking who owns what at what time.

No, a side chain is simply any chain with an asset that supports some form of 2-way pegging against BTC. There is no reason that side chains have to use the SPV proof mechanism for accomplishing this peg, or merged mining for validation. These are simply aspects of one example implementation pathway that was presented as a proof of concept of how a side chain could be implemented. The design space is actually quite large, however.
12  Bitcoin / Development & Technical Discussion / Re: Ultimate blockchain compression w/ trust-free lite nodes on: July 06, 2014, 12:01:17 PM
No offense, but I'm not sure you understand "UTXO" well enough to explain it to others. For starters, UTXO is nothing new, this post is about "committed utxo". As maaku explained, miners need to know that they're mining on top of the valid chain, that's the only way they can know they have the accurate UTXO.

maaku confirmed that I understood UTXO's SPV+ mode.

Jorge is correct: miners have to know they are building on top of a valid chain, and to do that they need to validate the entire block chain history. The post you linked to endorsed a statement which included this caveat, which your most recent explanation does not.
13  Bitcoin / Development & Technical Discussion / Re: I assume this 497 BTC output is unspendable? on: July 01, 2014, 03:40:10 PM
Imagine the situation when top-10 mining pools will accept this protocol change in 4 years from today.
There will be split of network in ~2018.
I think that the majority of users will follow the pool-owners

No, they won't. They'd have no economic incentive to. If a cartel of a few individuals can change bitcoin at will, then bitcoin loses its only redeeming feature and becomes a very expensive, less usable version of paypal. There is absolutely no way that any central party can mandate controversial hard-fork changes to the bitcoin protocol, no matter their hashrate.
14  Bitcoin / Development & Technical Discussion / Re: Is funding a development team really that difficult? on: June 27, 2014, 09:54:42 PM
One of the posters in this very thread was responsible for funding much of my development time over the last 18 months (not sure if he wants public credit, so I'm not naming him). It's a model that can work... but alas altruists are the minority. It seems, sadly, that most people would rather have someone else pay for the code. Tragedy of the commons and all that.

It is vitally important that we come up with alternative mechanisms for pooling resources to get the necessary projects done, because what we are doing is not working. I have high hopes for Hearn's Lighthouse application, but even more innovation than that may be needed...
15  Bitcoin / Development & Technical Discussion / Re: CoinJoin: Bitcoin privacy for the real world on: June 24, 2014, 10:41:11 PM
Read the first page of this thread. There's a solution involving blinded outputs.
16  Bitcoin / Development & Technical Discussion / Re: CoinJoin: Bitcoin privacy for the real world on: June 24, 2014, 05:31:29 PM
So it's trivially identifiable whose outputs are whose based on the observed offers?
17  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Freicoin: demurrage crypto-currency from the Occupy movement (crowdfund) on: June 23, 2014, 04:56:58 AM
I'm not sure what you're asking for re: timeline. Freicoin was released in Dec 2012, and so it's been live for about 18 months now. You can download the latest official version from the website:

http://freico.in/

There isn't a whitepaper because the concept is quite simple. You can read about it in the OP or the official website. There is a whitepaper describing future additions that will hopefully be included within a year:

http://freico.in/docs/freimarkets.pdf
18  Bitcoin / Development & Technical Discussion / Re: Ultimate blockchain compression w/ trust-free lite nodes on: June 22, 2014, 12:25:48 AM
I don't know of anyone besides me who is still working on UTXO commitments. It is developer time limited right now since for about six months I've been split between multiple projects trying to make ends meet. I posted a summary of the current state earlier in this thread, and any bitcoins or bitcoind developers would be appreciated in speeding the process along.
19  Bitcoin / Development & Technical Discussion / Re: Ultimate blockchain compression w/ trust-free lite nodes on: June 21, 2014, 03:54:00 PM
That appears to be a correct description of SPV+ mode.
20  Bitcoin / Development & Technical Discussion / Re: Ultimate blockchain compression w/ trust-free lite nodes on: June 20, 2014, 06:59:36 AM
I explained myself, twice:

The miner needs to verify the entire block chain history because otherwise he has no way of knowing if he is actually on a valid chain or not. This has nothing to do with UTXO commitments, rolling root, or any other proposal. It's a basic, fundamental requirement of any consensus system: if the miners themselves operate in SPV mode (which you advocate), then anyone -- no matter their hashrate! -- can trick the network into mining an invalid chain. The attacker does so by mining a fork with invalid history and temporarily (by luck or 51%) overcoming the honest network. New miners coming online, or miners tricked into reseting their state then switch to the invalid chain This completely invalidates the SPV assumption and makes it unsafe for anybody to use the network.
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!