On 05/21/2014 10:10 AM, Wladimir wrote:
> On Wed, May 21, 2014 at 6:39 PM, Chris Beams wrote:
>> I'm personally happy to comply with this for any future commits, but wonder
>> if you've considered the arguments against commit signing [1]? Note
>> especially the reference therein to Linus' original
I know the likelihood of this happening is slim, but if these are the
desired features we should consider switching to monotone (monotone.ca)
which has a much more flexible DAG structure and workflow built around
programmable multi-sig signing of commits. We could still maintain the
github account
Please make a pull request on github. It'll likely get merged quickly.
On May 29, 2014 5:04 PM, "Toshi Morita" wrote:
> I ran bitcoind under valgrind and found a place where it references an
> uninitialized variable in some cases:
>
> tm@tm-VirtualBox:~/bitcoind/bitcoin/src$ valgrind ./bitcoind
>
The correct approach here is header hash-tree commitments which enable
compact (logarithmic) SPV proofs that elide nearly all intervening
headers since the last checkpoint. You could then query the hash tree
for references to any of the headers you actually need.
See this message for details:
htt
Not when failure is defined as, e.g., extra text pushing a UI element
down such that the button the user needs to click is no longer visible.
You don't test that except by having a human being run through some
example workflows, which is presumably happening during the release process.
On 06/13/20
Not with current script, but there are mechanisms by which you can do a
digital signature where signing two pieces of information reveals the
ECDSA k parameter, thereby allowing anyone to recover the private key
and steal the coins.
Practically speaking, these are not very safe systems to use. For
Sergio, why is preventing mining pools a good thing? The issue is not
mining pools, which provide a needed service in greatly reducing
variance beyond what any proposal like this can do.
The issue is centralized transaction selection policies, which is
entirely orthogonal. And the solution already
Do you need to do full validation? There's an economic cost to mining
invalid blocks, and even if that were acceptable there's really no
reason to perform such an attack. The result would be similar to a block
withholding attack, but unlike block withholding it would be trivially
detectable if/when
It's not the pool operator's business what software the miner is running
to select transactions for his block, so long as the miner follows the
template and doesn't generate invalid blocks. We already discussed
invalid blocks, and checking the template requires parsing the coinbase
transaction and
Can someone explain to these guys and the public why promising to limit
yourselves to *only* a 50% chance of successfully double-spending a 6
confirm transaction is still not acceptable?
q=0.4
z=0 P=1
z=1 P=0.828861
z=2 P=0.736403
z=3 P=0.664168
z=4 P=0.603401
z=5 P=0.55062
On 08/06/2014 11:42 AM, Peter Todd wrote:
> On 6 August 2014 08:17:02 GMT-07:00, Christian Decker
> wrote:
>> +1 for the new field, overloading fields with new meaning is
>> definitely not a good idea.
>
> To add a new field the best way to do it is create a new, parallel,
> tx format where field
On 08/06/2014 01:02 PM, Tom Harding wrote:
> With first-eligible-height and last-eligible-height, creator could
> choose a lifetime shorter than the max, and in addition, lock the whole
> thing until some point in the future.
Note that this would be a massive, *massive* change that would
complete
On 08/06/2014 01:20 PM, Peter Todd wrote:
> The general case doesn't require transmission of any merkle data; it
> is derived from the tx data.
How can that possibly be the case? The information is hidden behind the
Merkle root in the transaction. The validator needs to know whether
there is an ex
On Sat, Aug 9, 2014 at 6:10 AM, Sergio Lerner
wrote:
> Hi Tim,
> It's clear from the paper that the second party in the protocol can
> de-anonymize the first party. So it's seems that dishonest shufflers would
> prefer to be in that position in the queue.
>
That's not clear to me. The 2nd part
There should not be a requirement at this level to ensure validity. That
would too constrain use cases of implementations of your protocol. It is
not difficult to imagine use cases where parties generate chained
transactions on top of unconfimed transactions. Although malleability
currently makes t
Thank you Jorge for the contribution of the Stag Hunt terminology. It is
much better than a politically charged "scorched earth".
On Feb 21, 2015 11:10 AM, "Jorge Timón" wrote:
> I agree "scorched hearth" is a really bad name for the 0 conf protocol
> based on game theory. I would have preferred
At this moment anyone can alter the txid. Assume transactions are 100%
malleable.
On Apr 16, 2015 9:13 AM, "s7r" wrote:
> Hi Pieter,
>
> Thanks for your reply. I agree. Allen has a good point in the previous
> email too, so the suggestion might not fix anything and complicate things.
>
> The prob
controller
constrains the maximum allowed block size to be within a range supported by
fees on the network, providing an emergency relief valve that we can be
assured will only be used at significant cost.
Mark Friedenbach
* There has over time been various discussions on the bitcointalk forums
about d
The problems with that are larger than time being unreliable. It is no
longer reorg-safe as transactions can expire in the course of a reorg and
any transaction built on the now expired transaction is invalidated.
On Fri, May 8, 2015 at 1:51 PM, Raystonn wrote:
> Replace by fee is what I was ref
Transactions don't expire. But if the wallet is online, it can periodically
choose to release an already created transaction with a higher fee. This
requires replace-by-fee to be sufficiently deployed, however.
On Fri, May 8, 2015 at 1:38 PM, Raystonn . wrote:
> I have a proposal for wallets suc
On Fri, May 8, 2015 at 3:43 PM, Aaron Voisine wrote:
> This is a clever way to tie block size to fees.
>
> I would just like to point out though that it still fundamentally is using
> hard block size limits to enforce scarcity. Transactions with below market
> fees will hang in limbo for days and
e, causing users to economize on block space without
> resorting to dropping transactions after a prolonged delay.
>
> Aaron Voisine
> co-founder and CEO
> breadwallet.com
>
> On Fri, May 8, 2015 at 3:45 PM, Mark Friedenbach
> wrote:
>
>> On Fri, May 8, 2015 at 3:43 PM, A
Micropayment channels are not pie in the sky proposals. They work today on
Bitcoin as it is deployed without any changes. People just need to start
using them.
On May 10, 2015 11:03, "Owen Gunden" wrote:
> On 05/08/2015 11:36 PM, Gregory Maxwell wrote:
> > Another related point which has been ten
wrote:
> Le 08/05/2015 22:33, Mark Friedenbach a écrit :
>
> > * For each block, the miner is allowed to select a different difficulty
> > (nBits) within a certain range, e.g. +/- 25% of the expected difficulty,
> > and this miner-selected difficulty is used for the proof o
Please let's at least have some civility and decorum on this list.
On Tue, May 26, 2015 at 1:30 PM, wrote:
> You're the Chief Scientist of __ViaCoin__ a alt with 30 second blocks
> and you have big banks as clients. Shit like replace-by-fee and leading
> the anti-scaling mob is for your clients,
Sequence numbers appear to have been originally intended as a mechanism for
transaction replacement within the context of multi-party transaction
construction, e.g. a micropayment channel. The idea is that a participant
can sign successive versions of a transaction, each time incrementing the
seque
On Wed, May 27, 2015 at 3:11 AM, Mike Hearn wrote:
>
> As I believe out of all proposed protocols Satoshi's is still the most
> powerful, I would suggest that any change to the semantics on nSequence be
> gated by a high bit or something, so the original meaning remains available
> if/when resour
I have no problem with modifying the proposal to have the most significant
bit signal use of the nSequence field as a relative lock-time. That leaves
a full 31 bits for experimentation when relative lock-time is not in use. I
have adjusted the code appropriately:
https://github.com/maaku/bitcoin/t
at legacy transactions that have already been signed but have
> a locktime in the future will still be able to enter the blockchain
> (without having to wait significantly longer than expected).
>
> On Thu, May 28, 2015 at 10:56 AM, Mark Friedenbach
> wrote:
>
>> I have no pro
at 8:18 AM, Tier Nolan wrote:
> On Thu, May 28, 2015 at 3:59 PM, Mark Friedenbach
> wrote:
>
>> Why 3? Do we have a version 2?
>>
> I meant whatever the next version is, so you are right, it's version 2.
>
>> As for doing it in serialization, that woul
The reference implementation is available at the following git repository:
https://github.com/maaku/bitcoin/tree/sequencenumbers
I request that the BIP editor please assign a BIP number for this work.
Sincerely,
Mark Friedenbach
t; obviously that it saves transaction space by repurposing unused space, and
> would likely work for most cases where an OP_RCLTV would be needed.
>
> Best,
> Stephen
>
> On Mon, Jun 1, 2015 at 9:49 PM, Mark Friedenbach
> wrote:
>
>> I have written a reference implemen
onment with access to information that it doesn't have now, which is
> > what we are trying to avoid.
> >
> > Best,
> > Stephen
> >
> >
> >
> > On Jun 2, 2015, at 12:16 AM, Mark Friedenbach
> wrote:
> >
> > You are correct! I am ma
Why is this your business or the business of anyone on this list? Take it
somewhere else.
On Thu, Jun 4, 2015 at 2:52 PM, Sven Berg wrote:
> 1) Hours/week have you devoted to each project out of a 40hr work week
>
> 2) Upfront and ongoing fees for use of your name
>
> 3) Break down total amounts
Rusty, this doesn't play well with SIGHASH_SINGLE which is used in
assurance contracts among other things. Sometimes the ordering is set by
the signing logic itself...
On Jun 5, 2015 9:43 PM, "Rusty Russell" wrote:
> Title: Canonical Input and Output Ordering
> Author: Rusty Russell
> Discussion
Certainly, but I would drop discussion of IsStandard or consensus rules.
On Jun 6, 2015 1:24 AM, "Wladimir J. van der Laan" wrote:
> On Fri, Jun 05, 2015 at 09:46:17PM -0700, Mark Friedenbach wrote:
> > Rusty, this doesn't play well with SIGHASH_SINGLE which is used in
Peter it's not clear to me that your described protocol is free of miner
influence over the vote, by artificially generating transactions which they
claim in their own blocks, or conforming incentives among voters by opting
to be with the (slight) majority in order to minimize fees.
Wouldn't it in
There's another important use case which you mentioned Greg, that also
requires special exemption: compact commitments via mid-state compression.
The use case is an OP_RETURN output sorted last, whose last N bytes are a
commitment of some kind. A proof of the commitment can then use mid state
comp
On Mon, Jun 15, 2015 at 5:08 PM, Aaron Voisine wrote:
> Wasn't the XT hard fork proposed as a last resort, should the bitcoin-core
> maintainers simply refuse to lift the 1Mb limit? No one wants to go that
> route. An alternate hard-fork proposal like BIP100 that gets consensus, or
> a modified v
to
proceed?
Thank you,
Mark Friedenbach
On Mon, Jun 1, 2015 at 6:49 PM, Mark Friedenbach
wrote:
> I have written a reference implementation and BIP draft for a soft-fork
> change to the consensus-enforced behaviour of sequence numbers for the
> purpose of supporting transaction replac
On Thu, Jun 18, 2015 at 6:31 AM, Mike Hearn wrote:
> The first issue is how are decisions made in Bitcoin Core? I struggle to
> explain this to others because I don't understand it myself. Is it a vote
> of people with commit access? Is it a 100% agreement of "core developers"
> and if so, who ar
Matt, I for one do not think that the block size limit should be raised at
this time. Matt Corallo also started the public conversation over this
issue on the mailing list by stating that he was not in favor of acting now
to raise the block size limit. I find it a reasonable position to take that
e
On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik wrote:
>
> The whole point is getting out in front of the need, to prevent
> significant negative impact to users when blocks are consistently full.
>
> To do that, you need to (a) plan forward, in order to (b) set a hard fork
> date in the future.
>
What retail needs is escrowed microchannel hubs (what lightning provides,
for example), which enable untrusted instant payments. Not reliance on
single-signer zeroconf transactions that can never be made safe.
On Fri, Jun 19, 2015 at 5:47 PM, Andreas Petersson
wrote:
> I have some experience her
Sorry for the duplication Amir, I meant to send this to everyone:
BitTorrent might be an example to look to here. It's a peer-to-peer network
that has undergone many significant protocol upgrades over the years while
maintaining compatibility. More recent clients have had the ability to
expose the
On Tue, Jun 19, 2012 at 10:33 AM, Alan Reiner wrote:
> I hope that someone else here would chime in on the issue raised in the
> thread, about using a tree-structure that has multiple valid
> configurations for the same set of unspent-TxOuts. If you use any
> binary tree, you must replay the ent
On Fri, Jul 6, 2012 at 9:49 AM, Jeff Garzik wrote:
> On Fri, Jul 6, 2012 at 12:45 PM, Peter Vessenes wrote:
> > The proposal is simple, and it's a small change for miners, I imagine.
> >
> > My question is: why?
> >
> > I worry about stuffing too many requirements on the coinbase. I suppose
> >
ided that
you have the necessary dependencies installed.
I hope that others find this useful. I have submitted these scripts as
pull-request #1597 on github.
Cheers,
Mark Friedenbach
--
Live Security Virtual Conference
Ex
Running a concurrent Mantis tracker would be confusing and fragment the
development pathway. We have an issue tracker; it's on github.
What's being talked about here are two separate things. Jenkins is a
continuous integration system. It can be configured to run the suite of
unit tests, regression
My only comment is that it should be called escheatment, not demurrage ;)
It's relation to demurrage is only that it might be desirable to garbage
collect decayed bit-dust. We looked at it early-on in the Freicoin
development, but rejected it as a possibility due to reasons others have
mentioned,
Alan's UTxO meta-chain proposal becomes vastly easier to do now that
ultraprune is merged. That would allow the Satoshi client to know it's
wallet balance and operate with a >=SPV level of security during the
initial block download, and keep them on the path of becoming a full node.
If users can se
structure. "refheight" or "nRefHeight" is what we call this
value internally, but "blocktime" or "blockheight" would work as well.
Github is currently down, so I apologize if a suitable field has already
been added.
Cheers,
Mark Friedenbach
[1] http://fre
On Mon, Mar 11, 2013 at 11:17 AM, Benjamin Lindner wrote:
> > Just activate a non-proportional
> > demurrage (well, I won't complain if you just turn bitcoin into
> > freicoin, just think that non-proportional would be more acceptable by
> > most bitcoiners) that incentives old transactions to be
I'm not sure I understand the need for hard forks. We can get through this
crisis by mining pool collusion to prevent forking blocks until there is
widespread adoption of patched clients.
Proposal:
1) Patch the pre-0.8 branches to support an increased lock count, whatever
number is required to ma
responsibly notify people and give them time to react, then move on. Let's
not codify the bug in the protocol.
Mark
On Wed, Mar 13, 2013 at 10:58 AM, Pieter Wuille wrote:
> On Wed, Mar 13, 2013 at 10:41:29AM -0700, Mark Friedenbach wrote:
> > 4) At some point in the futu
If you're considering a datagram protocol, you might be interested in some
more modern alternatives to UDP:
UDT: Breaking the Data Transfer Bottleneck
http://udt.sourceforge.net/
Stream Control Transmission Protocol
http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol
On Sat, Mar
trol mechanisms. Multiple UDT flows can share a single UDP
> port, thus a firewall can open only one UDP port for all UDT connections.
>
> The latter appears not so friendly to NAT.
>
>
> On 3/23/2013 3:30 PM, Mark Friedenbach wrote:
> > If you're considering a datagram pro
5-a70d5b157c80')
As for encoding the chain identifier, the simplest method is to give
"network" the "bytes" type, but defining a "UUID" message type is also
possible. In either case bitcoin mainnet would be the default, so the
extra 12 bytes (vs: &qu
This was meant to go to everyone:
On 5/20/13 7:45 PM, Jeff Garzik wrote:
> On Mon, May 20, 2013 at 7:59 PM, Mark Friedenbach wrote:
>> So as to remain reasonably compliant with RFC 4122, I recommend that we
>> use Version 4 (random) UUIDs, with the random bits extracted from the
&
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Jun 01, 2013 at 10:32:07PM -0400, Gavin wrote:
>> Feels like a new opcode might be better.
>>
>> Eg 100 OP_NOP1
>>
>> ... Where op_nop1 is redefined to be 'verify depth' ...
I would suggest the more general 'push depth onto stack'. You can t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
If a technical solution could be found, I don't doubt that it will
quickly become the only legal way to do transfers in the U.S.
Peter, you are Executive Director of the Bitcoin Foundation. I would
like to know that your efforts are focused on fighti
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John,
What you are recommending is a drastic change that the conservative
bitcoin developers probably wouldn't get behind (but let's see). However
proof-of-stake voting on protocol soft-forks has vast implications even
beyond the block size limit. Wi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/23/13 3:29 AM, Andreas Schildbach wrote:
>
> Yes, I understand that. For this reason, I would vote for adding the
> usual HTTP authentication/SSL stuff to the REST API. That way, SPV users
> can decide to run their own instance of the API (provi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/18/13 8:09 PM, John Dillon wrote:
> On the other hand, a tx with some txin proofs can be safely relayed by SPV
> nodes, an interesting concept. Do the UTXO commitment people have
keeping proof
> size small in mind?
More than a kilobyte, probably
basically cryptographic
protocols expressed as bitcoin scripts. Input from any of the resident
cryptographers would be very appreciated.
Happy hacking,
Mark Friedenbach
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using
Getting OT...
For a while I've wanted to combine one of these mnemonic code generators
with an NLP engine to do something like output a short story as the
passphrase, even a humorous onem with the key encoded in the story
itself (remember the gist of the story and that's sufficient to
reconstruct
Prefix the script with OP_RETURN. Otherwise you are still contributing
to blockchain bloat.
Mark
On 9/13/13 5:51 PM, Turkey Breast wrote:
> http://www.proofofexistence.com/
>
> and
>
> https://github.com/spesmilo/sx/blob/master/src/sx-embed-addr
>
> Embedding data in the blockchain as a hash i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Also somewhat related, I have been looking for some time now to
abstract out the UTXO and block databases so that a variety of
key/value stores could be used as a backend, configured by a command
line parameter. In particular, it would be interesting f
This kind of thing - providing external audits of customer accounts
without revealing private data - would be generally useful beyond
taxation. If you have any solutions, I'd be interested to hear them
(although bitcoin-dev is probably not the right place yet).
Mark
On 9/29/13 2:37 AM, Adam Back
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
There's no reason the signing can't be done all at once. The wallet
app would create and sign three transactions, paying avg-std.D, avg,
and avg+std.D fee. It just waits to broadcast the latter two until it
has to.
On 10/25/13 5:02 AM, Andreas Peterss
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
If I understand the code correctly, it's not about rejecting blocks.
It's about noticing that >50% of recent blocks are declaring a version
number that is meaningless to you. Chances are, there's been a soft
fork and you should upgrade.
On 10/30/13 1:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Or SIGHASH of a transaction spending those coins or updating the SIN...
On 11/2/13 2:14 PM, Johnathan Corgan wrote:> On 11/01/2013 10:01 PM,
bitcoingr...@gmx.com wrote:
>
>> Server provides a token for the client to sign.
>
> Anyone else concerned a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/4/13 10:16 AM, Peter Todd wrote:
> Again, the right way to do this is define the standard to use the
> last txout so that midstate compression can be applied in the
> future. We can re-use this for merge-mining and other commitments
> easily by d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/4/13 11:38 AM, Mike Hearn wrote:
> The Merkle branch doesn't get stored indefinitely though, whereas
> the coinbase hash does. The data stored in the coinbase [output]
> can always just be the 256-bit root hash truncated to less.
>
> I doubt the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
For this reason I'm in favor of skipping mBTC and moving straight to
uBTC. Having eight, or even five decimal places is not intuitive to
the average user. Two decimal places is becoming standard for new
national currencies, and we wouldn't be too far f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/14/13 2:00 PM, Alan Reiner wrote:
> Just keep in mind it will be a little awkward that 54.3 uBTC is
> the smallest unit that can be transferred [easily] and the standard
> fees are 500 uBTC.It's not a deal breaker, it's just something
> that
arzik wrote:
> Go straight to uBTC. Humans and existing computer systems handle
> numbers to the left of the decimals just fine (HK Dollars, Yen).
> The opposite is untrue (QuickBooks really does not like 3+ decimal
> places).
>
> - Jeff
>
> On Nov 14, 2013 4:40 PM,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/14/13 3:01 PM, Luke-Jr wrote:
> I think we all know the problems with the term "address". People
> naturally compare it to postal addresses, email addresses, etc,
> which operate fundamentally different. I suggest that we switch to
> using "invoi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/14/13 4:15 PM, Luke-Jr wrote:
> On Thursday, November 14, 2013 11:11:26 PM Mark Friedenbach wrote:
>> "key id" (thanks sipa).
>
> To be clear, I wasn't suggesting renaming scriptPubKey, which sipa
> was talk
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/15/13 4:41 PM, Drak wrote:
> For years, people had a problem with "email address", instead
> using "email number" but they got there eventually. Most people
> nowadays use "email address" So "payment address" or "bitcoin
> address" make better s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/15/13 5:19 PM, Drak wrote:
> Maybe, but again from the user's perspective they pay someone, and
> they receive money - just like you do with paypal using an email
> address. The technical bits in the middle dont matter to the user
> and trying to
I too would be against the foundation taking control of hosting or the
domain. I have no reason at this time not to trust them, by checks and
balances are a good thing.
On Dec 8, 2013 12:29 PM, "Mike Hearn" wrote:
> Issues that would need to be resolved:
>
> 1) Who pays for it? Most obvious answe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/13/2013 09:26 AM, Mike Hearn wrote:
> I'm thinking about a use case I hope will become common next year
> - pastebin style hosting sites for payment requests. Like, if I as
> a regular end user wish to use the payment protocol, I could just
> upl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Transactions != blocks. There is no need for a "merge" block.
You are free to trade transactions off-line, so long as you are
certain the other parties are not secretly double-spending coins they
send you on the block chain.
When connection to the bi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello fellow bitcoin developers. Included below is the first draft of
a BIP for a new Merkle-compressed data structure. The need for this
data structure arose out of the misnamed "Ultimate blockchain
compression" project, but it has since been recogniz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
JSON-RPC is a huge security risk. It's perfectly reasonable that
enabling it requires some technical mumbo-jumbo.
Are there specific configuration settings that you would like to see
exposed by the GUI?
On 12/19/2013 11:49 PM, Chris Evans wrote:
> m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Jeremy, Let's give a preview of the application-oriented BIPs I
mentioned:
Stateless validation and mining involves prefixing transaction and
block messages with proofs of their UTxO state changes. These are the
"operational proofs" I describe in t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
(Sorry Peter, this was meant for the whole list:)
On 12/20/2013 05:17 AM, Peter Todd wrote:
> I've thought about this for awhile and come to the conclusion that
> UTXO commitments are a really bad idea. I myself wanted to see them
> implemented about
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/20/2013 11:48 AM, Gregory Maxwell wrote:
> A couple very early comments— I shared some of these with you on
> IRC but I thought I'd post them to make them more likely to not get
> lost.
I got the inputs from IRC, but thank you for posting to the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ryan, these sort of adjustments introduce security risks. If you were
isolated from the main chain by a low-hashpower attacker, how would
you know? They'd need just three days without you noticing that
network block generation has stalled - maybe they
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
There is a standard mechanism for doing that called deterministic
signatures and is described in RFC 6979. It uses the private key and
the HMAC construction to generate a ECDSA k value.
On 01/03/2014 10:16 AM, Tier Nolan wrote:
> The random number tha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/06/2014 10:13 AM, Peter Todd wrote:
> On Sun, Jan 05, 2014 at 07:43:58PM +0100, Thomas Voegtlin wrote:
>> I have written a Python-levelDB implementation of this UTXO
>> hashtree, which is currently being tested, and will be added to
>> Electrum s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/06/2014 10:31 PM, Thomas Voegtlin wrote:
> You are right. The 256-way branching follows from the fact that the
> tree was implemented using a key-value database operating with byte
> strings (leveldb). With this implementation constraint, a diffe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/15/2014 04:05 PM, Jeremy Spilman wrote:
> Might I propose "reusable address".
Say it like it is. This is the only suggestion so far that I really like.
No amount of finger wagging got people to stop using the block chain
for data storage, but n
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/17/2014 01:15 AM, Mike Hearn wrote:
> I must say, this shed is mighty fine looking. It'd be a great place
> to store our bikes. But, what colour should we paint it?
>
> How about we split the difference and go with "privacy address"?
> As
Too c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
CPFP is *extremely* important. People have lost money because this
feature is missing. I think it's critical that it makes it into 0.9
If I get a low-priority donation from a blockchain.info wallet, that
money can disappear if it doesn't make it into
On 01/18/2014 03:05 AM, Wladimir wrote:
> On Sat, Jan 18, 2014 at 9:11 AM, Odinn Cyberguerrilla
>
>
>
> regarding:
> stuff not getting into blockchain in a day's time,
> microdonations not facilitated as much as they could be,
>
> Please point to your pull requests improving the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Since you are taking the hash of Unicode data, I would strongly
recommend using a canonical form, e.g. Normalized Form C.
On 01/20/2014 09:42 AM, slush wrote:
> Hi all,
>
> during recent months we've reconsidered all comments which we
> received from
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Proper Unicode handling is a serious issue however. You don't want
someone to move from one input method / machine to another and
suddenly find that their coins are inaccessible, because of an issue
of decomposed vs. compatibility forms or whatever.
O
On 02/12/2014 08:44 AM, Alan Reiner wrote:
> Changing the protocol to use these static IDs is a pretty fundamental
> change that would never happen in Bitcoin. But they can still be
> useful at the application level to mitigate these issues.
Not to mention that it would be potentially very insec
1 - 100 of 147 matches
Mail list logo
