Couldn't scripts like this have a standardized "hardfork unroll" mechanism,
where if a hardfork is activated and signaled to its clients, then those
commitments that are only meant for their original chain can be reversed
and undone just on the hardfork? Then the users involved would just send an
u
Reposting /u/BashCo's post on reddit here, for visibility:
---8<---
> Before anyone says 'bits' are too confusing because it's a computer
science term, here's a list of homonyms [https://en.wikipedia.org/
wiki/List_of_true_homonyms] that
A large miner would only need to divide his hardware setup into clusters
that pretend to be different independent miners to create these "miner
tokens", as explained before, to significantly raise his chances that he on
nearly every single round would be able to mine.
Once each individual token is
Den 23 jan. 2018 23:45 skrev "Gregory Maxwell via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
On Tue, Jan 23, 2018 at 10:22 PM, Anthony Towns wrote:
> Hmm, at least people can choose not to reuse addresses currently --
> if everyone were using taproot and that didn't involve hashing th
Den 24 jan. 2018 16:38 skrev "Tim Ruffing via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
Okay, I think my proposal was wrong...
This looks better (feel free to break again):
1. Commit (H(classic_pk, tx), tx) to the blockchain, wait until confirmed
2. Reveal classic_pk in the blockchai
Den 25 jan. 2018 00:22 skrev "Tim Ruffing via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
I think you misread my second proposal. The first step is not only to
publish the hash but to publish a *pair* consisting of the hash and the
transaction.
If the attacker changes the transaction
Den 13 feb. 2018 15:07 skrev "JOSE FEMENIAS CAÑUELO via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
***
NO PART OF THIS SOFTWARE CAN BE INCLUDED IN ANY OTHER PROJECT THAT USES THE
NAME BITCOIN AS PART OF ITS NAME AND/OR ITS MARKETING MATERIAL UNLESS THE
SOFTWARE PRODUCED BY THAT PROJECT
Den 15 feb. 2018 17:00 skrev "Tim Ruffing via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
Consensus rules
===
A decommitment d = chal spends a UTXO with address H_addr(chal), if
there exists a commitment c in the blockchain which references the UTXO
and which is the first c
Den 15 feb. 2018 22:58 skrev "Tim Ruffing via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
Also, the miners will indeed see one valid decommitment. This
decommitment may have been sent by the attacker but it's the preimage
chal of the address, because otherwise it's not valid for the ma
Small correction, see edited quote
Den 15 feb. 2018 23:44 skrev "Natanael" :
Allowing expiration retains insecurity, while *NOT* allowing expiration
makes it a trivial DoS target.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https:
Den tis 22 maj 2018 20:18Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> skrev:
> Hello all,
>
> Given the recent discussions about Taproot [1] and Graftroot [2], I
> was wondering if a practical deployment needs a way to explicitly
> enable or disable the Graftroot spending
Den tor 24 maj 2018 01:45Gregory Maxwell skrev:
> I am having a bit of difficulty understanding your example.
>
> If graftroot were possible it would mean that the funds were paid to a
> public key. That holder(s) of the corresponding private key could
> sign without constraint, and so the accou
Den tor 24 maj 2018 04:08Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> skrev:
>
> My understanding of the question is this:
>
> Are there any useful applications which would be impeded if a signing
> party who could authorize an arbitrary transaction spending a coin had
Den mån 19 nov. 2018 21:21 skrev Steven Hatzakis via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:
> Hi Weiji, and Everyone,
>
> I think this is an important topic so sharing my two cents in case in
> helps: It makes sense for users to know that they can't merely just
> translate a word fr
Related ideas previously submitted by me;
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013885.html
Title: Block size adjustment idea - expedience fees + difficulty scaling
proportional to block size (+ fee pool)
Den sön 7 apr. 2019 17:45simondev1 via bitcoin-dev <
bitcoin-d
On Thu, May 23, 2019 at 9:58 PM Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> If the difficulty can be directly observed by the script language, you
> would need to re-evaluate all scripts in unconfirmed transactions
> whenever the difficulty changes. This complic
Wouldn't block withhold be fixed by not letting miners in pools know which
block candidates are valid before the pool knows? (Note: I haven't read any
other proposals for how to fix it, this may already be known)
As an example, by having the pool use the unique per-miner nonces sent to
each miner
Den 20 dec 2015 12:38 skrev "Tier Nolan via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
>
> On Sun, Dec 20, 2015 at 5:12 AM, Emin Gün Sirer <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> An attacker pool (A) can take a certain portion of its hashpower,
>> use it to mine on behalf
To say that Bitcoin is strongly consistent is to say that the memory pool
and the last X blocks aren't part of Bitcoin. If you want to avoid making
that claim, you can at best argue that Bitcoin has both a strongly
consistent component AND an eventually consistent component.
The entire point of th
Den 12 okt. 2016 01:33 skrev "John Hardy via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
> Sidechains seem an inevitable tool for scaling. They allow Bitcoins to be
transferred from the main blockchain into external blockchains, of which
there can be any number with radically different a
Den 24 jan. 2017 15:33 skrev "Johnson Lau via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
B. For transactions created before this proposal is made, they are not
protected from anti-replay. The new fork has to accept these transactions,
as there is no guarantee that the existing fork w
Den 25 jan. 2017 08:06 skrev "Johnson Lau" :
What you describe is not a fix of replay attack. By confirming the same tx
in both network, the tx has been already replayed. Their child txs do not
matter.
Read it again.
The validation algorithm would be extended so that the transaction can't be
re
Den 25 jan. 2017 08:22 skrev "Johnson Lau" :
Assuming Alice is paying Bob with an old style time-locked tx. Under your
proposal, after the hardfork, Bob is still able to confirm the time-locked
tx on both networks. To fulfil your new rules he just needs to send the
outputs to himself again (with d
Den 28 jan. 2017 05:04 skrev "Luke Dashjr via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
Satoshi envisioned a system where full nodes could publish proofs of invalid
blocks that would be automatically verified by SPV nodes and used to ensure
even they maintained the equivalent of full
Den 5 feb. 2017 16:33 skrev "John Hardy via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
Currently in order to signal support for changes to Bitcoin, only miners
are able to do so on the blockchain through BIP9.
One criticism is that the rest of the community is not able to participate
I had these following ideas as I was thinking about how to allow larger
blocks without incentivizing the creation of excessively large blocks. I
don't know how much of this is novel, I'd appreciate if anybody could link
to any relevant prior art. I'm making no claims on this, anything novel in
here
Den 30 mars 2017 12:04 skrev "Luke Dashjr" :
I don't see a purpose to this proposal. Miners always mine as if it's their
*only* chance to get the fee, because if they don't, another miner will. Ie,
after 1 block, the fee effectively drops to 0 already.
I believe that with correctly configured i
Den 30 mars 2017 11:34 skrev "Natanael" :
Block size dependent difficulty scaling. Hardfork required.
Larger blocks means greater difficulty - but it doesn't scale linearly,
rather a little less than linearly. That means miners can take a penalty in
difficulty to claim a greater number of high fe
Den 30 mars 2017 11:34 skrev "Natanael" :
Block size dependent difficulty scaling. Hardfork required.
Larger blocks means greater difficulty - but it doesn't scale linearly,
rather a little less than linearly. That means miners can take a penalty in
difficulty to claim a greater number of high fe
Sorry for sending a double, hit the wrong button...
Den 31 mars 2017 06:14 skrev "Natanael" :
>
>
> Den 30 mars 2017 11:34 skrev "Natanael" :
>
> Block size dependent difficulty scaling. Hardfork required.
>
> Larger blocks means greater difficulty - but it doesn't scale linearly,
> rather a litt
Den 1 apr. 2017 14:33 skrev "Jorge Timón via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
Segwit replaces the 1 mb size limit with a weight limit of 4 mb.
That would make it a hardfork, not a softfork, if done exactly as you say.
Segwit only separates out signature data. The 1 MB limi
Den 1 apr. 2017 01:13 skrev "Eric Voskuil via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 03/31/2017 02:23 PM, Rodney Morris via bitcoin-dev wrote:
> If the obsession with every personal computer being able to run a
> fill node continu
Den 1 apr. 2017 16:35 skrev "Eric Voskuil via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 03/31/2017 11:18 PM, Jared Lee Richardson wrote:
>> If a typical personal computer cannot run a node there is no
>> security.
>
> If you can't de
Den 1 apr. 2017 16:07 skrev "Jorge Timón" :
On Sat, Apr 1, 2017 at 3:15 PM, Natanael wrote:
>
>
> Den 1 apr. 2017 14:33 skrev "Jorge Timón via bitcoin-dev"
> :
>
> Segwit replaces the 1 mb size limit with a weight limit of 4 mb.
>
>
> That would make it a hardfork, not a softfork, if done exactly
My point, if you missed it, is that there's a mathematical equivalence
between using two limits (and calculating the ratio) vs using one limit and
a ratio. The output is fully identical. The only difference is the order of
operations. Saying there's no blocksize limit with this is pretty
meaningles
Den 15 apr. 2017 13:51 skrev "Chris Acheson via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
Not sure if you missed my previous reply to you, but I'm curious about
your thoughts on this particular point. I contend that for any UASF,
orphaning non-signalling blocks on the flag date is [m
Den 17 apr. 2017 16:14 skrev "Erik Aronesty via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
It's too bad we can't make the POW somehow dynamic so that any specialized
hardware is impossible, and only GPU / FPGA is possible.
Maybe a variant of Keccak where the size of the sponge is i
To expand on this below;
Den 18 apr. 2017 00:34 skrev "Natanael" :
IMHO the best option if we change PoW is an algorithm that's moderately
processing heavy (we still need reasonably fast verification) and which
resists partial state reuse (not fast or fully "linear" in processing like
SHA256) jus
Den 3 maj 2017 16:05 skrev "Erik Aronesty via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
> But as you've observed, the failure probabilities are rather high,
> especially if an active attacker targets nodes carrying less commonly
> available blocks.
Wouldn't the solution be for nodes
Den 8 maj 2017 23:01 skrev "Sergio Demian Lerner via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
I'll soon present a solution to encourage full nodes to store the
blockchain based on Proof-of-Unique-Blockchain-Storage (PoUBS)
Proving that you're holding your own copy of the blockchain
- Sent from my tablet
Den 22 jul 2015 17:51 skrev "Thomas Voegtlin via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
>
> Hello,
>
> Although Electrum clients connect to several servers in order to fetch
> block headers, they typically request address balances and address
> histories from a
Den 7 aug 2015 23:37 skrev "Sergio Demian Lerner via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
>
> Mark,
> It took you 3 minutes to respond to my e-mail. And I responded to you 4
minutes later. If you had responded to me in 10 minutes, I would be of out
the office and we wouldn't have
My current idea:
* There's a scheduled hardcap that goes up over time.
* Miners vote on the blocksize limit within the hardcap, choosing the new
votecap. No particular idea for scheduling change. The 2016 block period
seems a bit long though, in case of sudden peak load.
(I'd suggest rolling vote
One last comment here on this topic;
For anybody who wants to discuss decentralized communication mechanisms in
general, they can come to www.reddit.com/r/p2pcomms (up until these
decentralized forums have become stable and common).
I've seen quite a few more of these projects lately, I want to m
Creative Commons Zero, if anything at all.
It essentially emulates public domain in jurisdictions that do not
officially have a public domain.
- Sent from my tablet
Den 1 sep 2015 15:30 skrev "Ahmed Zsales via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
> Hello,
>
> We believe the net
Den 2 sep 2015 00:03 skrev "Btc Drak via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
>
> I think it gets worse. Who are the copyright owners (if this actually
> applies). You've got people publishing transaction messages, you've
> got miners reproducing them and publishing blocks. Who ar
46 matches
Mail list logo
