Hi pushd.
Would you mind clarifying what you mean by BIP118 being a premature idea?
SIGHASH_ANYPREVOUT, or SIGHASH_NOINPUT, as it was called back then, was
first proposed in the original Lightning Network whitepaper back in 2015.
It has been discussed on and off for many years now. I would not call
9 kl 17:47 skrev Luke Dashjr :
> On Monday 11 November 2019 16:08:43 Hampus Sjöberg via bitcoin-dev wrote:
> > I am advocating to keep the blocksize low right now,
>
> It ISN'T low right now...
>
> > but I don't leave out
> > in increasing it in the future when
> 1. We have Lightning and SegWit so thankfully we do not need to deal with
blocksizes anymore really.
Regardless of the current proposal in this email thread, just because we
have Lightning doesn't mean we don't ever have to increase the blocksize
again.
Even with Lightning there would be too man
Bitcoin is a consensus critical system.
We have already had consensus problems between Bitcoin Core-versions,
rewriting everything in another language would expose us to even greater
risks, and moving to a language like Python I see no benefit whatsoever.
Best
Hampus
Den tis 23 apr. 2019 kl 16:47
Hi ZmnSCPxj.
> There is a position that fullnodes must be able to get a view of the UTXO
set, and extension blocks (which are invisible to pre-extension-block
fullnodes) means that fullnodes no longer have an accurate view of the UTXO
set.
> SegWit still provides pre-SegWit fullnodes with a view o
Most solutions only work with a single Bitcoin address (terrible for
privacy, and also potentially a security risk) or xpubkey (also terrible
for privacy).
I think the best solution here is some kind of store-and-forward server,
where you trade a little bit of privacy (to the server, that is), but
Thank you for your answer, Russel.
When a code path takes advantage of a jet, does the Simplicity code still
need to be publicly available/visible in the blockchain? I imagine that for
big algorithms (say for example EDCA verification/SHA256 hashing etc), it
would take up a lot of space in the blo
Forbidding 0 satoshi outputs (I wasn't actually aware that it was possible,
is 0 satoshi inputs also allowed?) would complicate a divisibility increase
softfork (I'm working on an idea for >= 1 satoshi transactions, but now it
seems like < 1 satoshi transactions would work too).
I don't think it's
> sounds good, though I'm unclear on how exactly to achieve (2) given that
any party I have ever transacted with (or otherwise knows an address of
mine) can send me coins at any time. So it seems the only possible way
to be certain is to run a node that has never published an address to a
3rd part
t; >
> >
> > On Thu, Jul 13, 2017 at 12:19 PM, Dan Libby via bitcoin-dev
> > > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> >
> > On 07/13/2017 06:39 AM, Hampus Sjöberg via bitcoin-dev wrote:
> > >> I believe that a good r
> I believe that a good reason not to wish your node to be segwit compliant
is to avoid having to deal with the extra bandwidth that segwit could
require. Running a 0.14.2 node means being ok with >1MB blocks, in case
segwit is activated and widely used. Users not interested in segwit
transaction
In softforks, I would argue that 100% of all nodes and miners need to
upgrade to the new rules.
This makes sure that trying to incorrectly spend an "AnyOneCanSpend" will
result in a hardfork, instead of a temporary (or permanent) chainsplit.
With drivechains, it seems like the current plan is to o
>From the PR change:
> Miners must continue setting the bit in LOCKED_IN phase so uptake is
visible and acknowledged. Blocks without the applicable bit set are invalid
during this period
Luke, it seems like the amendments to BIP8 make it drastically different to
how it first was designed to work.
> I think it would be useful for there to exist a useful and trivial
> patch against current (0.14.2) software to engage in the BIP91-like
> orphaning, like people have provided for BIP148-- but right now I
> don't see any specification of the behavior so it's unclear to me
> _exactly_ what it woul
> Ironically, it looks like most of the segwit2x signaling miners are
> faking it (because they're not signaling segwit which it requires).
> It'll be unfortunate if some aren't faking it and start orphaning
> their own blocks because they are failing to signal segwit.
Well, they're doing some kin
I don't think it's a huge deal if the miners need to run a non-Core node
once the BIP91 deployment of Segwit2x happens. The shift will most likely
be temporary.
I agree that the "-bip148"-option should be merged, though.
2017-06-20 17:44 GMT+02:00 Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists
> Who are we protecting users from, themselves? Are you protecting core?
from what? I am somewhat genuinely befuddled by those who can't even allow
a user config switch to be set.
Indeed. It seems silly. If you're activating the switch, you're most likely
fully aware of what you're doing.
I also s
I'm really happy to see people trying to cooperate to get SegWit activated.
But I'm really unsure about the technicalities about Silbert's proposal.
If we're going to do a hardfork, it makes most sense to assist Johnson in
his spoonnet/forcenet proposals.
Just doing a simple 2MB without fixing any
AFAICT, re-enabling these old OP-codes would require a hardfork.
If we had SegWit enabled, we could via a soft fork allocate new OP-codes
for the same functionality (by introducing a new version of Script).
I believe the Elements alpha project has been experimenting with
re-enabling old OP-codes:
> For example would be something like this:
> If block = (empty OR <%75 of mempool) THEN discard
> This threshold just an example
I don't think this is a good idea, mempool is different from node to node
and is not a part of the consensus.
Hampus
2017-03-24 18:29 GMT+01:00 Nick ODell via bitcoi
> It gives miners complete control over the limit. They can make blocks of
any size (within the current limit), thus triggering the conditions by
which your proposal would raise the limit further.
There might be a long term incentive to keep increasing the blocksize, to
further centralize the netw
> While disk space requirements might not be a big problem, block
propagation time is
Is block propagation time really still a problem? Compact blocks and FIBRE
should help here.
> Bitcoin, because its fundamental design, can scale by using offchain
solutions.
I agree.
However, I believe that on
> Also how about making timestamp 8 bytes? 2106 is coming up soon :)
AFAICT this was fixed in this commit:
https://github.com/jl2012/bitcoin/commit/fa80b48bb4237b110ceffe11edc14c8130672cd2#diff-499d7ee7998a27095063ed7b4dd7c119R200
2016-12-04 21:00 GMT+01:00 adiabat via bitcoin-dev <
bitcoin-dev
23 matches
Mail list logo
